Google Play's July 2026 policy update: 5 changes to ship before the 31 August deadline

Summary. Google published its Play policy announcement on 15 July 2026 with a compliance window of "at least 30 days," which puts the practical deadline for most items in mid-August. Three dates matter beyond that: 31 August 2026 for target API level 36, 1 November 2026 for the extension if you request one, and 28 October 2026 for the contacts and location permission changes announced on 15 April 2026. The single line with the widest blast radius is a clarification rather than a new rule: Google now states explicitly that its User Data requirements apply to third-party AI integrations, and that developers remain responsible for compliance including limited use, disclosure and consent. If your Android app calls an external model API, that sentence is about you. Google also confirmed that 99% of Play apps have been registered automatically for developer verification, leaving the remaining 1% facing global removal, and the developer account itself still carries a one-time US$25 registration fee.

This is a developer-facing read of the announcement: what each change actually requires in code and in your Play Console declarations, and which items are new obligations rather than restatements.

The five changes and their dates

Google filed three of these under "Clarifications" rather than "Updated policies," and noted that "our enforcement standards and practices remain the same" for clarified items. That framing is easy to misread as "nothing to do." A clarification tells you how an existing rule will be read, and reviewers apply it from the day it publishes.

1. Third-party AI integrations are User Data processing

The wording is short. Google is "clarifying that our User Data requirements also apply to third-party AI integrations and that developers remain responsible for ensuring compliance with this policy, including limited use, disclosure and consent."

Three obligations sit inside that sentence, and each one has a concrete artefact.

Disclosure means your privacy policy and your Play Data safety section must both say that user data leaves the app for a third-party model provider. A Data safety form that lists only your own backend is now wrong for any app that forwards a user's message, photo, document or voice recording to an external model.

Consent means the user agrees before that transfer happens, not after. An onboarding checkbox buried in terms of service is the pattern reviewers reject.

Limited use means the data goes to the declared purpose and nothing else. Sending support-ticket text to a model for summarisation is a declared purpose. Retaining the same text to fine-tune a feature you have not disclosed is not.

The engineering work here is smaller than the paperwork. Most teams need one audit of every outbound call to a model endpoint, a matching Data safety declaration, and a consent gate before the first transfer. The trap is SDKs: an analytics or support SDK that quietly routes content through a model provider still counts as your third-party AI integration, and you remain responsible for it.

2. READ_CALL_LOG loses its account-verification use case

Google's SMS and Call Log Permissions policy "will no longer permit account verification via phone call as a use case for the READ_CALL_LOG permission." The announcement names two replacements: the Digital Credentials API, used directly or through a verification provider built on it, and the SMS Retriever API.

Treating this as a drop-in swap is the mistake. Android's own documentation sets out what the Digital Credentials route involves. Phone number verification through the DigitalCredential API is supported on Android 10 (API level 29) and higher, and it requires an account with an aggregator, described as a billable cloud API endpoint that interacts with carriers on your behalf. The flow has two legs: the client app requests a temporary TS.43 token from the device, then your backend exchanges that carrier-issued token with the aggregator or carrier for the verified number.

The request itself is fixed-shape. The protocol must be set to openid4vp-v1-unsigned, response_type is vp_token, response_mode is dc_api, and the nonce must be a unique value generated by your backend for each request, matching the nonce in the aggregator DCQL credential object. The credential you want is specified through dcql_query.

            Verification migration checklist

1. Inventory every code path holding READ_CALL_LOG.
   Silent-verification SDKs are the usual hidden holder.
2. Pick a route:
   - SMS Retriever API        -> no aggregator contract, SMS delivery cost
   - Digital Credentials API  -> aggregator contract, carrier-grade signal
3. If Digital Credentials: sign the aggregator agreement first.
   The commercial step, not the code, is the long pole.
4. Generate the nonce server-side, per request. Never reuse.
5. Set minSdk expectations: the API needs Android 10 (API 29)+.
   Below that, keep a fallback path.
