Declare and request in context
For the applicable platform path, declare:
<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
Use the current notification-permission guidance for behavior by Android and target-SDK version. Explain the kind of notification the user is enabling rather than asking before the app has demonstrated its purpose.
A notification permission is not required on every older Android version, so guard version-specific requests appropriately.
Diagnose three independent layers
| Layer | Check |
|---|---|
| App-level access | Is notification permission currently granted where required? |
| Channel | Does the channel exist, and has the user disabled or changed it? |
| Delivery code | Was the notification actually posted with the correct channel and content? |
A successful push-message receipt does not prove a visible notification was posted. Conversely, a foreground data message may be intentionally handled without showing one.
Respect denial and settings changes
Keep the app usable when notifications are optional and declined. Provide a clear settings entry for users who later change their mind, but do not open settings repeatedly without an action from the user.
The runtime-permission model requires checking current access rather than trusting a past grant. Test returning to the app after access is revoked.
Test install and upgrade paths
Fresh installations, app upgrades and device upgrades can have different initial states. Test each relevant path on controlled devices. Include blocked channels, denied permission and a notification posted while the app is in the foreground and background.
Do not infer universal behavior from a development phone that already granted access months ago.
Review with APKLint
The Manifest Checker can verify the declaration and highlight related permission concerns. It cannot inspect a user's channel settings or guarantee delivery through a push service. Keep server receipt, client handling and visible presentation as separate diagnostics so the failure is fixed at the correct layer.
Trace an order alert from receipt to presentation
Suppose an order-status message reaches the device but no alert appears. Record receipt of a synthetic message without logging customer information, then inspect the client code path that should construct the notification. Check the intended channel and current app-level notification state. A successful network delivery acknowledgement covers only one part of this chain.
The notification permission reference describes Android 13 and later behavior. Keep target-SDK differences explicit when testing the timing of the permission prompt. A development installation with an existing grant is not a substitute for the fresh-install experience of a new user.
Distinguish a blocked category from a missing application grant
A user can accept notifications generally but disable the marketing channel. That preference should not be treated as a broken permission request, and the app should not repeatedly create replacement channels to evade it. Test a useful transactional category separately from an optional promotional category, using the channel configuration that the release actually ships.
When the user declines the runtime request, preserve access to order history within the app. Explain the consequence at the notification setting rather than blocking unrelated navigation. If the user later deliberately opens notification settings, refresh the displayed state on return. Do not automatically launch settings after every denial or imply that permission is required to use an unrelated feature.
Test dismissal of the permission dialog as well as explicit allowance and denial. Re-evaluate the actual grant before posting instead of interpreting every callback path as a positive result. Include a blocked channel, an enabled channel and an app-level revocation in the same release test plan so diagnostic messages identify the right layer.
A foreground service still has its own notification obligations even when the application lacks the notification runtime grant. The platform documentation explains that the grant is not itself required to launch a foreground service; other service-start requirements remain. Avoid using this distinction to promise that every service notification will appear in the same place under every permission state.
Finish with a fresh install and an update from a supported previous version on controlled devices. Confirm visible presentation and the notification's tap destination using synthetic data. Keep message receipt, notification posting and user-visible behavior as separate observations so a silent delivery failure cannot be mislabeled as a permission defect.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
