Android Automotive OS 13 – Construct And Run On Raspberry Pi 4B – Grape Up

Constructing an Android Automotive OS may not be a tough job by itself, however the lack of fine tutorials makes it exceptionally laborious. It solely will get more durable if you happen to don’t have at hand any specialised {hardware} like R-Automobile or Dragonboard. Nevertheless, you may simply get a Raspberry Pi – a small ARM-powered, multi-usage pc and an ideal candidate to run AAOS. To make the method simpler for everybody combating this sort of job, on this article, I’ll clarify step-by-step find out how to construct and run the newest model: Android Automotive OS 13. 

Let’s get began! 

Stipulations 

To construct the system, you have to a Linux. You should utilize WSL or MacOS (bear in mind, you want a case-sensitive file system), however pure Linux is the most suitable choice. 

{Hardware} 

As within the earlier article, you want a Raspberry Pi 4B microcomputer, an influence adapter (or you may energy it out of your PC with a USB cable), a reminiscence card, and a show. It’s good to have a touchscreen, however you need to use your mouse and, optionally, a keyboard if extra handy. 

One other nice-to-have ingredient is a USB-TTL bridge for debugging. Discover my earlier article for extra particulars on find out how to use it. 

TL;DR; 

Should you’re on the lookout for the easy means, go to https://github.com/grapeup/aaos_local_manifest and observe the readme. There are only a few instructions to obtain, construct and create a writeable IMG file in your Raspberry. However you want just a few hours to obtain and construct it anyway. Warning! It could not begin if you happen to received’t modify the show settings (see beneath for particulars). 

Adjusting AOSP to make it AAOS 

This venture relies on Raspberry Vanilla by KonstaT – an incredible AOSP port for Raspberry Pi. It covers all the things you could run a pure Android in your Raspberry – an adjusted kernel, {hardware} drivers, and so forth. Nevertheless, there isn’t a automotive construct, so you could assemble it. 

There are 4 repositories in github.com/grapeup relating to AAOS – three forks based mostly on Raspberry Vanilla and one new one. 

The repository aaos_local_manifest comprises an inventory of modified and new repositories. All vital modifications are situated in gadget/brcm/rpi4 and gadget/brcm/rpi4-car tasks outlined within the manifest_brcm_rpi4.xml file. Within the readme of this repository, you’ll discover steps to clone and construct the venture.

The subsequent repository, aaos_device_brcm_rpi4, comprises three components: 

The primary and most necessary is to make the most of the brand new rpi4-car venture and take away conflicting gadgets from the bottom venture.  

Within the aosp_rpi4.mk file, there’s a new line  

$(name inherit-product, gadget/brcm/rpi4-car/rpi4_car.mk) 

to incorporate a brand new venture. 

Within the gadget.mk file, the product attribute is modified to automotive,nosdcard, and all customized overlays are eliminated, together with the overlay listing subsequent to the file. 

Within the manifest.xml file, the android.{hardware}.automotive.automobile HAL ({Hardware} Abstraction Layer) is added. 

The second ingredient is to configure the construct for the display I use. I needed to set the display screen decision in vendor.prop and set the display screen density in BoardConfig.mk. You most likely don’t want such modifications if you happen to use an ordinary PC monitor, otherwise you want another one in your customized show. Bear in mind that the system received’t begin in any respect if the decision configured right here just isn’t supported by your show. 

The final ingredient comprises my regional/language settings in aosp_rpi4.mk. I’ve determined to make use of this file, because it’s not automotive-related, and to depart it within the code to indicate find out how to modify it if wanted. 

The principle half 

Essentially the most main modifications are situated within the aaos_device_brcm_rpi4_car repository. 

The rpi4_car.mk file relies on gadget/generic/automotive/widespread/automotive.mk with few modifications. 

Conditional, particular settings for the Generic System Photographs are eliminated together with the emulator configuration (gadget/generic/automotive/widespread/config.ini) and the emulator audio bundle (android.{hardware}.audio.service-caremu)

As a substitute, you want a combination of vendor-specific and board-specific parts, not included within the widespread/automotive makefile designed for an emulator. 

Android Automotive OS is strictly coupled with an audio engine, so you could add an automotive audio management bundle (android.{hardware}[email protected]) to make it work, even if you happen to don’t need to join any audio system to your board. Additionally, AAOS makes use of a particular show controller with the flexibility to make use of two shows on the identical time ([email protected]), so you could embrace it too. The subsequent half is SELinux policy for actual boards (not an emulator). 

