Android beyond the smartphone

Android beyond the smartphone
Silicon Valley Linux Technology Meetup, 14th
September 2016
Android beyond the smartphone 1 Copyright © 2011-2016, 2net Ltd

About Chris Simmonds
• Consultant and trainer
• Author of Mastering Embedded Linux
Programming
• Working with embedded Linux since 1999
• Android since 2009
• Speaker at many conferences and
workshops
"Looking after the Inner Penguin" blog at http://2net.co.uk/
https://uk.linkedin.com/in/chrisdsimmonds/
https://google.com/+chrissimmonds

Agenda
1. Embedded Android: 30 minutes
Q & A
2. Android BSP: 30 minutes
Q & A
3. Interfacing with the real world: 30 minutes
Q & A
Wrap-up and conclusion

Embedded Android

Mainstream Android
• Android from Google comes in several ﬂavours:
• Android, for smartphones and tablets (approx. 1.5
billion of them)
• Android Wear, for smart watches
• Android TV
• Android Auto, for in-vehicle "infotainment"
• Plus Brillo, a cut-down Android (no display) for IoT

Non-Google Android
• Android is an open source operating system
• Open source means anyone can join in
• Some well-known examples:
• Amazon Kindle Fire
• BlackBerry Priv
• Cyanogen Mod and many other "modder ROMs"

Embedded Android
• You can create your own custom Android for your
own needs
• Capitalize on familiar UI
• Well-known programming framework
• Good development tools

Why use Android?
• User interface
• Attractive
• Familiar navigation gestures
• Programming framework
• Everyone knows Java
• Developer tools
• Android Studio
• Many tools for debugging and proﬁling
• Secure, as a result of SELinux amongst other things
• Robust: each app runs in its own sandbox
• Updatable: built-in OTA updater

Example 1: marine navigation
• Furuno NavNet TZtouch2
• Navigation system for small boats
• i.MX6 platform
• AOSP 5.1

Example 2: point of sale
• Leaf Systems
• Point of sale terminal

How open is Android?
• Need to distinguish between the open part:
• AOSP
• And the proprietary part:
• Google Mobile Services
• GMS consists of extension libraries that implement
the Google APIs, such as maps, in-app payment,
Gmail and so on
• Let’s take a closer look at the architecture ...

Architecture of AOSP
Android Java libraries (android.*)
Android Java API
Applications
System services
"Glue" libraries
Native
servers
HAL
libraries
Other
libraries
Linux
Binder
JNI
Android
framework
Native
layer
Kernel
App
layer

The four layers
• Applications: stock AOSP apps and 3rd party apps
• Framework, consisting of
• The android.* libraries, which dispatch messages via
binder to ...
• ... System services, which use JNI to call down to ...
• ... "Glue" libraries written in C++
• Native
• The init program, various native servers (daemons)
and libraries
• Kernel
• A Linux kernel customised for the platform

Google Mobile Services
AOSP
Android apps
Google Mobile
Services
Google apps

Google Mobile Services
• Plain Android apps use only the APIs published
within the AOSP
• AOSP aps include Launcher2, Browser, Email,
Gallery, Keyboard
• GMS is a set of services that provide Google
proprietary APIs
• Most user-facing features require GMS, including
popular Google apps such as Play Store, Chrome
browser, Google Now, etc.
• Requires a license from Google
• (You can grab it unofﬁcially (and illegally) via the
gapps zip ﬁle - google for it)

What do you need to run Android?
• Hardware from one of the supported architectures
• ARM, x86 or MIPS, in 32 or 64 bit varieties
• Capable of running Linux
• At least 512 MiB RAM
• At least 512 MiB ﬂash storage
• Touchscreen or external display (optional, but
desirable)
• GPU with OpenGL ES libraries (optional, but
desirable)

Dev boards 1/3
Qualcomm DragonBoard 401c
• Quad-core ARM Cortex A53
• 1 GiB RAM
• Wi-Fi 802.11 b/g/n
• Adreno 306 GPU
• Expansion headers: 1 x UART, 2 x
i2c, 12 x GPIO
https://developer.qualcomm.com/hardware/dragonboard-410c

