Android on Trevor's Blog

My Google Play Account Got Banned, So I Opened a New One

Tue, 20 Oct 2026 10:49:18 +0800

Before you register, work out how you lost the last one

The day my account got banned, my first reaction was the same as yours: register another one.

But after going through the official docs I realized reopening is not a process problem at all. It splits into two cases, and the outcomes are very different.

The first is dormancy. If an account goes a long time without publishing updates, checking stats or managing store listings, Google deactivates it. The help center says: after a dormant account is deactivated, you can still create a new account and publish on Google Play later. For that kind of account, reopening is routine.

The second is termination for violation. The same article says: if you repeatedly or seriously violate these policies or the developer distribution agreement, your developer account or related Google Play developer accounts may be terminated.

Pay attention to the words “related”. Another page puts it more bluntly: multiple warnings may lead to termination of the individual account and related Google Play developer accounts.

So the real question is not “how do I reopen”. It’s “will the new one survive”.

Why I still picked a personal account

When you reopen, the account type step matters more than it did the first time.

An organization account needs a D-U-N-S number, organization registration documents, and the authorized representative’s ID, and all three have to line up with each other. A D-U-N-S application can take up to 30 days. The account is already gone; waiting another month is too slow.

A personal account needs one government-issued photo ID. Fewer documents, fewer places to get it wrong.

But don’t pick it just to save effort. There’s an official list: financial products and services, health apps, apps using VpnService, and government apps. Those four categories must use an organization account. If your app touches any one of them, a personal account won’t show the problem up front, but review will kick it back later anyway.

The six steps to reopen

Order matters here, especially step two. Step one is getting the Google account ready. Use a clean one, not an account that already registered another developer account, and don’t buy one.

Step two: go to Google Payments first and create a payments profile. Country/region China, legal name and address exactly as printed on your ID. You can’t skip this and can’t bolt it on later.

Step three: register a developer account in Play Console with that account and pay $25. Cards accepted are MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US). Prepaid cards are not accepted.

Step four: choose a personal account.

Step five: identity verification, submitting a government-issued photo ID.

Step six: device verification. Find a real Android 10+ phone that isn’t rooted, install the Play Console mobile app, scan the QR code. The docs say this takes a minute.

Why can’t you skip ahead? Phone verification comes after identity and device verification. Finish the earlier steps or the phone verification entry point never opens for you.

After approval, the home page looks like this

The day verification passed I got into Console and the first look is a letdown: 0 apps in production, 0 apps with policy tasks, 0 apps with publishing submissions. Three cards, all zeros.

That’s correct. Passing only means you can create apps now. It doesn’t mean an app can ship. The real starting point is that “Create app” button in the top right.

Two things on this page are worth noting. In the row of buttons at the top there’s “Policy status”, and account reputation problems show up there first. In the list below, anything tagged Draft is an app you created but haven’t submitted for review. That green banner in the middle is just a Play redesign notice and has nothing to do with your account status.

The address section ate most of my time

Last time I filled the address in without thinking. Not this time.

The docs say this on the required documents by country page, and I copied it down:

All documents you submit must match the information in your payments profile exactly, including personal identity details, organization name (for organization accounts), and address information. If you find any discrepancy between your documents and your payments profile, you can update the payments profile information during the verification task.

That sentence explains why most people get rejected. Verification is not checking whether your documents are complete. It’s checking whether they match what you typed in yourself.

Three lines have to match character for character.

Name: if the ID is in Chinese, write it in Chinese. Don’t write “张伟” in one place and “Zhang Wei” in another.

Address: the address in the payments profile is the legal address, and the country/region Play displays publicly is based on it. If the ID says “3号楼502, XX路128号, XX区” and you only wrote “XX路”, that counts as a mismatch. Province, city, district, street, building, unit — write down as many levels as you can.

Documents: four hard requirements. Valid and unexpired, color not black and white, clearly legible with reasonable exposure, and not a photocopy.

If you’ve already been rejected you don’t have to register again. The second half of that same sentence says you can update the payments profile during the verification task, fix the address to match the ID, and submit again.

How to keep the new account from getting dragged down

This is the part I most wanted to get right, because there’s no trick to it. Only facts.

When Google says “related developer accounts may be terminated”, it means Google looks at whether a set of things are the same: the same person, the same payment card, the same device, the same batch of package names, the same payout account.

Open a new account and carry all those traces over unchanged, and you’ve raised your hand to say “still me”.

What actually reduces risk is the reason the original account was banned being not that serious, or the appeal already settled. For serious violations like malware or fraud, ten new accounts won’t help. Reopening in that situation means the $25 is gone and the account gets banned again.

Put bluntly, that phrase “related developer accounts” exists specifically to close this door.

