Apps that request broad contact and location access without clear user benefit now have a hard deadline. Google's updated Play Policy, effective April 15, 2026, sets a 30-day enforcement window. After May 15, apps still requesting permissions that exceed their declared core functionality face suspension. This affects hundreds of thousands of apps across categories from productivity to e-commerce.
What the Google Play permissions policy actually changed
The April 2026 update is not a minor tweak. Google has tightened three existing rules simultaneously and added a new automated enforcement layer that flags apps during review rather than waiting for user complaints.
The three areas under direct enforcement are contact access, precise location, and the use of the QUERY_ALL_PACKAGES permission. Each now requires developers to submit a Declaration Form in the Play Console explaining exactly why the permission is necessary. Vague justifications like "to improve user experience" will be rejected outright.
- Contact permissions (
READ_CONTACTS,WRITE_CONTACTS) - Apps that only need to let users share one contact or pick a recipient can no longer justify full contact list access. Google's Android Contact Picker handles this without granting the app any permission at all. - Precise location (
ACCESS_FINE_LOCATION) - Apps must justify GPS-level precision over approximate location (ACCESS_COARSE_LOCATION). Delivery apps, navigation tools, and real-time fleet trackers qualify. A food ordering app that only needs to know a user's city does not. - Background location (
ACCESS_BACKGROUND_LOCATION) - This already required approval, but the new policy adds stricter category restrictions. Fitness tracking, navigation, and family safety apps remain eligible. Nearly every other category does not. - Package visibility (
QUERY_ALL_PACKAGES) - Only apps like device managers, security scanners, and file managers can justify seeing every installed app. The new enforcement closes a loophole that ad SDKs were exploiting to build device fingerprints. - Permission request timing - Apps may no longer prompt for permissions on first launch before users have interacted with the feature that requires them. The request must happen at the moment the user takes an action that genuinely needs it.
The best permission is the one you never request. If you can build the feature without it, Google now expects you to.
How to replace broad contact access with the Android Contact Picker
The Android Contact Picker (ContactsContract.CommonDataKinds accessed via ActivityResultContracts.PickContact) lets a user select a single contact and returns only the data your app receives - no full address book access, no permission dialog, no declaration form needed. For the vast majority of use cases, this is the correct replacement.
Here is the pattern in Kotlin:
val pickContact = registerForActivityResult(ActivityResultContracts.PickContact()) { uri ->
uri?.let { resolveContactUri(it) }
}
// Trigger when the user taps "Add contact"
pickContact.launch(null)If your app genuinely needs to read or sync a user's full contact list - a contacts manager, a CRM with sync, or a messaging app - you still qualify for READ_CONTACTS. File the Declaration Form clearly. State the exact feature, describe how the data is stored, and confirm it is never shared with third parties. Reviewers are checking all three points.
Replacing precise location with approximate location
Android 12 gave users the ability to grant approximate location even when an app requests precise. As of this policy update, apps that do not have a documented need for GPS accuracy must now request only ACCESS_COARSE_LOCATION from the start.
Approximate location gives you a circle with roughly 3-kilometer radius accuracy. That is enough for showing nearby restaurants, weather, local search results, or region-based content. It is not enough for turn-by-turn navigation, live delivery tracking, or geofencing smaller than a city block.
The practical migration for most apps is a one-line change in AndroidManifest.xml and a corresponding update to any runtime permission request. The harder work is auditing every place in your codebase that consumes location data and confirming that the accuracy you assumed is the accuracy you actually need.
The enforcement timeline and what happens if you miss it
Google's enforcement follows a three-stage sequence that has been consistent across recent policy updates:
- Warning email (already sent). Apps identified by the automated scanner received policy violation notices beginning April 15. If your developer account has one, check the Play Console Policy status page now.
- App suspension (May 15). Apps that have not shipped a compliant update by the deadline will be removed from the store. Existing installs continue to work, but new downloads stop and your store listing disappears.
- Account-level action (ongoing). Repeated or deliberate violations can escalate to developer account termination. Google has been more willing to use this option since 2024's enforcement wave removed over 2.28 million apps in a single year.
The fastest path to compliance is a targeted update, not a full release cycle. You do not need to rebuild the app. You need to remove the offending permission declarations, swap in the correct API calls, update your Declaration Form, and push to the Play Console. Google processes policy-compliance updates in 24-72 hours for most apps in good standing.
Auditing your app in 30 minutes
Before writing a line of code, run a permissions audit. Android Studio's App Inspection tool and the Permission Controller module show every permission your app holds at runtime. Cross-reference that list against your AndroidManifest.xml. Any permission declared there but not actively used in code is a removal candidate with zero feature impact.
For dependencies, check every third-party SDK in your build.gradle files. Ad networks, analytics SDKs, and social login libraries have historically been the silent source of permission bloat. A library that requests ACCESS_FINE_LOCATION in its own manifest merges that request into yours at build time. Tools like Gradle's dependency insight and the Android Gradle Plugin's merged manifest viewer surface these hidden declarations before Google does.
- Use Android Studio's Merged Manifest view - opens in the AndroidManifest.xml tab, shows every permission from every dependency in your build
- Run
aapt dump permissions <your-apk>- lists all permissions in the final APK, including those injected by SDKs - Check Google Play Console's Policy status page - shows any active policy flags on your app before the reviewer sees them
- Review Firebase, Meta, and AppLovin SDKs first - these three account for the largest share of unexpected permission additions in Android projects
What this means for apps built by agencies
If you had your app built by a development agency and are not actively maintaining the codebase yourself, this deadline applies to you just as much as it applies to in-house teams. The policy violation is against the developer account, not the code author. Check your Play Console now, forward any policy emails to whoever manages your Android project, and confirm a compliant update is in progress.
At SARVAYA, we handle exactly this kind of compliance work for clients who do not have a dedicated Android team. Whether the issue is a legacy permission request, an outdated SDK, or a full permissions architecture review, we can audit, fix, and ship a compliant update well inside the May 15 window. If you have a mobile project that needs a compliance check, reach out directly. We also build new Android and web apps with privacy-respecting permission patterns from the start - see the kind of work we do on our portfolio page.
