Google describes AAOS SDV as the Android Automotive Operating System for Software Defined Vehicle built on market-proven platforms and enhanced with virtualization technologies. The platform aims to maintain explicit sharing and default isolation by running multiple logical domains in parallel, rather than consolidating all functions into a single domain. AAOS SDV evolved from Microdroid, a privacy-optimized Android variant for lightweight virtual machines, giving engineers access to established security features while enabling domain isolation tailored to automotive use cases.
SECURE DELIVERY AND CODE INTEGRITY
AAOS SDV enforces code integrity through two installation methods: signing verification on boot for read-only system partitions and package-based updates via APEX, where code and dependencies are treated as separate partitions with mandatory signature checks. The system uses a read-only loopback mechanism to mount apex_payload.img and does not expose write paths to modify APEX at runtime. It also employs per-block verification to detect tampering and halts execution on hash mismatches, reinforcing a deny-by-default approach to software execution. TechStaged has also covered Defining Decentralization: An Ontological Perspective Arrives on arXiv.
- Read-only system partition installation with signature validation on boot
- APEX-based services treated as separate partitions with mandatory signing
- Block-level integrity checks using per-block verification to prevent tampering
- Atomic recovery via Active/Backup APEX design to roll back to a safe state if updates fail
MEMORY SAFETY AND DEVELOPMENT PRACTICES
To prioritize resilience, AAOS SDV limits development to the native framework and adopts memory-safe languages for new components. Google states Rust is used as the primary language for new components and service logic, leveraging its memory-safety guarantees to reduce common vulnerabilities while supporting development throughput.
DISTRIBUTED TRUST AND DOMAIN ISOLATION
AAOS SDV uses virtualization to run multiple isolated domains, with explicit segmentation between system clusters (for example, a cluster and an infotainment subsystem) to meet their distinct requirements. The platform relies on hardware-backed identity and integrity checks to ensure only trusted code and configurations operate within each domain.
- Multiple VM instances run in parallel with explicit sharing controls
- Isolated domains with deny-by-default access policies
- Hardware-rooted verification for software state
MESH PROVISIONING, DICE, AND CONTINUOUS TRUST
The platform introduces a mesh provisioning architecture that cryptographically verifies the version and author of every communication endpoint. It binds the network identity of components to their exact binary state, replacing implicit trust with hardware-backed verification. DICE-based authentication and attestation link the Component Device Identifier (CDI) with the device’s boot state and software configuration, enabling zero-trust style verification across the vehicle network.
- DICE-based authentication and attestation
- Compound Device Identifier derived from layered measurements (including UDS and ROM code)
- TLS-enabled secure handshakes for verified network identity
SECURE SOFTWARE DELIVERY LIFECYCLE AND VULNERABILITY MANAGEMENT
AAOS SDV integrates Android’s vulnerability management lifecycle to identify, triage, remediate, and disclose findings. The process includes continuous automated scanning, annual deep-dive penetration testing, and partner-driven intelligence via the Android security vulnerability reporting process. Updates and disclosures are coordinated through Android Security Bulletins and periodic platform audits.
- Continuous automated scanning
- Annual deep-dive penetration testing
- Android Security Bulletins and architectural reviews
WHAT THIS MEANS FOR OEMS AND UPDATES
The security model allows dynamic vehicle updates without compromising core access controls. OEMs balance security with updatability through service-level and VM-level permissions, enabling safe updates for non-security-sensitive components while hard-coding higher-risk permissions for sensitive signals across VMs. Detailed technical specifications and implementation notes are available on the AAOS SDV Overview page.
- Service-level vs VM-level permissions for updates
- Dynamic updates with strict access controls
- Availability of official specifications for implementation
RELATED COVERAGE
- Defining Decentralization: An Ontological Perspective Arrives on arXiv
- GitHub adds Trends tab to organization Code Quality dashboard to track code health over time
- Cloudflare rolls out task-based OAuth consent with optional scopes
- Cloudflare revisits remote Spectre attacks on Workers, reports mitigated risk after production assessment
- Software articles
SOURCES
- Android Developers Blog: AAOS SDV - Secure by Design Published · Primary source
