Android-Spiele im Auto GA: Parkmodus freigegeben – und der Prod-Build ohne UX-Check

Android Auto und AAOS Google built-in lassen Games jetzt GA in Open Testing und Production – aber nur im Parkmodus. Spoiler: Track-Freigabe ist nicht gleich UX-Freigabe ohne Quality-Check und DHU.

Die kurze Version: Am 21. September 2026 hat Jan Kleinert im Android Developers Blog die Games-Kategorie für Android Auto und für Autos mit Android Automotive OS (Google built-in) von Beta auf General Availability gehoben. Early-Access-Partner hatten bereits geparkte Spiel-Erlebnisse; Collections für Android Auto und AAOS liegen bereit. Open Testing und Production Tracks in Google Play sind offen. Use Case: Downtime an der Ladesäule oder beim Curbside-Pickup. Klingt einfach, ist es aber nicht – denn „published“ heißt noch lange nicht „Parked-UX freigegeben“.

Im Ernst: Wer jetzt den Prod-Build hochlädt, ohne die Car App Quality Guidelines für Games und ohne Desktop-Head-Unit-Test, feiert die Track-Ampel – und riskiert, dass das Infotainment das Spiel höflich, aber bestimmt aussperrt, sobald UX-Restrictions greifen. Wir bei digital-magazin.de halten die These bewusst scharf: GA ist Track-Status. UX-Freigabe braucht Quality Guidelines plus DHU- bzw. Emulator-Tests. Punkt.

Was GA am 21. September wirklich freigibt – und was nicht

Nerd-Alarm: Die Überschrift im Blog klingt wie ein Freifahrtschein für jedes Handy-Spiel auf dem Armaturenbrett. Lesen Sie den Text, und das Spiel selbst bekommt eine andere Rolle zugewiesen. Es darf auftreten – aber nur, wenn das Auto steht. Parked Apps. Nicht während der Fahrt. Die Plattform blockiert Activities standardmäßig, sobald das Fahrzeug in Bewegung ist oder UX-Restrictions aktiv sind. Kein distractionOptimized im Manifest. Audio stoppt bei Fahrtbeginn und darf nicht unpausiert werden. Das ist keine Empfehlung, das ist die Architektur.

Die Alltagsszene ist vertraut: Sie stehen in der Parkplatz-Warteschlange vor dem Drive-in, der Akku an der Ladesäule hängt bei 42 Prozent und die App sagt „noch 18 Minuten“, oder der Curbside-Pickup-Mitarbeiter tippt noch die Bestellung ab. Genau diese Idle-Zeit meint Google, wenn von Charging Station und Curbside Order Pickup die Rede ist. Das Infotainment wird in diesen Minuten vom Navigationshelfer zum Spielplatz – und zurück, sobald der Gang eingelegt wird. Wer das als „Spiele im Auto freigegeben“ liest und dabei an Autobahn-Runden denkt, hat den Parkmodus übersehen.

Early Access Partner kannten das schon. Sie haben geparkte Experiences gebaut, und Google zeigt Collections für Android Auto und für AAOS. Was sich mit dem Blog-Post vom 21. September ändert: Entwickelnde dürfen jetzt Open Testing und Production Tracks nutzen. Das ist der GA-Schritt. Nicht die Aussage „jedes Manifest mit appCategory="game" ist UX-tauglich“. Die Docs „Build games for cars“ können je nach Stand noch Beta- oder Track-Hinweise tragen; den GA-Claim nehmen wir aus dem Blog vom 21. September, den Docs-Stand kennzeichnen wir separat. Wer nur die Doku skimmt und den Blog überspringt, baut auf einem veralteten Track-Bild.

Wir bei digital-magazin.de haben uns den Parkmodus und die Datenschutz-Fragen rund um Sprachassistenten im Auto schon an anderer Stelle angeschaut – unter anderem in unserem Beitrag zu Gemini in Android Auto und Datenschutz. Games im Parkmodus sind die nächste Schicht derselben Maschine: mehr Oberfläche, mehr Idle-Zeit, dieselben Regeln zur Ablenkung.

Parked Apps: Was das Infotainment dem Spiel verbietet

