A tester accepts your closed-testing invite, opens the Play Store link, and finds no Install button. Sometimes Play tells them the app isn't available in their country. You never chose to block that country, so what happened?

Usually it's one of three things: the tester's Play country isn't in your closed track's country list, the track is quietly copying your production country settings, or the change you made hasn't reached testers yet. This guide explains how Google decides who can install a closed-test build, where the settings live in Play Console, and what to ask a tester before you change anything.

Why a tester can join but still can't install

Being on your tester list and being allowed to install are separate checks. The tester list (an email list or a Google Group) controls who may opt in. Country targeting controls which Play countries can actually get the release.

Google's Can't find an app help page puts it plainly for users: "you'll only be able to see apps and content that are compatible with your Google Play country." A tester can be correctly invited and opted in, and still be outside the countries your closed track targets.

Play country is the account's country, not where the tester is

This is the detail most people miss. Google's country targeting article says: "Country targeting is based on the user's Play country (that is, where their account is registered), not their current location."

So:

• A tester whose Play account is registered in India still has an India Play country while travelling in Germany.
• A VPN doesn't change the Play country Google uses for targeting.
• Asking where a tester "is" can give you the wrong answer. Ask which country their Google Play account is set to.

A tester can check this in the Play Store app: tap the profile icon, then Settings, General, Account and device preferences, Country and profiles. These are the steps from Google's change your Google Play country article.

Where country settings live in Play Console

Google separates app availability from country targeting, and internal testing sits outside both:

Google's article says: "By default, your testing releases match the country availability that you've set up for production." Its test setup guide, Set up an open, closed, or internal test, adds that "Changes to distributed countries and regions apply across all tracks," with internal testing as the exception.

In practice that means a country you never added to production, or removed from production, can also be missing from your closed test, even though you never touched the closed track.

How to give a closed track its own country list

If your testers are in countries you don't plan to launch in yet, you can stop the closed track copying production. According to Google's steps:

1. Open Play Console and select the app.
2. Go to Testing > Closed testing and click Manage track next to the track your testers joined.
3. Open the Countries/regions tab.
4. Click Unsync countries/regions so the track no longer follows production.
5. Click Edit countries, add or remove countries, and confirm.

Some limits apply. Google says you can customise testing-track countries only if your app has no app bundle uploaded to production, or it has one and at least one country is available in production. Turning sync back on is only possible when the track has no release rolled out, production targets at least one country or region, or pre-registration has started with at least one country other than "Rest of World".

If you run more than one closed track, check the track your testers actually joined. Each track has its own Manage track page.

Give the change time before retesting

Google's test setup article says that after a test is first published, "the test link can take several hours to become available to testers. Additional changes can also take several hours to become available."

So after you add a country, don't ask the tester to retry five minutes later and then assume the fix failed. Note the time you made the change, wait a few hours, and ask them to try again with the same opt-in link and the same Google account. Changing three settings at once makes it hard to tell which one fixed it.

Don't ask testers to change their Play country

Changing a Play country is a bigger step for the tester than adding a country is for you. Google's Play country article says:

• After setting a Play country, the user must wait at least 90 days before changing it, and at least 90 days between later changes.
• To set a new country, they must be in that location and have a payment method from that country.
• Members of a Google Family group can't change their Play country.
• Changing country can affect their Play balance, Play Points and access to some content.

Adding the tester's country to your closed track is almost always the right fix.

Internal testing ignores countries, but it isn't a shortcut

Google says country targeting doesn't apply to internal testing: "If an internal tester is located in a country where your app's production, open test, or closed test version isn't available, the user will still receive the internal test app."

That helps for quick team checks, but there are two catches:

• If your personal developer account was created after November 13, 2023, Google's testing requirements article requires a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. An internal test doesn't meet that.
• Google's test setup article says: "A user who opts into your app's internal test is no longer eligible to receive an open or closed test." They must opt out of the internal test first.

So don't move a tester to internal testing to dodge a country problem if you need them in your closed test. Our internal vs closed testing guide covers when each track makes sense.

What about the 14-day count?

