Google Play Policy Deadlines That Hit Apps Already Live

For an app that is already on the store, a missed Google Play policy deadline usually does not arrive as a removal email. It arrives as one of four different enforcement actions, and the one that damages live apps most often, restricted discoverability, can happen without any notification at all.

As of 9 November 2026, four dated obligations have already passed for apps that were published before them. The next batch lands on 27 January 2027. What matters operationally is not memorising the list but knowing which kind of deadline you are looking at, because each kind is enforced by a different mechanism, and only one of them stops an upload.

What a policy "deadline" actually is on Google Play

The word covers four distinct things, and blogs that round them into one calendar hide the difference.

A submission deadline blocks the upload itself. The target API level rule is the clearest case: on the Play Console Help page read today, "New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play". Nothing is reviewed; the bundle is refused at submission.

An availability deadline leaves the app published but reduces who can find it. The same help page says existing apps "must target Android 15 (API level 35) or higher to remain available to new users on devices running Android OS higher than your app's target API level". The app is not removed. Its reach contracts.

A registration or declaration deadline is enforced inside Play Console: developer verification registration, Data safety, permissions declarations. Google's July 2026 announcement put the registration piece plainly: check your Play Console Home page and register remaining apps "to avoid global removal from Google Play".

A conduct deadline changes what a policy prohibits, and the new text applies to apps that were already approved under the old text. The enforcement machinery is the ordinary review process, not a separate deadline mechanism.

Google publishes the authoritative list on the Policy Deadlines table, which filters by upcoming and past and moves anything older than three months into a Policy Archive. That table is the primary source for every date in this article.

What Google actually does when a deadline passes

The Enforcement Process page names the actions available to Google. Five of them matter to a live app, and they are not interchangeable.

• Rejection. A new app or an update is not made available. If an update to an existing app is rejected, the previously published version stays live. Google states rejections do not affect your account standing, and that you should not resubmit until every violation is fixed.
• Removal. The app and all previous versions come off Google Play, the store listing disappears, and in-app purchases may stop working until a policy-compliant version is approved. Google notes removal does not immediately affect account standing, but that multiple removals may lead to suspension.
• Suspension. Same removal effect, plus you can no longer use the app's APK or bundle, and the action counts as a strike against the account. Multiple strikes can terminate the account.
• Limited Visibility. Discoverability is restricted, but the app stays available and reachable by direct link. Google states this does not impact account standing and does not affect how existing users see the listing.
• Limited Regions. Download is restricted to certain countries while the listing remains otherwise intact.

Read those five together and the shape of the risk changes. Rejection and removal are loud, reversible and, by Google's own wording, do not touch account standing. Suspension is the one that compounds. Limited Visibility is the quiet one: the app keeps its listing, keeps its rating, keeps its account standing, and simply stops appearing where it used to. For a live app with organic installs, that is the outcome that can run for weeks before anyone notices.

Deadline timeline, read on 9 November 2026

1. 31 August 2026, passed. Submission rule takes effect: new apps and updates must target Android 16 (API 36). Uploads below it are refused before review.
2. 30 September 2026, passed. Play app registration deadline. The stated consequence is global removal, not a rejected update.
3. 9 November 2026, today. The extension date Google named for the target API requirement, 1 November 2026, is already behind you.
4. 27 January 2027, 79 days out. One batch: contacts, location button, READ_CALL_LOG, geofencing as a foreground service use case, and subscription eligibility disclosures.
5. 25 August 2027, 289 days out. Local network and manage-contacts permissions become declaration-gated for apps targeting Android 17 (API 37) or higher.

The live-app deadlines that have already passed

These are behind every app published before them. Their consequences are still running.

Date	What the deadline required	How it is enforced now
2026-08-26	Families Policy Requirements, Child Safety Standards and Age-Restricted Content extended to anonymous and random chat apps	Through normal policy review, and it now covers apps already published, not only new submissions
2026-08-31	New apps and updates must target Android 16 (API 36); Wear OS and Automotive OS 35, TV and XR 34	Upload refused before review begins
2026-08-31	Existing apps must target Android 15 (API 35) to remain available to new users on newer devices	Discoverability narrows to devices at or below the app's target API level
2026-09-30	Play apps registered in Play Console for Android developer verification	Google names "global removal from Google Play" as the risk for apps left unregistered
2026-11-01	The extension date Google named for the target API requirement	The named extension window is behind us; the underlying requirement applies

The target API rule is two clocks, and people conflate them

