DEV Community: vmzavas

How to Add Testers in Google Play Console

vmzavas — Tue, 03 Nov 2026 07:30:05 +0000

To add testers in Google Play Console, open your app's closed testing track, go to the Testers tab, add an email list or a Google Group, and save. Then share the track's opt-in link. A tester only counts once they open that link and accept it with the Google account you added.

This guide walks through each step for a closed test, which is the track that counts toward the 12 testers for 14 days requirement on new personal developer accounts. The menu names below match the current Play Console as far as I know; older layouts use slightly different labels for the same pages.

Step 1: open the closed testing track
Select your app in Play Console. In the left menu, open Test and release, then Testing, then Closed testing. In older layouts the same page is under Release, Testing.

You'll usually see a default track called Closed testing - Alpha. Click Manage track on it. You can create more closed tracks later, but one is enough for the requirement.

Don't use Internal testing for this. Internal testing is handy for quick checks with your own team, but the requirement for new personal accounts is about a closed test.

Step 2: add testers on the Testers tab
On the track page, open the Testers tab. You can choose who gets access in two ways: email lists or Google Groups.

With an email list, click Create email list, give it a name and add the testers' Gmail addresses, separated by commas, or upload them as a CSV file. Email lists belong to your developer account, so you can reuse a list for other apps later.

With a Google Group, type the group's email address, for example yourapp-testers@googlegroups.com. Anyone who joins that group gets access, so you don't have to add people one by one. The group must allow people to join, otherwise testers get stuck before they ever reach your app.

Fill in the feedback URL or email address so testers know where to report problems, then click Save changes.

Step 3: make sure the track has a release and countries
Testers can only install something if the track has a release. If you haven't done it yet, create a release on the same track, upload your app bundle and roll it out.

Also check the Countries / regions tab of the track. A tester in a country you haven't selected can accept the invite and still be told the app isn't available.

Then send the changes for review from Publishing overview, if Play Console asks you to. Google doesn't promise a fixed review time. It can be hours or a few days, and new apps often take longer. Testers can't install the app until the release has passed review.

Step 4: share the opt-in link
On the Testers tab, under How testers join your test, you'll find the link to join on the web. Copy it and send it to your testers, together with one line telling them to open it while signed in with the Google account you added.

On that page the tester taps Become a tester, then installs the app from the Google Play link on the same page. Closed test apps don't show up in Play Store search, so this link is the only way in.

If you use a Google Group, send the group link first and the opt-in link second. A tester who skips the group gets a not found or not available message.

Step 5: check that your testers count
Adding an address is not the same as having a tester. Someone counts toward the 12 only after accepting the opt-in link with the same Google account you added. Open your app's Dashboard to see the closed testing progress, with how many testers are opted in and how many days have passed.

If the number is lower than the people you invited, ask who hasn't accepted yet and whether they used a different Google account. Keep a few more than 12, because one drop below 12 can cost you days.

If you don't have 12 people who will stay for 14 days, PeerPlay is a free way to find them: Android developers test each other's apps every day through your real closed track, so they join with your opt-in link like any other tester.

Google Play 16 KB Page Size Requirement: What to Change

vmzavas — Mon, 02 Nov 2026 07:50:56 +0000

Short answer
The 16 KB page size requirement only matters if your app ships native code. Update to a recent Android Gradle Plugin and NDK, update Flutter, React Native or Unity and any SDK with native libraries, rebuild, then confirm in App bundle explorer or APK Analyzer that every library is 16 KB aligned.

If Play Console says your app doesn't support 16 KB memory page sizes, the problem is in native code: one or more .so libraries in your bundle were built for 4 KB pages. Rebuild with up to date tools and libraries so every native library is 16 KB aligned, then upload the new bundle.

Google announced that new apps and updates targeting Android 15 or higher must support 16 KB page sizes on 64-bit devices, with the deadline in late 2025. Check the current wording in Play Console for your app, because Google has given some developers extra time on request. In practice, many developers now meet this warning while uploading builds for closed testing.

Does it affect your app at all?
Only apps with native code are affected. If your app is written only in Kotlin or Java and doesn't include any .so files, it already works on 16 KB devices and you don't need to change anything.

Native code often comes in without you noticing. Flutter, React Native, Unity and most game engines ship native libraries, and so do many SDKs for ads, analytics, image processing, databases and video. To see what you have, open your bundle in Android Studio with Build, Analyze APK and look in the lib folder.

How to check if your bundle is compliant
Play Console shows the status per bundle. Open App bundle explorer, pick the bundle and look for the memory page size information there. This is the quickest check, because it is what Google itself uses.

In Android Studio, APK Analyzer marks native libraries that aren't 16 KB aligned. On the command line, zipalign -c -P 16 -v 4 followed by your APK path checks the alignment of an APK built from the bundle.