Google's requirement is written in terms of testers who are opted in: at least 12, continuously, for the 14 days before you apply. We couldn't find any Google statement about whether an opted-in tester who can't install, because of country targeting, still counts. Don't rely on it either way.

What we do know is that Google may ask for more testing if there was "insufficient tester engagement during the testing period," per the testing requirements article. A tester who can't install can't use the app or send feedback, so fix country access early, ideally before day one. For how to track each tester's continuous days, see how the 14-day testing window works.

If the country is fine, check the device

When the tester's Play country is on your list and you've waited a few hours, look at the other common blocker. Google's Can't find an app page also lists device compatibility: "You can only download or use an app on your device if the app is compatible with that device." Compare the tester's device and Android version with your app's requirements and any device exclusions. Our guide on inviting testers to a closed test walks through the other access checks, such as the wrong account or an unpublished release.

A message you can send a tester

Thanks for joining the test. To help me fix the install problem, could you tell me:

1. The Google account email you used to join.
2. Your Google Play country (Play Store, profile icon, Settings, General, Account and device preferences, Country and profiles).
3. Your phone model and Android version.
4. The exact message you see, or a screenshot. Please don't change your Play country. I'll update the test settings and let you know when to try again.

Checklist before your closed test starts

• Decide which countries your testers' Play accounts are registered in, not where they live.
• Check the Countries/regions tab on the exact closed track they'll join.
• If production doesn't include those countries, unsync the track and add them.
• Publish, then allow several hours before sending the opt-in link.
• Ask one tester per country to confirm they can see Install.
• Keep a short log of when you changed settings and which testers confirmed access.

Our free closed testing checklist includes this check alongside the rest of the setup.

If you use a tester service

Whoever supplies your testers, ask which countries their Play accounts are registered in before you narrow your closed track's country list. 12Testers14Day offers done-for-you Google Play closed testing: the Basic package is $15 for one app, with 14 testers for 16 days as a buffer above Google's 12 testers for 14 days (see pricing). Our site doesn't publish where tester accounts are registered, so if your app is limited to certain countries, contact the team before you buy. Google decides production access, and no service can promise approval.

FAQ

Does a VPN help a tester install a closed-test app from another country? Google says country targeting uses the account's Play country, "not their current location," so a VPN doesn't change it.

My app has no production release. Can I still choose countries for a closed test? Google says you can customise testing-track countries if no app bundle has been uploaded to production. Check the closed track's Countries/regions tab to see what's selected.

I added the country. Why can't the tester install yet? Google says changes can take several hours to reach testers. Wait, then retry with the same account and link before changing anything else.

Can I just use internal testing for testers in other countries? Internal testing ignores country targeting, but it doesn't meet the closed-testing requirement for new personal accounts, and a tester in your internal test can't receive your closed test until they opt out of it.

A closed test is meant to find problems, so it is common to ship at least one fix before the test ends. That's normal, and Google encourages it. The risky part is the mechanics: a version code that won't upload, a review that takes longer than you planned, or testers who never get the fixed build. This guide covers what Google documents about each one, and what it doesn't.

Does Google want you to update during the test?

Yes. Google's testing requirements article says: "Continue running closed tests while resolving user-reported issues and bugs. Updating your app in closed testing before releasing to production helps minimize low ratings and negative reviews."

It also matters later. If your personal developer account was created after November 13, 2023, you need a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. The application then asks you to "Describe any changes made to your app or game based on what you learned from your closed test." A fix you shipped during the test, and the feedback that led to it, is exactly what that question is looking for. (Our guide to applying for production access covers the full form.)

Does a new build restart the 14 days?

Google's requirement is written in terms of testers, not builds: at least 12 testers "opted in continuously for at least 14 days." The same article explains that testers who opt out before 14 days don't count, and that a tester who opts out and back in needs 14 consecutive days.

We couldn't find any Google statement that publishing a new build to the closed track restarts that count, and none that says it can't. So don't plan around either assumption. What clearly does affect the count is people leaving. A broken update that makes testers give up and opt out costs you more than the bug it was meant to fix. See how the 14-day window works for how to track each tester's continuous days.

