[Bug]: 5.1.38 - Most Android users cannot subscribe to push notifications with "Never Subscribed" or "Permission Not Granted" status
What happened?
Most users are shown as "Never Subscribed" on the Audience page, while their individual subscription pages display "Status details: Permission Not Granted". This happens even though the notification permission prompt is shown and accepted. Some users do obtain "Subscribed" status, but I do not see any clear pattern: they use different Android versions, devices, etc. This looks similar to #2106.
Steps to reproduce?
* Create a new Android app and integrate the OneSignal Android SDK
* Initialize OneSignal in the main Activity using the standard setup from the documentation
* Install the app and launch it, allow push notifications in popup (if needed)
What did you expect to happen?
Test device must appear in the OneSignal dashboard as "Subscribed"
OneSignal Android SDK version
5.1.37, 5.1.38
Android version
11
Specific Android models
In production, I see that all devices and Android versions are affected. Some examples:
* OnePlus BE2029 (Android 11)
* Redmi Note 10 2022 (Android 13)
* Samsung Galaxy Z Flip5 (Android 16)
Relevant log output
[OpRepo] processQueueForever:ops: [
bucket:0, retries:0, operation:{"name":"create-subscription","appId":"83..52","onesignalId":"d4..80","subscriptionId":"4b..ff","type":"PUSH","enabled":false,"address":"","status":"NO_PERMISSION","id":"5c..d8"},
bucket:1, retries:0, operation:{"name":"update-subscription","appId":"83..52","onesignalId":"d4..80","subscriptionId":"4b..ff","type":"PUSH","enabled":false,"address":"dZ...ZA","status":"NO_PERMISSION","id":"c3..01"},
bucket:1, retries:0, operation:{"name":"update-subscription","appId":"83..52","onesignalId":"d4..80","subscriptionId":"4b..ff","type":"PUSH","enabled":true,"address":"dZ...ZA","status":"SUBSCRIBED","id":"76..67"}
]
[OpRepo] SubscriptionOperationExecutor(operations: [{"name":"create-subscription","appId":"83..52","onesignalId":"d4..80","subscriptionId":"4b..ff","type":"PUSH","enabled":false,"address":"","status":"NO_PERMISSION","id":"5c..d8"}, {"name":"update-subscription","appId":"83..52","onesignalId":"d4...80","subscriptionId":"4b..ff","type":"PUSH","enabled":false,"address":"dZ..ZA","status":"NO_PERMISSION","id":"c3...01"}, {"name":"update-subscription","appId":"83..52","onesignalId":"d4..80","subscriptionId":"4b..ff","type":"PUSH","enabled":true,"address":"dZ..ZA","status":"SUBSCRIBED","id":"76..67"}])
[DefaultDispatcher-worker-3] HttpClient: Request Sent = POST https://api.onesignal.com/apps/83..52/users/by/onesignal_id/d4..80/subscriptions - Body: {"subscription":{"id":"4b..ff","type":"AndroidPush","token":"dZ..ZA","enabled":true,"notification_types":1,"sdk":"050138","device_model":"BE2029","device_os":"11","rooted":true,"net_type":0,"app_version":"1"}} - Headers: Accept=[application/vnd.onesignal.v1+json], Content-Type=[application/json; charset=UTF-8], OneSignal-Install-Id=[38..00], OneSignal-Subscription-Id=[4b..ff], SDK-Version=[onesignal/android/050138]
[DefaultDispatcher-worker-3] HttpClient: Got Response = POST https://api.onesignal.com/apps/83..52/users/by/onesignal_id/d4..80/subscriptions - STATUS: 200 - Body: {}
Code of Conduct
- [x] I agree to follow this project's Code of Conduct
I've managed to identify that the login() call leads to this issue.
My test app looks like this:
OneSignal.Debug.logLevel = com.onesignal.debug.LogLevel.VERBOSE
OneSignal.initWithContext(applicationContext, "83..52")
CoroutineScope(Dispatchers.IO).launch {
OneSignal.Notifications.requestPermission(true)
}
OneSignal.login("external_id") // this line causes "Permission Not Granted" status
If I comment out the OneSignal.login("external_id") line and reinstall the app, the new subscription appears as "Subscribed". I believe, it is the backend issue.
@tddevel correct, but not indicating external id is an issue for many users, since they relied on that user id when sending notifications
@yarodevuci Sure. To be clear: I am not suggesting removing login() as a workaround. I myself have multiple apps in production that call login() and rely on that mapping, and I am not planning to drop it.
What I meant is that it looks like a regression on OneSignal's backend side, because the same code used to work perfectly. I've already reported it to OneSignal support via chat, hopefully someone will look into it soon.
Today I tried two things with interesting outcomes.
- I changed the SDK version to 5.1.36, and it seems to work correctly.
- I tried to manually send my push token to the "Permission Not Granted" install, and the install changed its status to "Subscribed":
curl -X POST --data '{"subscription":{"type":"AndroidPush","token":"d..8","enabled":true,"notification_types":1,"sdk":"050137","device_model":"BE2029","device_os":"11","rooted":true,"net_type":0,"app_version":"2"}}' 'https://api.onesignal.com/apps/9d..99/users/by/onesignal_id/0f..e7/subscriptions'
It seems that the problem is in an order or timing, when the backend receives this information. I wanted to implement a workaround solution to run it on my server and fix subscription status for every user. Unfortunately, I was unable to retrieve subscription token for "Permission Not Granted" users because their token appears to be empty in the API responses.
Hi @tddevel thank you for reporting this, I will investigate. And you are calling the following block of code from your MainApplication's onCreate, correct?
OneSignal.Debug.logLevel = com.onesignal.debug.LogLevel.VERBOSE
OneSignal.initWithContext(applicationContext, "83..52")
CoroutineScope(Dispatchers.IO).launch {
OneSignal.Notifications.requestPermission(true)
}
OneSignal.login("external_id") // this line causes "Permission Not Granted" status
you are calling the following block of code from your MainApplication's onCreate, correct?
Hello, @nan-li! Thank you for joining us!
I am calling this from MainActivity's onCreate(). I know that it is not recommended, but it is not restricted. I need to do some preparatory work before enabling OneSignal — for certain users I don't need OneSignal at all, that's why I do this.
I tested the same code on 5.1.37, 5.1.38, and older versions. The problem is with those two. If you need, I can provide you with the entire Android Studio project to reproduce the problem.