To test the app itself, Android Studio offers emulator system images with a 16 KB page size for Android 15 and newer. Run your app on one and go through the main screens. A library that isn't ready often crashes at startup.

What to change for native Android code
Update the Android Gradle Plugin to a recent version. Newer versions package uncompressed native libraries with 16 KB zip alignment for you.

If you compile C or C++ with the NDK, update to NDK r28 or newer, which builds 16 KB aligned libraries by default. On older NDK versions you can add the linker flag -Wl,-z,max-page-size=16384, but upgrading is the cleaner fix.

For prebuilt .so files you don't compile yourself, you need a new version from whoever made them. You can't fix the alignment of someone else's library after the fact.

Flutter, React Native, Unity and third-party SDKs
For cross-platform apps the fix is usually an upgrade. Recent releases of Flutter, React Native and Unity build 16 KB compatible apps, so move to a current stable version of your framework and rebuild. Check your framework's release notes for the exact minimum version, because it changed over 2025.

Plugins and packages count too. A Flutter plugin or React Native library with its own native code needs to be updated separately. If one of them has no compatible version, look for a maintained alternative or ask its maintainer.

After every upgrade, run the App bundle explorer check again. One old library is enough to keep the warning.

Don't let it stall your closed test
If you are in the middle of a 14-day closed test, uploading a fixed build is fine. Opted-in testers get the update through the Play Store, and what counts for the requirement is that 12 or more of them stay opted in every day.

If you need those testers, PeerPlay is a free way to find them. Android developers test each other's apps every day through your real closed track, on real phones, which is also a good way to catch a native library that crashes on some devices.

'Version Code Has Already Been Used' on Google Play: Fix

vmzavas — Sun, 01 Nov 2026 09:37:41 +0000

Your upload was rejected because its version code is one Google Play has already received for that app. The fix is to raise the version code above the highest one you have ever uploaded, rebuild, and upload the new bundle.

The message usually reads: "Version code 1 has already been used. Try another version code." It is one of the most common upload errors during closed testing, because that is when most developers upload several builds in a short time.

Version code and version name are not the same
Every Android build has two version values. The version name, such as 1.0.2, is what users see on the Play Store. The version code is a whole number that only Google Play and Android use to tell builds apart.

Google Play only checks the version code. You can upload 1.0.0 and then 1.0.0 again as long as the second one has a higher version code, and you can't upload 2.0.0 if its version code was already used.

Why it says used when you deleted the release
A version code is taken the moment a bundle is uploaded, not when a release goes live. Discarding a draft release, removing a release from a track or uploading to a different track doesn't free it. Codes are shared by all tracks of the same app, so a build you uploaded to internal testing blocks that number for closed testing and production too.

To see the highest code Play Console knows, open your app in Play Console and look in App bundle explorer. It lists every bundle uploaded for the app with its version code. Your next upload needs a number higher than the top one there.

If you want the same build on another track, you don't need to upload it again. When you create the release, add the existing bundle from your library instead.

Where to change it in your project
Native Android: open app/build.gradle or build.gradle.kts and raise versionCode in the defaultConfig block. React Native uses the same field in android/app/build.gradle.

Flutter: the version code is the number after the plus sign in pubspec.yaml. In version: 1.0.0+3 the version code is 3, so change it to 1.0.0+4. You can also pass --build-number to flutter build appbundle. If the old number still ends up in the bundle, run flutter clean and build again.

Expo: set android.versionCode in app.json or app.config.js. If you build with EAS, it can also increase the number for you on each build.

Unity: open Player Settings, then Other Settings, and raise Bundle Version Code before building the app bundle.

Make sure the new bundle really has the new code
If you raised the number and still get the error, the file you uploaded is probably an old build. Check the date of the bundle, or open it in Android Studio with Build, Analyze APK, which shows the version code of the file.

In CI, a common cause is a version code fixed in the build file while the pipeline uploads a new bundle on every run. Many teams use the CI run number as the version code so it always goes up on its own.

Don't jump to a huge number to be safe. Google Play has a maximum version code, and every future upload has to be higher than your current one, so plain steps of one are the easiest to live with.

Uploading a new build during closed testing
Fixing a bug and uploading a new build during your 14-day closed test is normal, and opted-in testers get the update through the Play Store. What matters for the requirement is that 12 or more testers stay opted in every day.

If you need those testers, PeerPlay is a free way to find them: Android developers test each other's apps every day through your real closed track, so each new build you upload reaches real phones.

12 Testers for a Wear OS App, Watch Face or Android TV App

vmzavas — Sat, 31 Oct 2026 12:18:57 +0000

Most advice about Google Play closed testing assumes a phone app. You post your opt-in link, people install it on their phone, and the 14 days start counting. If you built a watch face, a Wear OS app or an Android TV app, that advice leaves out the hardest part.