Before you submit, check the files locally

Two of the four photo requirements can be checked right on a Mac: is it color, and is the resolution high enough. The built-in sips tool does it, nothing to install.

sips -g pixelWidth -g pixelHeight -g space your-id.jpg

Look at the space line. RGB means color. Gray means black and white, and a black and white image will always be rejected. If the short edge is under 1000 pixels, retake it: images passed through WeChat often end up only a few hundred pixels.

I wrote a small script to chain both checks, and the output looks like this:

id-color.png        1600×1000  space=RGB   ✓ pass
id-gray-small.png   640×400    space=Gray  ✗ short edge 400px  ✗ grayscale

One last honest word

With reopening, the documents and the process are secondary. What comes first is always why the last account died.

Dormancy deactivation: just walk the six steps above. Termination for serious violation: don’t count on a new account turning the page. Fix the problem first, then talk about registering.

Have you reopened one? Which step did you get stuck on? Comments welcome.

Google Play Registration: Your Address Has to Match Your ID

Tue, 20 Oct 2026 10:00:45 +0800

The most common rejection is not missing paperwork

Someone asked me again last week what to do about a rejected Play developer account. Going through his materials: ID photographed, card linked, the $25 charged successfully. The problem was the address — his card’s billing address was the office, the address on his ID was his hometown.

There are plenty of Chinese tutorials on the registration flow. Almost none cover address alignment, even though Google puts this front and center in its help center.

In Google’s own words

All documents you submit must match the information in your payments profile exactly, including: personal identity details, organization name (for organization accounts), and address. If you find any discrepancy between your document and your payments profile, you can update the payments profile while the verification task is in progress.

Right after that comes a line about why it fails:

Submitting unsupported documents is the leading cause of developer verification failure, and providing altered or forged documents can result in immediate removal of your account and apps.

Those two sentences lay the rule out completely: verification is not about whether you have documents, it is about whether what you submit matches what you entered. If it does not match, complete paperwork is still wrong.

A lot of people think the address is just a field you fill in on the signup form. It is not.

Play’s legal name and legal address come from the Google payments profile attached to your account. In other words, the address you store in Google Payments is what actually gets compared against your ID. The country and region shown publicly on your Play page are derived from that same legal address.

So the order is obvious: get the payments profile right first, then open the developer account. Doing it the other way plants a mine under your own review.

Three lines that have to line up

The first is the name. If the name on your ID is in Chinese, write it in Chinese in the payments profile too. If the system only takes Latin characters, pick one transliteration rule and stick to it. Do not write 张伟 in one place and Zhang Wei in another, and definitely do not spell it out in one place and abbreviate it in another.

The second is the address. Province, city, district, street, building number — go as deep as the ID goes, and match the wording character for character. If the ID says XX District, XX Road, No. 128, Building 3, Unit 502 and your payments profile says XX Road, that counts as a mismatch.

The third is the photo of the document. The four official requirements are specific: valid and unexpired, color not black and white, legible with balanced exposure, and not a photocopy. Fail any one and it counts as an unsupported document.

One item that is not in the official text but comes up constantly in practice: the billing address on the card you link should ideally be the same address. No official basis for this one, just experience. Take it as a pointer.

Six steps for registering entirely in Chinese

Step one: make a clean Google account. Do not reuse an account that already registered another developer account, and do not use a bought one. Identity verification later checks the person.

Step two: go into Google Payments and create a payments profile, set country/region to China, and enter the legal name and address exactly as they appear on your ID. The address you enter here is what every later verification checks against.

Step three: register the developer account in the Play Console with that account and pay $25. Cards are limited to MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US). Prepaid cards are not accepted.

Step four: choose the account type. Personal account, pick individual. Do not force organization just because it looks more official — organization accounts need a D-U-N-S number and company documents, and one missing item stalls you.

Step five: identity verification, submit a government-issued photo ID. For a personal account that is the only document.

Step six: device verification. Take a real phone on Android 10 or later, not rooted, install the Play Console app, scan the QR code. One minute.

You cannot skip around. Phone verification comes after these; until identity verification is done, the phone verification entry point does not even open.

Organization accounts need two more documents, with the same address alignment

An organization account needs the representative’s ID plus the organization’s registration document (a business license, typically) and a D-U-N-S number. The organization name and address on all three must match the payments profile character for character.

D-U-N-S is free to apply for on D&B’s own site, and Google specifically warns that third parties charge steep handling fees. Do not fall for it. Approval can take up to 30 days, so if you are going the organization route, start a month ahead.

Run your own check before you submit

Two of the four official photo requirements can be checked locally: whether it is color, and whether the resolution is enough. macOS ships with sips, nothing to install.

sips -g pixelWidth -g pixelHeight -g space your-id.jpg

