Android Automotive beyond infotainment

For many engineers, AAOS still means in-vehicle infotainment (IVI): applications on a centre display, media playback, navigation, settings and a controlled path into selected vehicle properties. That description is already incomplete.

Google's public AAOS SDV architecture introduces a lightweight Android foundation for additional compute domains, service-oriented communication across processes and virtual machines, service bundles packaged into independently updatable units, granular updates and a new approach to safety-related displays. The public Android Open Source Project (AOSP) baseline starts with Android 17, associated with the second quarter of 2026 and identified as 26Q2.

The platform is still evolving. This article describes the public architecture documented in September 2026 and focuses on its engineering implications, not on a single production vehicle implementation.

This is not simply a larger infotainment stack. It changes the unit of architecture. The centre of the system moves from screens and applications towards contracts, services and deployable capabilities.

The car is not becoming one large Android device

The phrase "Android beyond infotainment" can easily create the wrong mental model. It does not imply one Android instance controlling every function in a vehicle. Modern vehicle architectures contain several compute domains, electronic control units (ECUs), different safety requirements and components with very different timing characteristics.

The public AAOS SDV architecture reflects that reality. The current architecture documentation focuses on isolated virtual machines running on a VirtIO-capable hypervisor. Google's platform announcement also describes bare-metal deployment for workloads that require lower latency. The SDV Core profile is a lightweight, headless Android foundation intended for automotive services rather than a conventional application environment.

That distinction matters. Reusing Android does not remove architectural boundaries. It gives teams a common platform, lifecycle model and toolchain while preserving separation between domains. Core compute, body controls, cockpit graphics and infotainment do not suddenly become the same workload just because Android participates in each of them.

For an Android engineer, the familiar parts remain useful: Binder, Android Interface Definition Language (AIDL), system services, permissions, process isolation, Android Pony EXpress (APEX) packaging, observability and the Android build system. The unfamiliar part is the wider distributed system around them.

The public service model uses the Vehicle Services Interface Definition Language (VSIDL) and Protocol Buffers (Protobuf) to define contracts. It supports remote procedure call (RPC) channels and publish and subscribe topics. Transport options include Binder, VirtIO sockets (vsock), Ethernet, gRPC Remote Procedure Calls (gRPC), Fast Message Queue (FMQ) and Scalable service-Oriented MiddlewarE over Internet Protocol (SOME/IP).

Contracts become more important than location

Traditional Android architecture often assumes that the most important boundaries are inside one application or one device. We separate user interface (UI), domain logic and data access. We define repository interfaces. We decide whether work belongs in an app process, another process or a system service.

A software-defined vehicle adds another dimension: the component providing a capability may move between processes, virtual machines or physical controllers during the lifetime of a platform. An interface that accidentally depends on location becomes expensive to evolve.

AAOS SDV addresses this with a service-oriented and data-centric architecture. VSIDL describes service bundles and their communication. Protobuf describes the data exchanged through those contracts.

The communication model exposes two primary patterns. Topics support publish and subscribe flows for changing vehicle state. Channels support remote procedure calls where the caller needs a specific action or response. A subscriber cares about the topic and message type, not the location of a particular publisher. A client invokes a service through a named channel without embedding the location of the server into its business logic.

Code generation is the visible convenience, but abstracting topology is the more consequential change. The same logical contract can be carried through different transports without making its location part of the business logic. External ECUs can participate through SOME/IP integration.

The intended architectural reward is portability. A service can move as compute architecture changes, provided its contract and operational assumptions remain valid. The cost is that interfaces must be designed with much more discipline.

A service contract is a long-term product decision

In a mobile application, an internal interface can often change together with its callers in one release. In a vehicle, services may be produced by different teams, suppliers and release trains. Different versions can coexist across virtual machines. Updating every participant at exactly the same moment may be impossible.

This makes compatibility part of feature design. Renaming a service bundle, removing a publisher or changing a message type is not a local refactor. It can break a deployed system whose components no longer advance in lockstep.

