Users: Review Privacy Checkup and My Ad Center for your settings; a consumer-policy revision does not itself update an app’s permissions. Developers: Review contacts, location and account-owner workflows against current Play rules and Console notices.
- Consumer policy: Google’s own data practices; the current version checked October 8 is effective October 1, 2026. The April-to-May comparison below is historical.
- Play rules: third-party app distribution requirements; April and July changes have different scopes and deadlines.
- Android APIs: Contact Picker and location controls; behavior depends on the platform version and app implementation.
What changed between the April 2 and May 26 privacy policies?
This selective comparison uses Google’s official version diff, checked October 8, 2026. It describes wording changes, not evidence that collection began on those dates.
| Item | April → May difference |
|---|---|
| Activity storage | Search/Maps/Shopping history distinguished from other Web & App Activity |
| Personalization controls | Added history and recommendation controls, including personalized AI responses |
| Interaction media | Voice/audio wording broadened to images, files, audio and video |
| US state-law disclosures | State-law, CCPA and health-law explanations already existed; not a newly introduced section. Its media-category wording changed |
The April version and May version retain the earlier state-law framework. This is not a full legal redline; use the official diff for every edit and the current policy for today’s terms.
What did Google announce on April 15, 2026?
On April 15, 2026, Google announced a coordinated set of Google Play policy updates focused on reducing unnecessary access to sensitive user data while improving trust in the Android app ecosystem. The announcement combined new developer guidance, Play distribution requirements, and Play Console workflow changes rather than introducing a single Android platform feature.
For publishers, the practical themes are consistent:
- Request only the minimum data required for a feature.
- Prefer platform privacy features where available.
- Justify broader permissions through Play declarations when they are genuinely required.
- Use official ownership workflows for Play Console accounts.
It is important to separate three different layers:
| Layer | What it controls |
|---|---|
| Android platform capability | APIs such as Contact Picker, Sharesheet, location controls, and the Android 17 location button. |
| Google Play distribution policy | Which permissions may be requested for Play-distributed apps, when declarations are required, and how compliance is evaluated. |
| Individual app implementation | Whether a developer updates an app to use newer privacy-preserving APIs, continues requesting broader permissions where justified, or changes its release schedule. |
As reviewed October 8, some items are active and others have revised future dates. Google has also published additional implementation guidance that refines the original announcement, particularly for location permissions.
Why is Contact Picker becoming the preferred approach?
The largest practical change for many application teams concerns contact access.
For apps targeting Android 17 (API level 37) or later, Google says applications that do not require broad access to a user’s address book should use the Android Contact Picker or another appropriate minimum-scope alternative such as Sharesheet, rather than requesting READ_CONTACTS. See the official Android Contact Picker announcement and Play minimum-scope guidance.
The principle is straightforward.
Instead of granting an application visibility into the user’s entire contacts database, the user actively chooses the specific contact or contacts needed for the current task.
The Contact Picker supports:
- Single-contact selection.
- Multiple-contact selection.
- Returning selected contact information for the current session.
This does not mean every contact field is permanently hidden under all circumstances, nor does it automatically change the behavior of applications that have not been updated. Rather, developers adopting the new approach receive only the information associated with the contacts selected by the user during that interaction.
Typical use cases include:
- Inviting friends.
- Selecting recipients for sharing.
- Looking up a contact once.
- Choosing participants for a conversation.
By contrast, READ_CONTACTS is increasingly reserved for applications whose core functionality cannot operate without broad contact access. In those cases, Play policy requires an appropriate declaration explaining why broader access is necessary.
That distinction matters because Google is evaluating whether an application’s core purpose, rather than developer convenience, justifies broader permissions.
What does minimum-scope location mean in practice?
Location permissions are following the same minimum-scope philosophy.
The updated guidance encourages developers to request:
- Approximate (coarse) location whenever it is sufficient.
- Precise location only when the feature genuinely requires it.
- The Android 17 location button for transactional or infrequent precise-location requests.
The details appear in Google’s minimum-scope location guidance and April policy announcement.
This does not mean all uses of ACCESS_FINE_LOCATION are prohibited.
Instead, Google distinguishes several scenarios.
A weather application showing city-level forecasts may only need coarse location.
A delivery confirmation feature that occasionally needs an exact drop-off point may be better served by the Android 17 location button, allowing the user to provide precise location only for that transaction.
Navigation software, mapping applications, or other experiences whose primary function depends on continuous precise positioning may still require persistent foreground precise location, provided the developer can justify that need under Play policy.
Background location remains a separate category with its own requirements and declarations. Meeting the rules for one-time precise location does not automatically satisfy background access requirements.
The earlier late October 2026 expectation is no longer the current published milestone: Google’s Policy Deadlines now lists January 27, 2027 for this change. The implementation guidance describes transactional precise access for apps targeting Android 17+; confirm the applicable notice in Console.
When should developers prepare for each policy milestone?
Different parts of the announcement become relevant at different times.
| Policy / status checked October 8 | Action and scope | Official source |
|---|---|---|
| Contacts — confirmed revised date January 27, 2027; earlier October 28 date superseded | Android 17/API 37+ broad-access apps: justify core need or use picker; guidance notes a Console self-extension | Contacts timeline and deadlines |
| Transactional precise location — confirmed published date January 27, 2027; earlier late-October expectation superseded | Android 17+ one-time precise access: implement location button where required; confirm Console notice | Location guidance and deadlines |
| Persistent/background location — separate review requirements | Justify continuous core-function access; background permissions need their own process | Location guidance |
| Account ownership — confirmed May 27, 2026 requirement, already active | Use official transfer workflow | April announcement |
| Policy tooling — announced October rollout; availability unconfirmed here | Check tools shown in your account, rather than assuming rollout completed | April announcement |
Google also indicated that relevant policy updates would generally receive at least 30 days’ notice from the April announcement, although individual compliance dates vary by policy area.
Which permission path should app teams choose?
Choosing the correct implementation begins with the actual product requirement rather than the API a team has always used.
| Product scenario | Recommended direction |
|---|---|
| One-time contact selection | Use Android Contact Picker or another appropriate minimum-scope alternative such as Sharesheet. |
| Broad contact synchronization | Request READ_CONTACTS only if broad access is genuinely required for the application’s core function and complete the required Play declaration. |
| City-level location | Use coarse location if it satisfies the feature. |
| One-time precise location | Prefer the Android 17 location button for transactional or infrequent requests. |
| Active navigation | Persistent foreground precise location may remain appropriate when core functionality depends on it and policy requirements are satisfied. |
| Background tracking | Separate background-location justification and declaration remain necessary. |
| Account ownership transfer | Use the official Play Console Transfer ownership workflow rather than credential sharing. |
A useful internal review question is simple:
“Does this feature truly require continuous access to this category of data, or only enough access to complete the user’s immediate action?”
That framing aligns product design, privacy engineering, and Play compliance more effectively than beginning with existing permission requests.
How does the new account ownership transfer process differ from app transfers?
The ownership changes announced in April address an area that frequently caused confusion.
Beginning May 27, 2026, changes to the owner of a Play Console developer account must use Google’s official Transfer ownership workflow.
Google also introduced a mandatory seven-day security cool-down during the ownership transfer process.
The policy is intended to replace practices such as:
- Sharing primary account credentials.
- Informal ownership changes.
- Marketplace sales that rely on handing over login details.
Those approaches are not permitted under the new ownership policy.
Equally important, developers should not confuse this workflow with transferring an individual application between separate developer accounts.
Those are different administrative processes with different prerequisites and effects. Existing Play documentation for app transfers continues to apply independently of the new account-owner workflow.
Organizations acquiring development businesses, restructuring internal ownership, or changing legal entities should review which process applies before beginning any migration.
What do these changes mean for Android users and enterprise buyers?
For ordinary users, these updates should gradually reduce unnecessary requests for broad personal data—but only as developers adopt newer APIs and update their applications.
Users should therefore continue to review permission prompts rather than assuming every application automatically follows the latest guidance.
The April-to-May policy comparison does not identify a new acceptance task for ordinary users. To review your exposure, use these checks:
- Read what actually changed. Google’s Privacy Policy archive shows previous versions alongside the current one, so you can compare the historical May 26 text with April and read the current October 1 version instead of relying on second-hand summaries.
- Run Privacy Checkup. Google’s guided review walks through activity history, ad settings, and what other people can see about your account.
- Review ad personalization in My Ad Center. The current policy points there as the control surface for what information feeds the ads you see, including turning personalized ads off.
- Audit app permissions on the device. In Android settings, the permission manager shows which apps hold contacts, precise location, and background location access. As apps adopt the Contact Picker and the Android 17 location button, long-standing broad grants are worth revisiting—an app updated for the new rules may no longer need what it was granted years ago.
Expect the visible changes to arrive gradually through app updates: more contact selections through a system picker instead of an “allow access to all contacts” prompt, and more one-time precise-location buttons instead of standing permission grants.
For enterprise buyers, managed-device deployments, and procurement teams, these policy changes become part of supplier evaluation.
A practical vendor checklist includes asking:
- Which Android target SDK does the application currently support?
- Will contact-related workflows use Contact Picker where appropriate?
- Will one-time precise location use the Android 17 location button when applicable?
- Does the product request persistent foreground precise location?
- Is background location required? If so, what business justification supports it?
- Which Play declarations have been completed?
- What is the planned timeline for adopting updated privacy guidance?
These questions matter for software purchased alongside managed Android hardware because deployment planning increasingly depends on both platform compatibility and Play policy readiness.
For readers comparing broader Android privacy evolution, our guides to Android 17 precise location controls, Android 16 security and Live Updates, and Android 15 privacy and theft protection provide additional platform context.
What implementation evidence should development teams retain?
Privacy compliance becomes much easier when evidence is collected during development rather than immediately before release.
A practical implementation checklist includes:
- Build a complete permission inventory across the application.
- Map every permission to the feature that requires it.
- Verify the application’s target SDK.
- Replace broad permissions with minimum-scope alternatives wherever practical.
- Update privacy disclosures to match actual application behavior.
- Prepare supporting evidence for any required Play declarations.
- Test release builds using realistic permission scenarios.
- Review account governance and ownership controls before organizational changes.
Teams should also retain documentation explaining:
- Why a permission is required.
- Why lower-scope alternatives are insufficient.
- Which user flow depends on the permission.
- Which engineering decision led to the current implementation.
- Which version introduced the change.
This documentation supports engineering reviews, product discussions, and future policy submissions while reducing repeated compliance work.
What other April 2026 policy updates deserve attention?
Although contacts, location, and account ownership received the most attention, the April announcement also included several additional policy updates.
Google updated guidance around:
- Foreground-service policy, removing geofencing as an approved foreground-service use case and directing developers toward the Geofence API where appropriate.
- Health and fitness data guidance.
- Additional policy clarifications intended to improve consistency across Play requirements.
These items are important for affected products but are narrower in scope than the broader minimum-data direction reflected across contacts and location. The official Play policy announcement lists their scope and directs publishers to the applicable deadlines.
The April announcement was also not the last word for the year. On July 15, 2026, Google published a further Play policy update covering anonymous chat safeguards, call-log verification, package-name registration and third-party AI data handling. Our July 2026 policy checklist covers that action set separately, and teams tracking 2026 compliance should treat the two announcements as distinct workstreams with their own deadlines.
Taken together, the April 2026 changes show a consistent strategy rather than isolated policy revisions. Android continues to provide capabilities that support sophisticated applications, while Google Play increasingly encourages developers to request only the information needed for a specific task, document broader access when essential, and adopt standardized workflows for both permissions and account administration.
For publishers, the practical objective is not simply passing a policy review. It is designing applications whose permission model clearly matches user expectations. For buyers and procurement teams, the objective is verifying that vendors are planning for both Android platform evolution and Google Play distribution requirements instead of assuming that one automatically satisfies the other.
Review record — October 8, 2026: Compared April 2 and May 26 wording using the official US-region redline; identified the October 1 current policy and revised Play milestones. Separated historical policy changes from current developer actions; tooling rollout remains unconfirmed.
