Android Auto app development

Two platforms, one confusing pair of names

Android Auto projects an app from the driver's phone onto the car's screen. The app runs on the phone. The car is a display and an input device.

Android Automotive OS is Android running natively in the vehicle, as the car's own operating system, flashed by the manufacturer into the infotainment computer. The app runs on the car.

That difference decides what you are allowed to build, and Google's parked-app documentation states it as a table:

Parked app category	Platform
Video	Android Automotive OS only
Games	Android Auto and Android Automotive OS
Browsers	Android Automotive OS only

Video apps cannot be built for Android Auto. Not restricted, not discouraged — the category is not supported there. So if video in the car is your goal, Android Auto is not a smaller version of the answer, and any proposal that offers it is describing something that cannot exist.

What each one runs, and when

Android Automotive OS maps the car's state into three restriction sets: parked has no restrictions, idling prohibits video and configuration screens, and moving is fully restricted.

A video app declares android:appCategory="video" in its manifest, and Google is explicit that all video apps must pause playback when user experience restrictions are active. So video is a parked experience, by design and by regulation rather than by limitation.

Android Auto has no video path at all, parked or otherwise. What it has is audio, and that turns out to be the more useful product.

Audio is the realistic in-car product — but mind the category

A viewer in a moving car cannot watch your catalogue and should not want to. What they can do is listen: music, podcasts, match commentary, or the audio of something in your library that works without pictures. That works on both platforms, while driving, today.

The precision that matters is the app category, because the rules differ and this is where teams get caught.

A video app on Android Automotive OS is a parked experience. Driver distraction guideline DD-3 states that video, games and browser apps must not be launchable or usable while driving and must not play any audio. So a video app does not become a radio when the car moves.

A media app is the category that plays while driving, with its own constraints — guideline MA-1 requires that media apps must not autoplay on startup or without the user selecting the app or the media.

So "repurpose the video app as audio" means, in practice, shipping a media experience alongside the video one. The catalogue, entitlement model and playback stack are shared; the app category and its interface are not.

There is a route that closes the gap and it is not ready. Android Automotive OS has a feature letting a video app continue playing audio while driving, with driving-optimised playback controls, declared through a com.android.car.background_audio_while_driving feature flag. It is in beta and limited to early access partners — the right shape for this use case, and not something to put a launch date against.

Android Auto app development for broadcasters is the clearest case for the audio product, since news, sport and talk output is audio-viable without any adaptation.

Design the audio experience first. It is the mode that works on both platforms and in every driving state, and for most services it is the product that will actually get used.

Not every Automotive OS car has a Play Store

This is the distribution fact that catches people, and it follows from how the platform is licensed.

Google Play — the Play Store and Play services — is available only on cars with Google built-in. Google Automotive Services is a licensable bundle including Play and Maps that a manufacturer may choose to integrate or not, so an Android Automotive OS car without it offers no Play-based distribution at all. You cannot assume a given vehicle has a store you can ship to.

Billing is stranger still. On cars with Google built-in, Play Billing is supported but the purchase cannot be completed in the car — the user finishes it on another device through the Play app or the website.

Set that beside the rest of a rollout, where Apple has its reader-app route, Roku requires Roku Pay on the device and Amazon requires its own in-app purchasing. The car adds a shape where the transaction deliberately leaves the vehicle.

A few manifest details decide whether you reach cars at all:

• An app must declare android.hardware.type.automotive in a <uses-feature> element to be distributed to cars through Google Play.
• Declaring features such as Wi-Fi, camera or a specific screen orientation as required can prevent distribution to otherwise compatible vehicles. Google's guidance for parked and passenger apps is to set them android:required="false".
• Cars are fixed-orientation devices that may be portrait or landscape, so an app must support both to be distributed broadly.

None of these are difficult. All of them are easy to get wrong once and then wonder why the app is missing from half the fleet.

Android Auto app development for telcos runs into the licensing question most often, since operator device programmes and manufacturer relationships are exactly where Google Automotive Services is negotiated or declined.

The manufacturer owns the platform

Worth stating plainly, because it changes who you are actually dealing with.

Android Automotive OS is embedded software that the vehicle manufacturer flashes into the car. The manufacturer decides which services are enabled, which APIs are exposed and which apps are allowed to run; Google supplies the base platform and a reference implementation. User experience restrictions are defined by the manufacturer and may vary by geography.

So the route to viewers runs through car makers and their model programmes rather than through a store you can submit to this afternoon. That is a business development timeline, not an engineering one, and no amount of development speed shortens it.

What carries over from your Android app

The honest split, if you have an Android app already:

Carries over. On Android Automotive OS, a great deal — it is Android, so your player, DRM integration, API layer, entitlement model, catalogue code and much of your business logic move across. On Android Auto, the in-car experience is an extension of your existing app rather than a new product.

Does not. The interface, on both, because driver-distraction rules are prescriptive rather than advisory. Any assumption that video is available while moving. Picture-in-picture and app widgets, which are unavailable on many Automotive OS vehicles. And your testing approach, since the states that matter — parked, idling, moving, restrictions active — are not the ones your existing suite exercises.

Android Auto app development for vod platforms is the hardest to justify on numbers alone, because a catalogue product leans on browsing and browsing is exactly what a moving car forbids.

Is it worth doing?

An honest answer, since this is a Tier 2 surface for nearly everyone.

Probably not yet as a video play. The Automotive OS installed base is small next to televisions and phones, and video works only when parked. If you are choosing between another television platform and the car, take the television.

Yes in three cases. When you have an audio-viable catalogue and the in-car audio product genuinely extends your audience. When a car maker or operator relationship makes it strategic rather than speculative. And when being early is worth something, because very few OTT providers offer this at all.

What drives the cost

A range that fits everyone helps nobody, so here is what actually sets the number.

1. Which platform you mean, and whether video is in scope or the product is audio-only.
2. Whether an Android app already exists, which is most of an Automotive OS build.
3. How far the manufacturer conversations have progressed, and whether the target vehicles have Google built-in.
4. Your driver-distraction design work, which is a real design phase rather than a styling pass.

Tell us those four and you get a real number rather than a range that covers everyone.

Who builds it

Everything above is how we actually work rather than a checklist assembled for this page.

We build our own tooling. VibeView came out of exactly this problem — shipping to every platform means testing on every platform — and in-car adds states rather than just devices, since the same app must behave correctly parked, idling, moving and under restriction. When a project needs middleware rather than only an app, MwareTV is a technology partner of ours, so both sides come from one conversation.

And the people who scope your project are the people who build it. There is no account layer between you and the engineer who knows which of these two platforms will refuse to play your video.

Where this sits in the rest of your rollout

Late, unless a manufacturer relationship pulls it forward.

Build the surfaces with the audience first — televisions, then phones and web. The car is where you go when the catalogue is proven, the entitlement model is settled, and you have either an audio product worth shipping or a partnership that makes the video one worth having.

CarPlay is the natural companion decision, and it answers the same question differently.

We build these, end to end

The Android Automotive OS app, the Android Auto audio surface, driver-distraction-compliant interface design, playback and DRM integration, the manifest and distribution work that decides which vehicles you reach, and the shared layer that keeps the two from becoming separate products.

If you are trying to work out whether the car is worth it yet, we will tell you straight — and for most services today that is an audio product now and a video one when the installed base earns it.

Send us which platform you mean, whether an Android app already exists, and whether audio or video is the goal. You will get back a scope and a number rather than a brochure.