This document discusses several topics related to Android Automotive: 1. It provides an overview of the Android Automotive architecture and key system services like the Car System Service. 2. It describes the available car app APIs for both general app development and internal AOSP apps. 3. Several default car apps that come with AOSP are mentioned, which provide examples of how to design custom apps. 4. Other topics covered include the Exterior View System, vehicle properties, audio, power management, storage wear leveling, and boot time optimizations.

1. Android AutomotiveAndroid Automotive
YouTube™ LivestreamYouTube™ Livestream
September 4September 4thth 20192019

2. CC-BY-SA 3.0 - Attribution requirements and misc., except 3rd party material,
PLEASE READ:
This slide must remain as-is in this specific location (slide #1), everything else you are free to change;
including the logo :-)
Use of figures in other documents must feature the below "Originals at" URL immediately under that
figure and the below copyright notice where appropriate.
You are FORBIDDEN from using the default "About" slide as-is or any of its contents.
Several diagrams taken from 3rd party material:
Attribution/citation made in every case
Refer to each original for redistribution/citation
Facts and data are not in principle copyrightable (ex: constants in header files), however if you
don't feel comfortable with our use of your material then let us know and we'll remove it:
courseware@opersys.com
Copyright (C) 2019, Opersys inc.
These slides created by: Karim Yaghmour
Originals at: http://www.opersys.com/training/

3. AboutAbout
Introduced Linux Trace Toolkit in 1999
Originated Adeos and relayfs (kernel/relay.c)
Training, Custom Dev, Consulting, ...

4. Why use Android in cars?Why use Android in cars?
Users/industry expecting/standardizing on OS with:
Touch (swipe, pinch-zoom, etc.)
App/Developer ecosystem
Connected
Intelligent/Augmented/Bleeding-edge UX:
Real-time updated data (ex.: navigation)
Audio assistant
etc.
Android does that ... very well
Android is open source
etc.

5. Challenges:
Integration into existing car environment
Security
Upradability
Power consumption
Rear-view camera
Storage wear-leveling
Additional challenges:
Android is "controlled" by Google
Android is geared towards "disposable" devices

6. About Android Automotive OverallAbout Android Automotive Overall
"Final" approach/architecture probably TBD"Final" approach/architecture probably TBD
Much work and publications not publicMuch work and publications not public
Very much in fluxVery much in flux
Key issues yet to be resolvedKey issues yet to be resolved
General-purpose app dev still "alpha"General-purpose app dev still "alpha"

7. TopicsTopics
1. Introduction
2. Architecture
3. Car System Service
4. Car app APIs
5. Car Apps
6. Car HIDL
7. Exterior View System
8. Vehicle Properties
9. Audio
10. Power Management
11. Wear leveling
12. Boot time optimizations
13. Additional topics

8. IntroductionIntroduction
"Auto" vs. "Automotive" -- old (?) naming scheme:
"Auto" == projection app on your phone
"Automotive" == full Android IVI/head-unit
New nomenclature?:
"embedded"/"native"/"powered by Android"
We're focusing on "Automotive"
AOSP extensions for Car functionality
"Modular" addition to existing Android stack
Internals documentation either out-of-date or incomplete
App developer doc "overkill" for very tiny use-case
https://www.theverge.com/2019/1/25/18196234/google-android-auto-in-car-
systems-apple-carplay-interview

9. No "reference" platform available to check against
Emulator target available
Best way to investigate "real" system for now
See device/generic/car/ for implementation/build
Significant changes from 8.x to 9.x
9.x first version officially supported for general app dev
$ lunch
...
8. aosp_car_arm-userdebug
9. aosp_car_arm64-userdebug
10. aosp_car_x86-userdebug
11. aosp_car_x86_64-userdebug
...
$ make -j32
$ emlator &
$ adb root
$ adb shell

10. ArchitectureArchitecture

12. Car System ServiceCar System Service
packages/apps/Car/service
Primarily a multiplexing service:
Encompases all car-related services
See packages/services/Car/service/src/com/android/car/ICarImpl.java
/** @hide */
interface ICar {
/**
* IBinder is ICarServiceHelper but passed as IBinder due to aidl hidden.
* Only this method is oneway as it is called from system server.
* This should be the 1st method. Do not change the order.
*/
oneway void setCarServiceHelper(in IBinder helper) = 0;
IBinder getCarService(in String serviceName) = 1;
int getCarConnectionType() = 2;
}