BOARD_SEPOLICY_DIRS += gadget/generic/automotive/widespread/sepolicy 

Then you could add permissions to a couple pre-installed, automotive-oriented packages, to permit them to run within the system or consumer areas. 

PRODUCT_COPY_FILES += gadget/google/cuttlefish/shared/auto/preinstalled-packages-product-car-cuttlefish.xml:$(TARGET_COPY_OUT_PRODUCT)/and so forth/sysconfig/preinstalled-packages-product-car-cuttlefish.xml

The subsequent element is EVS  – Exterior View System launched to AAOS 13. Even if you happen to don’t actually need to join a number of cameras to the system to this point, you must embrace the default implementation of the element and configure it to work as a mock. 

DEVICE_PACKAGE_OVERLAYS += gadget/google/cuttlefish/shared/auto/overlay
ENABLE_EVS_SERVICE ?= true
ENABLE_MOCK_EVSHAL ?= true
ENABLE_CAREVSSERVICE_SAMPLE ?= true
ENABLE_SAMPLE_EVS_APP ?= true
ENABLE_CARTELEMETRY_SERVICE ?= true
CUSTOMIZE_EVS_SERVICE_PARAMETER := true
PRODUCT_PACKAGES += android.{hardware}[email protected]
PRODUCT_COPY_FILES += gadget/google/cuttlefish/shared/auto/evs/init.evs.rc:$(TARGET_COPY_OUT_VENDOR)/and so forth/init/init.evs.rc
BOARD_SEPOLICY_DIRS += gadget/google/cuttlefish/shared/auto/sepolicy/evs

The final half is to regulate variables for a system when working. You set two system properties straight within the makefile (to permit a compelled orientation and to allow the AVRCP Bluetooth profile).

PRODUCT_SYSTEM_DEFAULT_PROPERTIES +=
    config.override_forced_orient=true
    persist.bluetooth.enablenewavrcp=false

Ultimately, you override the next system variables, utilizing predefined and customized overlays.

PRODUCT_PACKAGE_OVERLAYS +=
   
gadget/brcm/rpi4-car/overlay
   
gadget/generic/automotive/widespread/overlay

Usually talking, PRODUCT_PACKAGE_OVERLAYS permits us to overwrite any worth from a property file situated within the supply code. For instance, in our case the overlay root listing is gadget/brcm/rpi4-car/overlay, so the file gadget/brcm/rpi4-car/overlay/frameworks/base/core/res/res/values/config.xml overwrites properties from the file frameworks/base/core/res/res/values/config.xml.

Let’s dive into properties modified.

  • frameworks/base/core/res/res/values/config.xml file:
  • config_useVolumeKeySounds disables utilization of {hardware} quantity keys, as they don’t seem to be current in our setup,
  • config_voice_capable permits data-only mode, as there isn’t a risk to make a voice name from our board,
  • config_sms_capable disables SMS capabilities for a similar cause,
  • networkAttributes and radioAttributes units the system to make use of WiFi, Bluetooth and ethernet connections solely, as there isn’t a GSM modem onboard,
  • config_longPressOnPowerBehavior disables long-press on an influence button, as there isn’t a energy button related,
  • config_disableUsbPermissionDialogs disables USB permission display screen, because it shouldn’t be used within the AAOS,
  • config_defaultUiModeType permits the automotive launcher by default,
  • config_defaultNightMode permits night time mode because the default one.
  • frameworks/base/packages/SettingsProvider/res/values/defaults.xml file:
  • def_wifi_on permits WiFi by default,
  • def_accelerometer_rotation units the default orientation,
  • def_auto_time permits acquiring time from the Web when related,
  • def_screen_brightness units the default display screen brightness,
  • def_bluetooth_on permits Bluetooth by default,
  • def_location_mode permits purposes to make use of location providers by default,
  • def_lockscreen_disabled disables the lockscreen,
  • def_stay_on_while_plugged_in units the gadget to remain enabled on a regular basis.
  • packages/apps/Automobile/LatinIME/res/format/input_keyboard.xml file units the default foreground colour of the default keyboard, because the default one just isn’t very readable. Set keyTextColorPrimary and textColor parameters to regulate it.
  • packages/apps/Automobile/LatinIME/res/values/colours.xml units colours or image characters on the default keyboard and the letter/symbols change on the underside proper nook.
  • packages/apps/Automobile/SystemUI/res/values/colours.xml units the background colour of the standing bar fast settings to make the default font colour readable.
  • packages/apps/Automobile/SystemUI/res/values/config.xml hides brightness settings from the highest bar, because it doesn’t work with out a particular drivers for the show.
  • packages/apps/Settings/res/values/config.xml file:
  • config_show_call_volume disables quantity management throughout calls,
  • config_show_charging_sounds disables charging sounds,
  • config_show_top_level_battery disables battery degree icon.
  • packages/modules/Wifi/service/ServiceWifiResources/res/values/config.xml permits 5Ghz help for the WiFi.
  • packages/providers/Automobile/service/res/values/config.xml disables working a devoted utility when the system begins up or a driver is modified.

