\documentclass[aspectratio=169,obeyspaces,spaces,hyphens,dvipsnames]{beamer}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}% http://ctan.org/pkg/lm
\usepackage{minted}
\usepackage{hyperref}
\usepackage{xcolor}
\usepackage{pgfplots}
\usepackage{tikz}
\usepackage[normalem]{ulem}
\usepackage{eurosym}

\mode<presentation>
\usetheme{Bootlin}

\def\signed #1{{\leavevmode\unskip\nobreak\hfil\penalty50\hskip2em
  \hbox{}\nobreak\hfil(#1)
  \parfillskip=0pt \finalhyphendemerits=0 \endgraf}}

\newsavebox\mybox
\newenvironment{aquote}[1]
  {\savebox\mybox{#1}\begin{quotation}}
  {\signed{\usebox\mybox}\end{quotation}}

\title{Android System Development}
\authors{Maxime Ripard}
\email{maxime.ripard@bootlin.com}
\institute{Bootlin}
\conference{Captronic Seminar}
\slidesurl{https://bootlin.com/pub/conferences/}

\usepackage{hyperref}

\begin{document}

\addtocontents{toc}{\protect\setcounter{tocdepth}{-1}}
\section{Android System Development}
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}}

\begin{frame}
  \frametitle{Maxime Ripard}
  \begin{itemize}
  \item Embedded Linux engineer and trainer at Bootlin since
    2011
    \begin{itemize}
    \item Embedded Linux development: kernel and driver
      development, system integration, boot time and power
      consumption optimization, consulting, etc.
    \item Embedded Linux training, Linux driver development training
      and Android system development training, with materials freely
      available under a Creative Commons license.
    \item \url{https://bootlin.com}
    \end{itemize}
  \item Contributor to various open-source projects: Barebox, Linux,
    Buildroot
  \item Living in Toulouse, south west of France
  \end{itemize}
\end{frame}

%% Bootlin %%
\begin{frame}
  \frametitle{Bootlin}
  \begin{itemize}
  \item Bootlin, specialized in Embedded Linux, since 2005
  \item Strong emphasis on community relation
  \item {\bf Training}
    \begin{itemize}
    \item {\em Embedded Linux system development}
    \item {\em Linux kernel and device driver development}
    \item Upcoming public sessions in Avignon, Lyon and Toulouse, or
      sessions at customer location
    \item All training materials freely available under a Creative
      Commons license.
    \end{itemize}
  \item {\bf Development and consulting}
    \begin{itemize}
    \item Board Support Package development or improvement
    \item Kernel and driver development
    \item Embedded Linux system integration
    \item Power-management, boot-time, performance audits and improvement
    \item Embedded Linux application development
    \end{itemize}
  \end{itemize}
\end{frame}

%% Bootlin customers %%
\begin{frame}
  \frametitle{Bootlin customers}

\noindent\null\hfill\includegraphics[width=0.2\textwidth]{common/alstom-transport.png} \hfill
\includegraphics[width=0.2\textwidth]{common/atmel.png} \hfill
\includegraphics[width=0.2\textwidth]{common/freescale.png} \hfill
\includegraphics[width=0.2\textwidth]{common/marvell.png} \hfill\null

\noindent\null\hfill\includegraphics[width=0.2\textwidth]{common/adeneo-embedded.png} \hfill
\includegraphics[width=0.2\textwidth]{common/ikusi.png} \hfill
\includegraphics[width=0.2\textwidth]{common/crystalfontz.png} \hfill
\includegraphics[width=0.2\textwidth]{common/nsn.png} \hfill\null

\noindent\null\hfill\includegraphics[width=0.2\textwidth]{common/alcatel.jpg} \hfill
\includegraphics[width=0.2\textwidth]{common/siemens.png} \hfill
\includegraphics[width=0.2\textwidth]{common/continental.jpg} \hfill
\includegraphics[width=0.2\textwidth]{common/orange.png} \hfill\null

\noindent\null\hfill\includegraphics[width=0.2\textwidth]{common/thales.png} \hfill
\includegraphics[width=0.2\textwidth]{common/motorola.jpg} \hfill
\includegraphics[width=0.2\textwidth]{common/stmicro.png} \hfill
\includegraphics[width=0.2\textwidth]{common/intel.jpg} \hfill\null
\end{frame}

\begin{frame}
  \frametitle{Bootlin training}
  \includegraphics[width=\textwidth]{common/training-locations.png}
\end{frame}

\section{Introduction to Android}

\subsection{Features}
\begin{frame}
  \frametitle{Features}
  \begin{itemize}
  \item All you can expect from a modern mobile OS:
    \begin{itemize}
    \item Application ecosystem, allowing to easily add and remove
      applications and publish new features across the entire system
    \item Support for all the web technologies, with a browser built
      on top of the well-established WebKit rendering engine
    \item Support for hardware accelerated graphics through OpenGL ES
    \item Support for all the common wireless mechanisms: GSM, CDMA,
      UMTS, LTE, Bluetooth, WiFi.
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{History}
\begin{frame}
  \frametitle{Early Years}
  \begin{itemize}
  \item Began as a start-up in Palo Alto, CA, USA in 2003
  \item Focused from the start on software for mobile devices
  \item Very secretive at the time, even though founders achieved a
    lot in the targeted area before founding it
  \item Finally bought by Google in 2005
  \item Andy Rubin, founder of Android, Inc was also CEO of Danger,
    Inc, a company producing one of the early smartphones, the
    Sidekick
  \end{itemize}
  \begin{center}
    \includegraphics[height=0.4\textheight]{common/sidekick.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Opening Up}
  \begin{itemize}
  \item Google announced the Open Handset Alliance in 2007, a
    consortium of major actors in the mobile area built around Android
    \begin{itemize}
    \item Hardware vendors: Intel, Texas Instruments, Qualcomm,
      Nvidia, etc.
    \item Software companies: Google, eBay, etc.
    \item Hardware manufacturers: Motorola, HTC, Sony Ericsson,
      Samsung, etc.
    \item Mobile operators: T-Mobile, Telefonica, Vodafone, etc.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Open Source Project (AOSP)}
  \begin{itemize}
  \item At every new version, Google releases its source code
    through this project so that community and vendors can
    work with it.
    \begin{itemize}
    \item One major exception: Honeycomb has not been released because
      Google stated that its source code was not clean enough to
      release it.
    \end{itemize}
  \item One can fetch the source code and contribute to it, even though
    the development process is very locked by Google
  \item Only a few devices are supported through AOSP though, only the
    two most recent Android development phones, the Panda board and the
    Motorola Xoom.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Releases}
  \begin{itemize}
  \item Each new version is given a dessert name
  \item Released in alphabetical order
  \item Last releases:
    \begin{itemize}
    \item Android 3.X Honeycomb
    \item Android 4.0 Ice Cream Sandwich
    \item Android 4.1/4.2 Jelly Bean
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Versions}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/history.pdf}
  \end{center}
\end{frame}

\subsection{Architecture}
\begin{frame}
  \frametitle{Architecture}
  \begin{center}
    \includegraphics[width=\textwidth]{common/architecture.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{The Linux Kernel}
  \begin{itemize}
  \item Used as the foundation of the Android system
  \item Numerous additions from the stock Linux, including new IPC
    (Inter-Process Communication) mechanisms, alternative power
    management mechanism, new drivers and various additions across the
    kernel
  \item These changes are beginning to go into the \path{staging/}
    area of the kernel, as of 3.3, after being a complete fork for a
    long time
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Libraries}
  \begin{itemize}
  \item Gather a lot of Android-specific libraries to interact at a
    low-level with the system, but third-parties libraries as well
  \item Bionic is the C library, SurfaceManager is used for drawing
    surfaces on the screen, etc.
  \item But also WebKit, SQLite, OpenSSL coming from the free software
    world
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Runtime}
  Handles the execution of Android applications
  \begin{itemize}
  \item Almost entirely written from scratch by Google
  \item Contains Dalvik, the virtual machine that executes every
    application that you run on Android, and the core library for the
    Java runtime, coming from Apache Harmony project
  \item Also contains system daemons, init executable, basic binaries,
    etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Framework}
  \begin{itemize}
  \item Provides an API for developers to create applications
  \item Exposes all the needed subsystems by providing an abstraction
  \item Allows to easily use databases, create services, expose data
    to other applications, receive system events, etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android Applications}
  \begin{itemize}
  \item AOSP also comes with a set of applications such as the phone
    application, a browser, a contact management application, an email
    client, etc.
  \item However, the Google apps and the Android Market app aren't free
    software, so they are not available in AOSP. To obtain them, you
    must contact Google and pass a compatibility test.
  \end{itemize}
\end{frame}

\subsection{Hardware Requirements for Linux}

\begin{frame}{Processor architecture}
  \begin{itemize}
  \item The Linux kernel and most other architecture-dependent
    component {\bf support a wide range of 32 and 64 bits
      architectures}
    \begin{itemize}
    \item x86 and x86\_64, as found on PC platforms, but also embedded
      systems (multimedia, industrial)
    \item ARM, with hundreds of different SoC (multimedia, industrial)
    \item PowerPC (mainly real-time, industrial applications)
    \item MIPS (mainly networking applications)
    \item SuperH (mainly set top box and multimedia applications)
    \item Blackfin (DSP architecture)
    \item Microblaze (soft-core for Xilinx FPGA)
    \item Coldfire, SCore, Tile, Xtensa, Cris, FRV, AVR32, M32R
    \end{itemize}
  \item Both {\bf MMU and no-MMU architectures are supported}, even though
    no-MMU architectures have a few limitations.
  \item Linux is {\bf not designed for small microcontrollers}.
  \item Besides the toolchain, the bootloader and the kernel, all
    other components are {\bf generally architecture-independent}
  \end{itemize}
\end{frame}

\begin{frame}{RAM and storage}
  \begin{itemize}
  \item {\bf RAM}: a very basic Linux system can work within 8~MB of
    RAM, but a more realistic system will usually require at least
    32~MB of RAM. Depends on the type and size of applications.
  \item {\bf Storage}: a very basic Linux system can work within 4~MB
    of storage, but usually more is needed.
    \begin{itemize}
    \item {\em flash storage} is supported, both NAND and NOR flash,
      with specific filesystems
    \item {\em Block storage} including SD/MMC cards and eMMC is
      supported
    \end{itemize}
  \item Not necessarily interesting to be too restrictive on the amount of
    RAM/storage: having flexibility at this level allows to re-use as
    many existing components as possible.
  \end{itemize}
\end{frame}

\begin{frame}{Communication}
  \begin{itemize}
    \item The Linux kernel has support for many common communication buses
      \begin{itemize}
      \item I2C
      \item SPI
      \item CAN
      \item 1-wire
      \item SDIO
      \item USB
      \end{itemize}
    \item And also extensive networking support
      \begin{itemize}
        \item Ethernet, WiFi, Bluetooth, CAN, etc.
        \item IPv4, IPv6, TCP, UDP, SCTP, DCCP, etc.
        \item Firewalling, advanced routing, multicast
      \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}{ARM and System-on-Chip}
  \begin{itemize}
  \item ARM is one of the most popular architectures used in embedded
    Linux systems
  \item ARM designs {\bf CPU cores} (instruction sets, caches, MMU, etc.)
    and sells the design to licensees
  \item The licensees are {\bf founders} (Texas Instruments, Freescale, ST
    Ericsson, Atmel, etc.), they integrate an ARM core with many
    peripherals, into a chip called a {\bf SoC}, for System-on-chip
  \item Each founder provides different models of SoC, with {\bf
      different combination of peripherals}, power, power consumption,
    etc.
  \item The concept of SoC allows to reduce the number of peripherals
    needed on the board, and therefore the cost of designing and
    building the board.
  \item {\bf Linux supports SoCs from most vendors, but not all}, and
    not with the same level of functionality.
  \end{itemize}
\end{frame}

\begin{frame}{ARM and System-on-Chip}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.8\textheight,keepaspectratio]{common/arm-soc.pdf}
  \end{center}
\end{frame}

\begin{frame}{Atmel AT91SAM9263}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.9\textheight,keepaspectratio]{common/at91sam9263.png}
  \end{center}
\end{frame}

\begin{frame}{Texas Instruments OMAP3430}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.9\textheight,keepaspectratio]{common/omap3430.png}
  \end{center}
\end{frame}

\begin{frame}{Type of hardware platforms}
  \begin{itemize}
  \item {\bf Evaluation platforms} from the SoC vendor. Usually
    expensive, but many peripherals are built-in. Generally unsuitable
    for real products.
  \item {\bf Component on Module}, a small board with only
    CPU/RAM/flash and a few other core components, with connectors to
    access all other peripherals. Can be used to build end products
    for small to medium quantities.
  \item {\bf Community development platforms}, a new trend to make a
    particular SoC popular and easily available. Those are
    ready-to-use and low cost, but usually have less peripherals than
    evaluation platforms. To some extent, can also be used for real
    products.
  \item {\bf Custom platform}. Schematics for evaluation boards or
    development platforms are more and more commonly freely available,
    making it easier to develop custom platforms.
  \end{itemize}
