Android Developer Verification: What Is Enforced and Who Owns Your App

If you own an Android app, someone may have told you that Google is closing sideloading, and you may be wondering whether your app is about to stop installing. Android developer verification is the policy behind that headline. It has been enforced in four countries since September 30, 2026, and Google says it will expand globally in 2027. Whether it affects you depends less on your code than on two things most teams never write down: who owns the developer account, and who holds the signing key.

Below is the state of the rollout as of October 4, 2026, from Google's developer documentation: what is enforced, what is not, and five things to settle before it reaches your market.

What is enforced today

Since September 30, 2026, on certified Android devices running Android 7 or later in Brazil, Indonesia, Singapore and Thailand, an app installed or updated through a participating store must have its package name registered to a verified developer. Certified means devices with Google Play Protect. The check is delivered through Google Play services, and sanctioned countries are excluded.

Seven stores participate:

• Google Play
• HONOR App Market
• OPPO App Market
• Samsung Galaxy Store
• Transsion Palm Store
• vivo V-Appstore
• Xiaomi GetApps

Registration has two halves. The first is identity. An individual provides a government photo ID, proof of address and an email address and phone number verified by one-time code. An organization provides a D-U-N-S number, an organization website verified through Google Search Console, and official organization documents.

The second half is the app: its package name, linked to the SHA-256 fingerprint of each certificate it is signed with. For a new package name the public certificate is enough. For an existing one you prove ownership by uploading an APK, signed with the private key, that contains a small adi-registration.properties file Google gives you. Several signing keys per package are allowed.

Google announced the requirement in August 2025 and opened registration to all developers in March 2026. For the rest of the world it says only that it will expand globally in 2027 and beyond. No day has been published; anyone quoting one is guessing.

What it does not block

"Google is ending sideloading" overstates what happened on September 30. Four routes still work:

• adb. Installing over USB with Android Debug Bridge needs no verification and has no waiting period. Developer machines, QA devices and test rigs are unaffected.
• The advanced flow. Since August 2026 a user can allow unregistered apps on their own phone: turn on Developer Mode, confirm nobody is coaching them through it, restart, wait 24 hours, authenticate, then allow it for seven days or indefinitely. Google says no adb command skips the wait.
• Managed devices. Google's Android Enterprise help says enrolling devices in EMM or MDM management (fully managed or work profile) exempts them, though Google recommends registering anyway.
• Installs outside the participating stores. Google's FAQ says other stores and sideloading are not affected until the global rollout.

An unregistered app can only be updated with the advanced flow on or over adb; otherwise the update fails. Whether one already on a phone keeps launching, Google's pages do not say.

Google: Android developer verification FAQ

Play apps versus apps distributed outside Play

If your app is on Google Play, most of the work has been done for you. Google says over 99% of Play apps were registered automatically, and that for most Play developers the identity verification they already completed counts. Apps that use Play App Signing are claimed automatically, because Google holds their signing key.

Most is not all. Play Console's policy deadlines page asked developers to register any remaining apps by September 30, 2026, or risk removal from Google Play worldwide. That consequence is not limited to the four countries. The date has passed, so open the verification page in Play Console and look for anything not marked Registered. What exactly triggers removal, and whether there is a grace period, is not documented.

If you distribute only outside Play (an APK on your website, Firebase App Distribution, another store), the path is the Android Developer Console. Full distribution there costs USD 25 according to Google's FAQ, requires the identity checks above, and allows unlimited apps and installs. That fee is stated for the Android Developer Console only; nothing we read says Play developers pay anything extra.

Google says verification takes about ten minutes if everything is ready. The slow part is the D-U-N-S number: it is free from Dun & Bradstreet, but Google warns it can take up to 28 days.

There is also a free limited distribution tier for students and hobbyists: no ID and no fee, but sharing is capped at 20 explicitly authorized devices and the tier is for non-commercial use. It is not a home for a business app.

Apps distributed both on and off Play register through Play Console. Teams with many packages can check status and register in bulk from CI through the Developer ID Status API and the Android Developer Console API.

None of this depends on how the app is built. Registration binds a package name, a certificate and an identity, so Kotlin, Flutter, React Native and Swift on Android apps are treated alike. Google does not say so explicitly; it follows from the mechanics.

Swift on Android in 2026: a real option beside Flutter, React Native and KMP?

Who owns the account and the key

This decides whether you can keep shipping, and Google's verification guides do not cover agency accounts. What follows is our inference from the mechanics, not Google guidance.