Good contracts need explicit ownership, stable semantics and a versioning strategy before they become widely consumed. Adding optional data is usually easier than changing the meaning of existing data. A new service version is sometimes safer than forcing an incompatible interpretation onto an old contract.

The most important question is not whether a schema compiles. It is whether old and new participants can continue to understand one another during rollout, rollback and recovery.

Deployment boundaries are architecture boundaries

AAOS SDV groups related business logic into service bundles. At runtime, a service bundle maps to a Linux process. It is also an authorization boundary: permissions to publish, subscribe, serve or call are granted to the bundle.

An SDV package is an APEX file that contains one or more service bundles from the same source of trust. It is the smallest independently updatable unit in this model.

This makes packaging an architectural decision. Put too much into one package and unrelated capabilities must be tested, released and rolled back together. Split the system too aggressively and operational complexity grows through more contracts, more dependencies and more failure modes.

The right boundary should reflect several things at once:

• business capability and ownership;
• security and authorization requirements;
• lifecycle and power mode;
• failure isolation;
• release cadence;
• resource and latency constraints;
• the need to update or roll back independently.

Android developers already make similar choices when deciding between modules, processes, services and applications. In an SDV architecture, the consequences last longer and span more organisations.

Granular updates do not make compatibility easier

One of the strongest promises of a software-defined vehicle is the ability to improve capabilities without replacing a complete system image. AAOS SDV supports both system updates and service bundle updates. The Update Manager writes an update to disk during preparation without making it active, activates the prepared update for the next reboot and then supports commit or rollback paths. System updates use an inactive partition slot, while service bundle updates stage APEX files in temporary sessions.

Granularity reduces the scope of an update, but it increases the number of valid system combinations. A single vehicle may temporarily contain old and new service versions at the same time. A rollout may stop halfway. A virtual machine may reboot while another remains available. A new package may need to be rolled back after other components have observed its data.

Testing only the desired final state is therefore insufficient. Teams need to test transitions:

• old client with new service;
• new client with old service;
• update prepared but not activated;
• activation followed by rollback;
• one compute domain temporarily unavailable;
• data produced before and after a schema change;
• power loss during an update window.

This is distributed systems work with automotive consequences. The update mechanism is only one part of the solution. Compatibility, observability and recovery behaviour must be designed into each service.

Partial failure should be the normal design assumption

Application code often treats a remote dependency failure as an exceptional state. In a vehicle spread across processes, virtual machines and controllers, temporary unavailability is normal. A service may be starting, suspended, updating, recovering or absent in a particular vehicle configuration.

A robust consumer needs to know what stale data means, how long cached state remains useful, which operations are safe to retry and when degraded behaviour is preferable to waiting. Timeouts cannot be arbitrary. A retry storm that is merely annoying in a phone application can become a system-wide resource problem in a constrained vehicle environment.

Health monitoring should answer operational questions rather than simply report that a process exists. Is the service ready? Is its data current? Can it satisfy this operation in the present vehicle mode? Are dependencies healthy? Can the system distinguish a slow response from a broken contract?

The most useful mental shift is simple: design every service with the expectation that another part of the vehicle will sometimes be unavailable.

Isolation is not an implementation detail

AAOS has always needed strong boundaries around vehicle access. In the conventional infotainment architecture, applications use well-defined application programming interfaces (APIs) in the Car API surface, Car Service mediates access and the Vehicle Hardware Abstraction Layer (VHAL) provides the controlled connection to vehicle networks and hardware. Permissions and Security-Enhanced Linux (SELinux) policy restrict who can reach those paths.

The SDV architecture expands the surface, but it does not remove the need for mediation. Service bundles carry explicit authorization policies. Virtual machines create explicit isolation boundaries between classes of workload. Code and packages have a defined source of trust. External vehicle communication still needs carefully controlled gateways.

