Geschlossene Tests in Google Play für Kotlin- und Jetpack-Compose-Apps

Neue Apps müssen die Play App-Signatur nutzen: Google verwahrt den App-Signaturschlüssel, und du signierst jeden Upload mit einem Upload-Schlüssel. Der Assistent in Android Studio kann den Keystore anlegen; er empfiehlt eine Gültigkeit von mindestens 25 Jahren.

Um über die Kommandozeile oder in der CI zu signieren, halte die Zugangsdaten in einer keystore.properties außerhalb der Versionsverwaltung und lies sie in app/build.gradle.kts ein:

storePassword=myStorePassword
keyPassword=myKeyPassword
keyAlias=upload
storeFile=/path/to/upload-keystore.jks

import java.io.FileInputStream
import java.util.Properties

val keystoreProperties = Properties().apply {
    load(FileInputStream(rootProject.file("keystore.properties")))
}

android {
    signingConfigs {
        create("release") {
            keyAlias = keystoreProperties["keyAlias"] as String
            keyPassword = keystoreProperties["keyPassword"] as String
            storeFile = file(keystoreProperties["storeFile"] as String)
            storePassword = keystoreProperties["storePassword"] as String
        }
    }
    buildTypes {
        release {
            isMinifyEnabled = true
            proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro")
            signingConfig = signingConfigs.getByName("release")
        }
    }
}

Sichere den Keystore und beide Passwörter. Geht der Upload-Schlüssel verloren oder wird er geleakt, erstelle einen neuen und beantrage in der Play Console ein Zurücksetzen; der App-Signaturschlüssel bleibt derselbe.

versionCode muss höher sein als bei jedem Bundle, das du je hochgeladen hast, egal in welchem Track; versionName sehen die Nutzer. Beide stehen in defaultConfig, neben den SDK-Leveln:

android {
    compileSdk = 36
    defaultConfig {
        applicationId = "com.yourcompany.app"
        targetSdk = 36
        versionCode = 2
        versionName = "1.0.1"
    }
}

Seit dem 31. August 2026 müssen neue Apps und Updates Android 16 (API-Level 36) als Ziel haben. Ein höheres targetSdk schaltet neues Plattformverhalten ein. Apps mit Ziel Android 15 und höher werden randlos (edge-to-edge) dargestellt, und unter Android 16 funktioniert das Abschalten nicht mehr. Prüfe also vor dem Test, dass deine Compose-Screens Window Insets korrekt behandeln.

• R8 entfernt, was Reflection braucht. Mit isMinifyEnabled = true können Serialisierungsmodelle, Retrofit- oder Gson-Klassen und manche Dependency-Injection-Setups nur im Release kaputtgehen. Ergänze Keep-Regeln in proguard-rules.pro und teste die Release-Variante.
• Überraschungen durch Edge-to-Edge. Inhalte unter Status- und Navigationsleiste verdecken Buttons. Nutze auf jedem Screen, den Tester sehen, das Padding von Scaffold oder WindowInsets-Modifier.
• Debuggable Release. Steht isDebuggable = true im Release-Build-Typ, lehnt die Play Console das Bundle ab.
• Signatur-Geheimnisse in Git. Direkt in build.gradle.kts geschriebene Passwörter landen im Repository. Halte sie in keystore.properties oder in CI-Secrets.
• Native Bibliotheken und 16-KB-Seiten. Reine Kotlin-Apps unterstützen 16-KB-Speicherseiten bereits, aber NDK-Code und Bibliotheken mit .so-Dateien müssen neu gebaut oder aktualisiert werden. Die Play Console warnt davor, und ab dem 1. Februar 2027 lassen sich Updates ohne Unterstützung nicht mehr veröffentlichen.
• Nur Debug testen. Tester bekommen die Release-Variante. Führe sie vor jedem Upload auf mindestens einer aktuellen Android-Version aus.

Tester führen immer nur die Release-Variante aus, ihre Abstürze stammen also aus R8-optimiertem Code mit umbenannten Klassen und Methoden. Der Build schreibt das Mapping, das das rückgängig macht, nach app/build/outputs/mapping/release/mapping.txt, überschreibt es bei jedem Build und packt es zusätzlich ins .aab.