Look at the space line. RGB means color, Gray means black and white, and a black and white image will be rejected. If the short edge is under 1000 pixels, reshoot. Compressed WeChat images are often only a few hundred pixels.

I wrapped these checks in a small script. Here it is run against two sample images:

id-color.png        1600×1000  space=RGB   ✓ pass
id-gray-small.png   640×400    space=Gray  ✗ short edge only 400px  ✗ color space is Gray

What if you already got rejected

You do not need to re-register. Google says you can update the payments profile while the verification task is in progress, change the address to match your ID, and submit again.

What is genuinely hopeless is forgery. An ID with the address edited in Photoshop, a borrowed ID, a bought business license — if they catch it, the account and apps are removed and the $25 is not refunded.

The address thing is tiny — one line of text. It is also huge, because it decides whether every verification after it passes. Did the address trip you up when you registered? Tell me in the comments.

A Google Play Developer Account: The Five Gates After the $25

Mon, 19 Oct 2026 15:38:12 +0800

Twenty-five dollars only buys the ticket

Chinese tutorials on Play developer accounts mostly stopped updating two years ago: $25, a credit card, an address, wait a day. That is no longer enough.

The help center now says: 18 or older, accept the developer distribution agreement, pay $25 by credit or debit card, cards limited to MasterCard, Visa, American Express, Discover (US only) and Visa Electron (outside the US), and prepaid cards are explicitly not accepted.

Paying the money only gets you through the door. After that comes identity verification, device verification, a closed test with twelve people over fourteen days, and the new rules that took effect September 30.

Personal or organization: pick the right one first

Play has exactly two kinds of developer accounts: personal and organization. Same features, both can monetize, both can add collaborators.

The difference is paperwork. An organization account must supply a Dun & Bradstreet number, D-U-N-S, the nine-digit business identifier issued by D&B. It is free to apply for, but you wait. There is also a list: financial services, health apps, apps that use VpnService, and government apps. Those four categories must use an organization account.

A personal account registers fast. The price is that the testing requirements below aim specifically at personal accounts.

Identity verification: the ID and the card have to be the same person

The official wording: to process the registration application, they may ask for a valid government-issued photo ID and credit card information, and the holder of both must be you. If they check and the information turns out invalid, the registration fee is not refunded.

This one gets ignored a lot in China. Paying with someone else’s card, or padding the file with a relative’s ID, both count as inconsistent information. $25 is not a lot, but you do not get it back.

Device verification: one minute, but you need a real phone

Since early 2024, a new personal account has to prove it has a real Android device before publishing anything. The method: scan a QR code with the Play Console mobile app, sign in to the same Google account, pick the developer account, tap verify.

The bar is a physical device on Android 10 or higher, not rooted. Emulators do not count, rooted devices do not count. Google says this should take under a minute, one device can verify multiple accounts, and the process does not collect the device’s phone number.

Twelve people, fourteen days

This is the one outdated tutorials get wrong most often. Plenty of articles still say find twenty testers and test for fourteen straight days. The official page now says: at least 12 testers who opted in to continuous participation in a closed test for at least the past 14 days.

The number changed and Chinese tutorials largely did not keep up. Per the current official wording, it is 12.

The rule only applies to personal accounts created after November 13, 2023. Once you satisfy it you can apply for production release access in the dashboard, and the application asks about app design, your testing process, and launch readiness.

From September 30, verification reaches past Play

This part is the genuinely new thing. Android developer verification enters the enforcement phase on September 30, 2026, starting with four countries — Brazil, Indonesia, Singapore and Thailand — covering distribution across seven stores: Google Play, HONOR App Market, OPPO Software Store, Samsung Galaxy Store, Transsion Palm Store, vivo App Store, Xiaomi GetApps.

In other words, from now on installing an app on a certified device raises a question: who signed this package. The official timeline is worldwide rollout in 2027.

It splits developers onto three paths, and identity verification, fees and where you can distribute all differ.

Three key details.

Full distribution requires opening a separate account in the Android Developer Console, also $25, which is a different payment from the Play one. Limited distribution is free and needs no ID documents, but covers only 20 devices, and users have to accept an invitation before they can install. On the unverified sideload path, users can let themselves through via an advanced flow, which the official writeup describes as a buffer that buys users time and room.

One more detail matters most to people who write code. The official FAQ is blunt: installing an app over ADB requires no registration and no verification. Development, debugging, flashing your own test builds — that channel is not closed. Apps on enterprise-managed devices also skip verification; the IT admin has already reviewed them.

What registering a package name needs, you can prep locally

The third step of the new verification system is registering the package name. Google requires an APK signed with your private key, to prove the package is yours. You do not have to wait for the account to be approved for this — you can rehearse it locally.

