Automotive Grade Linux & In-Vehicle Infotainment¶

Last updated: 2026-05-14

Recent Finds¶

AGL Releases SoDeV "Ultimate Unagi" — First Production SoC-Capable UCB Release, 5 New Members (AGL / Linux Foundation, May 14, 2026)¶

Automotive Grade Linux made the SoDeV reference platform generally available today (May 14, 2026) via the latest AGL Unified Code Base release codenamed "Ultimate Unagi" — the first UCB release to ship SoDeV as an integrated package runnable on real automotive hardware. The stack combines the AGL UCB, Linux containers, VirtIO, Xen hypervisor, Zephyr RTOS, and ELISA safety artifacts in a single pre-integrated downloadable package. Hardware support at launch: Renesas Sparrow Hawk reference boards, cloud-based processor environments, and virtual machines — with broader automotive SoC support planned through 2026. Support policy: Ultimate Unagi will receive updates for two years, synchronized ~3 weeks after each Yocto Scarthgap release. New members joining at launch: EMQ, Lineo Solutions, MediaTek, VA Linux Systems Japan, and Very Good Ventures — notably MediaTek, which is the first major SoC vendor joining since the SoDeV announcement, signaling hardware partner engagement expanding beyond the Renesas anchor. Governance note: AGL SoDeV remains under Linux Foundation neutral governance — architecturally equivalent to AAOS SDV (Xen hypervisor, VirtIO, Zephyr for safety-critical domains, Linux for IVI) but with foundation governance instead of Google roadmap control. The Berlin All Member Meeting (Sept. 30–Oct. 1, 2026) CFP is now open, with proposals due by July 12. Why this matters for the AAOS vs. AGL competitive thread: Ultimate Unagi is the first AGL release that matches the AAOS SDV February/April announcements with a concrete, developer-usable artifact — not just an architectural blueprint. With Renesas hardware + MediaTek joining, AGL SoDeV has its first credible OEM-tier SoC vendor pair. The strategic question (AAOS SDV governance vs. AGL neutral governance) now has a concrete product artifact on both sides for OEM evaluation teams to compare.

AAOS 25Q2 Feature Deep-Dive: Minimal Telephony, HD Radio EAS, Scalable UI (Android AOSP, April 10, 2026)¶

The Android Automotive 25Q2 release (source.android.com, updated April 10, 2026) adds several features beyond the vehicle-property promotions already documented. Key additions: (1) Minimal Telephony HAL subset — a reduced HAL allowing OEMs to implement Android telephony on data-only TCU (Telematics Control Unit) devices that lack voice hardware, reducing fragmentation across vehicles with different connectivity configurations. (2) HD Radio Emergency Alert System (EAS) support — new API passes EAS information from the HD Radio tuner to radio applications, enabling emergency alert display on in-vehicle screens without a separate alert module. (3) Scalable UI framework — configurable windowing components so OEMs can implement custom window management meeting their UX requirements without forking AAOS window manager; directly addresses the OEM complaint that AAOS previously forced one windowing model across different cluster/IVI topologies. (4) Dynamic vehicle property configuration — minimum, maximum, and supported values are now runtime-configurable rather than compile-time constants, enabling trim-level and market variants to share the same binary with runtime adaptation. (5) Subscription Management APIs — expose mobile data subscription status (active/inactive/trial) and expiration dates to in-car connectivity UX. (6) Third-party access to eight vehicle properties (navigation, voice assistant, weather, driving state) — previously SystemApi-only, now public API, allowing non-OEM apps to integrate with real vehicle state without a separate HAL partnership. Strategic significance: the Minimal Telephony HAL is the most impactful for SDV architectures — it acknowledges that not all vehicle modules need the full telephony stack, allowing leaner Android deployments on zonal gateways and TCUs. The Scalable UI addition directly addresses the OEM fragmentation complaint and reduces the incentive for OEMs to maintain out-of-tree window manager forks. AOSP source publication model (Q2/Q4 per year) is confirmed; use android-latest-release branch.