\end{frame}

\begin{frame}{Gumstix}
  \begin{columns}[c]
    \column{0.7\textwidth}
    \begin{itemize}
    \item {\bf TI OMAP3530 (600  MHz, ARM Cortex-A8, PowerVR SGX, DSP)}
    \item Component on Module
    \item 256 MB RAM
    \item 256 MB NAND (optional)
    \item Bluetooth, WiFi (optional)
    \item uSD
    \item \$115-229
    \item Development boards available at \$ 49-229, with many
      peripherals: LCD, Ethernet, UART, SPI, I2C, etc.
    \item \url{http://www.gumstix.com}
    \end{itemize}
    \column{0.3\textwidth}
    \includegraphics[height=4cm]{common/gumstix-overo.png}
   \end{columns}
\end{frame}

\begin{frame}{Pandaboard ES}
  \begin{columns}[c]
    \column{0.5\textwidth}
    \begin{itemize}
    \item {\bf TI OMAP 4460 (Dual-Core 1.2 GHz, cortex A9, PowerVR GPU, DSP)}
    \item Community development platform
    \item 1 GiB RAM
    \item SD slot, Ethernet, WiFi, Bluetooth, USB OTG
    \item HDMI, S-Video, Camera, audio
    \item \$ 149
    \item \url{http://pandaboard.org}
    \end{itemize}
    \column{0.5\textwidth}
    \includegraphics[width=\textwidth]{common/pandaboard.png}
   \end{columns}
\end{frame}

\begin{frame}{Snowball}
  \begin{columns}[c]
    \column{0.5\textwidth}
    \small
    \begin{itemize}
    \item {\bf ST Ericsson AP9500 (dual cortex A9, MALI GPU)}
    \item Community development platform
    \item 1 GB RAM
    \item 4-8 GB eMMC, microSD
    \item HDMI, S-Video, audio
    \item WiFi, Bluetooth, Ethernet
    \item Accelerometer, Magnetometer, Gyrometer, GPS
    \item Expansion: USB, I2C, SPI, LCD, UART, GPIO, etc.
    \item 169 \euro~to 244 \euro
    \item \url{http://igloocommunity.org}
    \end{itemize}
    \column{0.5\textwidth}
    \includegraphics[height=4cm]{common/snowball.png}
   \end{columns}
\end{frame}

\begin{frame}{Freescale Quick Start}
  \begin{columns}[c]
    \column{0.5\textwidth}
    \small
    \begin{itemize}
    \item {\bf Freescale I.MX53 (1 GHz Cortex A8)}
    \item Community development platform
    \item 1 GB RAM
    \item 4-8 GB eMMC, microSD
    \item LVDS, LCD, VGA, HDMI, audio
    \item Accelerometer, SD/MMC, microSD, SATA, Ethernet, USB
    \item Expansion: I2C, SPI, SSI, LCD, Camera
    \item 149 \euro
    \end{itemize}
    \column{0.5\textwidth}
    \includegraphics[height=4cm]{common/freescale-qsb.jpg}
   \end{columns}
\end{frame}

\begin{frame}{Criteria for choosing the hardware}
  \begin{itemize}
  \item Make sure the hardware you plan to use is already supported by
    the Linux kernel, and has an open-source bootloader, especially the
    SoC you're targeting.
  \item Having support in the official versions of the projects
    (kernel, bootloader) is {\bf a lot better}: quality is better,
    and new versions are available.
  \item Some SoC vendors and/or board vendors do not contribute their
    changes back to the Linux kernel. Ask them to do so, or use
    another product if you can. A good measurement is to see the delta
    between their kernel and the official one.
  \item Between properly supported hardware in the official Linux
    kernel and poorly-supported hardware, there will be huge
    differences in development time and cost.
  \end{itemize}
\end{frame}

\subsection{Embedded Systems using Linux}

\begin{frame}{Consumer device: Internet box}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/freebox.jpg}
  \end{center}
\end{frame}

\begin{frame}{Consumer device: Television}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/television.jpg}
  \end{center}
\end{frame}

\begin{frame}{Professional device: point of sale terminal}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/pos.jpg}
  \end{center}
\end{frame}

\begin{frame}{Industrial system: laser cutter}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/laser-cutter.jpg}
  \end{center}
\end{frame}

\begin{frame}{Industrial system: wind turbine}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/wind-turbine.jpg}
  \end{center}
\end{frame}

\begin{frame}{Industrial system: cow milking}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/cow-milking.jpg}
  \end{center}
\end{frame}

\begin{frame}{Industrial system: sea pollution detection system}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/sea-pollution.jpg}
  \end{center}
\end{frame}

\begin{frame}{Industrial system: viticulture machine}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/wine-machine.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Critical Systems: Nuclear Reactor}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/nuclear.jpg}    
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Critical Systems: Rockets}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/spacex.jpg}    
  \end{center}
\end{frame}

\subsection{Hardware Requirements for Android}

\begin{frame}
  \frametitle{SoC requirements}
  \begin{itemize}
  \item Since Android in itself is quite huge, the hardware required
    is quite different.
  \item First, the only architecture officially supported by Google is
    ARMv7 (basically, all the SoCs based on the Cortex-A). The CPU has
    to be powerful enough as well (the typical setup on recent
    releases is a dual-core CPUs running at more than 1GHz
    \begin{itemize}
    \item Other architectures like x86 and MIPS are supported by
      third-party ports
    \end{itemize}
  \item You also need to have a powerful enough GPU with OpenGL ES
    support. Latest versions of Android require the 3D hardware
    acceleration
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Storage and RAM needed}
  \begin{itemize}
  \item The required RAM size is also quite huge, 340MB are required
    for the kernel and userspace memory
  \item Required storage is quite huge as well. An image of the system
    is around 200-300MB, and you must have 350MB of data space for the
    user plus 1GB of shared storage for the applications. Google
    recommends to use block devices for storage and not flash devices.
  \item The shared space has to be accessible from a host computer by
    some way, like NFS, USB Mass Storage, MTP, etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{External Peripherals 1/2}
  \begin{itemize}
  \item No form of communication supported is mandatory, but you need
    at least one form of data networking with a throughput of at least
    200 kbit per second.
  \item You will also need obviously a rather large screen with a
    pointer device, presumably a touchscreen.
  \item Screens supported must have a screen size of at least 2.5
    inches, with a minimal resolution of 426x320, with a ratio between
    4:3 and 16:9 and with a color depth of at least 16bits.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{External Peripherals 2/2}
  \begin{itemize}
  \item Sensors are not mandatory, but depending of the class of
    sensors, they are:
    \begin{itemize}
    \item Recommended
      \begin{itemize}
      \item Accelerometer
      \item Magnetometer
      \item GPS
      \item Gyroscope
      \end{itemize}
    \item Optional
      \begin{itemize}
      \item Barometer
      \item Photometer
      \item Proximity Sensor
      \end{itemize}
    \item Deprecated
      \begin{itemize}
      \item Thermometer (and only to measure CPU temperature)
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Unusual Android Devices: Nook E-Book Reader}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/nook.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Unusual Android Devices: Watch}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/moto-watch.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Unusual Android Devices: Portable Console}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/odroid.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Unusual Android Devices: Microwave Oven}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/maid-oven.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Unusual Android Devices: Treadmill}
  \begin{center}
    \includegraphics[width=\textwidth,height=0.7\textheight,keepaspectratio]{common/nordicktrack-treadmill.jpg}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{When to choose Android}
  \begin{itemize}
  \item All of the requirements listed above are only if you want to
    be eligible to the Android Play Store
  \item If you don't want to get the store, you can obviously ignore
    these
  \item However, Android really makes sense in a system that has at
    least:
    \begin{itemize}
    \item A large screen
    \item A powerful SoC, with plenty of RAM, storage space (around
      512MB) and a decent GPU
    \end{itemize}
  \item This is not an advisable choice when you want to build a
    headless system, or a cheap system with limited resources
  \item In this case, a regular Linux system is definitely more
    appropriate. It will save you engineering costs, reduce the price
    of your hardware, and bring the same set of features you could
    expect from a headless Android
  \end{itemize}
\end{frame}

\section{Android Source Code and Compilation}
\subsection{How to get the source code}
\begin{frame}
  \frametitle{Source Code Location}
  \begin{itemize}
  \item The AOSP project is available at
    \url{http://source.android.com}
  \item On this site, along with the code, you will find some resources
    such as technical details, how to setup a machine to build
    Android, etc.
  \item The source code is split into several Git repositories for
    version control. But as there is a lot of source code, a single
    Git repository would have been really slow
  \item Google split the source code into a one Git repository per
    component
  \item You can easily browse these git repositories using
    \url{https://code.google.com/p/android-source-browsing/source/browse/}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Repo}
  \begin{itemize}
  \item This makes hundreds of Git repositories\!
  \item To avoid making it too painful, Google also created a tool:
    \code{repo}
  \item Repo aggregates these Git repositories into a single folder
    from a manifest file describing how to find these and how to put
    them together
  \item Also aggregates some common Git commands such as \code{diff}
    or \code{status} that are run across all the Git repositories
  \item You can also execute a shell command in each repository
    managed by Repo using the \code{repo forall} command
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Source code licenses}
  \begin{itemize}
  \item Mostly two kind of licenses:
    \begin{itemize}
    \item GPL/LGPL Code: Linux, D-Bus, BlueZ
    \item Apache/BSD: All the rest
    \item In the \code{external} folder, it depends on the component,
      but mostly GPL
    \end{itemize}
  \item While you might expect Google's apps for Android, like the
    Android Market (now called Google Play Store), to be in the AOSP
    as well, these are actually proprietary and you need to be
    approved by Google to get them.
  \end{itemize}
\end{frame}

\subsection{Compilation}
\begin{frame}
  \frametitle{Android Compilation Process}
  \begin{itemize}
  \item Android's build system relies on the well-tried GNU/Make
    software
  \item Android is using a ``product'' notion which corresponds to the
    specifications of a shipping product, i.e. \textit{crespo} for the
    Google Nexus S vs \textit{crespo4g} for the Sprint's Nexus S with
    LTE support
  \item To start using the build system, you need to include the file
    \path{build/envsetup.sh} that defines some useful macros for
    Android development or sets the \code{PATH} variable to include the
    Android-specific commands
  \item \code{source build/envsetup.sh}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Prepare the process}
  \begin{itemize}
  \item Now, we can get a list of all the products available and
    select them with to the \code{lunch} command
  \item \code{lunch} will also ask for a build variant, to choose
    between \code{eng}, \code{user} and \code{userdebug}, which
    corresponds to which kind of build we want, and which packages it
    will add
  \item You can also select variants by passing directly the combo
    \code{product-variant} as argument to \code{lunch}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Compilation}
  \begin{itemize}
  \item You can now start the compilation just by running \code{make}
  \item This will run a full build for the current selected product
  \item There are lots of other build commands:
    \begin{description}
    \item[make $<$package$>$] Builds only the package, instead of
      going through the entire build
    \item[make clean] Cleans all the files generated by previous
      compilations
    \item[make clean-$<$package$>$] Removes all the files generated by
      the compilation of the given package
    \item[mm] Builds all the modules in the current directory
    \item[mmm $<$directory$>$] builds all the modules in the given
      directory
    \end{description}
  \end{itemize}
\end{frame}

\subsection{Contribute}
\begin{frame}
  \frametitle{Gerrit}
  \begin{itemize}
  \item Google also developed for the Android development process a
    tool to manage projects and ease code reviews.
  \item It once again uses Git to do so and Repo is also built around
    it so that you can easily contribute to Android
  \item To do so, start a new branch with \code{repo start <branchname>}
  \item Do your usual commits with Git
  \item When you are done, upload to Gerrit using \code{repo upload}
  \end{itemize}
\end{frame}

\section{Linux kernel introduction}
\begin{frame}
  \frametitle{Linux kernel in the system}
  \begin{center}
    \includegraphics[width=\textwidth]{common/linux-kernel-in-system.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{History}
  \begin{itemize}
  \item The Linux kernel is one component of a system, which also
    requires libraries and applications to provide features to end
    users.
  \item The Linux kernel was created as a hobby in 1991 by a Finnish
    student, Linus Torvalds.
    \begin{itemize}
    \item Linux quickly started to be used as the kernel for free
      software operating systems
    \end{itemize}
  \item Linus Torvalds has been able to create a large and dynamic
    developer and user community around Linux.
  \item Nowadays, hundreds of people contribute to each kernel
    release, individuals or companies big and small.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Linux license}
  \begin{itemize}
  \item The whole Linux sources are Free Software released under the
    GNU General Public License version 2 (GPL v2).
  \item For the Linux kernel, this basically implies that:
    \begin{itemize}
    \item When you receive or buy a device with Linux on it, you
      should receive the Linux sources, with the right to study,
      modify and redistribute them.
    \item When you produce Linux based devices, you must release the
      sources to the recipient, with the same rights, with no
      restriction..
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Linux kernel key features}
  \begin{columns}
    \column{0.5\textwidth}
    \begin{itemize}
    \item Portability and hardware support. Runs on most
      architectures.
    \item Scalability. Can run on super computers as well as on tiny
      devices (4 MB of RAM is enough).
    \item Compliance to standards and interoperability.
    \item Exhaustive networking support.
    \end{itemize}
    \column{0.5\textwidth}
    \begin{itemize}
    \item Security. It can't hide its flaws. Its code is reviewed by
      many experts.
    \item Stability and reliability.
    \item Modularity. Can include only what a system needs even at run
      time.
    \item Easy to program. You can learn from existing code. Many
      useful resources on the net.
    \end{itemize}
  \end{columns}
