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
responsiveness
4.
http://stackoverflow.com/questions/2721386/android-how-to-share-code-between-projects-signed-with-the-same-certificate
Read the restrictions on shared usedid from Dianne. Also the use of
createPackageContext.
5.
http://www.satyakomatineni.com/akc/display?url=DisplayNoteIMPURL&reportId=3279&ownerUserId=satya
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
8.
http://www.satyakomatineni.com/akc/display?url=DisplayNoteIMPURL&reportId=3493&ownerUserId=satya
My notes on understanding what it means to sign a jar file. A conceptual model
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
