How Android 15 is Changing App Permissions in 2025: What Developers Need to Know

Why Android 15 Permissions Have Changed

Android 15 is here, and it’s a privacy-focused release that significantly tightens app permissions and user data access. Google’s goal with Android 15 is to give users greater control over their personal data while curbing permission abuse by apps.

This shift is a continuation of Android’s ongoing journey toward more granular, transparent permission management. In previous versions, we saw features like one-time permissions, auto-revoking unused permissions, and the requirement for apps to request notification access explicitly (introduced in Android 13). Android 15 takes these principles even further.

Why the changes? In recent years, both users and regulators have demanded stronger privacy. Apps that once had broad access to device features must now justify and minimize their permissions. Google is also aligning with Play Store policies that favor the “least privilege” approach – apps should only request permissions essential to their core functionality. The result is a platform that is more secure by default, boosting user trust. Developers need to adapt to these changes to keep their apps compliant, functional, and user-friendly on Android 15.

Pro Tip: “Staying on top of these changes isn’t optional – Google Play now requires apps to target recent SDK levels to remain available. (Starting August 31, 2025, new apps and updates must target API level 35 (Android 15).) Embracing Android 15’s permission model early will save you from scrambling to meet deadlines and ensure your app provides a modern, secure experience.”

Official Android 15 SDK and Tools

Major Runtime Permission Changes in Android 15

Android’s permission system has evolved dramatically, and Android 15 introduces several major runtime permission changes that developers must understand. Here’s a summary of what’s new or different in 2025:

• Stricter Foreground Service Permissions: Apps must explicitly declare the exact type of any foreground service they use and request a specific permission for it. For example, if your app uploads files in a foreground service, you must declare it as a dataSync service and hold the FOREGROUND_SERVICE_DATA_SYNC permission. Android 15 will not allow foreground services to run unless these proper types and permissions are in place.
• Granular Media File Access: Android continues the move toward scoped storage and fine-grained media permissions. Instead of one broad storage permission, you now request separate runtime permissions for images, videos, or audio (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO). Android 15 enforces this separation, and apps are encouraged to use the system Photo Picker for most use-cases instead of direct file access.

• Background Location Access Changes: Gaining background location is now a multi-step, more restrictive process. Your app must first request foreground (while-in-use) location normally, and only then can you request the ACCESS_BACKGROUND_LOCATION permission. Even after that, users have to manually enable “Allow all the time” in system settings – Android 15 will not simply show an “Allow always” option in the prompt. This two-step flow, introduced in earlier versions, is now strictly enforced to ensure users understand when an app is tracking location in the background.
• Notification Permission Requirement: As of Android 13+, notifications are an opt-in feature. Apps on Android 15 must request the POST_NOTIFICATIONS runtime permission before they can send any non-exempt notifications. Users will see a system dialog on first run asking if they want to allow notifications – if they deny, your app cannot bug them with alerts (unless they go into settings to enable it). This change improves the signal-to-noise ratio for users’ notification trays and is now standard practice.
• Auto-Revoking of Unused Permissions: Android 15 expands on the auto-revoke (auto-reset) feature introduced in Android 11. If a user doesn’t use your app for a few months, the system may automatically revoke sensitive permissions (like camera, microphone, location) from your app. New in Android 15, this feature is even more aggressive and covers more permission types. Your app should be prepared to handle a permission being revoked in the background – for example, by gracefully re-requesting it when the user returns, and by checking shouldShowRequestPermissionRationale() to decide if you should explain why the app needs it.