The rule for new personal developer accounts is the same: at least 12 testers opted in to your closed test for 14 days in a row before you can apply for production. What changes is who can actually test. Almost everyone who offers to test has a phone. Far fewer people have a Wear OS watch, and fewer still have an Android TV or Google TV device they are willing to install test builds on.

Why phone-only testers are a risk for watch and TV apps
A tester can join your test from any browser with a Google account, so a phone owner can opt in to a watch face test without any trouble. Your opted-in count goes up. But if they have no watch, they never install and never open your app.

Google does not publish exactly how it judges a closed test, so be careful with anyone who promises otherwise. What it does say in the production application is that it wants to know how testers engaged with your app and what you learned. A watch face that 12 people joined but nobody wore is a weak story to tell, and it gives you no real feedback about battery, layout on round screens or how your complications behave.

So for these apps the question is not only how to get 12 testers. It is how to get 12 testers who own the device.

Set up the test for the right device
Before you recruit anyone, check that the build is actually offered to the device. Play Console has form factor settings and separate release tracks for Wear OS and Android TV. If your watch or TV build sits on the wrong track, testers opt in and then see nothing to install on their watch or TV.

Test the path yourself with a second Google account if you can. Opt in from the web link, then open the Play Store on the watch or on the TV with the same account and look for your app. If it is not there, fix that first. Every tester you recruit before this works is a tester you may lose.

Write down the install steps for testers in plain words. For a watch: join from the link on your phone or computer, then open the Play Store on the watch and search for the app, or install it from the phone's Play Store if your watch is listed as a device. For a TV: join with the same Google account that is signed in on the TV, then find the app in the TV's Play Store. Short steps like these save you a lot of messages later.

Where to find people who own a watch or a TV
Start with other developers in the same niche. Watch face and Wear OS developers own watches, because they need them to build and check their own work. A swap between two watch face developers is the most natural swap there is: each of you has exactly the device the other needs. Developer forums for watch faces, including the Samsung developer forum, have threads where people ask for exactly this.

Look in communities where owners already talk about their devices. Subreddits and Discord servers about Wear OS, Galaxy Watch, Pixel Watch and Android TV boxes are full of people who like trying new watch faces and apps. Offer something useful in return, such as free premium access or an early version, and ask only people who say which device they own.

Ask your own users. If you already have a phone app with users, a short in-app or email message asking who owns a Wear OS watch can find testers who already trust you.

Recruit more than 12 and check every day
With phone apps the usual advice is to recruit 15 to 20 people instead of exactly 12, because some never join and some leave. With watch and TV apps the buffer matters even more, because each replacement is harder to find. Start with the bigger group on day one, not after someone drops.

Check your opted-in tester count in Play Console every day. If it drops below 12, the 14 days may have to count again, which costs you weeks on a watch or TV app. Message anyone who has gone quiet, and keep one or two backup testers you can invite the same day.

Ask testers for one short note during the test: which watch or TV model they use, and whether anything looked wrong. That gives you real answers for the production application instead of a vague line about testing.

If you cannot find enough device owners
Do not quietly fill the gap with phone owners who will never install the app. You may pass the count and still have nothing to say about how people used it.

PeerPlay is starting a Wear OS and Android TV package for this exact problem: testers who own your device type, opening your app every day for the 14 days, with nothing to test in return. It is in early access while we build the watch and TV tester group, so you request it from the pricing page and we confirm a start date. If you own a Wear OS watch or an Android TV, you can also join as a paid tester from the same page.

'Signed in Debug Mode' Error on Google Play: How to Fix It

vmzavas — Sat, 31 Oct 2026 08:18:54 +0000

Play Console shows this error when the file you uploaded was signed with Android's debug key instead of your own release key. The fix is to create a release keystore, make your release build use it, and upload the release build again.

The message usually reads: "You uploaded an APK or Android App Bundle that was signed in debug mode. You need to sign your APK or Android App Bundle in release mode." It often shows up right when a developer is trying to get a first build onto a closed testing track, so here is how to find the cause quickly.

Why Google Play refuses debug builds
Android Studio creates a debug keystore automatically on every developer's computer, usually at .android/debug.keystore in your home folder, with the well-known password android. It exists so you can run builds on your own phone without any setup.

Because every machine has its own throwaway debug key with the same public password, it can't identify you as the publisher of an app. Google Play needs every upload signed with a key that belongs to you, so it rejects anything signed with the debug certificate.

Step 1: check which key signed the file
Before you change anything, confirm what you uploaded. In a terminal, run keytool -printcert -jarfile app-release.aab, using the path to your bundle. keytool comes with the JDK that Android Studio uses.