\end{frame}

\begin{frame}
  \frametitle{Supported hardware architectures}
  \begin{itemize}
  \item See the \code{arch/} directory in the kernel sources
  \item Minimum: 32 bit processors, with or without MMU, and
    \code{gcc} support
  \item 32 bit architectures (\code{arch/} subdirectories)\\
    Examples: \code{arm, avr32, blackfin, m68k, microblaze, mips, score, sparc, um}
  \item 64 bit architectures:\\
    Examples: \code{alpha, arm64, ia64, sparc64, tile}
  \item 32/64 bit architectures\\
    Examples: \code{powerpc, x86, sh}
  \item Find details in kernel sources: \code{arch/<arch>/Kconfig},
    \code{arch/<arch>/README}, or \code{Documentation/<arch>/}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{System calls}
  \begin{itemize}
  \item The main interface between the kernel and userspace is the set
    of system calls
  \item About ~300 system calls that provide the main kernel services
    \begin{itemize}
    \item File and device operations, networking operations,
      inter-process communication, process management, memory mapping,
      timers, threads, synchronization primitives, etc.
    \end{itemize}
  \item This interface is stable over time: only new system calls can
    be added by the kernel developers
  \item This system call interface is wrapped by the C library, and
    userspace applications usually never make a system call directly
    but rather use the corresponding C library function
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Virtual filesystems}
  \begin{itemize}
  \item Linux makes system and kernel information available in
    user-space through virtual filesystems.
  \item Virtual filesystems allow applications to see directories and
    files that do not exist on any real storage: they are created on the
    fly by the kernel
  \item The two most important virtual filesystems are
    \begin{itemize}
    \item \code{proc}, usually mounted on \code{/proc}: \\
      Operating system related information (processes, memory
      management parameters...)
    \item \code{sysfs}, usually mounted on \code{/sys}: \\
       Representation of the system as a set of
       devices and buses. Information about these devices.
    \end{itemize}
  \end{itemize}
\end{frame}

\section[The Android Kernel]{Changes introduced in the Android Kernel}
\subsection{Wakelocks}
\begin{frame}
  \frametitle{Power management basics}
  \begin{itemize}
  \item Every CPU has a few states of power consumption, from being
    almost completely off, to working at full capacity.
  \item These different states are used by the Linux kernel to save
    power when the system is run
  \item For example, when the lid is closed on a laptop, it goes into
    ``suspend'', which is the most power conservative mode of a
    device, where almost nothing but the RAM is kept awake
  \item While this is a good strategy for a laptop, it is not
    necessarily good for mobile devices
  \item For example, you don't want your music to be turned off when
    the screen is
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Wakelocks}
  \begin{itemize}
  \item Android's answer to these power management constraints is wakelocks
  \item One of the most famous Android changes, because of the
    flame wars it spawned
  \item The main idea is instead of letting the user decide when
    the devices need to go to sleep, the kernel is set to suspend as
    soon and as often as possible. 
  \item In the same time, Android allows applications and kernel
    drivers to voluntarily prevent the system from going to suspend,
    keeping it awake (thus the name wakelock)
  \item This implies to write the applications and drivers to use the
    wakelock API.
    \begin{itemize}
    \item Applications do so through the abstraction provided by the
      API
    \item Drivers must do it themselves, which prevents to directly
      submit them to the vanilla kernel
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Wakelocks API}
  \begin{itemize}
  \item Kernel Space API
\begin{minted}[fontsize=\footnotesize]{c}
#include <linux/wakelock.h>
void wake_lock_init(struct wakelock *lock,
                    int type,
                    const char *name);
void wake_lock(struct wake_lock *lock);
void wake_unlock(struct wake_lock *lock);
void wake_lock_timeout(struct wake_lock *lock, long timeout);
void wake_lock_destroy(struct wake_lock *lock);
\end{minted}
  \item User-Space API
\begin{minted}[fontsize=\footnotesize]{console}
$ echo foobar > /sys/power/wake_lock
$ echo foobar > /sys/power/wake_unlock
\end{minted}
\end{itemize}
\end{frame}

\subsection{Binder}
\begin{frame}
  \frametitle{Binder}
  \begin{itemize}
  \item RPC/IPC mechanism
  \item Takes its roots from BeOS and the OpenBinder project, which
    some of the current Android engineers worked on
  \item Adds remote object invocation capabilities to the Linux Kernel
  \item One of the very basic functionalities of Android. Without it,
    Android cannot work.
  \item Every call to the system servers go through Binder, just like
    every communication between applications, and even communication
    between the components of a single application.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Binder}
  \begin{center}
    \includegraphics[width=\textwidth]{common/binder.pdf}
  \end{center}
\end{frame}

\subsection{klogger}
\begin{frame}
  \frametitle{Logging}
  \begin{itemize}
  \item Logs are very important to debug a system, either live
    or after a fault occurred
  \item In a regular Linux distribution, two components are involved
    in the system's logging:
    \begin{itemize}
    \item Linux' internal mechanism, accessible with the \code{dmesg}
      command and holding the output of all the calls to \code{printk()} from
      various parts of the kernel.
    \item A syslog daemon, which handles the userspace logs and
      usually stores them in the \path{/var/log} directory
    \end{itemize}
  \item From Android developers' point of view, this approach has two flaws:
    \begin{itemize}
    \item As the calls to \code{syslog()} go through as socket, they generate
      expensive task switches
    \item Every call writes to a file, which probably writes to a
      slow storage device or to a storage device where writes are expensive
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Logger}
  \begin{itemize}
  \item Android addresses these issues with \textit{logger}, which is
    a kernel driver, that uses 4 circular buffers in the kernel memory
    area.
  \item The buffers are exposed in the \path{/dev/log} directory and you can
    access them through the \textit{liblog} library, which is in turn, used by
    the Android system and applications to write to logger, and by
    the \textit{logcat} command to access them.
  \item This allows to have an extensive level of logging across the
    entire AOSP
  \end{itemize}
\end{frame}

\subsection{Anonymous Shared Memory (ashmem)}
\begin{frame}
  \frametitle{Shared memory mechanism in Linux}
  \begin{itemize}
  \item Shared memory is one of the standard IPC mechanisms present in most OSes
  \item Under Linux, they are usually provided by the POSIX SHM
    mechanism, which is part of the System V IPCs
  \item \path{ndk/docs/system/libc/SYSV-IPC.html} illustrates all the
    love Android developers have for these
  \item The bottom line is that they are flawed by design in Linux,
    and lead to code leaking resources, be it maliciously or not
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Ashmem}
  \begin{itemize}
  \item Ashmem is the response to these flaws
  \item Notable differences are:
    \begin{itemize}
    \item Reference counting so that the kernel can reclaim resources
       which are no longer in use
    \item There is also a mechanism in place to allow the kernel to
      shrink shared memory regions when the system is under memory
      pressure.
    \end{itemize}
  \item The standard use of Ashmem in Android is that a process opens
    a shared memory region and share the obtained file descriptor
    through Binder.
  \end{itemize}
\end{frame}

\subsection{Alarm Timers}
\begin{frame}
  \frametitle{The alarm driver}
  \begin{itemize}
  \item Once again, the timer mechanisms available in Linux were not
    sufficient for the power management policy that Android was trying to
    set up
  \item High Resolution Timers can wake up a process, but don't fire
    when the system is suspended, while the Real Time Clock can wake up
    the system if it is suspended, but cannot wake up a particular
    process.
  \item Developed the alarm timers on top of the Real Time Clock and
    High Resolution Timers already available in the kernel
  \item These timers will be fired even if the system is suspended,
    waking up the device to do so
  \item Obviously, to let the application do its job, when the
    application is woken up, a wakelock is grabbed
  \end{itemize}
\end{frame}

\subsection{Network Security}
\begin{frame}
  \frametitle{Paranoid Network}
  \begin{itemize}
  \item In the standard Linux kernel, every application can open
    sockets and communicate over the Network
  \item However, Google was willing to apply a more strict policy with
    regard to network access
  \item Access to the network is a permission, with a per application
    granularity
  \item Filtered with the GID
  \item You need it to access IP, Bluetooth, raw sockets or RFCOMM
  \end{itemize}
\end{frame}

\subsection{Low Memory Killer}
\begin{frame}
  \frametitle{Low Memory Killer}
  \begin{itemize}
  \item When the system goes out of memory, Linux throws the OOM
    Killer to cleanup memory greedy processes
  \item However, this behavior is not predictable at all, and can
    kill very important components of a phone (Telephony stack,
    Graphic subsystem, etc) instead of low priority processes (Angry Birds)
  \item The main idea is to have another process killer, that kicks in
    before the OOM Killer and takes into account the time since the
    application was last used and the priority of the component
    for the system
  \item It uses various thresholds, so that it first notifies
    applications so that they can save their state, then begins to kill
    non-critical background processes, and then the foreground
    applications
  \item As it is run to free memory before the OOM Killer, the latter
    will never be run, as the system will never run out of memory
  \end{itemize}
\end{frame}

\subsection{Various Drivers and Fixes}
\begin{frame}
  \frametitle{Various additions}
  \begin{itemize}
  \item Android also has a lot of minor features added to the Linux
    kernel:
    \begin{itemize}
    \item RAM Console, a RAM-based console that survives a reboot to
      hold kernel logs
    \item \textit{pmem}, a physically contiguous memory allocator, written
      specifically for the HTC G1, to allocate heaps used for 2D
      hardware acceleration
    \item ADB
    \item YAFFS2
    \item Timed GPIOs
    \end{itemize}
  \end{itemize}
\end{frame}

\section{Android Filesystem}
\subsection{Principle and solutions}
\begin{frame}
  \frametitle{Filesystems}
  \begin{itemize}
  \item Filesystems are used to organize data in directories and files
    on storage devices or on the network. The directories and files
    are organized as a hierarchy
  \item In Unix systems, applications and users see a {\bf single
      global hierarchy} of files and directories, which can be
    composed of several filesystems.
  \item Filesystems are {\bf mounted} in a specific location in this
    hierarchy of directories
    \begin{itemize}
    \item When a filesystem is mounted in a directory (called {\em
        mount point}), the contents of this directory reflects the
      contents of the storage device
    \item When the filesystem is unmounted, the {\em mount point} is
      empty again.
    \end{itemize}
  \item This allows applications to access files and directories easily,
    regardless of their exact storage location
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Filesystems (2)}
  \begin{itemize}
  \item Create a mount point, which is just a directory\\
    \code{$ mkdir /mnt/usbkey}
  \item It is empty\\
    \code{$ ls /mnt/usbkey}\\
    \code{$}
  \item Mount a storage device in this mount point\\
    \code{$ mount -t vfat /dev/sda1 /mnt/usbkey}\\
    \code{$}
  \item You can access the contents of the USB key\\
    \code{$ ls /mnt/usbkey}\\
    \code{docs prog.c picture.png movie.avi}\\
    \code{$}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{mount / umount}
  \begin{itemize}
  \item \code{mount} allows to mount filesystems
    \begin{itemize}
    \item \code{mount -t type device mountpoint}
    \item \code{type} is the type of filesystem
    \item \code{device} is the storage device, or network location to
      mount
    \item \code{mountpoint} is the directory where files of the
      storage device or network location will be accessible
    \item \code{mount} with no arguments shows the currently mounted
      filesystems
    \end{itemize}
  \item \code{umount} allows to unmount filesystems
    \begin{itemize}
    \item This is needed before rebooting, or before unplugging a USB
      key, because the Linux kernel caches writes in memory to
      increase performances. umount makes sure that those writes are
      committed to the storage.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Root filesystem}
  \begin{itemize}
  \item A particular filesystem is mounted at the root of the hierarchy,
    identified by \code{/}
  \item This filesystem is called the {\bf root filesystem}
  \item As \code{mount} and \code{umount} are programs, they are files
    inside a filesystem.
    \begin{itemize}
    \item They are not accessible before mounting at least one filesystem.
    \end{itemize}
  \item As the root filesystem is the first mounted filesystem, it
    cannot be mounted with the normal \code{mount} command
  \item It is mounted directly by the kernel, according to the
    \code{root=} kernel option
  \item When no root filesystem is available, the kernel panics\\
    \tiny