Spoiler: Das Infotainment ist hier der Türsteher, nicht der Fan. Android Auto und AAOS behandeln Games als Parked Apps. Sie dürfen nicht laufen, während das Fahrzeug fährt. UX-Restrictions blocken Launch und Nutzung by default. Wer im Manifest distractionOptimized setzt, arbeitet gegen die Distraction-Guidelines – und gegen die explizite Blog-Anweisung, dieses Metadata-Element in keiner Activity zu führen.

Audio ist der zweite Stolperstein. Das Spiel muss den Ton stoppen, wenn die Fahrt beginnt. Es darf ihn nicht wieder anwerfen, solange das Fahrzeug in Bewegung ist. Klingt trivial, bis Sie merken, dass viele Mobile-Titel Audio über Lifecycle-Callbacks, MediaSession oder Game-Engines fortsetzen, ohne den Fahrzeugzustand zu kennen. Bastelprojekt: Audio-Pipeline an den Parked-State koppeln, nicht an „App ist noch im Vordergrund“.

Beim erneuten Start vom Homescreen soll der Zustand so nah wie möglich wiederhergestellt werden. Responsiveness: kein Freezen, kein Stottern während des Spiels. Das steht in den Quality Guidelines unter Expected Performance für Games (EP-3) – und es ist genau der Punkt, an dem ein Prod-Upload ohne DHU-Lauf zur Lotterie wird. Die kurze Version: Track grün bedeutet „Review kann starten“, nicht „Parkplatz-UX ist abgenommen“.

Personifikation gefällig? Das Spiel will auf dem Display bleiben, wenn Sie anfahren. Das Infotainment sagt: Sitzplatz nur im Stehen. Der Audio-Stream will weiterlaufen. Die UX-Restriction zieht den Stecker. Wer diesen Dialog nicht im Manifest und in der Audio-Logik vorwegnimmt, liefert ein Bastelprojekt, das auf dem Telefon glänzt und im Auto den Review verliert.

Im Alltag heißt das: An der Ladesäule darf das Spiel den Idle füllen. Sobald Sie den Moduswechsel in den Fahrzustand auslösen, muss die Session so enden, dass niemand Ablenkung nachweisen kann – und dass die Review gegen DD-2/DD-3 nicht scheitert. Die Quality-Seite listet für Games unter Driver Distraction klar: nicht launchbar und nicht sichtbar während der Fahrt; Audio stoppt und bleibt gestoppt.

Noch ein Alltagsbild: Sie sitzen in der Parkplatz-Warteschlange, das Kind auf dem Rücksitz fragt nach dem nächsten Level, der Pickup-Code blinkt auf dem Handy. Genau dann soll das Spiel greifbar sein – und genau dann muss es verschwinden, wenn die Schlange sich bewegt und der Wagen rollt. Parkmodus ist keine Marketing-Metapher; es ist der Schalter zwischen „erlaubt“ und „gesperrt“. Wer diesen Schalter in der eigenen Architektur nicht modelliert, baut ein Telefonspiel mit Auto-Sticker, kein Car-Game.

Manifest, Tracks und die zwei Gesichter von AAOS

Nerd-Alarm: Ohne Manifest-Arbeit kommt kein Spiel in die Games-Kategorie – egal wie GA der Track heißt. Pflicht für die Kategorie: android:appCategory="game" am application-Element. Für Android Auto (Geräte mit Android 15 und höher): im Intent-Filter einer Activity die Category android.intent.category.CAR_LAUNCHER, typischerweise neben LAUNCHER, optional in einer anderen Activity, wenn das Auto eine andere Einstiegs-Activity starten soll.

Für Android Automotive OS: uses-feature android.hardware.type.automotive. Hier trennen sich die Tracks. Verteilen Sie über den Mobile-Track, muss android:required="false" stehen. Auf dem dedizierten AAOS-Track dürfen Sie true, false oder unset wählen; unset wirkt wie true und beschränkt die Distribution auf AAOS-Geräte. Wer das verwechselt, wundert sich, warum das Build auf dem falschen Shelf landet.

