Waiting for Android Dev phone for long time

by adag » Tue, 22 Sep 2009 01:15:45 GMT

Sponsored Links
 Hello Google Android Team,

Could you please let us know when android dev phone would be available
in the market. We were waiting for long time. Now even the
notification in  http://android.brightstarcorp.com/index.htm site also 
way beyond. It says dev phone would available early September. Where
as time crosses even mid September. Its a humble request to Google
android team to let us know when possibly it would available and if it
is not what are the other alternatives to have development hand set.
Because my development is drastically getting hampered without
development handset.



Waiting for Android Dev phone for long time

by Brian Conrad » Tue, 22 Sep 2009 02:38:57 GMT

 I'm wondering if they are planning to drop the program due to emergence 
of Android phones from other carriers?  I'm going to watch what Sprint 
does because if I recall correctly they had a pretty good program for 
developers as far as getting phones and an inexpensive month-to-month 
developer phone account so you can test the phone.


Sponsored Links

Waiting for Android Dev phone for long time

by Kent Loobey » Tue, 22 Sep 2009 04:13:54 GMT


Please let us know if you find that they are doing this.


Other Threads

1. Touch Screens

Anybody know if there are currently Android phones that DON'T have touch 
screens? Just asking because I'm starting a new project and wondering if 
I can rely on the user having a touch screen or not.


Brad Gies
Bistro Bot - Bistro Blurb

Never doubt that a small group of thoughtful, committed people can
change the world. Indeed. It is the only thing that ever has - Margaret Mead


2. Info: Android Predicates (Surrounding Architecture)

What I know as likely to be true
1. An application represented by an apk file (usually) runs in its own proces
2. Each such application or package runs under its own linux user id
to create/access resources underneath
3. Such a linux user id is usually auto generated
4. You can assign an explicitly specified shared id to a package to run under.
5. Each package or application in Android must be signed

6. A shared id is unique across the system and not just with in your
set of packages.
7. The format of this id typically follows the java package structure
to keep it unique.
8. Two or more packages can specify the same shared user id as long as
they are signed by the same certificate
9. Once an application is in the market you can not turn on/off the shared id
10. Once an application is in the market you can not reassign the shared id

11. An android application has 4 types of components
        a) Activity
        b) Content Provider
        c) Service
        d) Broadcast Receiver

12. A single thread called main thread is used to run all the components

13. The main thread is always responsible for the execution of the following
        a) Activty
        b) Local service that is accessed in-process
        c) Broadcast Receiever (whether local or remote)

14. Thread pools are used to run the following cases
        a) Content providers accessed from outside
        b) Services that are bound from outside

15. The thing about broadcast receivers is that even though they are
frequently used to entertain outside clients they still run  under the
main thread.

16. You cannot have two distinct signatures for the same package. In
otherwords two developers cannot install a package that carries the
same package name.
17. However same signature can be used to sign any number of packages
18. One-to-many: In other words a "One" signature supports "Many" packages
19. One-to-One: "One" package has one and only "One" signature
20. Signatures are protected by developer using a password
21. Keytool and Jarsigner are used to provision jar signing

22. One will use Context.createPackageContext(<packagename>) to get
access to the package needed
23. You can share more if both packages are signed with the same
signature and they have the same shared id
24. You can share another packages resources even if that package
doesn't belong to you as long as that packages declares those
resources to be sharable

25. A broadcast receiver has a 10 sec limit before an ANR is prompted
26. UI events have a 5 sec tolerance before an ANR is rushed
27. A broadcast receiver can be local or remote
28. A broadcast receiver is indicated by the <receiver> tag
29. To do long work in a broadcast reciver you must follow the following pattern
        a) tell the device to dont turn off by getting a wake lock
        b) start a service to keep the process alive
        c) start a thread
        d) when the thread finishes tell the service to stop, release the
lock, and release the process
        e) Meanwhile return from the broadcast receiver as soon as the service 
is setup
30. A sendBroadcast() call is used to start a broadcast receiver

31. a sendBroadcast() although intent based, these intents never touch
an activity or service
32. A broadcast receiver has one method "onreceive"
33. A broadcast reciever process is ready to go away as soon as teh
"onreceive" finishes unless you have taken steps to convert the
broadcastreceiver into a service
34. You can have a broad cast receiver that doesnt have any intent
filter. this is called a local only broadcast receiver
35. you invoke local broad cast receivers with explicit class names
36. An ANR shows up in two cases
        a) No UI response for 5 secs
        b) BroadcastReceiver hasn't returned in 10 secs

What I don't know yet
1. what is the structure and life time of auto generated linux user
ids. Do they stick around? Does that have any adverse effect on the
underlying linux process having to carry these additional userids?

2. what is the motivation behind an explicitly class based in-process
broadcast receiver? Can I just not use a function call?

3. Why isnt there a version of broadcast receiver that is essentially
service which we end up standing up using the same boiler plate code
every time?

4. what does it mean by loading a specific component in a different
process? Is this as simple as making the jar file available to that
process? Or are there any implication to statics, initialization etc.

What resources have I used to gather this
I may have misread these resources below, but I didn't make up the
above predicates.

1. http://developer.android.com/guide/topics/fundamentals.html#procthread
A link to understand the processes/threads/components. This is where
google states thread pools for certain components.

2. http://developer.android.com/guide/topics/manifest/receiver-element.html
This is the link for the receiver element where they talk about local
and remote receivers.

3. http://developer.android.com/guide/practices/design/responsiveness.html
This links talks about how broadcast receivers do indeed run on the
main thread and that the 10 sec limitation is put on their

Read the restrictions on shared usedid from Dianne. Also the use of

You will see here a) how to sign apk files b) further links to how to
share data between them c) share user id d) install/uninstall

6. http://developer.android.com/guide/publishing/app-signing.html
This link is a must read for signing apk files

7. http://java.sun.com/j2se/1.3/docs/tooldocs/win32/keytool.html
Excellent documentation on key tool, jar signer, and the signing process itself

My notes on understanding what it means to sign a jar file. A conceptual model


3. Android Suspend geeting called continuously

4. Application losing SharedPreferences and Sqlite database on Droid

5. Miring di hari Sabtu

6. eclipse upgrade now will not run emulator

7. G1 phone and update firmware 2.0-2.2 - question