What AAOS changes for app developers
Android Automotive OS (AAOS) is Android built into a vehicle, rather than Android Auto projected from a phone. The distinction affects your architecture, permissions, user interface, testing, and distribution strategy. An AAOS app runs on the car’s infotainment hardware, but the available features, screen dimensions, sensors, and vehicle integrations vary by OEM and vehicle model.
The practical goal is not to reproduce a mobile app on a dashboard. It is to deliver a short, glanceable, distraction-aware experience that works reliably with intermittent connectivity and constrained interaction time. Media, navigation, communication, and parked-use cases are the strongest starting points. Vehicle-control features require OEM-specific agreements and privileged access; ordinary third-party apps should not assume they can read or control safety-critical signals.
If your product includes speech, design the interaction as a hands-free system rather than simply adding a microphone button. The architecture principles in this guide to building a voice agent are useful for turn-taking, interruption handling, latency, and fallback behaviour.
Choose the right AAOS app category
Start by mapping the product to Android for Cars app categories and their allowed templates. Google’s car app libraries are designed to enforce interaction patterns that are safer while driving. Common categories include:
- Media: Audio playback, podcasts, music, and spoken-word content.
- Navigation: Routes, destinations, search, and turn-by-turn experiences where supported.
- Communication: Messaging and calling workflows with strong voice and notification constraints.
- Point of interest: Places, charging, parking, food, and other location-led services.
- Weather: Compact, glanceable weather information.
- Video and games: Typically restricted to parked use and subject to platform and OEM requirements.
This classification should happen before implementation. A mobile-first design that does not fit a supported car category may require substantial rework or fail review. For India-focused products, also decide early whether the experience needs multiple scripts, regional place names, low-bandwidth operation, or voice input across Indian languages. A broader discussion of these constraints appears in building AI apps for the next billion users in India.
Set up the development environment
Use a recent stable Android Studio release, the Android SDK, Kotlin, Gradle, and the Android for Cars App Library. Keep the project’s compile and target SDK versions aligned with current platform guidance, then verify behaviour against the minimum versions you intend to support.
A practical setup sequence is:
1. Create a dedicated AAOS project using a supported Android for Cars template rather than adapting every screen from a phone app.
2. Add the car app library and configure the required service, metadata, intent filters, and category declarations.
3. Create an AAOS emulator through Device Manager, choosing an automotive system image and representative screen configuration.
4. Run a physical-device plan for later stages. Emulator testing cannot reproduce every OEM launcher, audio stack, steering-wheel control, connectivity issue, or vehicle policy.
5. Keep a compatibility matrix covering API level, screen size, rotary or touch input, portrait or landscape orientation, network state, and parked versus driving state.
Use Kotlin coroutines, lifecycle-aware components, and a small modular architecture. Keep domain logic independent from Android UI and vehicle-specific adapters so that you can test it without an emulator.
Build around car-safe templates and states
The Android for Cars App Library uses templates such as list, grid, map, pane, message, and navigation patterns. Templates are intentionally restrictive: they reduce cognitive load and prevent developers from placing arbitrary mobile layouts in a driving context. Treat those limits as product requirements, not obstacles.
A robust screen should answer three questions immediately: Where am I? What can I do next? How do I recover if the action fails? Use short labels, clear hierarchy, large touch targets, strong contrast, and predictable back navigation. Avoid dense forms, long reading, rapidly changing animations, and workflows that demand multiple confirmations while moving.
Design separate states for:
- Disconnected: Show cached content or a clear retry action.
- Loading: Avoid indefinite spinners; provide meaningful progress or skeleton states.
- Driving: Reduce actions and suppress non-essential content.
- Parked: Unlock richer browsing only when platform policy allows it.
- Error: Explain the problem in plain language and offer one practical recovery path.
For voice-heavy experiences, keep spoken responses concise and make visual confirmation optional. Do not rely on voice recognition alone in noisy cabins, where accents, road noise, and multilingual switching can affect accuracy. Teams building India-oriented systems should test code-switching and regional pronunciation, informed by work on low-resource Indic natural language processing.
Handle vehicle and platform APIs carefully
AAOS exposes platform APIs, but access to vehicle properties is not uniform. Some vehicle data is protected by permissions, controlled by the OEM, or unavailable to third-party applications. Never design a product around assumed access to speed, fuel, doors, climate controls, or driver identity until the target OEM confirms the integration path.
Separate your application into three layers:
- Presentation: Car templates, lifecycle, accessibility, and interaction rules.
- Application services: Search, playback, routing, account state, caching, and business logic.
- Integration adapters: Media sessions, location providers, network services, OEM APIs, and vehicle signals.
This separation lets you replace a simulator or OEM adapter without changing the user experience. It also limits permissions and makes security review easier. Store the minimum personal data, protect tokens using Android security facilities, validate all network responses, and avoid logging precise location or voice content unnecessarily.
Test beyond the happy path
AAOS testing should include automated Android tests, emulator tests, and scenario-based manual testing. At minimum, cover:
- App launch, resume, rotation, process death, and background restoration.
- Loss of network during search, playback, login, and route calculation.
- Audio focus changes, incoming calls, navigation prompts, and media interruptions.
- Touch, rotary, steering-wheel, and voice interactions where supported.
- Driving restrictions, parked-only features, notifications, and user sign-out.
- Slow startup, low memory, battery impact, and repeated use over long journeys.
Measure task completion time, failed actions, voice latency, crash-free sessions, and network bytes—not only visual correctness. Test with drivers and passengers separately, because a feature that is acceptable when parked may be unsafe when the vehicle is moving. Use the emulator for fast regression and real vehicles for final validation across OEM implementations.
Prepare for Google Play and OEM distribution
AAOS distribution is not identical to publishing a phone application. You need the correct manifest declarations, supported category, quality checks, policy compliance, store assets, and testing track. Availability can depend on vehicle compatibility, geography, OEM decisions, and app category.
Before submission, confirm that:
- The app declares only the permissions and features it actually uses.
- Driving restrictions are enforced by the platform-supported APIs and templates.
- The app handles offline and degraded-network states gracefully.
- Sign-in, payments, messaging, and personal data follow current policy requirements.
- Store listings explain supported vehicles and any parked-only limitations.
- Crash, ANR, performance, accessibility, and security testing is complete.
Plan OEM conversations early if the product needs privileged vehicle data or controls. A commercially viable AAOS launch may require an OEM partnership, a fleet pilot, or a bundled distribution arrangement rather than an open consumer Play Store release.
A practical build roadmap
A focused first release can follow this sequence:
1. Validate the use case against an approved AAOS category.
2. Prototype the primary journey with car templates and sample data.
3. Add authentication, caching, analytics, and network failure handling.
4. Integrate media, location, voice, or OEM services behind adapters.
5. Test driving and parked states in the emulator and representative vehicles.
6. Run a limited fleet or partner pilot, then address crashes and interaction failures.
7. Submit the production build with accurate compatibility and policy information.
For more complex products, keep the backend observable and resilient. If several services or intelligent components coordinate requests, the design principles in building distributed systems with AI agents can help with timeouts, retries, idempotency, and failure isolation—provided the in-car client remains simple.
FAQ
Can an Android phone app run directly on AAOS? Not automatically. It must support the relevant car category, templates, lifecycle, and distribution requirements. Some phone apps may be compatible, but compatibility is not the same as a good in-car experience.
Do I need a physical vehicle? No for initial development. The AAOS emulator is essential for fast iteration, but physical vehicles are necessary for OEM-specific behaviour, audio, connectivity, and final usability validation.
Can third-party apps control vehicle functions? Usually not by default. Vehicle properties and controls are protected and commonly require OEM approval, special permissions, or system-level integration.
Should I build for Android Auto or AAOS first? Choose based on distribution and product needs. Android Auto reaches compatible phones and vehicles through projection; AAOS runs natively in supported vehicles and offers a different integration model.