Every Play package must be registered by 30 September 2026 — and the install-side milestone is a different obligation

Twenty-eight days, counted from 2 September 2026. Two different things happen on the date, and they are two different obligations.

One of them names four countries. The other one is written on your Play packages. If you ship an Android app on Google Play, the second is the sentence to read first, and this page exists to keep the two apart.

Every quotation below was read from the Google page it is attributed to on 2 September 2026, and the date beside it is the date it was checked. The authority on your own apps is Play Console.

Two obligations, one date

The install-side milestone is the one with the country names on it. developer.android.com/developer-verification carries a banner reading "Next milestone: September 30, 2026", and the sentence under it, checked 2 September 2026:

"These protections begin for users installing apps from participating stores (Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore, GetApps) in Brazil, Indonesia, Singapore, and Thailand, on certified devices running Android 7+. In 2027, we'll expand this globally to all apps on certified devices."

The same page's Timeline table, under the introduction "We're announcing these changes early and incorporating developer feedback to help keep the Android ecosystem safe and sustainable", gives the same milestone as one row of three:

Two statements about 2027 sit on that one page. The hero sentence commits to a year and scopes to all apps: "In 2027, we'll expand this globally to all apps on certified devices." The Timeline row reads "2027 and beyond" and scopes to all certified Android devices. Both are quoted above as they stand.

The registration obligation is the one written on your packages. Play Console Help, Registering Play package names (answer 16984799), checked 2 September 2026, in two consecutive sentences of a single paragraph:

"Effective September 30, 2026, all Play packages must be registered to meet Android developer verification requirements. Apps not registered by Sep 30, 2026 will be removed from Play pursuant to the Play Console Requirements policy."

Read the addressee. It is all Play packages. And read Google's own word for the consequence, which appears on the policy article that sentence points at — Play Console Requirements, answer 10788890, checked the same day: registering the remaining apps you want to continue distributing is what avoids "global removal from Google Play".

That is the sentence to hold a release against. The four country names belong to the install-side milestone. The registration sentence is written on all Play packages, and its consequence is described by Google as global.

The sentence that is written on all Play packages

The Play Console Requirements article states the duty flatly, in the present tense, and marks its effective date separately as a standalone line:

"To meet Android developer verification requirements and Play Console requirements, you must register your Play apps in Play Console."

"(effective September 30, 2026)"

The same article extends the console's registration function past the store itself:

"You can also use Play Console to register apps you distribute outside of Google Play to ensure they can be installed on certified Android devices."

And the developer-verification page gives the instruction in one line: "Use Play Console to manually register remaining apps or those distributed outside Google Play."

The Registering Play package names article sets two required tasks: verify your identity, and register your app package names. They are separate, they are both required, and the order in which you complete them changes what the console will tell you — which is two sections below.

Registration is decided on signing keys and install share

The eligibility rules are the part to read closely, and they are the reason a team can be certain it is fine and be wrong.

Google states that it will attempt to auto-register both existing and new Play apps, according to package-name eligibility rules that the article publishes as a three-row table. Set out as Google frames them:

• Majority key holder. Where one key accounts for over 50% of a package name's total known installs, that key has priority. All other developers submit a request.
• Fifty or more installs. Where no single key holds more than 50% of installs, every key with 50 or more installs is eligible to register the package name. A key below that threshold submits a request.
• Under fifty installs. Where no key meets the 50-install threshold, any key can be used on a first-come, first-served basis. After the first registration, the others submit a request.

Now read what all three rows key on. Every one of them is decided by an app signing key and the installs attributed to it. That makes registration a question about the release history of the binary.

Google names the topic itself: the link card to the verification FAQ on developer.android.com/developer-verification reads "FAQ / Find quick answers about registration fees, requirements, and signing keys."

Four release histories in which the key and the team have come apart:

• The signing key sits with an agency. The app was built out of house, the installs accumulated under a key that firm holds, and the engagement ended two years ago.
• One package name ships from two keys. A legacy signed build still installed in the field and a current one, or a variant signed on a separate pipeline.
• The upload key was rotated and nobody re-derived which key the installed base is actually attributed to.
• The app was inherited, through an acquisition or an internal transfer, along with a listing and without the keystore's history.

In each of those, the answer to "is my package registered" is a fact about keys and installs, and it is visible in Play Console.

The manual path, and where the answer is

The Registering Play package names article carries a section headed Auto-registration status, a section headed Manual registration of package names, a section headed Ineligible keys, and a Get help section.

Manual registration runs as five steps in Play Console. Its closing line is the one to read before you plan a release around it:

"You do not need to upload the actual APK."

And the condition on notifications is the one to clear first. Google states that you will only receive notifications about the registration status of your apps if you have completed identity verification in Play Console. Identity verification is the first of the two required tasks; completing it is what turns the second one into something the console will tell you about.

So the order that follows from Google's own text is: complete identity verification, then read the registration status of every package you ship, then submit a request for anything the eligibility rules leave to a request.

Account type: who Play requires to register as an Organization