Renault Trafic E-Tech CV Show Post-Show Summary — V2L/V2G, openR Evo, 800V Technical Details (April 21–23, 2026)¶

The CV Show (April 21–23, NEC Birmingham) confirmed the full production-ready specification of the Renault Trafic E-Tech. Key technical details now confirmed: 800V fast-charging system enables 15%–80% charge in approximately 20 minutes, recovering up to 260 km of range — a commercial vehicle charging speed competitive with passenger EVs. V2L/V2G capability confirmed (bidirectional power for tools and grid). The AAOS SDV integration is confirmed to be surfaced through openR evo with Google built-in, with 90% of vehicle functions OTA-updateable — production start: Sandouville plant (France), late 2026. The software stack explicitly routes height, load, and road restriction data into navigation — demonstrating that the SDV service layer has access to real-time vehicle telemetry (weight sensors, suspension data) beyond the infotainment domain. Significance for AAOS SDV evaluation: the Trafic E-Tech is now confirmed as a production-grade deployment of the full AAOS SDV stack on a commercial vehicle with body control and energy management domains — not just an IVI deployment. It is the most concrete proof point that AAOS SDV's service-oriented architecture works end-to-end on a production platform. No technical integration blueprint for AAOS SDV + AUTOSAR Classic coexistence has been published post-show.

Renault Trafic E-Tech CV Show Debut Confirmed — April 21–23, NEC Birmingham (CV Show / WhichEV, April 2026)¶

CV Show 2026 (April 21–23, NEC Birmingham) is now open and Renault's Trafic E-Tech is making its UK debut on stand 5F84 in Hall 5. New technical details confirmed at the show: Vehicle-to-Load (V2L) and Vehicle-to-Grid (V2G) bidirectional power capability confirmed (not previously confirmed from the initial announcement), alongside the 800V fast-charging architecture. The OpenR multimedia system runs on a 12-inch screen with commercial vehicle-specific navigation — confirming the AAOS SDV stack is surfaced through Renault's own UX layer, not a raw Android AOSP experience. Orders expected to open "later in 2026." The V2L/V2G confirmation is significant for fleet electrification economics: a van that can discharge to power tools on a job site, or provide grid services during downtime, changes the total cost of ownership calculation entirely and is a software-layer differentiator only possible on an SDV with OTA-updateable power management.

Renault Trafic E-Tech Electric UK Debut and Production Confirmation (Automotive World, April 2026)¶

The Renault Trafic E-Tech Electric made its UK public debut at the CV Show (Birmingham, April 2026), confirming production readiness with full technical specs: 800V fast-charging architecture, up to 450 km WLTP range (pending homologation), built on Ampere's (Renault Group's EV division) dedicated skateboard platform. The Trafic E-Tech is the first SDV commercial vehicle built on AAOS SDV — Renault describes 90% of functions as OTA-updateable, with Google's openR evo software embedded. Sandouville plant (France) will produce it with orders opening later in 2026. This is the most concrete near-term validation of AAOS SDV in production: not a passenger car concept, but a production commercial van at a major European OEM scheduled for delivery within 2026. The technical significance: it proves that AAOS SDV's service-oriented architecture can run on a commercial vehicle's domain consolidation topology — seat actuators, climate, lighting, telemetry, OTA — not just an infotainment screen. The remaining question is whether Renault publishes its AAOS SDV + AUTOSAR Classic coexistence architecture blueprint, which would be the first OEM-level technical documentation of this integration.

AGL SoDeV Reference Platform Reaches Automotive SoC Hardware Availability (AGL / Linux Foundation, Early 2026)¶

