8

Excuse me for such an elementary question. I understand that the Application class is instantiated when my app's process starts and I understand when the phone is completed booting my boot receiver will be called. I'm assuming since the phone knows via the manifest that my app holds BOOT_COMPLETED intent filter, the reboot process is. Phone reboots, phone starts all processes with BOOT_COMPLETED, phone fires off BOOT_COMPLETED broadcast. My concern came from wondering if I reference Application class instance variables within my boot receiver if the receiver would ever get called before my Application class was instantiated.

Again excuse me if this is dead obvious. I've never fully understood the reboot mechanics.

Captain Kirk
  • 350
  • 6
  • 24

2 Answers2

7

An Application is always started before any of its Activities/Services/Receivers. Here are a couple of blogs that go into the details:

[Edited]

But, according to a comment by @CommansWare:

Based on logging, the instance of the ContentProvider is created after the instance of the Application. However, onCreate() of the ContentProvider is called before onCreate() of the Application.

So, it is probably not safe to try to use the Application instance within a provider's onCreate().

cybersam
  • 63,203
  • 6
  • 53
  • 76
  • Maybe I am missing it, but I do not see where the blog posts back up your claim. For example, the string "provider" appears only once in the first post and not at all in the second. The first post's use of "provider" simply defines what one is. Similarly, the more generic term "component" is used in the first post, not the second, and nowhere does it state that the `Application` is created before any component. And while both blog posts refer to "application", I see no evidence that any of the references refer to the `Application` instance, but rather "application" as the long form of "app". – CommonsWare Jan 24 '15 at 23:53
  • 2
    @CommonsWare: Blog 2 states "This method invokes makeApplication() method which loads app specific classes into memory." And to be really clear, looking at the [code for makeApplication](http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.3_r1/android/app/LoadedApk.java#LoadedApk.makeApplication%28boolean%2Candroid.app.Instrumentation%29), we see that it returns an Application instance. Also, the question did not even ask about providers, but to make you happy :-), I have edited my answer to remove that word. – cybersam Jan 25 '15 at 00:04
  • 2
    I agree with your edit. `ContentProvider` is actually a mixed bag. Based on logging, the instance of the `ContentProvider` is created after the instance of the `Application`. However, `onCreate()` of the `ContentProvider` is called before `onCreate()` of the `Application`. – CommonsWare Jan 25 '15 at 00:18
  • Very interesting. So there is a window where the ContentProvider cannot rely on there being an Application instance. . Thanks for being exact. I have quoted you no in my answer. – cybersam Jan 25 '15 at 00:19
4

Phone reboots, phone starts all processes with BOOT_COMPLETED, phone fires off BOOT_COMPLETED broadcast.

I would phrase it more as "phone reboots, phone fires off BOOT_COMPLETED broadcast, and normal broadcast processing occurs, including starting any necessary processes".

My concern came from wondering if I reference Application class instance variables within my boot receiver if the receiver would ever get called before my Application class was instantiated.

It shouldn't. The order of instantiation is supposed to be:

  • any ContentProviders you have defined in your manifest, then

  • the Application instance, then

  • the component that triggered the need for the process (in this case, your ACTION_BOOT_COMPLETED BroadcastReceiver)

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Thanks CommonsWare. Do you happen to have a link where this is talked about on d.android.com? – Captain Kirk Jan 24 '15 at 23:20
  • 2
    @user1701153: I am not aware that it is talked about on d.android.com. This is the sort of thing that you pick up by working on Android for (gulp!) eight years, monitoring comments from Google engineers and whatnot. – CommonsWare Jan 24 '15 at 23:21
  • I've added an answer with a couple of links to blogs from somebody who worked in the "Android Performance team at Qualcomm". – cybersam Jan 24 '15 at 23:23