Explaining redundant Cloud messaging permissions added by FB analytics\crash

[Eugene Zakhareyev]

Hello,

We are using 

compile 'com.google.firebase:firebase-common:9.6.1'

compile 'com.google.firebase:firebase-core:9.6.1'

compile 'com.google.firebase:firebase-analytics:9.6.1'

compile 'com.google.firebase:firebase-crash:9.0.1'

And it appears that adding Firebase Analytics and Crash adds Cloud messaging permissions to our app, specifically 

com.google.android.c2dm.permission.RECEIVE

${applicationId}.permission.C2D_MESSAGE

Our app does not make use of any cloud messaging functionality.

It was referenced before in this thread https://groups.google.com/forum/#!topic/firebase-talk/CXgecSxgsRE, to the effect that permissions are implementation details and app developers should leave them alone lest they interfere with FB analytics and crash handling.

Our company has few apps with multimillion existing user base, and we are looking at migrating our analytics backend from Google Analytics to Firebase. In the past, when permissions were added to the existing app it has resulted in very slow upgrade velocity (as compared with app update with no permission change) and multiple support tickets from users (to explain added permission).

Ideally we would like to be able to add only permissions that derived from the library functionality; if we are risking thousands of users staying on old versions of our app because of onboarding to FB, this becomes not only engineering issue. 

In case every Firebase module absolutely requires those permissions, could I suggest that documentation includes this data as part of onboarding guide (or would appreciate pointers if such guide exists)? It appears that may be quite important for developers converting from GA to Firebase.

Additionally, it appears that WAKE_LOCK permission gained in importance in FB (as compared with GA where that was a requirement only for non-GP devices) and cannot be safely removed. Could that be reflected in documentation too?

Thanks much,

Eugene

 

[Doug Stevenson]

Eugene,

The two permissions you cite for FCM are examples of custom permissions that are not provided by the core Android OS.  These are used in conjunction with Play services, which is its own app on the user's device.  I don't think that custom permissions show up in the play store, since they don't imply that the customer's device or data can be accessed.  You could test this for yourself by publishing an update to an app that does not use Firebase to the alpha or beta channel of an existing app that does not yet use Firebase, and see what the user experience is like at the time of upgrade.

WAKE_LOCK is a pretty standard permission.  If someone asks about it, you could cite the official documentation, saying that the app uses components that may require to "keep the processor from sleeping or screen from dimming" for brief amounts of time, in order to operate correctly during those moments.  That statement should be true of any app that actually needs to use WAKE_LOCK correctly.  Any more detail than that would probably confuse the end user.

If you have specific requests regarding the functionality or documentation of Firebase, you are more than welcome to state you case as a feature request, which will get logged in our system and triaged appropriately.

BTW, the latest version of the Firebase client libraries for Android is 10.0.1 - I think it's worthwhile to stay up to date, as 9.6.1 is a few months old now.

Doug

[Eugene Zakhareyev]

Doug,

Thank you for your prompt response. If custom permissions are not visible to the users in any way, then it should be no problem for the app update (but we shall certainly test that before major rollout).

Yours truly,

Eugene