• Tighter Sideloading Restrictions: Apps installed from outside the Play Store (sideloaded apps) face new limitations on certain high-risk permissions. Android 15 can block or gate specific permissions for sideloaded apps – for instance, if a sideloaded app wants Accessibility Service or Device Admin privileges, the system may require an extra confirmation or outright prevent it. This is aimed at malware that users might unknowingly install. In practice, it means if you distribute apps outside Play (or in enterprise settings), you’ll need to guide users through enabling these permissions (often via special Intents to settings screens) – if the platform allows it at all.
• New Permission Checks for Content URIs: If your app reads content from other apps (like grabbing an image via a content:// URI), Android 15 performs stricter runtime checks. You must have been granted the appropriate read/write permission for that URI, or you’ll get a SecurityException when attempting access. The solution is to always call ContentResolver.checkUriPermission() before using a shared URI, and use the Storage Access Framework or Intents to gain access. This change closes loopholes where apps might have gotten temporary access to content and then tried to persist it beyond what’s intended.
• Background Activity Launch Limits: To reduce disruptive pop-ups, Android 15 further restricts apps from launching activities while running in the background (unless it’s in response to user action like a notification tap). This isn’t a permission per se, but it’s related to user experience and security. If your app tries to suddenly take over the screen from background, it will simply fail on Android 15. Developers should use Notification prompts or schedule foreground tasks (or use ActivityManager APIs that are allowed) to get user attention more appropriately.

These changes mean that as a developer, you’ll need to update your AndroidManifest.xml, request permissions in new ways, and adjust app workflows. In the next sections, we’ll dive into specific categories like location and camera, show how the AndroidManifest has evolved, and provide code examples in Kotlin and Java.

Sensitive Data Permissions by Category (Location, Camera, Mic, Notifications)

Not all permissions are created equal. Android classifies sensitive data access under “dangerous” runtime permissions, and each category has its own quirks and recent changes. Let’s break down the key categories – Location, Camera & Microphone, and Notifications – and what’s new for each in Android 15:

Location Permissions (Fine, Coarse, Background)

Location is one of the most sensitive user data types. Android 15 continues to enforce a “foreground-first” policy for location access:

• Coarse vs Fine Location: Since Android 12, users have been able to choose between giving apps approximate location (coarse) or precise location (fine). If your app only needs a general location (e.g. city-level for weather), you should request ACCESS_COARSE_LOCATION. If you need GPS precision, request ACCESS_FINE_LOCATION. Android 15 will present the user with an option to grant approximate location if you ask for fine – so make sure your app can handle receiving a coarse location result. Users appreciate apps that don’t ask for more precision than necessary.
• Background Location: As mentioned, Android 15 requires a two-step process. First, request foreground location (ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION). Then, to get background access (ACCESS_BACKGROUND_LOCATION), you must direct the user to settings (via an Intent to the App Settings > Permissions screen) or use a system dialog that appears after the foreground permission is granted. The user has to actively enable “Allow all the time.” Many users won’t, unless it’s absolutely needed. Google Play also heavily polices background location usage – if it’s not core to your app’s function, you risk Play Store rejection for requesting it. So use background location sparingly and explain clearly why it’s needed (e.g. “This app needs constant location to track your run even when the screen is off”).
• One-Time Permission: Remember that users can grant “Only this time” location permission (a feature since Android 11). Your app should handle this gracefully – the next time the app runs, the permission will be gone and you’ll need to request again. Android 15 continues to offer one-time grants, which is great for user privacy.
• Location Indicators: When your app accesses the device location, Android 15 (like Android 12+) will show a green indicator in the status bar to inform the user. There’s nothing special you need to code for this, but be aware the user knows when location is in use. It’s wise to only access location when needed (e.g. don’t run location updates in background constantly unless actively in use by the app’s functionality).

Camera and Microphone

Camera and microphone permissions (CAMERA and RECORD_AUDIO) are classic runtime permissions that most developers are familiar with. Here’s what’s important in 2025:

• Runtime Requests: These remain dangerous permissions that must be requested at runtime. Android 15 hasn’t changed the core request flow for camera or mic – if your app targets SDK 23+ (which it certainly will), you have to use requestPermissions() (or the newer ActivityResultContracts) to get user approval.
• Privacy Indicators & Toggles: Starting in Android 12, whenever the camera or mic is being used, users see an indicator (green dot) on their screen. Android 15 continues this. Additionally, Quick Settings toggles allow users to instantly disable all camera or microphone access system-wide. As a developer, you should handle the case where Camera.open() returns null or throws an exception because the user or system blocked camera access (e.g. via those toggles). Similar for microphone – you might get silence if the mic is blocked. Always check for CameraAccessException or use the CameraX API which handles some of this for you.
• One-Time and Auto-Revoke: Camera and mic permissions can also be granted “this time only.” If the user chooses that, your app gets access just for that session. Moreover, if your app isn’t used for a long period, Android 15’s auto-revoke will pull these permissions. Thus, your app should verify it still has camera/mic permission every time it’s about to use them (and be prepared to request again). This is especially important for apps that rely on these (e.g. a video call app should check permission each call attempt).
• Background Use Limitations: Android has steadily tightened rules on using camera/mic in the background. For instance, if your app tries to record audio from the background, it will generally fail unless you’re running a foreground service with a visible notification to the user. Android 15 continues to enforce that no sneaky background recording is allowed – this protects users from being recorded or photographed without their knowledge. Always bring your app to foreground (with user awareness) for camera/mic operations.

Notifications

Notifications are now user-granted privileges. If your app wants to post notifications on Android 15, you must request permission:

• POST_NOTIFICATIONS Permission: Declare android.permission.POST_NOTIFICATIONS in your manifest and request it at runtime. The system dialog has “Allow” and “Don’t allow” options for the user. Users can also swipe away the dialog; if they do, your app should defer asking again or prompt later as needed. If the user denies, you shouldn’t spam the request; typically apps will show some in-app UI explaining benefits of notifications and a button to trigger the permission ask again.
• Behavior if Denied: If the user selects “Don’t allow”, your app cannot post any notifications (except perhaps high-priority ones like incoming calls or media playback controls, which are “exempt” categories). All your notification channels will be blocked. And importantly, if your app targets < 13 and the user denied notifications even once, the system won’t prompt them again automatically. This is a gotcha: it means you, the developer, have to handle asking again via your own UI if appropriate, or direct the user to enable notifications in system settings. The best practice is to target 13+ so you control the request timing and rationale.
• Best Practices for Notifications: Only request notification permission at a point where the value is clear. For example, after a user performs an action that would result in a notification (“Turn on alerts for new messages?”) – this way the user understands why you’re asking. If you request it right on app launch without context, users may be more inclined to deny. Also, if they deny, avoid immediately nagging them. Perhaps provide a setting in your app (“Enable notifications”) that they can use later, which triggers the permission dialog again.
• Notification Policy on Play Store: Google Play has also updated policy regarding notifications – apps cannot send promotional or irrelevant notifications, and must respect user opt-out. While this isn’t a runtime permission issue, it’s related: abusing notifications (spam) could lead users to revoke your permission or even get your app in trouble with Play policies. So keep notifications useful and user-centric.

By understanding these categories – location, camera/mic, and notifications – you can tailor your permission requests and usage to meet both user expectations and Android 15’s requirements. Next, we’ll look at changes in the AndroidManifest structure and how you declare permissions and other attributes in this new era.

New AndroidManifest.xml Structures and Declarations

The AndroidManifest.xml file is where you declare what permissions your app needs and how your app’s components behave. Android 15 (and recent predecessors) brought some important changes to manifest requirements:

Explicit Exported Components: Starting from Android 12, any Activity, Service, or BroadcastReceiver with an <intent-filter> must include android:exported="true" or "false" in the manifest. This is a security requirement to avoid components unintentionally being accessible to other apps. If you neglect to set this in Android 15, your app will not install. Most likely, your app already targets an SDK where this was enforced, but if you’re jumping from an older target, be aware of this. Go through your manifest and ensure every component is explicitly marked exported or not. Example:

<activity 
    android:name=".ui.ShareTargetActivity"
    android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.SEND" />
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="image/*"/>
    </intent-filter>
</activity>

In this case, we set exported="false" because this activity should only be started internally (even though it has an intent-filter for sharing images, perhaps we only want our app to trigger it). In contrast, launch activities with LAUNCHER intent-filters should be exported="true" so they are accessible from the launcher and other apps.

• Foreground Service Types & Permissions: As mentioned in the runtime changes, you now must declare foreground service usage more explicitly. In your manifest, for each type of foreground task, add the corresponding permission. For example, if your app plays music in a foreground service, you should have:

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

Android 15 defines specific foreground service permission names, such as FOREGROUND_SERVICE_DATA_SYNC, FOREGROUND_SERVICE_MEDIA_PLAYBACK, FOREGROUND_SERVICE_LOCATION, FOREGROUND_SERVICE_CAMERA, etc. You also need to tag the service with the appropriate android:foregroundServiceType attribute. For example:

 <service
    android:name=".UploadService"
    android:foregroundServiceType="dataSync"
    android:exported="false" />

This tells the system that your UploadService will run a foreground task of type “data sync”, and you have declared you hold the matching permission. If you don’t do this, Android 15 will throw an error when you try to start the service. This manifest structure was introduced to ensure apps can’t abuse generic foreground services for unrelated tasks.

• Media Permissions and Conditional Declaration: With the new media permissions, you might need to conditionally declare certain uses. For instance, if your app still supports older devices and you want to use the legacy READ_EXTERNAL_STORAGE on those, but the new READ_MEDIA_ on newer – you can use the maxSdkVersion attribute on the old permission. Example from Android 14 docs:

<!-- Only for Android 12L and lower -->
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"
                  android:maxSdkVersion="32" />
<!-- For Android 13 and higher -->
<uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
<uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
<uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />

If targeting Android 15 and using the Selected Photos feature, also declare READ_MEDIA_VISUAL_USER_SELECTED (the permission that allows limited photo picking control). The manifest can include all these; the system will enforce the relevant ones based on OS version.

• New Permissions in Android 15: Android 15 adds some new permission constants. For example, android.permission.DETECT_SCREEN_RECORDING is a new signature permission that lets an app detect if the screen is being recorded. This might be used by security-conscious apps to know if content is being captured. If your app needs it, declare it, but note that signature permissions are only granted to system apps or apps signed with the same key as the OS (so most third-party apps cannot actually use DETECT_SCREEN_RECORDING unless on custom enterprise devices). Another new addition is related to theft prevention and Private Space, but those are largely system-level and not applicable to most apps (for example, Android 15’s Private Space feature doesn’t require third-party apps to declare anything special in manifest, it’s a user feature).
• Queries and Intents: If your app needs to interact with other apps (like query installed apps or call specific components), remember to use <queries> in the manifest for APIs that require package visibility. This hasn’t changed in Android 15, but it’s worth a reminder since many apps that haven’t been updated in a while might crash when scanning for other installed apps. Modern Android requires you to declare in advance which other apps’ info you want to query (via package name, intent actions, etc., in the manifest queries section).

In summary, treat your manifest with care when targeting Android 15. Go through each <uses-permission> and each component declaration:

• Remove any permissions you don’t truly need (Google Play Protect will flag apps that declare unrelated permissions – for example, a simple drawing app shouldn’t request SMS or phone permissions, or it might be seen as suspicious).
• Add the new required ones (notification, foreground service types, etc.).
• Make sure all Activities/Services/Broadcasts meet the exported/permissions requirements for Android 12+ and beyond.

By cleaning up your manifest, you set a solid foundation for requesting permissions at runtime properly, which we’ll explore next with some code examples.

Sample Code for Requesting Permissions (Kotlin & Java)

Let’s look at how to request permissions in code, using both Kotlin and Java approaches. We’ll cover a simple example of requesting a dangerous permission (say, Camera access) at runtime in an Activity.

Kotlin – Modern Approach with Activity Result API

In Kotlin (or Android in general), the recommended way is to use the Activity Result APIs (part of AndroidX) for a clean, lifecycle-aware permission request flow:

class CameraActivity : AppCompatActivity() {

    private val cameraPermissionLauncher = registerForActivityResult(
        ActivityResultContracts.RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission granted – you can safely initialize camera here
            startCameraPreview()
        } else {
            // Permission denied – show a rationale or disable camera features
            Toast.makeText(this, "Camera permission is required to take photos.", Toast.LENGTH_LONG).show()
        }
    }

    fun onOpenCameraClicked() {
        // Before requesting, you can optionally check if explanation is needed
        if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)) {
            // Show your own UI explaining why the app needs the camera, then request
            showCameraPermissionRationaleDialog() 
        } else {
            // Directly request the permission
            cameraPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Explanation: We create a cameraPermissionLauncher using registerForActivityResult with RequestPermission() contract. This gives us a callback isGranted when the user responds. In onOpenCameraClicked() (maybe called when a “Take Photo” button is pressed), we check shouldShowRequestPermissionRationale. This returns true if the user previously denied the request and didn’t check “Don’t ask again”. If true, we might show a custom dialog explaining why we need the camera, and then call cameraPermissionLauncher.launch(...) when the user agrees. If no rationale is needed, we directly launch the permission request. This modern approach automatically handles the result via the lambda, so we don’t need to override onRequestPermissionsResult. It’s clean and fits well with Kotlin’s concise style.

Java – Traditional Approach with requestPermissions()

In Java or for developers not using the new Activity Result API, you can use the older ActivityCompat.requestPermissions and override the result callback. For example:

public class CameraActivity extends AppCompatActivity {
    private static final int REQ_CODE_CAMERA = 100;

    public void onOpenCameraClicked(View v) {
        if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) 
                != PackageManager.PERMISSION_GRANTED) {
            // Permission not granted yet
            if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA)) {
                // Show an explanation to the user *asynchronously*
                new AlertDialog.Builder(this)
                    .setTitle("Camera Permission Needed")
                    .setMessage("This app needs camera access to take photos.")
                    .setPositiveButton("OK", (dialog, which) -> {
                        // User understood, now request permission
                        ActivityCompat.requestPermissions(CameraActivity.this,
                                new String[]{Manifest.permission.CAMERA}, REQ_CODE_CAMERA);
                    })
                    .setNegativeButton("Cancel", null)
                    .show();
            } else {
                // No explanation needed; request the permission
                ActivityCompat.requestPermissions(this,
                        new String[]{Manifest.permission.CAMERA}, REQ_CODE_CAMERA);
            }
        } else {
            // Permission already granted, proceed to open camera
            startCameraPreview();
        }
    }

    @Override
    public void onRequestPermissionsResult(int requestCode, 
                                          @NonNull String[] permissions, 
                                          @NonNull int[] grantResults) {
        super.onRequestPermissionsResult(requestCode, permissions, grantResults);
        if (requestCode == REQ_CODE_CAMERA) {
            if (grantResults.length > 0 && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Camera permission was granted
                startCameraPreview();
            } else {
                // Permission denied, disable camera functionality or inform user
                Toast.makeText(this, "Cannot open camera without permission", Toast.LENGTH_SHORT).show();
            }
        }
    }
}