\begin{verbatim}
Please append a correct "root=" boot option
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)
\end{verbatim}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Location of the root filesystem}
  \begin{itemize}
  \item It can be mounted from different locations
    \begin{itemize}
    \item From the partition of a hard disk
    \item From the partition of a USB key
    \item From the partition of an SD card
    \item From the partition of a NAND flash chip or similar type of
      storage device
    \item From the network, using the NFS protocol
    \item From memory, using a pre-loaded filesystem (by the
      bootloader)
    \item etc.
    \end{itemize}
  \item It is up to the system designer to choose the configuration
    for the system, and configure the kernel behavior with
    \code{root=}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Mounting rootfs from storage devices}
  \begin{itemize}
  \item Partitions of a hard disk or USB key
    \begin{itemize}
    \item \code{root=/dev/sdXY}, where \code{X} is a letter indicating
      the device, and \code{Y} a number indicating the partition
    \item \code{/dev/sdb2} is the second partition of the second disk
      drive (either USB key or ATA hard drive)
    \end{itemize}
  \item Partitions of an SD card
    \begin{itemize}
    \item \code{root=/dev/mmcblkXpY}, where \code{X} is a number
      indicating the device and \code{Y} a number indicating the
      partition
    \item \code{/dev/mmcblk0p2} is the second partition of the first
      device
    \end{itemize}
  \item Partitions of flash storage
    \begin{itemize}
    \item \code{root=/dev/mtdblockX}, where \code{X} is the partition number
    \item \code{/dev/mtdblock3} is the fourth partition of a NAND
      flash chip (if only one NAND flash chip is present)
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{rootfs in memory: initramfs (1)}
  \begin{itemize}
  \item It is also possible to have the root filesystem integrated
    into the kernel image
  \item It is therefore loaded into memory together with the kernel
  \item This mechanism is called {\bf initramfs}
    \begin{itemize}
    \item It integrates a compressed archive of the filesystem into
      the kernel image
    \end{itemize}
  \item It is useful for two cases
    \begin{itemize}
    \item Fast booting of very small root filesystems. As the
      filesystem is completely loaded at boot time, application
      startup is very fast.
    \item As an intermediate step before switching to a real root
      filesystem, located on devices for which drivers not part of the
      kernel image are needed (storage drivers, filesystem drivers,
      network drivers). This is always used on the kernel of
      desktop/server distributions to keep the kernel image size
      reasonable.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{rootfs in memory: initramfs (2)}
  \begin{center}
    \includegraphics[width=0.9\textwidth]{common/initramfs.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{rootfs in memory: initramfs (3)}
  \begin{itemize}
  \item The contents of an initramfs are defined at the kernel
    configuration level, with the \code{CONFIG_INITRAMFS_SOURCE}
    option
    \begin{itemize}
    \item Can be the path to a directory containing the root
      filesystem contents
    \item Can be the path to a cpio archive
    \item Can be a text file describing the contents of the initramfs
      (see documentation for details)
    \end{itemize}
  \item The kernel build process will automatically take the contents
    of the \code{CONFIG_INITRAMFS_SOURCE} option and integrate the
    root filesystem into the kernel image
  \item \code{filesystems/ramfs-rootfs-initramfs.txt} and
    \code{early-userspace/README}
  \end{itemize}
\end{frame}

\subsection{Contents}
\begin{frame}
  \frametitle{Filesystem organization on GNU/Linux}
  \begin{itemize}
  \item On most Linux based distributions, the filesystem layout is
    defined by the Filesystem Hierarchy Standard
  \item The FHS defines the main directories and their contents
    \begin{description}
    \item[/bin] Essential command binaries
    \item[/boot] Bootloader files, i.e. kernel common and related stuff
    \item[/etc] Host-specific system-wide configuration files.
    \end{description}
  \item Android follows an orthogonal path, storing its files in
    folders not present in the FHS, or following it when it uses a
    defined folder
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Filesystem organization on Android}
  \begin{itemize}
  \item Instead, the two main directories used by Android are
    \begin{description}
    \item[/system] Immutable directory coming from the original
      build. It contains native binaries and libraries, framework jar
      files, configuration files, standard apps,  etc.
    \item[/data] is where all the changing content of the system are put:
      apps, data added by the user, data generated by all the apps at
      runtime, etc.
    \end{description}
  \item These two directories are usually mounted on separate
    partitions, from the root filesystem originating from a kernel
    RAM disk.
  \item Android also uses some usual suspects: \path{/proc},
    \path{/dev}, \path{/sys}, \path{/etc}, \path{sbin}, \path{/mnt}
    where they serve the same function they usually do
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{/system}
  \begin{description}
  \item[./app] All the pre-installed apps
  \item[./bin] Binaries installed on the system (toolbox, vold,
    surfaceflinger)
  \item[./etc] Configuration files
  \item[./fonts] Fonts installed on the system
  \item[./framework] Jar files for the framework
  \item[./lib] Shared objects for the system libraries
  \item[./modules] Kernel modules
  \item[./xbin] External binaries
  \end{description}
\end{frame}

\begin{frame}
  \frametitle{Other directories}
  \begin{itemize}
  \item Like we said earlier, Android most of the time either uses
    directories not in the FHS, or directories with the exact same purpose as in
    standard Linux distributions (\code{/dev}, \code{/proc}), therefore avoiding collisions.
    \code{/sys})
  \item There is some collision though, for \code{/etc} and
    \code{/sbin}, which are hopefully trimmed down
  \item This allows to have a full Linux distribution side by side
    with Android with only minor tweaks
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{android\_filesystem\_config.h}
  \begin{itemize}
  \item Located in \code{system/core/include/private/}
  \item Contains the full filesystem setup, and is written as a
    C header
    \begin{itemize}
    \item UID/GID
    \item Permissions for system directories
    \item Permissions for system files
    \end{itemize}
  \item Processed at compilation time to enforce the permissions throughout
    the filesystem
  \item Useful in other parts of the framework as well, such as ADB
  \end{itemize}
\end{frame}

\subsection{Virtual Filesystems}
\begin{frame}
  \frametitle{proc virtual filesystem}
  \begin{itemize}
  \item The \code{proc} virtual filesystem exists since the beginning of
    Linux
  \item It allows
    \begin{itemize}
    \item The kernel to expose statistics about running processes in
      the system
    \item The user to adjust at runtime various system parameters
      about process management, memory management, etc.
    \end{itemize}
  \item The \code{proc} filesystem is used by many standard userspace
    applications, and they expect it to be mounted in \code{/proc}
  \item Applications such as \code{ps} or \code{top} would not work
    without the \code{proc} filesystem
  \item Command to mount \code{/proc}:\\
    \code{mount -t proc nodev /proc}
  \item \code{filesystems/proc.txt} in the kernel sources
  \item \code{man proc}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{proc contents}
  \begin{itemize}
  \item One directory for each running process in the system
    \begin{itemize}
    \item \code{/proc/<pid>}
    \item \code{cat /proc/3840/cmdline}
    \item It contains details about the files opened by the process,
      the CPU and memory usage, etc.
    \end{itemize}
  \item \code{/proc/interrupts}, \code{/proc/devices},
    \code{/proc/iomem}, \code{/proc/ioports} contain general
    device-related information
  \item \code{/proc/cmdline} contains the kernel command line
  \item \code{/proc/sys} contains many files that can be written to to
    adjust kernel parameters
    \begin{itemize}
    \item They are called {\em sysctl}. See \code{/latest/sysctl/}
      in kernel sources.
    \item Example\\
      \code{echo 3 > /proc/sys/vm/drop_caches}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{sysfs filesystem}
  \begin{itemize}
  \item The \code{sysfs} filesystem is a feature integrated in the 2.6
    Linux kernel
  \item It allows to represent in userspace the vision that the kernel
    has of the buses, devices and drivers in the system
  \item It is useful for various userspace applications that need to
    list and query the available hardware, for example udev or mdev
  \item All applications using sysfs expect it to be mounted in the
    \code{/sys} directory
  \item Command to mount \code{/sys}:\\
    \code{mount -t sysfs nodev /sys}
  \item
\begin{verbatim}
$ ls /sys/
block bus class dev devices firmware
fs kernel modulepower
\end{verbatim}
  \end{itemize}
\end{frame}

\subsection{Minimal filesystem}
\begin{frame}
  \frametitle{Basic applications}
  \begin{itemize}
  \item In order to work, a Linux system needs at least a few
    applications
  \item An \code{init} application, which is the first userspace
    application started by the kernel after mounting the root
    filesystem
    \begin{itemize}
    \item The kernel tries to run \code{/sbin/init}, \code{/bin/init},
      \code{/etc/init} and \code{/bin/sh}.
    \item If none of them are found, the kernel panics and the boot
      process is stopped.
    \item The init application is responsible for starting all other
      userspace applications and services
    \end{itemize}
  \item Usually a shell, to allow a user to interact with the system
  \item Basic Unix applications, to copy files, move files, list files
    (commands like \code{mv}, \code{cp}, \code{mkdir}, \code{cat},
    etc.)
  \item Those basic components have to be integrated into the root
    filesystem to make it usable
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Overall booting process}
  \begin{center}
    \includegraphics[width=0.7\textwidth]{common/overall-boot-sequence.pdf}
  \end{center}
\end{frame}

\section{Android Build System}
\subsection{Basics}
\begin{frame}
  \frametitle{Build Systems}
  \begin{itemize}
  \item Build systems are designed to meet several goals:
    \begin{itemize}
    \item Integrate all the software components, both third-party and
      in-house into a working image
    \item Be able to easily reproduce a given build
    \end{itemize}
  \item Usually, they build software using the existing building system shipped with
    each component
  \item Several solutions: \emph{Yocto}, \emph{Buildroot},
    \emph{ptxdist}.
  \item Google came up with its own solution for Android, that never relies on
    other build systems, except for \emph{GNU/Make}
    \begin{itemize}
    \item It allows to rely on very few tools, and to
      control every software component in a consistent way.
    \item But it also means that when you have to import a new
      component, you have to rewrite the whole Makefile to build it
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{First compilation}
\begin{minted}{console}
$ source build/envsetup.sh
$ lunch
You're building on Linux

Lunch menu... pick a combo:
     1. generic-eng
     2. simulator
     3. full_passion-userdebug
     4. full_crespo-userdebug

Which would you like? [generic-eng]
$ make
$ make showcommands
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Output}
  \begin{itemize}
  \item All the output is generated in the
    \code{out/} directory, outside of the source code directory 
  \item This directory contains mostly two subdirectories:
    \code{host/} and \code{target/}
  \item These directories contain all the objects files compiled
    during the build process: \code{.o} files for C/C++ code,
    \code{.jar} files for Java libraries, etc
  \item It is an interesting feature, since it keeps all the generated
    stuff separate from the source code, and we can easily clean without
    side effects
  \item It also generates the system images in the
    \code{out/target/product/<product_name>/} directory
  \item \code{make clean} only deletes that \code{out} directory
  \end{itemize}
\end{frame}

\subsection{Add a New Module}
\begin{frame}
  \frametitle{Modules}
  \begin{itemize}
  \item Every component in Android is called a \emph{module}
  \item Modules are defined across the entire tree through the
    \code{Android.mk} files
  \item The build system abstracts many details to make the
    creation of a module's Makefile as trivial as possible
  \item Of course, building a module that will be an Android
    application and building a static library will not require the same
    instructions, but these builds don't differ that much either.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Hello World}
\begin{minted}{make}
LOCAL_PATH = $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES = hello_world.c
LOCAL_MODULE = HelloWorld

LOCAL_MODULE_TAGS = optional

include $(BUILD_EXECUTABLE)
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Hello World}
  \begin{itemize}
  \item Every module variable is prefixed by \code{LOCAL_*}
  \item \code{LOCAL_PATH} tells the build system where the current
    module is
  \item \code{include $(CLEAR_VARS)} cleans the previously declared
    \code{LOCAL_*} variables. This way, we make sure we won't have
    anything weird coming from other modules. The list of the
    variables cleared is in \code{build/core/clear_vars.mk}
  \item \code{LOCAL_SRC_FILES} contains a list of all source
    files to be compiled
  \item \code{LOCAL_MODULE} sets the module name
  \item \code{LOCAL_MODULE_TAGS} defines the set of modules this module
    should belong to
  \item \code{include $(BUILD_EXECUTABLE)} tells the build system to
    build this module as a binary
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Tags}
  \begin{itemize}
  \item Tags are used to define several sets of modules to be
    built through the build variant selected by \code{lunch}
  \item We have 3 build variants:
    \begin{itemize}
    \item \code{user}
      \begin{itemize}
      \item Installs modules tagged with \code{user}
      \item Installs non-packaged modules that have no tags specified
      \item ADB is disabled by default
      \end{itemize}
    \item \code{userdebug} is \code{user} plus
      \begin{itemize}
      \item Installs modules tagged with \code{debug}
      \item ADB is enabled by default
      \end{itemize}
    \item \code{eng} is \code{userdebug}, plus
      \begin{itemize}
      \item Installs modules tagged as \code{eng} and
        \code{development}
      \item \code{ro.kernel.android.checkjni = 1}
      \end{itemize}
    \end{itemize}
  \item Finally, we have a fourth tag, \code{optional}, that will never
    be directly integrated by a build variant, but deprecates \code{user}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Make and clean a module}
  \begin{itemize}
  \item To build a module from the top directory, just do
    \code{make ModuleName}
  \item However, building a simple module won't regenerate a new image.
    This is just useful to make sure that the module builds.
    You will have to do a full \code{make} to have an image that contains
    your module
  \item Actually, a full \code{make} will build your module at some
    point, but you won't find it in your generated image if it is
    tagged as optional
  \item If you want to enable it for all builds, add its name to the
    \code{PRODUCT_PACKAGES} variables in the
    \code{build/target/product/core.mk} file.
  \item You can also get the list of the modules to be built with the
    \code{make modules} target
  \end{itemize}
