During the live embedded event in 2021, I presented this session where I go over some examples of customers using Android for their embedded projects, the pros and cons and some tips at the end.

1. EMBEDDED ANDROID IN REAL LIFE
LIVE EMBEDDED EVENT 2021
Gary Bisson

2. 2
WHO AM I?
Embedded SW / Open-source enthusiast!
• Different industries (consumer, defense, multimedia)
• Contributor to: Buildroot, Yocto, Linux kernel, U-Boot, AOSP
Started using Android 10 years ago
• Android 2.3 (Gingerbread)
• Worked on many different SoC (NXP, TI, Atmel, Qualcomm)
Working @Boundary Devices
• Boards designer / manufacturer
• NXP i.MX SoC specialists

3. 3
AGENDA
Introduction to Android
• Why are we here?
• Architecture overview
Android in Embedded projects
• Pros and Cons
• FAQ (and answers)
Real life examples
• Case studies
• Kiosk mode demo
Q&A

4. INTRODUCTION TO ANDROID

5. 5
WHY ARE WE HERE?
Android is the most used mobile OS

72% market share (as of April 2021)
Most source code is open-source

AOSP = Android Open-Source Project

But developed behind closed doors

Not including Google-specific applications
Not as much adoption in the embedded space

Although Android Auto is getting some traction

Not only a good soluton for the UI
●
Security / Device Update / Management

6. 6
WHY ARE WE HERE?
Disclaimers
Android is NOT the right OS for all projects

Not trying to convince everyone to use it
Choosing the OS is the first step of your project!

Is it a new project or the evolution of an existing product?

Is your team familiar with a particular OS?

What are the HW constraints of your system?
This presentation will provide some pointers & hints
This presentation is about the AOSP OS

No Google-specific aspects (GTS, GMS etc...)

7. 7
ANDROID ARCHITECTURE
Based upon the Linux Kernel
• Minus some specific patches
• People booted using mainline!
Most of the OS has been re-designed
• Init process + scripts
• Bionic C library
• Binder IPC
• Hardware Abstraction Layers
• System server + services
• Java UI frameworks

8. 8
ANDROID ARCHITECTURE
Yet still relying on many other OSS projects
• See external/ folder in build tree
•
wpa_supplicant / libpng / toybox...
Custom partition & filesystem layout
• Not following the Filesystem Hierarchy Standard
• Different between A/B and non-A/B devices
• Recently added a “super” partition for dynamic partitioning
Custom build system
• Used to be Makefile-based (Android.mk)
• Now using Soong build system (Android.bp)

9. 9
ANDROID SECURITY
SELinux
• Defines access controls for the processes and files
Application Sandbox + Signature
• Each app has its own UID
• Platform signature to access some APIs
Trusty TEE OS
• On ARM systems, Trusty uses ARM’s Trustzone™
• Standard implementation, used by many components
•
KeyMaster
•
GateKeeper
•
AVB

10. 10
ANDROID BOOT PROCESS
Android-specific boot changes
• Android bootimage includes kernel+dtb+ramdisk
• Android dtboimage includes several dtb overlays
• Boot Control Block (BCB) in misc partition
Android Verified Boot (AVB)
• Using dm-verity to check fs integrity
•
vbmeta partition for hashes
• Lock mechanism to prevent changes
• Rollback protection (A/B devices)
• Partial support in U-Boot!

11. ANDROID IN EMBEDDED PROJECTS

12. 12
PROS - APP DEVELOPMENT 1/2
Great BSP – App dev separation
• SDK provided for Java/Kotlin
• NDK provided for C/C++ native
Free suite of tools
• Android Studio to develop/design
• Emulator available
• Working on all OSes (Linux/Windows/Mac)
Extensive debugging tools
• Android Debug Bridge (ADB)
• logcat
• Systrace / Perfetto profiling

13. 13
PROS - APP DEVELOPMENT 2/2
Great SDK documentation
• developer.android.com
Many examples / sample apps available
• Can find an example for pretty much any API
•
Connectivity / Media / Camera etc...
• Many open-source projects, such as app stores
•
F-Droid is a good example (both server + client)
Many developers available!

