Android Automotive #2 — Development Environment

Today I will describe how I prepared my dev environment to work with aosp, it’s far from ideal, but with the limited information I was able to acquire it will have to do for now, I will strive to document any improvements or changes I’ve done. I will talk about the following:

• Creating your custom emulator configuration
• The vendor folder
• Getting the default car launcher and configuring the emulator to run your own
• Preparing to work on the vehicle hal

These posts are written for Android Automotive 11, things can be different on previous or more recent versions. My linux machine is running under WSL.

Custom Emulator Configuration

In reality, there is no need to create a custom emulator configuration, but personally, I prefer not to change the sources as much as possible and try to work alongside the original ones.
The emulator I’m using is the default car x86 one:

lunch aosp_car_x86-userdebug

I used this one because I was unable to make any other boot on my system (maybe because I’m running it under WSL).

In order to make my own I simply copied the default configuration and gave it a new name:

# on the sources root
cd device/generic/car/              //the location of the configurations makefiles
cp aosp_car_x86.mk my_car_emul.mk   //the default makefile for the car x86 emulator

Now open the my_car_emul.mk and change the product name to your new configuration:

.....
PRODUCT_NAME := my_car_emul
.....

Now edit AndroidProducts.mk, and add your new configuration, don’t forget to change both PRODUCT_MAKEFILES and COMMON_LUNCH_CHOICES:

PRODUCT_MAKEFILES := \
    $(LOCAL_DIR)/aosp_car_arm64.mk \
    $(LOCAL_DIR)/aosp_car_arm.mk \
    $(LOCAL_DIR)/aosp_car_x86.mk \
    $(LOCAL_DIR)/aosp_car_x86_64.mk \
    $(LOCAL_DIR)/car_x86_64.mk \
    $(LOCAL_DIR)/sdk_car_x86_64.mk \
    $(LOCAL_DIR)/my_car_emul.mk \

COMMON_LUNCH_CHOICES := \
    aosp_car_arm-userdebug \
    aosp_car_arm64-userdebug \
    aosp_car_x86-userdebug \
    aosp_car_x86_64-userdebug \
    sdk_car_x86_64-userdebug \
    my_car_emul-userdebug \

After this you will be able to set up the build environment to your custom build option:

lunch my_car_emul-userdebug

Again this step is not mandatory, but it helps to keep things organized as you add your own product packages.

The vendor folder

The vendor folder will be the place where almost all of our changes will be placed, our custom apps, and launchers will have this folder as their home and besides separating our additions it is also easier to get to them.

# on the sources root
mkdir vendor
mkdir vendor/imaginationoverflow 

Depending on where you got your sources, the vendor folder can already be present, in that case simply create a folder for your own additions.

The Car Launcher

The Car Launcher is the application that you see after you boot Android Automotive, it’s a java application running on a privileged sandbox that enables it to do pretty much whatever it needs to serve its purpose. This application can be found on packages/apps/Car/Launcher so let's get a copy to our vendor folder. (I decided to call it MyLauncher, the name is not important, just be consistent if you decided to use another name).

# on the sources root
 cp -r packages/apps/Car/Launcher vendor/imaginationoverflow/MyLauncher

Now, edit the Android.bp file under the MyLauncher folder in order to change its name and override the default CarLauncher:

android_app {
    name: "MyLauncher",

   .....

    overrides: [
        "Launcher2",
        "Launcher3",
        "Launcher3QuickStep",
        "CarLauncher"
    ],

...
}

Adding CarLauncher to the overrides will ensure that the MyLauncher application will be the one running when android boots. The name change is important for us to include it in the build process of our emulator, in order to do that, let’s get back to my_car_emul.mk and add this launcher to the build process:

# device/generic/car/my_car_emul.mk
...
EMULATOR_VENDOR_NO_SOUND := true
PRODUCT_NAME := my_car_emul
PRODUCT_DEVICE := generic_car_x86
PRODUCT_BRAND := Android
PRODUCT_MODEL := Car on x86 emulator



PRODUCT_PACKAGES += MyLauncher 

By adding to the PRODUCT_PACKAGES our launcher application name, it will be included in the build system, and it will just run. Now to be 100% sure that everything is building and running as we are expecting let's make a small change to our Launcher and see if it appears on the screen, let's edit the WeatherContextualInfoLiveData.java class:

   //vendor/imaginationoverflow/MyLauncher/src/com/android/car/carlauncher/WeatherContextualInfoLiveData.java
   private CharSequence getGreeting() {
        return "Hello from IO blog";
    }

Change the getGreeting method and run your emulator:

source build/envsetup.sh
lunch my_car_emul-userdebug
make
emulator -no-snapshot 

The weather text should have the altered string. Congratulations you made your first real change to the android automotive OS!!

The vehicle HAL

The vehicle HAL is the focal point if you want to use the Android Automotive OS on a new car or device. I will make an in-depth explanation on how to work with it soon, but for now, let's create a copy for us to play around with. The vHAL is under hardware/interfaces/automotive/vehicle, so let's copy it:

cd hardware/interfaces/automotive/
cp -r vehicle/ myvehicle

My initial idea was to copy the vHAL to the vendor folder and work it from there, but since there are some dependencies on the building files (the .bp and .mk) I decided to leave this one on the actual folder and change the default one.

To disable the default vHAL, the easiest way is to simply delete the vehicle folder, if you want to avoid that, you can go into the folder and rename all Android.bp files to for example__Android.bp and it will not be included in the build anymore.

Final Remarks

If you follow the above steps you already understand 90% of what you need in order to intervene in Android Automotive, I decided to postpone giving detailed explanations about the build system and how everything is organized until it makes sense in this series, the goal right now is to get something up and running ASAP and see quick results on our interventions in the system.

In the next post, I will describe how we can use the default emulation vHAL to connect to an actual device, as well as going in-depth on how the vHAL works in the OS.