keytool -genkeypair -v -keystore demo.jks -storetype PKCS12 \
  -alias upload -keyalg RSA -keysize 4096 -validity 10000 \
  -dname "CN=Demo Dev, O=Demo, C=CN"

keytool -list -v -keystore demo.jks | grep SHA256

What comes out is a SHA-256 string. Mine generated 52:05:B5:73:…, with another thirty bytes behind it. That fingerprint is what gets checked against package ownership from here on. Lose the private key and it never matches again. So from day one, treat the keystore file and its backup as the same object.

The math cross-platform developers have to do

If you are shipping Android from one codebase with Kotlin Multiplatform or Flutter, the accounting splits here. $25 to publish on Play, another $25 to distribute outside Play through the Android Developer Console, and both accounts need identity verification.

Where you save is elsewhere: device verification and the twelve-people-fourteen-days test are tied only to a personal account’s production release access. Organization accounts do not carry that.

The actually convenient move is to keep publishing through Play as usual, and register the package name and signing key in the Android Developer Console at the same time. Then no matter which store a user downloads from later, or whether they install straight from your site, the install does not get blocked.

$25 buys a ticket. The gates behind the ticket are where this year’s time actually goes. Which step did you get stuck on when you opened your account? Comments are open.

The Agent's Official Command Line: Android CLI 1.0

Wed, 14 Oct 2026 14:36:53 +0800

First, a broken link in the chain

You have an agent write some Kotlin. It says it’s done. Now what?

You open Android Studio yourself, watch Gradle spin, wait for the emulator, then poke the screen with your mouse to check whether that string actually changed. Inside the terminal the agent flies. At the point where you need to look at the screen, the chain snaps, and the rest of the work belongs to your eyes.

That gap is what Google just filled. Android CLI is at 1.0 stable. Their words:

Whether you use Gemini in Android Studio, Antigravity 2.0 or Antigravity CLI, or a third-party agent like Anthropic’s Claude Code or OpenAI’s Codex, our mission stays the same: make high-quality Android development possible anywhere.

Blunt enough. Whichever agent you use, they want you to stay in the terminal. I ran it end to end on this machine, from creating a project all the way to looking at the screen.

What it actually ships

I’ll go through the list by what it saves your agent from doing.

One android command

After installing you get a single command, android, with 19 top-level subcommands. Creating projects, starting emulators, installing apps, looking at the screen, all of it:

auth completion create describe device docs emulator info init
install layout run screen sdk skills studio update help

Agents used to have to remember three sets of flags for adb, emulator and gradle. Now there is one entry point against one SDK. It installs a single 3.6 MB binary into your home directory, and afterward android info reports the SDK path and version.

The official skills library

android init is the interesting one. It takes no arguments, and when it finishes it has written a 24,922-byte android-cli skill into every agent’s skill directory on your machine. It hit 10 on mine:

~/.claude/skills          ~/.gemini/skills           ~/.agents/skills
~/.commandcode/skills     ~/.hermes/skills           ~/.junie/skills
~/.openclaw/skills        ~/.config/opencode/skills  ~/.pi/agent/skills
~/.gemini/antigravity/skills

Hermes is in there, along with Claude Code, Codex, Gemini, OpenClaw and OpenCode. Worth looking at which directories it wrote into after it runs. It is dropping files in your home, after all.

There are 24 skills in the library now; android skills list shows them all. On the UI side: adaptive, camerax (camera migration), edge-to-edge, wear-compose-m3 (Wear OS).

There are a few project-hygiene ones too: play-policy-insights, restore-credentials, testing-setup, r8-analyzer. Installing is one line, android skills add , and you can pick which agent gets it.

An offline copy of the official docs

android docs search "edge to edge" downloads an index on first run. 5,319 entries, measured. What comes back is not a URL but a kb://android/... protocol address.

Even the sample code inside skills is in there, e.g. kb://android/agents/skills/wear/wear-compose-m3/references/material3/EdgeButtonSample.kt. Agents no longer have to search blogs. The official docs are queryable locally.

The look-at-the-screen commands

This group is the most useful thing in the release. screen capture --annotate labels the elements on screen as #1, #2, and screen resolve turns those labels back into coordinates:

android --no-metrics screen capture --annotate --output shots/12-annotated.png
android --no-metrics screen resolve --screenshot shots/12-annotated.png --string "tap #1 and #2"
# output: tap 72 31 and 835 30

The agent no longer does pixel math. It points at #3 and says tap this. layout in the same group returns the UI tree as JSON, with bounds and center point for every control.

Borrowing Android Studio’s semantic analysis

The new android studio subcommands: find-declaration for definitions, find-usages for references, analyze-file to run inspections, render-compose-preview to render a Compose preview, version-lookup for dependency versions, open-file to open a file in the IDE.