A package name is bound to the verified identity of the account that registers it, and Play registers a package to the account that created the app. So if an agency published your app from its own account, the app is registered to the agency, not to you. Change agencies or bring development in-house and you need that package moved, and the verification documentation does not describe how a package moves between developers.

Google does document what happens when several developers claim the same package name. The key behind more than 50% of installs gets priority. Keys with 50 or more installs are eligible. Below 50 installs it is first come, first served, and anyone else files a request that may be rejected. That is a dispute process, not a handover.

The signing key is the other half. With Play App Signing, Google holds the app signing key, so whoever controls the account controls registration. For an APK you sign yourself and distribute directly, the key is the proof of ownership, and Google is explicit that a lost signing key cannot be recovered: the way out is a new package name or a request for review. A key that lives on one developer's laptop is a business risk. To see which certificate signed an APK you have:

# Prints each signer's certificate digests,
# including the SHA-256 Google asks for
apksigner verify --print-certs app-release.apk

What we recommend to clients:

• Publish from a developer account your company owns, as an organization with your own D-U-N-S number, and invite the agency (us included) as users.
• If an agency account is unavoidable, put a written transfer plan in the contract.
• Know where every signing key lives and who can use it: a CI secret store or hardware security module, with a copy your company controls.
• If your app already sits under an agency account, raise ownership now, while the relationship is good.

Key custody is one part of a wider security question we cover, from the iOS side, here:

iOS app security for businesses: what actually protects your data

What the critics say

F-Droid, the open source Android store, has campaigned against the requirement from the start. Marc Prud'hommeaux of F-Droid's board formalized the Keep Android Open campaign in late October 2025, and on February 24, 2026 F-Droid published an open letter against it, backed by organizations including the EFF, the Free Software Foundation Europe and the Software Freedom Conservancy. Sources disagree on how many signed, so we give no count.

F-Droid argued the advanced flow would not arrive before enforcement; it launched in August 2026, ahead of the deadline.

In Brazil, complaints about the requirement reached the competition authority CADE before September 30, according to the legal news service MLex, and some asked for it to be suspended. Enforcement went ahead on schedule, and as of October 4, 2026 we found no report of a suspension.

Google's case is security. It says sideloaded sources carry over 90 times more malware than Play, and that the friction is meant to disrupt scams where someone pressures a victim into installing an app. That figure is Google's claim; we have not seen the data behind it.

How this compares to Apple's model

Apple has long required a verified developer identity and a signed app, and in the EU apps distributed outside the App Store still pass through Apple's notarization. Android is moving toward identity: verification records who published an app and with which key. Google's documentation does not describe a review of what the app does. Android also keeps its exits (adb, the advanced flow, enterprise management) and seven participating stores rather than one.

If you ship on both platforms, the distribution decisions now rhyme. Our guide to Apple's EU routes covers the other half.

Apple's new EU App Store terms: which distribution route fits your app

What this cannot tell you

Some questions have no public answer yet:

• The global date. Google says 2027 and beyond, nothing more precise.
• Whether the global phase covers sideloading in the same way. Google says only that it will expand globally.
• Whether unregistered apps already installed keep launching. Google's pages speak of installs and updates.
• How a package moves from one developer account to another, and anything agency-specific.
• What triggers removal from Play for an unregistered app, and whether there is a grace period.
• Whether an organization also needs a personal ID, and whether the USD 25 fee differs between organizations and individuals.
• Real-world impact: four days in, we found no data on failed installs.

We paraphrase Google rather than quote it. Check the live page before acting on a detail.

Android Developers Blog: Android developer verification, June 18, 2026

A practical checklist before your market's date

The five things to settle, in the order we would do them:

1. Inventory. List every package name you ship, where it is distributed, and which developer account owns it, internal apps included.
2. Check registration. In Play Console's verification page, confirm every app shows Registered. For apps outside Play, open an Android Developer Console account and register each package with the SHA-256 fingerprint of every key it is signed with, including any key a store re-signs with.
3. Start the identity paperwork now. Request a D-U-N-S number, which can take up to 28 days, and verify your organization's website in Google Search Console.
4. Settle ownership and keys. Move apps to a company-owned organization account or put a transfer plan in writing, and record where each signing key lives and who can reach it.
5. Check internal apps and test devices. Enroll company phones in EMM or a work profile, or register the internal apps you send to unmanaged phones. Keep using adb for QA, and tell testers that it still works.

For most Play apps this is an afternoon: confirm the status, confirm the owner, write down where the key lives. For apps outside Play, or under someone else's account, it is a project with a 28-day lead time. Start it before your country's date is announced.