Look at the Owner line. If it says CN=Android Debug, O=Android, C=US, the file was signed with the debug key. If it shows the name you entered when you created your release key, the signing is fine and you probably uploaded a different file than you think.

Step 2: build the release variant with your own key
In Android Studio, don't use the Run button or a plain build for this. Open Build, choose Generate Signed App Bundle or APK, pick Android App Bundle, and create a new keystore if you don't have one yet. On the last screen choose the release variant.

If you build from the command line, run gradlew bundleRelease. A debug task such as assembleDebug or bundleDebug always uses the debug key.

If you have no release keystore at all, this is the moment to create one and store it safely, together with its passwords. Every future update has to be signed with the same upload key.

Step 3: check the release block in Gradle
If you ran a release build and still got the error, open android/app/build.gradle or build.gradle.kts and find the release entry under buildTypes. If it says signingConfig signingConfigs.debug, your release build is signed with the debug key on purpose.

This is the default in new Flutter and React Native projects. Both templates sign release builds with the debug key until you change it, with a comment telling you to add your own signing config. So flutter build appbundle produces a release build that Google Play still rejects.

Add a release entry under signingConfigs with your keystore path, store password, key alias and key password, then set the release build type to signingConfigs.release. Keep the passwords in a key.properties file or environment variables that aren't committed to your repository.

Step 4: if it only fails in CI
If local builds are fine but builds from GitHub Actions or another CI service are rejected, the signing secrets are probably missing on the runner. Some build scripts quietly fall back to the debug key when the keystore variables are empty, so the build passes and Play Console rejects the file.

Check that the secret names in your CI settings match the names your Gradle file reads, and that the decoded keystore file exists where the build expects it. Then run the keytool check from step 1 on the file the CI produced.

Once Play Console accepts the bundle, the next step for a new personal account is usually the closed test with 12 opted-in testers for 14 days in a row. PeerPlay is a free way to find those testers: Android developers test each other's apps every day through your real closed track.

Tester Can't Find Your App From the Opt-In Link: Fixes

vmzavas — Fri, 30 Oct 2026 11:07:13 +0000

If a tester opens your opt-in link and Google Play says the app can't be found, the most common cause is that the Play Store on their phone is signed in with a different Google account than the one on your tester list. The next most common is a closed release that isn't live for testers yet.

On PeerPlay this is one of the first problems testers report. In one paid campaign this month the very first report a tester sent was "please fix your google group, I am seeing content not available." The app was fine. The door to it wasn't. Here is how to find which door is stuck.

What the tester actually sees
The wording varies by device and by where the tester is in the flow. On the Play Store it is often "Item not found" or a message that the app isn't available. On the web opt-in page it can be a page saying the content or app is not available, or a page that never shows the Become a tester button.

A different message, that the app isn't compatible with the device, is a separate problem: the tester reached your app, but their phone doesn't meet your app's requirements. That one is about your minimum Android version or required features, not the opt-in.

Cause 1: the wrong Google account
Many people have more than one Google account on their phone. They accept your invite in the browser with one account, and the Play Store app opens with another. To Google Play that second account is a stranger, so the app doesn't exist for it.

Fix for the tester: open the Play Store, tap the profile picture and switch to the account that is on the tester list. Then open the opt-in link again in a browser signed in with that same account.

Cause 2: not really on the list
If you use an email list, the tester's exact Gmail address has to be on it, and the list has to be attached to the closed track. If you use a Google Group, the tester has to actually join the group first, and the group has to be attached to the track.

Group settings cause a lot of these reports. A group that only accepts invited members, or where join requests wait for approval nobody gives, keeps testers out before they ever see your app. Make sure anyone with the link can join, or approve requests quickly.

Cause 3: the release isn't live for testers
Testers can only install a release that has been rolled out to the closed track and has finished Google's review. While it is in review, or if it was saved but never sent for review, the opt-in link can lead nowhere.

Fix for the developer: open the closed track in Play Console and check the release status. If it is still in review, tell testers to wait and try again later rather than retrying every few minutes.

Cause 4 and 5: country and timing
Closed tracks have their own country and region availability. If the tester's Play Store country isn't selected, they can be fully opted in and still be told the app isn't available. Add their country to the track instead of asking them to change their Play Store country.

Sometimes nothing is wrong and the Play Store simply hasn't caught up. After a tester opts in, it can take a while before the app shows up for them. If everything above checks out, the tester can wait, clear the Play Store app's cache in Android settings, and try the link again.

A quick checklist
For the tester: same Google account in the browser and in the Play Store, joined the Google Group if there is one, opened the opt-in link and tapped Become a tester, then installed from the link on that page, not from Play Store search. Closed test apps don't show up in search.

