Request POST_NOTIFICATIONS permission on Wear OS

[roberi]

Starting in Wear OS 4 (Android 13, API level 33), ongoing notifications are affected by the notification runtime permission. In the Wear app, there is currently no functionality to request this permission. If this permission is required and not granted, the ListenerService.showNotification() method exits.

// check if we have permission to post notification
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU
    && checkSelfPermission(android.Manifest.permission.POST_NOTIFICATIONS)
        != android.content.pm.PackageManager.PERMISSION_GRANTED) {
  return;
}

This PR introduces both a generic way to handle runtime permission in the Wearapp and specifically addresses the POST_NOTIFICATIONS permission requirement for Android 13 (API 33) and higher.

Key Changes include:

• A new reusable component RequestPermissionActivity to manage requests for any Android runtime permission (for now only the POST_NOTIFICATIONS permission, but later also BODY_SENSORS for heart rate monitoring).
• If needed, this activity displays a rationale to the user before the system permission dialog appears.
• It reports the outcome of the permission request back to the calling component (if they are interested).
• If the POST_NOTIFICATIONS permission is not already granted, the MainActivity (in the wear module) utilizes the new RequestPermissionActivity to prompt the user.

https://github.com/user-attachments/assets/453b5090-55f7-4894-a9c6-429c0a5c21e4

[gerhardol]

If the permission is denied, the guidlines at least for phone states that you should not ask again.

The phone app is a little annoying here. I implemented that the app is not starting GPS unless all the time is ticked, to avoid error reports from users where the phone shut down GPS access after an hour or so. But that should maybe have been a snackbar or something in the GUI and maybe a default note.

[roberi]

If the permission is denied, the guidlines at least for phone states that you should not ask again.

Ok, I see. I tried to follow the Workflow for requesting permissions on Android Developers, but I must have misunderstood something. Rereading them, I think the "error" is in my ActivityResultCallback. In their example, if the permission is not granted, they only "explain" to the user that the feature is unavailable because of the denial:

if (isGranted) {
  // Permission is granted. Continue the action or workflow in your
  // app.
} else {
  // Explain to the user that the feature is unavailable because the
  // feature requires a permission that the user has denied. At the
  // same time, respect the user's decision. Don't link to system
  // settings in an effort to convince the user to change their
  // decision.
}

In my code, I show the rational UI if not granted, which has the "explanation" and an OK button that requests the permission again:

if (isGranted) {
  sendPermissionResultAndFinish(true);
} else {
  if (shouldShowRequestPermissionRationale(permissionToRequest)) {
    rationaleUIRoot.setVisibility(View.VISIBLE);
  } else {
    sendPermissionResultAndFinish(false);
  }
}

Perhaps we should just send false instead:

if (isGranted) {
  sendPermissionResultAndFinish(true);
} else {
  sendPermissionResultAndFinish(false);
}

// or simply
// sendPermissionResultAndFinish(isGranted);

Then, the next time the user starts the app, the rational UI will be shown to "explain" why the permission is needed. If still denied, there will be no more "explaining".

[gerhardol]

Perhaps we should just send false instead:

Seem reasonable, no deep thoughts

There are reasons permissions for GPS and battery savings are annoying (if they are sufficient I am not the one to answer...), the notifications should not be.

[roberi]

I think this change better aligns the permission request workflow with the Android guidelines.

https://github.com/user-attachments/assets/71f0ea84-597d-4899-b95b-fa7d7f027995

The "explanations" can still be improved if needed.