IOException SERVICE_NOT_AVAILABLE FirebaseMessaging
See original GitHub issue[READ] Step 1: Are you in the right place?
Issues filed here should be about bugs in the code in this repository. If you have a general question, need help debugging, or fall into some other category use one of these other channels:
- For general technical questions, post a question on StackOverflow with the firebase tag.
- For general Firebase discussion, use the firebase-talk google group.
- For help troubleshooting your application that does not fall under one of the above categories, reach out to the personalized Firebase support channel.
[REQUIRED] Step 2: Describe your environment
- Android Studio version: 2021.1 Patch 1
- Firebase Component: com.google.firebase:firebase-messaging ( Firebase Messaging )
- Component version: 23.0.3
[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
Hi! We are experiencing a crash when trying to get the token for Firebase Cloud Messaging. This is happening in production, for some users only, Samsung and Nokia devices, but we are not able to reproduce it when downloading the app on our side or deploy from Android Studio.
The stacktrace is as follows:
Caused by java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: SERVICE_NOT_AVAILABLE
at com.google.firebase.messaging.FirebaseMessaging.blockingGetToken(FirebaseMessaging.java:620)
at com.google.firebase.messaging.FirebaseMessaging.lambda$getToken$4(FirebaseMessaging.java:387)
at com.google.firebase.messaging.FirebaseMessaging$$InternalSyntheticLambda$0$2fd74daaa9547626a2178c157d189c0e094dccccb61fc5ee6d886ccc44d7a00a$0.run$bridge(FirebaseMessaging.java:22)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:462)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at com.google.android.gms.common.util.concurrent.zza.run(com.google.android.gms:play-services-basement@@18.0.0:2)
at java.lang.Thread.run(Thread.java:919)
We know the Devices crashing contains Google Play Services, as we have them in house for testing as well. What other reasons could throw SERVICE_NOT_AVAILABLE?
Relevant Code:
We use a particular setup. Apart from our default Firebase Project, we have a 3rd party restriction to connect to a secondary Firebase project to receive push notifications (FCM).
// Initialization Code for the secondary Firebase Project used to receive push notifications.
Firebase.initialize(
context = appContext,
FirebaseOptions.Builder()
.setApiKey(apiKey)
.setProjectId(projectId)
.setApplicationId(applicationId)
.setGcmSenderId(senderId)
.build(),
INSTANCE_KEY
)
val firebaseApp = FirebaseApp.getInstance(INSTANCE_KEY)
val firebaseMessaging = firebaseApp.get(FirebaseMessaging::class.java) as FirebaseMessaging
Preconditions.checkNotNull(firebaseMessaging, "Firebase Messaging component is not present")
// The code trying to obtain the token
firebaseMessaging.token.addOnCompleteListener { task ->
if (!task.isSuccessful) {
continuation.resume(Result.failure())
} else {
continuation.resume(Result.success())
}
}
Any help is more than welcome.
Issue Analytics
- State:
- Created a year ago
- Comments:8 (5 by maintainers)
Top GitHub Comments
Thanks @argzdev, Im fine with feature request label and happy to answer any questions from the engineers when looking into this.
The use case comes from a Third Party restriction. We had Firebase already setup in our android app for a long time ago, and our server was sending us push notifications successfully via FCM (project 1). However we recently had to include a 3rd party library (customer care library with push notifications feature) which account was linked already to another FCM account (project 2) and couldn’t be changed.
That’s why we had to add a secondary FCM project setup only to receive push notifications inside that third party library.
That does sound like a reasonable use case. Thank you for sharing, @claucookie!