Optional, aber sichtbarkeitsrelevant: android.hardware.gamepad mit required="false". Viele Nutzende wollen am großen Display lieber mit Gamepad spielen als tippen. required="true" nur, wenn ohne Controller nichts geht – sonst filtern Sie Geräte und OEM-Setups aus, die einen Controller koppeln könnten, ihn aber nicht als Pflicht-Feature ausweisen.

Adaptive Screens: vollflächig, ohne Letterboxing oder Pillarboxing. Canonical Screen Sizes für Android Auto (Landscape 16:9, Portrait 9:16 laut Docs); für AAOS Emulator Hardware Profiles (Landscape 4:3, Portrait 10:16). DO-2 in den Quality Guidelines verlangt für Android Auto ausdrücklich, dass Games auf Landscape-Displays nicht signifikant pillarboxed sind. Klingt nach Layout-Fleißarbeit – ist aber Review-Kriterium, kein Nice-to-have.

Wer die große Frage „wohin steuert das deutsche Auto?“ stellt, landet schnell bei Software-Stacks und Idle-Oberflächen. Unser Text zur Zukunft des deutschen Autos ordnet genau diese Schicht ein: nicht nur Antrieb, sondern was auf dem Display erlaubt ist, wenn niemand fährt.

Publish-Checkliste: Track offen ist nicht Test bestanden

Spoiler: Der Blog sagt es selbst – vor Production gegen die Car App Quality Guidelines for Games testen; Desktop Head Unit für Android Auto; AAOS Emulator für Automotive; Review gegen die Guidelines vor Open Testing oder Production. Die Docs betonen: Spiele werden gegen die Quality Guidelines geprüft, sobald Sie Tracks jenseits von Internal Testing ansteuern. GA öffnet die Tür. Die Prüfung bleibt.

Die kurze Version einer Publish-Checkliste für Entwickelnde:

Im Ernst: Wer Schritt sieben und acht überspringt und trotzdem Production wählt, verwechselt „Track erlaubt Upload“ mit „UX freigegeben“. Die manuelle Review laut Quality-Seite ist zusätzlicher Aufwand jenseits der normalen Play-Store-Prüfung. Scheitert die App, kommt die Rückmeldung an die Console-Mail – und Updates hängen, bis die Car-Qualitätsprüfung durch ist. Bastelprojekt mit Prod-Label ist teurer als Bastelprojekt auf Internal Testing.

Sample-Hinweis aus dem Blog: TrivialKart for Unity auf der Desktop Head Unit im geparkten Zustand. Das ist kein Merch, das ist die Referenzszene: Parked State, Unity-Spiel, DHU. Wenn Ihr Titel dort freiert, stuttert oder Audio nicht stoppt, ist die Collection-Fantasie vorbei, bevor Marketing „Games im Auto“ tweetet.

Zum Vergleich der Medienwelt auf der Gegenseite: Apple CarPlay hat eigene Regeln für Podcasts und Webradio. Wir haben das unter Apple CarPlay: Podcasts und Webradio fürs Auto auseinandergenommen – andere Plattform, gleiches Grundproblem: Was darf wann auf dem Display, und wer prüft das vor dem Store?

Charging-Idle und Curbside: Der Use Case, den GA meint

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptDesk with gamepad and car quality checklist paper beside closed laptop, fail-nerd apartment mood, soft daylight, no logos, no brand names, no readable text, 16:9

Die Platte „Spiele im Auto“ triggert Bilder von Beifahrer-Langeweile auf der Autobahn. Google schreibt Charging Station und Curbside Pickup. Das ist Idle, nicht Drive. An der Ladesäule warten Nutzende ohnehin. Beim Drive-in oder Curbside steht der Wagen, der Motor darf laufen oder nicht – der Parkmodus entscheidet über die Freigabe der Activity, nicht Ihr Wunsch nach Highscore.

Personifikation: Die Ladesäule tickt Minuten herunter. Das Infotainment gähnt. Das Spiel klopft an und sagt: Fünf Level bis 80 Prozent. Sobald Sie den Fuß vom Bremspedal nehmen und losrollen, muss das Spiel den Mund halten – Audio inklusive. Wer die Session speichert und beim nächsten Parken wiederherstellt, erfüllt EP-2. Wer neu startet und Fortschritt verliert, liefert eine parked Experience, die sich wie ein Absturz anfühlt.