For the developer: release rolled out and out of review, tester email or group attached to the closed track, group open to joining, and the tester's country selected. On PeerPlay, testers can send a Google Group Error, Broken Download Link or Not Available in My Country report, which tells you which of these to look at first.

Apply for Production Missing After 14 Days? Check This

vmzavas — Thu, 29 Oct 2026 18:35:38 +0000

If the Apply for production button is missing after 14 days, the most likely reason is that Play Console doesn't count 14 days yet. Your own calendar and Google's count often start on different days, and any day below 12 opted-in testers breaks the streak.

This is one of the most common questions from developers at the end of a closed test. Here is where the button should be, the reasons it doesn't show up, and what to do about each one.

Where the button should be
Open Play Console, select your app and go to its Dashboard. For personal accounts that need closed testing, the Dashboard shows the closed testing requirement with your progress: how many testers are opted in and how many days have passed. Once both conditions are met, that is where Apply for production appears.

Make sure you are looking at the right app. If you have more than one app in the account, each one has its own closed test and its own count. Testers on app A don't help app B.

Reason 1: your 14 days started later than you think
The count doesn't start when you create the closed track or share the opt-in link. In practice it starts on the day you first have at least 12 testers opted in. If testers trickled in over the first week, your 14 days may have started on day 6 of your own calendar.

Look at the progress on the Dashboard rather than your own notes. If it says fewer days than you expected, this is almost always why. The fix is simply to keep testers opted in until the count reaches 14.

Reason 2: you dropped below 12 at some point
The requirement is 12 or more testers opted in for 14 days in a row. If someone opted out and your count fell to 11, even for a day, the streak may have been broken. A tester who removed themselves from your Google Group or email list, or who left the test from the Play Store, counts as gone.

Check your opted-in count now. If it is below 12, recruit replacements first. Keep a buffer above 12 so one drop-out doesn't cost you days again. If you need replacements quickly, PeerPlay is built for this: Android developers test each other's apps every day, through your real closed track.

Reason 3: testers aren't really opted in
A tester on your list is not the same as an opted-in tester. Each tester has to open your opt-in link and accept it with the same Google account that is on your list. Testers who only received an invite, or accepted with a different account, don't count.

Also check that your closed track has a release that is actually available to testers. If the release is still in review or was never rolled out, testers can't properly join the test.

Reason 4: your account doesn't need it
Not every account sees this flow. As far as Google documents it, the closed testing requirement applies to personal developer accounts created on or after November 13, 2023. Organization accounts don't have it, so there is no Apply for production step: they can publish to production directly.

If you have an organization account or an older personal account, look for the Production track instead of waiting for a button.

If everything looks right
If the Dashboard shows 12 or more testers and 14 days, and the button still isn't there, give it a day. Play Console counts aren't always updated in real time. If it is still missing after that, contact Play Console support from the Help menu with screenshots of your tester count and track.

When the button does appear, the application asks how you ran the test, what feedback you got and what you changed. Prepare those answers during the 14 days, not after.

How Peer Testing Verifies a Tester Really Used Your App

vmzavas — Thu, 29 Oct 2026 13:11:50 +0000

A question I get from almost every developer who tries PeerPlay: how do you know a tester really used my app, and didn't just install it to look busy? It is a fair question. Google's closed testing requirement asks for 12 testers opted in for 14 days in a row, and a tester who installs and forgets is worth very little to you.

So here is exactly what PeerPlay checks today, based on how the app's code works, and, just as important, what it cannot check.

A test starts in PeerPlay and opens your app
A tester can't count a day by opening your app from the home screen. They tap Start Test on your app's card in PeerPlay, and PeerPlay launches your app. From that moment PeerPlay counts the time the tester spends away from PeerPlay, which in practice is time in your app.

The target is 30 seconds a day. When it is reached, the day counts. If the tester comes back too early, the test isn't thrown away. They see a message like "Counted 12s of 30s. Tap Continue and keep playing to finish today's test", and the counted seconds wait for them. A live timer notification on the phone shows how far along the test is.

Two bugs that taught me how real testing looks
The first version reset the count every time the tester left your app for a moment. An ad, a permission dialog or a quick glance back at PeerPlay sent the timer back to zero. For ad-heavy games that made the test practically impossible to finish, even for a tester doing everything right. Now every stretch in your app adds up toward the 30 seconds.

The second one came from phones, not testers. Some phones, often in a game mode, kill background apps to free memory, and PeerPlay was one of them while the tester was playing. The time spent was lost. Now PeerPlay recovers that session on its next start and still counts the time the tester was away.

Signals against gaming the system
Hopping through apps as fast as possible doesn't work well. After a test, PeerPlay puts a short cooldown on the Start Test button, so a tester can't start one app after another in rapid fire. Continuing an unfinished test skips the cooldown, because that is real testing.

