Handling Permissions In Android 13 And Above

Android permissions changed significantly from Android 13 onwards. Applications now request access with greater precision, and users have more control over notifications, photos, nearby devices and location data. A permission strategy that worked on Android 11 may therefore create confusing prompts or rejected access on newer phones.

For Australian developers, this matters across a wide range of devices and network conditions. A customer using a Google Pixel in Sydney, a Samsung Galaxy in Melbourne or an older handset in regional Queensland may see different system screens depending on Android version, manufacturer settings and the app’s target SDK.

The safest approach is to request access at the moment it becomes useful, explain the benefit in plain language and handle denial without breaking the core experience. Permission handling should be treated as part of product design, privacy compliance and quality assurance.

The examples below focus on runtime permissions, modern Android APIs and practical release preparation. Broader Android development references, including Android permission guidance, can help when comparing implementation patterns across platform versions.

What Changed In Android 13

Android 13 introduced the POST_NOTIFICATIONS runtime permission for most newly installed applications targeting API level 33 or higher. An app cannot assume that notifications are enabled, even when alerts are central to its service. The request should appear after the user understands why notifications matter, such as receiving a delivery update or an appointment reminder.

Media access also became more specific. Instead of broadly requesting access to all images and videos, developers should consider the system photo picker when a user needs to choose a small number of files. This reduces unnecessary access and gives people a familiar, controlled selection screen.

Android 13 also separates some Bluetooth-related permissions under the nearby devices group. Applications that scan for accessories, connect to fitness equipment or communicate with smart-home devices may need BLUETOOTH_SCAN, BLUETOOTH_CONNECT or related declarations. These should be requested only when the relevant hardware feature is opened.

Request Access At The Right Moment

A permission prompt is more effective when it follows a clear user action. Ask for camera access when the person taps a scan button, location access when they enable a map-based feature, and microphone access when they start recording. Avoid requesting every permission during the first launch sequence.

The explanation before the system dialogue should be short and factual. State what the app will do, why the capability is needed and whether the feature can be skipped. “Allow location access to show nearby collection points” is more useful than a vague message about improving the experience.

If access is denied, preserve the rest of the application wherever possible. A shopping app can still display products if location is refused, while a transport app can allow manual suburb selection. This approach is especially helpful for users managing limited mobile data or using an older device on a regional network.

Media, Notifications And Nearby Devices

For image selection, Android’s photo picker is generally preferable to requesting broad media-library access. It lets a person choose particular photos without giving the application unrestricted visibility of their gallery. This is appropriate for profile images, rental applications, marketplace listings and customer support attachments.

Notification permission requires a careful fallback. If the user declines, important information should remain available inside the app, through email where appropriate or via another agreed channel. An Australian retail app should not make a time-sensitive order impossible to track solely because push notifications were disabled.

Nearby-device access deserves equally clear treatment. A cycling application pairing with a heart-rate monitor has a strong reason to request Bluetooth access, while an unrelated feature should not trigger the same prompt. Explain whether the app scans, connects or exchanges data, then stop scanning when the feature is no longer active.

Location And Privacy Responsibilities

Location access should reflect the least precise option that supports the feature. A weather widget may work with approximate location, while turn-by-turn navigation needs precise location. Android allows users to adjust this choice, so applications should cope with approximate results rather than treating them as an error.

Background location has a higher privacy threshold and should be requested separately from foreground access. The application must demonstrate a genuine background use case, provide a transparent explanation and follow Google Play policy requirements. Tracking people continuously without an obvious benefit can damage trust and create regulatory risk.

Australian organisations also need to consider the Privacy Act 1988 and the Australian Privacy Principles. The privacy notice should describe what personal information is collected, why it is collected, how it is used and who may receive it. Businesses serving customers in Sydney, Brisbane or Perth should make the same explanation available regardless of the user’s location or device.

Handling Denials And Settings Changes

A denial is a normal user decision, not an application failure. Store only the minimum state needed to avoid repeatedly interrupting the person, then provide a clear route to continue without the restricted feature. If the permission becomes essential later, explain the consequence immediately before requesting it again.

Some users select “don’t ask again”, disable a permission from Android Settings or revoke access after an update. Check permission status whenever the protected feature starts rather than relying only on the result from an earlier session. A settings button can help, but it should open the relevant application settings page only after the user understands what to change.

Permission state can also change when an application is restored to a new handset, when a user clears data or when Android automatically resets unused permissions. Test these transitions deliberately. People replace phones frequently in Australia, and an account migration should not be mistaken for continuous permission approval.

Testing Across Devices And Releases

Permission testing should cover clean installation, upgrade from an older version, denial, temporary denial, permanent denial and permission changes made outside the app. Test both target SDK behaviour and the Android version running on the device. An emulator is useful, but physical testing can reveal manufacturer-specific wording and battery restrictions.

A release checklist can keep reviews consistent:

• Verify every dangerous permission has a clear user-facing purpose.
• Test Android 13, Android 14 and newer supported releases.
• Confirm denied access does not crash or trap the user.
• Check privacy copy against the actual data collected.

Testing should include compact screens, large text, dark mode and poor connectivity. A user in a regional town may wait longer for a permission-related screen or rely on a prepaid plan, so avoid loading a heavy explanation from a remote server before showing the system request.

Review manifest declarations as part of each release. Remove permissions that are no longer used, check libraries for inherited declarations and confirm that Play Console disclosures match the implementation. Useful release checks include:

• Compare manifest permissions with active product features.
• Inspect notification behaviour after a clean install.
• Validate photo picker and Bluetooth flows on real hardware.
• Re-test after changing the target SDK.

A permission audit is also valuable before seasonal campaigns, major account changes or expansion into new services. If an application adds delivery tracking, health integrations or identity verification, the privacy explanation and access flow should be reviewed before the feature reaches customers.

Use these practices to audit your Android application before release: map each protected feature to its minimum permission, test every denial path and update the privacy wording to match real behaviour. A deliberate permission flow gives Australian users greater control while keeping essential app features reliable on Android 13 and above.