HomeUser GuideDeveloper GuideChangelog
Changelog
Back to All

Android 13 Notification Opt-in

almost 2 years ago by Nikola Zagorchev

Google announced that Apps targeting Android 13 and upward, will now need to request permission to post notifications

Background

Google announced that Apps targeting Android 13 and upward, will now need to request permission to post notifications. Users need to allow opt-in for notifications. This is done through a system prompt with the options to Allow, Don’t allow, or Ignore it by tapping outside. The user can be asked for permission a limited number of times, after which they can control this from Settings.
More can be found in the Official documentation.

Leanplum Android SDK 7.1.0 supports Push Pre-permission (Push Ask to Ask) and Register For Push message templates to help notification opt-ins.

Table of Contents

User Experience

Users now need to choose to receive notifications. This will enhance the overall user experience since users will not receive notifications without the user’s explicit consent. By getting users to opt-in, you can better determine what content they would like to receive and engage with them more effectively.

Allow

Notifications are allowed and all channels are enabled.

Don't Allow

Notifications and all channels are disabled. User cannot see notifications from the app. This is similar to turning off the notifications from Settings.

Ignore

The notification state remains unchanged.

Push Opt-in Flows

The behavior of the opt-in depends on whether the app targets Android 13 (API level 33) or an earlier version, what is the device's Android version and whether the app was already installed or not.

New installation

  • If the app is targeting Android 13 and running on Android 13 device, Notifications are not enabled and the user needs to opt-in to receive notifications.
  • If the app is targeting Android 12 or older and running on Android 13 device, Notifications are not enabled by default. Request Permission flow is handled by the system and will not be shown unless a Notification channel is registered.
  • If the app is targeting Android 13 and running on Android 12 or older device, Notifications are enabled by default.
  • If the app is targeting Android 12 or older and running on Android 12 or older device, Notifications are enabled by default.

📘

Leanplum automatically creates notification channels on Leanplum start and when a push notification is received. If your app does not target Android 13, this will cause the push permission prompt to be shown on Android 13 devices.

Existing apps

Existing applications that have notifications enabled, will be automatically granted permission.

Best practices on requesting permission

Google describes the Best practices on when and how to request permission here.

You may want to give the user some time to get familiar with your app before asking them to opt-in for notifications. It is recommended to be clear why your app needs to send notifications to the user.

Push Permission

In order for the SDK to request POST_NOTIFICATIONS permission, Leanplum's Push module specifies it in its manifest. This permission is required to display notifications in Android 13:

<uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>

Push Primer (Pre-Permission)

Android provides an opportunity to show a Push Primer in-app message giving insights on why users will benefit from enabling notifications. The system controls this through the shouldShowRequestPermissionRationale() flag by setting it to true.

Leanplum takes care of all this under the hood and offers you a ready-to-use solution. The Push Pre-Permission (Push Ask to Ask) in-app message is now supported on Android.
You can use the same campaigns for both iOS and Android now if desired.

900

The Push Pre-Permission checks if notifications are enabled or not. If they are already enabled, the message will not be shown - no View event will be tracked.
Otherwise, it behaves the following way:

  • if shouldShowRequestPermissionRationale equals true - presents the Push Pre-Permission. Tracks View event.
  • If notifications have not been enabled and permission is not granted, but shouldShowRequestPermissionRationale equals false - the native push prompt is triggered. Tracks View event.

When Push Pre-Permission is presented:

  • if Accepted - shows the native prompt. Accept event is tracked.
  • if Cancelled - the message is dismissed. Cancel event is tracked.

By default, the Push Pre-Permission message will be presented every time the display trigger occurs. You can control the frequency from the Campaign Composer to show the message a limited number of times during a desired time frame (once a week, once per month, every 5 times the trigger is done, etc.).

Register For Push

The Action checks if notifications are enabled and if permission is granted.
If not, it triggers the native push prompt and tracks the View event.

Example flows

Observe the following use cases if you are running a campaign with the Push Pre-Permission on User starts app.

Enable notifications on the first attempt

  • On app start, the native prompt is shown and the user clicks "Allow".
  • On each subsequent start of the app, nothing will be shown and notifications are on.

Enable notifications on the second attempt

  • On app start, the native prompt is shown and the user clicks "Don't Allow".
  • On the second start, the Pre-Permission dialog is shown, the user clicks "OK" and on the native prompt user clicks "Allow".
  • On subsequent starts, the dialog will not be shown and app notifications are on.

Choosing Maybe Later

  • The Pre-Permission message will be shown on each app start if the user clicks "Maybe Later".
  • You need to decide on the frequency (once a week, once per month, every 5 times the trigger is done, etc.)

Disable notifications

  • On app start, the native prompt is shown and the user clicks "Don't Allow".
  • On the second start, the Pre-Permission dialog is shown, the user clicks "OK" but on the native prompt clicks "Don't Allow".
  • On each subsequent start of the app, nothing will be shown and notifications will remain off.

If the user has their notifications turned on, but later decides to disable notifications manually, then on the next start of the app, they will view the Pre-Permission message again, because the shouldShowRequestPermissionRationale would be true.

Push Permission result

The push permission request requires an activity. The developer can register for the activity result and get the result of the permission request - granted or not.
The Leanplum push permission request code is available in the PushPermissionUtil - pushPermissionRequestCode.

Push Tokens

The Push notification token will still be generated with notification permissions set to false. The token is generated by the Push Service - FCM, HMS, MiPush.

Push Delivered Tracking

Tracking of Push Delivered event will not be affected, as it is related to the data message, and not the notification itself.