Every counted test records the device model, the Android version and whether Android reports the device as a physical phone. Emulators, virtual devices and bots are not allowed on PeerPlay.

Testers who join a campaign and walk away are recorded too. Each tester's profile shows a quit counter, the number of campaigns they joined and abandoned, so you can see who has a habit of leaving.

What no testing app can prove
Here is the honest limit. PeerPlay doesn't see the tester's screen and doesn't read what they do inside your app. It knows your app was launched from PeerPlay and that the tester stayed away from PeerPlay for at least 30 seconds. That is a strong signal of a real session, but it is not proof that every one of those seconds was spent looking at your app.

Any service that claims to prove more than that is either installing something much more invasive on the tester's phone, or overselling. The daily open, the device record and the quit counter are there to make lazy testing hard and visible, not impossible.

What to check on your side
Use your own analytics. If you have Firebase Analytics or a similar tool in your app, your daily active users during the test should roughly match the number of testers opening it. If PeerPlay shows 15 testers a day and your analytics shows 3 sessions, something is off, and you should tell me.

Read the feedback. A tester who writes "I had to tap several times before anything happened" was in your app. A tester who has written nothing after a week might still be opening it, but you know less about them.

And watch your opted-in count in Play Console every day. PeerPlay can make sure testers open your app, but the number Google counts toward the 14 days lives in your console.

We Paid Our First Two Testers. Here's What It Took.

vmzavas — Wed, 28 Oct 2026 20:09:18 +0000

For weeks, the PeerPlay tester page has said that Pro testers get paid to PayPal once their balance reaches $5. This week that stopped being a promise. On October 27 and 28, 2026, I sent the first two payouts.

They are small: $5.05 each, $10.10 in total. But they are real money, sent to two real people who opened paid apps on their own phones day after day so that developers could get through Google Play's closed testing requirement. Here is exactly how it went, including the part that didn't work the first time.

The two payouts
The first request was paid on October 27 at 16:22. The tester was testing on a Samsung Galaxy S20+ running Android 12. The whole $5.05 came from testing.

The second was paid on October 28 at 19:35, to a tester on an Infinix phone running Android 14. Their $5.05 included $2.00 from referrals, for developers they referred to PeerPlay. The rest came from testing.

In my admin panel that adds up to two requests, two paid out, nothing pending, and $10.10 in total. I sent both with a short note: "Peerplay payout. Tnx for testing."

How a tester gets to $5
On PeerPlay's paid (VIP) campaigns, a Pro tester earns $0.05 for every day they test an app. Testing means opening the app from PeerPlay and using it for about 30 seconds. If they test on 12 of the 14 campaign days, including day 13 or 14, they also get a $0.30 bonus once day 14 has ended. That is up to $1.00 per app per campaign.

So $5 is not a click-and-collect amount. It means several paid apps tested day after day, often in parallel. That is exactly what the developers paying for those campaigns need: people who are still there on day 14.

How a payout actually happens
There is no automatic payout robot behind this yet. When a tester's balance reaches $5, they request a payout from their profile in the app. The request lands in my admin panel, next to the PayPal email the tester gave when they applied as a Pro tester and the physical device they test on.

I check the request, copy the PayPal address and send the money by hand from my own PayPal account. Then I mark the request as paid. It is slow compared to a fully automated system, but at this stage it means I look at every payout before it goes out, and I would rather catch a mistake than automate one.

It also means I see the same thing the developers paying for campaigns care about: every payout is tied to a real device and a real tester, not to an anonymous account.

The payout that bounced
One of the two payouts didn't go through on the first try. PayPal declined it because the tester's account had reached its receiving limit. Some PayPal accounts can only receive a certain amount until the owner confirms more details. Nothing was wrong with the payout itself. The tester lifted the limit in their PayPal account, and the second attempt went through.

If you are a tester, check this before you request a payout. Open your PayPal account and make sure it can receive money, especially if it is new or you have never been paid into it before. It saves a day of back and forth.

What it cost on my side
I'm in Serbia, so I paid from a card in Serbian dinars. Each $5.05 payout cost me RSD 556 through PayPal's own conversion, and PayPal notes that its rate includes a currency conversion fee. For a tester the amount is the same $5.05. For me, the conversion is a small extra cost on every payout, and I'll take it into account as payouts grow.

Why this matters to developers
When a developer buys a paid campaign, part of that money is supposed to reach the testers. These two payouts are the first proof that it does. The testers were on ordinary phones, a Samsung from a few years ago and a newer Infinix, which is the kind of device mix a closed test should see.

If you want to be one of the next testers paid, install PeerPlay on a real Android phone and apply as a Pro tester in your profile. Applications are reviewed by hand, emulators are not allowed, and only apps with the PRO badge pay. Make sure your PayPal account can receive money, and test every day.

