Google Play’s 12 Testers for 14 Days Rule: Publishing an Android App in 2026

Update, 1 October 2026: the closed test is over and Council is now live on Google Play.

Here is the real version of that, Council on Google Play as I write this:

The app is built, signed, reviewed, approved, and live on a closed track in 177 countries. The button that would let me publish it is grey, and it will stay grey for at least another two weeks. Ten testers have opted in. I need twelve, and then the two-week clock starts from zero.

The same app has been on the App Store for months. Apple’s process was: upload, fill in metadata, wait for review, ship. Google’s, for an account like mine, is a different category of thing — and almost none of the difficulty is in the parts a developer would consider difficult.

The wall before the wall

I started on 26 August by asking a simple question: where do we actually stand on Android? The answer was that I couldn’t create the app. Not “the app was rejected” — the Play Console had no app record at all, and the Create app button was locked behind a padlock reading “Complete account verifications to create new apps.”

Two open tasks, chained:

1. Verify that you have access to an Android mobile device. Sign in to the Play Console mobile app on real hardware.
2. Verify your contact phone number — which unlocks only after task 1 and after Google approves your identity documents.

Task 1 is the interesting one. It wants a non-rooted physical device running Android 10 or later, and the Play Console app checks device integrity, so emulators fail it. I had no Android device. I develop on a Mac and ship to an iPhone.

There is no clever way around this. Cloud device farms mean typing your Google password into rented hardware. A borrowed phone clears the gate in under a minute but leaves you shipping an Android build you have never run on Android. So: buy a cheap used phone, from a mainstream seller so it is Play Protect certified and not carrying a custom ROM. That is the whole answer, and it costs about a week of calendar time before you have written a single line of Android-specific code.

The detour that looks like a shortcut

There is an exemption. Organization accounts skip both the device check and the closed-testing requirement below. I have a registered Polish sole proprietorship, so I spent an evening chasing it.

The chase went further than I expected — the business does have a Dun & Bradstreet record, which is what an organization account needs. Then the details caught up with it:

• It is a new account, not a conversion. Google does not upgrade personal to organization. You register a second developer account, verify it, and transfer the app across.
• Verification requires the legal name to match D&B exactly. Mine is registered under my own name, not the trading name I actually use.
• Google’s rules exclude “DBAs, fictitious businesses, trade names”, and there are consistent community reports of sole proprietors being bounced back to a personal account.

Net: roughly the same calendar time as just running the closed test, plus a real chance of rejection at the end of it. Incorporating to dodge a fourteen-day timer is backwards. If you incorporate, do it for liability or tax reasons. I dropped it and bought the phone.

The build was the easy part, and it still wasn’t easy

Verification cleared on 2 September. That evening I created the app and ran the first Android production build. Council’s mobile app is Expo, so this is one command.

It queued for forty minutes on the free EAS tier, compiled for twenty-two, and then hung in Gradle’s configure phase. First Android build, so nothing was cached: RevenueCat, PostHog, Google Sign-In and Hermes all compiling from scratch on a shared worker behind everyone else’s paid builds. I cancelled it and built locally instead, which took about twenty-five minutes and has been how every Council Android build has happened since. RevenueCat, the subscription layer in that list, now has its own short setup post.

Then Play Console wanted the rest of it, and the rest of it is a long tail of forms rather than one big obstacle: nine app-content declarations (privacy policy, ads, content rating, target audience, data safety, advertising ID, government apps, financial features, health), the store listing, a 1024×500 feature graphic, and screenshots regenerated for Play’s aspect ratios because the iOS frames don’t fit. Eleven of eleven setup tasks, all in one evening.

One footnote for anyone automating this: the finished AAB is 78 MB, and browser automation tools cap file uploads at 10 MB. Every single release of Council has required me to personally drag a file from my Desktop into a Chrome window. It is the one step in the entire pipeline that no amount of tooling has removed.

The gate itself

Internal testing published instantly. Production was grey, with the requirements spelled out:

Requirement	Detail
Publish a closed testing release	Goes through full policy review, unlike internal
At least 12 testers opted in	Simultaneously, on real Google accounts
Run the closed test for 14 continuous days	The count dropping below 12 breaks the run
Apply for production	A questionnaire about your closed test, then a review

This applies to personal accounts created on or after 13 November 2023. Mine is one of them.