AGL's SoDeV reference platform has progressed from its December 2025 announcement (virtual environment availability) to supporting automotive SoCs in early 2026. The stack combines the AGL Unified Code Base, Linux Containers, VirtIO, Xen hypervisor, Zephyr RTOS, and ELISA safety artifacts — all in a single pre-integrated downloadable package. Led by Panasonic Automotive Systems and Honda, with Toyota, Mazda, AISIN, and Renesas contributing. The AGL SoDeV GitHub activity (meta-agl-monorepo updated April 15, meta-rcar-demo April 13, Zephyr fork April 10) confirms active ongoing development in April 2026. This matters as a counterweight to AAOS SDV's momentum: AGL SoDeV offers the same ECU-consolidation architecture (multiple domains as VMs on one SoC) but under neutral Linux Foundation governance, with Japanese OEM backing as its anchor. The competitive positioning is now explicit: AAOS SDV (Google-controlled, AOSP pending) vs. AGL SoDeV (foundation-governed, already on AGL Reference Hardware) — and both are targeting the same domain consolidation use cases previously served by AUTOSAR Adaptive.

AAOS SDV Open-Source and the Open Question of Governance (Eclipse SDV Blog, March 27, 2026)¶

Eclipse SDV's formal response to the AAOS SDV announcement, published the same day as the Google open-sourcing news. The governance concern raised: AAOS SDV uses a single-vendor open-source model (Google retains roadmap control) rather than a foundation-based neutral governance model like AGL or Eclipse SDV. Specific risks flagged: (1) license for AAOS SDV not yet confirmed (Apache 2 preferred but not guaranteed), (2) access currently restricted to "automotive partners" rather than the full ecosystem, (3) historical risk of abrupt license change or project discontinuation in single-vendor OSS (Google's track record includes many discontinued projects). Eclipse SDV explicitly positions itself as the vendor-neutral alternative. Why this matters for OEM decision-making: for OEMs evaluating whether to build on AAOS SDV, this crystallizes the strategic risk. The governance model determines whether AAOS SDV becomes a true open platform or a Google-controlled layer — and directly affects AUTOSAR Adaptive coexistence architecture decisions: if AAOS SDV's license terms are unfavorable, AUTOSAR Adaptive (MISRA+ISO 26262+neutral governance) becomes the safe harbor for safety-critical domains while the IVI layer remains contested. No published coexistence blueprint exists from any major OEM as of April 2026 — the governance uncertainty makes publishing one premature.

Google Expands Open-Source AAOS SDV into Core Vehicle Controls — April 2026 Update (Open Source For You, Apr 2026)¶

Google's April 2026 update to AAOS SDV deepens the March 24 announcement with an expanded scope for open-source release: the platform now explicitly covers seat actuators, climate controls, lighting, cameras, mirrors, vehicle telemetry, diagnostics, and OTA software update infrastructure — in addition to infotainment. The April clarification signals a concrete roadmap for AOSP integration later in 2026, making the full vehicle-domain Android stack available to any automaker or Tier-1 without licensing fees. The strategic implication is sharper in April: AAOS SDV is now positioned not as a complement to AUTOSAR but as a direct competitor to AUTOSAR Adaptive for all non-safety-critical vehicle domains. Automakers lacking strong internal software capability (most traditional OEMs outside Tesla and Rivian) gain a fully maintained, Google-backed SDV foundation. The question the April update does not answer: how AAOS SDV's service layer co-exists with AUTOSAR Classic ECUs on the same vehicle bus — no published integration blueprint exists yet.

AUTOSAR SDV Forum & AUTOSAR China Day — March 18–19, 2026 (AUTOSAR, 2026)¶

