Android Auto Integration Development
Android Auto allows you to output the application interface to the multimedia system screen of a car through USB or wireless connection. Architecturally, this is host-side rendering: the car requests templates through the Car App Library, the application forms them—but the host renders them, not the application itself.
Car App Library — The Only Right Path
The old method through CarActivity and custom UI is deprecated. From Android Auto 6.0+, Google requires using androidx.car.app:app (Car App Library). These are declarative templates similar to CarPlay: ListTemplate, GridTemplate, NavigationTemplate, MapWithContentTemplate.
An important nuance: Car App Library has several API levels (CarAppApiLevel). Templates added at level 5 are unavailable on cars with older hosts. Check CarContext.getCarAppApiLevel() and degrade the interface for older hosts.
Application categories are: navigation, POI (parking, charging, gas stations), IoT (smart home control), weather, video calling. Since 2024, food was added like Apple's approach. A regular application without the allowed category in AndroidManifest.xml → <category android:name="androidx.car.app.category.NAVIGATION"/> — Auto simply won't launch it.
Common Integration Mistakes
Main thread blocking in Session.onCreateScreen(). Session is the entry point for Auto applications. onCreateScreen() must return the initial Screen immediately. If you make a network request here, Auto shows an empty screen with a timeout. Correct approach: return LoadingTemplate or an empty ListTemplate, then asynchronously load data and call invalidate().
MapTemplate and Surface rendering. For navigation applications, render the map on SurfaceContainer through SurfaceCallback. This is fundamentally different from a regular View: draw on Canvas through SurfaceContainer.getSurface(), update only when data changes. No onDraw() loop—only explicit lockCanvas() → draw → unlockCanvasAndPost(). Common mistake: drawing on every onStableAreaChanged() even if the map hasn't changed—this appears as flickering on some hosts.
Testing without a car. Desktop Head Unit (DHU) is Google's official simulator. Launched through android-sdk/extras/google/auto/desktop-head-unit. DHU with the --phone parameter emulates phone mode (USB), --car emulates wireless. Final testing in a real car is mandatory—SurfaceCallback behavior and touch gestures on the car screen are only reproduced there.
Architecture
CarAppService
└── Session (lifecycle: Car connected)
└── Screen stack (push/pop)
├── HomeScreen → ListTemplate
├── DetailScreen → DetailTemplate
└── NavigationScreen → NavigationTemplate + SurfaceCallback
Screen is analogous to Fragment. invalidate() redraws onGetTemplate(), the system requests the updated template. You cannot update templates faster than the host allows—there is rate limiting. If invalidate() is called too frequently, Auto ignores intermediate calls.
Integration with the main application is through a shared business logic layer (Repository, UseCases). The Auto Session subscribes to the same Flow/LiveData as the mobile UI.
Timeline
POI or audio integration: 4–7 weeks. Navigation application with a map and Surface rendering: 8–14 weeks. Cost depends on the complexity of navigation logic and whether a map already exists in the mobile application.