Für Entwickelnde heißt der Use Case: Sessions kurz halten, Speicherstände billig machen, Touch-Targets groß (UX-1: mindestens 64 dp in den differenzierten Stufen; Abstände UX-2), Schrift lesbar (UX-3: mindestens 24 sp, wo die Tier-Anforderungen greifen). Car ready (Tier 3) ist für Parked Categories die Eintrittskarte in den Store; Car optimized und Car differentiated bauen darauf auf. Games sitzen primär in der Parked-Welt – wer „während der Fahrt mitspielen“ plant, baut gegen die Kategorie.

Alltagstest ohne Labor: nächste längere Ladesession, Handy mit Android 15+, Android Auto verbunden, ein Early-Access- oder Collection-Titel. Beobachten Sie Launch im Stand, Verhalten beim Anfahren, Audio, Relaunch. Dann dieselbe Checkliste gegen Ihr eigenes Build auf der DHU. Die Differenz zwischen „auf dem Sofa am Emulator“ und „an der Säule mit UX-Restriction“ ist genau der Grund, warum wir Track und UX trennen.

Noch konkreter an der Säule: Die Ladekurve flacht ab, Sie haben zwölf Minuten „echter“ Idle, bevor der Timer endet oder der nächste Termin drängt. Zwölf Minuten sind kein Open-World-Abend – sie sind Puzzle, Score-Attack, ein Level, das sich sauber pausieren und fortsetzen lässt. Spiele, die lange Cutscenes brauchen oder Offline-Checks ignorieren, scheitern an genau diesem Fenster. Der Use Case erzwingt Design für Unterbrechung, nicht Design für Marathon.

Docs-Stand vs. Blog-GA: Lesen Sie das Datum

Nerd-Alarm: Die Seite Build games for cars war zum Stand um den 14. September 2026 (Last updated laut Seite) bereits mit Quality-Hinweisen und Aspect-Ratio-Vorgaben gefüllt; Track-Formulierungen in älteren Spiegelungen können noch nach Beta klingen. Den GA-Claim – Open Testing und Production für die Games-Kategorie – setzen wir auf den Blog-Post von Jan Kleinert vom 21. September 2026. Die Quality-Seite selbst vermerkt unter September 2026: Games von Beta zu GA; Entwickelnde können auf alle Track-Typen publishen.

Wer also nur die Doku öffnet und „noch Beta?“ liest, arbeitet mit einem Docs-Stand, nicht mit dem Blog-Ereignis. Wer nur den Blog liest und die Quality Guidelines überspringt, kennt den Track und kennt die Prüfung nicht. Beides zusammen: GA ist da; die Checklisten sind verbindlich; DHU und AAOS-Emulator bleiben Pflichtwerkzeuge vor Open Testing/Production.

Testing-Docs und Quality-Checklisten gehören zusammen. Die Quality-Seite verweist explizit auf Tests mit AAOS-Emulator und Desktop Head Unit, bevor Sie bei Google Play einreichen. Das ist kein optionaler Workshop. Das ist der Unterschied zwischen „wir haben published“ und „die parked UX ist freigegeben“ – redaktionell unsere These, gestützt auf die Reihenfolge im Blog: implementieren, gegen Guidelines testen, DHU/Emulator, dann Track.

Neben Android Auto existiert die CarPlay-Welt mit eigenen Karten- und Plattform-Deals; wer Plattformvergleiche sucht, findet bei uns etwa den Blick auf Apple Maps und die Ford-E-Auto-Plattform. Hier bleiben wir bei Android, Auto und Games – und bei der Parkmodus-Logik.

Fail-Muster: Prod ohne UX-Check

Spoiler aus der Praxis der Review-Logik, nicht aus einem geleakten Ticket: Sie setzen appCategory="game", haken in der Play Console Android Auto und AAOS an, laden den Bundle auf Production – und haben weder DHU noch Quality-Selbstcheck gemacht. Die Ampel „Track erlaubt“ war grün. Die parked UX war es nicht. Typische Fail-Muster:

• Letterbox auf Canonical Landscape, weil das Phone-Layout 1:1 gespiegelt wurde.
• Audio läuft weiter, wenn die DHU den Drive-State simuliert – MediaSession kennt den Parkmodus nicht.
• distractionOptimized steckt noch in einer Activity aus einem alten Car-Template-Experiment.
• State Restore fehlt: Relaunch vom Homescreen ist ein Kaltstart; EP-2 greift.
• Gamepad als required="true", obwohl Touch reicht – Distribution schrumpft unnötig.
• AAOS-required falsch für den gewählten Track; das Build liegt im falschen Regal.

Im Ernst: Jeder dieser Punkte steht in Blog oder Guidelines. Keiner braucht ein neues Framework. Was fehlt, ist Disziplin vor dem Prod-Klick. GA macht den Klick möglich. Es macht ihn nicht klug. Die These bleibt: „published“ ist nicht „Parked-UX freigegeben“. Wer Feier und Checkliste trennt, spart sich die Rejection-Schleife.

Bastelprojekt als Gegenmittel: Eine Abend-Session mit DHU, TrivialKart als Referenz, eigenes Debug-Build, Drive-State umschalten, Audio lauschen, Screenshot der Pillarbox-Falle, Manifest-Diff ohne distractionOptimized. Danach erst Open Testing. Klingt pedantisch – ist billiger als ein geblocktes Update für alle Form Factors.

Was Entwickelnde jetzt konkret anfassen sollten

Die kurze Version als Arbeitsliste, ohne Marketing-Nebel:

1. Manifest: appCategory="game", CAR_LAUNCHER für Android Auto, Automotive-Feature mit korrektem required je Track, optional Gamepad required="false".
2. Parked-Verhalten: kein distractionOptimized; Audio an Drive-State koppeln; State Restore; Input-Responsiveness.
3. Layout: adaptive, volle Fläche, Canonical Sizes / Hardware Profiles; Pillarbox-Falle auf Landscape vermeiden.
4. Tests: DHU (Android Auto), AAOS-Emulator, Selbstreview gegen Games-Abschnitte der Car App Quality Guidelines.
5. Play Console: Form Factors opt-in; erst Internal/Closed absichern, dann Open Testing/Production – wohl wissend, dass die Car-Review greift.

Klingt einfach, ist es aber nicht, sobald Unity-Lifecycle, MediaSession und Fahrzeugsignale in demselben Prozess hängen. Bastelprojekt heißt hier: einmal TrivialKart-Pfad nachbauen, einmal eigenes Audio am Fake-Drive-State der DHU brechen sehen, einmal Pillarbox auf einem Canonical-Profil messen. Wer das überspringt, feiert GA und debugt später Rejection-Mails.

Wir bei digital-magazin.de trennen bewusst Feier und Checkliste. Die Feier gilt dem Meilenstein: Games-Kategorie GA, Collections, Idle-Use-Cases an Säule und Pickup. Die Checkliste gilt jedem Prod-Build, der ohne Quality-Check und ohne DHU live gehen will. Published ist ein Track-Status. Parked UX freigegeben ist ein Testergebnis.

Lesende, die nur die Headline „Android-Spiele im Auto GA“ mitnehmen, sollten den Parkmodus laut mitlesen. Nutzende an der Ladesäule bekommen Idle-Unterhaltung – nicht Freizeitpark auf der Autobahn. Entwickelnde bekommen offene Tracks – und dieselben Ablenkungsregeln wie zuvor, nur verbindlicher geprüft. Das Infotainment bleibt Türsteher. Das Spiel bleibt Gast im Stehen.

Was bleibt?

Der Punkt ist: Am 21. September 2026 ist die Games-Kategorie für Android Auto und AAOS Google built-in GA – Open Testing und Production inklusive. Parkmodus bleibt die Bühne; Fahrt bleibt gesperrt; Audio muss schweigen, sobald es losgeht. Wer Production ohne Abgleich mit den Car App Quality Guidelines und ohne Desktop-Head-Unit- bzw. Emulator-Lauf ansteuert, verwechselt Ampel und Abnahme. Lesen Sie den Blog von Jan Kleinert, halten Sie den Docs-Stand von Build games for cars dagegen, und lassen Sie das Infotainment den Türsteher spielen, bevor Google Play es tut.