Every year the same confusion produces the same support ticket. A developer reads that the deadline applies to "existing apps", assumes their untouched app will be pulled, and either panics or ignores the whole thing because the app is still listed.

Both misses. The submission clock is about API 36: it governs what you are allowed to upload. The availability clock is about API 35: it governs how many people can find what is already uploaded. An app targeting API 34 is not deleted. It stops being offered to users on Android versions newer than API 34, which over a year is most of the growth in the install base. Nothing in Play Console turns red, because nothing is broken; the distribution surface just quietly narrows.

The same shape recurs on other technical rules. The 16 KB page size requirement reached live apps as a submission block with no review finding to explain it, and the diagnosis there is a native-library problem before it is a policy problem.

Then the trap closes. The update you would ship to fix the availability problem is itself subject to the API 36 submission rule. So the fix path is stricter than the state that flagged you. Any team planning to sit out a target API cycle should price that in: the escape hatch is a build you have to make anyway, on a deadline you no longer control. When the console refuses a bundle outright, the cause is usually one of a short list, and the fix for an upload rejected for its target API level is a build change plus a re-signed release, not a review argument.

One practical caution about reading this from documentation. On 9 November 2026 the Target API level page still words the extension in the future tense, saying you will be able to request an extension to 1 November 2026, and that extension forms will be available in Play Console "later this year". The date it names is already past. Whether an extension is still open for your app is a fact about your account, not about the help page, and the place it is stated is the warning itself: Google writes that the extension form is reached "through the details page of the warning or issue on the Policy status page in Play Console".

Registration is the deadline with the largest downside

The 30 September 2026 registration requirement is easy to skip because it does not look like app work. It is account work, and its stated penalty is not a rejected update but removal of everything. Google's announcement says 99% of apps were registered automatically, which is exactly why the remaining ones go unnoticed: the console looks normal, the app stays live, and the only signal is a prompt on the Play Console Home page.

If you have any doubt, the check is one screen. Open Play Console Home, look for the registration prompt, and register the package names you intend to keep distributing. Package-name registration is separate from the developer identity verification and registration fee most people think of when they hear "verification", and the two run on different clocks with different documents.

The deadlines you can still prepare for

The next batch is concentrated on one date. Every row below is from the Policy Deadlines table as read on 9 November 2026, with the announcement date kept alongside, because the gap between announcement and deadline is the window you actually get to work in.

Deadline	Change	Announced
2027-01-27	Contacts Permissions policy: broad contacts access restricted; apps that do not need it must use the Android Contact Picker	2026-04-15
2027-01-27	Location Permissions: the location button becomes the recommended minimum scope for precise location	2026-04-15
2027-01-27	Account verification by phone call is no longer a permitted use of READ_CALL_LOG; alternatives are the Digital Credentials API or the SMS Retriever API	2026-07-15
2027-01-27	Geofencing removed as an approved foreground service use case; use the Geofence API	2026-04-15
2027-01-27	Subscriptions with ongoing eligibility-based discounts must disclose eligibility criteria, verification and post-eligibility pricing	2026-10-29
2027-04-14	AppFunctions built with the API must comply with all existing Play policies, including no deceiving or manipulating AI agents	2026-10-29
2027-08-25	Local Network Permission restricted to core functionality; apps targeting Android 17 (API 37) or higher must file a Play Console declaration	2026-10-29
2027-08-25	Manage Contacts Permission restricted; apps must file a declaration to use it	2026-10-29

Two of those rows are the ones a live app cannot delegate. The READ_CALL_LOG change hits any app that verifies a phone number by placing or answering a call, which is a pattern still common in apps written before SMS Retriever was widely adopted. The contacts and local-network rows arrive with a declaration requirement, and a declaration is a form with a deadline attached, not a code change you can ship quietly.

How to read your own deadline status, not a blog's

Every date above will age. The check underneath them does not. In the order worth doing it:

1. Play Console, Policy status. Per-app warnings and issues live here, and the details page of a warning is where any extension form sits. This is the only place that states what your account is actually being asked to do.
2. Play Console Home. Registration and verification prompts surface here rather than on the app's own page, which is why account-level deadlines get missed by teams that only open the release dashboard.
3. The App content page (Monitor and improve, then Policy and programs, then App content). Declaration deadlines are attached to individual declaration forms. Each form has a Timeline section, and eligible policies expose a Request additional time button that, once granted, rewrites the form's compliance deadline and shows the status "Extension granted". Google is explicit that this depends on the policy and that each policy fixes its own extension length.
4. The Policy Deadlines table (12921780). Filter to upcoming for planning, past for diagnosis, and use the Policy Archive for anything older than three months.
5. Email and console notifications. A backstop, not a source. They arrive after an action, which is too late for the deadlines where the penalty is a registration flag rather than a rejection.