\end{frame}

\subsection{Add a New Product}
\begin{frame}
  \frametitle{Defining new products}
  \begin{itemize}
  \item Devices are well supported by the Android build system. It allows
    to build multiple devices with the same source tree, to have a
    per-device configuration, etc.
  \item All the product definitions should be put in
    \code{device/<company>/<device>}
  \item The entry point is the \code{AndroidProducts.mk} file, which
    should define the \code{PRODUCT_MAKEFILES} variable
  \item This variable defines where the actual product definitions are
    located.
  \item It follows such an architecture because you can have several
    products using the same device
  \item If you want your product to appear in the \code{lunch} menu, you need
    to create a \code{vendorsetup.sh} file in the \code{device} directory,
    with the right calls to \code{add_lunch_combo}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Product, devices and boards}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/product-definition.pdf}
  \end{center}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Minimal Product Declaration}
\begin{minted}[fontsize=\small]{make}
$(call inherit-product, build/target/product/generic.mk)

PRODUCT_NAME := full_MyDevice
PRODUCT_DEVICE := MyDevice
PRODUCT_MODEL := Full flavor of My Brand New Device
\end{minted}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Copy files to the target}
\begin{minted}[fontsize=\small]{make}
$(call inherit-product, build/target/product/generic.mk)

PRODUCT_COPY_FILES += \
  device/mybrand/mydevice/vold.fstab:system/etc/vold.fstab

PRODUCT_NAME := full_MyDevice
PRODUCT_DEVICE := MyDevice
PRODUCT_MODEL := Full flavor of My Brand New Device
\end{minted}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Add a package to the build for this product}
\begin{minted}[fontsize=\small]{make}
$(call inherit-product, build/target/product/generic.mk)

PRODUCT_PACKAGES += FooBar

PRODUCT_COPY_FILES += \
  device/mybrand/mydevice/vold.fstab:system/etc/vold.fstab

PRODUCT_NAME := full_mydevice
PRODUCT_DEVICE := mydevice
PRODUCT_MODEL := Full flavor of My Brand New Device
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Overlays}
  \begin{itemize}
  \item This is a mechanism used by products to override resources
    already defined in the source tree, without modifying the original
    code
  \item This is used for example to change the wallpaper for one
    particular device
  \item Use the \code{DEVICE_PACKAGE_OVERLAYS} or
    \code{PRODUCT_PACKAGE_OVERLAYS} variables that you set to a path
    to a directory in your device folder
  \item This directory should contain a structure similar to the
    source tree one, with only the files that you want to override
  \end{itemize}
\end{frame}


\begin{frame}[fragile]
  \frametitle{Add a package to the build for this product}
\begin{minted}[fontsize=\small]{make}
$(call inherit-product, build/target/product/generic.mk)

PRODUCT_PACKAGES += FooBar

PRODUCT_COPY_FILES += \
  device/mybrand/mydevice/vold.fstab:system/etc/vold.fstab

DEVICE_PACKAGE_OVERLAYS := device/mybrand/mydevice/overlay

PRODUCT_NAME := full_mydevice
PRODUCT_DEVICE := mydevice
PRODUCT_MODEL := Full flavor of My Brand New Device
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Board Definition}
  \begin{itemize}
  \item You will also need a \code{BoardConfig.mk} file along with the
    product definition
  \item While the product definition was mostly about the build system
    in itself, the board definition is more about the hardware
  \item You can have a full working example in
    \code{device/samsung/crespo/BoardConfigCommon.mk}
  \item However, this is poorly documented and sometimes ambiguous so
    you will probably have to dig into the \code{build/core/Makefile}
    at some point to see what a given variable does
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Minimal Board Definition}
\begin{minted}{make}
TARGET_NO_BOOTLOADER := true
TARGET_NO_KERNEL := true
TARGET_CPU_ABI := armeabi
HAVE_HTC_AUDIO_DRIVER := true
BOARD_USES_GENERIC_AUDIO := true

USE_CAMERA_STUB := true
\end{minted}
\end{frame}

\section{Android Native Layer}
\subsection{Bionic}
\begin{frame}
  \frametitle{Bionic}
  \begin{itemize}
  \item Google developed another C library for Android:
    \code{Bionic}. They didn't start from scratch however, they
    based their work on the BSD standard C library.
  \item The most remarkable thing about Bionic is that it doesn't have
    full support for the POSIX API, so it might be a hurdle when porting an
    already developed program to Android.
  \item However, Bionic has been created this way for a number of
    reasons
    \begin{itemize}
    \item Keep the libc implementation as simple as possible, so that
      it can be fast and lightweight (Bionic is a bit smaller than
      uClibc)
    \item Keep the (L)GPL code out of the userspace. Bionic is under
      the BSD license
    \end{itemize}
  \item And it implements some Android-specifics functions as well:
    \begin{itemize}
    \item Access to system properties
    \item Logging events in the system logs
    \end{itemize}
  \item In the \code{prebuilt/} directory, Google provides a prebuilt toolchain
    that uses Bionic
  \end{itemize}
\end{frame}

\subsection{Toolbox}
\begin{frame}
  \frametitle{Why Toolbox?}
  \begin{itemize}
  \item A Linux system needs a basic set of programs to work
    \begin{itemize}
    \item An init program
    \item A shell
    \item Various basic utilities for file manipulation and system
      configuration
    \end{itemize}
  \item In normal Linux systems, those programs are provided by
    different projects
    \begin{itemize}
    \item \code{coreutils}, \code{bash}, \code{grep}, \code{sed},
      \code{tar}, \code{wget}, \code{modutils}, etc. are all different
      projects
    \item Many different components to integrate
    \item Components not designed with embedded systems constraints in
      mind: they are not very configurable and have a wide range of
      features
    \end{itemize}
  \item BusyBox is an alternative solution, extremely common on
    embedded systems
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{General purpose toolbox: BusyBox}
  \begin{itemize}
  \item Rewrite of many useful Unix command line utilities
    \begin{itemize}
    \item Integrated into a single project, which makes it easy to
      work with
    \item Designed with embedded systems in mind: highly configurable,
      no unnecessary features
    \end{itemize}
  \item All the utilities are compiled into a single executable,
    \code{/bin/busybox}
    \begin{itemize}
    \item Symbolic links to \code{/bin/busybox} are created for each
      application integrated into BusyBox
    \end{itemize}
  \item For a fairly featureful configuration, less than 500 KB
    (statically compiled with uClibc) or less than 1 MB (statically
    compiled with glibc).
  \item   \url{http://www.busybox.net/}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{BusyBox commands!}
  Commands available in BusyBox 1.13
  \begin{spacing}{0}
    \tiny
    \code{[, [[ , addgroup, adduser, adjtimex, ar, arp, arping, ash, awk, basename, bbconfig, bbsh, brctl, bunzip2, busybox, bzcat, bzip2, cal, cat, catv, chat, chattr, chcon, chgrp, chmod, chown, chpasswd, chpst, chroot, chrt, chvt, cksum, clear, cmp, comm, cp, cpio, crond, crontab, cryptpw, cttyhack, cut, date, dc, dd, deallocvt, delgroup, deluser, depmod, devfsd, df, dhcprelay, diff, dirname, dmesg, dnsd, dos2unix, dpkg, dpkg_deb, du, dumpkmap, dumpleases, e2fsck, echo, ed, egrep, eject, env, envdir, envuidgid, ether_wake, expand, expr, fakeidentd, false, fbset, fbsplash, fdflush, fdformat, fdisk, fetchmail, fgrep, find, findfs, fold, free, freeramdisk, fsck, fsck_minix, ftpget, ftpput, fuser, getenforce, getopt, getsebool, getty, grep, gunzip, gzip, halt, hd, hdparm, head, hexdump, hostid, hostname, httpd, hush, hwclock, id, ifconfig, ifdown, ifenslave, ifup, inetd, init, inotifyd, insmod, install, ip, ipaddr, ipcalc, ipcrm, ipcs, iplink, iproute, iprule, iptunnel, kbd_mode, kill, killall, killall5, klogd, lash, last, length, less, linux32, linux64, linuxrc, ln, load_policy, loadfont, loadkmap, logger, login, logname, logread, losetup, lpd, lpq, lpr, ls, lsattr, lsmod, lzmacat, makedevs, man, matchpathcon, md5sum, mdev, mesg, microcom, mkdir, mke2fs, mkfifo, mkfs_minix, mknod, mkswap, mktemp, modprobe, more, mount, mountpoint, msh, mt, mv, nameif, nc, netstat, nice, nmeter, nohup, nslookup, od, openvt, parse, passwd, patch, pgrep, pidof, ping, ping6, pipe_progress, pivot_root, pkill, poweroff, printenv, printf, ps, pscan, pwd, raidautorun, rdate, rdev, readahead, readlink, readprofile, realpath, reboot, renice, reset, resize, restorecon, rm, rmdir, rmmod, route, rpm, rpm2cpio, rtcwake, run_parts, runcon, runlevel, runsv, runsvdir, rx, script, sed, selinuxenabled, sendmail, seq, sestatus, setarch, setconsole, setenforce, setfiles, setfont, setkeycodes, setlogcons, setsebool, setsid, setuidgid, sh, sha1sum, showkey, slattach, sleep, softlimit, sort, split, start_stop_daemon, stat, strings, stty, su, sulogin, sum, sv, svlogd, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tcpsvd, tee, telnet, telnetd, test, tftp, tftpd, time, top, touch, tr, traceroute, true, tty, ttysize, tune2fs, udhcpc, udhcpd, udpsvd, umount, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, vlock, watch, watchdog, wc, wget, which, who, whoami, xargs, yes, zcat, zcip}
  \end{spacing}
\end{frame}

\begin{frame}
  \frametitle{Toolbox}
  \begin{itemize}
  \item As Busybox is under the GPL, Google developed an equivalent
    tool, under the BSD license
  \item Much fewer UNIX commands implemented than Busybox, but other
    commands to use the Android-specifics mechanism, such as
    \code{alarm}, \code{getprop} or a modified \code{log}
  \end{itemize}
  Commands available in Toolbox in Gingerbread
  \begin{spacing}{0}
    \tiny
    \code{alarm, cat, chmod, chown, cmp, date, dd, df, dmesg, exists, getevent, getprop, hd, id, ifconfig, iftop, insmod, ioctl, ionice, kill, ln, log, ls, lsmod, lsof, mkdir, mount, mv, nandread, netstat, newfs_msdos, notify, powerd, printenv, ps, r, readtty, reboot, renice, rm, rmdir, rmmod, rotatefb, route, schedtop, sendevent, setconsole, setkey, setprop, sleep, smd, start, stop, sync, syren, top, umount, uptime, vmstat, watchprops, wipe}
  \end{spacing}
\end{frame}

\subsection{Init}
\begin{frame}
  \frametitle{Init}
  \begin{itemize}
  \item \code{init} is the name of the first userspace program
  \item It is up to the kernel to start it, with PID 1, and the
    program should never exit during system life
  \item The kernel will look for init at \code{/sbin/init},
    \code{/bin/init}, \code{/etc/init} and \code{/bin/sh}. You can
    tweak that with the \code{init=} kernel parameter
  \item The role of init is usually to start other applications at
    boot time, a shell, mount the various filesystems, etc.
  \item Init also manages the shutdown of the system by undoing all it
    has done at boot time
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android's init}
  \begin{itemize}
  \item Once again, Google has developed his own instead of relying on
    an existing one.
  \item However, it has some interesting features, as it can also be
    seen as a daemon on the system
    \begin{itemize}
    \item it manages device hotplugging, with basic
      permissions rules for device files, and actions at device plugging
      and unplugging
    \item it monitors the services it started, so that if they crash,
      it can restart them
    \item it monitors system properties so that you can take
      actions when a particular one is modified
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Init part}
  \begin{itemize}
  \item For the initialization part, init mounts the various
    filesystems (\code{/proc}, \code{/sys}, \code{data}, etc.)
  \item This allows to have an already setup environment before taking
    further actions
  \item Once this is done, it reads the \code{init.rc} file and
    executes it
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{init.rc file interpretation}
  \begin{itemize}
  \item Uses a unique syntax, based on events
  \item There usually are several init configuration files,
    \code{init.rc} itself, and \code{init.<platform_name>.rc}
  \item While \code{init.rc} is always taken into account,
    \code{init.<platform_name>.rc} is only interpreted if the platform
    currently running the system reports the same name
  \item This name is either obtained by reading the file
    \code{/proc/cpuinfo} or from the \code{androidboot.hardware}
    kernel parameter
  \item Most of the customizations should therefore go to the
    platform-specific configuration file rather than to the generic
    one
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Uevent}
  \begin{itemize}
  \item Init also manages the runtime events generated by the kernel
    when hardware is plugged in or removed, like udev does on a standard
    Linux distribution
  \item This way, it dynamically creates the devices nodes under \code{/dev}
  \item You can also tweak its behavior to add specific permissions to 
    the files associated to a new event.
  \item The associated configuration files are \code{/ueventd.rc} and
    \code{/ueventd.<platform>.rc}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Properties}
  \begin{itemize}
  \item Init also manages the system properties
  \item Properties are a way used by Android to share values across
    the system that are not changing quite often
  \item Quite similar to the Windows Registry
  \item These properties are split into several files:
    \begin{itemize}
    \item \code{/system/build.prop} which contains the properties
      generated by the build system, such as the date of compilation
    \item \code{/default.prop} which contains the default values for
      certain key properties, mostly related to the security and
      permissions for ADB.
    \item \code{/data/local.prop} which contains various properties
      specific to the device
    \item \code{/data/property} is a folder which purpose is to be
      able to edit properties at run-time and still have them at the
      next reboot. This folder is storing every properties prefixed by
      \code{persist.} in separate files containing the values.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Modifying Properties}
  \begin{itemize}
  \item You can add or modify properties in the build system by using
    either the \code{PRODUCT_PROPERTY_OVERRIDES} makefile variable, or
    by defining your own \code{system.prop} file in the device
    directory. Their content will be appended to
    \code{/system/build.prop} at compilation time
  \item Modify the \code{init.rc} file so that at boot time it exports
    these properties using the \code{setprop} command
  \item Using the API functions such as the Java function
    \code{SystemProperties.set}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Permissions on the Properties}
  \begin{itemize}
  \item Android, by default, only allows any given process to read the
    properties.
  \item You can set write permissions on a particular property or a
    group of them using the file
    \code{system/core/init/property_service.c}
  \end{itemize}
