AOSP Embeded Android Participants should have RaspBerrry pi4 board

Course Content with Lab/Hands-on Activity (day wise break-up):

Day 1

1. Introduction to Android, AOSP, and Android Automotive

a. Android architecture: the big picture

b. Getting the source code: the Android Open-Source Project (AOSP)

c. Building Android from source

d. Criteria for selecting hardware

e. Android overview and Detailed view on Android Automotive Architecture

f) overview.

2. Booting Android

a. Learning how the bootloader starts Android.

b. Flashing images using fastboot

c. Customizing init boot scripts

a. Android boot flow

i. Information about init.rc (before customization of boot init scripts)

ii. The different stages of init rc

b. Init.rc changes to load kernel modules or to start user space services from

different stage of a startup.

c. Zygote and system server process

d. Controlling system behavior using system properties

e. Reducing boot time (Boot chart analysis for timing optimization)

f. Android verified boot.

a. Explaining the practical flow of the Android kernel boot up.

g. Full boot up (till HMI) or only till, say for example, the serial console.

Building Android from source

three stages of boot vs various service managers at boot time Stage 1 , 2, 3

init.rc

zygote.rc

.mk vs .bp file

Kati vs. Soong

creating a service with a .rc file

a. Android build system – SOONG build, clang compiler

b. For instance, lunch makefile structure etc.

c. Android images (boot.img, userdata.img , system.img, vendor.img etc)

i. What’s the purpose of these different images?

ii. What content should go to which image?

 

d. m mm mmm

e. getprop

f. Build environment for the code.

Day 2

Android System Internals and HAL - VHAL for Automotive

a. SELinux

a. Compliant & enforced modes.

b. Policies for components

i. How to write policies for device files,

ii. Where to place the policies,

iii. Policy violations.

audit2allow

Android Permission Architecture

write a daemon with rc to receive and display the data

creating a property value using it in a .rc file

various layers: HAL, vendor, device, framework, packages

Add the prebuilt APK to packages and execute.

porting Android code as a stock/prebuilt under a package.

Android apps as privileged apps

placing the file under device.mk

Android Gradle, i.e., material3, into a .BP file

creating a daemon (service) with a .rc file using HAL vs HIADL, AIDL

Introduction to AIDL in Android Studio (a prerequisite)

creating and implementing an interface HAL accessing the same at the device layer

creating logs to check the flow of app

Why HAL crashes and its various reasons

VINTF vs. treble (thinking from the VTS )

Important changes in .bp file

Frozen: true vs. false -> AIDL versioning.. Camera.. 1 2 3 4 5

How to temporarily fix the issue when HAL crashes and its repercussions with the

framework.

How the above inconsistent code can cause a VTS failure

How to FIX and build an app compatible with VTS

SELInux policy

Day 3

Page 8 of 12

Introduction to NDK. Using it from the JNI layer. In line with framework codes, i.e.,

audio/camera, etc.

implementing a bottom-to-top approach of HAL/Vendor (VTS), device, framework,

package(CTS)

Complete code walkthrough workshop

Android Frameworks’ Application Layer

Introduction to AIDL Android APP

Android’s Hardware Abstraction Layer (HAL) concepts

Introduction to Binder, HIDL, and AIDL

compiling process and its dependency

Writing a HAL module device partition Display the data via LOG

Integral part of VINTF and HAL

The project Treble

Why and how systems break: a temporary fix

Day 4

 

The Exterior View System (EVS)

Exterior View System (EVS) rendering:

EVS Architecture:

Dive into EVS App, Manager, and HAL (HIDL/AIDL differences).

Low-Latency Rendering:

Displaying camera frames bypassing SurfaceFlinger.

Early-Boot Lifecycle:

Launching EVS within 2 seconds of kernel start and smooth handover to System UI.

Hardware Interfaces: Integration with VHAL (triggering on reverse gear)

EVS (Exterior View System) is safety-critical; it must run uninterrupted during boot,

shutdown, and user-switching transitions (e.g., when Driver A logs out and Driver B logs

in). If this could be explained with the EVS app as an example.

Let's say Reverse is engaged and then a user switch happens. How do we make sure that

the stream is uninterrupted, and which layers have to take care of user permissions?

Multi-user permission

 

 

 

 

The EVS camera and display HALs

Android Automotive Multimedia Framework – Video

Video layer management, rendering, bypassing SurfaceFlinger for HWC, and

synchronization.

Video Decoding and Rendering Pipeline

Android Automotive Multimedia Framework – Audio

Audio in normal Android

Audio Capture and Input Sharing Policies

Audio Decoding and Rendering Pipeline

Audio Focus and Ducking

Audio policy configuration

Integrating Android audio with the vehicle

Android Automotive Multimedia Framework – Connectivity, Radio, Networking

Vehicle HAL (VHAL) overview

Simulating vehicle properties and signals

Integration of VHAL with Android stack

Automotive-specific system services and their roles

Introduction to CarService and Car APIs

Day 5 

 

a. VTS, CTS —overview, test execution, and test result analysis.

a. Understanding of Modules and their test cases [Testing]

b. Setup and execution [Testing]

c. Pre-conditions (Feature or System settings) for the module test cases

execution [Testing]

b. Writing UT

b. logcat, dumpsys, tombstone (error memory), HIDL deathrecipient (ANR, ASAN,

Tombstone, debuggerd, BoundSAN, GDB, sample report analysis from Existing

project)

c. Logging levels.

Interfacing with hardware / system-level debugging

a. System profiling tools – CPU load, memory analysis

b. Monitoring applications

a. Reference to meminfo,

c. Interface to HW: Some different approaches to reaching hardware from apps.

a. ADB (debug shell)

AOSP initiated defects analysis.

a. Overall Android Automotive Software Architecture understanding - code flow

[Architecture] how to identify and scope a failure

 

b. Understand code flow by implementing a simple use case, e.g., play a wave fie or

increase volume.

from HMI app “Audio" [Development]

c. Use case understanding—Event analyser tool "DumpSys"

-- tool output analysis

[Debugging]

d. Bug-Report understanding [all logs extract and capturing]

e. AAFW, 3rd party apps defects analysis and triaging (CTS/ATS failures)

f. (Tool overview + usage should serve most of the purpose; debugging would be

case-specific)