You may learn extra about every of these settings within the feedback within the authentic information which these settings got here from.

The final repository is aaos_android_hardware_interfaces . You don’t want it, however there may be one helpful property hardcoded right here. In Android, there’s a idea referred to as HAL – {Hardware} Abstraction Layer. For AAOS, there may be VHAL – Car {Hardware} Abstraction Layer. It’s accountable, amongst others, for HVAC – Heating, Air flow, and Air Conditioning. In our setup, there isn’t a automobile {hardware} and no bodily HVAC, so you employ android.{hardware}.automotive.automobile@V1-emulator-service whose default implementation is situated underneath {hardware}/interfaces/automotive/automobile. To alter the default items utilized by HVAC from imperial to rest-of-the-world, you could modify the {hardware}/interfaces/automotive/automobile/aidl/impl/default_config/embrace/DefaultConfig.h file.

Constructing

The constructing course of for AAOS 13 for Raspberry Pi is way simpler than the one for AAOS 11. The kernel is already precompiled and there may be a lot much less to do.

Simply name these three instructions:

. construct/envsetup.sh
lunch aosp_rpi4-userdebug
make bootimage systemimage vendorimage

On a Home windows laptop computer (utilizing WSL, after all) with the i7-12850HX processor and 32GB RAM, it takes round 1 hour and 40 minutes to perform the construct.

Making a bootable SD card

There are two choices – with or with out the mkimg.sh script. The script is situated underneath gadget/brcm/rpi4 listing and linked in the principle listing of the venture as rpi4-mkimg.sh. The script creates a digital picture and places 4 partitions inside – boot, system, vendor, and userdata. It’s helpful as a result of you need to use Raspberry Pi Imager to put in writing it into an SD card nonetheless, it has just a few limitations. The picture at all times has 7GB (you may change it by adjusting the IMGSIZE variable within the script), so that you received’t use the remainder of your card, irrespective of how huge it’s. In addition to that, you at all times want to put in writing 7GB to your card – even when you must replace solely a single partition, and together with writing zeros to an empty userdata partition.

The choice means is to put in writing it on the cardboard by hand. It’s tough underneath Home windows as WSL doesn’t comprise card reader drivers, nevertheless it’s handy in different working techniques. All required information are constructed within the out/goal/product/rpi4 listing. Let’s put together and write the cardboard. Warning! In my system, the SD card is seen as /dev/sdb. Please modify the instructions beneath to not destroy your knowledge.

OK, let’s clear the cardboard. It’s essential to wipe every partition earlier than wiping your entire gadget to take away file techniques signatures.

sudo umount /dev/sdb*
sudo wipefs -a /dev/sdb*
sudo wipefs -a /dev/sdb

Now let’s put together the cardboard. This line will use fdisk to create 4 partitions and set flags and filesystems.

echo -e "nnnnn+128Mnantn0cnnnnnn+2Gnnnnnn+256Mnnnpnnnwn" | sudo fdisk /dev/sdb

The final step is to put in writing knowledge and put together the final partition.

sudo dd if=boot.img of=/dev/sdb1 bs=1M
sudo dd if=system.img of=/dev/sdb2 bs=1M
sudo dd if=vendor.img of=/dev/sdb3 bs=1M
sudo mkfs.ext4 -L userdata /dev/sdb4
sudo umount /dev/sdb*

Abstract

Android Automotive OS is a big leap for the automotive trade. As there isn’t a manufacturing automobile with AAOS 13 to this point, you may expertise the longer term with this handbook. What’s extra, you are able to do it with a low-budget Raspberry Pi pc. This fashion, I hope you may develop your purposes and play with the system simply with out a further layer of utilizing emulators. Good luck and completely happy coding!