\begin{minted}[fontsize=\footnotesize]{c}
/* White list of permissions for setting property services. */
struct {
    const char *prefix;
    unsigned int uid;
    unsigned int gid;
} property_perms[] = {
    { "net.rmnet0.",      AID_RADIO,    0 },
    { "net.dns",          AID_RADIO,    0 },
    { "net.",             AID_SYSTEM,   0 },
    { "dhcp.",            AID_SYSTEM,   0 },
    { "log.",             AID_SHELL,    0 },
    { "service.adb.root", AID_SHELL,    0 },
    { "persist.security.", AID_SYSTEM,   0 },
    { NULL, 0, 0 }
};
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Special Properties}
  \begin{itemize}
  \item \code{ro.*} properties are read-only. They can be set only
    once in the system life-time. You can only change their value by
    modifying the property files and reboot.
  \item \code{persist.*} properties are stored on persistent storage
    each time they are set.
  \item \code{ctl.start} and \code{ctl.stop} properties used instead
    of storing properties to start or stop the service name passed as
    the new value
  \item \code{net.change} property holds the name of the last
    \code{net.*} property changed.
  \end{itemize}
\end{frame}

\subsection{Various daemons}
\begin{frame}
  \frametitle{Vold}
  \begin{itemize}
  \item The VOLume Daemon
  \item Just like init does, monitors new device events
  \item While init was only creating device files and taking some
    configured options, \code{vold} actually only cares about storage
    devices
  \item Its roles are to:
    \begin{itemize}
    \item Auto-mount the volumes
    \item Format the partitions on the device
    \end{itemize}
  \item There is no \code{/etc/fstab} in Android, but
    \code{/system/etc/vold.fstab} has a somewhat similar role
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{rild}
  \begin{itemize}
  \item \code{rild} is the Radio Interface Layer Daemon
  \item This daemon drives the telephony stack, both voice and data
    communication
  \item When using the voice mode, talks directly to the baseband, but
    when issuing data transfers, relies on the kernel network stack
  \item It can handle two types of commands:
    \begin{itemize}
    \item \textit{Solicited commands}: commands that originate from
      the user: dial a number, send an SMS, etc.
    \item \textit{Unsolicited commands}: commands that come from the
      baseband: receiving an SMS, a call, signal strength changed, etc.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Others}
  \begin{itemize}
  \item{netd}
    \begin{itemize}
    \item \code{netd} manages the various network connections: Bluetooth,
      Wifi, USB
    \item Also takes any associated actions: detect new
      connections, set up the tethering, etc.
    \item It really is an equivalent to NetworkManager
    \item On a security perspective, it also allows to isolate
      network-related privileges in a single process
    \end{itemize}
  \item{installd}
    \begin{itemize}
    \item Handles package installation and removal
    \item Also checks package integrity, installs the
      native libraries on the system, etc.
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{SurfaceFlinger and PixelFlinger}
\begin{frame}
  \frametitle{Introduction to graphical stacks}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/wm-architecture.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Compositing window managers}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/cwm-architecture.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{SurfaceFlinger}
  \begin{itemize}
  \item This difference in design adds some interesting features:
    \begin{itemize}
    \item Effects are easy to implement, as it's up to the window
      manager to mangle the various surfaces at will to display them
      on the screen. Thus, you can add transparency, 3d effects, etc.
    \item Improved stability. With a regular window manager, a message
      is sent to every window to redraw its part of the screen, for
      example when a window has been moved. But if an application
      fails to redraw, the windows will become glitchy. This will not
      happen with a compositing WM, as it will still display the
      untouched surface.
    \end{itemize}
  \item SurfaceFlinger is the compositing window manager in Android,
    providing surfaces to applications and rendering all of them with
    hardware acceleration.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{SurfaceFlinger and PixelFlinger}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/surfaceflinger-architecture.pdf}
  \end{center}
\end{frame}

\subsection{Stagefright}
\begin{frame}
  \frametitle{Stagefright}
  \begin{itemize}
  \item StageFright is the multimedia playback engine in Android since
    Eclair
  \item In its goals, it is quite similar to Gstreamer: Provide an
    abstraction on top of codecs and libraries to easily play
    multimedia files
  \item It uses a plugin system, to easily extend the number of
    formats supported, either software or hardware decoded
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{StageFright Architecture}
  \begin{center}
    \includegraphics[width=0.95\textwidth]{common/stagefright.pdf}
  \end{center}
\end{frame}

\begin{frame}[fragile]
  \frametitle{StageFright plugins}
  \begin{itemize}
  \item To add support for a new format, you need to:
    \begin{itemize}
    \item Develop a new Extractor class, if the container is not
      supported yet.
    \item Develop a new Decoder class, that implements the interface
      needed by the StageFright core to read the data.
    \item Associate the mime-type of the files to read to your new
      Decoder in the \code{OMXCodec.cpp} file, in the
      \code{kDecoderInfo} array.
      \begin{itemize}
      \item $\rightarrow$ No runtime extension of the decoders, this
        is done at compilation time.
      \end{itemize}
    \end{itemize}
  \end{itemize}
\begin{minted}{c}
static const CodecInfo kDecoderInfo[] = {
    { MEDIA_MIMETYPE_AUDIO_AAC, "OMX.TI.AAC.decode" },
    { MEDIA_MIMETYPE_AUDIO_AAC, "AACDecoder" },
};
\end{minted}
\end{frame}

\subsection{Dalvik and Zygote}
\begin{frame}
  \frametitle{Dalvik}
  \begin{itemize}
  \item Dalvik is the virtual machine, executing Android applications
  \item It is an interpreter written in C/C++, and is designed to be portable,
    lightweight and run well on mobile devices
  \item It is also designed to allow several instances of it to be run
    at the same time while consuming as little memory as possible
  \item Two execution modes
    \begin{itemize}
    \item \code{portable}: the interpreter is written in C, quite
      slow, but should work on all platforms
    \item \code{fast}: Uses the \emph{mterp} mechanism, to define
      routines either in assembly or in C optimized for a specific
      platform. Instruction dispatching is also done by computing the
      handler address from the opcode number
    \end{itemize}
  \item It uses the \emph{Apache Harmony} Java framework for its core
    libraries
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Zygote}
  \begin{itemize}
    \item Dalvik is started by \code{Zygote}
    \item \code{frameworks/base/cmds/app_process}
    \item At boot, Zygote is started by init, it then
      \begin{itemize}
      \item Initializes a virtual machine in its address space
      \item Loads all the basic Java classes in memory
      \item Starts the system server
      \item Waits for connections on a UNIX socket
      \end{itemize}
    \item When a new application should be started:
      \begin{itemize}
      \item Android connects to Zygote through the socket to request
        the start of a new application
      \item Zygote forks
      \item The child process loads the new application and start
        executing it
      \end{itemize}
  \end{itemize}
\end{frame}

\subsection{Hardware Abstraction Layer}
\begin{frame}
  \frametitle{Hardware Abstraction Layers}
  \begin{itemize}
  \item Usually, the kernel already provides a HAL for userspace
  \item However, from Google's point of view, this HAL is not sufficient and
    suffers some restrictions, mostly:
    \begin{itemize}
    \item Depending on the subsystem used in the kernel, the userspace
      interface differs
    \item All the code in the kernel must be GPL-licensed
    \end{itemize}
  \item Google implemented its HAL with dynamically loaded userspace libraries
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Library naming}
  \begin{itemize}
  \item It follows the same naming scheme as for init: the generic
    implementation is called \code{libfoo.so} and the hardware-specific
    one \code{libfoo.hardware.so}
  \item The name of the hardware is looked up with the following properties:
    \begin{itemize}
    \item \code{ro.hardware}
    \item \code{ro.product.board}
    \item \code{ro.board.platform}
    \item \code{ro.arch}
    \end{itemize}
  \item The libraries are then searched for in the directories:
    \begin{itemize}
    \item \code{/vendor/lib/hw}
    \item \code{/system/lib/hw}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Various layers}
  \begin{itemize}
  \item Audio (\code{libaudio.so}) configuration, mixing, noise
    cancellation, etc.
    \begin{itemize}
    \item \code{hardware/libhardware_legacy/include/hardware_legacy/AudioHardwareInterface.h}
    \end{itemize}
  \item Graphics (\code{gralloc.so}, \code{copybit.so},
    \code{libhgl.so}) handles graphic memory buffer allocations,
    OpenGL implementation, etc.
    \begin{itemize}
    \item \code{libhgl.so} should be provided by your vendor
    \item \code{hardware/libhardware/include/gralloc.h}
    \item \code{hardware/libhardware/include/copybit.h}
    \end{itemize}
  \item Camera (\code{libcamera.so}) handles the camera functions:
    autofocus, take a picture, etc.
    \begin{itemize}
    \item \code{frameworks/base/include/camera/CameraHardwareInterface.h}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Various layers}
  \begin{itemize}
  \item GPS (\code{libgps.so}) configuration, data acquisition
    \begin{itemize}
    \item \code{hardware/libhardware/include/hardware/gps.h}
    \end{itemize}
  \item Lights (\code{liblights.so}) Backlight and LEDs management
    \begin{itemize}
    \item \code{hardware/libhardware/include/lights.h}
    \end{itemize}
  \item Sensors (\code{libsensors.so}) handles the various sensors on
    the device: Accelerometer, Proximity Sensor, etc.
    \begin{itemize}
    \item \code{hardware/libhardware/include/sensors.h}
    \end{itemize}
  \item Radio Interface (\code{libril-vendor-version.so}) manages all
    communication between the baseband and \code{rild}
    \begin{itemize}
    \item You can set the name of the library with the \code{rild.lib} and
      \code{rild.libargs} properties to find the library
    \item \code{hardware/ril/include/telephony/ril.h}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Example: rild}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/rild-architecture.pdf}
  \end{center}
\end{frame}

\subsection{JNI}
\begin{frame}
  \frametitle{What is JNI?}
  \begin{itemize}
  \item A Java framework to call and be called by native applications
    written in other languages
  \item Mostly used for:
    \begin{itemize}
    \item Writing Java bindings to C/C++ libraries
    \item Accessing platform-specific features
    \item Writing high-performance sections
    \end{itemize}
  \item It is used extensively across the Android userspace to
    interface between the Java Framework and the native daemons
  \item Since Gingerbread, you can develop apps in a purely native
    way, possibly calling Java methods through JNI
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{C Code}
\begin{minted}[fontsize=\footnotesize]{c}
#include "jni.h"

JNIEXPORT void JNICALL Java_com_example_Print_print(JNIEnv *env,
                                                    jobject obj,
                                                    jstring javaString)
{
    const char *nativeString = (*env)->GetStringUTFChars(env,
                                                         javaString,
                                                         0);
    printf("%s", nativeString);
    (*env)->ReleaseStringUTFChars(env, javaString, nativeString);
}
\end{minted}
\end{frame}

\begin{frame}[fragile]
  \frametitle{JNI arguments}
  \begin{itemize}
  \item Function prototypes are following the template:
\begin{minted}[fontsize=\footnotesize]{c}
JNIEXPORT jstring JNICALL Java_ClassName_MethodName
          (JNIEnv*, jobject)
\end{minted}
  \item \code{JNIEnv} is a pointer to the JNI Environment that we will
    use to interact with the virtual machine and manipulate Java objects
    within the native methods
  \item \code{jobject} contains a pointer to the calling object. It is very
    similar to \code{this} in C++
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Java Code}
\begin{minted}[fontsize=\footnotesize]{java}
package com.example;

