Publishing your first Android app in 2026: the closed test (12 testers, 14 days) step by step

In short

• If your personal developer account was created after November 13, 2023, Google requires a closed test with at least 12 testers opted in continuously for 14 days before you can publish to production.
• Internal testing does not count. Only the closed test moves the clock. I mixed up the two links myself.
• Since August 31, 2026, a new app must target Android 16 (API level 36). Check this first: it is the one thing that can block everything.
• The longest part is neither the code nor the listing: it is getting 12 real people and keeping them for 14 days. Aim for 15 to 20.
• Plan for about 3 weeks between the first upload and production access, 14 of which you cannot shorten.
• Below are the checklist, message templates and timeline I used, taken from the release of Qodex.

Why I wrote this guide

I published Qodex, a 100% offline QR code and barcode scanner, in October 2026. On paper, the process fits on one page. In practice, I tripped over a dozen details the documentation barely mentions: a feature graphic rejected with no explanation, a warning about "native debug symbols", a question about generative AI, a test link that turned out to be the wrong one, and above all the hard question: where do you find 12 testers when you have no audience?

This guide follows the real order in which things happen in Play Console. Each step says what to prepare, how long it took me, and the trap I ran into. The Google rules quoted here were checked against the official help pages in October 2026. They change regularly, so a source link is given every time.

1. Before you start: 4 checks that save you from starting over

1.1 Your account type

Google offers two kinds of developer accounts: personal and organization. The choice is permanent.

• Personal account created after November 13, 2023: you must run a closed test (12 testers, 14 days). That is my case.
• Organization account: no closed-test requirement, but you need a legal entity and usually a D-U-N-S number.

Registration costs US$25, once, and Google may ask for a government ID and a credit card in your legal name. Prepaid cards are not accepted. Source: Play Console, creating your account.

1.2 The target API level (targetSdk)

This is what made me switch apps at the last minute. My first candidate targeted API 35. Since August 31, 2026, new apps and updates must target Android 16 (API 36) to be accepted. You can request an extension to November 1, 2026 in the Console, but I would not start a first release on borrowed time. Source: target API level requirements.

How to check:

• Kotlin/Java project: open app/build.gradle.kts and look for targetSdk = 36.
• Flutter project: the value often comes from flutter.targetSdkVersion, which depends on your Flutter version. An older Flutter can leave you on API 35 without you choosing it. Set the value explicitly or upgrade Flutter.

My rule since then: for a very first release, I pick the "cleanest" app (API 36, few permissions, no data collected), not the most ambitious one. The goal is to unlock production access. Complex apps come next, on an account that is already approved.

1.3 A final package name

The identifier (applicationId, for example com.oufrid.qodex) can never be changed after the first upload. Also make sure the app name is consistent everywhere: strings, the About screen, exported file names. In Qodex, two leftovers of the old project name were still hiding in the clipboard label and in the exported CSV file name. No tool flags these: search the whole codebase for the old name.

1.4 A backed-up signing key

You sign your AAB with an upload key. Google then re-signs the app with its own key through Play App Signing. If you lose the upload key, Google can reset it, but it is a process you would rather skip. Keep the .jks file and its passwords in a password manager, never in the Git repository or in a chat.

2. How long each step takes

Google states that the production access review "usually takes seven days or less, but can occasionally take longer". Source: testing requirements for new personal accounts.

3. Preparing the AAB: the file you send to Google

Google Play no longer accepts APKs for new apps: you need an Android App Bundle (AAB). Google then generates the right APKs for each phone.

Checklist before uploading:

1. targetSdk set to 36 (see above).
2. An integer versionCode that goes up with every upload (1, 2, 3…). It can never go back down.
3. A readable versionName (for example 1.0.1), which is what users see.
4. AAB signed with your upload key, in release mode.
5. Minification enabled if possible (isMinifyEnabled = true) and tested: a bad minification setup causes crashes that only show up in release builds.
6. The release APK tested on a real phone (not just the debug build).

My apps are built by GitHub Actions: every tagged version produces a Release containing the AAB and every APK (universal and per architecture). The upside: I can install the universal APK on my phone and check exactly what I am sending to Google.

The "native debug symbols" warning

After uploading the AAB, the Console showed: "This App Bundle contains native code, and you've not uploaded debug symbols."

Yet I had debugSymbolLevel = "SYMBOL_TABLE" in my configuration. The explanation: Qodex's native code is not mine, it comes from ML Kit, Google's barcode recognition library. These libraries ship precompiled and stripped of symbols. There is simply nothing to upload.

Verdict: it is a warning, not an error. It blocks neither review nor publication. If your app contains your own C or C++ code, upload the symbols. If the native code comes only from third-party libraries (ML Kit, TensorFlow Lite, some game engines), you can ignore it.

4. The store listing: texts and graphics

