Geschlossene Tests in Google Play für React-Native-Apps

Google Play verlangt für neue Apps die Play App-Signatur: Google verwahrt den App-Signaturschlüssel, und du signierst Uploads mit einem Upload-Schlüssel. Erzeuge ihn mit keytool, das mit dem JDK kommt:

keytool -genkeypair -v -storetype PKCS12 -keystore my-upload-key.keystore \
  -alias my-key-alias -keyalg RSA -keysize 2048 -validity 10000

Verschiebe die Datei nach android/app/ und trag die Zugangsdaten in ~/.gradle/gradle.properties ein, damit sie nie in Git landen:

MYAPP_UPLOAD_STORE_FILE=my-upload-key.keystore
MYAPP_UPLOAD_KEY_ALIAS=my-key-alias
MYAPP_UPLOAD_STORE_PASSWORD=*****
MYAPP_UPLOAD_KEY_PASSWORD=*****

Füge dann in android/app/build.gradle eine release-Signaturkonfiguration hinzu und nutze sie im Release-Build-Typ. Der Release-Build-Typ der Vorlage signiert mit dem Debug-Schlüssel, bis du das änderst:

android {
    signingConfigs {
        release {
            if (project.hasProperty('MYAPP_UPLOAD_STORE_FILE')) {
                storeFile file(MYAPP_UPLOAD_STORE_FILE)
                storePassword MYAPP_UPLOAD_STORE_PASSWORD
                keyAlias MYAPP_UPLOAD_KEY_ALIAS
                keyPassword MYAPP_UPLOAD_KEY_PASSWORD
            }
        }
    }
    buildTypes {
        release {
            // ...
            signingConfig signingConfigs.release
        }
    }
}

Jeder Upload braucht einen höheren versionCode als alles bisher Hochgeladene. In einem Bare-Projekt steht er in android/app/build.gradle; versionName ist die Bezeichnung, die Nutzer sehen:

android {
    defaultConfig {
        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. Die SDK-Level stehen im ext-Block von android/build.gradle (compileSdkVersion, targetSdkVersion). Neue React-Native-Versionen heben sie an. Bei einer älteren Version ist ein React-Native-Upgrade meist sicherer, als nur targetSdkVersion zu erhöhen, weil auch deine nativen Bibliotheken kompatibel sein müssen.

• Debug-signiertes Bundle. Vergisst du, den Release-Build-Typ auf signingConfigs.release umzustellen, lehnt die Play Console den Upload als debug-signiert ab.
• Überraschungen mit R8/ProGuard. Mit enableProguardInReleaseBuilds = true können Bibliotheken, die Reflection nutzen, nur im Release abstürzen. Ergänze ihre Keep-Regeln in android/app/proguard-rules.pro und teste den Release-Build auf einem Gerät.
• Unlesbare Absturzberichte. Hermes, die Standard-Engine, führt vorkompilierten Bytecode aus; Release-Stacktraces zeigen ins kompilierte Bundle. Bewahre die Source Maps jedes hochgeladenen Builds auf, um Berichte von Testern zu symbolisieren.
• Die App sucht Metro. Ein Release-Build, der den Entwicklungsserver erreichen will, hat kein gebündeltes JavaScript. Prüfe die Einstellung configureondemand und baue neu.
• Native Module und 16-KB-Seiten. Bibliotheken mit nativen .so-Dateien müssen 16-KB-Speicherseiten unterstützen. Die Play Console warnt davor, und ab dem 1. Februar 2027 lassen sich Updates ohne Unterstützung nicht mehr veröffentlichen. Aktualisiere sie vor Testbeginn.
• Verlorener Keystore. Sichere den Keystore und seine Passwörter. Du kannst in der Play Console ein Zurücksetzen des Upload-Schlüssels beantragen, aber das kostet Zeit, die du mitten im Test nicht verlieren willst.

Ein JavaScript-Absturz in einem Release-Build kommt bei dir als Hermes-Bytecode-Position wie p@1:132161 an, die für sich genommen nichts verrät. React Native erzeugt für Android-Release-Builds standardmäßig Source Maps; entscheidend ist, für jedes hochgeladene Bundle die richtige Map aufzubewahren.

1. 1

   Source Map archivieren

   Kopiere nach jedem Release-Build die Map aus android/app/build/generated/sourcemaps/react/release/ und beschrifte sie mit dem Versionscode. Sie muss genau zum Commit des abgestürzten Builds passen: Schon kleine Codeänderungen verschieben die Offsets.

2. 2

   metro-symbolicate ausführen

   Speichere den Stacktrace des Testers in einer Datei oder lies ihn direkt aus adb logcat und leite ihn mit dieser Map durch metro-symbolicate. Das Tool übersetzt Bytecode-Offsets zurück in Dateinamen, Zeilen und Funktionsnamen.

3. 3

   Native Frames in der Play Console prüfen

   Abstürze im Java- oder Kotlin-Code nativer Module erscheinen unter Beobachten und verbessern → Android Vitals → Abstürze und ANRs. Mit aktivem R8 macht die Mapping-Datei im .aab sie ohne zusätzlichen Upload lesbar.

# From a saved stack trace
npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map < stacktrace.txt

# From a connected device
adb logcat -d | npx metro-symbolicate android/app/build/generated/sourcemaps/react/release/index.android.bundle.map

Beendet sich metro-symbolicate sofort ohne Ausgabe, hat es keine Eingabe bekommen: Übergib den Stacktrace per Pipe oder Umleitung, nicht durch Eintippen im Terminal.

Sobald dein React Native-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.

Bei React Native: versionCode (und versionName) erhöhen, neu bauen und das neue Bundle in denselben geschlossenen Track hochladen.

cd android
./gradlew bundleRelease

Deinstalliere die Debug-App, bevor du die Release-Variante mit npm run android -- --mode="release" installierst; Android ersetzt keine App, die mit einem anderen Schlüssel signiert ist. Wiederhole diese Prüfung vor jedem Upload, denn reine Release-Probleme wie fehlende Keep-Regeln zeigen sich im Debug nie.

JavaScript-Updates over the air sind eine Grauzone, nach der viele Teams fragen. Laut der Google-Play-Richtlinie zu Geräte- und Netzwerkmissbrauch darf sich eine App nicht außerhalb von Google Play aktualisieren; die Einschränkung gilt aber nicht für Code, der in einer virtuellen Maschine oder einem Interpreter läuft, etwa JavaScript. Nativer Code, neue Berechtigungen und native Module brauchen immer ein neues Bundle über Google Play.

• Der geschlossene Track bleibt der Hauptweg. Ein neuer versionCode im geschlossenen Track erreicht jeden Tester mit Opt-in über Google Play und erscheint in deinem Release-Verlauf.
• Native Abhängigkeiten nicht anfassen. Ein Upgrade von React Native oder einem nativen Modul mitten im Test ändert weit mehr als den Fehler, den du behebst. Mach das vor dem Test oder nach dem Produktionszugang.
• Eine Map pro Release aufbewahren. Jeder neue Build erzeugt eine neue Source Map. Speichere sie mit dem Versionscode, sonst lässt sich der nächste Absturzbericht dieser Version nicht entschlüsseln.