As a change in Android 13, Notification Runtime Permissions was introduced.
Let`s take a closer look at how it affects app behavior.
1. Notification runtime volume of Android 13
Up to Android 12, you could display Notifications by default when you install the app. Users had to disable Notifications in the App Info screen to prevent apps from sending Notifications.
In Android 13, the Notification runtime permission was added, and this permission has now been changed to control the app`s ability to send Notifications. Also, since Runtime permission is OFF by default, the app cannot send notifications to the user until it receives this permission.
2. Declare permission and request permission (Target SDK API 33 or higher)
Apps with Target API 33 or higher can declare POST_NOTIFICATIONS permission in AndroidManifest as follows:
<manifest ...>
<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
<application ...>
...
</application>
</manifest>
When your app requests the POST_NOTIFICATIONS permission from the user, you can implement it like this: It is the same as the basic Runtime permission request method.
requestPermissions(arrayOf(Manifest.permission.POST_NOTIFICATIONS), REQUEST_CODE)
For how to request runtime permission from the user, refer to Android developer`s App permission request.
3. Declare permission and request permission (Target SDK API 32 or lower)
Since the POST_NOTIFICATIONS permission was added in Android 13 (API 33), apps compiled with Android 12L (API 32) or lower do not have the permission added. That`s why the system automatically adds permissions to the app and pops up a permission request popup.
When an app with Target API 32 or lower is installed on an Android 13 device, the POST_NOTIFICATIONS permission is automatically declared to be used by the app by default.
Permissions are automatically declared, but permissions are not automatically granted. To be granted permission, you need to get permission from the user through the permission request popup.
As with the permission declaration, API 32 and lower apps have no code to request permission for POST_NOTIFICATIONS. Therefore, the system automatically opens a permission popup in the following cases so that the user can grant permission.
- When the App is launched in the Launcher with Notification Channel registered, a permission request pop-up is issued.
- After the App is launched in the Launcher, a permission request pop-up is issued when registering the Notification Channel.
In other words, for apps under API 32, the permission request popup is automatically generated when Notification Channel is created with the code below or when the app is executed after Notification is created.
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
val btn : TextView = findViewById(R.id.myBtn)
btn.setOnClickListener {
createNotificationChannel(this)
}
}
private fun createNotificationChannel(context: Context) {
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
val name = "my-notification-channel"
val importance = NotificationManager.IMPORTANCE_DEFAULT
val channelId = "${context.packageName}-$name"
val channel = NotificationChannel(channelId, name, importance)
channel.description = "my notification channel description"
val notificationManager = getSystemService(NOTIFICATION_SERVICE) as NotificationManager
notificationManager.createNotificationChannel(channel)
}
}
}
In the example app above, if you press the button, a channel is created, and the system automatically pops up a permission request popup.
For apps under API 32, when the system automatically opens a permission popup, if the user presses the
Don
t allow` button once, the popup does not occur even if the app is restarted.
In the case of API 33 or higher apps, when the app opens the permission popup, the permission popup can continue to pop up until the user presses the
Don
t allow` button twice. (It follows the default Runtime permission policy)
You can get the sample app from GitHub - create notification channel.
4. Impact on app updates
Assume that you have Target API 32 or lower app installed on Android 12, and your device has been upgraded to Android 13.
Upgrading to Android 13 with Notification disabled in App Settings
The POST_NOTIFICATIONS
permission is off by default when upgrading to Android 13, because the user changed the setting to not use Notifications in Android 12.
Upgrading to Android 13 with Notification enabled in App Settings
Since the Notification setting in Android 12 is enabled, the POST_NOTIFICATIONS
permission is on by default when upgrading to Android 13. Therefore, the Notification can be raised without additional permission requests.
5. Summary
When installing the app, some users felt tired because of the behavior of launching Notification without user consent. I think the introduction of Notification permission in Android 13 reflects this user experience.
Until now, the app was able to display Notificaiton by default, and if users who were uncomfortable with this had changed it to off in the settings, now it is not possible to launch Notificaiton by default, and the UX has been changed so that the app you want to launch takes the user`s permission.
In terms of app behavior,
- For apps compiled with API 32 or lower, the platform automatically adds permissions and pops up a request popup on Android 13. However, since the degree of freedom is reduced, it would be better to change to API 33 as much as possible so that the app pops up the permission popup at the desired timing.
- Apps with API 33 or higher can display a permission popup by themselves, and if the user denies permission more than twice, you can guide them to set it directly in the settings
- When the device is upgraded from Android 12 to 13, change the permission of POST_NOTIFICATIONS to allow or deny by default according to Android 12`s Notification setting
Related Posts
- How to download and build Android 13, AOSP
- Notification permission request, pop up notification in Android 13
- Resolve `Access blocked: ComponentInfo` error on Android 13
- Fix error "android gradle plugin requires java 11 to run. you are currently using java 1.8."
- Android - Vibration, Vibrator, VibrationEffect example
- How to get phone number in Android
- How to create Bugreports and Logcat with ADB in Android
- Clear application user data with ADB in Android
- How to disable/enable apps with ADB in Android
- How to find PID of a package with adb in Android
- How to grant/revoke permissions with adb in Android
- How to install an apk(app) with adb in Android
- How to kill a process/package from ADB in Android
- How to transfer files using adb push/pull command in Android
- How to capture the screen from adb in Android
- How to uninstall/install system apps from adb in Android
- How to change Settings values from adb in Android
- How to Factory reset with ADB in Android
- How to get logcat from ADB command in Android
- How to capture Heap Dump from app with ADB in Android
- How to force stop an app with adb in Android
- How to start/stop a service from adb in Android
- How to send/broadcast an intent from adb command in Android
- How to start an activity from adb in Android
- How to generate input from adb in Android
- How to check SQLite DB table in Android Studio
- How to get memory info and thread list from adb in Android
- Android - Uri, Scheme and SSP(Scheme Specific Part)
- How to parse a xml file with XmlResourceParser in Android
- Android - Signing an apk with Platfom key
- How to fix "Cleartext HTTP ... not permitted" for Android development
- How to fix "kvm permission denied" for Android Emulator
- Using ADB over Wifi for Android development