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

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/

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

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.

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

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"

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

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

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

ArchitectureArchitecture

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;
}

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

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

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

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

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

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

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

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

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

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

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.

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)

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

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

Additional topicsAdditional topics
AOSP build considerations
Use of containers/hypervisors

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