跪拜 Guibai
← Back to the summary

Google's New Developer Verification Will Block Unregistered Apps from Installing on Android

I can't remember exactly which day it was recently, but one evening I was reading an article.

I had originally intended to glance at the latest Material 3 Expressive documentation, but Chrome's homepage on my phone pushed a blog post: Android Developer Verification. I subconsciously assumed it was another minor notification like a "Play Console redesign."

But after actually reading it, I realized—Google, what are you doing?

1. What Exactly Did Google Do This Time

Let me restate the skeleton of that announcement in words I can understand.

On September 30, 2026, Google will roll out a new developer verification mechanism. Simply put:

Note the keyword: distribution. This new rule doesn't just govern the Play Store; it governs "all apps."

57f051f14d51f637.png

The first batch of markets to land are 4 countries: Brazil, Indonesia, Singapore, Thailand.

The first batch of "cooperating" app stores includes 7:

—Yes, 5 of them are Chinese manufacturers. Google calls this "industry-wide collaboration."

But fortunately, according to the announcement, starting in 2027, this mechanism will expand to all Android devices certified by GMS.

In other words, current domestic manufacturers probably won't rush into this yet. But the question is, how long can they hold out?

Sooner or later, the phone in your hand will also be included in this "verification."

The next day, I shared this news with a colleague, and he asked me: Why not buy an iPhone?

Hmm, that makes some sense!

2. The "Surface-Level" Reasonableness

Writing this far, I have to pause for a moment. I personally feel, just a tiny bit: Google's argument is not completely unreasonable.

In the announcement, Google said this mechanism is to "prevent malicious developers from using anonymous identities to release harmful apps."

Does that sound reasonable? It does sound reasonable.

Think about it: those apps that install remote trojans on your phone in the middle of the night, disguise themselves as "Clean Master," and forward your payment SMS messages—the developers behind them are often registered anonymously. They change their alias, change their signing certificate, change their country, and they're back in business.

You can't catch them!

If opening an app store becomes like opening a bank account—you have to provide ID, sign an agreement, leave a record—then the cost of anonymous wrongdoing will indeed be higher.

As a developer, I admit: this layer of logic has no flaws at all.

Throughout the entire process of writing this article, I never intended to deny that.

But—

Acknowledging it's reasonable does not mean acknowledging its specific implementation is correct.

3. A Few Details

68ee818adf5cfe4d.png

Google said one thing in the announcement:

"Advanced users will still be able to sideload apps from unverified developers."

Sideloading is the two most valuable words in Android's decade-long history. It refers to "installing software directly onto a device without going through an official app store"—downloading an APK from a website, a friend transferring a tool via a USB drive, internal apps distributed within a corporate network, all belong to sideloading. Sideloading is the most substantial difference between Android and iPhone, and the true meaning of the word "open" on Android.

So what does the "sideloading escape hatch" Google left for advanced users look like? You wouldn't know until you read it; I thought the developer had committed some crime:

  1. Open system settings
  2. Tap the version number seven times consecutively to enable developer mode
  3. Dismiss the "confirm you are not under duress" prompt
  4. Enter the device's PIN
  5. Restart the device
  6. Wait 24 hours
  7. Go back to settings, dismiss the prompt again
  8. Choose "Allow temporarily (7 days)" or "Allow permanently"
  9. Confirm again that you understand the so-called "risks"

—Just to install a sideloaded app on a device you already paid for, you need to perform nine steps, plus a mandatory 24-hour cooling-off period.

A cooling-off period, what a familiar phrase.

I wonder if anyone remembers the process of unlocking the bootloader back in the day, where you even had to write an application first!

There's one detail about this process: it's not managed by the Android system itself, but by Google Play Services.

Google Play Services is a closed-source service Google installs on certified devices. It is not the Android system itself; Google can update, tighten, or abolish it at any time, without needing to push a system update to users, and without needing user consent.

As of the time I'm writing this article—this "advanced process" has not yet entered any beta, preview, or canary version. It currently only exists in a Google blog post and a few mockups.

As a developer, I feel a slight sense of discouragement.

9 steps + 24h + buried in developer options + dependent on a closed-source service that can be shut down at any time—with these four conditions combined, ordinary people simply cannot complete this process.

Those who can complete it are "advanced users" with a purpose, motivation, and a bit of tinkering ability—and Google is betting precisely that the proportion of this group will be small enough not to worry about.

I have to add one thing: this design has a specific name in product language, called a Dark Pattern, and it's a feature.

4. Who Gets Hurt

Who exactly does this thing "hurt"?

A "professional developer" like me—I will eventually register, because if I don't register, I can't publish apps, and without registering, subsequent device testing will also be a big hassle.

Although I'm not a Google-registered developer right now, registration only costs $25, which isn't a problem for me. This step is just a procedural hassle for me.