The 2026 SDV Forum and AUTOSAR China Day (March 18–19, 2026) drew global participation from OEMs and Tier-1 suppliers reviewing AUTOSAR's SDV positioning. Key industry data surfaced: leading OEMs allocate 21% of SDV expenditure to software (vs. equal portions on E/E architecture), and a vast majority are adopting zonal E/E architectures to centralize compute and reduce wiring harness weight. The SDV software stack analysis maps 8 layers and 48 components, evaluating AUTOSAR Adaptive and Eclipse SDV frameworks alongside vehicle platforms like MB.OS. This positions AUTOSAR Adaptive not as an all-domain solution but as one layer in a multi-framework SDV stack, where it handles safety-critical compute domains while middleware like Zenoh or AAOS SDV services handle non-safety domains. The China Day attendance signals that Chinese OEM SDV programs are increasingly referencing AUTOSAR standards — potentially accelerating AUTOSAR Adaptive adoption in vehicles designed for multiple markets simultaneously.

Zephyr RTOS Safety Certification: ASIL-D Submission Filed, MC/DC Gap Acknowledged (Zephyr Project, 2026)¶

Zephyr submitted its first functional safety certification artifacts in 2025–2026, targeting ISO 26262 ASIL-D (automotive) and IEC 61508 SIL 3 (industrial). The Safety Committee's stated goal is a complete certification artifact set by 2026, but full third-party certification is likely to slip to 2027 due to two factors: community resourcing gaps, and — critically — a deliberate decision not to pursue MC/DC (Modified Condition/Decision Coverage), which is a formal ASIL-D software testing requirement. This means the current certification effort has a known compliance gap for ASIL-D: Zephyr can satisfy most ASIL-D criteria but not the MC/DC structural coverage requirement without significant additional test infrastructure. Practical implication for AGL SoDeV teams: Zephyr + ELISA is the right architectural direction for safety-critical bare-metal domains, but production sign-off for ASIL-D requires supplementary MC/DC coverage evidence that Zephyr itself will not supply by default. Teams must maintain their own MC/DC evidence layer until this gap is formally closed by the community.

Renesas R-Car X5H Gen 5: 3nm Multi-Domain Automotive SoC Sampling for AGL SoDeV (Renesas, 2026)¶

Renesas has begun sampling its R-Car X5H Gen 5 — the first multi-domain automotive SoC built on a 3nm process node — alongside the R-Car Open Access (RoX) Whitebox SDK, previewed at CES 2026. This is the hardware target that AGL SoDeV is designed to run on: a single SoC consolidating instrument cluster, IVI, ADAS, and zonal gateway domains — the full ECU consolidation vision. The 3nm process delivers the compute density needed for concurrent multi-domain workloads (GPU for HMI, NPU for ADAS, CPU clusters for Linux/Zephyr domains) within automotive thermal budgets. For AGL SoDeV context: at Embedded World 2026 (Nuremberg, March 10–12), AGL demoed SoDeV live alongside AISIN and Renesas in Hall 4 — the first hardware-level demos of SoDeV on real automotive silicon, not just virtual machines or cloud. The transition from "available in virtual environments early 2026" (announced Dec 2025) to "running on Renesas R-Car reference hardware" closes the gap between AGL's SDV ambition and actual automotive-grade silicon deployment.

AAOS SDV Open-Sourced into AOSP: Architecture, Renault Trafic e-Tech Production, Qualcomm Silicon (WardsAuto + Android Devs Blog, March 2026)¶

The full AAOS SDV architecture revealed March 24, 2026: headless Android native stack covering seat actuators, instrument cluster, climate, lighting, cameras, mirrors, and telemetry — deployed via a topology-agnostic, service-oriented communication layer treating vehicle functions as reusable microservices across centralized or distributed ECU topologies. Supports hypervisor-backed virtualization (virtio) or bare-metal for latency-sensitive domains. A Display Safety framework meets functional safety requirements for the instrument cluster — Google's answer to ASIL-B instrument cluster safety requirements without full AUTOSAR Classic. Granular service-level OTA updates with dependency management. Qualcomm Snapdragon Digital Chassis is the primary silicon partner; Qualcomm's Snapdragon vSoC-on-Google-Cloud (announced CES 2026) provides a cloud-native simulation environment for hardware-software co-development — accelerating cycles before physical SoCs are available. Renault Trafic e-Tech is the lead production vehicle (90% of functions OTA-updateable, production beginning late 2026 — first European SDV built on Android OS co-developed with an OEM). AAOS SDV will be open-sourced into AOSP later in 2026 — making it freely available to any Tier 1 or smaller OEM, directly competing with AGL's open-source positioning. Key unresolved tension: AAOS SDV's service-oriented comms layer overlaps functionally with AUTOSAR Adaptive ara::com middleware, and OEMs committed to AUTOSAR safety-critical ECUs have no published coexistence strategy yet.

