"MESSAGING_EVENT" and "INSTANCE_ID_EVENT" running Services in apps started in "Restricted Mode"

[pablobaxter]

Describe your environment

• Android Studio version: 3.6.2
• Firebase Component: FCM, InstanceID
• Component version: 16.1.0

Describe the problem

There is a specific instance in Android where an app can be started without calling any ContentProviders or the Application listed in the app's manifest.

From https://developer.android.com/guide/topics/data/autobackup#ImplementingBackupAgent:

During auto backup and restore operations, the system launches the app in a restricted mode to both prevent the app from accessing files that could cause conflicts and let the app execute callback methods in its BackupAgent. In this restricted mode, the app's main activity is not automatically launched, its Content Providers are not initialized, and the base-class Application is instantiated instead
of any subclass declared in the app's manifest.

The problem here is that we can still send intents to a BroadcastReceiver or Service that is exported (such as FirebaseMessagingService). I have seen several crashes in the Google Play console that don't exist in Firebase Crashlytics, that made absolutely no sense unless my Service ran before my custom Application class or any of the ContentProvider classes I had, which I thought was never the case.

After some testing, I verified that this was in fact happening, and explained some other crashes that made no sense. Essentially, the app can start without ever initializing Firebase (unless we initialize it on the Service itself) and still get external intents from Firebase, causing crashes.

Steps to reproduce:

1. Install any app that is setup with FirebaseMessagingService (ensure FirebaseApp.getInstance() is called in it) and has android:allowBackup="true" in the AndroidManifest.xml.
2. Ensure the device has a Google account setup in it.
3. Perform a backup on the device via ADB (adb shell bmgr backupnow com.mypackage.foo. More info here: https://developer.android.com/guide/topics/data/testingbackup)
4. While the backup is occurring, trigger a MESSAGING_EVENT intent to start the service

If done correctly (or incorrectly?), the app will crash because FirebaseApp was not initialized.

[google-oss-bot]

I found a few problems with this issue:

• I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
• This issue does not seem to follow the issue template. Make sure you provide all the required information.

[andirayo]

Fly-by-comment:
Could it be that FIS or IID requires an FirebaseApp object to request FirebaseOptions from it?

[ashwinraghav]

@pablobaxter Thanks for the raising the (excellently described and analyzed) issue!
I remember seeing your question on firebase-talk as well.

@ciarand Do we have the option of invoking the com.google.firebase.MESSAGING_EVENT intent after determining whether the receiving app is currently in restricted mode and scheduled it for a later if it is ?

@pablobaxter Sry your current work around (as quoted on the thread) is to disable automatic backups. That does not seem ideal. Do you have the option of catching the exception and exiting early ? You may also be able to persist the contents of the remote msg and read it at a later time using one of the background processing options depending on your use case ?

[ciarand]

Thanks @pablobaxter, this is a really useful bug report. Can you post one of the stack traces from the Google Play console?

[pablobaxter]

@ashwinraghav No worries! This issue actually explains some of the Dagger issues I kept seeing when I try to cast the Application object, along with other oddities (it brought sanity back to my world). I believe this is an Android platform issue, as when the app crashes while in restricted mode, the next time you tap on the app icon, the process is re-launched in this restricted mode. It looks like the only fix is to restart the phone, but I need to validate this is truly the case.

@ciarand Here is the stack trace I posted on the Firebase forum:

Caused by: java.lang.IllegalStateException: 
  at com.google.firebase.FirebaseApp.getInstance (FirebaseApp.java:219)
  at com.google.firebase.iid.FirebaseInstanceId.getInstance (FirebaseInstanceId.java)
  at com.google.firebase.iid.FirebaseInstanceId.getInstance (FirebaseInstanceId.java)
  // Service that calls "FirebaseInstanceId.getInstance()"

Let me know if you need anything more.

[ciarand]

Just so I'm super clear: your code is calling FirebaseInstanceId.getInstance() in response to receiving a message (i.e. in your onMessageReceived hook)? It's not happening as part of FCM's setup before we call your onMessageReceived, right?

[pablobaxter]

For this specific crash, yes. I don't know if FCM calls for an instance of the FirebaseApp internally, but if it does, I would expect that to crash as well, since the FirebaseInitProvider would not be called.

[ciarand]

Awesome, thanks @pablobaxter. I've raised an issue internally and we're figuring out what the right thing for the SDK to do is. It doesn't seem like there's a straightforward mechanism by which we can determine whether the app is running in this restricted mode, which makes fixing it on the SDK side a little more difficult. Because this is a pretty advanced use case, the solution might just end up being adding documentation that talks about this mode specifically to the general Firebase Android docs.

To solve this for now it seems like you should be able to hook into the BackupAgent's onCreate, or you could conditionally do it in the FirebaseMessagingService#onCreate based on whether FirebaseApp.getApps() is empty. Not a super elegant solution (and the 2nd version assumes that the only app that will be instantiated is the default one), but doesn't really incur any extra performance overhead compared to doing it in the Application#onCreate or leaving it to the init provider.

[pablobaxter]

@ciarand No problem! Let me know if there is anymore info I can provide. For the meantime, I disabled allowBackup as it's causing other issues (not Firebase related, but caused by Restricted Mode), and will test around what else might start services/receivers. Most obvious thing that comes to mind are alarms/jobs.

🎶 Hi ho, hi ho, fun with code I go... 🎵