The preview of the policy article — Preview: Play Console Requirements, answer 17125096, checked 2 September 2026 — carries the registration duty as a numbered item in the "before you submit your app" list. The page numbers its items bare, with a trailing period, so item 3.4. reads:

"3.4. Register your app package names via Play Console to comply with Android developer verification requirements. Learn more about registering Play package names."

The same article carries an account-type requirement keyed to what the app does. Its lead-in and its first item, verbatim:

"When creating your Play Console account, developers providing the following services must register as an Organization:"

"1.1. Financial products and services, including but not limited to banking, loans, stock trading, investment funds, cryptocurrency software wallets, and cryptocurrency exchanges. Learn more about the Financial Services policy."

If you ship a lending, banking, broking, funds or crypto-wallet app, that is the account type Play requires, and it sits upstream of identity verification rather than beside it.

Both Play Console Requirements articles are live at the same time

This matters operationally, because a reader who lands on one of them can reasonably believe they have read the policy.

The current article (answer 10788890) carries a banner reading "Changes are coming to this article This article will be updated with recently announced changes." — sitting directly above the registration paragraph and the "(effective September 30, 2026)" marker that are already published in its body. Its bottom navigation lists both "4 of 5 - Play Console Requirements" and "5 of 5 - Preview: Play Console Requirements". The preview article describes itself as previewing "changes included in our July 2026 policy updates" and points back: "To view the current 'Play Console Requirements' article, visit this page."

And the current article states its own precedence rule, which is the useful sentence to carry away from all of this:

"Disclaimer: Policy summaries and Key Considerations are overviews only; always refer to the full policy for compliance. The full policy takes precedence in case of conflict."

Read both. On 10788890 and 17125096, the date you can pin either article to is the date you open it.

Google's own pages are moving while you read them

Three measurements from 2 September 2026.

The Timeline and the news section on the same page describe the same item in two states. The Timeline row above lists "Developer APIs, limited distribution accounts, and power user advanced flow launch" under the milestone "August 2026". Further down the same page, under Latest News: "Limited distribution accounts are now available", with the sub-line "Learn how students, teachers, and hobbyists can share apps with up to 20 devices without a government-issued ID or registration fee."

The rollout of verification access is described in a relative timeframe with no anchor. A Latest News card reads "Rolling out to all developers on Play and Android consoles", and under it: "Over the next few weeks, we're opening the verification process to everyone through Android Developer Console and the Play Console." The card carries no publication date.

One page in this set carries a date of its own. developer.android.com/google/play/requirements/target-sdk prints "Last updated 2026-08-14 UTC." at its foot.

The conclusion an engineer can act on is the same in all three cases: the state of your account and your packages is a thing Play Console reports, and a published page is a description of the programme rather than a report on your apps.

Two more obligations sit on the same release

Named here, not covered here.

Target API level. Play Console Help, Target API level requirements for Google Play apps (answer 11926878), checked 2 September 2026:

"Starting August 31, 2026: New apps and app updates must target Android 16 (API level 36) or higher to be submitted to Google Play; except for Wear OS, and Android Automotive OS apps, which must target Android 15 (API level 35) or higher, and Android TV and Android XR apps, which must target Android 14 (API level 34) or higher."

That date is behind us. It is a live submission gate, and it is a separate obligation from package registration.

The Data safety declaration. A separate obligation on the same release, and the one that turns on what the binary and its SDKs actually do.

Package registration, the target API level gate and the Data safety declaration are three different obligations that land on one release.

The build and the console

Registration is an action taken in Play Console by the account that holds the app. Google Play adjudicates it.

What an assessment reaches is the other artefact in the same release — the build. The published scope of ours on Android is the APK retrieved, decompiled and analysed for hardening posture — obfuscation, anti-debug, anti-tamper, certificate pinning and protected storage; component mapping across activities, intents, providers, services, schemes and deep links; and Android hardening — Keystore misuse, root detection, intent abuse, manifest exposure. Security Brigade has been CERT-In empanelled since 2008, with 693+ mobile application scopes assessed.

A penetration test and a Play policy requirement are different obligations on the same release. If you want the build looked at, the number is +91 22 4164 2220.

If you are reading this now

Four things, in order.

1. Complete identity verification in Play Console, because that is the condition Google attaches to receiving notifications about the registration status of your apps.
2. Open Play Console Home and read the registration status of every package you ship — including the ones nobody has released this year, and the ones distributed outside Google Play.
3. Establish who holds the signing key for every package in that list — in house, at an agency, or inherited.
4. For anything the eligibility rules leave to a request, submit the request, and treat the answer to "which key holds the installs" as something to establish rather than assume.

The date on the registration sentence is 30 September 2026, and it was checked on 2 September 2026.

Check Play Console.

Every quotation above was read from the Google page it is attributed to — developer.android.com/developer-verification, Play Console Help answers 16984799, 10788890, 17125096 and 11926878, and developer.android.com/google/play/requirements/target-sdk — on 2 September 2026.