Six days from now, on September 30, Android starts checking who made your app before it lets someone install it. Not the store. The phone.

The first wave is four countries: Brazil, Indonesia, Singapore, and Thailand. On certified Android devices there, an app has to be registered to a verified developer or the normal install path refuses it. It applies to installs from Google Play and from the other participating stores: Samsung Galaxy Store, Xiaomi GetApps, OPPO App Market, vivo V-Appstore, Honor App Market, and Transsion Palm Store. In 2027 it expands to every certified device everywhere.

I build Flutter apps that end up on Play, and I had a vague sense this was coming. What I did not have was a clear picture of whether I needed to do anything. So here is the picture.

Most Play apps are already registered

Google says 99% of apps on Play have been registered automatically. If you publish through the Play Console and your developer account is already identity-verified, which it has been required to be since 2023 for new accounts, your apps were most likely registered without you touching anything.

“Most likely” is not “yes.” The Play Console home page now has a section for this. Open it and look. If anything shows as not registered, register it there. That is the entire check, and it takes less time than reading this post.

What is actually being registered

Two things per app: the package name, and the SHA-256 fingerprint of the key that signs the build users install.

The second one is where a Flutter developer can get confused, because there are two keys in the picture. If you use Play App Signing, which every new app has for years now, you sign your upload with an upload key and Play re-signs it with an app signing key it holds. The fingerprint that matters for verification is the app signing key, the one on the APK that actually lands on the phone. Play handles that mapping for you when it auto-registers. It only becomes your problem if you distribute the same package outside Play with a key Play does not know about.

This is the same three-piece matching problem I wrote about on the Apple side in certificates, identifiers, and provisioning profiles. Identity, app ID, signing key. When one of the three does not match what the platform expects, the failure shows up somewhere that looks unrelated.

Distributing outside Play

If you ship an APK from your own site, or to a client's own devices, or through a store that is not on the list, you register through the Android Developer Console instead. That is a separate flow from the Play Console, with an identity check and a signing key registration of its own. If you are on both Play and outside it, the Play Console path covers both.

There is a new account type for people who do not want to hand over government ID: limited distribution accounts. No ID, no fee, and a hard cap of twenty devices. That is for students and hobby projects, not a workaround for shipping.

What still works without verification

adb install is untouched. Local development, running on a test device from your machine, CI that pushes to an emulator, none of that changes. You are not verifying yourself to debug your own app.

There is also an “advanced flow” for users who want to install an unverified app on purpose. Google describes it as having friction designed to resist coercion, which is a polite way of saying it is built so a scammer on the phone cannot talk someone through it. I would not build a distribution plan on top of it.

What I am doing

Checking the Play Console for the apps I have access to. Reading the section instead of assuming the auto-registration got everything. For the Flutter game that had to run on Android TV, confirming the TV build shares the package name and signing key of the phone build, because that is exactly the kind of second variant that is easy to forget.

None of this is hard. It is only dangerous if you do not know it is happening, and on September 30 the first users in four countries will find out for you.

Sources: Android Developers, “Android developer verification.” Android Developers Blog, “Android developer verification: Building a safer ecosystem together,” June 2026.