That means the agent borrows the IDE’s fifteen-odd years of semantic analysis instead of guessing with regex. There is a floor: Android Studio Quail 1 or later.

Booking a physical device

android device remote lets you book a remote physical device to run on. Their example connects to a Pixel 10 Pro. This path needs android auth and a Google account first.

I ran it from zero on macOS

Only a clean run counts. These are the commands I actually ran, none left out:

# install: download the script and read it first, don't pipe straight into shell
curl -fsSL -o /tmp/android-cli-install.sh \
  https://dl.google.com/android/cli/latest/darwin_arm64/install.sh
bash /tmp/android-cli-install.sh            # → ~/.local/bin/android, 3,650,880 bytes

android --no-metrics -V                     # 1.0.16500706, first run walks you through the Android SDK terms
android init                                # writes skills into each agent's skill directory
android --no-metrics skills list            # official skill catalog, 24 measured
android --no-metrics docs search "edge to edge"

# end to end: create project → start emulator → build → install → look at screen
android --no-metrics create --name CliDemo \
  --application-id com.example.clidemo --min-sdk 36 -o ~/android-cli-repro/CliDemo
android --no-metrics emulator list          # existing AVD on my machine: Medium_Phone_API_36.1
android --no-metrics emulator start Medium_Phone_API_36.1   # returns only when ready, about 17s
cd ~/android-cli-repro/CliDemo
./gradlew :app:assembleDebug                # first build: BUILD SUCCESSFUL in 1m 24s
android --no-metrics run --apks app/build/outputs/apk/debug/app-debug.apk
android --no-metrics screen capture --output shots/10-before.png
android --no-metrics layout

Project creation first. create produces a Compose + AGP 9 + Kotlin 2.3.20 project. I never touched SDK Manager. It noticed platforms/android-36 was missing and installed it.

emulator start is a nicely designed piece: it blocks until the device is fully booted, printing remaining seconds along the way, so you never poll adb yourself. Ready in 17 seconds for me.

What actually surprised me was the second run. I changed one string, listOf("Android") to listOf("Android CLI") in the data source, and ran the loop again:

./gradlew :app:assembleDebug                # incremental: BUILD SUCCESSFUL in 8s
android --no-metrics run --apks app/build/outputs/apk/debug/app-debug.apk
# Delta Install: Sent 167.94 KB patch instead of 28.67 MB (1 APK, 99.43% savings)

The first install pushed 28.64 MB. The second pushed a 167.94 KB patch, 99.43% saved. Delta install is on by default (--use-delta-install defaults to true), and for the change-a-string-and-look loop, everything you save is waiting.

Reading the UI tree with layout afterward, the string is already the new one:

应用窗口: CliDemo  焦点=True  边界=[0,0][1080,2400]
  - android.widget.TextView | text='Hello Android CLI!' | center=[220,136]

The entry bar and a few pitfalls

The one that trips you up fastest is run. Its description says build, deploy, launch. Without --apks, it just fails for me:

Error: No apks specified. Use --apks 
Component check failed

The APK was already built and describe had just located it. run still would not do it on its own. The actual split: producing the artifact belongs to the project’s own ./gradlew, run handles install and launch.

One more, sneakier. The package deploys but the UI does not change, because the old process is still alive and run will not force-kill it for you. Add adb shell am force-stop com.example.clidemo and run again.

There is a version floor too. The android studio commands need Quail 1 or later. Too old and you get No running Studio instances found, plus a line telling you to grab a newer build from the site.

Two more. android init writes files into your home directory, it is not a read-only operation, so if you have a lot of agents on the machine, read the list before you run it. And the subcommand is the singular device; android device list reports 'list' is not a valid command.

Also android completion writes shell completion into your shell config. Do not run it if you do not want that touched.

Telemetry deserves a line. The CLI collects data by default. The docs say what: which subcommand ran, the parameter names used, and a set of fixed values such as emulator template names and agent names (GEMINI, CLAUDE, CODEX). Add --no-metrics if you do not want it. Every command above carries it.

One last thing

This release did not invent a separate workflow for agents. It changed the things that already existed. Docs, skills, emulators, physical devices, IDE semantic analysis: all now exposed as interfaces a machine can read.

The details are handled too. Pixel coordinates become labels like #3, the UI tree comes back as JSON.

On your toolchain: would you hand the whole change-code-to-see-the-screen stretch over to an agent? Comments are open.

Android Is Tightening Sideloading, and Cross-Platform Devs Need to Redo Their Distribution Math

Fri, 09 Oct 2026 07:39:00 +0800

