AppMatic Tech builds Android Automotive OS infotainment apps in Kotlin, Android Auto apps with the Android for Cars App Library, and companion mobile apps in Swift, Kotlin, and Flutter for automotive brands, fleets, and media platforms. The Ahmedabad, India engineering team delivered an AAOS app for a 100M+ potential-user platform in two months.
Drivers see one car screen, but developers face three different platforms with different rules for what runs, where it runs, and how it gets approved. Choosing the wrong one early wastes a release cycle.
Key takeaways
| Point | Detail |
|---|---|
| AAOS runs on the car | The app installs on the head unit and works without a phone. |
| Android Auto and CarPlay project the phone | The app runs on the phone and renders on the car display. |
| In-car apps are category-limited | Media, navigation, point of interest, and a short list of other categories. |
| Driver distraction drives the UI | Large targets, glanceable text, and limited interaction in motion. |
| Streaming context is hostile | Connectivity varies inside a moving vehicle, so caching and buffering decide playback quality. |
What is the difference between AAOS, Android Auto, and CarPlay?
The three platforms differ in where the app executes, and that single fact drives most other differences.
| Platform | Where the app runs | Needs a phone | Primary stack |
|---|---|---|---|
| Android Automotive OS | On the vehicle head unit | No | Kotlin, Android SDK, Car App Library, media services |
| Android Auto | On the phone, projected to the car display | Yes | Kotlin, Android for Cars App Library |
| Apple CarPlay | On the iPhone, projected to the car display | Yes | Swift, CarPlay framework templates |
AAOS is the platform to choose when the product must work independently of the driver's phone, for example native in-car streaming, or when a vehicle brand ships its own app store experience. Projection platforms reach more cars sooner because the car needs only to support the protocol, but the app is limited by the phone's connection and by template rules.
Which app types can run in the car?
None of the three platforms allows arbitrary apps on the car screen. Each approves a short list of categories, because the car display is a safety surface.
- Media and audio apps are supported on all three platforms and are the largest category. On AAOS and Android Auto they are built around a media session and browse tree that the car UI renders, so the app supplies content and playback state while the system supplies the interface.
- Navigation and point-of-interest apps use template classes from the Android for Cars App Library on Android, and equivalent templates in the CarPlay framework on iOS.
- EV charging, parking, and similar categories are supported through approved template categories, and Apple requires a CarPlay entitlement granted per category before an app can ship.
- Games, video, and free-form browsing are restricted or blocked while driving.
The practical consequence for a product team is that the in-car experience is a constrained subset of the phone app. The scope question is which three or four actions a driver needs in motion, not how to port every screen.
How does driver distraction shape the UI?
Driver distraction guidelines are the review gate that rejects most first submissions. The rules are consistent across platforms even where the wording differs:
- Large touch targets. Controls must be operable at arm's length without precise aim.
- Glanceable hierarchy. The single most important element, such as now-playing title or next turn, must be readable in under two seconds.
- Shallow navigation. Deep list trees and long scrolling are limited in motion.
- No free-form text entry while moving. Search uses voice or a parked-only keyboard.
- Short, stable text. Marquee text, animations, and layout shifts are avoided.
AppMatic Tech designs these constraints in at wireframe stage and validates against the platform guideline before release, because a rejection near a launch date is the most expensive place to discover a layout problem.
What does the engineering work look like?
Beyond UI, three engineering areas separate an in-car app from a phone app with a larger screen.
| Area | Phone app assumption | In-car reality |
|---|---|---|
| Connectivity | Stable Wi-Fi or 4G | Tunnels, dead zones, and handovers every few minutes |
| Session lifecycle | App open means user attention | Ignition on and off, with playback expected to resume |
| Input | Touch and keyboard | Touch, steering wheel buttons, and voice |
Streaming apps therefore need request caching, resumable playback, and a buffer strategy tuned for intermittent networks. Apps that talk to vehicle data, such as charging status or trip history, add a further layer covered in BLE, MQTT, and telematics architecture and, for AI assistants on vehicle data, in MCP servers for device and fleet data.
What happened on a real AAOS delivery?
AppMatic Tech took over an Android Automotive OS infotainment app for a leading Indian FM and music streaming platform with 100M+ potential users. The inherited Kotlin codebase had UI rendering problems, API failures, and playback instability, and the festive season release date could not move.
The two-month engagement covered four workstreams:
- Stabilisation. Root-cause diagnosis of the rendering, API, and playback faults before any new feature work.
- In-car UI. Redesign to large touch targets and a glanceable hierarchy for the head unit screen, validated against the Android Automotive driver distraction guidelines.
- Streaming optimisation. Request caching, response handling, and playback buffer management tuned for in-vehicle connectivity.
- Release management. Testing, QA, and certification preparation for head unit deployment.
The full breakdown is in the Android Automotive OS case study.
Which platform should a product team start with?
| Product situation | Start with | Reason |
|---|---|---|
| Streaming or media brand, car brand partnership | AAOS | Native in-car presence, no phone dependency |
| Wide reach across existing cars | Android Auto and CarPlay | Works with cars already on the road |
| Charging, parking, or navigation product | Template categories on all platforms | Approved categories with shared design rules |
| Telematics or fleet product | Mobile app plus dashboard first | Car screen adds little for back-office users |
Many teams ship the phone app first, then add the in-car surface once the content API and playback logic are proven.
For the wider picture across telematics, EV charging, dealer platforms, and vehicle-data AI, see the AppMatic Tech automotive software development page. Related engineering is covered under mobile app development, and AppMatic Tech can scope an in-car app through contact@appmatictech.com.
Sources
| Claim used in this article | Source |
|---|---|
| AAOS app delivery, driver distraction validation, and two-month timeline | Android Automotive OS case study |
| Android Automotive OS runs on the vehicle head unit; Android Auto projects from the phone | Android Developers, Android for Cars |
| Car App Library template categories | Android Developers, Car App Library |
| CarPlay category entitlements | Apple Developer, CarPlay |
Frequently Asked Questions
- What is the difference between Android Automotive OS and Android Auto?
- Android Automotive OS is a full operating system that runs on the vehicle's head unit, so apps install on the car and work without a phone. Android Auto is a projection system that shows an app running on the driver's phone on the car display. AppMatic Tech builds AAOS apps as native Kotlin applications and Android Auto apps with the Android for Cars App Library.
- Does an app built for Android Auto work on Android Automotive OS?
- Not automatically. Both platforms support the Android for Cars App Library, which lets one template-based codebase target both, but media apps on AAOS are built as native media services, and AAOS apps need their own manifest declarations, testing on an automotive emulator or head unit, and a separate Google Play review track.
- What is driver distraction review for in-car apps?
- Driver distraction review checks that an in-car app limits interaction while the vehicle is moving. Reviewers look for large touch targets, short text, limited list depth, and no video or free-form keyboard input in motion. AppMatic Tech designs for glanceable hierarchy from the first wireframe, because redesigning after rejection costs more than building to the guideline.
- Can any app type run on Android Automotive OS or CarPlay?
- No. Both platforms restrict in-car apps to approved categories. Android for Cars supports media, navigation, point of interest, and similar template categories, and Apple CarPlay requires an entitlement for categories such as audio, navigation, EV charging, and parking. A general-purpose app cannot be placed on the car screen.
- How long does it take to build an Android Automotive OS app?
- AppMatic Tech delivered an AAOS infotainment app for an Indian FM and music streaming platform with 100M+ potential users in two months, after taking over an inherited codebase with UI rendering, API, and playback problems. A new media app with an existing mobile API typically needs a similar window, while apps needing vehicle hardware integration take longer.