Dev boards 2/3
Wandboard
• i.MX6 SoC: single, dual or quad
core ARM Cortex A-9
• 512 MiB, 1 GiB or 2 GiB RAM
• Ethernet and WiFi
• Vivante 880 GPU
i2c, 8 x GPIO
http://www.wandboard.org

Dev boards 3/3
BeagleBone Black
• TI AM3359 SoC: single core ARM
Cortex A-8
• 512 MiB RAM
• Ethernet
i2c, 65 x GPIO
https://github.com/csimmonds/android4beagle

Questions?

Building an Android BSP

DIY Android
• So, you want to port Android to your platform? Here
are the steps:
• Make sure it boots Linux (no Android)
• Create a simple minimal Android device deﬁnition
• Boot Android to command shell (no display)
• Get ADB USB gadget driver to work
• Build Android UI, without GPU support, and get
display working
• Implement vendor GPU drivers and OpenGL ES
libraries
• Implement networking, audio, camera, etc as required

The Linux kernel
• The AOSP repositories do not include a kernel
• It is up to you to provide one
• Android needs some special kernel features,
including:
• Android-speciﬁc device drivers: binder, logger,
anonymous shared memory, etc
• Aggressive power management: auto sleep and wake
locks

Androidisms 1/2
• In mainline Linux since 3.3
• Binder: transaction-based inter-process
communication
• Anonymous shared memory: allows processes to
share memory segments
• Low memory killer: kills background applications
when memory is low
• In mainline Linux since 3.5
• Autosleep/wakelock: suspends CPU unless kernel or
app holds a lock

Androidisms 2/2
• Still out of tree
• Paranoid network security: restricts access to network
sockets to apps with android.permission.INTERNET
• The recommended kernel conﬁguration options are
documented at
source.android.com/devices/tech/kernel.html

Google reference kernels
• Google provide reference implementations for Nexus
devices and the emulator at
https://android.googlesource.com
• There are details on how to build them at
http://source.android.com/source/
building-kernels.html
• For example, to get the kernel for the emulator
("goldﬁsh"):
$ git clone https://android.googlesource.com/kernel/goldfish
$ cd goldfish
$ git checkout origin/android-3.18

Google kernels: some stats
Kernel Latest version Patches(*) Products
common 4.1 516 generic
exynos 3.4.67 - Nexus 10
goldﬁsh 3.18.0 713 Emulator
msm 3.10.73 32968 Nexus 4, 5, 6, 5X, 6P
omap 3.10.0 1218 Minnow (Moto 360)
samsung 3.0.8 - Nexus S
tegra 3.10.40 - Xoom, Nexus 7, 9
x86 3.10.20 - Nexus Player
(*) Number of patches from mainline, which you can ﬁnd
like this:
$ git remote add stable
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
$ git fetch stable
$ git log v<kernel-version>..HEAD
$ git format-patch v<kernel-version>..HEAD

Vendor kernels
• Most vendors base their kernels on the Google
reference
• ... and then add more patches of their own
• Kernel code is licensed under GPLv2, so source is
(should be) generally available
• Conclusions:
• The kernel in most shipping products is quite old
• About 500 patches account for Androidisms not in
mainline
• The remainder are speciﬁc to a particular
SoC/board/product

Getting AOSP
• First, you need to get repo:
$ curl http://commondatastorage.googleapis.com/git-repo-
downloads/repo > ∼/bin/repo
$ chmod a+x ∼/bin/repo
• Then use it to clone AOSP:
$ mkdir ∼/myandroid
$ cd myandroid
$ repo init -u https://android.googlesource.com/platform/manifest
-b android-6.0.1_r55
• The -b option selects the branch
• See http://source.android.com/source/
build-numbers.html for comprehensive list

Building Android
• The Android build system uses GNU make
• Controlled by a single top level Makefile plus many
fragments:
• AndroidProducts.mk: defines products, in sub tree
device/
• BoardConfig.mk: defines boards, in sub tree device/
• Android.mk: defines Android packages, throughout
AOSP

