Complete Setup Guide for Automotive Application Testing (AAOS Emulator)
This guide provides a step-by-step walkthrough for setting up the Android Automotive OS (AAOS) Emulator to test automotive applications in a controlled and reliable environment. It covers everything from environment prerequisites to emulator configuration, helping developers and testers streamline their workflow when validating in-vehicle apps
The rise of Android Automotive OS
The modern automobile is undergoing a rapid transformation, shifting from a mechanical machine to a sophisticated, connected computing platform. The key to this change is Android Automotive OS (AAOS), a full operating system that makes the car itself an Android device. This is a fundamental difference from Android Auto, which simply displays content from your phone. This integration allows for a deep connection between the infotainment experience and the vehicle’s core functions, enabling features like on-screen climate control, detailed navigation, and a rich ecosystem of third-party applications. This profound integration marks a new era in vehicle technology.
Why security testing is critical?
With this increased connectivity and deep system integration comes a new frontier for security. A vulnerability in an automotive application or the AAOS framework itself could have far more serious consequences than a bug in a smartphone app. A compromise could lead to a variety of risks, from exposing sensitive user data to potentially affecting critical vehicle functions. The security of AAOS and the applications that run on it is therefore not just about data privacy — it’s about vehicle safety and integrity. Comprehensive security testing is a non-negotiable step to ensure these systems are protected against malicious attacks.
What this guide will cover?
This guide provides a comprehensive, step-by-step walkthrough to get you started in automotive application security testing. We’ll begin by building your foundational test lab, from creating and configuring the AAOS emulator to using command-line tools for low-level interaction. From there, we’ll dive into the core of security analysis: installing and preparing a test application and configuring the environment to intercept and analyze all network traffic, including encrypted HTTPS requests. By the end, you’ll have the practical skills and a working environment to begin your journey into this critical field.
Prerequisites:
Before we start, make sure you have:
- RAM: Minimum 8 GB (16 GB recommended for smooth emulation)
- Storage: 10+ GB free space
- CPU: Intel VT-x/AMD-V enabled in BIOS
- Software:
Android Studio (latest version)
Android SDK + Command-line tool
Java JDK 11 or above
ADB (Android Debug Bridge)
Environment Setup:
1) Open Android Studio
2) Open Virtual Device Manager
Click More Actions → Virtual Device Manager.
3) Create a new virtual device
In Device Manager, click Create virtual device….
4) Choose the Automotive device profile
In Add Device → Form Factor, select Automotive.
Pick Automotive Distant Display with Google Play (1080×600, 120 dpi). Click Next.
5) Select the exact system image
In Configure virtual device:
- Name: Automotive Distant Display with Google Play (or your preferred name)
- API: API 33 “Tiramisu”
- Services: Google Play Store
- System Image: Automotive Distant Display with Google Play x86_64 System Image (API 33)
Click Finish.
6) Confirm download
Android Studio will prompt to download the image, which is approximately 1.2 GB. Click Yes.
7) Observe the download
The SDK Component Installer shows x86_64–33_playstore_r02.zip downloading.
8) Installation complete
When the installer shows Done, click Finish.
9) Verify the AVD is created
Back in Device Manager, you should see:
Automotive Distant Display with Google Play — API 33 — Virtual.
10) Launch the emulator
Click the Run ▶ icon. The emulator boots (Google splash).
11) Check the config.ini file
Once the emulator has booted up, Android Studio automatically generates a configuration file for your AVD. You can find this file by navigating to C:\Users\Sandy\.android\avd\Automotive_Distant_Display_with_Google_Play.avd on your system. This directory contains the configuration files and the disk images for your emulator. Open the config.ini file to view the settings.
12) Review the config.ini details
Inside the config.ini file, you can see the hardware and system properties of your AVD. Pay close attention to the avd.ini.displayname which confirms the correct emulator profile is being used. You can also see important parameters like cpu.ncore and ramSize which define the virtual device’s resources.
AvdId = [your_new_avdid]
PlayStore.enabled = false
abi.type = x86_64
avd.ini.displayname = [your_new_avdid]
avd.ini.encoding = UTF-8
disk.dataPartition.size = 6442450944
fastboot.chosenSnapshotFile =
fastboot.forceChosenSnapshotBoot = no
fastboot.forceColdBoot = yes
fastboot.forceFastBoot = no
hw.accelerometer = yes
hw.arc = false
hw.audioInput = yes
hw.battery = no
hw.camera.back = none
hw.camera.front = none
hw.cpu.arch = x86_64
hw.cpu.ncore = 4
hw.dPad = no
hw.device.hash2 = MD5:5f6209fe11b596feb0d470effb1a9a6b
hw.device.manufacturer = Google
hw.device.name = [your_new_avdid]
# Remove unsupported secondary display (can crash automotive AVD)
# hw.display6.density = 120
# hw.display6.flag = 0
# hw.display6.height = 600
# hw.display6.width = 400
hw.gps = yes
hw.gpu.enabled = yes
hw.gpu.mode = swiftshader_indirect
hw.gyroscope = yes
hw.initialOrientation = landscape
hw.keyboard = yes
hw.lcd.density = 160
hw.lcd.height = 792
hw.lcd.width = 1408
hw.mainKeys = no
hw.ramSize = 4096
hw.sdCard = yes
hw.sensors.light = yes
hw.sensors.magnetic_field = yes
hw.sensors.orientation = yes
hw.sensors.pressure = no
hw.sensors.proximity = no
hw.trackBall = no
image.sysdir.1 = system-images\android-33\android-automotive\x86_64\
runtime.network.latency = none
runtime.network.speed = full
sdcard.size = 512M
showDeviceFrame = no
skin.dynamic = yes
tag.display = Automotive
tag.displaynames = Automotive,Google APIs
tag.id = android-automotive
tag.ids = android-automotive,google_apis
target = android-33
vm.heapSize = 256
13) Review additional configuration details
Scrolling down in the config.ini file reveals more settings. Key entries include hw.gps, hw.gpu.mode, and hw.lcd.density which are configured for the automotive use case. The tag.display and tag.id fields confirm this is an Android Automotive AVD with Google APIs.
14) Find the emulator executable
To run the emulator from the command line, you need to locate its executable. The emulator.exe file is typically found in C:\Users\<username>\AppData\Local\Android\Sdk\emulator. This location is important for running the emulator directly without Android Studio, which is often necessary for advanced testing or automation.
15) List your AVDs from the command line
Open a command prompt or terminal and navigate to the emulator directory (from the previous step). Run the command emulator -list-avds. This will list all the Android Virtual Devices (AVDs) you have created, confirming that your “Automotive_Distant_Display_with_Google_Play” AVD is available to be launched.
16) Launch the emulator from the command line
To launch the emulator using the command line, use the command emulator -avd Automotive_Distant_Display_with_Google_Play. This command starts the AVD and displays a log of its boot process, including checks for hardware virtualization and system requirements.
17) Observe the Google splash screen
As the emulator starts, you will first see the Google splash screen, a clear sign that the AVD is booting up correctly. This screen confirms that you have successfully launched the virtual device.
18) Verify the home screen and app drawer
After a few moments, the emulator will show the AAOS home screen, including the app launcher with various pre-installed apps like “News,” “Bluetooth Audio,” and “Contacts.” This confirms the AVD is fully operational and ready for you to install and test applications. You can use this state to begin your work.
19) Get root access via adb
To gain root access, which is crucial for security testing, open a new command prompt and type adb shell. Then, within the shell, use the command su. The prompt will change from $ to #, indicating that you have successfully gained root privileges. This is a powerful feature of the AAOS emulator, allowing for in-depth system analysis and manipulation.
20) Install an APK
To test internet connectivity and HTTPS traffic, we’ll install a browser app. Use the adb install command from your Windows command prompt. In this case, the command is adb install “vai browser.apk”. Once the installation is successful, you will see a new browser icon on your AAOS emulator’s home screen.
21) Verify browser functionality
Launch the newly installed browser. Try navigating to a website, for example, a blog or news site. This step confirms that the browser is working and that the emulator has a functional network connection, which is a prerequisite for proxying traffic.
22) Export the CA certificate from Burp Suite
On your host machine, open Burp Suite and navigate to the Proxy tab. Click on Proxy listeners, and then select Import/export CA certificate to begin the export process. This is the first step in getting the Burp Suite certificate onto the emulator so it can trust the proxy.
23) Select the export format
In the CA Certificate window, choose Export and select the Certificate in DER format option. This is a binary format for the certificate. Click Next to proceed.
24) Save the certificate
Choose a location to save the certificate file. The standard location is often the Documents or a designated project folder. Save the file with a .der extension (e.g., ca.der).
25) Convert the certificate format
Android requires the certificate to be in PEM format. On your Kali Linux or other Unix-like system, use the openssl command to convert the DER file to PEM. The command is openssl x509 -inform DER -in ca -out burp.pem. This command reads the binary DER input and writes it to a readable PEM file.
26) Get the certificate subject hash
Android also requires the certificate file to be named with its subject hash. Use the openssl command again to get this hash. The command is openssl x509 -inform PEM -in burp.pem -subject_hash_old -noout. The output will be a unique hexadecimal string, which is the required filename.
27) Rename the certificate file
Rename the burp.pem file to the hash obtained in the previous step, adding a .0 extension. The command is cp burp.pem 9a5ba575.0 (using your specific hash). This naming convention is necessary for Android to recognize it as a valid system-trusted CA.
28) Inspect the certificate content
You can use the cat command to view the contents of the newly renamed PEM certificate file. This shows the certificate’s PEM-encoded data, confirming it’s ready to be pushed to the emulator.
29) Push the certificate to the emulator and reboot
Back on your Windows machine, use adb to gain root access and remount the system partition with write permissions. Then, push the renamed certificate file to the /system/etc/security/cacerts/ directory on the emulator. Finally, use the adb reboot command to restart the virtual device, allowing it to load the new certificate and trust it for HTTPS traffic interception.
30) Open Extended Controls
After the emulator has rebooted, click the three dots on the right side of the emulator’s window. This opens the Extended Controls menu, which provides various settings for the virtual device.
31) Configure the Proxy Settings
In the Extended Controls menu, navigate to the Settings tab and then select Proxy. Choose the Manual proxy configuration option. Enter the Host name and Port number for your Burp Suite listener. The standard settings are 127.0.0.1 (or your host machine’s IP address) and 8080. Click Apply to save the changes.
32) Test HTTPS Interception
Open the browser on the AAOS emulator and visit a website that uses HTTPS (e.g., your personal blog or a test site). Simultaneously, observe the HTTP history tab in Burp Suite on your host machine. You should see the intercepted request appear in the list, confirming that your setup is working correctly and you can now analyze secure traffic.
Conclusion:
Congratulations! You have successfully configured a complete AAOS penetration testing environment. This setup is a powerful starting point for:
- Static analysis: Using tools like MobSF to inspect the APK for vulnerabilities.
- Dynamic analysis: Using Frida to manipulate app behavior at runtime.
- Binary inspection: Examining the app’s files on the device for sensitive information.
This is a dynamic field, and with this foundational knowledge, you are well-equipped to drive into the world of automotive application security.
References:
https://source.android.com/docs/automotive/start/what_automotive
https://developer.android.com/codelabs/build-a-parked-app
For more contact:
Written By: Sandeep Vishwakarma