In this Java example, we manually check permission, optionally show a rationale AlertDialog, then call requestPermissions(...). The result is handled in onRequestPermissionsResult. This is more verbose than the Kotlin example but functionally similar. The key things to note:

• Always check if you already have the permission (the user might have granted it earlier).
• Use shouldShowRequestPermissionRationale to decide if you should show a custom explanation. This is good UX, especially if a user previously denied your request – blasting the dialog again without context can lead to frustration (or them choosing “Don’t ask again”).
• Handle both the granted and denied cases in the callback. If denied, you might disable the feature or prompt the user with a message. If the user chose “Don’t ask again,” you cannot directly prompt them; you’d have to send them to the app’s settings page if they want to enable it.

Both approaches (Kotlin and Java) ultimately achieve the same result: requesting a runtime permission and handling the user’s choice. Use the one that fits your project’s style (Kotlin + coroutines + LiveData can even simplify it further, but the above is a good general template).

Additional tip: For multiple permissions (say you need to ask for Camera and Audio for a video recorder), you can use ActivityResultContracts.RequestMultiplePermissions in Kotlin, or pass an array of permissions to requestPermissions in Java. Make sure to handle the logic if one is granted and another denied (perhaps enable partial functionality).

Changes to Permission Dialog Behavior

Android has not only changed when and how we request permissions, but also how the system dialogs behave and what options users have. Understanding these dialog behaviors will help you create a smoother user experience:

• “Allow only this time” Option: As noted, since Android 11 the permission prompt might include “Only this time” in addition to “Allow” and “Deny.” If the user selects this, the permission is granted temporarily. When the user leaves the app or enough time passes, the permission is auto-revoked. Android 15 continues to support one-time permissions, which are great for user trust. As a developer, just be aware that you may have to ask again next time, and that the system will not remember the grant beyond that session.
• “While app is in use” (Foreground) vs “Allow all the time”: For location (and a few others like camera on some OEM variants), the dialog sometimes gives a while-in-use option. “Allow while app is in use” means the app can access the resource only when it’s in the foreground (or in a foreground service) – not in the background. If your app requests background location directly, the system won’t show a dialog with “Allow all the time” – it will show a message saying “Allow in settings” for background. The user has to go to settings to enable it. Android 15’s dialogs reinforce this: users are not easily tricked into giving background access. The “Allow all the time” option never appears in the initial pop-up; it must be done via settings after foreground permission is granted.
• Auto-Revoke Notification: Starting in Android 11, when a user grants a permission, the system might show a subtle notice like “This app hasn’t been used in a while, permissions have been auto-reset.” Conversely, when granting, it might inform “You can change this later in settings” or that unused permissions will be removed. Android 15 may remind users about auto-revoke in the UI. For developers, this means a user might not be surprised if your app asks for permission again after a long hiatus – the system primed them that it could happen. Still, consider showing a friendly message like “Welcome back! For your security, Android reset the permissions. Please grant them again so we can continue where we left off.”
• Multiple Denials = No More Dialog: If a user hits “Deny” twice for the same permission (and especially if they tick “Don’t ask again”), the system will stop showing the dialog on further requests. In your code, when you get a denial, you should check shouldShowRequestPermissionRationale. If that returns false and you don’t have the permission, it usually means the user selected “don’t ask again” or the permission is permanently denied. In that case, the only path is to direct the user to the app’s settings to manually enable it. Android 15’s dialog behavior hasn’t changed this mechanism, but just remember: two strikes and you’re out (automatically). Your app shouldn’t continually pester; instead, maybe disable the feature and show a message like “Permission X is required for this feature. You denied it, so enable it from settings if you change your mind.”

• Partial Media Access Dialog: New with Android 14 (and thus in Android 15), if you request READ_MEDIA_IMAGES or READ_MEDIA_VIDEO, the system dialog might present three options: “Allow access to all photos”, “Select photos” (or “Allow selected”), and “Don’t allow”. This is the photo picker integrated dialog. If the user chooses “Select photos…”, the system will walk them through picking specific images that your app can access (without granting blanket storage access). This is a big UX improvement as users can grant exactly the media they want to share. As a developer, if your permission request returns as granted in this case, it actually means partial access was given. Your app can only see the photos the user selected, nothing else. If they try to use a different photo, you’d have to ask again. Internally, this works with the READ_MEDIA_VISUAL_USER_SELECTED permission behind the scenes. Important: test your media-related features on Android 14/15 devices to see this dialog in action, and ensure your app handles the case of getting a limited selection (e.g. don’t assume you can suddenly read the entire gallery).
• Special Permissions (SYSTEM_ALERT_WINDOW, etc.): Some permissions are not granted via a simple dialog at all – they take the user to a settings screen (like Draw over other apps, Write system settings, Notification Listener access, Accessibility Service access). Android 15 doesn’t change how these behave fundamentally, except for the sideloading context mentioned earlier (sideloaded apps might not even be allowed to prompt for these in some cases). But one change in behavior to note: if your app uses SYSTEM_ALERT_WINDOW (draw over apps) and you also try to launch a foreground service, Android 15 will require that you only do so when your overlay is visible to the user. In other words, an app that draws in the background hidden and starts a service is not allowed – the overlay must be actively shown as a form of user awareness. This isn’t a dialog change, but it’s a policy that touches on how those special permissions interplay with runtime behaviors.