By the time a cross-platform project reaches release, there is usually more than one distribution path. One through Google Play, one straight from your own site, and sometimes a test build for the QA folks. Android’s developer verification reprices the entry cost of each path, and the three bills are not calculated the same way at all.

Three paths, three bills

Start with the Google Play path. For a team that already has a Play developer account, this bill is close to zero. The app is already inside the verification flow, packages using Play App Signing get their package names claimed automatically, and all you have to do is confirm your status on the developer verification page. The new cost is time, and the review cycle is unchanged.

Now the sideload path. When users download your APK in a browser and install it directly, after September 30, 2026 they will have to clear an identity check in four countries: the package name has to be registered, and the package has to be signed with your private key.

The team left an exit. Development installs through the Android Debug Bridge are unaffected, the advanced flow lets users grant a one-time pass, and a free limited distribution account covers 20 devices. The catch: once the advanced flow is off, updates to unregistered apps fail. Those builds you hand to QA have to fit inside those 20 devices.

Then the enterprise internal distribution path. Managed devices installing from an organization store get an exemption, as long as the device is genuinely managed. If the same app also ends up on employees’ own unmanaged phones, register it anyway. What this means for cross-platform teams is that internal test builds and demo builds still count as package names and identities — you cannot skate past it with “it’s only internal.”

Why the math is messier for cross-platform teams

The first reason is the number of package names. A KMP or Flutter project often produces several artifacts out of one repo: the main build, assorted flavors, test builds, each with its own package name. Verification works off package name and signing key, so your inventory has to cover every artifact and every key, not just the one that ships to the store.

The second is where the keys come from. On one team you can easily have a keystore generated on a CI machine, a keystore someone keeps locally, and the one Play App Signing hosts. The more names there are, the easier it gets to ship a build that was not signed with the key you thought.

The third is what you submit. In the end this verification asks for two things: a package name, and an APK signed with your private key. The first gets checked for duplicates, the second has to prove itself.

While we are on boundaries: this verification only governs package names on Android-certified devices. If the same project also ships to HarmonyOS or iOS, those signing materials are a separate system and outside these rules. But archiving your keys and being able to run your own check is something both sides should be doing.

First: archive the keys, and be able to prove it

Registration requires proving the package name is yours, and the credential they accept is an APK signed with your private key. In other words, the signing key graduates from something sitting in a build cache into an identity document. The official FAQ has a line specifically about this: lose the key and you cannot register the package name, so use a key management solution.

Archiving is not enough by itself. You have to be able to prove it at any time. I wrote a thirty-line script that, in one run, prints an APK’s package name and certificate fingerprint and compares them against the archived fingerprint list. Same code, same package name, signed with a different key, and the output forks:

Identical package name, completely different fingerprint. That is what using the wrong key looks like. This happens on teams more often than you would guess, especially after a CI machine gets replaced or someone regenerates a keystore.

Three archiving rules. Keep the keystore file, the alias, and the fingerprint list together, in a password manager or the team vault; keep the fingerprint list as plain text, one SHA-256 per line, so machines can diff it; wire that step into the release process as a gate, and block the release when it does not match. The official docs also mention that one package name can register multiple signing keys, which is what you want when rotating keys.

Second: check whether the package name is taken before you ship

Package names are claimed first come, first served. You check for collisions when you pick the name, not on launch day.

Google opened the Android Developer ID Status API specifically for this, and it returns three states: registered, unregistered, and registered but tied to a different certificate fingerprint. That last one is the painful case, because it means someone else holds the package name.

When you do collide, the official path is to apply for registration, but it needs extra review, and the docs say outright that the package name may be in use by other developers at the same time. Anyone who has done Android knows what two apps sharing a package name means.

The API has a quota, 1,000 calls per project per day, and it has to be attached to a Google Cloud project: create the project, enable the API, set up auth. I do not have that setup on this machine, so this section follows the docs only — I never actually issued a request. For day-to-day status checks, the package name lists in Play Console and the Android Developer Console show it directly, as registered, unregistered, or draft.

Third: accounts and paperwork, start what you can start

For an individual developer, this step is just identity verification. Organizations need two more things: a D-U-N-S number, and a company site verified through Search Console.

D-U-N-S is free, you apply on the Dun & Bradstreet site, and the process takes up to 28 days. It is the only item on the whole list whose waiting time you cannot compress, and the official help docs specifically warn about third-party services charging steep fees for it.

On cost: a full distribution account is a one-time $25, the same ballpark as Play’s registration fee; limited distribution is free. Money and forms are not the real problem. The real cost is those 28 days up front.

Three traps that will stop you

The first is losing the key. This is not an inconvenience, it is an inability to register the package name — meaning you never get that name back.

The second is someone else registering the package name first. After you apply you may end up sharing it, which is a landmine with an unknown detonation date.

