Through a new product named
trout, Android Automotive (AAOS) now provides support
for deployment as a guest virtual machine (VM) in environments compatible with the
trout is based on the
virtual reference platform and is available as the
trout device configuration. The
userspace source code can be found at
device/google/trout. The table
below describes the technology used to virtualize each of the subsystems in
|Audio Control HAL
|Extended View System (EVS)
|Global navigation satellite system (GNSS)
|Sensor HAL 2.0
virtio-scmi and IIO
trout can be used as a starting point to create new In-Vehicle Infotainment (IVI)
Android targets. The build infrastructure is designed to be extended and customized.
# Inherit trout-arm64 default values and settings $(call inherit-product, device/google/trout/aosp_trout_arm64.mk) # Customize HALs as needed LOCAL_VHAL_PRODUCT_PACKAGE := email@example.com LOCAL_AUDIO_PRODUCT_PACKAGE := firstname.lastname@example.org # Configure SELinux policy BOARD_SEPOLICY_DIRS += device/oem/car/sepolicy/vendor/oem # Configure properties LOCAL_DUMPSTATE_PROPERTIES := \ ro.vendor.dumpstate.server.cid=22 \ ro.vendor.dumpstate.server.port=406 \ ro.vendor.helpersystem.log_loc=/data/dumpstate [... and more as needed ...]
Several Android HALs can be individually replaced with custom implementations, or the
default implementations maintained but certain configuration parameters adjusted to establish
proper inter-VM communication in the target environment. These HALs (including Vehicle HAL,
Audio Control HAL, and Dumpstate HAL) are implemented by means of a gRPC interface backed by a
vsock connection between the AAOS guest and a host system providing the
underlying feature implementation. These must be configured by means of supplying the proper
vsock connection parameters as vendor properties. The source code acts as the ultimate
ground truth on which properties are available for configuration and their semantics.
Compile the userspace
To compile the userspace:
- Download the Android source tree:
repo init -u https://android.googlesource.com/platform/manifest -b main repo sync -j8
- Build the environment:
source build/envsetup.sh lunch aosp_trout_arm64-userdebug make -j24
Building the kernel
trout 1.1, the kernel codebase is provided in AOSP. The
trout kernel is composed of the same
code as the upstream ACK 5.10, with the addition of
trout-specific modules for VirtIO subsystems.
- To clone the kernel, run:
repo init https://android.googlesource.com/kernel/manifest -b trout-android12-5.10 && repo sync
- To build the kernel run:
Your hypervisor supplier may have a different kernel configuration required or additional modules that need to be compiled. Be sure to follow this specific guidance, if provided.
When AAOS runs as a guest VM, our goal is to be a compatible Android deployment from the
framework perspective. Host side issues are the purview of each implementation and outside the
We have not performed additional xTS validation on
trout 1.1. Continue
to refer to the below discussion of CTS support in
trout 1.0, several CTS issues remain. The following CTS modules are known to include test
The following CTS-V areas are known to include test failures:
|Car Launcher test
Bluetooth Low Energy (BLE) Advertiser test
Streaming Video Quality Verifier
Bluetooth HID Device test
Hifi Ultrasound Microphone test
Hifi Ultrasound Speaker test
Unlocked Device Required test
Dynamic Sensor Discovery test
Off Body Sensor test
Significant Motion test
Audio Output Routing Notification test
Network Request or Suggestion test
trout 1.1 contains the following known issues:
- User builds of
troutare not available. The system is built as
-userdebug, which may affect some CTS tests.
- Android Verified Boot (AVB) is not supported.
- Some Android subsystems may be unavailable, including secure world and NNHAL.
- Guest network access is generally provided by means of a virtualized Wi-Fi adapter and a
virtio-nettunnel. Host-side connectivity depends on your specific hypervisor deployment.
- Some implementations may offer limited or no Bluetooth capability.
- A VHAL event injection may not work for some sensors.
- Some heavy workloads may cause audio playback glitches.
- In some implementations, adb reboot of the AAOS guest may reboot the entire system.
- STS may cause system instability and require a reboot.
For additional details, refer to the partner release notes for your specific deployment of