Step 1: Raise the version code

Every upload needs a new, higher versionCode. Android Developers' versioning guide says you can use any positive integer, "However, make sure that each successive release of your app uses a greater value." It also says "You can't upload an APK to the Play Store with a versionCode you have already used for a previous version," and that the greatest value Google Play allows is 2100000000.

A few practical points:

• versionCode is the internal number Play uses to decide which build is newer. versionName (for example "1.0.3") is what users see. Changing only versionName isn't enough.
• If your CI sets the version code from a build number or timestamp, check it can't go backwards, for example after you switch branches or rebuild an old commit.
• Name the release in Play Console with something you'll recognise later, such as the version name plus "fix login crash". Google says the release name is only shown in Play Console, not to users.

Step 2: Publish to the same closed track your testers joined

Google's test setup article explains which build a device gets. Devices receive the version that "Contains the highest version code compatible with the device" and "Is published to a track the user is eligible to receive." To be eligible for a test track, a user has to be on that track's tester list and actively opted in.

That means the fix has to go to the track your testers are actually on. In Play Console, go to Test and release > Testing > Closed testing, click Manage track for that track, then Create new release. Google's release guide notes that you can't create a new release while you have outstanding releases, so finish or discard any earlier draft first.

Two things to avoid:

• Don't move closed testers to internal testing to get them a fix faster. Google says: "Users who opt into internal testing aren't eligible for open and closed testing, even if included as testers on those tracks. These users receive only the version code published on the Internal testing track." Internal testing is still useful for checking a fix with your own team first; just keep your closed testers out of it. Our internal vs closed testing guide explains the difference.
• Don't start a new closed track for the fix. Your testers opted in to a specific track. A build on a different track doesn't reach them unless they're on that track's list and opt in again.

Step 3: Plan for review and delivery time

A closed-testing update isn't instant. Google's publishing article says app changes need to be processed before they're published, and "Processing can take a few hours or up to seven days (or longer in exceptional cases)." The test setup article adds that after a test is first published, "Additional changes can also take several hours to become available."

Google also warns that the review turnaround "is counted from the last submitted change to an app," so submitting another change while one is in review can push your app to the back of the queue. In practice:

• Batch fixes into one release rather than sending several small ones in a day.
• Avoid sending store listing or app content edits at the same moment as an urgent fix, unless they need to go together.
• If your 14 days are nearly up, decide whether you want testers to use the fix before you apply, and allow for review time. A build that's still in review on the day you apply isn't one your testers have used.

Step 4: Tell testers what changed

Google says testers can't leave public reviews on test versions, so your own feedback channel does the work here. When the update goes live:

1. Write short release notes. Play Console allows up to 500 characters per language. Google says not to use release notes "for promotional purposes or to solicit user actions," so keep them to what changed.
2. Message testers through your feedback channel with the version name, what was fixed, and what you'd like them to check again. For example: "Version 1.0.3 is rolling out to the test now. It fixes the crash when saving a photo. Please update from the Play Store page and try saving a photo again."
3. Ask them to update, not uninstall and reinstall. Google's requirement counts testers who stay opted in, and one simple instruction (update from the app's Play Store page) makes it less likely that anyone leaves the test by mistake.
4. Ask them to confirm the version. If your app shows its version name on a settings or about screen, ask testers to check it so you know their feedback is about the new build.

A quick checklist for a mid-test update

Common questions

Can I upload a fix in the last few days of the test? Google doesn't forbid it. Just remember the update may take hours or days to reach testers, so decide whether you want testers to try the fix before you apply.

What happens to testers who don't update? They keep the version they have until their device updates. Google's documented rule is about which version a device is eligible to receive, so ask testers to update if you want feedback on the new build.

Should I pause the track while I fix a bug? Pausing ends the test. Google's test setup article says that after a test ends, testers don't receive updates, though the app stays installed. Only do this if you mean to stop testing.

Does the 14-day count depend on how active testers are? The requirement is about continuous opt-in, but Google also asks about tester engagement in the production access form and may ask for more testing if engagement was too low. See what useful tester activity looks like.