6. Remove the permission from the manifest and re-file the
   Permissions declaration in Play Console.
          

Point 3 is the one that breaks release plans. An aggregator agreement is procurement, and procurement does not fit inside a 30-day policy window at most companies. Teams that cannot close it in time should ship the SMS Retriever path now and migrate later.

3. Register every app, or lose distribution

Google tied Play distribution to Android developer verification and Play Console requirements: "you must register your Play apps in Play Console. While 99% of apps on Play have been registered automatically, you should check your Play Console Home page and register any remaining apps you want to continue distributing to avoid global removal from Google Play."

Global removal is the strongest enforcement language in the announcement. The 1% that did not auto-register are disproportionately the apps nobody looks at any more: white-label builds, regional variants, an old internal tool published under a personal account. Those are exactly the ones that will fail quietly.

Play Console can also register apps you distribute outside Google Play, so they can install on certified Android devices. That matters for anyone shipping an APK through a website or an enterprise MDM alongside a Play listing.

Our Android developer verification checklist for September 2026 works through the account-level side of this in detail.

4. Target API level 36 by 31 August 2026

This is the yearly update, and Google restated it in the same announcement. The requirement is not one deadline but two, and teams routinely conflate them.

An extension to 1 November 2026 is available. Google says the extension form appears through the details page of the warning or issue on the Policy status page in Play Console, and that only apps already out of compliance receive it. You cannot request it pre-emptively.

Two facts calm most stakeholder conversations. Users who already installed your app are not affected and can still find, reinstall and use it on any OS version the app supports. And a user on a newer device following a deep link to a non-compliant listing sees Google Play state that "this app is not available to install on their device because it was made for an older version of Android."

For teams already planning further ahead, our guide to the Android 17 targetSdk 37 and adaptive layout migration covers the wave after this one.

5. Ratings, location precision, and the smaller clarifications

Four items round out the announcement, and they are cheap to fix if you catch them.

Content Ratings now explicitly disallow unrated apps on Google Play. Any listing without a completed rating questionnaire is non-compliant, which usually surfaces in dormant apps rather than active ones.

The Play Data safety section gained more guidance on precise and approximate location disclosures. If your app collects coarse location and your form implies precise, or the reverse, correct it in the same pass as the AI-integration disclosure from change one.

The Personal Loans policy has been reframed for Earned Wage Access apps, so EWA services meet the same transparency and user-privacy standards as other financial service apps. This is narrow but consequential for the payroll-advance category, which is growing quickly in India.

Age-Restricted Content and Functionality, Child Safety Standards and Families Policy Requirements all gained requirements for anonymous chat and random chat apps, and the Families Policy now prohibits anonymous chat apps from targeting children.

Google also introduced standardised numbering across some policies for tracking, and published an open-source Android skill that grounds LLMs in Play policies so an AI assistant can evaluate code against them inside an IDE or CLI. Running your own review against the same policy text a reviewer uses is a sensible pre-submission gate, though it is an assistant rather than an approval.

Next: 28 October 2026

Two permission changes announced on 15 April 2026 land on 28 October 2026, and both push apps toward narrower data access.

The Contacts Permissions policy governs broad access to a user's contacts. Apps that do not need broad access must use the Android Contact Picker, which Google positions as a more secure, easy-to-integrate alternative that minimises data collection.

The Location Permissions policy introduces the location button as the recommended minimum scope for precise location, in line with the user data and sensitive permissions requirements.

Both are the same pattern as the Contact Picker and photo picker changes before them: a system UI that returns exactly what the user chose, instead of a permission that returns everything. Design for the picker now and the October deadline is a non-event.

India-specific considerations

For Indian app teams, change one lands on top of an existing obligation rather than beside it. Section 8 of the Digital Personal Data Protection Act, 2023 makes the Data Fiduciary responsible for compliance in respect of any processing undertaken on its behalf by a Data Processor, irrespective of any agreement to the contrary. Google's clarification says the same thing in store-policy language: routing user data through a third-party model does not move responsibility to the model provider.