Android Automotive OS Expanding Beyond IVI into Full SDV Domains (Android Developers Blog, March 2026)¶

Google published a March 2026 blog post detailing how Android Automotive OS is being extended beyond infotainment into broader SDV domains — a direct competitive move into territory AGL SoDeV targets. Renault confirmed production deployment of Android Automotive OS for the Trafic e-Tech beginning late 2026, representing a concrete OEM production commitment to the Android SDV stack on a commercial vehicle (not just passenger car). The extension targets zone-architecture domains beyond the HMI: body control, driver monitoring, and OTA infrastructure. Key competitive implication: the Android AAOS vs. AGL SoDeV battle is no longer just IVI — it's a full-stack SDV platform competition, with Google's app ecosystem and OTA infrastructure vs. AGL's open-source neutrality and Japanese OEM backing. OEMs must now explicitly choose or layer both.

Zenoh Gaining Production Ground in SDV Over SOME/IP for Greenfield Deployments (ZettaScale, 2026)¶

Eclipse Zenoh (v1.0 released 2024) is moving from benchmarking to OEM-level production adoption discussions, with ZettaScale reporting engagement on greenfield SDV programs. A 2025 ScienceDirect performance study (https://www.sciencedirect.com/science/article/pii/S1570870525000320) confirms Zenoh's lower latency and reduced transmission overhead vs. vSOME/IP in industrial IoT scenarios. The automotive middleware benchmarking paper (arXiv:2505.02734) already in this wiki showed Zenoh winning in dynamic reconfiguration — critical to zone-architecture SDVs. The nuance now emerging from production decisions: SOME/IP remains dominant in AUTOSAR Classic brownfield ECU networks (too much installed base to displace), while Zenoh is the default for new greenfield SDV programs where the architects have a clean-slate middleware choice. The two protocols are co-existing in mixed fleets, not replacing each other.

Automotive Middleware Benchmark: FastDDS vs. Zenoh vs. vSomeIP (arXiv:2505.02734, RWTH Aachen, 2025)¶

The most rigorous head-to-head comparison of the three dominant automotive middleware candidates across message types matching real sensor payloads (IMU, camera, LiDAR, radar). Results: Zenoh achieves fastest discovery and time-to-first-message; FastDDS best-effort provides best throughput scaling; vSomeIP significantly underperforms on latency and discovery. A notable finding: FastDDS reliable mode failed to complete the full test set (stopped at 4,557 of 5,500 samples), raising a robustness concern for safety-relevant applications. Zenoh — Eclipse Foundation project, released 2024 — is emerging as a credible third option alongside DDS and SOME/IP, particularly for zonal architectures with wireless or mixed-transport links. For AUTOSAR Adaptive (which mandates SOME/IP and DDS as backends), this benchmark suggests Zenoh warrants inclusion in transport-selection evaluations for new SDV programs.

QNX vs Zephyr vs Embedded Linux in 2026: Safety Certification Status (Promwad, 2026)¶

Current Zephyr certification status: targeting IEC 61508 SIL 3 end-to-end certification in 2026, ISO 26262 ASIL D on roadmap but no firm date. Most production teams treat Zephyr as "safety-aware" rather than "safety-certified" — usable in safety systems with supplementary evidence, but formal certificate not yet in hand. ELISA (Embedded Linux in Safety Applications) has produced safety evidence artifacts for Linux but has not achieved complete IEC 61508 or ISO 26262 certification. Practical upshot for AGL SoDeV: the Zephyr + ELISA layer is a path toward certification, not a currently certified solution. OEMs adopting SoDeV must maintain a parallel safety evidence effort until formal certification lands. This also means AGL SoDeV's open-source SDV stack is ready for prototype and pre-development programs now, but production sign-off requires additional work.

Mixed-Criticality IVI Demo at Embedded World 2026: Android + Safety Linux on Same SoC (April 7, 2026)¶

Kernkonzept, Telechips, and Elektrobit demonstrated a production-oriented cockpit at Embedded World 2026 running Android infotainment and EB corbos Linux for Safety Applications in strict isolation on the same Telechips Dolphin5 SoC (Arm automotive CPU + Mali-G78AE GPU). Kernkonzept's L4Re hypervisor handles hardware-assisted GPU virtualization between the safety and non-safety VMs — each gets isolated GPU time slices without shared memory channels that could violate ASIL-B separation. This is the supply-chain proof that the SoDeV architecture works on shipping silicon: Tier-1 middleware (Elektrobit), hypervisor (Kernkonzept), and SoC (Telechips) are all production-ready for consolidated cockpit domains. Key implication: the "one SoC for instrument cluster + IVI" design that AGL SoDeV targets is no longer theoretical — it was demoed in hardware at Embedded World April 2026.

AGL Launches SoDeV: Open Source Software-Defined Vehicle Reference Platform (Linux Foundation, Dec 2025)¶

AGL's biggest announcement in years: SoDeV (Software Defined Vehicle) is a full SDV reference implementation led by Honda and Panasonic Automotive Systems, combining the AGL Unified Code Base (UCB) with VirtIO, Xen hypervisor, Linux Containers, Zephyr RTOS, and ELISA (safety-critical Linux). The SDV pivot means AGL is no longer just an IVI platform — it is positioning for ECU consolidation: multiple vehicle domains running as virtual machines on a single high-compute SoC. VirtIO provides a hardware-abstraction interface so software can be developed and tested on cloud processors or virtual environments before porting to automotive SoCs (Renesas, NXP, Qualcomm). Available early 2026 for virtual environments; automotive SoC target later in 2026. Contributors include Toyota, Mazda, AISIN, Renesas.

FPT Software Joins Automotive Grade Linux and the Linux Foundation ¶

FPT Software's entry into the AGL ecosystem signals continued momentum for standardized embedded Linux in automotive. AGL is now a Linux Foundation project with Toyota, Panasonic, Renesas, and major Tier 1 suppliers. FPT's focus is connected vehicle development — over-the-air (OTA) updates, telematics, and cloud-to-car APIs. Shows the supply chain is building AGL expertise beyond traditional automotive ECU suppliers.

Toyota's Linux Journey (It's FOSS)¶

