Only one Application per-.apk-per-process is created, ever. If you use android:process to have multiple .apks sharing the same process, each .apk will have its own Application instantiated in the process. If you use android:process to have an .apk run in multiple processes, each process will get its own Application instance.
Application.onTerminate() is *never* called. This function is there for environments where processes are emulated, which is not any production device or the emulator. But it doesn't matter that it isn't called because... well, Application lives for the lifetime of the process, and the process goes away by the OOM killer killing it, which cleans up Application and everything else related to the process without any user space code for it running. Now it is conceivable that there is some case where if a process is left completely empty (with no app components) for a while, and GCs, the data about the loaded process may get GCed as well and have to be recreated. I don't see how this can happen off-hand (there are a number of ways non-weak-references are held between these things), but I can't say for certain there is no such bug here. That said, my recommendation to everyone is to just not subclass Application. This gives you *nothing* you can't do in other, better ways. In particular, a singleton directly represents what is really going on (it lives for the life of the process after the first need for it) and helps keep code more modular. I regret that the Application class was ever introduced; it was a compromise to make people more comfortable with there being some kind of traditional "main application" concept, but in fact it doesn't really fit in with how Android works so ends up just causing problems. As far as using Application to clean up statics -- this simply doesn't really make sense, for the reasons above. For a legacy application with statics that can't be re-used again in the same process, your only choice is probably to just self-kill your process when the user leave the game. That is, when the game activity is finished. If you can reset your statics after the game is over, then at least instead of killing it you can do that when the activity is finished. But this needs to be driven by Activity, not Application. On Sun, Oct 31, 2010 at 12:34 AM, Mark Murphy <mmur...@commonsware.com>wrote: > In a comment on an epic StackOverflow question-and-answer, a gentleman > who I will call Tim has outlined a scenario he says he is running > into, one I have some difficulty believing. > > Reading somewhat between the lines, the flow would appear to be this: > > 1. User taps on an activity icon in the launcher > 2. Process starts up > 3. Application object is put in that process -- and a custom > Application object loads an NDK library which initializes some > statics/singletons > 4. User uses application > 5. User abandons application (e.g., HOME) > 6. Later, user returns to application, before the first process is > killed or recycled for use with another app > 7. A second Application object is created, in the same process, before > the first Application object is called with onTerminate() > > This screws things up for Tim's app -- apparently, it does not deal > with pre-initialized statics/singletons well. They were presumably > counting on onTerminate() to let them clean up the NDK space. As a > result, they are relying upon killProcess() (somehow...unclear under > what conditions they might call this) to force their own process to go > away, so their statics get cleaned up. > > Step #7 is what confuses me. I can see a new Application object being > created, but only if the first Application object were terminated. I > don't see any NDK-related bugs out on b.android.com that seem to match > this complaint, though in principle it might cause problems for > non-NDK apps as well. > > Has anyone encountered a new Application object being created in a > process before the old one is terminated? > > Thanks! > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > Android 2.2 Programming Books: http://commonsware.com/books > > -- > 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<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
