\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}

\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{A Look through the Android Stack}
\authors{Maxime Ripard}
\institute{Bootlin}
\email{maxime.ripard@bootlin.com}
\slidesurl{https://bootlin.com/pub/conferences/}

\usepackage{hyperref}

\begin{document}

\addtocontents{toc}{\protect\setcounter{tocdepth}{-1}}
\section{A Look through the Android Stack}
\addtocontents{toc}{\protect\setcounter{tocdepth}{2}}

\begin{frame}{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, etc.
    \item Embedded Linux, Embedded Android and driver development
      training, with materials freely available under a Creative
      Commons license.
    \item \url{https://bootlin.com}
    \end{itemize}
  \item Contributor to Buildroot, a simple open-source embedded build
    system
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{What is Android?}
  \begin{itemize}
  \item Mobile OS bought by Google in 2005
  \item Opened up to the world through the Android Open Source Project
    the 21 October 2008 with the release of Android 1.0 (mostly) under
    the Apache 2.0 License
  \item Has deep foundation into the open-source/free software world,
    even if a huge part has been written from scratch: uses Linux,
    WebKit, SQLite, OpenSSL, etc.
  \item Is now one of the most successful mobile OS in the world
  \end{itemize}
\end{frame}

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

\section{Booting Up...}

\subsection{The Linux Kernel}

\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.4, after being a complete fork for a
    long time
  \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}
  \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]{binder.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Ashmem}
  \begin{itemize}
  \item \path{ndk/docs/system/libc/SYSV-IPC.html} illustrates all the
    love Android developers have for the shared memory mechanism in
    Linux
  \item Ashmem is the response to the flaws exposed
  \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}

\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 behaviour 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}

\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 Alarm Timers, which combines Real-Time Clock with the
      high-resolution timers to wake up a process even when the device
      is in suspend.
    \item Paranoid Network, which restricts access to the network
      interfaces only to a given GID
    \item ADB
    \item YAFFS2
    \item Timed GPIOs
    \end{itemize}
  \end{itemize}
\end{frame}

\subsection{Init}

\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:
      set particular permissions to the device files, mount the
      filesystems, start a daemon, etc.
    \item it monitors the services it started, so that if they crash,
      it can restart them, reboot the device, etc.
    \item it monitors system properties so that you can take actions
      when a particular one is modified
    \end{itemize}
  \item Basically, it is quite comparable to sysvinit + udev
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Android startup}
  \begin{center}
    \includegraphics[width=\textwidth]{init.pdf}
  \end{center}
\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{Service Manager and Various Services}

\begin{frame}
  \frametitle{System Server boot}
  \begin{center}
    \includegraphics[height=0.8\textheight]{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}

\section{Communication within the system}

\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 1/2}
  \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.
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Binder 2/2}
  \begin{itemize}
  \item This is useful if you want to separate components in distinct
    processes, or to manage several components of a single process (i.e.
    Activity's Windows).
  \item Object identity is also used for security. Some
    token passed correspond to specific permissions. Another
    security model to enforce permissions is for every transaction to
    check on the calling UID.
  \item Binder also supports one-way and two-way messages 
  \end{itemize}
\end{frame}


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

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

\begin{frame}
  \frametitle{Binder Implementation 2/2}
  \begin{center}
    \includegraphics[height=0.8\textheight]{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}
  \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}

\section{Wrap-up}

\begin{frame}
  \frametitle{Interactions in the System}
  \begin{center}
    \includegraphics[height=0.8\textheight]{android-stack.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Example: VibratorService}
  \begin{center}
    \includegraphics[height=0.8\textheight]{overall-arch-vibrator.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Questions?}
  \begin{center}
  \large
  Our training slides are available on
  \url{https://bootlin.com/doc/training/android/}
  \vspace{1.5cm}\\
  \Large
  Maxime Ripard\\
  \large
  \code{maxime.ripard@bootlin.com}
  \vspace{1.5cm}\\
  \tiny
  PDF and sources of these slides will be available on
  \url{https://bootlin.com/pub/conferences/2012/lsm/}
  \end{center}
\end{frame}


\end{document}