Toyota committed fully to AGL for IVI across all Toyota and Lexus vehicles globally — a landmark OEM decision that validated AGL over proprietary IVI stacks. The article traces Toyota's transition from QNX-based systems through GENIVI to AGL, and explains why standardization reduces per-model software cost by sharing a common middleware stack. AGL competes directly with Android Automotive OS (used by GM, Volvo, Polestar) and Apple CarPlay-integrated RTOS solutions.

AGL Software Architecture for Automotive Infotainment (Semantic Scholar)¶

Five-layer AGL architecture: App/HMI → Application Framework → Services → OS → Hardware. The framework layer (Wayland/Weston compositor, AGL Application Framework with security policies, WebKit for web-based HMI) sits above a hardened Linux kernel with Yocto Project build system. Integration with AUTOSAR-compliant ECUs occurs via CAN bus, LIN, and Automotive Ethernet (AVB/TSN). Key design principle: safety-critical functions remain on dedicated microcontrollers; the Linux IVI domain is isolated.

Google Open-Sources AAOS SDV via AOSP — Full Vehicle OS Platform, Q2/Q4 2026 Releases (March/April 2026)¶

Google announced in late March 2026 that Android Automotive OS is being extended beyond the IVI domain and open-sourced via AOSP as AAOS SDV — a headless, Android-native platform designed to power vehicle systems across the full SDV stack: instrument cluster, climate control, seat actuators, lighting, cameras, telemetry, and more. AOSP source releases are scheduled for Q2 2026 (early access) and Q4 2026 (full release). Qualcomm announced at CES 2026 a turnkey pre-integrated AAOS SDV stack on Snapdragon Digital Chassis — reducing OEM integration effort significantly. The Renault Trafic E-Tech (production late 2026, Sandouville France) is explicitly named by Google as the production reference vehicle, running Ampere's Android-based CAR OS with 12-inch openR evo infotainment (Google built-in), OTA support, and bodybuilder API access through the same screen. Architectural significance: AAOS SDV is designed to coexist with AUTOSAR Classic ECUs rather than replace them — but unlike AGL SoDeV, it is backed by Google's full ecosystem (Play Store, Maps, Assistant) and a commercially supported OEM partner track. This resolves one major open question in this wiki: Google's coexistence strategy is "Android as the SDV service layer above AUTOSAR Classic ECUs" — no published technical blueprint yet, but the Renault deployment will be the first OEM-level demonstration. For AGL: the threat is real. AAOS SDV now competes not just in IVI but for the entire ECU consolidation layer that AGL SoDeV is targeting.