Creating a new device
• Device configurations are in the device/ directory
• There is a two-level hierarchy
• organization/product
• The examples that follow use sirius and marvin 1
• Configuration is defined in AndroidProducts.mk,
BoardConfig.mk and supporting files
• The next few slides describe these essential files...
1In the The Hitchhikers Guide to the Galaxy, Marvin was a
paranoid android manufactured by the Sirius Cybernetics Corp

AndroidProducts.mk
• This is the top-level makeﬁle for the product
• Simply references a makeﬁle for each variant of the
product
• Often there is only one
• For example:
PRODUCT_MAKEFILES := $(LOCAL_DIR)/aosp_marvin.mk

Product makeﬁle example
aosp_marvin.mk
$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base.mk)
$(call inherit-product, device/sirius/marvin/device.mk)
PRODUCT_NAME := aosp_marvin
PRODUCT_DEVICE := marvin
PRODUCT_MODEL := Paranoid Android

Pre-deﬁned products
• In build/target/product:
• embedded.mk: minimal build of native layer plus
SurfaceFlinger but no Java
• aosp_base.mk: embedded.mk, plus Dalvik, Android
framework, apps, etc
• aosp_base_telephony.mk: aosp_base.mk plus
phone dialler and ril
• sdk.mk: the SDK
• In device/google/atv/products:
• atv_base.mk: Android TV

Android packages
• Android packages (also called Android modules) are
units of code that can be compiled separately
• Each package is deﬁned by an Android.mk
• Name of package given by
• LOCAL_PACKAGE_NAME := for Android applications
• or
• LOCAL_MODULE := for everything else
• Package names must be unique: build will fail if not
• In Marshmallow there are > 2800 Android.mk ﬁles

device.mk
• device.mk contains additions and overrides to
standard conﬁguration
• For example, to add packages:
PRODUCT_PACKAGES +=
librs_jni
com.android.future.usb.accessory
androidvncserver

BoardConfig.mk
• Defines characteristics of the board
• CPU architecture and type
• Sizes of file system partitions
• Too many settings to document here: look at other
BoardConfig.mk files for ideas

vendorsetup.sh
• lunch searches for vendorsetup.sh in
• vendor/*/vendorsetup.sh
• vendor/*/*/vendorsetup.sh
• device/*/*/vendorsetup.sh
• Used to add a product to the menu
• Format is
add_lunch_combo PRODUCT_NAME-[user | userdebug | eng]
• Example
add_lunch_combo aosp_marvin-eng

Running the build
• Select the device
$ lunch
Lunch menu... pick a combo:
1. aosp_arm-eng
[...]
26. aosp_marvin-eng
• Start the build
$ make -j8
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=6.0.1
TARGET_PRODUCT=aosp_marvin
[...]
• And wait several hours

The problem with graphics
• Android requires OpenGL ES v1.1 to boot
• Many applications require OpenGL ES v2 or later
• Android provides a fall-back implementation for
OpenG LES v1
• A software rendering engine called PixelFlinger
• OpenGL ES v2 and later requires hardware, together
with kernel drivers and libraries
• The problem: drivers and libraries are not open
source

Living without GPU support
• Enable PixelFlinger by adding to kernel command
line qemu=1 qemu.gles=0
• Great for board bring-up and early stages of porting
• Could be used in a production device with simple UI
needs
• But, many things need OpenGL ES 2 (e.g. Chrome
browser)

Questions?

Interfacing with the real world

Hardware interfacing
• Android has support for the hardware you would
expect in a smartphone
• UI: touchscreen, HDMI monitor, keyboard, mouse,
gamepad
• Network: mobile data, WiFi, Ethernet
• Sensors: accelerometer, magnetometer, ambient
light, etc.
• But, embedded applications have more diverse
needs ...
• USB, serial, i2c, digital and analog I/O

I/O, securely
• In Linux, all I/O is done via ﬁle descriptors
("everything is a ﬁle")
• For security and stability, we want to restrict access
to I/O
• Android has a complex security model that enforces
this

The principle of least privilege
• Each component (app, system service, native
daemon) is only allowed to access resources
necessary to do the job
• Enforced by ﬁle modes and SELinux policy
• Package Manager assignes a unique User ID (UID)
to each app when it is installed
• Apps cannot access any I/O ﬁle nodes

