On September 21, 2026, Google announced the general availability of its games category for Android Auto and for Android Automotive OS with Google built-in. Developers can now use Google Play's open testing and production tracks to deliver games that users play while parked.
This is not the first time games have run on in-car screens. Support began as a beta in May 2025, and several launch titles were already available. What opened this time is the public distribution path that lets games reach beyond a limited group of testers. For developers who already have an Android game, the entry point is only a few lines in the manifest, but the work before release extends to parked-state detection, state restoration, screens, input, and review.
What changed with general availability is the distribution path, not the feature
The Android for Cars changelog shows that on May 22, 2025, games could be published only through internal testing and closed testing. Around that time Google cited Angry Birds 2, Farm Heroes Saga, Candy Crush Soda Saga, and Beach Buggy Racing 2 as early examples on Android Auto, but general developers needed early-access participation to reach production.
What general availability changes is not the ability to run games in the car but the reach of distribution on Google Play. In May 2025 it was internal and closed testing; in September 2026 it extends to open testing and production.
| Date | Status stated by Google | Release scope available to developers |
|---|---|---|
| May 22, 2025 | Games support begins in beta | Internal testing, closed testing |
| September 14, 2026 | General availability recorded in the changelog | All track types |
| September 21, 2026 | General availability announced on the official blog | Open testing and production tracks explicitly stated |
Sources: Android for Cars changelog and Android Developers Blog. The comparison covers distribution tracks for the games category, not in-car runtime features or the number of supported vehicles. September 14 is the documentation update date and September 21 is the blog announcement date, so they are listed separately.
The difference is significant. Internal testing suits in-development checks, and closed testing still limits participants. With open testing and production available, developers can build in-car play into their general release plans. Being allowed to publish, however, is not the same as each game passing review and appearing in every vehicle.
Android Auto and Android Automotive OS are not the same in-car Android
The two names sound alike, but games run in different places. On Android Auto, a smartphone running Android 15 (API level 35) or higher runs the game and projects it to the connected car display. Developers add android.intent.category.CAR_LAUNCHER to the activity's intent filter, creating an entry point that can be launched from the car launcher.
On Android Automotive OS, apps are installed directly on the car's head unit. android:appCategory="game", which identifies the app as a game, is required on both, but android.hardware.type.automotive for in-car hardware must also be declared according to the distribution method. When shipping the same artifact through a mobile track, android:required="false" is needed; on a dedicated track you can choose true, false, or leave it unspecified. Unspecified is treated as true, so only Android Automotive OS devices are targeted.
| Item | Android Auto | Android Automotive OS |
|---|---|---|
| Where it runs | Smartphone running Android 15 or higher | Car head unit |
| In-car entry point | Add CAR_LAUNCHER to the activity |
Declare android.hardware.type.automotive |
| Distribution unit | Included in phone/tablet apps | Mobile or dedicated track |
| Main test environment | Desktop Head Unit (DHU) | Android Automotive OS emulator |
| Categories usable while parked | Games only, for now | Games, video, browsers |
In other words, even if game code is shared, the distribution and test targets are not one and the same. Android Auto inherits the smartphone's performance and OS requirements, while Android Automotive OS must fit the head unit's hardware and available services. Google's documentation does not give the number of supported vehicles or country-by-country availability at the time of general availability, so the potential market size of the two combined cannot be calculated.
Stop the screen and sound the moment the car starts moving
Games are apps for use while parked. Android Auto and Android Automotive OS block activity launch and use when the vehicle is moving or in a state that could distract the driver. When Android Auto detects driving, it automatically closes apps on the car display.
But the OS block alone does not satisfy the safety requirements. Developers must not apply distractionOptimized to a game's activities, and must stop audio when driving begins and prevent playback from resuming while the car is moving. If sound effects or background music continued after the screen went dark, the game would cross the boundary of being a parked-only app.
At the same time, the game's state has to be protected. Google's quality requirements ask that, when the game is relaunched from the home screen, it return as close as possible to its previous state. If a car that was charging while someone played starts moving, the display and sound must stop, and when the car is safely parked again and the game reopened, progress should be restored. Without this state-transition design, an interruption made for safety could lead directly to data loss or a restart from the beginning.
Being unusable while driving is not a missing feature but a condition of publication. What developers need to verify is less whether the game launches than whether the display, audio, and saved state switch correctly each time the car moves from parked to driving and back to parked.
The weight of porting comes down to screens, input, and review
Manifest changes are only the starting point. In-car displays come in landscape, portrait, and notched shapes, and a game locked to a phone's portrait orientation will not pass as is. The target aspect ratios Google gives are 16:9 landscape and 9:16 portrait for Android Auto, and 4:3 landscape and 10:16 portrait for Android Automotive OS. On Android Auto, if large pillarboxes (side margins) appear in landscape, Play review will reject the app.
On Android Auto, the DHU lets you test the standard small landscape screen at 800×480, 160 dpi. The wide-landscape and portrait sample configurations are both 1920×1080, 160 dpi, but differ in the margins that crop the display area. Even at the same resolution, the area where controls and subtitles can be placed is not the same. UI pinned to screen edges and camera views that assume a particular ratio tend to break under in-car validation.
Touch input is available, and gamepad support is optional. If you support it, declare android.hardware.gamepad with android:required="false". If you set it to true, then even in in-car environments where a controller can be connected, the device may not have that feature and could be dropped from distribution. If you add input methods, it is worth checking the on-screen button display, focus movement, and recovery after disconnection within the same play state.
As the release stage rises, so does the weight of quality review.
| Google Play track | Treatment of car quality review | Impact of non-compliance |
|---|---|---|
| Internal testing | None | Not blocked by car quality review |
| Closed testing | Non-binding | Notified, but the submission is approved |
| Open testing | Binding | Submission cannot go through if non-compliant |
| Production | Binding | Submissions containing non-compliant builds are rejected |
Source: Google's guide to distributing car apps. Games are also required to respond to input and avoid freezing or stuttering during play, per the car app quality guidelines. General availability does not loosen review. Rather, now that games can reach production, flaws in screen adaptation or state management become problems that can halt a release date.
What to watch next is actual distribution reach, not vehicle counts
In its announcement, Google did not disclose the total number of in-car games, the number of supported vehicles, available countries, user numbers, or revenue sharing. Even with a smartphone running Android 15 or higher, a game can be played only if the connected head unit supports parked games, the game is distributed to that region and device, and it passes car review. It is too early to work backward to a market size from the single phrase "general availability."
To gauge adoption, it will be necessary to watch whether the number of titles discoverable on Play and the number of supported vehicles grow, and how games playable by touch alone diverge from those that assume a gamepad. Whether launch, resume, and exit work smoothly in the short windows of waiting to charge or waiting for a pickup will also matter. For in-car games, being able to survive interruption without breaking is likely to count for more than being playable for long sessions.
The first thing developers should check is not whether a large in-car-specific overhaul is needed. It is whether an existing game's screen can adapt to four aspect ratios, stop sound and display when driving starts, restore state at the next stop, and withstand production review. Titles that meet those conditions can connect this newly opened distribution path to real users.