4.1 The texts

Write each language separately. Raw machine translation shows, especially in Arabic. To speed this up, I built the Lab's Play Store listing generator: it counts characters live in all three languages and flags anything over the limit.

4.2 Graphics: the table I wish I had

Official specs checked on the graphic assets help page:

To be eligible for Google Play recommendations, the same page recommends at least 4 screenshots of at least 1080 px (for example 1080 × 1920 in portrait).

4.3 My feature graphic problem (and the fix)

My icon went through on the first try. The feature graphic kept showing "Couldn't upload, please try again". I checked the file: exactly 1024 × 500, no alpha channel, 238 KB. So it was compliant.

What unblocked it:

1. Re-exporting the graphic as JPEG (quality around 90), stripping metadata and the embedded color profile.
2. Reloading the Console page and trying again, if needed in another browser or a private window (ad-blocking extensions sometimes interfere with uploads).

JPEG remains the safest format for the feature graphic: it cannot carry an alpha channel, and it is the most forgiving format to upload.

4.4 Screenshots that sell

• Take screenshots on a real phone, with realistic data in the app (not an empty history).
• Put first the screen that shows the result (for Qodex: a scanned, decoded code), not the home screen.
• Remove screenshots of system dialogs (the camera permission prompt, for example).
• Check that the name shown everywhere in the app is the final name.

5. Declarations: app content

This is the "paperwork" part. It takes under an hour if you know the answers.

5.1 Data safety

This form describes what your app collects and shares. Be accurate: a false declaration can lead to removal. For Qodex the answer was simple: no data collected, no data shared, the app does not even request the Internet permission.

Careful: third-party libraries count. If you include an analytics, advertising or crash reporting SDK, what it collects must be declared.

5.2 Content rating

A questionnaire (violence, sexual content, language, gambling, user-generated content…). For a utility with no sensitive content, you get an "Everyone" rating.

5.3 The generative AI question

The Console asked whether my app contained AI-generated content, with the option to "label" it or not. I hesitated, because my description mentioned "on-device AI".

What to understand: the question targets apps that generate content (text, images, voice, video) with a generative model. Qodex uses recognition AI: it reads a barcode, it creates nothing. So I answered no.

Answering "yes" by mistake brings nothing and adds obligations, such as letting users report offensive generated content. Answer based on what your app actually does. If it really generates content, declare it.

5.4 Other declarations

• Target audience: if you tick an age range that includes children, extra rules apply (Families program).
• Ads: yes or no, depending on your app.
• App access: if part of the app is behind a login, give reviewers test credentials.
• Privacy policy: a public URL is mandatory. Qodex's is generated automatically by my site from the app's data.

6. The closed test: the part everyone underestimates

6.1 Internal or closed test: do not pick the wrong link

The Console offers several testing tracks. I confused them and nearly started my 14 days on the wrong one.

The first link I copied was an internal test link. If you see internaltest in the URL, it is not the right one.

6.2 The exact rule, as Google words it

For personal accounts created after November 13, 2023, you need a closed test with at least 12 testers who have been opted in continuously for at least 14 days. Until then, production is disabled. Source: Play Console Help.

What that means in practice:

• "Continuously": a tester who opts out on day 10 no longer counts. Several developers report that if the count drops below 12, the clock starts over. Take no risks: aim for 15 to 20 testers.
• Opted in is not the same as "on your list": the person must have clicked the opt-in link and accepted the invitation with the right Google account.

6.3 Email list or Google Group: choose the group

To define who may test, the Console accepts a list of addresses or a Google Group. I chose the group:

• you add it once in the Console;
• after that, you manage members in Google Groups without touching the Console;
• you can open it to join requests so people sign up themselves.

Setup:

1. Create the group in Google Groups (mine has a @googlegroups.com address).
2. Set who can join: "ask to join" if you want to approve each person, or direct adds by you.
3. In the Console: Closed testing → Testers → Google Groups → paste the group address.
4. Copy the opt-in link shown on that same page.

6.4 The feedback channel: an email is enough

The Console asks for an email address or a URL for tester feedback. For a closed test of 15 to 20 people, an email is the best choice: direct, personal, no form to maintain. A structured form only becomes useful with dozens of testers.

6.5 The 2-step tester journey (the trap of the link that does not work)

The opt-in link only works for someone who is already in the group. A person who clicks before being added simply sees that they are not a tester. If you only share that link, you lose people.

So on Qodex's page I built a journey with two numbered steps:

1. Sign up as a tester: a button to my Google Form, which asks for the Gmail address used on the Android phone.
2. Join the test and install: once the signup is confirmed (I let the person know), they come back, open the opt-in link, accept, then install from Google Play.

A warning reminds people that step 2 only works after confirmation, on Android only, with the Gmail they provided. Since then, every app I put into testing automatically gets the same journey on my site.