The third hides on the limited distribution path. Once the advanced flow is off, updates to unregistered apps fail. The official FAQ is explicit: unregistered apps can only be installed and updated through the advanced flow or the Android Debug Bridge. In the 20-device scenario, remember not to flip that switch off.

What to do now, what can wait

Already in effect: four countries, seven participating stores (Google Play, Samsung Galaxy Store, Xiaomi GetApps among them), covering certified devices on Android 7 and up, with the first phase limited to phones and tablets as form factors.

Three things you can do right now: archive your keys and hook up the self-check, check whether your package names are taken, and get the D-U-N-S and account paperwork moving.

What can wait: stores not on the list, and direct sideloading by users, are unregulated until this round expands. The official timeline is a global rollout in 2027 and beyond, and they recommend developers complete verification before that; press coverage puts the early pace at the US and UK first. Apps already on Play have to register for all form factors — enforcement just starts with phones and tablets.

One phrase worth remembering: the official FAQ says “not applicable for now,” not “never.” The gap between those two sentences is that 2027 slot.

Last thing

Add up the three bills and the most expensive item is not the $25. It is the lead time on identity paperwork, and the fact that a signing key has no substitute. Ten minutes to fill in a form, 28 days for D-U-N-S, and if the key is gone there is no second one. So for a cross-platform team this should not be something you remember the week before launch. It belongs as a step in the release process.

Which path does your project take? And can you find that signing key right now? Talk in the comments.

References:

Android developer verification official guide https://developer.android.com/developer-verification/guides
Official FAQ https://developer.android.com/developer-verification/guides/faq
Check package name registration status (Developer ID Status API) https://developer.android.com/developer-verification/guides/check-registration-status
Register a package name with the Console API https://developer.android.com/developer-verification/guides/developer-console-api

Android Sideloading Only Got Half Apple-ified: It Wants Identity, Not Content Review

Thu, 08 Oct 2026 08:14:49 +0800

If you have friends in Brazil, Indonesia, Singapore or Thailand, after September 30 they may run into something new: tap install in some app store, get a prompt saying the developer isn’t verified, and it won’t install. At the same moment, the China-market Android phone in your hand installs anything with no change at all.

The Chinese tech scene hasn’t talked about this much. The English community has been arguing for a while. The Hacker News thread from October 1 pulled 338 points and 141 comments. F-Droid, on the free software side, put out an open letter together with the Electronic Frontier Foundation, and the title is one line: opposing Android developer verification.

So this is worth taking apart. What it changed, and who actually gets hurt.

In Google’s own words: apps have to be registered by verified developers

Google puts it plainly. The official guide opens with: Android requires all apps to be registered by verified developers before users can install them on certified Android devices.

Let’s draw the boundaries first:

Takes effect September 30, starting in Brazil, Indonesia, Singapore and Thailand
Covers seven stores: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo App Store, Xiaomi GetApps
Applies to certified devices on Android 7 and up, with the check delivered through Google Play services
This round only covers phones and tablets
Global rollout in 2027, with verification extended to all third-party Android stores

One detail matters more than it looks: this round only covers those seven stores. The official FAQ is explicit — if you distribute through other channels, or users just sideload, these new requirements don’t touch you for now.

In other words, the sideloading road isn’t blocked. There’s just an ID check at the entrance.

Google’s own analogy is refreshingly candid. They say it’s like checking ID at the airport, which is a different thing from security screening. What’s being confirmed is who the developer is. The app’s content isn’t reviewed, and neither is where it came from.

Three roads, pick one

The official docs give three paths. The difference sits in the identity verification column.

	Full distribution	Limited distribution	Sideloading unregistered apps
Who it’s for	Organizations and professional developers	Students, hobbyists, individuals	Developers who won’t verify
Identity verification	Required	Not required	Not required
Distribution scope	Any store or your own site	Up to 20 devices	Any channel, but users must enable advanced flow
User experience	Same as today	Install after accepting an invite	Set up once, then install freely

Full distribution means handing over identity: a developer console account at $25 one time, a D-U-N-S number if you register as an organization, up to 28 days for review, plus a website verified with Google Search Console.

Limited distribution is the door left open for people who don’t want to hand over a government ID. Free, no cap on app count, but limited to 20 devices and users have to accept your invite. Students, hobbyists, and people writing apps for themselves take this road, it’s the least hassle.

The third road is for users: apps from unregistered developers still install, but the user has to go through advanced flow setup once. Google says the point of those safeguards is to give users time to break off coercion.

One official line to note: once advanced flow is turned off, updates to unregistered apps fail. That road works as a destination, not as a daily driver.

I built an APK by hand. What gets verified is really just two things

