AAOS SDV in 2026: one permission class costs a mesh-wide VM update

Summary. On 24 August 2026 Google published the security design behind Android Automotive OS for Software Defined Vehicle (AAOS SDV), written by Markus Vill, Sean Keys and Istvan Nador of Android Auto. The post names a cost most OEMs will only meet after they have shipped: "permissions for security-sensitive signals must be hard-coded into every VM," and "introducing a security-sensitive service to a new VM requires updating the VM-level permissions system-wide. This necessitates an update to all VMs within the mesh." The AOSP deployment documentation for the same feature describes a .default.textproto fallback introduced, in its own words, so that "if a new VM appears after a vehicle update, a reasonable default.textproto might be sufficient to avoid updating all VMs." Those two statements are not the same claim. AAOS 26Q2 is API level 37 and shipped 8 new features against 180 fixed issues, and from 2026 AOSP source lands publicly only in Q2 and Q4, so an OEM that gets the permission split wrong waits roughly 6 months for the next public drop.

What Google published, and what the docs add

The blog covers the security architecture rather than the feature list: virtualization for domain isolation, Microdroid lineage, UID-based process isolation with SELinux deny-by-default, APEX packaging with per-block dm-verity over 4 KB blocks, DICE-derived identity for VM-to-VM TLS, and Rust as the primary language for new components. All of that is uncontroversial and matches the AAOS SDV architecture page, which describes SDV as a headless Android instance running on a VirtIO-capable hypervisor, testable in Cuttlefish.

The part worth reading twice sits near the end, under layered access control. AAOS SDV enforces two policy layers, and both must pass. Service-level permissions declare what a service bundle can publish, subscribe to, serve or call. VM-level permissions declare what any service on a given VM may do across the mesh. The VM-level authorization policy page is explicit: "You must grant both service-level and VM-level permissions to permit cross-VM communication," and by default all cross-VM communication is denied.

The conflict: what a new VM actually costs

Read together, the blog and the deployment page give two different answers to the same operational question.

Both can be true at once, and that is the trap. The .default.textproto escape hatch works only if the default policy already permits the new signal. For a security-sensitive signal, the default policy is exactly the file an OEM will have written to deny it. So the fallback saves you on non-sensitive services and does nothing on the sensitive ones, which is the case the blog is describing. The docs page frames the default as an updatability win. The blog frames the same design as a fleet cost. A programme plan built on the docs sentence alone will underestimate the work.

The precedence order is not "deny wins"

The blog says nothing about evaluation order. The VM-level policy page documents six ranked steps before the implicit default, and the ranking is by granularity first, not by verdict:

AOSP's own worked example uses door unlock. A policy that denies com.sdv.security.UnlockDoors on every topic, then allows it on driver_door, permits the driver door publication. The type-wide deny does not survive a narrower allow. Anyone reviewing an OEM policy file with "deny overrides allow" in mind will read that file wrong. The authorization policy schema also carries an allow_read_all boolean that grants discovery and call rights over every RPC server and every publication, with the schema comment warning it "should be used with a good reason and for privileged agents only (e.g. Telemetry)."

"Lightweight" APEX updates still reboot the vehicle

The blog contrasts "lightweight APEX updates" against "full VM redeployments." The service bundle updates page is blunter: "For an update to take effect, you must reboot the device." The Update Manager stages APEX files in temporary sessions and activates them after a system reboot, moving through READY, PREPARE, ACTIVATE and COMMIT. Both update classes end in a reboot. The difference is payload size and validation scope, not driver disruption.

There is a second cost buried in the same page. A brand-new APEX, one with no earlier version on a read-only partition, needs its public signing key pre-installed under /partition/etc/brand_new_apex/, and if it later turns out to be malicious it "must be blocked using a system update" by adding its package name to a per-partition blocklist.json. So the cheap path (a new APEX) has an expensive recovery path (a full A/B system update). SDV uses non-virtual A/B updates, per the A/B system updates page.

Enforcement is per VM, and syncing it is only a recommendation

The enforcement page states that authorization enforcement is applied per VM and controls decisions on the local VM only, then adds that Google recommends syncing enforcement configuration across all VMs in the mesh. A recommendation is not a check. On user builds enforcement cannot be disabled and the controlling properties are ignored. On non-user builds setprop sdv.authz.enable disabled or permissions_only changes behaviour at runtime, which is fine on a bench and dangerous on anything that leaves one.

The practical test for an OEM: if a userdebug image can reach production hardware, the mesh has a VM where authorization can be turned off with one property write while its peers keep enforcing. The identity layer still holds, because DICE binds network identity to the exact firmware measurement, but the policy layer does not.

How to tell if this is you

Three checks, all cheap:

1. Search the build for SDV_VM_LEVEL_PERMISSIONS_MODULE. If it resolves to a single APEX shared across VMs, every security-sensitive addition is a mesh-wide change.

1. List the files inside com.oem.sdv.authz. If there is only .default.textproto and no per-VM <vm_name>.textproto, the deny posture is uniform and the blog's cost applies in full.

1. Grep the service-level policies for allow_read_all: true. Anything outside telemetry is a finding.

India-specific considerations

Indian OEMs and the tier-one suppliers around Pune, Chennai and Gurugram are building AAOS programmes against the same two-release AOSP calendar. The Digital Personal Data Protection Act 2023 treats vehicle telemetry that identifies a driver as personal data, and the allow_read_all flag is precisely the switch that turns a scoped telemetry agent into an unscoped one. Teams shipping into India should keep the telemetry policy file under the same review gate as any other privacy control, and should assume a security-sensitive signal change is a fleet OTA rather than a patch. Our work on Android target API 36 migration and Android 17 API 37 behaviour changes shows the same pattern: the platform date is public, the internal cost is not.

What is still unknown

Google has not published a VM count above which a mesh-wide permission update becomes impractical, nor any guidance on partial mesh updates. The blog does not say whether a VM running an older VM-level policy is quarantined or simply denied. AOSP documents automated quarantine protocols for unauthorized code execution but does not tie them to policy version skew. Until that is written down, treat policy version skew as an outage class of its own and test it in Cuttlefish before hardware.

FAQ

How eCorpIT can help

eCorpIT builds and reviews Android platform and application code for teams shipping into regulated markets, and our senior engineering teams read vendor policy files the way an auditor reads a control matrix. We are CMMI Level 5 and ISO 27001:2022 certified, and we design applications aligned with DPDP requirements. If you are planning an AAOS or AAOS SDV programme and want the permission split reviewed before the build is frozen, book an Android platform review.

References

1. AAOS SDV - Secure by Design, Android Developers Blog, 24 August 2026

1. Software defined vehicle, Android Open Source Project

1. SDV architecture, Android Open Source Project

1. Communications authorization overview, AOSP

1. VM-level authorization policy, AOSP

1. Authorization policy schema, AOSP

1. Authorization policy deployment, AOSP

1. Authorization enforcement, AOSP

1. Service bundle updates, AOSP

1. A/B system updates for SDV, AOSP

1. SDV Update Manager, AOSP

1. Android Automotive 26Q2 release notes, AOSP

1. Get started with the software defined vehicle, AOSP

1. OEM A/B partition updates, AOSP

1. Android Security Bulletins, AOSP

Last updated: 24 August 2026.