1. 1

   Die Play Console entschleiern lassen

   Ab Android Gradle Plugin 4.1 übernimmt die Play Console die Mapping-Datei aus dem hochgeladenen Bundle. Abstürze unter Beobachten und verbessern → Android Vitals → Abstürze und ANRs zeigen dann deine echten Klassen- und Methodennamen.

2. 2

   Pro Release eine Kopie aufbewahren

   Archiviere mapping.txt mit jedem hochgeladenen Versionscode. Du brauchst sie für Stacktraces, die Tester in Fehlerberichte kopieren, und für jedes Absturz-Tool außerhalb von Google Play.

3. 3

   Von Hand zurückübersetzen

   Führe retrace aus den Kommandozeilen-Tools mit dem Mapping und einer Datei mit dem Stacktrace aus. Aktuelle Android-Studio-Versionen übersetzen Stacktraces in Logcat auch automatisch zurück.

$ANDROID_HOME/cmdline-tools/latest/bin/retrace \
  app/build/outputs/mapping/release/mapping.txt trace.txt

Nutzt du das NDK? Setze debugSymbolLevel im Release-Build-Typ. SYMBOL_TABLE liefert Funktionsnamen in der Play Console, FULL zusätzlich Dateien und Zeilennummern. Bei App Bundles werden die nativen Symbole automatisch eingebunden und hochgeladen.

android {
    buildTypes {
        release {
            ndk {
                debugSymbolLevel = "FULL" // or "SYMBOL_TABLE"
            }
        }
    }
}

Behält R8 Code, den du nicht erwartet hast, oder entfernt es Code, den Reflection braucht, zeigt -whyareyoukeeping den Pfad von einer behaltenen Klasse zu einem Einstiegspunkt, und configuration.txt neben dem Mapping listet alle zusammengeführten Regeln.

Sobald dein Kotlin / Jetpack Compose-Bundle gebaut und signiert ist, passiert der Rest in der Play Console und funktioniert für jedes Framework gleich. Hier die Checkliste; jedes Menü und jeden Bildschirm erklärt die vollständige Play-Console-Anleitung.

• App-Einrichtung abschließen: im Dashboard Datenschutzerklärung, App-Zugriff, Werbung, Altersfreigabe, Zielgruppe, Datensicherheit und Store-Eintrag.
• Release für den geschlossenen Test erstellen: unter Testen und veröffentlichen → Tests → Geschlossene Tests die Länder deiner Tester wählen, das .aab hochladen und zur Prüfung senden.
• Tester per Google Group hinzufügen: im Tab Tester die Gruppe eintragen und den Opt-in-Link teilen. Er funktioniert, sobald der Track Veröffentlicht zeigt.
• Mindestens 12 Tester 14 Tage ohne Unterbrechung im Opt-in halten. Interne Tests zählen nicht, und wer austritt und wiederkommt, beginnt seine 14 Tage von vorn.
• Während des Tests mindestens ein Update veröffentlichen und notieren, was Tester gefunden und was du geändert hast.
• Produktionszugang beantragen: im Dashboard den Antrag öffnen und die drei Abschnitte zu deinem Test, deiner App und deiner Produktionsreife beantworten. Die Entscheidung trifft Google; niemand kann eine Freigabe garantieren.

Plane Ausfälle ein: Gewinne mehr als 12 Tester, damit ein Abgang deinen Zeitplan nicht verschiebt. Alle Play-Console-Schritte ansehen.

Erhöhe versionCode, baue das Bundle neu (Gradle oder der Assistent in Android Studio) und lade es in denselben geschlossenen Track hoch.

./gradlew bundleRelease

Um das Bundle zu installieren, das du gleich hochlädst, erzeuge daraus mit bundletool gerätespezifische APKs, signiert mit deinem Upload-Schlüssel. Näher kommst du nicht an das heran, was Google Play ausliefert, einschließlich der Aufteilung nach Bildschirmdichte, Sprache und ABI:

bundletool build-apks --connected-device \
  --bundle=app/build/outputs/bundle/release/app-release.aab --output=app.apks \
  --ks=/path/to/upload-keystore.jks --ks-key-alias=upload
bundletool install-apks --apks=app.apks

Für schnelle Checks im eigenen Team nimmt die interne App-Freigabe der Play Console jeden Versionscode an und liefert einen Download-Link für bis zu 100 Personen. Diese Uploads können nicht Teil eines Test-Tracks sein und ersetzen den geschlossenen Test nicht: Deine 12 Tester installieren immer aus dem geschlossenen Track.