[Bug]: OneSignal.Notifications.requestPermission(true) on Android never resolves

[SamYu]

What happened?

When calling OneSignal.Notifications.requestPermission(true); on Android, the promise is never resolved and no Android system notification prompt is shown. This makes it so users are unable to get notifications on Android without permission.

const permission = await OneSignal.Notifications.getPermissionAsync();

if (!permission) {
  const result = await OneSignal.Notifications.requestPermission(true);

  console.log("notification permission result", result); // This is never logged

  if (result) {
    await OneSignal.User.pushSubscription.optIn();
    await updateNotificationPermissions({
      variables: {
        input: {
          push: true,
          email: null,
        },
      },
    });
  }

Steps to reproduce?

1. Install `react-native-onesignal` on Expo
2. Call await OneSignal.Notifications.requestPermission(true);
3. Check if code executes after

What did you expect to happen?

It should open the Android system notification permission prompt.

React Native OneSignal SDK version

5.2.13

Which platform(s) are affected?

• iOS
• Android

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[fkiDev]

same here

[PhillipFraThailand]

Hi, i recently fixed an issue similar to this, where the permission request never resolved on Pixel phones on Android 16 when the user had denied permissions via single and multiple permission requests. I fixed it by checking if the request never resolved and then let the flow continue without the permission.

[nan-li]

Hi all, thanks for reporting. We are working on changes in the Android SDK that will eventually fix this issue but there is no ETA on when that will be readily available. In the meantime, the suggestion from @PhillipFraThailand can hopefully be a workaround for you.

[giantslogik]

just noting that OneSignal.Notifications.requestPermission(false) never resolves as well.

[mlisikbf]

@nan-li do I understand correctly that this is a known issue that you have a grasp on internally? if so, is there an ETA now that some time has passed? the volume we're seeing is low, but it does create a pretty broken experience for the user, so we're weighing a workaround vs waiting for a fix