14. 14
CONS - BSP DEVELOPMENT 1/2
Dependent on Silicon Vendor support
• Although not strictly necessary
• Some SV BSPs are more complete than others
•
Several prebuilt blobs (usually graphics)
•
Verify what is/isn’t supported!
Source code is huge!
• A full sync is about ~100GB
• A build can also take an extra ~90GB
• Recommend using xref websites:
•
https://cs.android.com/android/platform/superproject
•
http://aosp.opersys.com/

15. 15
CONS - BSP DEVELOPMENT 2/2
Not many resources available
• Although documentation is getting better
•
https://source.android.com/
• Yet many aspects require diving into the source
• Unlike for the app, developers are hard to find
Codebase / System update
• Long-run strategy? How to update in 5 years?
• Google tries to fix that part
•
Project Treble, GKI etc…
•
Depends on Vendor BSP quality

16. 16
CONS - RESOURCES REQUIREMENT
Android is memory-hungry
• Android 10 (AOSP) takes ~1GB of RAM at bootup
• Android 10 (AOSP) has ~160 services running by default
•
This number increases every release
•
Hard to reduce the number without breaking things
• But many platforms now ship with 2GB+
Same goes for the storage
• Need at the least 4GB
•
Many partitions, each with padding for future updates
•
A/B configuration requiring more space

17. 17
PROS & CONS - HAL SUPPORT
Pros: HAL is great...
• Allows to support variety of hardware IC
• Yet providing the same API to developers
Cons: ...when the vendor provides it!
• Otherwise can be very painful
• Depends on the HAL
•
Some (like sensors) are easier than others
Cons: ...when the interface exists in the first place!
• What if there’s no interface for the HW we want to access?

18. 18
FAQ - HOW TO ACCESS HW?
The easy way...
Accessing directly from your application (Java / JNI)

19. 19
FAQ - HOW TO ACCESS HW?
• Requires to update ueventd.rc
•
Recommended not to provide access to others
• Also need to update the SEPolicies
• Such approach requires to have system UID (platform signature)
The easy way...

20. 20
FAQ - HOW TO ACCESS HW?
The easy way...
Some JNI examples exist for
• GPIO access (libgpiod)
• I2C access (i2cdev)
• UART (from frameworks/base)
•
SerialManager API is hidden (not in SDK)
Android Studio can sign with platform key
• Need to use a keystore (.jks)

21. 21
FAQ - HOW TO ACCESS HW?
The proper way...
Creating a custom HAL
• Either as part of the System Server
• Or as a standalone service
Creating a SDK add-on
• Easiest way for developers to use the new API
• No specific UID / signature required
Some examples exist
• AOSP PlatformLibrary is a good start
• BasicService / BasicClient created long time ago
•
Would need to be updated with HIDL
Embedded Android – Karim Yaghmour

22. 22
FAQ - HOW TO SIGN MY BUILD/APP?
The entire build is signed
• Default keys under build/target/product/security/
• Can be selected at build time
•
PRODUCT_DEFAULT_DEV_CERTIFICATE
• Build signature used in OTA update
•
‘make dist’ or ‘make otapackage’
Each application is signed as well
• Some APIs are reserved to platform keys

23. 23
FAQ - HOW TO DO OTA?
Non-A/B system updates
• “old” update mechanism
• Requires to reboot into Recovery Console (RC)
•
Keeps on trying to update until successful
• Android provides APIs to verify and install the package
• Uses ‘cache’ partition to store the package
Sample client implementation
• FSLOta by Freescale/NXP
•
Gets an update package from HTTP server
•
Easily configurable via ota.conf file

24. 24
FAQ - HOW TO DO OTA?
A/B (Seamless) update
• Ensures the device is always operable
•
Rollback mechanism
• Duplication of partitions: uses more space
• Virtual A/B has been introduced
•
Best of both worlds (haven’t tried it yet)
•
Using device mapper snapshots
A/B daemon example provided by Google
• SystemUpdaterSample
•
Gets an update package from HTTP server
•
Easily configurable via json file

