12 Testers for a Wear OS or Android TV App: What Counts

The Short Answer

Short answer: there is no wearable exemption and no television exemption. A personal developer account created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for 14 days before it can apply for production access. Google's help page states it in app terms and never splits it by form factor. What changes for a Wear OS or Android TV build is not the rule but the number of people who can actually install it.

That creates two separate problems, and they fail in different ways. The first is install reach: a tester can opt in to your closed test and still be unable to install anything, because your build only ships to watches or to television hardware. The second is a review that most phone apps never meet: after your 14 days, the Wear OS or TV part of the listing goes through its own approval before it becomes discoverable, and a rejection there does not stop the phone build from going live.

The tester condition applies to personal accounts created after 13 November 2023. If your account predates that or is an organisation account, the tester gate may not apply to you at all, but the form-factor review still does. Google Play Personal Apps: Do They Skip the 12-Tester Rule? covers which accounts are in scope.

Why Is a Watch or TV Build Harder to Test Than a Phone Build?

The requirement is defined per app; installation is decided per device. A phone in a tester's pocket is not a Wear OS watch and is not an Android TV box. Google's Wear documentation is blunt about the split: "Wear OS APKs are separate from mobile APKs, and are uploaded and updated independently from within the Play Console." The watch build is its own artefact, delivered to its own device class.

1. The tester opts in to the closed test with the same Google account their device uses.
2. Google Play recognises your app for that form factor: a watch APK on the release, or a leanback launcher for TV.
3. The release's country list and device filters both allow that specific device.
4. The tester installs from the Play Store on the watch or TV, or remotely from the Play Store on a phone or desktop.
5. Twelve testers stay opted in for 14 continuous days; a late install does not backfill earlier days.

Step 2 is where most watch and TV campaigns lose their fortnight. The Play Store app on a phone will not offer a watch-only build, and Play on a TV will not show an app that has no leanback launcher. Testers read both outcomes as "your link is broken" and stop replying, while Play Console still shows them as opted in.

What Does Google Actually Count?

The rule is written in opt-in language, not install language. From App testing requirements for new personal developer accounts:

Two words carry the whole sentence: opted in. A tester who joins your list and never manages to install anything still moves the opted-in number, and the clock still runs. That is exactly why a niche form factor feels like it is working right up until you apply.

The application form, however, is not written in opt-in terms. Google's own description of the "About your closed test" section lists what you must supply: "Select an option indicating how easy it was to recruit testers for your app", plus "Whether testers used all available app features" and whether tester usage "matched expected production user behavior". A watch app where half the testers never opened it on a watch is difficult to describe honestly in that form.

In our analysis of 1,500+ closed-testing campaigns, the ones that stall at the application stage are rarely short of opted-in testers. They are short of installs they can point to. That is an observation from our own campaign records, not a Google statistic, and it does not establish causation.

Google does not publish a numeric threshold for installs, sessions or engagement in its testing documentation, so treat installs as the target because the form asks for evidence of use, not because there is a hidden number to clear. Anyone quoting you one is guessing.

Can Phone Testers Satisfy the Requirement for a Wear OS App?

Sometimes, and the condition matters. If the watch build sits on the same listing as a phone app with the same package name, then a tester with an ordinary Android phone installs the phone APK and is opted in to that app. Google's documentation requires exactly that arrangement when you ship both: "If you have a phone APK in addition to a watch APK, you must use the Multi-APK delivery method to manage both", and it recommends the same package name and the same store listing because it links the watch app to the phone app's reviews and ratings.

For Play to treat your build as a Wear OS app at all, the manifest needs a direct child <uses-feature android:name="android.hardware.type.watch" />, and the app must declare whether it is standalone through com.google.android.wearable.standalone. Set that to false and the app still downloads, but it needs its companion phone app to be usable.

What the phone-APK route does and does not do: it keeps 12 humans opted in and the clock moving, and it gives testers something real to use. It does not install your watch APK anywhere, and it does not answer a reviewer asking what the watch experience was like. Google does not publish a form-factor-specific counting rule, so treat this as a way to keep the requirement satisfied while you line up real watch installs, not as a substitute for them.

One warning, because this is where the shortcut turns into a rejection. Google's functionality, content and user experience policy says: "We do not allow apps that only have limited functionality and content", and lists "Apps that are designed to do nothing or have no function" among the violations. A companion that handles watch-face configuration, settings, sync, history or account pairing has a reason to exist. A screen with your logo and a "connected" label does not.

A different package name also breaks the trick: a different package is a different app with its own store listing, its own closed test and its own 14 days.

How Do You Make a TV Build Visible Before You Recruit?

TV has the same shape of problem with a different filter. Google's TV build guidance warns that the launcher declaration is not optional: "If you don't include the CATEGORY_LEANBACK_LAUNCHER intent filter in your app, it's not visible to users running Google Play on TV devices." It repeats the point for hardware: unless the manifest declares that a touchscreen is not required, "your app doesn't appear in Google Play on TV devices."

Three things are worth fixing before you invite a single tester:

• A <category android:name="android.intent.category.LEANBACK_LAUNCHER" /> intent filter on your TV activity, so Play recognises the app as a TV app.
• A home screen banner at 320x180 px in drawables/xhdpi for each language you support, with the app name in the artwork.
• android.hardware.touchscreen declared as not required, so a device with no touch input is not filtered out.