Android Automotive 25Q2 Source Drop — AOSP Now Live (source.android.com, April 10, 2026)¶

The Android Automotive 25Q2 release page went live at source.android.com (last updated April 10, 2026), marking the Q2 early-access AOSP source drop that was previously only promised for "later this year." This is the first concrete AOSP publication milestone — source now available to any OEM or Tier-1 without a Google partnership agreement. Notable 25Q2 changes: (1) Windowing framework — configurable OEM components to meet custom windowing requirements and facilitate differentiated HMI experiences; (2) Vehicle property constants promoted from @SystemApi to public APIs — widening third-party app access to vehicle state (speed, door status, climate zone settings) without OEM custom APIs; (3) ongoing topology-agnostic communication layer work enabling the same service graph to run on centralized or distributed ECU topologies. The Q2 drop is an "early access" tier; the Q4 2026 drop is expected to carry the full AAOS SDV feature set including the safety-domain extensions. Practical significance for OEMs: the @SystemApi→public promotion removes a major friction point for third-party app developers who previously had to work through OEM-specific APIs to access basic vehicle properties — directly strengthening the Android IVI app ecosystem compared to AGL's thinner app story. The governance question (Apache 2 vs. partner-restricted license) is now partially resolved: Q2 source is openly accessible, suggesting Apache 2 rather than partner-restricted terms.

Core Concepts¶

AGL Architecture¶

┌─────────────────────────────────────┐
│   HMI Apps (Qt, HTML5/WebKit, EGL)  │  ← App Layer
├─────────────────────────────────────┤
│  AGL App Framework (security, APIs) │  ← Framework
├─────────────────────────────────────┤
│  Services (audio, BT, navigation,   │  ← Services
│  vehicle signals, telephony)        │
├─────────────────────────────────────┤
│  Linux Kernel + Yocto BSP           │  ← OS
├─────────────────────────────────────┤
│  SoC Hardware (Renesas R-Car, etc.) │  ← Hardware
└─────────────────────────────────────┘
         ↕ CAN / Ethernet AVB
┌─────────────────────────────────────┐
│  AUTOSAR ECUs (powertrain, ADAS)    │
└─────────────────────────────────────┘

Key Technologies¶