What to do in the week after a deadline passes

The response depends entirely on which action you received, and the enforcement vocabulary is the diagnostic tool.

• Update rejected. Your live version is still serving. Fix every cited violation, then resubmit once; if the citation is about functionality rather than a declaration, start with the checks Google actually applies to a rejection rather than rewriting the listing; Google warns against resubmitting before the fix, and that advice exists because a second rejection on the same build costs review days without changing the outcome.
• App removed. The listing is gone but the account is not. Google states the listing is restored once a policy-compliant update is submitted and approved. Republishing without the fix does not work.
• Downloads falling, listing still visible. Treat this as a possible Limited Visibility or target API availability restriction before you treat it as an algorithm problem. Check the app's target API level and the Policy status page before touching the store listing.
• Suspended. This is a strike, and strikes accumulate. Use the appeal route named in the enforcement email rather than opening a new channel.
• Registration prompt unanswered. Resolve it the same day. It is the one item on the list where the stated consequence is the whole catalogue rather than one app.

If the underlying issue is a target API level that Play Console refuses at upload, the error has a small set of causes and a defined fix path. If the issue is a policy text change that your app now contradicts, the work is a code or listing change first and an appeal second, in that order.

Why we check this before a campaign, not after

We run closed-testing campaigns, and the first two things we look at on an app we have not seen before are its target API level and its Policy status page. Our own records across 1,500+ campaigns are not Google data and do not describe the wider developer population, but the reason we check those two fields first is structural rather than statistical: a build that the console refuses at upload cannot be distributed to testers at all, and an app under removed or restricted visibility can be tested perfectly well while giving you no signal about whether it will ever reach the users the test was meant to prove.

That ordering is the whole lesson of this article compressed. A deadline you can see in your own console is an administrative task. A deadline you learn about from a rejection is a schedule problem, and one you learn about from a download graph is a revenue problem.

Frequently asked questions

Does missing a Google Play policy deadline remove my app?

Not usually. Google's enforcement actions are rejection, removal, suspension, limited visibility and limited regions, and most deadline breaches resolve into a blocked upload or a narrower audience rather than a removal. Removal is the stated consequence for specific account-level obligations such as failing to register your apps, and for policy violations serious enough to warrant it.

What is the difference between a removal and a suspension?

Both take the app off Google Play, but a removal does not immediately affect account standing and is reversed by submitting an approved, compliant update. A suspension also removes the app, additionally blocks you from using its APK or bundle, and counts as a strike, with multiple strikes capable of terminating the developer account.

My app is still listed but installs dropped. Is that a policy action?

It can be. Limited Visibility restricts discoverability while leaving the app available by direct link, and the target API availability rule reduces which devices are offered the app once its target level falls behind. Both look like a ranking change from the outside, so check the Policy status page and the app's target API level before changing anything in the store listing.

Can I still get an extension after the deadline has passed?

Only if Play Console offers it. Extension requests for eligible policy declarations are made from the App content page, and the target API extension form is reached from the details page of the warning on the Policy status page. Google notes that not every policy allows an extension, and that each fixes its own extension period, so the console is the authority on your own case.

Does the target API deadline apply to an app I never update?

Yes, but on the availability clock rather than the submission clock. An app that is not updated is not blocked from anything, because there is no upload to block. It does stop being available to new users on devices running Android versions newer than its target API level, and that reach shrinks as the install base moves forward.

Does a rejected update affect my developer account?

Google states that rejections do not impact the standing of your developer account, and that a rejected update leaves the previously published version available. Repeated rejections can still contribute to escalation, and Google's own guidance is to fix all violations before resubmitting.

Where do I see which policy deadlines apply to my app?

Three places, in this order: the Policy status page in Play Console for warnings tied to a specific app, the App content page for declaration deadlines and extension requests, and the Policy Deadlines table for the public calendar of dates. Play Console Home carries the account-level prompts such as app registration.

Sources

• Google Play Console Help, Policy Deadlines (read 9 November 2026)
• Google Play Console Help, Target API level requirements for Google Play apps
• Google Play Console Help, Enforcement Process
• Google Play Console Help, Play Console Requirements
• Google Play Console Help, Policy announcement: July 15, 2026
• Google Play Console Help, Request more time to complete a policy declaration
• Google Play Console Help, Managing Policy Violations and Appeals
• Android Developers, Android developer verification