Geschlossene Tests in Google Play für Unity-Spiele

Ohne eigenen Keystore signiert Unity mit einem Debug-Schlüssel, und die Play Console lehnt debug-signierte Bundles ab. Leg im Editor einen an:

1. 1

   Keystore Manager öffnen

   Geh zu Edit → Project Settings → Player → Android → Publishing Settings und öffne den Keystore Manager.

2. 2

   Keystore erstellen

   Wähle Keystore → Create New, speichere die Datei (irgendwo oder im eigenen Keystore-Ordner), vergib ein Passwort und füge einen Schlüssel mit Alias hinzu.

3. 3

   Für Builds verwenden

   Wähle zurück in den Publishing Settings den Keystore und den Schlüssel-Alias aus und gib die Passwörter ein.

Dieser Keystore ist dein Upload-Schlüssel. Beim ersten Upload richtet die Play Console die Play App-Signatur ein, und Google verwahrt den App-Signaturschlüssel. Sichere die Keystore-Datei und beide Passwörter außerhalb des Projekts; ein verlorener Upload-Schlüssel bedeutet einen Antrag auf Zurücksetzen in der Play Console.

Unter Player → Other Settings → Identification ist Version das, was Spieler sehen, und Bundle Version Code die Ganzzahl, die Google vergleicht. Erhöhe den Bundle Version Code vor jedem Build, den du hochlädst; die Play Console lehnt wiederverwendete Codes ab.

Daneben steht Target API Level. Seit dem 31. August 2026 müssen neue Apps und Updates Android 16 (API-Level 36) als Ziel haben. In der automatischen Einstellung nutzt Unity das höchste installierte SDK; prüfe, dass es mindestens 36 ist. Ältere Editor-Versionen unterstützen das neueste Level eventuell nicht; dann aktualisiere Unity vor dem Test, nicht währenddessen.

• Mono-Build. Mono kann kein ARM64 erzeugen. Die Play Console markiert den Release dann, weil er die 64-Bit-Anforderung nicht erfüllt. Wechsle zu IL2CPP mit ARM64.
• Development Build vergessen. Development-Builds sind langsamer, zeigen ein Entwicklungs-Wasserzeichen und können als debuggable markiert sein, was die Play Console ablehnt.
• Alte SDKs für Werbung und Analytics. Veraltete Drittanbieter-SDKs bringen alte native Bibliotheken und Berechtigungen mit. Aktualisiere sie vor dem Test: Die Play Console warnt vor Bibliotheken ohne Unterstützung für 16-KB-Speicherseiten, und ab dem 1. Februar 2027 lassen sich Updates ohne Unterstützung nicht mehr veröffentlichen.
• Bundle zu groß. Scheitert der Upload an der Größe, aktiviere Split Application Binary, damit Unity Assets in Play-Asset-Delivery-Pakete statt ins Basismodul legt.
• Minify bricht Plugins. Die Minimierung im Release kann Java-Klassen entfernen, die Plugins per Namen laden. Ergänze Keep-Regeln oder teste den minimierten Release vor dem Upload auf einem Gerät.
• Versionscode vergessen. Der zweite Upload mit demselben Bundle Version Code schlägt fehl. Automatisiere die Erhöhung oder setz sie auf deine Release-Checkliste.

Stürzt ein Unity-Spiel auf dem Smartphone eines Testers ab, zeigt der Stacktrace in libil2cpp, libunity oder libmain. Ohne Symbole zeigt die Play Console nur rohe Adressen, und Google Play symbolisiert keine Abstürze, die eingegangen sind, bevor du die Symbole hochgeladen hast. Richte das vor dem ersten geschlossenen Release ein, nicht nach dem ersten Absturz.

1. 1

   Symbole aktivieren

   Setze unter File → Build Profiles → Android die Option Debug Symbols auf Public. Öffentliche Symbole enthalten nur die Symboltabelle, was für lesbare Funktionsnamen reicht und die Datei klein hält. Debugging ergänzt vollständige Debug-Informationen, um lokal einen nativen Debugger anzuhängen.

2. 2

   Weg zu Google wählen

   Wähle .zip für ein Paket wie MyApp-0.1-v100-IL2CPP.symbols.zip, das du selbst hochlädst, oder bette die Symbole ins App Bundle ein, damit sie mit dem .aab hochgeladen werden. In einem Build-Skript erledigt das der Ausschnitt unten.

3. 3

   Symbole den Versionen zuordnen

   Symbole gehören zu genau einem Bundle Version Code. Lädst du das Zip von Hand hoch, dann im App-Bundle-Explorer der Play Console im Tab Downloads dieser Version, bevor Tester sie installieren.

// Public symbols, embedded in the .aab so they upload with it
UserBuildSettings.DebugSymbols.level = DebugSymbolLevel.SymbolTable;
UserBuildSettings.DebugSymbols.format = DebugSymbolFormat.IncludeInBundle;

Liefert ein natives Plugin eine eigene Symboldatei mit, wähle sie im Inspector aus und setze Shared Library Type mit passender CPU auf Symbol. Sie muss genauso heißen wie die Bibliothek und in einem eigenen Ordner liegen.

Sobald dein Unity-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 Unity: Bundle Version Code erhöhen, die .aab neu bauen und in denselben geschlossenen Track hochladen. Eine kleine Korrektur mitten im Test genügt.

Auf deinen eigenen Geräten installiert Build and Run das Spiel auf dem unter Run Device gewählten Smartphone; ist der Ausgabepfad einmal gesetzt, wiederholt Strg+B (macOS: Cmd+B) das. Unitys Application Patching verkürzt Debug-Build-Zeiten auf deinem Gerät, liefert Testern aber nichts aus: Sie brauchen immer ein neues .aab im geschlossenen Track.

• Passwörter werden nicht gespeichert. Unity speichert Keystore- und Schlüsselpasswörter nicht auf der Festplatte, du gibst sie nach jedem Editor-Neustart erneut ein. Für reproduzierbare CI-Builds setzt du sie im Editor-Build-Skript, neben der Erhöhung des Versionscodes aus dem Build-Abschnitt.
• Auf die Größe achten. Google Play begrenzt das Basismodul auf 500 MB komprimierte Downloadgröße. Größere Spiele brauchen Asset-Packs über Play Asset Delivery; Module und Install-Time-Asset-Packs zusammen dürfen bis zu 4 GB groß sein.
• Nach nativen Updates neu bauen. Der Editor warnt beim Build vor jeder .so, die auf 4 KB statt 16 KB ausgerichtet ist. Aktualisiere auf das neueste Patch-Release deines Editors und nativer Pakete wie Burst und baue vor dem nächsten Upload neu.
• Editor-Version stabil halten. Ein Wechsel der Unity-Version mitten im Test ändert die Engine-Bibliotheken, die Tester ausführen. Halte die Version alle 14 Tage fest, außer ein Absturz erzwingt ein Update.