Yocto Project: Build system producing custom Linux distros for embedded targets. AGL uses Yocto layers to support multiple SoC families (Renesas R-Car, NXP i.MX8, Qualcomm SA8155P).
Wayland/Weston: Display server replacing X11 in automotive. Compositor enforces HMI policies (instrument cluster overlay priority, ADAS camera feeds cannot be occluded).
KUKSA.val / VSS: Vehicle Signal Specification — standardized API for accessing vehicle data (speed, fuel level, ADAS status) from the Linux domain.
SOME/IP + DDS: Service-oriented middleware for intra-ECU and inter-domain communication on Automotive Ethernet.
Automotive Ethernet (BroadR-Reach / 100BASE-T1, 1000BASE-T1): Unshielded, single-pair Ethernet replacing CAN for high-bandwidth domains (cameras, displays, LiDAR).

AUTOSAR Integration¶

Classic AUTOSAR: RTOS-based, for safety-critical ECUs (powertrain, brakes, airbags). MISRA C compliance, functional safety (ISO 26262 ASIL-D).
Adaptive AUTOSAR (AP): POSIX-compliant, C++14, for high-compute domains (ADAS, autonomous driving). Runs on Linux or QNX.
Integration point: AGL IVI communicates with Classic AUTOSAR ECUs via gateway ECUs translating CAN ↔ Ethernet.

Competitive Landscape (IVI Platforms, 2026)¶

Platform	Backing	Key Users	Notes
AGL	Linux Foundation	Toyota, Suzuki, Mazda	Open source, Yocto-based
Android Automotive OS	Google	GM, Volvo, Polestar, BMW	Full Google Play, GAS licensed
BlackBerry QNX	Blackberry/QNX	Many OEMs (safety OS)	POSIX RTOS, ASIL-D capable
Elektrobit (EB)	Continental	BMW, VW Group	Commercial, AUTOSAR stack
GENIVI	Defunct → AGL	—	Merged into AGL ecosystem

Functional Safety (ISO 26262)¶

ASIL-A through ASIL-D: Automotive Safety Integrity Levels based on severity × exposure × controllability.
IVI systems typically ASIL-A or QM (no safety requirement) — but must not interfere with ASIL-D systems.
Hardware/software partitioning ensures Linux domain cannot cause safety-critical failures.

Open Questions¶

Will Android Automotive OS eventually dominate due to Google's app ecosystem, or will OEMs resist data dependency?
How does Adaptive AUTOSAR over Linux compare to AGL for the ADAS domain — are they converging?
What is the long-term strategy for OTA security on AGL systems (signed updates, rollback, key management)?
How does AGL handle mixed-criticality scheduling when instrument cluster and IVI share the same SoC?
SoDeV uses Xen for hypervisor-based isolation — how does this compare to AUTOSAR AP's approach to domain isolation? Is Xen safety-certifiable to ISO 26262 ASIL-B/D?
Will Zephyr RTOS within SoDeV become the AGL-standard approach for safety-critical bare-metal ECU functions co-existing on the same silicon?
AAOS SDV vs. AUTOSAR Adaptive ara::com: what is the published coexistence strategy from any major OEM for a vehicle with both? No blueprint exists as of April 2026. Eclipse SDV governance critique (March 27) makes this more urgent — OEMs need technical AND governance clarity before committing.
Will AOSP open-source release of AAOS SDV happen before end-2026? Will the license be Apache 2 (as preferred by ecosystem) or a more restrictive "automotive partner" model? Eclipse SDV's concern about single-vendor OSS governance risks is the key watchlist item.
AUTOSAR China Day 2026 participation: are Chinese OEMs using AUTOSAR Adaptive for their SDV programs, or building proprietary stacks? How does this affect the global standards landscape?
Renault Trafic E-Tech is the anchor AAOS SDV production vehicle (late 2026). Will Renault publish a technical integration blueprint showing AAOS SDV service layer + AUTOSAR Classic ECU coexistence? This would be the first OEM-level coexistence documentation.
AGL SoDeV is on automotive SoCs (April 2026 repos active). When does a production OEM (Toyota, Honda) commit a specific model to SoDeV rather than to AGL UCB or AAOS SDV?