The practical consequence is that one artefact can serve both. A single register of outbound data flows, listing every model endpoint, the categories of personal data sent, the declared purpose and the retention period, satisfies the Play Data safety declaration and the DPDP record you need anyway. Building two separate inventories is wasted work. Our DPDP engineering playbook for Indian startups sets out the wider record-keeping structure.

The READ_CALL_LOG change also bites harder in India, where phone-number-first signup is the default rather than the exception. Indian consumer apps that verify by call or by reading the call log need the migration in change two, and the aggregator route means a commercial agreement with a party that can reach Indian carriers. Start that conversation in July, not in August.

The US$25 Play developer registration fee is one-time rather than annual, so account consolidation is not a cost lever. Registering a forgotten app is cheaper than losing it.

A 30-day plan

The window Google gave is at least 30 days from 15 July 2026, and the API level deadline is 31 August 2026. That makes the next six weeks the whole schedule.

1. Grep the codebase for every outbound call to a model endpoint, including calls made by third-party SDKs, and list what data each one sends.

1. Update the Play Data safety section and the privacy policy to match that list, then add a consent gate before the first transfer.

1. Search the manifest and all SDK manifests for READ_CALL_LOG. Decide between the SMS Retriever API and the Digital Credentials API this week, because the aggregator contract is the long pole.

1. Open Play Console Home and confirm every app you still distribute is registered, including builds you ship outside Play.

1. Check each app's targetSdkVersion against API level 36 for submissions and API level 35 for continued discoverability, and watch Notifications for the extension form if you will miss 31 August.

1. Complete the content rating questionnaire on any listing that lacks one.

1. Plan the Contact Picker and location button work for 28 October 2026 into the same release train rather than a separate one.

Teams shipping Android and iOS from one codebase should sequence this against store review cycles rather than calendar dates. A policy fix that lands in a build waiting on review is a policy fix that missed the deadline. Our Android and Kotlin app development practice and the analysis of the 2026 Google Play service fee split cover the surrounding release and economics questions.

FAQ

How eCorpIT can help

eCorpIT runs Play policy readiness passes for Android teams: a full inventory of outbound model calls, matching Data safety and privacy-policy declarations, a consent gate before the first transfer, and the READ_CALL_LOG migration onto the SMS Retriever or Digital Credentials path. Our senior engineering teams also handle the targetSdkVersion lift to API level 36 and the regression testing that comes with it. We design these systems aligned with Digital Personal Data Protection Act 2023 requirements, so the Play declaration and the DPDP record come from one inventory rather than two. Send us your manifest and Data safety form at /contact-us/ and we will tell you what fails.

References

1. Policy announcement: July 15, 2026 - Play Console Help, the primary announcement covering all five changes.

1. Target API level requirements for Google Play apps - Play Console Help, thresholds, form factors and the 1 November 2026 extension.

1. Policy Deadlines - Play Console Help, the 28 October 2026 contacts and location deadlines.

1. Verify phone numbers with digital credentials - Android Developers, the TS.43 token flow, aggregator requirement and request parameters.

1. Request SMS Verification in an Android App - Android Developers, the SMS Retriever API alternative.

1. Overview of digital credentials - Android Developers, the wider Credential Manager context.

1. Minimize your permission requests - Android Developers, alternatives to sensitive permissions.

1. Get started with Play Console - Play Console Help, the one-time US$25 developer registration fee.

1. Android Contact Picker - Android Developers, the alternative to broad contacts access.

1. Location button - Android Developers, the recommended minimum scope for precise location.

1. Play policy insights skill - the open-source Android skill grounding LLMs in Play policies.

1. Update or unpublish your app - Play Console Help, options for apps you will not update.

1. Digital Personal Data Protection Act, 2023, Section 8: general obligations of Data Fiduciary - India Code, official text.

Last updated: 22 July 2026.