Google Play's July 2026 Policy Update: App Team Checklist

Google Play’s July 15, 2026 policy update requires immediate work from several app teams: anonymous or random chat services, apps using READ_CALL_LOG for phone-call verification and publishers with Play package names that were not auto-registered. Every team should also audit third-party AI data flows, confirm a content rating and meet the separate August 31 target API deadline.

This is an operational summary, not legal advice. Google Play’s current policy text and the notice in your Play Console account control.

Key takeaways

• Anonymous and random chat apps face expanded age-restricted and child-safety requirements on August 26, 2026; anonymous chat apps may not target children under the Families policy.
• Account verification by phone call is no longer an accepted READ_CALL_LOG use case. Migrate to a lower-permission verification method.
• All Play package names must be registered by September 30, 2026. A “99% auto-registered” statistic is not a substitute for checking each app.
• Google clarified—not newly created—the developer’s responsibility for User Data compliance when third-party AI receives app data.
• The August 31 target API requirement is a separate annual deadline: phone app submissions target API 36, while existing phone apps need API 35 for full discoverability to new users on newer Android versions.

What changed, what was clarified and what was only a reminder?

Google deliberately separates the announcement into three groups. Preserve that distinction in compliance tracking.

Type	July 2026 item	Operational meaning
Updated policy	Anonymous/random chat, child safety and Families rules	Review audience, age controls, moderation and store targeting
Updated policy	READ_CALL_LOG no longer permitted for phone-call account verification	Replace the permission-dependent flow
Updated requirement	Register Play apps/package names	Check identity and registration status in Play Console
Clarification	User Data rules apply to third-party AI	Existing obligations cover AI vendors and data flows
Clarification	Unrated apps are not allowed	Verify an active, accurate content rating
Clarification	More guidance for location Data safety disclosures	Reconcile declared precise/approximate use with the app
Reminder	August 31 target API level	Complete the annual SDK migration or eligible extension process

The distinction matters because a clarification does not grant a fresh compliance period. If an app was already sending user data to an AI provider without appropriate limited use, disclosure or consent, the July wording should trigger correction—not a plan to wait for a future enforcement date.

This article complements our April 2026 Google Play policy guide, which covers contacts permission, location changes and account transfers. The July update adds a different action set and should have a separate owner and evidence trail.

What are the important 2026 dates?

Use the date attached to the individual requirement, not “30 days after the announcement” as a universal deadline.

Date	Milestone	Team action
July 15, 2026	Policy announcement	Triage every app and assign owners
August 26, 2026	Anonymous/random chat and related Families/child-safety changes listed by Google	Complete audience, safety and targeting changes
August 31, 2026	Annual target API deadline	Meet the form-factor-specific target levels or submit an eligible extension
September 30, 2026	All Play package names must be registered	Resolve any failed or manual registration
November 1, 2026	Target API extension endpoint for eligible apps	Finish migration before extended distribution expires

Google may show app-specific warnings or dates in Play Console. Record those notices in the compliance ticket and treat the earlier applicable requirement as the release boundary.

Which apps need urgent review?

Run a portfolio query before reading policy text app by app. Mark an application high priority if any answer below is yes.

1. Does it enable anonymous or random matching, chat, voice or video interaction?
2. Is it designed for children, listed in the Families program or likely to attract minors?
3. Does it request READ_CALL_LOG, especially during onboarding or account recovery?
4. Does any SDK or server send user data to a generative AI, moderation, transcription or AI-agent provider?
5. Is the content rating missing, expired or inconsistent with current features?
6. Does Play Console show incomplete identity or package-name registration?
7. Is a phone app submission below API 36, or an existing phone app below API 35?

Then inspect shared SDKs and white-label builds. One onboarding library can create the same call-log violation across several package names. One AI support vendor can affect every app even if the model is not visible in the primary interface.

What must anonymous and random chat apps do?

Google expanded its Age-Restricted Content and Functionality and Child Safety Standards policies to cover anonymous and random chat. Its Families requirements now prohibit anonymous chat apps from targeting children. The Policy Deadlines page lists August 26, 2026 for these changes.

Affected teams should review the complete linked policies, then verify at least these areas:

• Target audience and content selections in Play Console.
• Store listing language, imagery, keywords and acquisition campaigns that may target children.
• Age assurance or age-gating logic appropriate to the service and market.
• Reporting, blocking, moderation, escalation and law-enforcement response processes.
• Safeguards around adult-minor interaction and sexual exploitation risks.
• Whether random voice/video matching changes the applicable content rating.
• Evidence that safety controls work in every locale and on every client version still supported.

Do not treat a date-of-birth screen as the complete child-safety program. Policy compliance can span product behavior, content operations, staffing, response times and marketing. Preserve screenshots, test records, moderation rules and escalation logs as review evidence.

If an app cannot meet the rules by the applicable deadline, feature restriction or temporary distribution changes may be safer than shipping an unverified partial control. That decision should involve product, safety, legal and release owners.

How should phone-call verification be replaced?

The July update removes account verification by phone call as a permitted READ_CALL_LOG use case. An app should not retain the sensitive permission merely to detect an incoming verification call.

Google points developers to alternatives including the Digital Credentials API and SMS Retriever API. Choose the replacement from the identity assurance actually required:

Need	Lower-permission starting point	Validate
Receive an SMS code automatically	SMS Retriever API	Message format, timeout and manual-code fallback
User confirms a credential	Digital Credentials API or provider built on it	Credential availability, issuer support and recovery
Simple possession check	User-entered one-time code or verified link	SIM-swap and phishing risk, rate limits
Strong account security	Passkey plus risk-based recovery	Device loss, cross-device sign-in and support flow

Inventory the full call-verification path: manifest permission, runtime request, SDK dependency, backend challenge, fraud rules, help-center instructions, analytics events and recovery. Removing the manifest line while the server still expects a missed-call signal will strand users.

Roll out the replacement before withdrawing the old flow, but do not keep the prohibited permission path active beyond the applicable policy date. Measure completion, fraud, resend, abandonment and support volume by country and carrier.

What does package-name registration require?

Google says 99% of Play apps were registered automatically, but every publisher must verify the remaining one percent in its own portfolio. Effective September 30, 2026, all Play package names must be registered; Google says unregistered apps will be removed from Play under the Play Console Requirements policy.

For each developer account:

1. Confirm identity verification under Play Console account settings.
2. Open the Console home page and Android developer verification area.
3. Export or record every package name and registration status.
4. Resolve drafts or failed auto-registration.
5. For manual registration, select an eligible public certificate, add Google’s supplied snippet to an APK asset folder, sign it and upload it as instructed.
6. Record the confirmation email and final status.
7. Repeat for package names distributed outside Play if installation on certified Android devices requires registration.

Google’s package eligibility rules consider signing keys and known install share. Teams with shared package names, acquired apps, multiple certificates, white-label arrangements or disputed ownership need additional lead time. An ineligible key can require a request to use the package name.

Do not wait until September 29 to discover that the employee who controls a historical signing key has left the company.

How do User Data rules apply to third-party AI?

Google describes this item as a clarification: User Data requirements already apply when an app integrates a third-party AI service. The developer remains responsible for limited use, disclosure and consent.

Map the end-to-end chain:

• What user data, attachments and retrieved context enter the AI feature?
• Does the client send directly to the provider, or does a company backend proxy the request?
• Which provider, model, region and subprocessors receive it?
• Is content stored, logged or used for provider model improvement?
• Do the privacy policy, in-app disclosure, Data safety form and consent experience agree?
• Can the user avoid the AI feature or delete associated data where required?
• What happens when the provider changes its terms, model or retention behavior?

The answer “our SDK handles it” is not a compliance control. Maintain a vendor data-processing record, approved configuration, version inventory and change-review owner. Minimize content before transfer, separate sensitive account fields from prompts and prevent raw prompts from appearing in analytics or crash logs.

For architectural choices that can reduce or control data transfer, use our on-device vs cloud AI decision guide. For AI agents that act across applications, the Android Halo visibility guide covers user confirmation and action transparency.

What should teams check for ratings and location disclosures?

Google clarified that unrated apps are not allowed on Play. Confirm each active package has a rating and that the questionnaire reflects current user-generated content, chat, commerce, gambling-like mechanics, violence, sexual content and AI-generated material. Revisit it when the product changes, not only when Play prompts a review.

Google also added guidance around precise and approximate location disclosures in the Data safety section. Compare declared collection and sharing with runtime permissions, SDK behavior, backend fields and feature requirements. Our Android 17 precise location controls guide explains the platform changes that make unnecessary precision an increasingly fragile assumption.

Treat the privacy policy, Data safety answers, permission prompts and actual network behavior as four views of the same system. A wording update cannot repair undisclosed collection in code.

What is required by the August 31 target API deadline?

For standard phone and tablet apps beginning August 31, 2026:

• New apps and app updates must target Android 16, API level 36, or higher to be submitted.
• Existing apps must target Android 15, API level 35, or higher to remain discoverable to new users on devices running Android versions above the app’s target level.

Wear OS and Android Automotive OS submissions must target API 35; Android TV and Android XR submissions must target API 34. Existing-app discoverability thresholds vary by form factor, so consult Google’s table for the exact package.

Eligible affected apps can request an extension to November 1, 2026 through the warning or issue in Play Console. An extension protects time; it does not remove migration work. Use the Android 17 stable rollout guide to structure compatibility testing across OS versions and critical workflows.

A release-ready compliance checklist

Owner	Evidence required	Done when
Portfolio manager	App/package inventory and triage result	Every active app has an owner and status
Trust and safety	Chat audience, controls, moderation tests	August 26 requirements are evidenced
Identity engineer	New verification flow and permission scan	READ_CALL_LOG verification dependency is removed
Play Console admin	Identity and package registration export	Every Play package shows registered
Privacy owner	AI data-flow map, disclosure and vendor record	Code, console and policy text agree
Content owner	Current rating questionnaire	No active app is unrated or stale
Android lead	targetSdk, compatibility and release report	Correct form-factor target is submitted
Release manager	Policy-status screenshots and approvals	No unresolved applicable blocker remains

Final recommendation

Run the July 2026 update as a portfolio program with three workstreams. First, remediate updated policies: anonymous/random chat safeguards, call-log verification and package registration. Second, validate existing obligations highlighted by Google’s clarifications: AI user data, content ratings and location disclosure. Third, finish the separate annual target API migration.

Assign dates from the applicable Google policy page, preserve Play Console evidence and recheck status before every production release. The highest-risk failure is not misunderstanding a paragraph; it is leaving one old package, white-label build or shared SDK outside the inventory.