So the damage to me isn't that great. Most of the projects I'm currently working on are based on AOSP development, so it has almost no impact on me.

The ones who really get hurt are the following:

1. Small tools shared between friends

Last week, my cousin asked me on WeChat: "Can you send me that flashcard app again? I reset my phone." — This kind of "flashcard tool, self-written, sent to three or five friends" happens frequently every day. In the future, this path will become increasingly difficult.

2. Apps written for elders in family scenarios

Last year, I wrote an app for my grandmother that "calls me when pressed and held," and I just threw the APK into the family group chat. After 9.30, for safety's sake in the future, I would need to first register a Google developer account, submit ID documents, sign an agreement, and pay a fee, just so my grandmother's phone can install the app I wrote for her.

3. Internal test builds on corporate networks

This is what I feel most deeply; the previous two scenarios aren't that frequent for me personally!

This is even more common in development circles: internal test builds don't go through the Play Store; the APK goes through an internal CI pipeline, and then testers scan a code to install it on their machines.

After this, every test device must first go through that 9-step process, plus a 24-hour cooldown. One build produces 30 machines; just gathering the devices that have "cooled down" becomes a project in itself.

4. Open-source apps on F-Droid

If you don't know F-Droid, simply put: it's the world's largest free and open-source Android app store, containing thousands of fully open-source apps—no ads, no tracking, no background data collection.

F-Droid officially issued a public statement in September 2025^1, the original words were:

This policy poses an existential threat to F-Droid.

The vast majority of F-Droid's developers are individuals or small teams—they make unpaid contributions, apps whose source code can be reviewed line by line, and they don't ask anyone for ID documents.

After 9.30, these apps will be blocked by default by the same "unverified means uninstallable" mechanism.

This is a truly fatal blow!

5. ID Cards

The EFF (Electronic Frontier Foundation) had a comment in November 2025^2:

Using ID documents as a gatekeeper is not a security measure; it's a means of censorship.

5. But Isn't the iPhone the Same?

At this point, a rational person would ask: But isn't the iPhone the same? Hasn't Apple always prohibited sideloading?

This brings up the most ironic piece of news I've seen:

Starting in 2024, the EU, through the Digital Markets Act (DMA), forced Apple to open up sideloading. Within the EU, Apple was forced to allow third-party app stores, non-WebKit engines, and sideloading. Apple is complaining verbally, but its body is already implementing this policy.

So what about Google?

Apple was forced to move from closed to open; Google is proactively moving from open to closed.

Once this "reverse locking" is implemented, the most terrifying thing is the subsequent impression:

If Google can retroactively lock down devices already sold... forcibly update their "app installation rules"... hardware manufacturers worldwide will know: this is permitted.

Phone manufacturers, PC manufacturers, smart home manufacturers, car infotainment manufacturers—every one of them could, in some "security upgrade," quietly add "unregistered apps are not allowed to be installed."

Android's openness has never just been Android's own business.

It is the most prominent battleground for the principle that "consumer electronic devices are controlled by the user."

Whether Google's update will be written down as the "starting point of the consumer electronics 'walled garden'"—I dare not draw a conclusion. But as someone who has written apps on Android for 13 years, for the first time, I feel Android is no longer open!

Ars Technica gave this event a name: Google envies Apple.

6. What's the Community's Reaction

There are people in the community who are really doing things, and have been doing them for a while.

After Google announced the policy in August 2025, a group of organizations took the lead and published an open letter^3.

As of now, this open letter has been co-signed by 71 organizations from 23 countries, some of which you might have heard of:

Cory Doctorow (science fiction author, writer of Little Brother) gave this event a nickname, calling it "Darth Android"—"Dark Android." He wrote an article called Fulu^4, describing Google's strategy as "systematically, premeditatedly, and irreversibly" shutting down Android's openness.

There is a joint petition on change.org^5 that has already surpassed 100,000 signatures.

The community's advice for ordinary users:

Get F-Droid installed on all Android phones.

Only when people use it heavily can alternative app stores survive.

The community's advice for developers:

Do not register a developer account.

Do not register an Android Developer Console, do not sign Google's irrevocable terms, do not verify your identity.

Google's plan can only succeed if developers cooperate. Therefore, do not cooperate.

7. Some Thoughts

00.png

There's still some time before 9.30.

Writing this far, I suddenly don't know what kind of "conclusion" to use to end this article.

Regarding the community's feedback above, I can only say: obviously, the arm can't twist the thigh!

But there's one thing I have to say.

Last year, AOSP also made big news—Google moved the core development of AOSP behind closed doors; the public repository could only get "released" versions, and the real-time development of the master branch could no longer be seen. The community exploded at that time too. I discussed it with a few friends, and we all finally said, "It probably won't come to that."

And now this year, this happens again.

I'm not mourning for Android; I myself still have to write code on Android, make apps, and make a living—but the word "open," Google, have some shame.

That's all!