25. 25
FAQ - HOW TO START A NATIVE SERVICE?
The init process relies on init.rc files composed of Actions & Services
• on <trigger> [&& <trigger>]*
•
Condition to do something (start a service, create a file, set permissions etc..).
• service <name> <pathname> [ <argument> ]*
•
Starts the native binary with options (class, user, group, disabled, critical etc..).

26. 26
FAQ - HOW TO HAVE ONLY 1 APP RUNNING?
1. Creating a custom Launcher to control everything
• Used to be the recommended way in the early days
•
Only requires to register to the HOME intent
• Yet the SystemUI can overlay that Launcher
•
Status & Navigation bars to be disabled
2. Using the Lock Task Mode
• Requires a Device Policy Controller (DPC)
• Also called Kiosk mode, or Screen pinning
•
User can still exit the mode in screen pinning
• Easy and secure OTA mechanism

27. 27
FAQ - HOW TO CUSTOMIZE THE BUILD?
Build changes
• Adding apps/tools/files
• Adding a prebuilt apk
UI changes
• Mostly in frameworks config.xml / dimens.xml:
•
Navigation / Status Bar control
Customization recommendations
• Try not to modify Android (core / frameworks)
•
Use overlays for xml configurations
•
Use external services if you create your own HAL
•
Don’t modify Android base SELinux policies!
Most common requests

28. 28
FAQ - WHAT ARE THE SECURITY GUIDELINES?
1. Enable secure boot!
2. Do not set SELinux as permissive
3. Only ship ‘user’ builds
4. Use your own signing keys
5. Update your kernel to integrate stable
6. Integrate Android security updates

29. 29
FAQ - CAN SOMEBODY HELP ME?
Nice 3rd
-party solutions to help you!
Kynetics
• Update Factory - OTA Management
• Low-level access SDK add-ons
• Build customization
Esper.io
• Fleet management
•
Device policies + provisioning
•
Application updates
•
Monitoring (battery, RAM, storage, temp)

30. REAL LIFE EXAMPLES

31. 31
CASE STUDY #1 - ACCESS CONTROL
Main features
• 7” touch screen
• Barcode scanner
• NFC
• Wiegand
Why Android?
• Leveraging existing app from another platform
•
Adapting only took a few days
• App in Kiosk mode
• Security features

32. 32
CASE STUDY #1 - ACCESS CONTROL
Updating Hardware & Software
• From i.MX 6 Quad to i.MX 8M Mini
•
Using same interfaces
•
Just different layout / pin muxing
• From Android 8 to Android 10
•
Took only a couple of hours for the app!
•
Mainly adapting GPIO and SELinux rules
Enterprise device management
• Fleet management
• App / OTA updates

33. 33
CASE STUDY #2 - DIGITAL SIGNAGE
Main features
• HDMI monitors
• Wi-Fi and Ethernet connectivity
Why Android?
• HTML5 Application
•
Needed Browser acceleration (video + graphics)
• Dual monitors support
•
Presentation API
• Easy to use OTA updates Dow Jones News ticker - ProducerMatthew

34. 34
CASE STUDY #3 - RUGGED TABLET
Main features
• 10” touch screen
• 4G / Wi-Fi / BT connectivity
• NFC / USB barcode scanner
• Accelerometer + Gyroscope
• Audio speakers + jack
• 8000mAH battery
Why Android?
• Provide customer with well known UI
• Custom app store available
• Device owner/manager in place

35. 35
DEMO - KIOSK MODE
• AOSP on an embedded device
•
Using i.MX 8M Mini Nitrogen device
• Simple Kiosk App
•
Created from sample code
•
Simply going fullscreen
•
Source code available on Github
• Device Owner App
•
Created from AOSP example
•
Putting the Kiosk App in Lock Task Mode
•
Source code available on Github

36. 36
REFERENCES
Embedded Android - Karim Yaghmour
• A must-read of any BSP / HAL work
• Many presentations from Karim available online
What Differs the Android Open Source Project from Other Linux Distributions? - Sergio Prado
• ELCE 2020 talk (slides + video available)
GNU/Linux ou Android - Pierre Ficheux (in French)
• Live Embedded Event 2020 (video available)
Android official platform documentation:
• https://source.android.com/
Android source code!
• https://android.googlesource.com/

37. Q&A