If you'd rather not recruit and coordinate testers yourself

12Testers14Day provides Google Play closed-testing help: about 14 testers for about 16 days, as a buffer around Google's 12-tester, 14-day requirement. Packages are one-time: $15 Basic for one app or $29 Premium for two, per the pricing page on October 19, 2026. During a run you share changes in your workspace when you publish a new build (how a run works). Note that the delivery and refund policy excludes broken builds and unusable installs, so check each update before you publish it. Google decides production access.

Official references: App testing requirements for new personal developer accounts · Set up an open, closed, or internal test · Prepare and roll out a release · Control when app changes are reviewed and published · Version your app

If your app costs money, or sells one-time products or subscriptions, a closed test raises a practical question: will your testers be charged? Google's answer depends on the testing track and on whether each tester is a license tester. Getting this wrong can mean testers paying real money, or a 14-day test where nobody ever touches your purchase flow.

The short answer

Based on Google's Play Console Help and Android Developers documentation:

Google's test setup article says: "Testers must purchase paid apps when participating in open or closed tests. For internal tests, testers can install paid apps for free." It also says internal testers pay for in-app purchases unless you add them to a license testers list.

Google's billing testing guide adds that users "incur actual charges for their test track purchases unless the user is a license tester."

Note on paid apps and license testers: Google's license testing article says your own publishing account can buy your app as a test purchase, and that license testers can buy one-time products and subscriptions without being charged. Before you promise testers a free install of a paid app in a closed test, try it with one license-tester account and check the price shown on the Play Store page.

Why this matters for the 12-tester requirement

If your personal developer account was created after November 13, 2023, Google's testing requirements article says you need a closed test with at least 12 testers opted in continuously for at least 14 days before you can apply for production access. (See our 12-testers requirement explainer for details.)

That has two consequences for monetized apps:

• A paid price is a barrier to opting in. Every closed tester has to buy the app. Fewer people will agree, and anyone who doesn't install can't give you much feedback.
• An untested purchase flow is a launch risk. If testers avoid your paywall because they don't want to spend money, your billing code ships with almost no real-device use.

Option 1: Keep in-app purchases testable with license testers

For a free app with in-app products or subscriptions, add your closed testers as license testers as well.

1. In Play Console, go to Settings > License testing.
2. Choose testers with an email list (up to 2,000 addresses per list) or a Google Group (no user limit, according to Google).
3. Save your changes.
4. Make sure the same people can receive your release. Being a license tester doesn't put someone on your closed track. They still need to be in the track's tester list and opt in through the opt-in link. Our guide to inviting testers and fixing access problems covers the common opt-in issues.
5. Make sure your one-time products and subscriptions are published. Google says they must be published before they can be tested.

Once that's done, license testers see test payment methods at checkout. Google's billing guide lists several, including:

• Test instrument, always approves, for a successful purchase.
• Test instrument, always declines, for a failed payment.
• Slow test card, approves after a few minutes and Slow test card, declines after a few minutes, for pending purchases.
• A test instrument that simulates a user-initiated chargeback.

Things that behave differently for license testers

Tell testers about these so their reports make sense:

• Subscriptions renew fast. A monthly or weekly test subscription renews about every 5 minutes, and a yearly one about every 30 minutes. Test subscriptions renew at most six times, not counting free trials and introductory periods.
• Unacknowledged purchases are refunded. Google says a license-tester purchase is refunded after 3 minutes if your app doesn't acknowledge it. If testers report that "the purchase disappeared", check your acknowledgement code first.
• Resubscribe and pause are always on. Google says these features are always enabled for license testers even if you've disabled them in Play Console.

Google also recommends testing with some non-license-tester accounts, either occasionally or after large changes, so your app doesn't depend on test-only behavior.

Option 2: Decide what to do about a paid app price

If your app has an up-front price, you have a few choices. Each has trade-offs.