7. Finding 12 testers when you have no audience

This is the real issue. With family and friends it is easy: send a message, ask for the Gmail, done. But asking a stranger for their email address in a private message breeds suspicion. The fix: let strangers come to you, in a setting where sharing a Gmail is normal.

7.1 The four sources that work

1. Your circle (family, friends, colleagues, clients): the foundation, as long as they have an Android phone and a Gmail account. They do not need to use the app heavily, just keep it installed.
2. Tester exchange communities: since the rule arrived, developers test each other's apps on Reddit (search "closed testing" in Android and beta-testing communities), Telegram and Discord. You test their apps, they test yours. There, sharing a Gmail is the whole point of the exchange.
3. A public form on your site, shared on your networks (LinkedIn, X, developer groups): people who fill it in are volunteers.
4. Paid tester services: they exist, but quality varies and they do not replace real users. I keep them as a last resort.

7.2 Removing the doubt: the sentence that reassures

When you explain why you need the address, suspicion fades. Here is the wording I use:

It is simply the Google account you already use on the Play Store. I never see your password: Google only needs the list of accounts allowed to test. You can leave the test whenever you want. It is an official Google requirement before any release.

7.3 Message template: your circle (WhatsApp)

Hi! I just released my first Android app, Qodex:
a 100% offline QR code and barcode scanner, no ads,
no trackers. Before the public launch, Google requires
a few testers. Could you help? Just install it and keep
it for about 2 weeks.
If you're in, send me the Gmail address on your Android phone.

7.4 Message template: exchange community (Reddit, Telegram)

[Closed test exchange] Qodex: offline QR & barcode scanner

Looking for testers for my closed test (the 12 / 14 days rule).
In return, I'll test your app and keep it installed for 14 days.

1. Sign up (Gmail on your Android phone): <form link>
2. I add you within 24 h and let you know.
3. You join the test: <closed test link>

Reply with your own test link, I'll sign up the same day.

Two rules in these communities: keep your side of the deal (keep their apps for 14 days too), and be quick to add people to the group, or they give up.

7.5 Message template: once the person has been added

You're in as a tester. Three steps:
1. Open this link: <closed test link>
2. Tap "Become a tester"
3. Tap "Download it on Google Play" and install
Important: use the phone with the Gmail you gave me,
and keep the app installed for about 2 weeks. Thanks!

8. The typical timeline, from day 0 to production

Tip: do not start the clock with 3 testers. Gather about fifteen sign-ups first, add them all, then share the link. Your 14 days will be safer.

9. Applying for production access

Once the criteria are met, a button appears on the Dashboard. The form has three parts: your closed test, your app, and its production readiness. Answer concretely:

• How did you recruit your testers? Say it honestly (circle, communities, form).
• What feedback did you receive and what did you change? Give specific examples: a bug fixed, a text clarified. This is where a real test makes the difference.
• Why is the app ready? Stability, no crashes, features tested.

If Google decides the app is not ready, it may ask you to keep testing. It is not a final rejection.

10. Traps and fixes

11. What about APKs outside Google Play?

If you also distribute APKs on your website, a new rule affects you. Google has started Android developer verification: first in Brazil, Indonesia, Singapore and Thailand, with a global rollout planned for 2027. Apps from unverified developers become harder to install on certified devices there. Source: Android developer verification.

If you publish on Google Play with a verified account, you are already in the right framework. For APKs distributed elsewhere, keep an eye on that page.

FAQ

Does internal testing count toward the 14 days?

No. Only the closed test counts. Internal testing is for quickly checking installation with up to 100 testers, but it does not unlock production.

Does the 12-tester rule apply to my organization account?

No. The rule targets personal developer accounts created after November 13, 2023. Organization accounts are not subject to it.

Do testers have to use the app every day?

The rule is about being opted in continuously for 14 days. In your production request, Google asks about the test and the feedback you received: testers who open the app and send you comments make your case much stronger.

What happens if a tester opts out during the test?

They no longer count. If you drop below 12 testers, you may have to restart the count. That is why you should recruit a margin of 3 to 8 extra people.

Can I publish an update during the closed test?

Yes. Upload a new AAB with a higher versionCode to the same track. Opted-in testers stay opted in. Fixing feedback during the test is even a good argument in your production request.

Do I need to declare AI if my app uses ML Kit?

The question is about generative AI, which produces content. Recognition (barcodes, text, faces) is not part of it. Answer based on what your app actually does.

How long does it take overall?

In my case, plan for about three weeks between the first upload and production access: a few days of review, the time to gather 12 testers, 14 days of testing, then about 7 days for the final review.

---

Getting an app ready to publish and want to skip those three weeks of trial and error? I design and publish Android apps end to end, account, listing and closed test included. Let's talk about your project. And if you want to try my next apps before anyone else, join the testers club.