The thing worth internalizing: the clock measures opt-ins, not builds. I shipped three closed-track releases in three days while the counter sat still, and none of them reset anything. The only number that matters is how many people currently have your app installed with a Google account that opted in.

Where twelve testers actually come from

I started the way everyone starts: I asked my friends. That produced four Gmail addresses, one of which was mine. Then I learned that the opt-in link, the one Play Console hands you to share, only works for people already on your tester list. Anyone else gets an error. So the flow is always two steps — you add them, then they click — which means recruiting by link doesn’t work at all.

The fix is to switch the track from an email list to a Google Group, and once you know that, you find the thing the rule actually built. There is an ecosystem of Telegram groups fronted by Google Groups where developers stuck at exactly this gate install each other’s apps. Join the group, opt into everyone’s closed test, and they opt into yours. My track now points at a Google Group with a few hundred people in it, and the way I got from four testers to ten was posting a message in Russian to a Telegram channel promising to reciprocate.

The reciprocation is real work, and I did it: joined four more Google Groups, opted into eight closed tests, installed five of them on a Pixel emulator, opened each one. (Three of the eight used private email lists, so I couldn’t join at all.) An emulator with the Play system image is fine for this — it’s only the developer account verification that demands physical hardware.

I want to be careful about how I characterize this. Google’s stated aim is that real people genuinely use your app before it reaches everyone, and the production application asks you questions about how the test went. What the rule produced in practice is a barter market in tester counts, where a dozen strangers install your app because you installed theirs. It is not fraud and nobody is faking anything — the installs are real, the accounts are real. It just isn’t user testing either.

The gap between “You are a tester” and an installed app

Assume every tester will hit at least one of these, because mine did:

• A track uses either an email list or a Google Group, never both. The moment I switched to the group, my four friends stopped being eligible until they joined it too.
• Telegram’s in-app browser is signed into a different Google account than the phone’s Play Store. The tester opts in successfully — under the wrong account. This was the single most common failure.
• “Item not found” is normal for up to an hour after opting in. It reads like a hard failure and is just propagation. Send people the Play Store listing link rather than the web opt-in link; it opens in the Play app under the right account and shows a join card.
• Play Console never tells you who opted in. Only the count. I ended up querying my own Supabase auth table to work out which testers had actually signed in.

The part that defends the rule

Here is the honest counterweight to everything above. The closed test found three bugs, and all three were Android-specific, and none of them would have surfaced on iOS or on my own machine:

Google Sign-In was broken on every Play install. Play App Signing re-signs your bundle with Google’s key, not your upload key, so the SHA-1 fingerprint in my Android OAuth client matched nothing. The app worked perfectly when I installed it directly and failed for anyone who got it from the store.

Every tester’s first launch showed a payment error. The app opens a paywall on first run; the paywall asked the Play Store for products; there were none, because Play subscriptions require a merchant account and I hadn’t set one up. A tester’s screenshot is how I found out. That sent me down a full afternoon of merchant profile, subscription, seven-day trial, service account credentials and real-time notifications — all things I would otherwise have discovered on launch day.

A sign-in race condition. Android delivers the OAuth redirect twice, as a browser result and as a deep link. Both handlers ran the token exchange about 50 ms apart; the second one collided with a unique constraint and returned a 500. The user saw “Sign-in didn’t complete” while being, in fact, signed in. It’s a race, so it hit one tester and not the one before him.

Three real bugs, from ten testers, in three days. I would have shipped all three. Whatever I think of how the twelve-tester rule works in practice, it caught things I did not catch.

What I’d tell 26-August me

1. Buy the Android phone first. Everything else is downstream of it, including the timeline.
2. Ignore the organization-account exemption unless you already have a company that matches D&B exactly.
3. Create the app record the same day verification clears, even with nothing to upload. The closed test can’t start until it exists.
4. Put the track on a Google Group from the very beginning, not an email list. Switching later means re-inviting everyone.
5. Set up the merchant account and store products before the first tester installs, not after.
6. Recruit before you’re ready. Getting to twelve is the long pole, and it is entirely social, not technical.
7. Fix bugs freely during the test. Releases don’t reset the clock; testers uninstalling does.

The build, the store listing, the declarations, the subscriptions and the three bug fixes took about six hours of actual work, spread over four evenings, mostly driven from a terminal through the same setup I use for everything else. Getting twelve people to keep an app installed for a fortnight is the part with no engineering solution at all.

Twelve testers and fourteen days later, Council is live on Google Play.