Android 13 issues

[shiniwat]

Description

I am using Best Practices template at this moment, as I am still investigating some specific code defect when running on Android 13. Hope this helps discussing potential issues when running on Android 13.

Android 13 introduces some behavior changes that will likely affect to SDL apps.

1. Notification permission
   As you see at https://developer.android.com/about/versions/13/changes/notification-permission, Android 13 introduces the new runtime permission: POST_NOTIFICATION permission. Because SDL apps depends on Foreground service, which also depends on Notification channel, SDL’s foreground service requires POST_NOTIFICATION runtime permission in order for posting foreground service notification.
   As the note section at the doc above mentions, however, apps don’t need POST_NOTIFICATION permission in order to launch a foreground service. Therefore, if user disallowed the notification permission on a SDL app, the SDL service still works, while it can’t show any notification to the user.
   We should clarify if all SDL apps requires POST_NOTIFICATION runtime permission or not, and update the doc and/or library itself accordingly.

2. Foreground services Task Manager (FGS Task Manager)
   As you see at https://developer.android.com/about/versions/13/changes/fgs-manager, Android 13 introduces Foreground Services Task Manager (FGS Task Manager), which list apps that are currently run a foreground service. Because SDL apps depend on Foreground service, basically all SDL apps will be listed on the FGS task manager, and explicitly killed by user.
   Because it is user’s action, we cannot prevent users from stopping SDL app via FGS task manager. However, we still have to verify the following points:

• SDL app library behaves as expected even if user stopped the SDL app especially if the app runs SdlRouterService that is currently connected with head unit.
• All SDL apps make sure it tests with the following command:
  adb shell cmd activity stop-app PACKAGE_NAME

There might be other behavior changes that potentially affect to SDL apps, but above two obviously affect to existing SDL apps, and worth discussing further.

[shiniwat]

I have tested our SDL apps in two separate modes: 1) the app built with targetSdkVersion = 31, 2) the app built with targetSdkVersion = 33.
The followings are key findings when running on Android 13 beta 4 (TPB4.220624.005).

• The app built with targetSdkVersion = 31 works almost in the same way when running on Android 13. The biggest difference is notification runtime permission is automatically requested at the first launch. If user denied the permission, the permission dialog will never appear, but user can still allow the permission thru app settings.
• FGS Task manager shows the app that calls NotificationManager#createNotificationChannel (or other notificationChannel APIs). Even if the app starts ForegroundService, but never create notificationChannel, the app won't be shown by FGS task manager. This behavior is applied on both API level 31 and API level 33 apps.
• The app built with targetSdkVersion = 33 should add <uses-permission android:name="android.permission.POST_NOTIFICATION"/> in AndroidManifest, and should manually request notification runtime permission. Otherwise, user can never turn on the notification for the app, as the switch in app settings is disabled.
• Regardless of the API level (i.e. both 31 and 33), even if the notification permission is disallowed by user, the foreground service itself works normally.
• If user stops the app by FGS task manager, the entire application is stopped and removed from memory. This behavior is clearly mentioned at https://developer.android.com/about/versions/13/changes/fgs-manager. If the user explicitly starts the app, the (SDL) app starts normally again.

These are what I found on Android 13 beta4. Overall, API level 31 app has no specific dev task to support Android 13. API level 33 app has minimal task (i.e. change targetSdkVersion, and add POST_NOTIFICATION permission), but dev impact would be minimal.

[joeygrover]

Addressed with #1826