Get your 12 testers for Android, and security-check your app before Google reviews it

Google Play's 12 testers requirement, precisely

If you created a personal developer account after 13 November 2023, you can't publish to production until you have run a closed test with at least 12 testers opted in, continuously, for 14 days. The full breakdown of the 12 testers, 14 days rule takes each word apart; this is the short version.

The engagement trap: why 12 opt-ins isn't the finish line

Meeting the count lets you apply; it doesn't get you approved. The production access application asks three sets of questions:

1. 1. About your closed test

   How you recruited testers, how easy that was, how engaged they were, and a summary of their feedback.

2. 2. About your app

   Its intended audience, the value it provides, and expected installs in its first year.

3. 3. About your production readiness

   What you changed during the test, and how you decided the app was ready.

A developer who borrowed 12 inactive accounts has nothing true to write in the first or the third. That is the trap. How to answer the production access questions goes through each one.

What Google verifies

Google does not publish the signals it uses to judge engagement, and any page that lists them is guessing. The working assumption that holds up: Google runs the store, the track and the install, so it can see whether testers installed through Play and whether the app was used, and it has said it can refuse production access when testing looks insufficient. Plan for a test that would survive a person reading your answers.

The failures we see most

To check that your own test device installed from Google Play rather than a sideload:

adb shell pm list packages -i com.your.app
# package:com.your.app  installer=com.android.vending   <- installed from Google Play
# installer=null, or a file manager                      <- sideloaded

Step by step: from closed track to production access

Security audit for your app: a MASVS checklist before closed testing

Why audit before the closed test, not after launch

• An APK is public from the first install. Your testers download the same binary the world will. Hardcoded keys, backend URLs and debug flags are readable with free tools in minutes, so a key leaked on day 0 of testing is already compromised.
• Some findings block the release, not just the risk: an outdated target API level; sensitive permissions such as QUERY_ALL_PACKAGES, background location, SMS and call log, exact alarms or all-files access, which need a Play Console declaration; and a Data Safety form that doesn't match the SDKs in your build.
• Fixing after testing means re-testing. A new build doesn't reset Google's clock, but a fix that changes behaviour deserves the testers' 14 days too.

A note on the standard. OWASP MASVS v2 has eight control groups: STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY. The old L1/L2 levels were removed from MASVS in v2.0; how deep to test now lives in the MASTG testing profiles. Obfuscation and tamper detection belong to MASVS-RESILIENCE, not MASVS-CODE.

Setup: turn your bundle into something you can inspect

# App Bundle -> universal APK (debug-signed, which is fine for inspection)
bundletool build-apks --bundle=app-release.aab --output=app.apks --mode=universal
unzip -p app.apks universal.apk > app.apk

aapt2 dump badging app.apk | grep -E "package:|sdkVersion|targetSdkVersion"
apkanalyzer manifest debuggable app.apk          # must print: false
apkanalyzer manifest print app.apk > AndroidManifest.xml
jadx -d out/ app.apk                             # decompiled sources + resources

val kg = KeyGenerator.getInstance(KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore")
kg.init(
    KeyGenParameterSpec.Builder("session_key",
        KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT)
        .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
        .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
        .setKeySize(256)
        .build()
)
val cipher = Cipher.getInstance("AES/GCM/NoPadding").apply { init(Cipher.ENCRYPT_MODE, kg.generateKey()) }
val iv = cipher.iv  // generated by Keystore; store it with the ciphertext

<network-security-config>
  <base-config cleartextTrafficPermitted="false" />
  <domain-config>
    <domain includeSubdomains="true">api.example.com</domain>
    <pin-set expiration="2027-06-30">
      <pin digest="SHA-256">CURRENT_SPKI_BASE64=</pin>
      <pin digest="SHA-256">BACKUP_SPKI_BASE64=</pin>
    </pin-set>
  </domain-config>
</network-security-config>

openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null \
 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der \
 | openssl dgst -sha256 -binary | openssl enc -base64

android {
    buildTypes {
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
        }
    }
}

What an automated check covers, and what it can't

How TestersWiz fits: two tracks, one timeline

What neither is: a penetration test, a certification, or a guarantee that your app or its backend is secure. For regulated apps, or anything handling payments or health data, commission a human assessment against the MASTG.

TestersWiz vs peer groups vs tester farms

Frequently asked questions