Android's September deadline is a fire drill in four countries. Find your signing key anyway.
Enforcement on 30 September hits seven stores in Brazil, Indonesia, Singapore and Thailand. Not sideloading, not other stores. But registration is bound to your app signing key, and Google's FAQ says a lost one can't be recovered.
There's a version of this story going around that says Android is closing. Sideloading is dead, the open platform is over, verify or disappear. I went and read Google's own developer verification pages this week, because Murror ships on Android and I wanted to know what I actually had to do before the end of the month. The docs say something narrower than the panic, and in one specific place something worse.
Start with what happens on 30 September.
Enforcement begins for users installing from participating stores — Google Play, HONOR App Market, OPPO App Market, Galaxy Store, Palm Store, V-Appstore and GetApps — in Brazil, Indonesia, Singapore and Thailand, on certified devices running Android 7 or higher. If you haven't verified your identity and registered your apps by then, they're blocked from installation for users in those regions.
Now what doesn't happen, because this is the part the coverage flattens. Google's FAQ is explicit: the deadline applies only to those specific participating stores. Distribute through a store that isn't on the list, or let users sideload your APK directly, and the requirements don't apply to your app yet. ADB installs are unaffected and stay that way. Enterprise apps on managed devices are out of scope. Outside Play, enforcement covers mobile and tablet form factors only.
The global rollout — all apps, all certified devices — is 2027.
So for most people reading this, September is a fire drill happening in four countries. That's the honest read, and I'd rather hand you that than manufacture urgency.
Here's the part I'd actually act on this month, and it has nothing to do with the date.
Registration is bound to your app signing key. And the FAQ says it plainly: if you lose your signing key, you won't be able to register your packages. No recovery path. That's the entire answer.
Sit with what that means for a small team. Registration isn't a form you fill in later, it's a claim you prove with a key. If your keystore lived on a laptop you replaced in 2023, if it's in a shared drive nobody has opened since, if the contractor who set up the build is gone — then you don't have a September problem or even a 2027 problem. You have an unfixable one you haven't found yet. And the deadline that would surface it is a year away, which is precisely long enough for checking to never become this week's job.
If you use Play App Signing you're fine; Google says eligible apps are claimed automatically, and 99% of Play apps get registered without anyone lifting a finger. This is a warning for everyone else. Apps distributed outside Play, old projects, anything you signed yourself.
Three more details that surprised me.
Updates break, not just installs. Unregistered apps can only be installed or updated when the user has the advanced flow enabled, or over ADB. So the failure mode isn't "new users can't get it." It's "the users you already have stop receiving fixes."
The free tier is a one-way door. Limited distribution accounts, for students, teachers and hobbyists, need no government ID and no fee, but cap you at 20 devices. You can migrate a limited account up to full. You cannot go back down.
The advanced flow is deliberately slow, which quietly kills it as a distribution plan. For a user to install from an unverified developer they have to turn on developer mode, pass a check that nobody is coaching them, restart and reauthenticate, wait a one-time 24-hour period, then confirm with biometrics or a PIN. That's designed so a scammer can't talk a victim through it on a live call, and as safety design it's genuinely good. It also means "power users will just sideload it" has stopped being a strategy you can lean on. There is now a one-day wait and a warning screen between your app and its most motivated user.
One more if you're a company rather than a person: registering as an organisation needs a D-U-N-S number, and Google says obtaining one can take up to 28 days. That's the item with a real lead time.
What I'd do this week, and it's twenty minutes.
Find your keystore. Actually open it — don't just remember roughly where it is. If you can't, that's the finding, and you'd much rather have a year to solve it than a month.
Check your registration status. It's in Play Console next to each app, in Android Developer Console under Package names, or in Android Studio when you generate a signed bundle.
If you distribute outside Play at all, note the $25 full-distribution fee on the Android Developer Console, waived for limited accounts.
And if you're an organisation, start the D-U-N-S now. Twenty-eight days is the kind of number that eats a deadline quietly.
The Murror version of this is unglamorous: we're on Play with Play App Signing, so mechanically it costs us nothing, and I nearly skipped reading any of it for exactly that reason. What made me glad I didn't was the key clause — not because it's our exposure, but because it's the shape of risk I'm worst at noticing. A requirement whose prerequisite is something you were supposed to have kept safe two years ago, with a deadline far enough out that checking never becomes urgent until it's too late to fix.


Replies
The D-U-N-S timeline caught my attention. A 28 day lead time is easy to miss if nobody on the team own that process.
Murror
@johanna_john1 That one has no owner by default, which is exactly why it slips. It's not an engineering task, it's not really legal either, so it sits in the gap between them until someone hits the wall. If you're an org, my only advice is to start it this week even if you're not sure you'll need it — 28 days is Google's own upper bound, and it costs you nothing to have it sitting there.
@monatruong_murror Exactly. It is the kind of task that can easily get missed because nobody clearly owns it. Starting early seems much safer than waiting until it becomes urgent.
Murror
@johanna_john1 If it helps: the cheapest way to give it an owner is to make it a purchasing task rather than a compliance one. It's a number you request from Dun & Bradstreet, it costs nothing on the free path, and whoever handles your invoices and company registrations already speaks that language. Framed as "we need a D-U-N-S for an app store requirement" it takes ten minutes to start; framed as "someone should look into Android verification" it sits for a month.
the advanced sideloading flow sounds intentionally inconvenient. i can see why that improves safety but it also changes practical direct distribution is.
Murror
@uttam_kumar31 Yeah, and I think the inconvenience is the feature rather than a side effect. The 24-hour wait exists specifically so nobody can walk a victim through it on a phone call, and that's hard to argue with. What it costs is a distribution path a lot of small teams quietly relied on. "Our power users will just sideload" was never a real plan, but it was a comforting one, and now there's a warning screen and a day's delay sitting in front of it.
@monatruong_murror The 24 hour delay definitely changes the equation for smaller teams. Sideloading used to feel like a simple backup option but now it comes with enough friction that it needs to be planned for.
Murror
@uttam_kumar31 The way I'd plan for it is to stop counting it as a channel. A path with a 24-hour wait and a scary screen in front of it isn't distribution, it's a support escape hatch for maybe a dozen people a year - useful for a beta tester or someone in a region you don't ship to, useless as a plan B if a store relationship goes wrong. The teams that used to say "we can always sideload" were mostly using it as insurance against a store review going badly, and that insurance has quietly lapsed. Worth noticing before you need to claim on it.
i would be interested in hearing how many developers actually know where their signing key is today. that might be the most useful test of this whole change.
Murror
@joseph_collins2 I'd bet the honest number is uncomfortable. My guess: most people can name the machine it was on, fewer can open it today, and the gap between those two is where the whole risk lives. The test I'd actually run is not "do you know where it is" but "can you produce a signed build from it this afternoon, without asking the person who set up CI."
@monatruong_murror The second test is much more realistic. Knowing where the key is does not help much if nobody can actually use it when needed.
Murror
@joseph_collins2 Right, and there's a third level under it that's worse: whether anyone can use it without breaking something. Plenty of teams have a key that technically works but lives in one person's CI secrets, so producing a build means that person is available and remembers the passphrase. That's not a lost key, it's a key with a single point of failure attached, and it fails the same way at the same moment. The version of the test I'd run is: someone who didn't set it up produces a signed build, today, from what's written down.