System services
• System resources (display, audio, etc.) are proxied
through Android system services running with greater
privilege
• System services fail the request if app doesn’t have
the permission
Client app Server
process
/dev/binder

Android permissions
• Apps request permissions in AndroidManifset.xml
• For example, to access the serial port:
<uses-permission android:name="android.permission.SERIAL_PORT"/>
• Permission checked by the service
• In this case, Serial Manager:
SerialService.java
enforceCallingOrSelfPermission(android.Manifest.permission.SERIAL_PORT,
null);
// Throws SecurityException if the client app does not have permission

Accessing hardware in Android
• There are services for
• USB host
• USB accessory (described later)
• Serial
• Other types of interface are not provided

USB host mode
• Android supports USB connections where Android is
the USB host
• Applies to most USB devices
• Class android.hardware.usb

USB accessory mode
• Android also has USB "accessory mode"
• Android acts as a USB device, the other end acts as
the host and provides power
• Android Open Accessory (AOA) protocol
• AOAv1 from Honeycomb v3.1 (API level 12)
• AOAv2 from Jelly Bean v4.1 (API level 16): adds
audio from Android to accessessory and HID
• Example use: link Android devices to car stereos

Serial
• Android has (minimal) support for serial ports
• Class android.hardware.SerialPort
• Requires platform support
• Enable serial ports in framework
• Permit access to device nodes in SELinux

Serial
import android.hardware.SerialManager;
import android.hardware.SerialPort;
[...]
private SerialManager mSerialManager;
private SerialPort mSerialPort;
mSerialManager = (SerialManager)getSystemService(Context.SERIAL_SERVICE);
mSerialPort = mSerialManager.openSerialPort("ttyS1", 115200);
ret = mSerialPort.read(mInputBuffer);
mSerialPort.write(mOutputBuffer, bytes.length);

i2c
• There are no Android APIs for i2c
• However, as a work round:
• Modify boot scripts to set mode of /dev/i2c* to 0666
(*)
• Either run SELinux in permissive mode or write
SELinux policy to allow apps to read/write those
nodes
• Write a native library that reads/writes the registers
on your i2c device
(*) There are better ways, but this works. Ideally you would implement
an i2c system service and use Android permissions to control
access

Non-Android code
• Use case: porting a middleware layer
• Problems
• Android C library (Bionic) lacks features -> code won’t
compile
• Android build system can’t run external Makefiles ->
need to re-write as Android.mk files
• Android file system layout is not standard -> need to
change file paths

Separately-compiled binaries
• Use an external GNU toolchain, and either:
• static link - no library dependencies, but large
executables
• chroot - create your own root for your program (see
later)
• Copy the compiled executables and other ﬁles into
the Android image from device.mk using
PRODUCT_COPY_FILES

Communication with Android apps
• Use standard IPC mechanisms that are supported by
Android:
• Local (UNIX) Socket (preferred)
• Named pipe (also known as FIFO)
• A regular ﬁle
• Can use any libraries, including those not provided by
Android
• Avoid license restrictions so you can use GPL code
• Application and your imported native code run in
separate processes, so more robust

chroot
• Standard utility that runs a command with different
root directory
• chroot <new root> <command>
• The command (and child processes) can only access
ﬁles "inside" the new root
• Often called a chroot jail
• See man chroot(8) for details
• Android does not include chroot!
• Typically, you would use a statically-compiled
Busybox which has its own chroot, along with other
tools.

What next?
• Get a dev board
• Start to play
• Learn how to build Android from scratch
• Begin tinkering with hardware
• Keep on learning

Classses in Android and Linux
• KComputing, in conjunction with 2net, offer a number
of 4-day instructor-led classes, including
• Android Porting
• Android internals
• Embedded Linux
• System programming for embedded Linux
• Open access or on-site
• Details at http://2net.co.uk/training.html/

Questions?
Slides will be available from the meetup
email: training@kcomputing.com (USA) or
training@2net.co.uk (rest of world)

Android beyond the smartphone

More Related Content

What's hot

Viewers also liked

Similar to Android beyond the smartphone

Recently uploaded

Android beyond the smartphone