class Print
{
        private static native void print(String str);

        public static void main(String[] args)
        {
                Print.print("HelloWorld!");
        }

        static
        {
                System.loadLibrary("print");
        }
}
\end{minted}
\end{frame}

\section{Android Framework and Applications}
\subsection{Service Manager and Various Services}
\begin{frame}
  \frametitle{Whole Android Stack}
  \begin{center}
    \includegraphics[height=0.85\textheight]{common/android-stack.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{System Server boot}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/system-server-boot.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{The first step: \code{system_server.c}}
  \begin{itemize}
  \item Located in \code{frameworks/base/cmds/system_server}
  \item Started by \code{Zygote} through the SystemServer
  \item Starts all the various native services:
    \begin{itemize}
    \item \code{SurfaceFlinger}
    \item \code{SensorService}
    \item \code{AudioFlinger}
    \item \code{MediaPlayerService}
    \item \code{CameraService}
    \item \code{AudioPolicyService}
    \end{itemize}
  \item It then calls back the SystemServer object's \code{init2} function to
    go on with the initialization
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Java Services Initialization}
  \begin{itemize}
  \item Located in
    \code{frameworks/base/services/java/com/android/server/SystemServer.java}
  \item Starts all the different Java services in a different thread
    by registering them into the Service Manager
  \item \code{PowerManager}, \code{ActivityManager} (also handles the
    ContentProviders), \code{PackageManager}, \code{BatteryService},
    \code{LightsService}, \code{VibratorService}, \code{AlarmManager},
    \code{WindowManager}, \code{BluetoothService},
    \code{DevicePolicyManager}, \code{StatusBarManager},
    \code{InputMethodManager}, \code{ConnectivityService},
    \code{MountService}, \code{NotificationManager},
    \code{LocationManager}, \code{AudioService}, \code{...}
  \item If you wish to add a new system service, you will need to add
    it to one of these two parts to register it at boot time
  \end{itemize}
\end{frame}

\subsection[IPCs, Binder and AIDLs]{Inter-Process Communication, Binder and AIDLs}
\begin{frame}
  \frametitle{IPCs}
  \begin{itemize}
  \item On modern systems, each process has its own address space,
    allowing to isolate data
  \item This allows for better stability and security: only a given
    process can access its address space. If another process tries to
    access it, the kernel will detect it and kill this process.
  \item However, interactions between processes are sometimes needed,
    that's what IPCs are for.
  \item On classic Linux systems, several IPC mechanisms are used:
    \begin{itemize}
    \item Signals
    \item Semaphores
    \item Sockets
    \item Message queues
    \item Pipes
    \item Shared memory
    \end{itemize}
  \item Android, however, uses mostly:
    \begin{itemize}
    \item Binder
    \item Ashmem and Sockets
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Binder}
  \begin{itemize}
  \item Uses shared memory for high performance
  \item Uses reference counting to garbage collect objects no longer
    in use
  \item Data are sent through \emph{parcels}, which is some kind of
    serialization
  \item Used across the whole system, e.g., clients connect to the
    window manager through Binder, which in turn connects to
    SurfaceFlinger using Binder
  \item Each object has an \emph{identity}, which does not change,
    even if you pass it to other processes, that is used to distinct
    components from a given process, or to enforce security
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Binder Mechanism}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/binder-call-stack.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Binder Implementation 1/2}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/binder-calling.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Binder Implementation 2/2}
  \begin{center}
    \includegraphics[height=0.8\textheight]{common/binder-calling-aidl.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Android Interface Definition Language (AIDL)}
  \begin{itemize}
  \item Very similar to any other Interface Definition Language you
    might have encountered
  \item Describes a programming interface for the client and the
    server to communicate using IPCs
  \item Looks a lot like Java interfaces. Several types are already
    defined, however, and you can't extend this like what you can do in
    Java:
    \begin{itemize}
    \item All Java primitive types (\code{int}, \code{long},
      \code{boolean}, etc.)
    \item \code{String}
    \item \code{CharSequence}
    \item \code{Parcelable}
    \item \code{List} of one of the previous types
    \item \code{Map}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{AIDLs HelloWorld}
\begin{minted}{java}
package com.example.android;

interface IRemoteService {
    void HelloPrint(String aString);
}
\end{minted}
\end{frame}

\begin{frame}
  \frametitle{Intents}
  \begin{itemize}
  \item Intents are a high-level use of Binder
  \item They describe the intention to do something
  \item They are used extensively across Android
    \begin{itemize}
    \item Activities, Services and BroadcastReceivers are started
      using intents
    \end{itemize}
  \item Two types of intents:
    \begin{description}
    \item[explicit] The developer designates the target by its name 
    \item[implicit] There is no explicit target for the Intent. The
      system will find the best target for the Intent by itself, possibly
      asking the user what to do if there are several matches
    \end{description}
  \end{itemize}
\end{frame}

\subsection{Various Java Services}
\begin{frame}
  \frametitle{Android Java Services}
  \begin{itemize}
  \item There are lots of services implemented in Java in Android
  \item They abstract most of the native features to make them
    available in a consistent way
  \item You get access to the system services using the
    \code{Context.getSystemService()} call
  \item You can find all the accessible services in the documentation 
    for this function
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{ActivityManager}
    \begin{itemize}
    \item Manages everything related to Android applications
      \begin{itemize}
      \item Starts Activities and Services through Zygote
      \item Manages their life cycle
      \item Fetches content exposed through content providers
      \item Dispatches the implicit intents
      \item Adjusts the Low Memory Killer priorities
      \item Handles non responding applications
      \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{PackageManager}
    \begin{itemize}
    \item Exposes methods to query and manipulate already installed
      packages, so you can:
      \begin{itemize}
      \item Get the list of packages
      \item Get/Set permissions for a given package
      \item Get various details about a given application (name,
        uids, etc)
      \item Get various resources from the package
      \end{itemize}
    \item You can even install/uninstall an apk
      \begin{itemize}
      \item \code{installPackage}/\code{uninstallPackage} functions are
        hidden in the source code, yet \code{public}.
      \item You can't compile code that is calling directly these
        functions and they are not documented anywhere except in the
        code
      \item But you can call them through the Java \code{Reflection}
        API, if you have the proper permissions of course
      \end{itemize}
    \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{PowerManager}
  \begin{itemize}
  \item Abstracts the Wakelocks functionality
  \item Defines several states, but when a wakelock is grabbed,
    the CPU will always be on
    \begin{itemize}
    \item \code{PARTIAL_WAKE_LOCK}
      \begin{itemize}
      \item Only the CPU is on, screen and keyboard backlight are off
      \end{itemize}
    \item \code{SCREEN_DIM_WAKE_LOCK}
      \begin{itemize}
      \item Screen backlight is partly on, keyboard backlight is off
      \end{itemize}
    \item \code{SCREEN_BRIGHT_WAKE_LOCK}
      \begin{itemize}
      \item Screen backlight is on, keyboard backlight is off
      \end{itemize}
    \item \code{FULL_WAKE_LOCK}
      \begin{itemize}
      \item Screen and keyboard backlights are on
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{AlarmManager}
  \begin{itemize}
  \item Abstracts the Android timers
  \item Allows to set a one time timer or a repetitive one
  \item When a timer expires, the AlarmManager grabs a wakelock,
    sends an Intent to the corresponding application and releases
    the wakelock once the Intent has been handled
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{ConnectivityManager and WifiManager}
  \begin{itemize}
  \item ConnectivityManager
    \begin{itemize}
    \item Manages the various network connections
      \begin{itemize}
      \item Falls back to other connections when one fails
      \item Notifies the system when one becomes available/unavailable
      \item Allows the applications to retrieve various information
        about connectivity
      \end{itemize}
    \end{itemize}
  \item WifiManager
    \begin{itemize}
    \item Provides an API to manage all aspects of WiFi networks
      \begin{itemize}
      \item List, modify or delete already configured networks
      \item Get information about the current WiFi network if any
      \item List currently available WiFi networks
      \item Sends Intents for every change in WiFi state
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Example: Vibrator Service}
  \begin{center}
    \includegraphics[height=0.82\textheight]{common/overall-arch-vibrator.pdf}
  \end{center}
\end{frame}

\subsection{Extend the framework}
\begin{frame}
  \frametitle{Why extend it?}
  \begin{itemize}
  \item You might want to extend the existing Android framework to add
    new features or allow other applications to use specific devices
    available on your hardware
  \item As you have the code, you could just hack the source to make
    the framework suit your needs
  \item This is quite problematic however:
    \begin{itemize}
    \item You might break the API, introduce bugs, etc
    \item Google requires you not to modify the Android public API
    \item It is painful to track changes across the tree, to port the
      changes to new versions
    \item You don't always want to have such extensions for all your
      products
    \end{itemize}
  \item As usual with Android, there's a device-specific way of
    extending the framework: \code{PlatformLibraries}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{PlatformLibraries}
  \begin{itemize}
  \item The modifications are just plain Java libraries
  \item You can declare any namespace you want, do whatever code you
    want.
  \item However, they are bundled as raw Java archives, so you cannot
    embed resources in the modifications
  \item If you would still do this, you can add them to
    \code{frameworks/base/res}, but you have to hide them
  \item When using the Google Play Store, all the libraries including
    these ones are submitted to Google, so that it can filter out apps
    relying on libraries not available on your system
  \item To avoid any application to link to any jar file, you have to
    declare both in your application and in your library that you will
    use and add a custom library
  \item The library's xml permission file should go into the
    \code{/system/etc/permissions} folder
  \end{itemize}
\end{frame}

\section[Android Debug Bridge]{Developing and Debugging with ADB}
\subsection{Introduction}
\begin{frame}
  \frametitle{ADB}
  \begin{itemize}
  \item Usually on embedded devices, debugging and is done either
    through a serial port on the device or JTAG for low-level
    debugging
  \item This setup works well when developing a new product that will
    have a static system. You develop and debug a system on a product
    with serial and JTAG ports, and remove these ports from the final
    product.
  \item For mobile devices, where you will have applications
    developers that are not in-house, this is not enough.
  \item To address that issue, Google developed ADB, that runs on top
    of USB, so that another developer can still have debugging and
    low-level interaction with a production device.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Implementation}
  \begin{itemize}
  \item The code is split in 3 components:
    \begin{itemize}
    \item ADBd, the part that runs on the device
    \item ADB server, which is run on the host, acts as a proxy and
      manages the connection to ADBd
    \item ADB clients, which are also run on the host, and are
      what is used to send commands to the device
    \end{itemize}
  \item ADBd can work either on top of TCP or USB.
    \begin{itemize}
    \item For USB, Google has implemented a driver using the USB
      gadget and the USB composite frameworks as it implements either
      the ADB protocol and the USB Mass Storage mechanism.
    \item For TCP, ADBd just opens a socket
    \end{itemize}
  \item ADB can also be used as a transport layer between the
    development platform and the device, disregarding whether it uses
    USB or TCP as underneath layer
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{ADB Architecture}
  \begin{center}
    \includegraphics[width=\textwidth]{common/adb-arch.pdf}
  \end{center}
\end{frame}

\subsection{Use of ADB}

\begin{frame}
  \frametitle{Useful Commands}
  \begin{description}
  \item[push] Copies a local file to the device
  \item[pull] Copies a remote file from the device
  \item[install] Installs the given Android package (apk) on the device
  \item[uninstall] Uninstalls the given package name from the device
  \item[lolcat] Prints the device logs. You can filter either on
    the source of the logs or their on their priority level
  \item[shell] Runs a remote shell with a command line interface. If an
    argument is given, runs it as a command and prints out the result
  \item[reboot] Reboots the device. \code{bootloader} and
    \code{recovery} arguments are available to select the operation
    mode you want to reboot to.
  \end{description}
\end{frame}

\begin{frame}
  \frametitle{ADB forward and gdb}
  \begin{center}
    \includegraphics[height=0.75\textheight]{common/adb-forward-tcp.pdf}\\
    \code{adb forward tcp:5555 tcp:1234}\\
    See also \code{gdbclient}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{ADB forward and jdb}
  \begin{center}
    \includegraphics[height=0.75\textheight]{common/adb-forward-jdwp.pdf}\\
    \code{adb forward tcp:5555 jdwp:4242}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Various commands}
  \begin{itemize}
  \item Wait for a device and install an application
    \begin{itemize}
    \item \code{adb wait-for-device install foobar.apk}
    \end{itemize}
  \item Test an application by sending random user input
    \begin{itemize}
    \item \code{adb shell monkey -v -p com.bootlin.foobar 500}
    \end{itemize}
  \item Filter system logs
    \begin{itemize}
    \item \code{adb logcat ActivityManager:I FooBar:D *:S}
    \item You can also set the \code{ANDROID_LOG_TAGS} environment
      variable on your workstation
    \end{itemize}
  \item Access other log buffers
    \begin{itemize}
    \item \code{adb logcat -b radio}
    \end{itemize}
  \end{itemize}
\end{frame}

