[fix] Android: Resolve requestPermission call when already granted

[nan-li]

Description

One Line Summary

Resolve requestPermission call if permission is already granted.

Details

Problem:
If permission is already enabled, the native call to OneSignal.getNotifications().requestPermission(fallbackToSettings, Continue.with(...) never suspends and the Continuation code block never runs. As a result, we would not be able to resolve the promise over the bridge.

Solution:
Before calling that method, do a permission check and return true.
I chose to check the permission in Android bridge instead of resolving early in Dart because the Dart-level _permission boolean may not be set yet when requestPermission is called soon after initialization. I ran into this case when testing the following scenario:

Test scenario

// Notification permission has already been granted

OneSignal.initialize("YOUR_APP_ID");
print('BEFORE calling requestPermission');
bool perm = await OneSignal.Notifications.requestPermission(true);

// The following did not print prior to this PR
print('AFTER calling requestPermission with answer: $perm');

Motivation

Resolve calls to request permission correctly so app code doesn't hang.
A customer reached out to support.

Scope

Now, we also resolve correctly when permission has already been granted.

Testing

Unit testing

None

Manual testing

Android emulator API 33

• Tested the boolean returned when permission is accepted and denied and it returns true and false respectively.
• Tested combinations of toggling permissions in app settings and calls to requestPermission.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is 

[shepherd-l]

I rebased my branch to make the commit history neater. You might need to rebase this PR too

I think this bug applies to all wrappers. If so, do you think this logic should be replicated in each wrapper or could we have logic in the native Android SDK?

[nan-li]

I think this bug applies to all wrappers. If so, do you think this logic should be replicated in each wrapper or could we have logic in the native Android SDK?

Yes that would be ideal, I haven't found a way to workaround this yet. The problem arises from this method being implemented in Kotlin using coroutines. If you are using Kotlin, it just works and returns the boolean directly and correctly. If you are using Java to call the method, you must use a Continuation block. Users of the native SDK likely won't run into their app hanging because they are unlikely to put additional logic in the block. Users of our wrappers are likely to use async await with this method which will cause their app to hang.

For example:

// kotlin
var permission = OneSignal.Notifications.requestPermission(true);

// java
OneSignal.getNotifications().requestPermission(true, Continue.with(r -> {
        // code to execute using the response, unlikely app developers have blocking code within here
}));

[shepherd-l]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @emawby, @jennantilla, and @jinliu9508)

[shepherd-l]

Do you know if this also applies to Location.requestPermission?

[nan-li]

Do you know if this also applies to Location.requestPermission?

It doesn't apply to Location.requestPermission currently because we do not give back the users's selection to this prompt.

[GeceGibi]

Why is waiting for ?

[ramithks]

Big thanks to @nan-li and the OneSignal Team for the rapid response and fixing the issue in Release 5.1.0 :)