For engineers, this means the security model belongs in the initial service design. The questions are concrete:

• Who is allowed to publish this state?
• Who may invoke this operation?
• What validation occurs at the boundary?
• Can a compromised consumer flood a vehicle network?
• What data is safe to record for diagnostics?
• Which capability must remain available during degraded operation?

A flexible communication layer is valuable only when identity, authorization and rate control travel with it.

Safety changes how display architecture is discussed

Moving Android into more of the cockpit raises an immediate question: how can rich Android graphics coexist with information that must remain visible and correct?

The public Display Safety architecture separates responsibilities. DriverUI renders the interactive cluster experience. A high availability renderer provides elements that must appear quickly after boot and can supply placeholders when Android is unavailable. A safety monitor continuously compares required visual information with what is present in the rendered output.

This is a useful pattern beyond its specific implementation. Safety is not achieved by declaring one large UI process to be reliable. It is achieved through separation, independent monitoring, constrained responsibilities and a defined degraded mode.

Google provides a reference implementation and toolchain, but the reference safety monitor is not certified to an Automotive Safety Integrity Level (ASIL). The documentation is explicit that original equipment manufacturers (OEMs) must adapt the implementation to their requirements and obtain the relevant certification. Android engineers entering this area need to work closely with functional safety, hardware and systems teams. Application-level correctness is necessary, but it is not the whole assurance case.

What remains recognisably Android

Despite the larger scope, much of the engineering discipline is familiar. AIDL contracts, Binder behaviour, process lifecycle, SELinux, permissions, APEX packaging, tracing, logs and system service design remain relevant. Experience diagnosing startup ordering, memory pressure and asynchronous state is directly useful.

What changes is the scale of the context. An Android engineer may need to understand hypervisor boundaries, vehicle power modes, SOME/IP, Protobuf compatibility, service discovery, health monitoring and update orchestration. The documented service development flow also places Rust in the implementation path for custom business logic.

The job moves closer to platform engineering. UI expertise still matters, especially in IVI and cluster experiences, but the differentiating skills increasingly include contract design, failure modelling and operational thinking.

What Android engineers should learn next

The transition does not require every Android developer to become an automotive systems engineer overnight. It does suggest a practical learning path:

1. Understand the existing AAOS stack. Learn how applications, Car API, Car Service and VHAL divide responsibility.
2. Design contracts before implementations. Practice Protobuf schema evolution, explicit semantics and compatibility review.
3. Learn both communication models. Use publish and subscribe for evolving state, and RPC when a caller needs an action and result.
4. Model partial failure. Define readiness, stale data, retry policy, timeouts and degraded behaviour.
5. Treat deployment as part of architecture. Understand APEX, process boundaries, authorization and rollback.
6. Test across topology. Run services in separate processes and virtual machines, then introduce delay, restart and version mismatch.
7. Learn the vehicle lifecycle. Boot, suspend, shutdown and power state are product behaviour, not infrastructure trivia.
8. Work with safety and security specialists early. These constraints cannot be added after the service model is complete.

A small experimental service can make these concerns concrete. Define one state topic, one command channel and two independently versioned consumers. Run them across a boundary, change the schema and observe how quickly apparently simple assumptions become system contracts.

The opportunity and the limit

AAOS SDV has the potential to reduce fragmentation across vehicle compute platforms and make automotive services easier to develop, deploy and update. A common open platform could also improve tooling and make software behaviour more consistent across hardware generations.

It does not eliminate vehicle complexity. It reorganises it. Service boundaries, compatibility rules, authorization, update policy and failure behaviour become visible architectural products that teams must own.

In my view, the strongest implementations will not be the ones that place Android in the greatest number of controllers. They will be the ones that use common platform capabilities without erasing the boundaries required by latency, safety, security and hardware responsibility.

For Android engineers, that is the real significance of moving beyond infotainment. The platform is expanding, but so is the definition of good Android engineering.