Use cases

This page contains common use cases for AVF.

Isolated compilation

As a software-secure enclave, a protected virtual machine (VM) provides a safe environment to compile security-sensitive code. This environment allows moving the compilation of bootclasspath and system server JARs (triggered by an APEX update) from early boot to before reboot, and significantly reduces the post APEX update boot time.

The implementation is in the com.android.compos APEX. This component is optional and can be included using a makefile.

The security goal is to truthfully compile verified input and produce the output in isolation; Android as an untrusted client can't alter the compilation output in any way other than causing it to fail (when Android falls back to boot time compilation).

The compilation service in the VM generates a signature only if there's no error during the entire compilation. Android can retrieve the public key from the VM for signature verification.

The VM's key is generated from the VM's DICE profile, defined by the APEXes and APKs mounted to the VM, in addition to other VM parameters, such as debuggability.

To determine if the public key isn't from an unexpected VM, Android boots the VM to determine if the key is correct. The VM is booted at early boot after each APEX update.

With Protected VM's Verified Boot, the compilation service runs only verified code. As a result the code can therefore determine to accept only inputs that satisfy certain conditions, for example, accept an input file only where its name and the fs-verity digest are defined in an allowlist.

Any exposed APIs from the VM are attack surfaces. All input files and parameters are assumed to be from an untrusted client, and must be verified and vetted before processing.

Input and output file integrity is verified by the VM, with the files stored on Android as an untrusted file server, as follows:

• The content of an input file must be verified before use using the fs-verity algorithm. For an input file to become available in the VM, its root hash must be provided in a container (APK) that contributes to the VM’s DICE profile. With the trusted root hash, an attacker can't tamper with the input without being detected.
• The integrity of the output file must be maintained in the VM. Even if an output file is stored on Android, during the generation, the integrity is maintained with the same fs-verity tree format but can be dynamically updated. The final output file can be identified with the root hash, which is isolated in the VM. The service in the VM protects the output files by signature.

Linux development environment

Android has traditionally been the only major operating system that doesn't let users develop apps on the platform itself. With the introduction of the Linux development environment, we aim to provide a Linux-based development environment to Android users who are developers. In the future, we plan to expand the effort to make it possible for our partners to implement innovative VM use cases like running graphical user interface apps and even games.

The Linux development environment is available on select devices and runs in a non protected virtual machine.

The high-level flow is as follows:

1. To use the Linux development environment, enable developer options.
2. After you enable developer options, the Terminal app appears on your home launcher.
3. Launch the Terminal app from your home launcher.
4. If required, the Terminal app downloads the OS image from Play.
5. The Terminal app uses the Android Virtualization Framework (AVF) to create a virtual machine (VM).
6. AVF then runs the VM with the OS image.
7. The virtual machine boots the OS from the image.
8. After the VM boots, the WebView in the Terminal app connects to a web service in the virtual machine. This service provides terminal access over HTTP.
9. You interact with the terminal by entering commands and viewing the output in the app.

The high-level components of the Linux VM are as follows:

• Terminal app: An Android application providing a terminal interface. It uses a WebView to connect to a web service running in the VM for interaction. This app is disabled by default. Activate it in Developer Settings.
• Android Virtualization Framework (AVF): Android's existing subsystem for VM creation and management. It requires minimal modification to support custom OS images for this feature.
• virtual machine: A VM that AVF generates. It hosts the terminal service, and AVF creates it specifically for the Terminal app's functionality.
• OS image: A slightly modified Debian-based OS image from upstream Debian. The Terminal app downloads this image from an external Google server. It serves as the foundation for the VM's operation.
• Guest Agent: New software in the VM. It reports the OS's state to AVF and provides control of the virtual machine.
• ttyd: Open-source software running in the VM that implements terminal emulation over HTTP. The Terminal app's WebView connects to it.
• Tethering Manager: An existing Android subsystem. It provides network access to the virtual machine by tethering the VM to the Android-powered device.

Content Safety On-Device

Content Safety On-device is a privacy-preserving content safety solution created by the Content Safety On-device Team. It performs content safety classification for various Google products on 1P/3P devices, and protects 1B+ users from abusive content, without requiring user data being sent back to Google servers. It is designed to adhere to Private Compute Core (PCC) principles to ensure transparent and privacy-preserving communication between the client, the virtual machine (VM), and preventing any exfiltration of user data. It can be used for things such as enabling abuse detection on devices, such as Play Protect live threat detection.

In this use case, the system utilizes protected virtual machines to run its model classification for Play Protect live threat detection which then significantly enhances the security of its models and protections. This prevents reverse engineering and manipulation by attackers, even on rooted devices, by ensuring only approved code runs and its operations are hidden from external processes.

The high level flows are as follows:

1. Live threat detection pings Private Compute Services to start the VM. Private Compute Services is a privacy-centric intermediary between the PCC and the cloud server
2. Private Compute Services starts the VM and gets its public key from the VM
3. Private Compute Services hands over VM ownership to Play Protect live threat detection
4. Private Compute Services sends attestation and public key to the server
5. Server verifies attestation and encrypt protections with VM public key
6. Server then sends the encrypted protections back to the device
7. Then, the on-device live threat detection can utilize encrypted protection within the VM. The VM is the only entity with the private key which can decrypt the protections

The high level component are as follows:

• Server: Encrypt and deliver encrypted protections to the VM
• Private Compute Services: Used to start the VM and mediate the communication to the VM and show transparency that no user data is going through Astrea to server
• Play Protect live threat detection:
  • Contains and uses model classifiers provided by Content Safety on-device
  • Accepts ownership of the VM and holds it for classification use
  • Starts and stops the VM as needed.