Android notification permission: request POST_NOTIFICATIONS in context

A notification prompt shown before a person understands the feature often feels like an interruption. On Android 13 and later, that moment also controls whether a newly installed app can send most notifications at all. The implementation decision is therefore both technical and product-facing: declare the permission, choose when to ask, and decide what the app does after each possible answer.

Google’s guidance gives apps targeting Android 13 or higher control over when the system dialog appears. Use that control to connect the request to an action the person has just taken, such as enabling an alert or asking to follow an update. The app should still work when permission is denied or left undecided.

Know which Android behavior you are shippingCopy Anchor Link

Android 13 (API level 33) introduced the runtime POST_NOTIFICATIONS permission for non-exempt notifications. Apps targeting API 33 or later can choose when to request it. If an app targets Android 12L (API level 32) or lower, Android controls the first prompt: it appears when the app starts an activity after creating its first notification channel, or when it creates that channel while an activity is running. That often means the prompt appears during startup.

The distinction matters in a cross-platform project. A target SDK setting can change when a person sees the request even when the visible app flow did not change. Check the target SDK of the actual Android release build, not just the value in a development configuration. If you maintain multiple application IDs, product flavors, or release tracks, identify which variant the store build uses.

On Android 13 and later, notifications for a newly installed app are off by default until the app requests permission and the person grants it. A denied request blocks notifications except for specific exemptions. A swipe-away leaves the permission state unchanged; it is not the same as an explicit denial. Keep these outcomes separate in the app’s state handling and in tests.

Existing installations can behave differently after a device upgrade. Android may pre-grant the permission to an eligible app when the device upgrades, provided the app already has a notification channel and the person had not explicitly disabled its notifications on Android 12L or earlier. A prior user-disabled state persists across the upgrade. Do not assume that every returning user will see the same prompt as someone installing the app fresh.

Declare the permission and gate notification workCopy Anchor Link

For an app targeting Android 13 or later, declare android.permission.POST_NOTIFICATIONS in the Android manifest and request it through the runtime permission flow. A manifest declaration alone does not grant permission. Before sending a notification, check whether notifications are enabled and handle the result in the experience that depends on them.

In a native Compose screen, Android’s guide shows rememberLauncherForActivityResult() with ActivityResultContracts.RequestPermission(). A React Native or other cross-platform app may use its framework’s permission API, but it still needs to follow Android’s platform behavior and report the permission result back to the feature. Verify the library and app code you actually ship; do not assume a wrapper automatically makes the permission request happen at the right time.

Also distinguish notification permission from foreground-service startup. Android does not require POST_NOTIFICATIONS to launch a foreground service, but the service still has to include its required notification. If permission is denied, the foreground-service notice may appear in Task Manager rather than the notification drawer. A denied notification prompt is not a reason to skip the service’s own requirements.

Ask when the person sees the valueCopy Anchor Link

Google recommends waiting until a user understands the app and prompting in context. Examples include someone tapping an alert bell, choosing to follow an account, or submitting a delivery order. These actions make the reason for the request concrete. A short explanation screen can help when the app needs to explain the benefit; Android’s guidance says it is needed when shouldShowRequestPermissionRationale() returns true, and otherwise may be omitted.

A practical sequence looks like this:

1. Let the person reach the feature without requiring notifications.
2. When they turn on an alert or follow an update, explain what will be sent and when.
3. Launch the system permission dialog from that action.
4. If granted, confirm that alerts are enabled for the feature.
5. If denied or unchanged, keep the feature usable and provide an in-app route to notification settings where appropriate.

Avoid requesting permission immediately after install solely because the app can. A person who has not encountered the feature has little context for the choice. Do not put a pre-permission screen in front of every user by default either; use one when the explanation answers a real question the person is likely to have.

The request should describe the app’s actual notification behavior. If the feature offers several categories, make those choices understandable and avoid implying that enabling one alert turns on unrelated notifications. Android notes that users can revoke permission later and can see the number of notifications the app sends. Treat the grant as permission to deliver the feature the person asked for, not a blank check for every future message.

Handle all three dialog outcomesCopy Anchor Link

A complete flow accounts for allow, deny, and swipe-away. After allow, enable the requested notification capability and make sure the relevant channels are configured. After denial, continue the rest of the app and explain which feature will not send notifications. If the person swipes the dialog away, retain the undecided state rather than recording a denial or repeatedly prompting on the next screen.

On Android 13 and later, the system permission behavior has a detail that can surprise returning users: if an app targets API 32 or lower and a person taps “Don’t allow,” the system does not prompt again until the app is uninstalled and reinstalled or the app updates its target to Android 13 or higher. For apps targeting Android 13 or later, the app owns the timing of subsequent requests. Build your state machine around the actual platform result and target SDK, rather than assuming every denial can immediately be followed by another system dialog.

Before attempting to send, call the platform’s notification-enabled check. If permission is missing, do not loop a system prompt. Offer a clear settings path only when the person tries to use the affected feature or asks to change the choice. The app should state what is unavailable and preserve other functionality.

Test install, upgrade, and denial pathsCopy Anchor Link

A single “Allow” test does not cover the release behavior. Android’s documentation provides ADB commands to simulate first install, a device upgrade with notifications enabled, and a device upgrade after the person disabled notifications. Run those sequences on an Android 13-or-later test device or emulator, and verify both system state and the app’s own UI.

At minimum, exercise these cases:

• Fresh install on Android 13 or later: notifications start disabled and the app requests permission only at the intended point.
• Allow: the feature confirms the opt-in and can send through the intended channel.
• Deny: the rest of the app remains usable and the affected feature explains its limit.
• Swipe away: no false grant or denial is stored, and the app does not nag on every launch.
• Upgrade with an existing channel and notifications enabled: confirm the expected pre-grant behavior.
• Upgrade after notifications were explicitly disabled: confirm that the previous choice is respected.
• Target SDK 32 or lower versus 33 or higher: confirm who controls the dialog timing.
• Foreground service with permission denied: confirm the service still follows its notification requirements and that the notice appears in the expected system surface.

Record the target SDK, install or upgrade path, permission result, and channel state for each test. This makes regressions easier to diagnose when a release changes target level, notification-library version, or onboarding flow. The product team can then review a precise behavior rather than a vague “notifications stopped working” report.

Keep a release checklistCopy Anchor Link

Before shipping, verify that the release manifest declares POST_NOTIFICATIONS when the target requires it, the app checks notification availability before sending, and each request is tied to a user-understood feature. Confirm that denial and swipe-away are represented separately, that existing-user upgrade paths are tested, and that foreground services still show their required notification behavior.

The goal is not to maximize prompt acceptance. It is to ask at a moment when the benefit is clear, honor the answer, and make the feature’s behavior predictable. For a broader release checklist, pair this permission review with the separate Android advertising ID permission guide; notification access and advertising identifiers are different Android checks.

SourcesCopy Anchor Link

• Notification runtime permission — Android Developers