Concepts go further if you run them yourself. My local Android SDK had aapt2, d8, zipalign, apksigner and keytool, enough to hand-assemble an APK without Android Studio.

The flow: write an AndroidManifest.xml with just the package name com.example.handmade, javac one class, d8 it into classes.dex, aapt2 link to produce the APK, then generate an RSA key pair on the spot with keytool and sign with apksigner.

Then pull the identity out and look at it:

Signer #1 certificate DN: CN=Handmade Identity Demo, O=none, C=CN
Signer #1 certificate SHA-256 digest:
0a220aaa9b719f34f97e88cb46a95de020fba812fee540251cc2cae7a188a269
Verified using v2 scheme (APK Signature Scheme v2): true

package: name='com.example.handmade' versionCode='1' versionName='1.0'

An 8,619-byte APK, and the identity is those two lines: the package name com.example.handmade, plus the certificate fingerprint, that SHA-256 starting with 0a22. That pair is what Google wants you to register. Officially: provide an APK signed with your private key, which links that APK to your developer account.

A control test makes it more interesting.

I verified the unsigned APK and it flatly reported DOES NOT VERIFY, missing META-INF/MANIFEST.MF. Then I signed the same APK with a second key. Not a character of code changed, the package name didn’t change, and the fingerprint went from starting 0a22 to starting ee56.

So what gets verified is the person, not the code. Which explains why the official FAQ has a line specifically saying that if you lose your signing key you can’t register the package name. That keystore file isn’t a build cache, it’s an ID card. Archive it like private data.

This isn’t App Store-ification, it’s macOS notarization

Most people’s first reaction is that Google is going Apple. That read is only half right.

Where it’s similar is real: distribution hangs off an account. On Apple’s side every install path hangs off the Apple Developer Program, $99 a year, and organizations also need a D-U-N-S. On macOS it’s more direct — Gatekeeper checks a notarization ticket online on first run. And the third-party marketplaces Apple opened up in the EU also require confirming at install time that the source is an authorized channel.

Where it’s not similar is the point, and there are two places.

First, Google doesn’t review content. The official help doc says outright that app content and functionality information is not collected. Apple’s setup is review plus cut: content rules up and down, and under the newest EU terms it’s 26% for in-app purchase, 20% for alternative payments, 15% for link-outs, and another 5% for third-party marketplaces or web distribution.

Second, Google left a no-identity exit: 20-device limited distribution, advanced flow, and adb development installs that are completely untouched. Apple has no counterpart.

There’s also a fun contrast in direction. In the EU, Apple is being pushed open by the Digital Markets Act. Google here is voluntarily tightening. Nobody is copying anybody — two curves pointing opposite ways, meeting in the middle.

The line actually worth watching is the one about verification extending to all third-party Android stores. At that point Google isn’t just the doorman of its own yard, it’s the identity issuer for other people’s stores.

Who gets hurt

Ordinary users won’t. The experience genuinely doesn’t change, which is the hardest thing for opponents to argue.

Three other groups will. Non-profit repos like F-Droid are first in line, and their open letter is blunt:

Installing or launching any app on a certified device will phone home to Google to verify that the developer and app have been approved.

They host thousands of apps, verification binds to package name, which means every volunteer has to hand their identity to Google. Their conclusion is to advise developers not to register.

The second group is people who can’t complete verification. The official FAQ admits it: developers in sanctioned regions cannot complete verification. Offline environments, no documents to produce, or a region where the flow simply doesn’t work — those people are shut out of distribution.

The third group is any future distributor that wants to compete with Play. They can’t even go live without going through Google’s registration process first.

For developers in China, three practical moves

First, if your app is Play-only and you use Play App Signing, you’re already inside this flow. Google claims it automatically, no extra action needed. To check your status, just look at the developer verification page in Play Console.

Second, if you have overseas users and distribute outside Play, what you should do now is archive your signing keys properly, apply for the D-U-N-S early, and treat 2027 as the real deadline instead of staring at this September.

Third, for apps you only write for yourself or a small circle, adb is officially kept and advanced flow works too — but remember that updates to unregistered apps depend on it, so don’t turn it off.

One API worth knowing about: Google opened the Android Developer ID Status API, which tells you whether a package name is registered, 1,000 calls a day. It has to be attached to a Google Cloud project to call, which I don’t have here, so I’m only noting it as a lead. For people who distribute, it means you can ask who owns a package name before installing.

Last

This isn’t a security check. It’s the gatekeeping right of distribution moving out of the operating system and into Google’s account system. Nearly invisible to ordinary users, a structural blow to non-mainstream distribution.

The 2027 global rollout is the watershed. These four countries today are just a very cheap pilot that can be adjusted at any time.

If you’ve got an app that only distributes inside China, will you register, or wait for 2027? Talk it out in the comments.