Android beyond the smartphone

Android beyond the smartphoneSilicon 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


http://2net.co.uk/

https://uk.linkedin.com/in/chrisdsimmonds/

https://google.com/+chrissimmonds

Agenda

1. Embedded Android: 30 minutesQ & A

2. Android BSP: 30 minutesQ & A

3. Interfacing with the real world: 30 minutesQ & A

Wrap-up and conclusion


Embedded Android


Mainstream Android

• Android from Google comes in several flavours:

• Android, for smartphones and tablets (approx. 1.5billion 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 yourown 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 profiling

• Secure, as a result of SELinux amongst other things

• Robust: each app runs in its own sandbox

• Updatable: built-in OTA updaterAndroid beyond the smartphone 8 Copyright © 2011-2016, 2net Ltd

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 implementthe 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

Nativeservers

HALlibraries

Otherlibraries

Linux

Binder

JNI

Androidframework

Nativelayer

Kernel

Applayer


The four layers• Applications: stock AOSP apps and 3rd party apps

• Framework, consisting of

• The android.* libraries, which dispatch messages viabinder 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 appsGoogle 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 Googleproprietary APIs

• Most user-facing features require GMS, includingpopular Google apps such as Play Store, Chromebrowser, Google Now, etc.

• Requires a license from Google

• (You can grab it unofficially (and illegally) via thegapps zip file - 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 flash storage

• Touchscreen or external display (optional, butdesirable)

• GPU with OpenGL ES libraries (optional, butdesirable)


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 xi2c, 12 x GPIO

https://developer.qualcomm.com/hardware/dragonboard-410c


Dev boards 2/3

Wandboard

• i.MX6 SoC: single, dual or quadcore ARM Cortex A-9

• 512 MiB, 1 GiB or 2 GiB RAM

• Ethernet and WiFi

• Vivante 880 GPU


http://www.wandboard.org


Dev boards 3/3

BeagleBone Black

• TI AM3359 SoC: single core ARMCortex A-8

• 512 MiB RAM

• Ethernet


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 definition

• Boot Android to command shell (no display)

• Get ADB USB gadget driver to work

• Build Android UI, without GPU support, and getdisplay working

• Implement vendor GPU drivers and OpenGL ESlibraries

• 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-specific device drivers: binder, logger,anonymous shared memory, etc

• Aggressive power management: auto sleep and wakelocks


Androidisms 1/2

• In mainline Linux since 3.3

• Binder: transaction-based inter-processcommunication

• Anonymous shared memory: allows processes toshare memory segments

• Low memory killer: kills background applicationswhen memory is low

• In mainline Linux since 3.5

• Autosleep/wakelock: suspends CPU unless kernel orapp holds a lock


Androidisms 2/2

• Still out of tree

• Paranoid network security: restricts access to networksockets to apps with android.permission.INTERNET

• The recommended kernel configuration options aredocumented atsource.android.com/devices/tech/kernel.html


source.android.com/devices/tech/kernel.html

Google reference kernels

• Google provide reference implementations for Nexusdevices and the emulator athttps://android.googlesource.com

• There are details on how to build them athttp://source.android.com/source/building-kernels.html

• For example, to get the kernel for the emulator("goldfish"):

$ git clone https://android.googlesource.com/kernel/goldfish$ cd goldfish$ git checkout origin/android-3.18


https://android.googlesource.com

http://source.android.com/source/building-kernels.html

http://source.android.com/source/building-kernels.html

Google kernels: some statsKernel Latest version Patches(*) Productscommon 4.1 516 genericexynos 3.4.67 - Nexus 10goldfish 3.18.0 713 Emulatormsm 3.10.73 32968 Nexus 4, 5, 6, 5X, 6Pomap 3.10.0 1218 Minnow (Moto 360)samsung 3.0.8 - Nexus Stegra 3.10.40 - Xoom, Nexus 7, 9x86 3.10.20 - Nexus Player

(*) Number of patches from mainline, which you can findlike 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 Googlereference

• ... 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 inmainline

• The remainder are specific to a particularSoC/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


http://source.android.com/source/build-numbers.html

http://source.android.com/source/build-numbers.html

Building Android

• The Android build system uses GNU make

• Controlled by a single top level Makefile plus manyfragments:

• AndroidProducts.mk: defines products, in sub treedevice/

• BoardConfig.mk: defines boards, in sub tree device/

• Android.mk: defines Android packages, throughoutAOSP


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 aparanoid android manufactured by the Sirius Cybernetics CorpAndroid beyond the smartphone 31 Copyright © 2011-2016, 2net Ltd

AndroidProducts.mk

• This is the top-level makefile for the product

• Simply references a makefile for each variant of theproduct

• Often there is only one

• For example:PRODUCT_MAKEFILES := $(LOCAL_DIR)/aosp_marvin.mk


Product makefile 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_marvinPRODUCT_DEVICE := marvinPRODUCT_MODEL := Paranoid Android


Pre-defined products

• In build/target/product:

• embedded.mk: minimal build of native layer plusSurfaceFlinger but no Java

• aosp_base.mk: embedded.mk, plus Dalvik, Androidframework, apps, etc

• aosp_base_telephony.mk: aosp_base.mk plusphone 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) areunits of code that can be compiled separately

• Each package is defined 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 files


device.mk

• device.mk contains additions and overrides tostandard configuration

• 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 otherBoardConfig.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 isadd_lunch_combo PRODUCT_NAME-[user | userdebug | eng]

• Exampleadd_lunch_combo aosp_marvin-eng


Running the build

• Select the device$ lunchLunch menu... pick a combo:

1. aosp_arm-eng[...]

26. aosp_marvin-eng

• Start the build$ make -j8============================================PLATFORM_VERSION_CODENAME=RELPLATFORM_VERSION=6.0.1TARGET_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 forOpenG LES v1

• A software rendering engine called PixelFlinger

• OpenGL ES v2 and later requires hardware, togetherwith kernel drivers and libraries

• The problem: drivers and libraries are not opensource


Living without GPU support

• Enable PixelFlinger by adding to kernel commandline qemu=1 qemu.gles=0

• Great for board bring-up and early stages of porting

• Could be used in a production device with simple UIneeds

• But, many things need OpenGL ES 2 (e.g. Chromebrowser)


Questions?


Interfacing with the real world


Hardware interfacing

• Android has support for the hardware you wouldexpect in a smartphone

• UI: touchscreen, HDMI monitor, keyboard, mouse,gamepad

• Network: mobile data, WiFi, Ethernet

• Sensors: accelerometer, magnetometer, ambientlight, etc.

• But, embedded applications have more diverseneeds ...

• USB, serial, i2c, digital and analog I/O


I/O, securely

• In Linux, all I/O is done via file descriptors("everything is a file")

• For security and stability, we want to restrict accessto I/O

• Android has a complex security model that enforcesthis


The principle of least privilege

• Each component (app, system service, nativedaemon) is only allowed to access resourcesnecessary to do the job

• Enforced by file 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 file nodes


System services• System resources (display, audio, etc.) are proxied

through Android system services running with greaterprivilege

• System services fail the request if app doesn’t havethe permission

Client app Serverprocess

/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 isthe 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 asthe 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): addsaudio 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 writeSELinux policy to allow apps to read/write thosenodes

