Geschlossene Tests in Google Play für Ionic- und Capacitor-Apps

Google Play verlangt für neue Apps die Play App-Signatur. Der Keystore, den du im Assistenten von Android Studio anlegst (Create new) oder an npx cap build übergibst, ist dein Upload-Schlüssel; den separaten App-Signaturschlüssel verwahrt Google nach deinem ersten Upload.

Android Studio empfiehlt für neue Schlüssel eine Gültigkeit von mindestens 25 Jahren. Bewahre die .jks-Datei außerhalb des Ordners android/ auf, falls du das native Projekt einmal neu erzeugst, und sichere sie zusammen mit beiden Passwörtern. Geht der Upload-Schlüssel verloren, kannst du in der Play Console ein Zurücksetzen beantragen.

Wenn du Build-Optionen in der Capacitor-Konfiguration hältst, schreib die Passwörter nicht in die eingecheckte Datei. Die Konfiguration ist Teil deines Repositorys.

Capacitor liest die Version nicht aus package.json. Die Werte, die Google Play sieht, stehen in android/app/build.gradle; erhöhe versionCode vor jedem Upload:

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. Capacitor setzt targetSdkVersion in android/variables.gradle, und jede Hauptversion unterstützt genau einen Wert: Capacitor 8 nutzt 36, Capacitor 7 nutzt 35. Eigene Werte werden nicht unterstützt; der Weg zu API 36 ist also das Upgrade auf Capacitor 8 samt Plugins, nicht das Ändern der Zahl.

ext {
    // ...
    targetSdkVersion = 36
}

• Live Reload vergessen. Ein server.url in der Capacitor-Konfiguration lässt die App die Adresse deines Entwicklungsrechners laden. Tester sehen einen leeren Bildschirm. Entferne es vor dem Release-Build.
• Veraltete Web-Assets. Wer das Bundle in Android Studio erzeugt, ohne vorher npx cap sync android auszuführen, liefert den vorherigen Web-Build aus.
• Plugins auf anderer Hauptversion. Alle @capacitor/*-Pakete und Community-Plugins müssen zur Hauptversion von @capacitor/android passen. Abweichungen führen zu nativen Build-Fehlern oder Abstürzen zur Laufzeit.
• Unverschlüsselte Anfragen. Android blockiert reinen http://-Verkehr standardmäßig. Produktions-Builds sollten nur HTTPS-APIs aufrufen.
• Native Plugins und 16-KB-Seiten. Plugins mit .so-Bibliotheken 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.
• Nur im Browser testen. Zurück-Taste, Berechtigungen und Deep Links verhalten sich im Android-WebView anders. Installiere den Release-Build vor dem Upload auf einem echten Gerät.

Die meisten Probleme in einem Capacitor-Release-Build stecken in der Web-Schicht, also sind die Browser-Tools, die du schon kennst, der beste Einstieg. Im Release-Build sind sie abgeschaltet: webContentsDebuggingEnabled steht standardmäßig auf false, und Capacitors eigenes Logging folgt loggingBehavior mit dem Standard debug, sodass Release-Builds still bleiben.

1. 1

   Im Debug-Build reproduzieren

   Starte die App aus Android Studio auf einem Smartphone, öffne chrome://inspect in Chrome auf deinem Rechner und wähle die WebView. Du bekommst Konsole, Netzwerk-Panel und Breakpoints für deinen Web-Code. edge://inspect funktioniert in Edge genauso.

2. 2

   Release-Build nur lokal untersuchen

   Tritt ein Fehler nur im Release auf, setze webContentsDebuggingEnabled vorübergehend auf true in einem Build, den du selbst installierst. Lade diesen Build nie hoch: Er macht den Web-Inhalt deiner App auf jedem Gerät debugbar.

3. 3

   Native Abstürze in der Play Console sammeln

   Abstürze in Capacitors Java-Code oder in nativen Plugins erscheinen unter Beobachten und verbessern → Android Vitals → Abstürze und ANRs. Mit aktivem R8 macht die Mapping-Datei im .aab sie lesbar.

const config: CapacitorConfig = {
  // ...
  android: {
    // Never ship this to Google Play
    webContentsDebuggingEnabled: true,
  },
};

Frag Tester nach Gerätemodell, Android-Version und Version von Android System WebView. Viele reine WebView-Fehler hängen von dieser letzten Zahl ab, und alles unterhalb von android.minWebViewVersion liegt außerhalb dessen, was deine App unterstützt.

Sobald dein Ionic / Capacitor-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.

Web-App neu bauen, synchronisieren, versionCode erhöhen und ein neues signiertes Bundle für denselben geschlossenen Track erzeugen:

npm run build
npx cap sync android
npx cap open android

Die Google-Play-Richtlinie zu Geräte- und Netzwerkmissbrauch verbietet einer App, sich außerhalb von Google Play zu aktualisieren, mit einer Ausnahme für Code, der in einem Interpreter oder einer virtuellen Maschine läuft, etwa JavaScript in einer WebView. Deshalb gibt es Live-Update-Dienste für die Web-Schicht. Nativer Code, Plugins und Berechtigungen brauchen immer ein neues Bundle über Google Play.

Während des geschlossenen Tests ist ein neuer versionCode im geschlossenen Track der direkte Weg: Er wird geprüft, Tester bekommen ihn über Google Play, und er erscheint in deinem Release-Verlauf. Nutzt du zusätzlich einen Live-Update-Dienst, setze ihn für echte Korrekturen ein und halte den Web-Build im geschlossenen Track damit synchron.

• Auf das WebView-Minimum achten. android.minWebViewVersion steht standardmäßig auf 60 und kann nicht unter 55 liegen. Tester mit Problemen sollten zuerst Android System WebView über Google Play aktualisieren.
• Kein Mixed Content. android.allowMixedContent ist standardmäßig aus und nicht für die Produktion gedacht. Liefere jede API und jedes Asset über HTTPS aus und lass server.cleartext auf dem Standardwert false.
• Vor jedem Build synchronisieren. Jede Korrektur braucht nach dem Web-Build npx cap sync android, sonst enthält das neue Bundle noch das alte JavaScript.