\section{Android Application Development}
\subsection{Basics}
\begin{frame}
  \frametitle{Android applications}
  \begin{itemize}
  \item Android applications are written mostly in Java using Google's
    SDK
  \item Applications are bundled into an Android PacKage (\code{.apk}
    files) which are archives containing the compiled code, data and resources for the
    application, so applications are completely self-contained
  \item You can install applications either through a market (Google
    Play Store, Amazon Appstore, F-Droid, etc) or manually (through
    ADB or a file manager)
  \item Of course, everything we have seen so far is mostly here to
    provide a nice and unified environment to application developers
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Applications Security}
  \begin{itemize}
  \item Once installed, applications live in their own sandbox,
    isolated from the rest of the system
  \item The system assigns a Linux user to every application, so that
    every application has its own user/group
  \item It uses this UID and files permissions to allow  the application
    to access only its own files 
  \item Each process has its own instance of Dalvik, so code is
    running isolated from other applications
  \item By default, each application runs in its own process, which
    will be started/killed during system life
  \item Android uses the \emph{principle of least privilege}. Each
    application by default has only access to what it requires to work.
  \item However, you can request extra permissions, make several
    applications run in the same process, or with the same UID, etc.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Applications Components}
  \begin{itemize}
  \item Components are the basic blocks of each application
  \item You can see them as entry points for the system in the application
  \item There is four types of components:
    \begin{itemize}
    \item Activities
    \item Broadcast Receivers
    \item Content Providers
    \item Services
    \end{itemize}
  \item Every application can start any component, even located in
    other applications. This allows to share components easily, and
    have very little duplication. However, for security reasons, you
    start it through an Intent and not directly
  \item When an application requests a component, the system starts
    the process for this application, instantiates the needed class and
    runs that component. We can see that there is no single point of
    entry in an application like \code{main()}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Application Manifest}
  \begin{itemize}
  \item To declare the components present in your application, you
    have to write a XML file, \code{AndroidManifest.xml}
  \item This file is used to:
    \begin{itemize}
    \item Declare available components
    \item Declare which permissions these components need
    \item Revision of the API needed
    \item Declare hardware features needed
    \item Libraries required by the components
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{NDK}
  \begin{itemize}
  \item Google also provides a NDK to allow developers to write native
    code
  \item While the code is not run by Dalvik, the security guarantees
    are still there
  \item Allows to write faster code or to port existing C code to
    Android more easily
  \item Since Gingerbread, you can even code a whole application
    without writing a single line of Java
  \item It is still packaged in an apk, with a manifest, etc.
  \item However, there are some drawbacks, the main one being that you
    can't access the resources mechanism available from Java
  \end{itemize}
\end{frame}

\subsection{Activities}
\begin{frame}
  \frametitle{Activities}
  \begin{itemize}
  \item Activities are a single screen of the user interface of an
    application
  \item They are assembled to provide a consistent interface. If we
    take the example of an email application, we will have:
    \begin{itemize}
    \item An activity listing the received mails
    \item An activity to compose a new mail
    \item An activity to read a mail
    \end{itemize}
  \item Other applications might need one of these activities. To
    continue with this example, the Camera application might want to
    start the composing activity to share the just-shot picture
  \item It is up to the application developer to advertise available
    activities to the system
  \item When an activity starts a new activity, the latter replaces
    the former on the screen and is pushed on the \emph{back stack}
    which holds the last used activities, so when the user is done
    with the newer activity, it can easily go back to the previous one
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Activity Lifecycle 1/3}
  \begin{itemize}
  \item As there is no single entry point and as the system manages
    the activities, activities have to define callbacks that the
    system can call at some point in time
  \item Activities can be in one of the three states on Android
    \begin{description}
    \item[Running] The activity is on the foreground and has focus
    \item[Paused] The activity is still visible on the screen but no
      longer has focus. It can be destroyed by the system under very
      heavy memory pressure
    \item[Stopped] The activity is no longer visible on the screen. It
      can be killed at any time by the system
    \end{description}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Activity Lifecycle 2/3}
  \begin{itemize}
  \item There are callbacks for every change from one of these states
    to another
  \item The most important ones are \code{onCreate} and \code{onPause}
  \item All components of an application run in the same thread. If
    you do long operations in the callbacks, you will block the entire
    application (UI included). You should always use threads for every
    long-running task.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Activity Lifecycle 3/3}
  \begin{figure}[h!]
    \centering
    \includegraphics[height=0.8\textheight]{common/activity-lifecycle.png}\\
    {
      \tiny
      Credits: \url{http://developer.android.com}
    }
  \end{figure}
\end{frame}

\subsection{Services}
\begin{frame}
  \frametitle{Services}
  \begin{itemize}
  \item Services are components running in the background
  \item They are used either to perform long running operations or
    to work for remote processes
  \item A service has no user interface, as it is supposed to run when the
    user does something else
  \item From another component, you can either work with a service in
    a synchronous way, by \emph{binding} to it, or asynchronous, by
    \emph{starting} it
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Services Types}
  \begin{itemize}
  \item We can see services as a set including:
    \begin{itemize}
    \item Started Services, that are created when other components
      call \code{startService}. Such a service runs as long as needed,
      whether the calling component is still alive or not, and
      can stop itself or be stopped. When the service is stopped, it
      is destroyed by the system
    \item Bound Services, that are bound to by other components by
      calling \code{bindService}. They offer a client/server like
      interface, interacting with each other. Multiple components can
      bind to it, and a service is destroyed only when no more
      components are bound to it
    \end{itemize}
  \item Services can be of both types, given that callbacks for these
    two do not overlap completely
  \item Services are started by passing Intents either to the
    \code{startService} or \code{bindService} commands
  \end{itemize}
\end{frame}

\subsection{Content Providers}
\begin{frame}
  \frametitle{Content Providers}
  \begin{itemize}
  \item They provide access to organized data in a manner quite
    similar to relational databases
  \item They allow to share data with both internal and external
    components and centralize them
  \item Security is also enforced by permissions like usual, but they
    also do not allow remote components to issue arbitrary requests
    like what we can do with relational databases
  \item Instead, Content Providers rely on URIs to allow for a restricted set of
    requests with optional parameters, only permitting the user to
    filter by values and by columns
  \item You can use any storage back-end you want, while exposing a
    quite neutral and consistent interface to other applications
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Content URIs}
  \begin{itemize}
  \item URIs are often built with the following pattern:
    \begin{itemize}
    \item \code{content://<package>.provider/<path>} to access particular tables
    \item \code{content://<package>.provider/<path>/<id>} to access
      single rows inside the given table
    \end{itemize}
  \item Facilities are provided to deal with these
    \begin{itemize}
    \item On the application side:
      \begin{itemize}
      \item \code{ContentUri} to append and manage numerical IDs in URIs
      \item \code{Uri.Builder} and \code{Uri} classes to deal with
        URIs and strings
      \end{itemize}
    \item On the provider side:
      \begin{itemize}
      \item \code{UriMatcher} associates a pattern to an ID, so that
        you can easily match incoming URIs, and use switch over them.
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{Managing the Intents}
\begin{frame}
  \frametitle{Intents}
  \begin{itemize}
  \item Intents are basically a bundle of several pieces of information,
    mostly
    \begin{itemize}
    \item \code{Component Name}
      \begin{itemize}
      \item Contains both the full class name of the target
        component plus the package name defined in the Manifest
      \end{itemize}
    \item \code{Action}
      \begin{itemize}
      \item The action to perform or that has been performed
      \end{itemize}
    \item \code{Data}
      \begin{itemize}
      \item The data to act upon, written as a URI, like
        \code{tel://0123456789}
      \end{itemize}
    \item \code{Category}
      \begin{itemize}
      \item Contains additional information about the nature of the
        component that will handle the intent, for example the launcher
        or a preference panel
      \end{itemize}
    \end{itemize}
  \item The component name is optional. If it is set, the intent will
    be explicit. Otherwise, the intent will be implicit
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Intent Resolution}
  \begin{itemize}
  \item When using explicit intents, dispatching is quite easy, as
    the target component is explicitly named. However, it is quite
    rare that a developer knows the component name of external
    applications, so it is mostly used for internal communication.
  \item Implicit intents are a bit more tricky to dispatch. The system
    must find the best candidate for a given intent.
  \item To do so, components that want to receive intents have to
    declare them in their manifests \emph{Intent filters}, so that the
    system knows what components it can respond to.
  \item Components without intent filters will never receive implicit
    intents, only explicit ones
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Intent Filters 1/2}
  \begin{itemize}
  \item They are only about notifying the system about handled implicit
    intents
  \item Filters are based on matching by category, action and data.
    Filtering by only one of these three (by category for example) is fine.
    \begin{itemize}
    \item A filter can list several actions. If an intent action field
      corresponds to one of the actions listed here, the intent
      will match
    \item It can also list several categories. However, if none of the
      categories of an incoming intent are listed in the filter,
      then intent won't match.
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Broadcast Receivers}
  \begin{itemize}
  \item Broadcast receivers are the fourth type of components that can
    be integrated into an application. They are specifically designed
    to deal with broadcast intents.
  \item Their overall design is quite easy to understand: there is
    only one callback to implement: \code{onReceive}
  \item The life cycle is quite simple too: once the onReceive callback
    has returned, the receiver is considered no longer active and can
    be destroyed at any moment
  \item Thus you must not use asynchronous calls (Bind to a service
    for example) from the onReceive callback, as there is no way
    to be sure that the object calling the callback will still be alive
    in the future.
  \end{itemize}
\end{frame}

\subsection{Resources}
\begin{frame}
  \frametitle{Applications Resources}
  \begin{itemize}
  \item Applications contain more than just compiled source code:
    images, videos, sound, etc.
  \item In Android, anything related to the visual appearance of the
    application is kept separate from the source code: activities
    layout, animations, menus, strings, etc.
  \item Resources should be kept in the \code{res/} directory of your
    application.
  \item At compilation, the build tool will create a class \code{R},
    containing references to all the available resources, and
    associating an ID to it
  \item This mechanism allows you to provide several alternatives to
    resources, depending on locales, screen size, pixel density,
    etc. in the same application, resolved at runtime.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Resources Directory}
  \begin{itemize}
  \item All resources are located in the \code{res/} subdirectory
    \begin{itemize}
    \item \code{anim/} contains animation definitions
    \item \code{color/} contains the color definitions
    \item \code{drawable/} contains images, "9-patch" graphics, or XML-files
      defining drawables (shapes, widgets, relying on a image file)
    \item \code{layout/} contains XML defining applications layout
    \item \code{menu/} contains XML files for the menu layouts
    \item \code{raw/} contains files that are left untouched
    \item \code{values/} contains strings, integers, arrays,
      dimensions, etc
    \item \code{xml/} contains arbitrary XML files
    \end{itemize}
  \item All these files are accessed by applications through their
    IDs. If you still want to use a file path, you need to use the
    \code{assets/} folders
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Resources}
  \begin{figure}[h!]
    \centering
    \includegraphics[height=0.4\textheight]{common/resource-no-alternative.png}\\
    \includegraphics[height=0.4\textheight]{common/resource-alternative.png}\\
    {
      \tiny
      Credits: \url{http://developer.android.com}
    }
  \end{figure}
\end{frame}

\begin{frame}
  \frametitle{Alternative Resources}
  \begin{itemize}
  \item Alternative resources are provided using extended sub-folder
    names, that should be named using the pattern
    \code{<folder_name>-<qualifier>}
  \item There is a number of qualifiers, depending on which case
    you want to provide an alternative for. The most used ones are probably:
    \begin{itemize}
    \item locales (\code{en}, \code{fr}, \code{fr-rCA}, ...)
    \item screen orientation (\code{land}, \code{port})
    \item screen size (\code{small}, \code{large},...)
    \item screen density (\code{mdpi}, \code{ldpi}, ...)
    \item and much others
    \end{itemize}
  \item You can specify multiple qualifiers by chaining them,
    separated by dashes. If you want layouts to be applied only when
    on landscape on high density screens, you will save them into the
    directory \code{layout-land-hdpi}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Resources Selection}
  \begin{figure}[h!]
    \centering
    \includegraphics[height=0.8\textheight]{common/resource-selection.png}\\
    {
      \tiny
      Credits: \url{http://developer.android.com}
    }
  \end{figure}
\end{frame}

\section{Demo Time!}

\begin{frame}
\frametitle{Hardware used in this demo}
  Using DevKit8000 boards from Embest
  \begin{columns}
    \column{0.6\textwidth}
    \begin{itemize}
      \item OMAP3530 SoC from Texas Instruments
      \item 256 MB RAM, 256 MB flash
      \item 4”3  TFT LCD touchscreen
      \item 1 USB 2.0 host, 1 USB device
      \item 100 Mbit Ethernet port
      \item DVI-D / HDMI display connector
      \item Expansion port, JTAG port, etc.
      \item Currently sold in Europe at 269 EUR (V.A.T. not included)
            by NeoMore.
    \end{itemize}
    \column{0.4\textwidth}
    \includegraphics[width=\textwidth]{common/devkit8000.jpg}
  \end{columns}
\end{frame}
\end{document}