In summary, the permission dialogs in Android 15 are designed to be clear and empowering for users. They can grant temporary access, limit the scope (like only selected photos), and avoid harassment (by disabling prompts after repeated denials). As a developer, respecting these behaviors and designing your app flow around them will lead to a much better user experience. For example, if a user denies a permission, don’t immediately force the issue – maybe let them continue using other parts of the app and remind them gently later if they try to use the feature that needs that permission.

SDK Version Considerations and Backward Compatibility

Targeting Android 15 (API level 35) means embracing these new permission models, but many of us still need to support older Android versions at the same time. Here are key SDK and compatibility points to keep in mind:

• MinSdkVersion vs TargetSdkVersion: Your app’s minSdkVersion might be much lower than 35, and that’s okay – Android has backward compatibility frameworks to help. The behavior changes in permissions largely apply based on the OS the app is running on and the app’s target SDK. For example, if your targetSdk = 35 but the app is running on an Android 13 device, the Android 13 rules apply (e.g. notification permission exists, etc., but not the new Android 15-only changes). Conversely, if your app targets 29 but runs on Android 15, the system might put some features in a compatibility mode. Always test on the lowest OS you support and the highest (latest) to see differences.
• Conditional Code with Build.VERSION: Use Build.VERSION.SDK_INT checks when certain code should only run on newer OS. For instance:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) { 
    // Android 13+ specific code (e.g. request notification permission)
} else {
    // Code for older devices (maybe auto-enable notifications as it was before)
}

For Android 15 (UpsideDownCake/VanillaIceCream), you’d check against UPSIDE_DOWN_CAKE or the integer 34/35 as appropriate (official final API level to be confirmed as 34 for 14, 35 for 15).

• Use Support Libraries: AndroidX support libraries often provide backward-compatible methods. For example, ActivityCompat.requestPermissions works back to Android 4.0, so you don’t need to litter your code with version checks for basic permission requests – just call it. Another example: the Jetpack Core library can handle checking if auto-revoke is enabled on the device and even disable it for specific permissions if absolutely necessary (there’s an API PermissionManager for auto-reset exemptions in special cases). Leverage these libraries instead of writing custom compatibility shims.
• Gradual Rollout of Behavior Changes: Some changes only apply when you target a certain API. For instance, the selected photos dialog only shows if targetSdk >= 34 AND running on Android 14+. If you were to target 33 on Android 14, the system would instead grant full media access or use a compatibility mode. So, upgrading your target SDK can actually change how the OS behaves with your app. This is why it’s crucial to read the “Behavior changes for apps targeting Android 15” docs and test thoroughly. The rule of thumb: test your app with targetSdk updated before you release. Many devs leave targetSdk old to avoid changes, but Google Play’s policy will force updates eventually – it’s better to adapt your app proactively.
• Keep Permissions in Sync with Legacy Devices: If your app still cares about users on, say, Android 8 or 9, note that some new permissions don’t exist there. For example, POST_NOTIFICATIONS doesn’t exist on Android 12 or lower. It’s fine to declare it in the manifest – older devices will ignore unknown permissions – but your code shouldn’t try to request it on older devices (you’d gate that by an SDK check). The manifest snippet with maxSdkVersion as shown earlier is another technique to ensure you don’t accidentally request irrelevant permissions on older platforms (e.g., restrict READ_EXTERNAL_STORAGE to maxSdk 32, and add the new ones without maxSdk so they apply to 33+). By doing so, when your app runs on Android 11, it sees the legacy permission, and on Android 13 it sees the new ones.
• Testing Backward Compatibility: Be sure to test scenarios like:
  • User on Android 11 or 12: does your app still work (maybe with fewer features) if they don’t have the new photo picker? (If you used the Play Services Photo Picker backport as recommended, it should cover older devices too).
  • User on Android 13: do they get a notification permission prompt at the appropriate time? If your target was below 33 previously, you might have never handled this, now you will have to.
  • User on Android 15: does anything crash or behave oddly because of the stricter rules? For example, if you used to start a foreground service without the proper type, on Android 15 it might crash where it silently worked on 12.
• Library and SDK Updates: Update any third-party SDKs or libraries you use. Many libraries release updates to support new Android versions. For instance, if you use a camera library, make sure it handles runtime permissions correctly. Some ad or analytics SDKs might add new permissions – be cautious, as those could trigger Play Store reviews. You’ll want to know and possibly disable any library requesting sensitive permissions that your app didn’t intend to ask for.
• Opting out of Auto-Revoke for Legacy Compatibility: There is an edge-case API where apps can ask the system to exclude them from auto-revoke (say, a device admin app that must always have permissions). However, Google Play discourages using this except for very specific cases. It’s better to let auto-reset happen. If your enterprise clients require otherwise, it might be handled via enterprise policies rather than at app level in Android 15.

In short, supporting Android 15 doesn’t mean dropping support for older versions. But you will be coding conditionally and using new APIs alongside old ones. The good news is, by following Android’s best practices (like using AndroidX libraries and not relying on hidden APIs), your app can smoothly handle both old and new behaviors. Aim to make the new model your default (design for Android 15), and simply provide fallbacks for older devices. This way your core logic stays clean and modern.

Developer Best Practices for 2025’s Permission Model

To succeed as an Android developer in 2025, especially with the changes Android 15 brings, consider these best practices moving forward:

1. Adopt a Privacy-First Mindset: Only request permissions that are absolutely necessary for your app’s primary functionality. Every permission you ask for is a potential point of friction with users (and a review hurdle with Google Play). Doing a quick audit: if you have old code requesting contacts or SMS but it’s not central to your app, remove it. Android 15 (and Play Protect) will flag apps that overreach.
2. Explain Before You Ask: Don’t just fire off permission requests cold. Use a custom dialog or UI hint to explain why you need a permission in user-friendly terms. For example, “Enable location to see restaurants near you.” This dramatically increases the chance the user will grant the permission. It also gives you a chance to gracefully handle a denial (“No thanks” path). With the greater control users have, they appreciate when apps are transparent about their requests.
3. Use Modern APIs (Photo Picker, etc.): Embrace platform features that avoid needing permissions. For media, use the Android 13+ Photo Picker API (with backport) to let users select photos without your app ever getting broad file permission. For sharing, use the system share sheet rather than reading external storage. For location, if approximate will do, prefer that. Android is providing these alternatives for a reason – they result in less burden on the user and less risk for you. Also consider WorkManager for background work instead of long-running background services (WorkManager will handle deferrals and constraints, and it plays nicely with system restrictions).
4. Test Thoroughly Under Different Conditions: Test your permission flows under various scenarios: first install, after denial, after “don’t ask again”, after app hasn’t been used for months (you can simulate this by toggling “Remove permissions if app not used” in app info, or via ADB commands). Also test upgrades: if a user had your app on Android 14 and granted some permissions, then they upgrade to Android 15, does everything still work? For instance, after upgrade, the system might auto-revoke some permissions if they hadn’t been used in a while until the user opens the app again.
5. Handle Auto-Revoke Gracefully: As mentioned, if your app is prone to being unused for stretches, implement a check on startup: if a key permission is missing, maybe show a friendly message or trigger the permission request again. The Android APIs allow you to check if the user has chosen to auto-revoke permissions for your app (there’s an API PackageManager.isAutoRevokeWhitelisted() if needed), but generally assume it can happen and be ready.
6. Stay Updated on Play Policy: Google Play’s policies evolve. For 2025, background location, accessibility, SMS/Call Log, and notification permission usage are under strict scrutiny. Example: If you request ACCESS_BACKGROUND_LOCATION, you must fill out a form in Play Console explaining why (or your app update may be rejected). If you request Accessibility Service and your app is not obviously an accessibility tool, Play might warn or remove it (they are cracking down on apps misusing it for automation or things like that). Keep an eye on the official Google Play Policy Center and our own Android Dev Tools Studio posts on policy updates. We have a detailed post on Google Play’s 2025 policy changes – be sure to read “Google Play Policy Changes Every Developer Should Know in 2025” (internal link) for a deeper dive.
7. Target the Latest SDK (and use new APIs): Don’t procrastinate on updating your targetSdkVersion. Each year, as noted, Google Play will enforce it. Targeting API 35 (Android 15) means you opt in to all these new behaviors, but that’s a good thing, it means you can ensure your app is compliant and provides the best experience on new devices. If you stay behind, your app might behave unexpectedly on newer Android (because the system tries to maintain compat but sometimes with quirks). Plus, you won’t be able to publish updates after the deadline. So plan the work early. Typically, get the Android 15 SDK when it’s in beta, test your app, fix any issues, and have an update ready by the time it’s official.
8. Leverage Internal Testing & Feedback: When rolling out a new version of your app with these changes, consider using Play Console’s internal testing track or a staged rollout. Watch crash logs and user feedback closely. Sometimes a permission change can break a specific device or scenario you didn’t anticipate (e.g. a certain content URI was accessible in older OS but now needs an explicit grant, causing a crash). Real-world usage will reveal these. Be ready to issue quick fixes.
9. Educate Your Users: This might sound odd, but if your app’s value proposition is heavily tied to a permission (say, a social AR app that needs camera and location), it might be worth including a brief onboarding slide or FAQ in-app to reassure users about privacy. For example: “We only use your location to show content relevant to you. We never share it with others. You can change permissions anytime in settings.” A little education can increase trust and opt-in rates. It shows you’re not taking their data lightly.
10. Keep an Eye on Future Developments: Android 15 is not the end of the road. Android 16 and beyond will likely continue this trajectory. Perhaps we’ll see even more user control (maybe granular contact or calendar access, who knows!). Stay connected with Android developer news – subscribe to the Android Developers Blog and our updates here on Android Dev Tools Studio. Being proactive on upcoming changes (like the Privacy Sandbox or other initiatives) will keep your app ahead of the curve.

By following these best practices, you’ll not only comply with Android 15’s requirements, but you’ll also deliver a better app experience that respects users. Apps that handle permissions well tend to have higher user trust, which can translate to better reviews and engagement.

Google Play Policy Compliance in the Android 15 Era

With great power (access to user data) comes great responsibility – and Google Play’s policies are there to enforce that. Many of the changes in Android 15’s permission model align with Play Store policy requirements that have been rolled out over the past few years. As a developer, you must ensure your app not only technically handles permissions right, but also meets policy guidelines to avoid bans or removals. Here are the key policy points to watch:

• Target API Level Requirement: We’ve mentioned this, but to reiterate from a policy standpoint: Google Play requires you to target recent Android versions. For 2025, that means target Android 15 (API 35) by August 31, 2025 for all new app updates. Apps that don’t will not be allowed on the Play Store (or if already published, they become invisible to new users). There are exceptions for Wear OS and TV, but for general apps it’s strict. Compliance with this is non-negotiable if you want to stay on Play.
• Permission Usage and Documentation: Certain permissions are gated by Play’s “permissions declaration” process. For example:
  • Background Location: If you include ACCESS_BACKGROUND_LOCATION, Google Play will require you to fill out a form explaining why your app needs it. They will manually review whether your use case is valid (e.g. a turn-by-turn navigation app makes sense to have background location; a wallpaper app does not). If they decide it’s not core to the app, they can reject your app update or remove the app. This ties back to the earlier point – if you can avoid needing background location, do so. If you need it, make sure your app clearly demonstrates the use (in-app and in the store listing description) and that you’ve followed best practices (didn’t request it too early, provided user benefit, etc.).
  • SMS and Call Log: These are highly sensitive. A few years ago, Play banned most uses of READ_SMS, SEND_SMS, READ_CALL_LOG, etc., except for default handler apps (like your phone’s SMS app or dialer) or very specific cases (like a voicemail app or finance app that does phone number verification via SMS). If your app still requests these and you’re not one of the allowed types, remove them or expect removal. Developers now often use alternative APIs (e.g., SMS Retriever API for one-time codes) instead of needing SMS permission.
  • Accessibility API: There’s no manifest permission for this (users enable it in Accessibility settings), but Play has cracked down on apps using Accessibility Service for non-accessibility purposes (like automating UI clicks, or worse, malware). If your app uses it, you must strictly abide by their policy (you have to declare it in the store listing and cannot use it for things like enhancing performance or UI automation that aren’t related to helping users with disabilities). With Android 15 limiting sideloaded apps from easily enabling accessibility, Play’s stance is reflected at the OS level too.
