Games Are the Only Parked App Android Auto Runs. The Play Category Is Still Closed-Testing Only.

Android Auto now runs games on the head unit while parked — the only parked app category it supports. The Play Store category is still beta, closed-testing only. For anyone holding a licensed catalogue, the car is a genuine new surface with a very narrow door, and that door admits one native Android package at a time.

Google spent the first half of 2026 turning the dashboard into an entertainment device. The May announcement was mostly about video and Gemini. The more interesting material sits in the developer documentation, where a single sentence defines the entire opportunity for game licensors: on Android Auto, games are the only thing you are allowed to ship.

🚗 What Google Actually Announced, and What It Left Out

The headline figures come from Google's own Android in cars post of 12 May 2026: "more than 250 million Android Auto-compatible cars on the road today", and Google built-in "now available in more than 100 models from 16 brands". Parked video streams in full HD at 60fps, and — the detail worth memorising — video "transitions seamlessly to audio-only when driving begins".

Two products hide behind the word "Android" here, and conflating them will wreck a forecast.

• Android Auto is phone projection. The car's infotainment system is whatever the manufacturer built; your phone casts an interface onto it. This is the 250-million-vehicle number.
• Google built-in, running Android Automotive OS, is Android as the infotainment OS itself, with a Play Store on the dashboard and no phone required. This is the 100-models-from-16-brands number.

Those two install bases differ by roughly two orders of magnitude. They also differ in what they will run. Google's parked apps documentation lists video, games and browsers as parked categories on Android Automotive OS — but on Android Auto, the docs are blunt: "Games are the only parked app category supported by Android Auto at this time."

🎮 One Category, and It Happens to Be Yours

That exclusivity is the whole story. Every other content vertical that would like a slice of a captive driver's attention — streaming, news, shopping, social — is locked out of the projection product entirely. Games are in.

The mechanics are specific. Parked apps on Android Auto require Android 15 or higher on the connected phone, and the app "runs directly on the head unit" rather than on the handset. The manifest needs an activity carrying android.intent.category.CAR_LAUNCHER, and games additionally have to declare android:appCategory="game" on the application element. Gamepad support is optional and must be declared with required="false", because plenty of head units can pair a controller and plenty cannot.

Then comes the sentence that should reset every in-car roadmap this year. From Google's games-in-cars guide: "The Games category is in beta. At this time, anyone can publish games to internal testing and closed testing tracks on the Play Store. Publishing to open testing and production tracks will be permitted at a later date."

There is no production track. There is a nomination form for early-access partners and there are closed tests. If a vendor, an agency or a platform is offering you an in-car games launch this quarter, what they are offering is a closed test with a press release attached. That is not nothing — first-mover position in a category with one occupant is worth having — but it should be budgeted as R&D, not as distribution.

⏱️ The Session Is a Charging Stop, Not a Commute

The obvious question is how long anyone actually sits in a parked car with the screen on. The best public number comes from the US Department of Energy's Fact of the Week #1319, published December 2023, drawing on roughly 2.4 million charging sessions logged between June 2020 and June 2023.

• Paid DC fast charging: 42 minutes per session, averaging 22 kWh.
• Free DC fast charging: 1 hour 18 minutes, averaging 42 kWh.

Forty-two minutes is a very unusual session length in casual games. A mobile arcade session is measured in single-digit minutes. Forty-two minutes with a large landscape screen, a comfortable seat and nothing else to do sits much closer to a handheld console session — and that has design consequences that run in the opposite direction from the hypercasual instincts most catalogues were built on.

It also has a caveat that matters more than the average: the session ends when the charge finishes or the passenger gets bored, and neither event respects a level boundary. Long session, arbitrary termination. Those two together select for a specific kind of title.

📐 800×480, 64dp Touch Targets, Ten Seconds to Launch

Google publishes canonical car screen configurations for testing, and they are not phone screens. Small landscape is 800×480 at 160 dpi. Wide landscape and portrait are both 1920×1080 at 160 dpi. At 160 dpi a pixel is a dp, so the small case is an 800×480 dp layout — a small-tablet canvas, wider and shorter than anything a portrait mobile build assumes.

Requirement DO-2 in the car app quality guidelines states the app "is not significantly pillarboxed when running on landscape displays". A portrait-locked casual title fails that on sight. This is the single most common disqualifier in an existing mobile catalogue, and you can audit for it in an afternoon without writing any code.

The interaction requirements are stricter than the phone equivalents by roughly a third:

• UX-1: touch targets at least 64dp. Material's usual floor on a phone is 48dp.
• UX-2: targets at least 24dp apart, and 24dp from screen edges.
• UX-3: font sizes at least 24sp.

And the performance requirements assume a driver with no patience. DR-2: the app must launch in no more than 10 seconds. DR-3: content must load in no more than 10 seconds. DR-1: buttons respond within two seconds. EP-3: "The app is responsive to input and does not freeze or stutter during gameplay."

EP-3 is the one that bites hardest, because head units are not phones. Infotainment silicon is specified years before the vehicle ships and then lives in the car for a decade. A build that comfortably holds 60fps on a mid-range handset is not automatically safe on a dashboard SoC, and there is no telemetry channel that will tell you it is failing.

🛑 DD-3 Ends the Session Mid-Level, Every Time

The requirement that shapes the product more than any other is DD-3: "The app must not be launchable or usable while driving and must not play any audio."

