Since November 2023, Google has required every new personal developer account to run a closed test with at least 12 testers opted in continuously for 14 days before it will even consider a production release. When you are building your app alone, that reads like a wall: twelve people, fourteen days, and nobody on hand. This guide takes it apart step by step — getting your .aab file, recruiting past the minimum, automating access with a Google Group, holding the two weeks without wearing out the people you know, and clearing the final questionnaire on the first try.
Google's rule, in one minute
Google asks for something simple, worded in a way that scares people: before you can apply for production, your app must have gone through a closed test with at least 12 testers opted in continuously for at least 14 days.
| Question | Answer |
|---|---|
| Who is affected? | Personal developer accounts created on or after 13 November 2023 |
| Who isn't? | Organization accounts, and personal accounts created before that date |
| How many testers? | 12 minimum, at the same time |
| For how long? | 14 days, consecutive |
| What breaks the counter | A tester who leaves the program. If they come back, their 14 days start over |
| What unlocks the next step | The Apply for production button on the Play Console dashboard |
| How long Google takes | Usually seven days or less |
Source: Play Console Help — App testing requirements for new personal developer accounts, checked 11 September 2026.
Two clarifications that save a lot of anxiety. First, the counter tracks your testers' opt-in, not your builds: shipping a new release to the closed track during the 14 days resets nothing. Second, it really is 12 Google accounts — not 12 devices, not 12 five-star reviews.
This is a checkbox, not an exam
The rule gets read as a judgement on the quality of your app. It isn't one. Google is not asking you to nail your launch; it is checking that your app ran on real phones, in real hands, and that you can describe what happened. Nobody is grading your retention curve.
The real cost isn't the 14 days either. It's the reviews that bracket them: up to seven days to approve the closed track before anyone can install anything, then usually seven days or less for the production request, then the same again for the production release itself. Budget four to six weeks between your first click and a public app — and plan your announcements around that, not around the number 14.
There is another way to read the constraint. Twelve people using your app for two weeks is the user test you would never have organised on your own, and that most solo projects never get. You are about to learn where people get lost on the first screen, which word in your menu means nothing to them, and whether your app survives a 2019 Android phone at 8% battery. Google is forcing you to do what you should have done anyway.
Step 1 — Get your .aab file out of GoodBarber
Google wants an Android App Bundle (.aab), not an APK. This is the part the platform handles end to end.
Before you submit anything, generate the Ad Hoc version of your Android app and install it on your own phone. It is your last safety net: what you can't see in the back-office preview, you will see there.
Then, in the back-office: Sales Channel > Android App > Update, then Submit my app. The Submission to Google Play page opens and hands you your .aab in one click. Keep it somewhere you can find it — you'll upload it within the minute. (Both the GoodBarber back-office and the Play Console are localized; menu labels appear in your account language. They are given here in English, the way Google's own documentation names them.)
You never open Android Studio, Gradle, or a command line. GoodBarber compiles a native Android binary in Kotlin and hands it to you ready to upload — exactly the file the Play Console expects.
One detail that pays off later in the journey: the compilation engines only embed a library if the matching feature is switched on in your back-office. Turn it off, the platform recompiles, and the library is gone from the binary. So the Data safety section of the Play Console — the one solo creators dread — covers what your app actually does, rather than a bundle of generic SDKs shipped by default with the builder.
Six checks before you create the closed track
- The Ad Hoc build runs on a real Android device. Not just in the preview.
- Your graphics are ready: 512 × 512 px icon, 1024 × 500 px feature graphic, and 2 to 8 phone screenshots.
- The store listing is filled in: name, short description, full description, category, contact email.
- The App content section is complete: privacy policy, data safety, ads, target audience.
- The countries and regions of the closed track are selected — and this is trap number one. The Play Console goes by the country of the tester's Google account, not where they physically are. Your cousin in Montreal with a Canadian Google account will see nothing if you only ticked the United States. When in doubt, tick every country: a closed track is only visible to your testers anyway.
- The feedback channel is filled in (an email address or a URL). Google asks for it, and it is where the raw material for the final questionnaire will arrive.
The full screen-by-screen walkthrough lives in our help centre: Publish your app on Google Play with a Personal account.
Step 2 — Recruit 15 to 20 testers when you have no network
Aim for 15 to 20 people. Not out of zeal — out of arithmetic. Out of ten people who say yes, one will give you an email address that isn't their Google account, another will never click the opt-in link, a third will leave the program on day six while tidying up their phone. Start at exactly 12 and you find out on day twelve, then start again.
One thing to understand before you approach anyone: you are asking for an opt-in, not a chore. Your testers install the app from the Play Store like any other, after one click on a link. No file to sideload, no obscure manipulation, no risk to their phone. Saying that in your first sentence doubles your hit rate.
| Channel | What it gives you | What to bring to it |
|---|---|---|
| People you know (family, friends, colleagues) | 5 to 8 reliable opt-ins within 48 hours | Their exact Gmail address, not their work email |
| r/AndroidAppTesters and r/AndroidClosedTesting on Reddit | The top-up that takes you past 12 | Reciprocity: you test their app, they test yours, for 14 days on both sides |
| Discord servers and Telegram groups for test swaps | Same logic, faster turnaround | The same discipline: a commitment made is a commitment kept |
| The community around your subject (no-code forums, professional Facebook groups, industry Slacks) | The most useful feedback of the lot | A real message, not an ad. Say what the app does and why it exists |
| A waiting-list page, or your app's PWA link | A list you will reuse at launch | A one-field form, and the link to the web version of your app |
Two honest warnings about these channels.
r/androiddev is not where you recruit. It's a technical discussion forum, and test requests get removed. The dedicated communities above exist precisely because this Google rule created the need.
Test swaps fill the counter, not the questionnaire. Twelve developers installing your app so you'll install theirs satisfies Google on the number — but the production form will ask what feedback you received and what you changed. Mix the two: a few swap testers to clear the threshold, a few people who actually care about your subject so you have something to report. And when you go looking for the latter in a community, give something before you ask. A message that exists only to place a link gets removed, and rightly so.
The message that gets a yes
Short, precise, with the real cost stated up front. Something like: "I'm launching an app for [subject]. Google wants 12 people to install it and keep it for 14 days. Concretely: one click on a link, install from the Play Store, and you leave it on your phone for two weeks. I need the Gmail address your Android phone uses. If you open it two or three times and tell me what annoys you, that's perfect."
If your GoodBarber plan includes native apps, it also includes the PWA generated from the same configuration. Send that web link before you ask for the opt-in: people say yes far more easily to an app they have already seen running in their browser.
Step 3 — Automate access with a Google Group
The Play Console accepts two ways of naming your testers: a list of email addresses, or the address of a Google Group. Pick the group, for a very practical reason. With a list, every new tester forces you to reopen the track, edit the list and save. With a group, you paste one address into the Play Console once and manage arrivals from Google Groups afterwards. Over three weeks of staggered recruiting, that's a dozen round trips you don't make.
- Go to groups.google.com and create a group —
testers-myapp@googlegroups.com, for instance. - In the access settings, allow yourself to add members directly: your testers then have nothing to do on their side.
- Add the Gmail addresses as you collect them.
- In the Play Console, open Test and release > Testing > Closed testing, then the Testers tab of your track, and declare the group by its email address.
- Save, then send your changes for review.
Avoiding the "App not available" error
This is what your testers see when they click too early, and it is by far the most demoralising moment of the whole operation: you did the work, and the first ten people you asked reply that it doesn't work.
The rule fits in one line: publish first, send the link second. As long as your closed track shows as Draft, Google is still reviewing it and the link leads nowhere. Wait for the status to turn to Closed testing — that's the signal, and it can take up to seven days.
If the message persists once the track is live, the cause is almost always in this list:
- the tester never opened the Join on Android opt-in link before going to look for the app in the Play Store;
- they are signed in to the Play Store with a different Google account from the one in your group;
- their Google account's country isn't among the countries and regions ticked on the track;
- they were added to the group moments ago and propagation isn't finished: give it a few minutes to a few hours.
Step 4 — Hold 14 days without wearing out the people you know
The natural reflex is to follow up every day. It is the surest way to get your app uninstalled by the people who love you. Three messages are enough, and each does a different job.
Day 0 — the link and one single question. The opt-in link, what to do in two lines, and a precise question rather than a "let me know what you think", which never gets an answer. "On the first screen, what don't you understand?" produces ten usable replies.
Day 7 — show that it's moving. This is the moment your app mentally disappears from your testers' phones, and it's where the platform helps. Publish fresh content from the CMS: it lands in the app immediately, with no new build and no new Google review. Pair it with a push notification to your testers. You've just proved the app is alive without resubmitting anything.
If you want to push a real binary update — a bug fixed, a screen reworked — go back to Sales Channel > Android App > Update, collect the new .aab and drop it as a new release on the same closed track. Your testers get it automatically and, once again, it does not reset the 14-day counter.
Day 12 — the last call. Ask for final feedback, and above all ask each person explicitly to stay opted in until day 15. Two days of margin cost you one message and save you from discovering a dropout at the exact moment you click Apply for production.
Between those three messages, keep a log. One line per piece of feedback: the date, who said it, what they said, what you changed, in which version. That file isn't bureaucracy — it is literally the answer to the third section of the questionnaire, written without effort.
Step 5 — Clearing the production questionnaire
Once the 14 days are behind you, open the Dashboard in the Play Console and click Apply for production. Google asks its questions in three blocks.
About your closed test. How you recruited your testers, how engaged they were, what feedback you got. Be factual and numbered: "24 people approached, 17 opted in, 15 still opted in at the end of the 14 days; recruited from my professional network and two Android tester communities; 11 opened the app more than three times."
About your app. Who it's for, what it brings, and an estimate of expected installs. A modest, argued estimate lands better than a round number out of thin air.
About your production readiness. What the feedback changed, and why you consider the app ready. This is where your log pays off: quote two or three specific pieces of feedback and the fix that followed.
Your checklist before sending:
- at least 12 testers still opted in at the moment you apply;
- specific answers, never generic — two vague lines is the single most common reason for a second round;
- real feedback quoted, not summarised;
- at least one concrete change tied to a piece of feedback, with the version that carries it;
- no inflated figures: don't claim 20 testers if you had 15.
Expect seven days or less for the answer, emailed to the account owner. If approved, head to Test and release > Production: create a release, add the last App Bundle used in the closed test from your library, and send everything for final review.
A realistic timeline
| Stage | Time to budget |
|---|---|
Prepare the store listing and collect the .aab | 1 to 2 days |
| Google's review of the closed track | Up to 7 days |
| Recruiting your testers (alongside the review) | 3 to 7 days |
| The closed test itself | 14 days minimum |
| Review of the production request | Usually 7 days or less |
| Review of the production release | Usually 7 days or less |
| Total | 4 to 6 weeks |
Recruiting is the one line you actually control. Start it the day you send the closed track for review, not the day it comes back approved: that way both clocks run together.
Frequently asked questions
Do the 14 days start at submission or when testers opt in?
When testers opt in. You need 12 accounts opted in continuously for 14 days: day one is the day your twelfth tester joins, not the day you sent your app for review.
Can I ship an update during the closed test?
Yes, and you should. You drop a new release on the same track. The counter tracks your testers' opt-in, not your builds.
Is it 12 testers or 12 devices?
12 Google accounts opted in to your closed track. One person with two phones is still one tester.
Is my account affected?
If it is a personal developer account created on or after 13 November 2023, yes. Accounts created before that date and organization accounts are not subject to this requirement.
Does an organization account get me out of the rule?
Technically yes, but it isn't a shortcut: an organization account requires a registered legal entity and a verified D-U-N-S number. If you publish as an individual, the closed test is still the shorter road. And the rule attaches to the account, not to whoever presses the button — delegating publication doesn't make it disappear.
Does the App Store have the same constraint?
No. Apple sets neither a minimum number of testers nor a test duration before release. The iOS route has requirements of its own, covered in Publish your iOS app yourself (Solo).
What if Google turns down my production request?
You can apply again. Go back through the three sections and replace every general statement with a fact: a number, a quoted piece of feedback, a dated change. Rejections almost always punish a vague answer, rarely the app itself.
I'd rather not handle any of this. Is that possible?
Yes: the GBTC option puts publication in the hands of GoodBarber's team. One caveat: if your developer account is a recent personal one, the 12-testers-for-14-days requirement stays attached to that account.
Your test build is one click away
The technical half of this story — compiling a native Android app, producing a compliant .aab, regenerating it on every update — is what blocked most solo creators ten years ago. Today it is a button in a back-office. What stands between you and the Play Store is twelve people and fourteen days, and you now know how to get both.
Project ready? Open Sales Channel > Android App > Update in your GoodBarber dashboard and collect your .aab file. No app yet? Start for free — no credit card required.