• Play Protect and Runtime Scanning: Google Play Protect now uses machine learning to scan apps for misuse of permissions. As noted by security analysts, Play Protect on Android 15 will even flag apps at runtime if they exhibit suspicious behavior with permissions. For example, a simple calculator app asking for GPS or reading contacts might get flagged to the user as potentially unsafe. This is an automated warning independent of the review process. To maintain user trust (and your app’s reputation), avoid any permission that can’t be justified by a feature that the user expects. If you absolutely need an unusual combo (say your calculator has a share feature that needs contacts), consider redesigning to not require it, or make it an optional add-on that’s clearly separate.
• Data Safety Section: By now, Play Store requires a Data Safety section where you disclose what data your app collects, shares, and how it’s secured. Many of those data types are tied to permissions (location, contacts, etc.). Ensure that if you request a permission, you accurately reflect the usage in the Data Safety form. For instance, if you ask for location, you’ll have to declare that you collect location data and whether it’s shared and why. Misrepresenting can lead to app removal. Android 15’s focus on privacy means Google will likely cross-check apps’ behaviors against their Data Safety claims more strictly.
• Notification Permission and User Choice: Google has updated Developer Program Policies stating that apps must respect the user’s notification preference. If a user denies or turns off notifications, you cannot try to circumvent that (obviously). Also, you should not harass the user to turn it back on. Apps that misuse notifications for ads or irrelevant content can be suspended. With the new runtime permission, Play might treat violation of notification use as a policy issue (e.g., sending promotional pushes without consent could be considered a policy breach under “Spam”). Always ensure your notifications are actionable and relevant, and provide an in-app toggle for users to control certain types if possible.
• Compliance with Special Industries: If your app deals with sensitive information (health, finance, kids’ data), additional rules apply (COPPA, HIPAA, etc.). While not Android-15-specific, note that using certain permissions in those domains might have extra steps. For example, an app designed for children likely shouldn’t request location or camera at all, or it might fall under Families Policy scrutiny.

In essence, Android 15’s permission changes and Google Play’s policies are two sides of the same coin: one is implemented in code, the other in guidelines. If you follow the spirit of one, you’ll likely satisfy the other. The spirit is to respect user privacy and be transparent. Do that, and your app should sail through reviews and keep users happy.

Impact on End Users & App Engagement

All these changes might make developers feel like things are getting stricter (they are), but it’s important to consider the impact on end users – which is ultimately positive. A more privacy-conscious Android means users can trust apps more, which can actually improve engagement if handled right. Let’s break down how Android 15’s permission changes affect users and what it means for your app’s engagement:

• Greater Sense of Control = Higher Trust: Users now have fine-grained control – they can allow notifications or not, give an app only partial photo access, or grant location just once. When an app respects these choices and still provides value, users are more likely to keep using it. Trust is a big factor in retention. If a user feels an app isn’t snooping on them unnecessarily, they’ll be more comfortable engaging with it frequently. On the flip side, if an app demands a bunch of permissions upfront with no explanation, many users will abandon or uninstall it out of caution.
• Initial Friction but Long-term Benefit: Yes, asking for permissions adds friction to the user onboarding – each dialog is a point where the user might say “no” or even close the app. But Android 15 encourages us to request permissions in context, not all at first launch. This actually can improve the user’s first-time experience. They can start exploring the app, and only see a permission prompt when they try to use a related feature. For example, a fitness app might not ask for location until the user actually begins their first workout route. The user then understands why it’s needed, making them more likely to grant it. Thoughtful timing of permission requests can thus improve feature adoption (users will try that feature, see the prompt, grant it, and use the feature – rather than preemptively being scared off).
• Reduced “Permission Fatigue”: Because Android 15 will auto-reset unused permissions and disallow certain abusive scenarios (like constant background access without reason), users won’t suffer as much from apps overreaching. Over time, this could lead to users being more willing to grant permissions when asked, since by default apps don’t keep them indefinitely if not in use. Essentially, when your app really needs something, the user might not be as jaded by previous bad experiences, and might grant it. We’re moving away from the days when people just flat-out denied everything or, conversely, blindly accepted everything. There’s a healthier balance now.
• Notification Opt-in Effects: With notifications being opt-in, you might see fewer users enabling them, unless your notifications are truly valuable. This means you might reach a smaller portion of your user base via push notifications than before (since pre-Android-13, everyone was opted-in by default). It puts pressure on developers to up their notification game – focus on quality over quantity. Engaging content in notifications (that the user explicitly wanted) will yield better click-through and retention. Those who do opt in are your most engaged users; respect their attention. For those who don’t, consider in-app messages or periodic emails as alternate channels to reach them (but again, only with user consent via separate opt-ins).
• Features Tied to Permissions – Communicate Value: If a user denies a permission that is central to your app’s purpose, it’s on you to communicate the value of enabling it. Android 15 won’t let you nag via system dialog, so maybe use a friendly in-app banner: “ Turn on Location to get local deals!” or a settings screen with a prominent “Enable XYZ” button. Many users simply forget or misjudge the importance of a permission. A gentle nudge (not a spammy popup) can educate them. If they understand the benefit, they might go to settings and enable it, re-engaging with that feature. On the other hand, if you don’t communicate and just leave a feature non-functional, the user might think the app is broken or not useful, and disengage. So, bridging that gap is key.
• End-User Privacy = Brand Loyalty: In the current climate, privacy is a selling point. If your app can honestly say “We respect your privacy – we only ask for what we need, and you’re in control,” that can be a part of your brand’s reputation. Smaller developers might even mention in app descriptions or websites how they’re compliant with the latest standards, etc. Users (and even enterprise clients if you develop B2B or internal apps) will gravitate towards apps that are transparent. This intangible benefit can set you apart from competitors who might still be asking for five permissions at startup for no clear reason.
• App Engagement Patterns: Some apps historically abused permissions to keep themselves running (for example, auto-start at boot, using accessibility to prevent being killed, etc.). Android 15 is shutting many of these tricks down. Apps that relied on “growth hacking” via aggressive background behavior might see their engagement drop – if their core value isn’t strong. Meanwhile, apps that provide real user value at the right time will continue to thrive. Essentially, Android is leveling the playing field by removing shady tactics; engagement will be driven more by genuine usefulness. Ensure your app focuses on that usefulness, and use permissions as enablers for user-desired features, not for sneaky background processes.
• Performance and Battery: While not immediately obvious, stricter permission and background limits mean fewer apps doing resource-intensive operations invisibly. Users on Android 15 may notice improved battery life and performance because apps that don’t need to run won’t as easily run in the background. This is good for overall user satisfaction with the platform. For your app, it means if you do need to run in background (say, a music player or workout tracker), you’ll be one of fewer apps competing for resources, presumably. But you’ll also have to adhere to foreground service limits (with user-visible notifications). Users are more likely to trust an app that shows what it’s doing (e.g., a persistent notif “Tracking your workout – 23 minutes”).