Inside 7 Live Closed Tests: What Testers Found So Far

vmzavas — Wed, 28 Oct 2026 08:55:32 +0000

Seven VIP campaigns are running on PeerPlay this week. These are paid Google Play closed tests: a developer pays for a package of tester slots, and those testers open the app every day for 14 days while the developer works toward production access.

This morning, October 28, 2026, I took screenshots of my Discovery screen, where six of them sit next to each other. I won't name the apps or the testers. But the screen says a lot about what really happens during the 14 days, so here is what I see.

The six campaigns on one screen
A sudoku puzzle game, launched six days ago: full, 20 of 20 testers. One piece of feedback so far.

A card games app, launched a week ago: full, 20 of 20. Seven pieces of feedback.

A Halloween-themed game, about two weeks in: full, 20 of 20. Seven pieces of feedback.

A Christmas-themed game from the same developer, launched today: one slot left.

A Spanish learning app, launched two days ago: full, 15 of 15. Two pieces of feedback.

A dating app, launched four days ago: 14 slots still open, nine pieces of feedback, and three issue reports from testers on its card.

Slots fill fast, unless something blocks the door
Most of these campaigns are full, and the newest game filled all but one slot on its first day. When the setup works, getting testers to join is not the hard part.

The dating app is the exception, and its card shows a likely reason. Testers have reported all three issue types PeerPlay lets them send: a Google Group error, a country availability problem and a broken download link. A tester who can't get in doesn't take a slot, and the campaign waits. If your tester count is stuck, check your group settings, your track's countries and your opt-in link before you blame the audience.

What testers actually wrote
The Halloween game is the furthest along, so its feedback shows the whole arc. In order, from the first week:

First, a bug report: "please fix your google group, I am seeing content not available." The first problem was not in the app at all. It was the door to the app.

Then praise, as a star report: "Love Halloween UI."

Then the hard one: most features felt unresponsive, and the tester had to tap several times before anything happened. The same tester followed up two minutes later with a star report: the colour palette is good, but the app needs a tutorial at the start, because it is too confusing.

Then two very different star reports. One said "Best app I ever tried." The other said "consider increasing the ui elements size."

What a developer can take from this
Expect setup problems first. In this campaign the first report was about the Google Group, and on the dating app three reports are about getting in. Test your own opt-in link from a fresh Google account before day one.

The useful feedback is specific. "Best app I ever tried" is nice to read and tells you nothing. "Tap several times before anything happens", "needs a tutorial" and "make the UI elements bigger" are three things a developer can fix and then mention in the production application, where Google asks what you learned from testing.

One tester can give you most of it. The unresponsiveness report and the tutorial suggestion came from the same person, two minutes apart. When a tester writes in detail, reply and ask a follow-up question while they still remember.

One report was about us
Not every piece of feedback is about the app being tested. A few days into the Halloween campaign a tester wrote: "I am testing every day and the system says I didn't reach the goal." That one is about PeerPlay's own day counting, not the developer's app.

I'm leaving it in because it is honest and common. Day counts depend on time zones and on when a test is recorded, and I wrote a whole post after a tester was counted from day 2 because his first test landed just after midnight. If your testers say the count looks wrong, check the boundary before assuming they skipped a day.

I'll come back to these campaigns when they finish and write about how many of them get through Google's production review.

Firebase App Distribution vs Google Play Closed Testing

vmzavas — Tue, 27 Oct 2026 13:53:27 +0000

PeerPlay runs on Firebase: the app's data lives in Firestore, the server logic runs in Cloud Functions, and this blog is served from Firebase Hosting. So when developers ask whether Firebase App Distribution can replace Google Play closed testing, I understand the appeal. It is fast, it is free, and it is already in the console you have open.

The short answer is no, not for the 12 testers, 14 days rule. The longer answer is that the two tools do different jobs, and many developers end up using both. Here is how they compare, and how to avoid the one trap that comes with mixing them.

What each tool is for
Firebase App Distribution sends a build of your app directly to people you invite. You upload an APK or app bundle, add testers by email or share an invite link, and they install it, usually through Firebase's App Tester app. There is no store listing and no Play review, so a build can reach testers within minutes of uploading.

Google Play closed testing runs through Play Console. You upload a build to a closed track, add testers by email list or Google Group, and they opt in through your link and install the app from the Play Store, exactly like a real user would. Builds usually go through Google's review before testers get them.

Only one of them counts toward the 12
For newer personal developer accounts, Google asks for at least 12 testers opted in to a closed test for 14 days in a row before you can apply for production. That count lives in Play Console, on your closed testing track. Google has no way to see who installed your app through Firebase App Distribution, so those testers don't count, however many there are and however often they open the app.