Google's video experience shows what a graceful version of that looks like — the picture stops, the audio continues. A game gets no such fallback. It stops, completely and silently, the moment the vehicle moves. There is no warning, no grace period, no save prompt. IN-2 also forbids heads-up notifications, so you cannot even ask for attention on the way out.

The counterweight is EP-2: "When the app is relaunched from the home screen, the app must restore the app state as closely as possible to the previous state."

Read those two together and the design brief writes itself. The player will be cut off at random, and your only job is to make the return cheap. That eliminates a surprising amount of a standard casual catalogue:

• Timed runs and countdown modes. A clock that keeps running through an interruption converts every drive-away into a loss.
• Anything real-time or multiplayer. A disconnect that is guaranteed and unannounced is not something matchmaking can absorb.
• Energy, lives and daily streaks. Punishing a player for an event they did not cause is a review-score problem.
• Rewarded video with a mandatory completion. A killed impression is an unpaid ad and an ungranted reward, and the player blames you for both.

What survives is turn-based, save-anywhere, single-player content: puzzles, card and board games, match-3, word games, tycoon and idle loops, tabletop conversions. Which is to say, a decent slice of an existing licensed catalogue — just not the slice most people would pick first.

🌐 Why an HTML5 Catalogue Doesn't Cross Over in a Sprint

Browsers are a parked category on Android Automotive OS. They are not one on Android Auto. So on the surface with 250 million vehicles behind it, there is no web runtime you can point a game URL at, and a licensed HTML5 build has no direct route in.

The realistic path is a native wrapper per title: an Android package that carries the web build, declares the car intent category and the game app category, and gets reviewed against the car quality guidelines. That is essentially the same work as the Android packaging route you would already be doing for a Play Store release, plus a car-specific review pass and a layout audit. It is not exotic. It is also not free, and it is per title, not per catalogue.

One more piece of friction worth knowing before you debug it at 2am: the docs note "there is additional filtering built into the Google Play Store to prevent parked apps from being distributed to devices without the necessary fixes. If your app is otherwise compatible with a device, this might be the reason why it is not installable on that device." An in-car title that will not install on a specific head unit is often not a bug in your build at all.

📉 Underwrite the Install Base Conservatively

The 250 million figure is a ceiling, not an addressable market. Subtract every vehicle whose head unit does not support running parked apps, every driver on a phone below Android 15, and — for now — every user at all, because there is no production track to publish to.

The built-in side has its own discount, and it is structural rather than temporary. ABI Research forecast that fewer than 6% of new vehicles shipped with Android Automotive OS would carry Google Automotive Services, arguing that carmakers were wary of the Android compatibility obligations, the limits on customisation and ownership, and the uncertainty around long-term support. That forecast is several years old now and reasonable people can argue about how it landed, but the mechanism it identified still holds and is the part operators keep missing: Android Automotive OS in a vehicle does not imply a Play Store in that vehicle. Manufacturers ship AAOS as a base platform and then substitute their own app store, or ship no store at all. No Google Automotive Services means no Play Store, which means no games, whatever the OS badge says.

🚫 Four Ways to Waste This Budget

Porting the catalogue. Ten titles is not one project with ten builds; it is ten review submissions, ten layout audits and ten sets of head-unit performance surprises. Pick three that already run landscape and already save anywhere.

Modelling it as an ad channel. There is no published in-car eCPM benchmark, because there is no production inventory. Anyone quoting you one is extrapolating from tablets. Model this at zero revenue and justify it as placement, brand or platform-partnership value instead.

Buying source code you cannot re-layout. Car compliance is a UI problem before it is anything else. If a licence gives you a binary and no ability to change touch target sizes or unlock orientation, it cannot become a car title. Check what your source-code terms actually grant before you shortlist.

Assuming your existing licence covers it. A grant covering "web and mobile" does not obviously extend to an automotive head unit, and a distribution clause naming "app stores" may or may not reach a manufacturer's own in-car store. This is cheap to fix on the next renewal and expensive to discover after a launch.

🎮 Where a Licensed Catalogue Fits

Forestry Games has licensed HTML5 and Android games since 2017, across a catalogue of 1,049 titles, and works with brands and publishers on branded builds. The practical relevance here is narrow and worth stating plainly: the constraint on in-car games is not access to content, it is per-title engineering and rights scope. If you are evaluating the surface, the useful questions to put to any licensor are whether the grant names in-vehicle infotainment, whether you receive source you can re-lay-out, and whether the titles you want are landscape-native and save-anywhere. Those three answers determine your cost per car-ready title far more than the catalogue size does.

🧭 The Next Ninety Days

The category will open. Google does not build canonical car screen configurations, publish game-specific quality tiers and stand up a beta track for a product it intends to abandon. But it is not open now, and the gap between "beta with closed testing" and "production" is where a sensible programme gets built rather than announced.

Concretely: audit your catalogue for landscape-native titles with no timed runs and no mandatory ad completions, and count how many survive — that number is your real starting position. Take the best three and check them against DD-3, EP-2, UX-1 and DR-2 on paper before writing any code. Build one, test it on all three canonical screen configurations in the emulator, and push it to an internal testing track so you learn where the review friction actually is. Nominate for early access. And put in-vehicle infotainment into the platform scope of the next licence you sign, whether or not you have decided to use it, because it costs nothing at signature and is a renegotiation later.

One title, tested, in a closed track, with the rights already cleared, beats a catalogue-wide port that arrives the same month the category opens to everyone else. Start with the licence scope, not with the build.