Infotainment, HMI & AAOS
A practical engineering model for integrating applications into Android Automotive OS, connecting vehicle-facing behavior through Car APIs and Vehicle HAL, and separating application logic from cockpit presentation.
Engineering model
AAOS application integration is the coordination of application behavior, platform services, vehicle-facing interfaces, and user-interface technology inside an infotainment system. An application may consume Car APIs, depend on Vehicle HAL data through the AAOS platform, or operate as a system app when deeper platform integration is required. The main engineering challenge is keeping these boundaries explicit so that state, availability, lifecycle behavior, and presentation can be tested independently.
Core concepts
AAOS provides the runtime and platform context in which an application operates. Defining what belongs in the application, what belongs in platform integration, and what belongs in the interface prevents vehicle-specific behavior from spreading through the whole design.
Car APIs provide the application-facing model for vehicle functions, while Vehicle HAL connects those vehicle properties to the surrounding vehicle networks and services. The distinction matters because application behavior depends on both API semantics and the availability of the underlying property.
A normal application and a system app have different integration responsibilities. Choosing the least privileged boundary that satisfies the function reduces coupling to AOSP implementation details and makes behavior easier to test.
Qt and QML provide an alternative presentation stack for graphical and embedded applications. Keeping presentation state separate from vehicle-facing state allows the same behavior to be reasoned about without tying it to a particular cockpit interface.
AAOS applications operate alongside Android Auto and Apple CarPlay. Integration must define which experience owns a display or function at a given time and how the application behaves when another experience is active.
Start by identifying which behavior is application logic, which behavior is supplied by AAOS, and which behavior depends on vehicle-facing services.
An AAOS application should have a clear boundary around its user-facing behavior and its use of Car APIs. Vehicle-specific data should enter through a defined interface rather than being interpreted independently in every screen or feature. If the application requires behavior unavailable through its normal interface, evaluate whether a system app or an AOSP-level change is actually necessary instead of assuming that deeper integration is the default.
Reason from the application request or observation back through Car APIs and Vehicle HAL rather than treating a missing value as an application-only defect.
State what the application needs to observe or change, including the expected value, update behavior, and behavior when the value is unavailable.
Confirm that the application is using the intended Car APIs and that its state model distinguishes a valid value from an unavailable or not-yet-updated value.
Determine whether the corresponding vehicle property is supplied through Vehicle HAL and whether the integration exposes the required updates to AAOS.
Exercise changes in a controlled sequence and compare application state, Car APIs behavior, and Vehicle HAL updates instead of checking only the final screen.
Use the first boundary where expected behavior diverges to separate application logic, platform integration, and vehicle-facing availability concerns.
| Layer | Primary responsibility | Useful diagnostic question |
|---|---|---|
| Application | Interpret data and present behavior | Did the application model the value and unavailable states correctly? |
| Car APIs | Expose vehicle-facing behavior to the application | Does the application-facing interface report the expected state and updates? |
| Vehicle HAL | Connect AAOS vehicle properties to vehicle networks and services | Is the required property present and changing as expected? |
| User interface | Render current application state | Does the interface reflect state transitions without becoming the source of truth? |
The implementation language and presentation framework should follow the boundary being integrated, not obscure it.
Kotlin is suited to AAOS application code, while C++ is relevant where systems or embedded application behavior requires it. Qt and QML provide a separate route for graphical and embedded interfaces. The important design decision is not merely the language: it is whether vehicle-facing state, application state, and rendered state remain distinguishable when the interface changes.
Deeper platform integration can solve real requirements, but it also increases coupling and expands the surface that must be tested.
AOSP is the platform codebase used as a basis for device systems. When an application must operate as a system app or requires platform behavior beyond ordinary Car APIs, the change should be isolated and documented as a platform dependency. Keep the application-facing contract stable where possible so that application behavior can be tested without requiring every test to exercise the full AOSP integration.
Describe the behavior that cannot be implemented through the existing application boundary or Car APIs.
Identify whether the requirement belongs in the application, a system app, Vehicle HAL, or another AOSP integration point.
Specify inputs, outputs, state transitions, and unavailable behavior at the boundary before changing implementation details.
Test the application with controlled boundary behavior and test the platform integration against expected vehicle-facing transitions.
Projection experiences add another integration condition: the application may not always own the visible cockpit experience.
Android Auto and Apple CarPlay should be treated as separate experiences that can affect which interface is visible or active. The application should define its behavior when focus changes, when its interface is not visible, and when vehicle-facing state continues to change while another experience is active. These cases belong in the application state model rather than being handled only as screen-level events.
| Condition | Application concern | Expected engineering treatment |
|---|---|---|
| Application visible | Current state is presented to the user | Render the latest valid state and make unavailable state explicit. |
| Android Auto active | The application may not own the visible experience | Keep internal state coherent and avoid assuming that visibility means continued user interaction. |
| Apple CarPlay active | The application may coexist with a different visible experience | Define behavior for loss of visibility and restoration without resetting unrelated state. |
| Vehicle value unavailable | The application cannot rely on a current vehicle value | Represent unavailability directly and avoid presenting an inferred value as current. |
Testing should prove behavior at each boundary, not only confirm that an application launches or a screen appears.
Exercise valid, changing, and unavailable values without depending on a complete vehicle integration.
Verify that application requests and observations use the intended Car APIs behavior and preserve the distinction between current and unavailable state.
Exercise the vehicle-facing property path and compare updates with the application-facing result.
Repeat the same state cases when the application becomes visible, loses visibility, and resumes alongside Android Auto or Apple CarPlay.
Confirm that Qt and QML or the chosen AAOS interface renders transitions consistently without owning vehicle-data interpretation.
Record the first layer that diverges from the expected sequence; avoid changing presentation code when the mismatch originates in Vehicle HAL or Car APIs.
A compact review can expose architectural gaps before they become difficult to diagnose in the full cockpit system.
| Review area | Evidence to inspect | Failure signal |
|---|---|---|
| Boundary definition | A stated path between application, Car APIs, and Vehicle HAL | The same vehicle behavior is implemented in multiple layers. |
| State model | Defined valid, changing, and unavailable states | The interface displays a default value as if it were current. |
| Platform dependency | A documented reason for AOSP or system app integration | Platform access is used without a specific missing capability. |
| Presentation separation | UI code consumes application state through a defined boundary | QML or another interface directly determines vehicle-data validity. |
| Coexistence behavior | Cases for Android Auto and Apple CarPlay are exercised | Visibility changes reset or corrupt unrelated application state. |
| Diagnostic sequence | Expected transitions are recorded across layers | Debugging starts with screen changes before checking the first failing boundary. |
Engineering pitfalls
Vehicle HAL connects AAOS vehicle properties to vehicle networks and services; it is not automatically the complete application-facing contract. The application should reason through Car APIs and verify how the property is exposed.
A default can look like a valid vehicle value. Model unavailability explicitly so the interface does not present an assumption as current state.
When QML or another presentation layer owns vehicle-data interpretation, state becomes duplicated and difficult to test. Keep interpretation in application logic and let the interface render it.
A system app changes the integration boundary but does not define the required behavior. First identify the missing capability and its observable contract.
A correct final screen can hide missed updates, incorrect lifecycle handling, or a broken Vehicle HAL path. Test transitions across the application, Car APIs, and Vehicle HAL boundaries.
Android Auto and Apple CarPlay can change which experience is visible. Applications need explicit behavior for visibility changes and restoration rather than assuming continuous ownership of the cockpit.
FAQ
Engineering support
Need a focused AAOS integration review, implementation plan, or debugging workflow? An independent automotive software engineer can help structure the application, Car APIs, Vehicle HAL, and UI boundaries around the behavior your team needs to test.