I think the best way to approach thinking about this is to recognize that for each main concepts, there's either two or three different LEVELS of existence. It's also helpful to be very clear about what is meant by "application", and to recognize that's separate from Task as well as Process.
When you install a .apk file, the package manager examines the AndroidManifest.xml file and notes the existence of a new application, and its associated activities, services, and broadcast receivers. When something happens to trigger one of these -- let's say the user taps on an application icon, triggering an intent for the main activity -- the system identifies what declared activity should run. At this point, it creates a new activity, and in this case, it also assigns that new activity to a new task. This new activity has an implied "application" object, that corresponds to what's declared in the manifest. These are logical things at this point. To actually implement the functionality, the system does this: 1) It looks for a process already running for this package. If there is one, it starts one. 2) It looks for the proper Application INSTANCE in that process. If it exists it uses it, otherwise it creates it and runs its onCreate() method. 3) It creates the Activity INSTANCE, runs its onCreate() method, etc. At this point, the Activity exists at three different levels. * It has a Java object, with methods being called on the UI thread at various poinits. * It has a system representation of an active activity, that points both to the running INSTANCE and to the .apk it came from * It has the declared potential existence in the .apk file. If the process is killed, the Java representation of the activity is first told about it, so it can save its state, and restore it when it is recreated. But while the process is killed: The Activity Java instance no longer exists. The Activity system representation still exists, and it still exists on the stack of activities in the task. The .apk file still exists, of course. Now, when the activity needs to run, the system once more starts a process, and launches an activity INSTANCE in that process. What about the Application? Well, the application INSTANCE also was destroyed. Unlike Activities, they don't get told they're about to be destroyed, so the Application doesn't save any state. But the Activity instances do. To create an Activity INSTANCE, you first have to have an application INSTANCE, so the system will always create one of those first. So, if you implement your state saving correctly -- the process will be destroyed, but the next time the logical activity and its application need to do something, new INSTANCES will be created in a new PROCESS, which will pick up where the old ones left off, using the saved state. The activities declared in a .apk are class-like, or template-like -- you may have more than one of the system representations, if the user does something to invoke them multiple times. So following a link on a game app's About page may take you to a web browser activity, and on to a succession of 20 more web browser activities. Hit the back button 21 times, and you're back to the game. app. That's all one task, with activities from two different applications running in two different processes, and with 21 occurrences of the Web Browser activity at the logical level -- but no more than one actual instance is really needed at a time! If you switch to a different task -- BOTH processes may be killed -- and the browser process restarted when you return, and then finallly, the game restarted when you hit the back button enough times! This really isn't all that complicated, but the closely-related concepts for each makes reading the documentation confusing. There's a level of existence for each of these things that does NOT depend on the existence of a process, and a level that DOES. The level that DOES is what runs code, and thus is what the lifecycle documentation is primarily concerned with. But each logical system-level activity also has a definite beginning and end. So to answer your last question: " in what scenario could this occur and how is the application accessible if the containing process has been killed? " The application INSTANCE is destroyed ANY time the process is destroyed, and so are all of the activity and service INSTANCES associated with it. You can't access it in this state, simply because you have no running code, and no running activity or service INSTANCE from which to access it. When you DO -- the application INSTANCE is recreated first, and so you access it just like you always would. You can NEVER run any code that would see it missing. I hope this helps... On Mar 15, 4:39 am, Fuzzyboy <run...@gmail.com> wrote: > Being interested in Android development and still in the > experimentation phase - there's something I haven't been able to > grasp. > > As far as I've been able to understand, the process lifecycle and > applikation lifecycles are seperate and as such, it would be possible > for the application to still to exist, even if it's process has been > killed. > > So I guess my question would be, in what scenario could this occur and > how is the application accessible if the containing process has been > killed? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