In summary, the impact on users is largely positive: more privacy, more control, and arguably a better experience with apps that follow the rules. For developers, the challenge is to adjust without hurting engagement:

• Make permission asking a part of the user journey, not a blocker.
• When users say “no”, adapt gracefully and offer alternate paths or gentle re-entries into the happy path.
• Highlight the benefits of granting permissions, but never be deceptive.

If done right, you might find that users who grant permissions to your app are highly engaged and trusting, and those who don’t can still use portions of your app (maybe leading them to eventually convert when they see value). Android 15 essentially asks us to respect users – which is a win-win for long term engagement.

External References & Official Resources

Finally, don’t just take our word for it. It’s always wise to consult the official documentation and resources straight from Google:

• Official Android 15 Developer Documentation – particularly the sections on Behavior Changes and Privacy & Permissions on Andoid Studio. Google outlines the changes in detail, and provides migration tips. The “behavior changes for all apps” and “behavior changes for apps targeting 15” pages are goldmines.
• Android Developers Blog – Android 15 Release – when Android 15 was officially announced, the Android Developers Blog had a post highlighting the major features and changes for developers. It’s a great high-level summary directly from the source.
• Google Play Policy Center – this isn’t just legalese; they have clear lists of what’s allowed or not. For example, the User Data policy section explicitly covers sensitive permissions and the requirement to have a privacy policy. The Permission Requests policy section describes how you should sequence permission requests (only at runtime, for instance) and not abuse them. Compliance here is mandatory for Play Store apps.
• Android Code Samples on GitHub – Google maintains a repository of sample apps (in android/platform-samples on GitHub) that demonstrate best practices. There are samples for runtime permissions, foreground services, etc. You can see real example code of how Google intends developers to use these APIs.
• Developer Forums and Issue Tracker – if you encounter a bug or odd behavior with permissions on Android 15, you’re likely not alone. Checking the Android Developer community (Stack Overflow, Reddit’s r/androiddev, etc.) can surface discussions. For confirmed issues, Google’s issue tracker might have reports – for instance, some developers early on raised concerns about photo picker behavior, and those got addressed in patches. Staying tuned in will help you react quickly if something in Android 15 needs a workaround.

By utilizing both this comprehensive guide and other resources, you should be well-equipped to update your apps for Android 15, ensure compliance with policies, and deliver a product that delights users and respects their choices.

In conclusion, Android 15’s changes to app permissions are a big step forward in Android’s evolution. Developers who adapt will find that, although the road to adaptation requires effort, the end result is a more trustworthy app ecosystem. Users will reward apps that handle permissions elegantly with their time, attention, and positive reviews. As a developer, staying informed and agile is your best strategy. Happy coding on Android 15, and may your apps continue to thrive in this privacy-conscious era!

FAQ’s

1. What are the key permission changes in Android 15?

Android 15 introduces stricter rules around foreground services (requiring explicit types and permissions), imposes scoped access for media files (e.g. separate READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), enforces a multi-step flow for background location, and tightens permission for sideloaded apps on “special” capabilities like accessibility or overlays

2. Why do I need to declare android:exported in the manifest?

Since Android 12+, any component with an <intent‑filter> must explicitly include android:exported="true" or "false". Failing to do so will cause installation to fail on Android 15+.

3. How do I safely request background location on Android 15?

You must first request foreground location (ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION) at runtime. Only after that can you prompt the user to manually enable “Allow all the time” in system settings—Android 15 removes automatic “Allow always” pop-ups for background location.

4. What happens to media access in Android 15?

Scoped storage continues. You should use Photo Picker, or request separately READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, or READ_MEDIA_AUDIO. Users may choose “Select photos” instead of blanket access, and unused permissions can auto‑revoke after periods of inactivity .

5. Can sideloaded apps get “special” permissions on Android 15?

Yes—but under stricter control. Permissions like Accessibility, overlay, device admin, usage access, default app roles, and SMS/log-reading require users to explicitly enable Restricted Settings. The platform may block or prompt more intensively for sideloaded apps.