Separate platform access from Play eligibility
For apps targeting Android 14 or higher, the platform guidance describes stricter treatment of full-screen intents and an access-checking API. Google Play's permission policy adds eligibility and declaration requirements.
Do not assume that adding the permission to the manifest gives every installed app default access. Installation history, user settings and distribution rules can affect the state.
Check the capability before using it
On supported versions, use NotificationManager.canUseFullScreenIntent() to determine whether the app currently has access. The platform provides ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT for the relevant settings flow.
Guard version-specific calls and recheck after returning from settings. A user pressing Back is a normal outcome, not an error that should trigger an endless settings loop.
Build a usable fallback
| State | Expected behavior |
|---|---|
| Access available and event eligible | Use the documented notification flow |
| Access unavailable | Deliver an appropriate notification without assuming full-screen launch |
| User declines settings change | Preserve the choice and explain only the affected feature |
| Feature no longer needs it | Remove the request and associated declaration |
Notification channel settings and notification permission are separate concerns. Full-screen access does not automatically enable a blocked channel or guarantee that every device presents the same UI.
Test the event lifecycle
Test a locked device, an unlocked device, an existing call or alarm, cancellation and repeated events. Verify that dismissing or answering the event clears the corresponding notification state. Use real feature scenarios, not just a button that launches a test activity.
Audit the final manifest
APKLint can flag the declaration and help identify whether it arrived from your code or an SDK. It cannot decide whether your app qualifies for a Play policy exception or guarantee that a full-screen presentation will occur. Keep the feature rationale and current policy evidence with the release review.
Associate presentation with a live incoming event
Consider an incoming-call feature. A notification can be delivered after the caller has already canceled, so the activity must validate the event's current state before presenting answer controls. Keep the call identifier in the event data and reconcile it against the application's authoritative state. Permission to use a full-screen intent does not make a stale event current.
The Android 14 behavior guidance explains the restricted use and capability check. Treat the device's actual access state as an input to notification presentation, and keep the app's eligibility review distinct from that runtime check. Do not use urgent full-screen presentation for ordinary promotional messages.
Test the same event with and without access
On a controlled device, trigger a synthetic incoming event with access enabled, then repeat with access unavailable. Confirm that the fallback provides the supported notification experience without assuming the activity will launch automatically. The user should still be able to understand and act on an eligible current event through the available interface.
Repeat with the device locked and unlocked, with the relevant channel disabled and with applicable notification permission denied. These conditions affect different parts of the presentation path. Avoid a single success Boolean that merges event receipt, notification posting and visible activity launch into one result.
Cancel the event while the notification is visible and verify that its actions no longer accept the old call. Then send a second event with a new identifier. The second event must not reuse the first one's extras, dismissal state or pending action in a way that answers or dismisses the wrong request.
If the app offers the system settings flow, launch it only after a clear user action and recheck capability on return. Returning without a grant is a supported outcome. Keep the fallback available and avoid repeatedly redirecting the user to settings merely because the app prefers a more intrusive presentation.
Finally, test dismissal, answering and timeout through the feature's real state transitions. Clean up the corresponding notification and any associated work when the event ends. Retain the event identifier and non-sensitive lifecycle observations in diagnostics, so a presentation failure can be distinguished from a canceled or expired call without recording private call contents.
Sources and further reading
- Android Developers: Manifest.permission reference
- Google Play: Permissions and APIs that access sensitive information
- Android 14 target-specific behavior changes
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