TV app quality adds one more measurable condition: the app must support commonly used Android TV devices by setting minSdkVersion to 31 or lower, and every control has to work on a five-way D-pad. Both are checked during review, not by Play's installer, so a build can install and still fail the quality bar.

The tester side is unchanged in principle: the TV or Google TV device must be signed in with the same Google account that opted in, and the install happens from the Play Store on that device. If you already ship a phone app on the same listing, the multi-APK logic from the Wear OS section applies identically — phone testers opt in, but only TV owners produce TV installs.

Which Review Runs After Your 14 Days?

For Wear OS, adding the form factor is a Play Console step, not a build step: Test and release > Advanced settings > Form factors > Add form factor > Wear OS, which also asks for Wear screenshots. Once a release is in your closed testing track, you opt in to Wear OS and agree to the review policy in the same menu, then start the rollout. Until that opt-in happens the watch build is not distributed, which is a common reason testers report "nothing to install" on an otherwise healthy closed test.

That review has three states: Pending, Approved, and Not approved. Only an approved Wear OS listing becomes discoverable to Wear OS users. Google documents the rejections it sees most often:

• The store listing never mentions "Wear OS".
• No screenshot of the app running on a Wear OS device.
• Layouts that break on a round display, with no stated limitation.
• Basic functionality broken, or screenshots that do not match the app.
• Missing Wear functionality requirements, such as malformed Wear notifications or no RemoteInput for messaging replies.

Watch faces are not exempt from anything here. Per Wear OS app quality, since January 2026 the Watch Face Format is required for installing watch faces on Wear OS devices, and since 15 September 2026 Wear OS apps must support 64-bit devices. A watch face that fails those two will not install for a tester regardless of how many people opted in.

Practical consequence: your timeline is 14 days plus a review, and the review can come back negative after production access was already granted for the phone app. The phone listing stays live, the Wear or TV section shows Not approved and stays invisible to those users, and the loop is fix, opt in again, publish, wait.

How Do You Recruit Testers Who Own the Hardware?

Recruit on hardware ownership, not on willingness. The expensive mistake is adding twelve helpful people and discovering on day three that three of them own an Apple Watch and two only have a TV with a cast-only dongle.

• Screen with two questions: which watch model do you own, or which TV device, and is it signed in with the Google account you will test with. A Galaxy Watch running Tizen or an Apple Watch cannot install a Wear APK.
• Start with your own phone users if the listing already has a phone app. An in-app invitation converts people who already use the product, and many of them own the watch or TV.
• Go where the devices are: the Wear OS and Android TV communities on Reddit, watch-face design forums and XDA TV threads. Ask for the model in the reply rather than in a follow-up.
• Over-recruit by three or four. Fifteen or sixteen people protects the twelve you need when someone sells the watch, swaps phones or goes quiet for a week.
• Keep one channel for the tester list so opt-ins are easy to audit. Email list vs Google Group for Google Play Closed Testing covers which one leaves a cleaner record.

If you are considering paying for testers, ask the service one question before you pay: can your testers install on a Wear OS watch or an Android TV device, and will you show me the installed-device evidence. A pool of phone testers will happily opt in and never touch your form factor. Are Paid Google Play Tester Services Worth It? sets out what to demand in writing.

How Do You Check That Installs Actually Happened?

The Testers tab gives you an opted-in count, and that number will not tell you whether anyone installed anything. The cheapest early warning is the feedback filter: Google's testing feedback page lets you filter by "criteria such as date, language, reply state, app version, or device type". If the device-type list never shows your watch or TV build, you have opt-ins without installs, and you still have time to act.

Two more checks are worth doing weekly. First, look at installed audience rather than daily actives: with a dozen testers, installed audience versus DAU tells you whether people are still running the build or only opened it once. Second, keep the release's device list honest — a tester whose device is excluded sees a compatibility message rather than your app, and that message has its own causes that are not always about hardware.

Small numbers are normal here. A watch app with 12 opted-in testers may legitimately show fewer installs than opt-ins, and that is a healthy result. Zero is not.

Questions Developers Ask About Watch and TV Testing

Does a watch face need 12 testers? Yes, if your account is a personal account created after 13 November 2023. Google treats watch faces as Wear OS apps for the closed-testing requirement, and the Watch Face Format requirement applies to them as well.

Can phone testers satisfy the requirement for a Wear OS app? They can keep the opted-in count and the clock moving when the phone APK shares the package name and listing. They do not install the watch build, and they say nothing about the watch experience in your application.

Can testers install on an emulator to fill the twelve? No Google document describes emulator installs as part of a closed test, so do not build a 14-day window on one. Use emulators for your own QA on round displays and TV resolutions, and put real hardware behind the twelve.

Do I need a separate closed test for the TV version? No. It is the same app and the same track; you add the form factor and pass TV quality. A separate package name would be a separate app with its own closed test.

What happens if the Wear OS review is rejected after production access? The phone build stays live. The Wear OS section shows Not approved and stays invisible to Wear users until you fix the issues, opt in again and publish another review.

Is the 14-day window different for TV apps? No. Same 12 testers, same 14 continuous days, same application form.