DEV Community

Cover image for Six Build Checks I Run Before Every Google Play Closed Test
Sundar
Sundar

Posted on

Six Build Checks I Run Before Every Google Play Closed Test

#android #googleplay #testing #mobile

Most closed-test problems I get asked about aren't tester problems. They're build problems that look like tester problems. A tester says "it won't install" or "there's no update", and the real cause is a versionCode, a signing key, or a minSdk that quietly shut them out.

So before I upload anything to a Google Play closed track, I run the same short check. Here it is, with the reasoning.

Six build checks before a Google Play closed test

1. Bump the versionCode, every time

Play Console won't accept a bundle whose versionCode has already been used for that app, and testers only get an update when the new code is higher than what they have installed.

// app/build.gradle.kts
android {
    defaultConfig {
        versionCode = 14        // must be higher than the last upload
        versionName = "1.0.3"   // what testers see
    }
}
Enter fullscreen mode Exit fullscreen mode

If you build in CI, derive it from something that only goes up (a build number), not from the date string you might reuse.

2. Upload an App Bundle signed with your upload key

New apps go to Play as an Android App Bundle (.aab), and with Play App Signing Google re-signs what testers download. What you sign with is your upload key. Two things I check:

  • The release build is signed with the upload key registered in Play Console, not a debug key.
  • The build isn't debuggable. Play rejects debuggable bundles. 
./gradlew bundleRelease
# then confirm which certificate signed it
keytool -printcert -jarfile app/build/outputs/bundle/release/app-release.aab
Enter fullscreen mode Exit fullscreen mode

3. Don't mix sideloaded builds with the Play build

This one causes a lot of "App not installed" messages. If a tester sideloaded an APK you signed yourself (debug or a local release key), the Play-signed build has a different signature. Android won't install one over the other.

The fix is boring: ask that tester to uninstall the sideloaded copy, then install from the Play Store link on the opt-in page. Uninstalling the app is fine. Tapping "Leave the program" is the thing to avoid.

Example: common build-side reasons a closed tester can't install

4. Check minSdk and device filters against your testers' phones

A high minSdk, a required hardware feature in the manifest, or a narrow ABI list can make the app "not compatible" with a tester's device. In Play Console, the device catalog for your app shows which devices your current bundle supports. I look there before blaming the tester.

<!-- make optional hardware optional, or some phones get filtered out -->
<uses-feature android:name="android.hardware.camera" android:required="false" />
Enter fullscreen mode Exit fullscreen mode

5. Meet the current target API level

Play sets a minimum targetSdk for new apps and updates, and it moves up roughly once a year. I check the current number in Play Console Help before each first upload instead of trusting memory, because a bundle below it gets blocked at upload time.

6. Send the release to review and confirm it's live on the closed track

Uploading isn't publishing. After I roll out to the closed track, I check the Publishing overview so the change actually goes to review, then wait for the track to show the release as available before I send testers the opt-in link.

What this doesn't fix

None of this gets you production access by itself. For newer personal developer accounts, Google still wants at least 12 testers opted in for 14 continuous days on a closed track, and it reviews the production access application on its own terms. A clean build just means the testers you invite can actually install and stay in.

I keep the full pre-launch list, including the tester side, as a free Google Play closed testing checklist.

Top comments (0)