Geschlossene Tests in Google Play für Expo-Apps (EAS)

Beim ersten Android-Build bietet EAS an, einen Keystore zu erzeugen, und speichert ihn auf den Expo-Servern; spätere Builds verwenden ihn wieder. Für Google Play ist dieser Keystore dein Upload-Schlüssel. Beim Hochladen des ersten Bundles wird die Play App-Signatur eingerichtet, und Google verwahrt den App-Signaturschlüssel.

Mit eas credentials siehst du den eingerichteten Keystore, lädst ein Backup herunter oder ersetzt ihn. Bewahre das Backup sicher auf: Du brauchst es, falls du einmal lokal baust oder EAS verlässt.

eas credentials -p android

Erzeuge nach dem ersten Upload keinen neuen Keystore. Ein mit einem anderen Upload-Schlüssel signiertes Bundle wird abgelehnt, bis du in der Play Console ein Zurücksetzen des Upload-Schlüssels beantragst.

Die Play Console lehnt jedes Bundle ab, dessen versionCode schon verwendet wurde. Am einfachsten verwaltet EAS ihn in der Cloud und erhöht ihn bei jedem Produktionsbuild:

{
  "cli": { "appVersionSource": "remote" },
  "build": {
    "production": { "autoIncrement": true }
  },
  "submit": {
    "production": {
      "android": { "track": "alpha", "releaseStatus": "draft" }
    }
  }
}

Ist appVersionSource auf remote gesetzt, speichert EAS den Versionscode und ignoriert android.versionCode in deiner App-Konfiguration. Hast du schon Builds von Hand hochgeladen, führe einmal eas build:version:set aus, damit EAS bei deiner letzten Nummer weitermacht.

Seit dem 31. August 2026 müssen neue Apps und Updates Android 16 (API-Level 36) als Ziel haben. Jede Expo-SDK-Version legt das Ziel-SDK selbst fest; die zuverlässige Lösung ist also eine SDK-Version mit Ziel 36. Das Config-Plugin expo-build-properties kann targetSdkVersion überschreiben, aber nur, wenn dein SDK und deine Bibliotheken das unterstützen.

• eas submit landet im internen Test. Standardmäßig schickt eas submit -p android den Build in den internen Track, der für die Regel mit 12 Testern nicht zählt. Setze im Submit-Profil wie oben "track": "alpha" (Googles standardmäßiger geschlossener Track) oder lade die heruntergeladene .aab von Hand in den geschlossenen Track.
• Erste Releases nur als Entwurf. Solange die App nie veröffentlicht wurde, nimmt Google über die API nur Entwurfs-Releases an. Behalte "releaseStatus": "draft" bei und schließe das Rollout in der Play Console ab.
• Ein Dienstkonto ist nötig. eas submit nutzt einen Google-Dienstkontoschlüssel, den du bei EAS unter den Zugangsdaten der App hochlädst. Ohne ihn lädst du manuell hoch.
• Entwicklungs-Builds. Ein Build mit developmentClient: true erwartet einen Entwicklungsserver. Stell sicher, dass Tester das Produktionsprofil bekommen.
• Fehlende Umgebungsvariablen. Werte aus einer von Git ignorierten .env-Datei werden nicht zu EAS Build hochgeladen. Lege Produktionswerte als EAS-Umgebungsvariablen an, sonst spricht der Release-Build mit dem falschen Backend.
• Native Änderungen brauchen einen neuen Build. Berechtigungen, Paketname und Config-Plugins erreichen Tester nur über einen neuen EAS-Build, nicht über ein Over-the-Air-Update.

eas submit -p android --profile production

Ein Production-Build verhält sich anders als Expo Go und Development-Builds: Es gibt keinen Dev-Server, das JavaScript ist minifiziert und nur die nativen Module, die du einkompiliert hast, sind vorhanden. Reproduziere, was Tester sehen, bevor du rätst.

1. 1

   Production-Modus lokal starten

   npx expo start --no-dev --minify führt dein JavaScript wie ein Release-Bundle aus und zeigt Fehler, die der Entwicklungsmodus nie auslöst.

2. 2

   Native Logs lesen

   Schließ das Smartphone per USB an und führe adb logcat aus. Native Logs zeigen oft die Ursache, wenn eine JavaScript-Error-Boundary das Problem nicht abfängt.

3. 3

   Play Console prüfen

   Abstürze von Testern erscheinen unter Beobachten und verbessern → Android Vitals → Abstürze und ANRs. Auch der Pre-Launch-Bericht, den Google nach einem Upload automatisch erstellt, startet die App auf Testgeräten und listet gefundene Abstürze auf.

4. 4

   JavaScript-Fehler lesbar machen

   Mit Sentry lädt EAS Build die Source Maps automatisch hoch, sobald SENTRY_AUTH_TOKEN als sensible EAS-Umgebungsvariable gesetzt ist. Führe nach eas update den Befehl npx sentry-expo-upload-sourcemaps dist aus, damit auch Updates lesbar sind.

Brauchst du natives Debugging? npx expo prebuild -p android erzeugt den Ordner android, damit du den Debugger von Android Studio anhängen kannst. Lösche ihn danach, damit Expo das Projekt weiter verwaltet.

Sobald dein Expo-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.

Mit Cloud-Versionierung startest du einfach den Produktionsbuild erneut und lädst ihn hoch oder reichst ihn im geschlossenen Track ein; der Versionscode steigt von selbst.

eas build -p android --profile production

Für reine JavaScript-Korrekturen kann EAS Update ein neues Bundle ohne erneute Store-Einreichung ausliefern. Die Google-Play-Richtlinie zu Geräte- und Netzwerkmissbrauch erlaubt so ein Update für Code, der in einem Interpreter oder einer virtuellen Maschine läuft, etwa JavaScript; nativen Code herunterzuladen erlaubt sie nicht. Nutze Updates für echte Korrekturen und bleib im Rahmen dessen, was der geprüfte Build tut.

eas update --channel production --message "Fix checkout crash" --environment production

• Channels. eas update:configure setzt einen channel in den Build-Profilen preview und production. Ein Build erhält nur Updates, die in seinem Channel veröffentlicht werden. Ab SDK 55 ist --environment Pflicht.
• Runtime-Version. Ein Update erreicht nur Builds mit derselben Runtime-Version. Die Richtlinie fingerprint ändert sie bei jeder Änderung, die die native Runtime betrifft, sodass inkompatible Updates sehr unwahrscheinlich sind.
• Neustarts. Release-Builds laden ein Update im Hintergrund und wenden es nach einem Neustart der App an. Bitte Tester, die App zu schließen und wieder zu öffnen, notfalls zweimal.
• Native Änderungen brauchen einen Build. Neue Berechtigungen, Config-Plugins oder native Bibliotheken erreichen Tester nur über einen neuen Production-Build im geschlossenen Track, der zugleich ein sichtbares Release in der Play Console hinterlässt.