• Write a native library that reads/writes the registerson your i2c device

(*) There are better ways, but this works. Ideally you would implementan i2c system service and use Android permissions to controlaccess


Non-Android code

• Use case: porting a middleware layer

• Problems

• Android C library (Bionic) lacks features -> code won’tcompile

• Android build system can’t run external Makefiles ->need to re-write as Android.mk files

• Android file system layout is not standard -> need tochange file paths


Separately-compiled binaries

• Use an external GNU toolchain, and either:

• static link - no library dependencies, but largeexecutables

• chroot - create your own root for your program (seelater)

• Copy the compiled executables and other files intothe Android image from device.mk usingPRODUCT_COPY_FILES


Communication with Android apps

• Use standard IPC mechanisms that are supported byAndroid:

• Local (UNIX) Socket (preferred)

• Named pipe (also known as FIFO)

• A regular file

• Can use any libraries, including those not provided byAndroid

• Avoid license restrictions so you can use GPL code

• Application and your imported native code run inseparate processes, so more robust


chroot

• Standard utility that runs a command with differentroot directory

• chroot <new root> <command>

• The command (and child processes) can only accessfiles "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-compiledBusybox which has its own chroot, along with othertools.


Creating a chroot

• Create a directory containing the files you want

• Set the permissions of the socket, (mysocket) toworld read/write so that a normal Android applicationcan access it

myroot/|-- bin| |-- myprog|-- etc| |-- my.conf|-- lib| |-- libmylib.so|-- proc||-- var

|-- mysocket


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 numberof 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/


http://2net.co.uk/training.html/

Questions?

Slides will be available from the meetup

email: [email protected] (USA) [email protected] (rest of world)


Android beyond the smartphone

Software

Transcript of Android beyond the smartphone