• Ask closed testers to buy it. This matches Google's rules, but expect fewer people to agree, and be clear with them about the cost before they opt in.
• Use internal testing for early paid-app checks. Internal testers install paid apps free, but an internal test doesn't count toward the 12-tester closed-testing requirement. Google also says people who opt in to internal testing aren't eligible for your closed test, even if they're on its tester list. Our internal vs closed testing guide compares the two.
• Think hard before making a paid app free. Google's pricing article says you can change an app from paid to free, but "once your app has been offered for free, the app can't be changed to paid." To charge again you would need a new app with a new package name. Moving to a free app with an in-app purchase or subscription is a separate product decision, not a testing shortcut.

A pre-test checklist for monetized apps

• Decide whether testers should make purchases, and write it in your tester instructions.
• Add every closed tester to License testing if you want purchases tested without real charges.
• Publish the one-time products and subscriptions you want tested.
• Confirm each tester is on the closed track's tester list and has opted in.
• Check that your app acknowledges purchases, so test purchases aren't refunded after 3 minutes.
• Give testers specific purchase journeys, such as "buy the monthly plan, cancel, then restore purchases".
• Run at least one check with a non-license-tester account before production.

Our free closed-testing checklist covers the rest of the setup.

FAQ

Do closed testers pay for in-app purchases? Yes, unless they're license testers. Google says users are charged for test-track purchases unless they're license testers.

Do license testers count toward the 12 testers? License testing and the closed-test tester list are separate settings. Google's requirement counts testers who are opted in to your closed test. A license tester who isn't on the track and opted in doesn't count.

Can testers use promo codes instead? This article doesn't cover promo codes. Check Play Console Help for the current rules before relying on them.

Does a paid-app closed test affect production access? Google decides production access based on your testing, your app and your answers. The price alone isn't something this article can predict. What helps is a test where testers actually use the app, including the paid features. See what tester activity looks like.

If you'd rather not recruit testers yourself

12Testers14Day provides Google Play closed-testing help: about 14 testers for about 16 days, as a buffer around Google's 12-tester, 14-day requirement. Packages are one-time ($15 Basic for one app, $29 Premium for two, per the pricing page on October 18, 2026). If your app is paid or you want testers to make test purchases, contact the team before you buy so they can confirm what's possible. You can also read how a testing run works.

Official references: Set up an open, closed, or internal test · Test in-app billing with application licensing · Test your Google Play Billing Library integration · Set up your app's prices · App testing requirements for new personal developer accounts

If your new Play Console account won't let you publish to production until you've run a closed test, you've probably come across "12 testers for 14 days". This article covers what Google requires, why developers get stuck on it, and what 12Testers14Day (shown on the site as "12Testers for 14 Days") does about it. It also covers what the service can't do.

Google Play's closed-testing requirement

According to Google's Play Console Help article App testing requirements for new personal developer accounts, personal developer accounts created after November 13, 2023 must run a closed test with at least 12 testers who have been opted in continuously for at least 14 days. Until then, Production and Pre-registration stay disabled in Play Console. Once you meet the criteria, you apply for production access from the Dashboard and answer questions about your testing, your app and whether it's ready for production.

Some details are easy to miss:

• Google describes this rule for personal accounts created after that date. Google's article doesn't apply it to organization accounts. Your own Play Console Dashboard shows whether it applies to you.
• The count is taken when you apply. At least 12 testers must be opted in at that moment, and they must have stayed opted in for the previous 14 days.
• Gaps break the streak. Google says testers who opt out before 14 days don't count, and someone who opts out and later opts back in needs 14 consecutive days.
• Meeting the numbers doesn't end the review. Google says it may ask you to keep testing if you had fewer than 12 opted-in testers or if tester engagement was too low.

Why developers get stuck

On paper the rule is simple. In practice, solo developers and small teams tend to run into the same problems:

• Finding 12 people with Android phones who will actually install a test build. Many developers don't have 12 willing Android users nearby.
• Keeping all of them opted in for 14 days. If even one person leaves early, you can drop below 12 and have to extend the timeline.
• Access problems. Common ones are the wrong Google Account, an opt-in link that isn't live yet, or a tester still enrolled in your internal test. Each of these stops someone from counting.
• Feedback you can use. The production-access questions ask how you tested and what you learned. Testers who install and never open the app give you little to write about.

