FirebaseInstanceID breaking multi-process apps on Android?

[Uli Bubenheimer]

I've been surprised to notice that FirebaseInstanceIdService and FirebaseInstanceId.getInstance() work only in the main Android app process. When run in an external process, the service will never be called, and getInstance() throws an exception: java.lang.IllegalStateException: FirebaseApp with name [DEFAULT] doesn't exist.

Are the Firebase folks aware of this issue? I have not seen any mention of it. This works great with GCM, and I need this resolved to bring my app over to Firebase.

I've tested this with Play Services 9.2.1 and 9.4.0  on the API 21 emulator.

[Doug Stevenson]

Uli,

Firebase initializes itself in the main process automatically by a ContentProvider that gets merged into your manifest at build time.  ContentProviders aren't created in other processes, so you will have to manually init Firebase in your other processes in order to make use of Firebase features.  I have not tried this myself yet, but my understanding is that you should do this via the FirebaseApp singleton using its initializeApp() function that takes three args.  You'll need to arrange for this to happen at the entry point for your component that expects to run in another process.

All that said, you may experience some problems if you use some features of Firebase in a second process.  In particular, Firebase Realtime Database will definitely not work with persistence enabled (there is no sync among processes to write to its sqlite datastore), and I believe Remote Config will not work either, for similar reasons.  I'm not sure about FCM, though.

Doug

[Uli Bubenheimer]

Thanks for the clarification. What I've done now is to simply swap my processes around, so that Firebase components run in the process that I want, and my UI runs in the external process. Seems to work at least for Instance ID and FCM.

An alternative, that I started with, is to force all the Firebase-related components into my external process by overriding the merged manifest entries from Firebase in my own manifest. That worked, too, but is a lot of typing and can easily get out of sync when Firebase updates.

I may have to reconsider soon, though, when adding Firebase dependencies that are more close related to the UI.

Could it be time to rethink the Firebase design with a multitude of services being offered under the same umbrella now?

Uli

[Doug Stevenson]

Uli,

You're right, overriding Firebase components in the manifest will require some diligence to determine if anything changes between releases.  I think the new APK analyzer in Android Studio 2.2 preview can help you spot merged Firebase components, if you're not using that already.  You can use that to easily see the fully merged manifest, then copy and compare it to a build with an updated version of Firebase.

If any of the current Firebase SDK has limitations that are difficult to manage for your situation, I would encourage you to file a feature request and describe your situation so that we can have a record of what you're doing.  While I can't guarantee anything will be done in response, we do take that feedback seriously and consider it for future development.  https://firebase.google.com/support/contact/bugs-features/

Doug

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/sIogPuUsC50/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/41b998ed-479e-4d82-9fba-9b79d13ccab9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Uli Bubenheimer]

I will keep these in mind. Thanks again for the assistance!

With feedback in mind, my sentiment is not positive towards imposing otherwise configurable functionality via Manifest merging and Google Services Gradle plugin. I see these approaches as only facilitating the configuration of toy projects, but making configuration of real apps exceedingly difficult, besides being scantly documented. It's a terrible trade-off, and I hope that Google will correct course on these. I just watched the I/O talk on FCM stating easier use than GCM. I find the opposite to be true.

Uli

On Friday, August 12, 2016 at 3:52:08 PM UTC-5, Doug Stevenson wrote:

Uli,

You're right, overriding Firebase components in the manifest will require some diligence to determine if anything changes between releases.  I think the new APK analyzer in Android Studio 2.2 preview can help you spot merged Firebase components, if you're not using that already.  You can use that to easily see the fully merged manifest, then copy and compare it to a build with an updated version of Firebase.

If any of the current Firebase SDK has limitations that are difficult to manage for your situation, I would encourage you to file a feature request and describe your situation so that we can have a record of what you're doing.  While I can't guarantee anything will be done in response, we do take that feedback seriously and consider it for future development.  https://firebase.google.com/support/contact/bugs-features/

Doug

On Thu, Aug 11, 2016 at 8:02 PM, Uli Bubenheimer <ubu...@gmail.com> wrote:

Thanks for the clarification. What I've done now is to simply swap my processes around, so that Firebase components run in the process that I want, and my UI runs in the external process. Seems to work at least for Instance ID and FCM.

An alternative, that I started with, is to force all the Firebase-related components into my external process by overriding the merged manifest entries from Firebase in my own manifest. That worked, too, but is a lot of typing and can easily get out of sync when Firebase updates.

I may have to reconsider soon, though, when adding Firebase dependencies that are more close related to the UI.

Could it be time to rethink the Firebase design with a multitude of services being offered under the same umbrella now?

Uli

On Thursday, August 11, 2016 at 5:39:04 PM UTC-5, Doug Stevenson wrote:

Uli,

Firebase initializes itself in the main process automatically by a ContentProvider that gets merged into your manifest at build time.  ContentProviders aren't created in other processes, so you will have to manually init Firebase in your other processes in order to make use of Firebase features.  I have not tried this myself yet, but my understanding is that you should do this via the FirebaseApp singleton using its initializeApp() function that takes three args.  You'll need to arrange for this to happen at the entry point for your component that expects to run in another process.

All that said, you may experience some problems if you use some features of Firebase in a second process.  In particular, Firebase Realtime Database will definitely not work with persistence enabled (there is no sync among processes to write to its sqlite datastore), and I believe Remote Config will not work either, for similar reasons.  I'm not sure about FCM, though.

Doug

On Wednesday, August 10, 2016 at 4:35:52 PM UTC-7, Uli Bubenheimer wrote:

I've been surprised to notice that FirebaseInstanceIdService and FirebaseInstanceId.getInstance() work only in the main Android app process. When run in an external process, the service will never be called, and getInstance() throws an exception: java.lang.IllegalStateException: FirebaseApp with name [DEFAULT] doesn't exist.

Are the Firebase folks aware of this issue? I have not seen any mention of it. This works great with GCM, and I need this resolved to bring my app over to Firebase.

I've tested this with Play Services 9.2.1 and 9.4.0  on the API 21 emulator.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/sIogPuUsC50/unsubscribe.

To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.

[Uli Bubenheimer]

For the record - I had to revert to the manual copying & customizing of all merged Firebase components in the Manifest. Android Studio bug prevents attaching the debugger to an app configured to use a separate process as its primary process. More frustration.