About://Ron Munitz
● Distributed Fault Tolerant Avionic Systems
○ Linux, VxWorks, very esoteric libraries, 0’s and 1’s
● Highly distributed video routers
○ Linux
● Real Time, Embedded, Server bringups
○ Linux, Android , VxWorks, Windows, devices, BSPs, DSPs,...
● Distributed Android
○ Rdroid? Cloudroid? Too busy working to get over the legal naming, so
no name is officially claimed for my open source
● What currently keeps me busy:
○ Running the PSCG, a Embedded/Android consulting and Training
○ Managing R&D at Nubo
○ Lecturing at Afeka’s college of Engineering
○ Amazing present, endless opportunities. (Wish flying took less time)
PSCG
Agenda
● History and motivation: Embedded,
Headless
● Embedded Software Development Primer
● Android’s Linux legacy
● Android initialization process
● AOSP configurations
● Android headless configurations
PSCG
Selected keypoints in the evolution of
Embedded systems: The 20th century
● Pre 40’s: Mechanical Computers, Turing Machine
● The 40’s: Mechanical Computers, Embedded
Mechanical Computers(V2...), Digital Computers (Z3...)
● The 50’s: Digital Computers, Integrated Circuit, BESYS
● The 60’s: MULTICS, Modem, Moore’s Law, PC
● The 70’s: Apple First Computer, Unix, B becomes C,
● The 80’s: DOS, MacOS, Windows, System-V, GNU
● The 90’s: GSM, World Wide Web, Windows 3.0/9*,
36/56Kbps Modems, ISDN, Linux
PSCG
Selected keypoints in the evolution of
Embedded systems: The 21st century
Windows, Linux, OS X, Symbian, Moblin, Meego,
Cellular Phones, PDA’s, IEEE802.11, Wireless, Mobile
Data, 2G, 3G, Bluetooth, NFC, GPS, Cameras iPod,
iPhone, Android, iPad, Laptops, Tablets, Ultrabooks,
ChromeOS, Google, Apple, Amazon, Facebook, Twitter,
Pebble, Smart Phones, Smart Watches,Smart *, Smart
Home, Sensors, Location, Data, Big Data, 4G, LTE,
DSL, Cable, Broadband, IPTV, Streaming TV,
Crowdsourcing, Social Media, Autonomous Cars,
Robots, iRobot, The Internet of Things….
PSCG
Headless Operating Systems
● Operating Systems which do not emit
substantial physical output
● Do what they have to do
○ @see Embedded Systems
● Save resources on what they don’t
● Can be customized General Purpose OS
● Can be customized Mobile OS
● Can be built from the ground up.
PSCG
Traditional Android
● User/UI centric
● Display is a critical component
○ Have you ever lost someone… Someone like your screen?
● Lots of Sensors
● Rich API’s and set set of tools
● Huge developer base
● A customizable mobile OS
● Can be built from the ground up
○ We’ll do it at my 1:30 session
PSCG
Motivation for Headless Android
● What if your device had no screen?
● But it had lots of Sensors.“Standard” sensors
● And you really, but really don’t want to mess
too much with the hardware itself.
● Just write the minimal required software
○ Using competent developers
○ Using convenient tools
○ Using an Operating System (? → !!!!! )
PSCG
Embedded Systems: Generation I
● Mostly Analog devices.
● Some examples include:
● Laundry Machines
● Refrigerators
● “Ancient” Missiles
● Cars
● Thermostats
PSCG
Embedded Systems: Generation II
● Dedicated Hardware, dedicated software.
● Introducing the Micro-Processor.
● No Operating Systems
● Heavy use of product dependent Assembly
● When lucky enough - also C.
● When extremely lucky - team is large enough to have
some libraries.
● Still very common with DSPs and other performance
critical components.
Embedded Systems: Generation III
● Using Operating Systems:
○ Core/Real time embedded OS such as VxWorks,
Embedded Linux variants, Windows, Integrity, and a
lot lot more
○ General Purpose Operating Systems such as some
Embedded Linux Variants
○ Also run servers.
● You really use them anywhere and everyday:
○ Set Top Boxes, Televisions, Entertainment Systems,
ROUTERS, Phones, Smart watches...
Embedded Systems: Generation IV
● Using the Android,iOS,FirefoxOS or other “mobile”
Operating Systems.
It is somewhere between:
○ Core/Real time embedded Opsrating Systems
○ General Purpose Operating Systems
● Also run servers (ron@nubosoftware.com)
● You CAN really use them anywhere and everyday:
○ Set Top Boxes, Smart TV’s, Entertainment Systems,
Cellular Phones, Tablets, smart watches...
Embedded Build Systems
● In the introduction module we saw a recipe for building
Android using the AOSP Build System.
● The build procedure was done on a designated
machine, which has all the required tools to turn the
○ That machine is referred as The Host
● The host is used to build the system for a designated
device, may it be a handset, an emulator, a streamer
etc.
○ That device is referred to as The Target
PSCG
● In Embedded Software Development, the common
case is that host != target
● They may have the same attributes:
○ architecture (i.e x86, arm, mips…),
○ library versions (libc, libstdc++, …)
○ toolchains (gcc, ar, …)
● But they do not have to, and will usually have little to
nothing in common.
● Hence, the build system uses a cross Toolchain, to
cross compile build artifacts for the target on the
host.
Embedded Build Systems PSCG
Canadian Cross
This simplified (and very inaccurate) image depicts a technique for building
Cross Compilers, known as the Canadian Cross
*source: http://en.wikipedia.org/wiki/Cross_compiler_
Host
Target Target
Host
PSCG
HOST
Embedded Development Overview
TARGETLinux kernel (3.10.7.3)
GNU toolchain
GNU make (3.81)
Python (2.7.3)-
Shell (bash 4.2.25)
Oracle JDK (1.6.0.34)
Git (1.7.9.5)
repo (1.12.2)
Cross toolchains
Android
Emulator
(X86)
Android
Emulator
(ARM)
Windows
over
VirtualBox
Linux over
VmWare
Android-
X86 over
QEMU
LFS over
UML
BSP
Kernel
Drivers (?)
Userspace (?)
Shell (?)
Graphics (?)
...
?
HOST
Connecting the host with the target -
The Android way
TARGETLinux kernel (3.10.7.3)
GNU toolchain
GNU make (3.81)
Python (2.7.3)-
Shell (bash 4.2.25)
Oracle JDK (1.6.0.34)
Git (1.7.9.5)
repo (1.12.2)
Cross toolchains
Android
Emulator
(X86)
Android
Emulator
(ARM)
Windows
over
VirtualBox
Linux over
VmWare
Android-
X86 over
QEMU
LFS over
UML
BSP
Kernel
Drivers (?)
Userspace (?)
Shell (?)
Graphics (?)
...
fastboot
adb
HOST
Embedded Build System - Overview
Operating system
Host toolchains
Cross toolchains
Source control
Android
Emulator
(X86)
Android
Emulator
(ARM)
Windows
over
VirtualBox
Linux over
VmWare
Android-
X86 over
QEMU
LFS over
UML
Build (I)
Images (Build Artifacts)
for target (I)
Build (II) Images (Build Artifacts)
for target (II)
HOST
Embedded Build System - The
Android way
Linux kernel (3.10.7.3)
GNU toolchain
GNU make (3.81)
Python (2.7.3)-
Shell (bash 4.2.25)
Oracle JDK (1.6.0.34)
Git (1.7.9.5)
repo (1.12.2)
Cross toolchains
Android
Emulator
(X86)
Android
Emulator
(ARM)
Windows
over
VirtualBox
Linux over
VmWare
Android-
X86 over
QEMU
LFS over
UML
lunch (I)
make
out/target/product/(I)/*.img
(system.img, boot.img …)
lunch (II)
make
out/target/product/(II)/*.img
(system.img, boot.img …)
HOST
Flashing build artifacts -
The Android way
TARGET
Android
build
System
Android
Emulator
(X86)
Android
Emulator
(ARM)
Windows
over
VirtualBox
Linux over
VmWare
Android-
X86 over
QEMU
LFS over
UML
BSP
Kernel
Drivers (?)
Userspace (?)
Shell (?)
Graphics (?)
...
*.img:
system,
data,
recovery,
boot
(kernel,
ramdisk)
Build fastboot
flash
PSCG
ROM flashing
● ROM Flashing (simplified) - is the action of transferring
the build system output (a.k.a “Build Artifacts”) onto the
target memory (i.e. flash, EEPROM, Hard drive, RAM,
etc).
● Once the ROM is flashed, and assuming it is functional,
it will be loaded and run when your target is power
cycled / reset.
● It is the responsibility of the Bootloader to have the
target’s CPU fetch, load and execute the ROM contents.
PSCG
Embedded Development Example -
The Android way - Flashing Maguro
● Assuming I would like to build the AOSP for my maguro
device.
○ The Host is My laptop, running Ubuntu 12.04 as its
Operating System.
○ The Target is an Samsung Galaxy Nexus GSM.
■ Before flashing - it is running a stock ROM
■ After flashing - it will be running what I built using the AOSP!
○ The “Flashing” occurs when we:
■ Reboot to fastboot mode
■ Flash the boot.img, system.img etc.
of the build output directory (out/target/product/maguro)
Embedded Development Example -
The Android way - Android Emulator
● In the previous module we built an aosp_x86-eng build
variant of the AOSP.
○ The Host is My laptop, running Ubuntu 12.04 as its
Operating System.
○ The Target is an Android Emulator - running what I
built using the AOSP!
○ The “Flashing” pseudo-occurs when we run the
emulator, and it loads the system.img, userdata-
qemu.img, kernel and cache.img of the build output
directory (out/target/product/generic-x86)
The init call graph
init init.rcinit.environ.rc
init.
<anboot.
hw>.rc
import /init.environ.rc - env. variables
import /init.usb.rc - USB configuration -
defines Android as the slave on the USB
bus - with some mode switching options
import /init.${ro.hardware}.rc -
androidboot.hardware
import /init.trace.rc - system wide tracing
to the kernel trace buffer
init
Kernel/init/
main.c
system/cor
e/init
system/cor
e/rootdir
device/vendo
r/product/init.
hw.rc
init.usb.rc
init.trace.rc
PSCG
Syntax
● on <trigger>
<do stuff>
● service <example> <path> <arguments>
user <SomeUser_lets_say_root>
group <SomeGroup_lets_say_system>
class <start me with the rest of the class>
oneshot
PSCG
Gotcha’s
● Service name MUST not be too long!
○ service the_most - OK! :)
○ service the_most_important_service_in_the_world - NOT :(
● Start services at appropriate times (class)
● Beware of the critical option
○ 4 crashes in 4 minutes will cause device reboot
● Watch for user/group
● Unnamed class will assume “default”
PSCG
Debugging tips
● getprop is a life server
○ getprop init.svc.<service_name> tells the status of
the service
■ running, stopped,restarting
○ getprop init.action tells the action currently being
executed
○ getprop init.command tells the command currently
being executed
PSCG
A note about the readme file
● There is no such thing as “init.conf”.
They actually refer to “init.rc”.
○ For example, “on boot” is the first trigger called after
the init process loaded the file init.rc
PSCG
What does it have to do with
Headless Android? PSCG
● The obvious: Everything :
○ No init - no Linux.
○ No Linux - no Android
○ No Android init - no Android.
● The less obvious
○ Some “Headless Android” configuration is supported
right out of the box
○ To use it, apply the following to your init.rc file:
■ setprop ro.config.headless 1
What Happens Next?
● A lot.
● We will have a brief look at the source code
of:
○ The SystemServer, which is spawned by init, using
the app_process native executable.
○ Some native services which require no Java at all
○ Some “Java” services which are of the core of the
fully fledged Android System
● Just a glance to make some sense of the
System Server initialization
going deep requires time.
I give separate training on Android Internals.
PSCG
● The AOSP provides a build system which allows to
easily configure and choose a product type for building
● Or more precisely: Easily once you are familiar with it.
● Getting Familiar with it is hard.
● And partially covered in my next session
○ @see KitKat build System at 1:30PM
● Fortunately - there are premade templates that run:
○ emulators
○ minimal devices
● Let’s have a look at few!
Build Configurations PSCG
Full emulator
● aosp_x86-eng
● Fully fledged emulator
● requires the goldfish kernel
● can be made headless with some
adjustments.
PSCG
Mini emulator
● device/generic/mini_emulator-<arch>
● Fully fledged emulator
○ But with much less packages
○ And a sample launcher (minimalistic one)
● requires the goldfish kernel
● can be made headless with some adjustments.
● Not exposed to the user by default system
○ But can be easily added with a single lunch-combo
■ e.g: add_lunch_combo mini_emulator_x86-eng
PSCG
Mini-X86
● device/generic/x86
● lunch: mini-x86
● Minimal hardware configuration template
● With full Android framework support
● Not for use by emulator
● Cannot be run without adaptation and
debugging
● However it makes a good template.
PSCG
embedded.mk
● Minimal Embedded Linux distribution
● Does not build nor enable the app_process
● Useful for initial bringup
● Or if you do not need the any Java part of
the framework at all.
● Enabled components: networking, adb,
service mechanism, installd, android
permissions and more
PSCG
What about real devices?
● In order to build the AOSP for your on device
you need to know:
○ Your hardware layout
○ The Android build system (@see next session)
○ How to incorporate it with the Android build system
○ That it takes time to ramp up.
○ But there are recipes to use
● Usually it is easier bring up on a linux
emulator, and then port to the real device.
PSCG
But what if I want all but the UI?
● Well, Android has thought about it for you.
● It is possible to make the Android system work except
for launching Activity.
● That means you can write fully functional code that
uses:
○ Services
○ ContentProviders
○ BroadcastReceivers
○ Intents
○ AsyncTasks, …, ….
PSCG
But what if I want all but the UI?
● “All you need” is to set a single property to 1:
○ setprop ro.config.headless 1
○ Make sure the change is persistent
○ Reboot/kill system_server/reflash Android.
● Problem: System Server crashes on android-4.4_r2
● Cause: Some unhandled exceptions (@see code, next)
● Fix: Handle exceptions, grep for all Headless
occurrences, disable “graphical services”.
PSCG
But what if I want all but the UI?
● Services to be disabled:
○ WindowManager
○ InputMethodManager
○ SurfaceFlinger (Optional!!!)
○ SystemUI
○ Possibly more.
● Where to start looking?
○ frameworks/base/services/java/com/android/server/
SystemServer.java
PSCG
A Summary of Headless Configs
● Derive only from Embedded.mk
○ Headless
○ But has no Java. Only minimal “native” Android.
● Build other config but strip Android packages
○ May be tedious
○ May be time consuming and error prone due to code
modifications
○ May be well worth it
● Use existing Android configuration property
○ Does the job for some things
○ Doesn’t for others
○ Usually requires more work on code
PSCG
AOSP Future work
● Headless Systems are important enough
to get attention within the AOSP, after
countless modders have made their own
implementations
● Yet it is not flawless, as we saw in the latest
version.
● The more demand and patches to the AOSP
there are - the better it will get.
PSCG