What 12Testers14Day does

12Testers14Day offers Google Play closed-testing help for Android developers. You keep your app and your Play Console account. The service organizes the testers and the testing window around Google's requirement.

According to the live site, the service:

• Assigns real Android testers. The site says your app runs on real devices used by people, "not automated installs or passive accounts".
• Builds in a buffer. Each package assigns about 14 testers for about 16 days, so one dropout or a late start doesn't automatically put you below Google's 12 × 14 minimum.
• Shows participation and daily progress. You follow tester participation, access questions, daily progress and feedback from one shared workspace.
• Collects structured feedback. Testers follow your instructions, try the journeys you name, and report what they find.
• Helps with the production-access questions. The site provides templates and guidance for writing complete answers to Google's questionnaire. You can also try the free production-access questionnaire tool.
• Delivers a closeout report. At the end you get an organized record of participation, observations and next steps. The site has an illustrative sample report, which is labeled as a sample, not a customer result.

How it works

The How it works page describes four steps:

1. Prepare. Choose a plan and submit your app details: the closed-test link, access instructions (including any login details testers need) and the journeys you want tested.
2. Connect. Follow the setup instructions for your closed test. On the home page, the service says it provides the tester list and setup guidance you need to configure the closed track. Keep the build available and answer any access questions.
3. Follow along. Use your workspace to track progress and answer questions during the window. If you publish a new build, let the service know.
4. Review. Read the closeout report, decide what to fix, and then apply for production access yourself in Play Console.

Packages and pricing

These prices are on the live pricing page as of October 17, 2026:

You buy packages, not a subscription. Agencies or teams with several apps can contact the team about a custom plan.

What 12Testers14Day doesn't do

• It doesn't decide production access. Completing 12 testers for 14 days makes you eligible to apply. Google reviews your account, app, store listing, policy compliance and answers, and makes the decision itself. No testing service can promise approval.
• It doesn't fix the app for you. Crashes, broken builds, login walls without test credentials, or policy problems can still cause trouble. Google says production review isn't a troubleshooting step.
• It doesn't submit anything for you. You set up the closed track, publish the build and submit the production-access application.

If the service itself fails to deliver the agreed testing window, refunds follow the published service guarantee. That page explains what counts as a delivery failure and lists the exclusions (for example a wrong opt-in link, a closed track that isn't live, broken builds, or a Google rejection by itself).

How testers join your closed test

The service supplies the testers, but it helps to know how joining works. On your closed track's Testers tab, Play Console offers two access methods:

• Email list. You add testers' Google Account addresses to a list in Play Console and attach it to the track.
• Google Group. You enter a group address (yourgroupname@googlegroups.com). Google says only members can join, and they must join the group before opting in.

With either method, Google's test setup help says a tester counts only if they're in the track's tester configuration and have actively opted in through the opt-in link. Remember these basics as well:

• The opt-in link only appears when the app's status is Published.
• Testers need a Google Account or Google Workspace account.
• Testers in your internal test aren't eligible for the closed test until they leave the internal test.

When a tester is blocked, work through the checks in Invite testers and fix access problems.

FAQ

Do organization accounts need 12 testers for 14 days? Google's help article describes the requirement for personal accounts created after November 13, 2023. Check your Play Console Dashboard to see what applies to your account.

Does the service guarantee production access? No. Google alone makes that decision.

Can I find testers myself instead? Yes. Google recommends personal and professional networks and communities. The site also runs a free, self-managed tester community if you'd rather coordinate the test yourself.

What should I prepare before buying? You need a closed track with a published build, a working opt-in link, test login details if your app requires sign-in, and a short list of the journeys you want tested. The closed-testing checklist covers these.

Get started

If you'd rather spend the next two weeks on your app than on recruiting testers, review the packages and pricing or read how a testing run works. Then register your app on 12Testers14Day.

Official references: App testing requirements for new personal developer accounts · Set up an open, closed, or internal test