As far as Google documents it, internal testing doesn't count either. It has to be a closed track. If your goal is production access, your 12 testers need to be opted in there.

Where App Distribution still wins
Speed. If you want a designer, a friend or a single bug reporter to try a fix today, App Distribution gets it to them before a Play review would even start. It is a good fit for the days before your closed test, when the app still changes every few hours and you only need two or three people looking at it.

Less setup for the tester. They don't need to be on a tester list in Play Console or find your app through an opt-in page. They follow an invite and install. For a quick look, that is much less friction.

Separate audience. You can keep a small inner circle on App Distribution for rough builds while your closed testers on Play only get the stable ones. That keeps your 12 testers away from the build that crashes on launch.

The trap: two builds, one phone
If one person is in both groups, watch the signing key. A build from App Distribution is usually signed with your own key. A build from the Play Store is signed by Google if you use Play App Signing. Android won't install one over the other when the signatures differ, so the tester has to uninstall first.

That uninstall is where closed tests get hurt. The tester removes your Play build to try the App Distribution one, forgets to reinstall it, and stops opening the app from the Play Store for the rest of the test. If you use both tools, keep your 12 closed testers on the Play build only, and use different people, or a separate debug package name, for App Distribution.

A simple way to use both
Use App Distribution while the app is still rough, for fast builds to a handful of people. Once it is stable enough that a stranger could use it, upload it to a closed track and start recruiting for the 14 days. After that, ship updates to the closed track as you normally would. Updating mid-test does not reset the count, as long as your testers stay opted in.

And if the hard part is not the tool but finding 12 people who stay for 14 days, that is the problem PeerPlay is built for: developers test each other's apps from the Play Store, through each app's real closed track.

Who Can Be a Google Play Tester? Country, Device, Account

vmzavas — Mon, 26 Oct 2026 08:14:05 +0000

PeerPlay has a Report an Issue button on every app a tester joins. It offers three choices: Broken Download Link, Google Group Error, and Not Available in My Country. The third one exists because a tester can do everything right, accept the invite, open the link, tap install, and still be told the app is not available to them.

For Google Play's 12 testers, 14 days requirement, that tester doesn't count, no matter how willing they are. So before you count someone toward your 12, check four things: their account, their country, their device and their account type.

A Google account on your list Every closed tester needs a Google account, and that account has to be on your tester list, either added by email in Play Console or as a member of a Google Group you attached to the track. Then they have to accept through your opt-in link.

The common trap is a phone with more than one Google account. The tester opts in with one account in the browser and the Play Store app is signed in with another. Ask testers to opt in with the same account they use in the Play Store on that phone.

If you use a Google Group, check that its join settings actually let testers in. A group that only accepts invited members, or one where join requests wait for an approval nobody gives, stops testers before they ever reach your opt-in link. That is the problem PeerPlay's Google Group Error report is there to catch.

A country your track is available in Closed testing tracks in Play Console have their own country and region availability. If a tester's Play Store country is not on that list, they can be fully opted in and still see that the app is not available. Check the track's country settings before you recruit, especially if you only picked your home country when you set it up.

A tester's Play Store country is tied to their Google account and payment profile, not to where they happen to be today, and Google limits how often it can be changed. Don't ask testers to switch it. Open your track to their country instead.

On PeerPlay, developers set Target Countries when they add an app, either All Countries or a list of country codes, and testers see it under Requirements Info before they request to test. Not Available in My Country is the report a tester sends when that still goes wrong.

A device your app supports Your app's minimum Android version, required hardware features and supported screen types decide which phones can install it. A tester on an older Android version or a phone without a feature your manifest requires may find the app missing or marked as not compatible.

Know your own requirements before you recruit, and say them up front. PeerPlay's app form has a Supported Devices field, which defaults to All Android Devices and suggests entries like Android 8.0+ or Tablets. Testers also need a real Android phone with the Play Store. iPhones can't install a Play test, and PeerPlay doesn't allow emulators.

An account that can install apps Not every Google account behaves like a personal Gmail account. Work and school accounts are managed by an administrator, who may limit or block the Play Store. A tester who signs in with their work account may not be able to install anything outside what their employer allows.

Children's accounts are another case. Google accounts have a minimum age that varies by country, and younger users usually have supervised accounts where a parent controls what can be installed. Don't build your 12 on accounts whose installs someone else has to approve. When in doubt, ask testers to use a personal Google account.

Check before you count
In the message where you share your opt-in link, ask two quick questions: which country is your Play Store set to, and which Android version is your phone on? It takes a tester ten seconds and saves you days.

Ask each tester to confirm that the install actually worked, not just that they joined. Then compare your opted-in count in Play Console with your list on day 1. If someone can't install, replace them that day rather than hoping it fixes itself, and keep a few testers above 12 for exactly this reason.