13. SystemActivityMonitoringService
CarPowerManagementService
CarPropertyService
CarDrivingStateService
CarUXRestrictionsService
CarPackageManagerService
CarInputService
GarageModeService
AppFocusService
CarAudioService
CarNightService
InstrumentClusterService
CarProjectionService
SystemStateControllerService
CarBluetoothService
CarDiagnosticService
PerUserCarServiceHelper
CarStorageMonitoringService
CarConfigurationService
VmsSubscriberService
VmsPublisherService

14. Only a handful of these are publicly-available
Like other system services:
AIDL for each service
HALs/HIDLs used when needed needed
Communication w/ other system services as needed
Packaged as a presistent app
Started as a "service" when a first app attempts to connect with the Car Manager

15. Car app APIsCar app APIs
2 types of APIs:
General app dev for Google Play publication
"Internal" app dev with AOSP APIs
Regarding Google Play apps:
Supported app categories for "Automotive"
( ):
Media apps:
... and nothing else ...
"Google Play services for Android Automotive OS is still in alpha stage."
https://developer.android.com/training/cars
https://developer.android.com/training/cars/media
https://developer.android.com/training/cars/google-services

16. AOSP APIs are far more relevant and interesting
AOSP APIs have no tutorials
Official doc here:
More interestingly, APIs found in AOSP itself:
packages/services/Car/car-support-lib
packages/services/Car/car-lib
Those are the APIs used by the internal AOSP Car apps
Similar in purpose as frameworks/base/core
https://developer.android.com/reference/android/car/classes

17. Car AppsCar Apps
AOSP ships with default/sample Car apps
Great starting point to see how to design your own
As of 9.x:
Dialer
Hvac
LatinIME
Launcher
LensPicker
LocalMediaPlayer
Media
Messenger
Radio
Settings
SystemUpdater
They use combination of Android and Car APIs
Ultimately rely on system services to operate

18. Car HIDLCar HIDL
hardware/interfaces/automotive:
audiocontrol
evs
vehicle
Default implementations for each

19. Exterior View SystemExterior View System
For imagery capture and display very early on boot
Tailored for 2 second rear-view requirement
Should NOT depend on SurfaceFlinger
Requires low-level integration with drivers

21. The main operations are in the app
Take frame from camera and sends it to display
Sample/reference EVS application:
packages/services/Car/evs/app
Aimed at being started as soon as camera/display "ready"
Should be tailored/rewritten as needed
Manager:
packages/services/Car/evs/manager
Facilitates shared access to camera
1 stream, multiple consumers
No difference for apps between using Manager vs. HAL implementation

22. HIDL:
hardware/interfaces/automotive/evs/1.0/
Recommended to augment existing kernel drivers for EVS
Again, do NOT rely on SurfaceFlinger

25. Vehicle PropertiesVehicle Properties
get/set/sub interface for all vehicle properties
List and type of each property provided in HIDL def by Google
See hardware/interfaces/automotive/vehicle/2.0

28. AudioAudio
Android responsible for infotainment sounds:
media
navigation
communication
Android NOT responsible for mission-critical chimes/warnings
It's assumed there's a hardware mixer beneath Android that mixes Android audio and mission-
critical audio.

34. Power ManagementPower Management
Android runs on the SoC
SoC assumed to be controlled/tethered to Vehicle Master Control Unit (VMCU)
Android Automotive knows about "deep sleep" (i.e. suspend to RAM)
Android does NOT do hibernation
Parts:
CarPowerManager (the public API)
CarPowerManagerService (the actual service)

41. Wear levelingWear leveling
Average data written to phone/day: 10GB
"... we expect Android Automotive implementations to have more eMMC writes than a phone."
For an 16GB eMMC w/ 3k erase/write cycles -- lifetime versus daily writes:
16GB/day: 10 years
32GB/day: 5 years
Suggested to use "adoptable" SD card
See "dumpsys car_service" for wear logs
This is the biggest issue facing Android Automotive, IMHO

42. Boot time optimizationsBoot time optimizations
Minimizing Linux kernel boot times has been heavily studied
Many conference presentations on documents on how to do this
Little to no effort from Google to minimize Android boot times
A few scattered conference presentations on the topic:
Suspend to flash
Use of suspendable containers
In short, if it's time-critical, avoid Android at all cost
At some point in the future, Android will need to address suspend to flash

43. Additional topicsAdditional topics
AOSP build considerations
Use of containers/hypervisors

44. Thank You!Thank You!
karim.yaghmour@opersys.com