\subsection{Init}

\begin{frame}
  \frametitle{Whole Android Stack}
  \begin{center}
    \includegraphics[height=0.85\textheight]{slides/android-native-layer-init/android-stack-init.pdf}
  \end{center}
\end{frame}

\begin{frame}
  \frametitle{Init}
  \begin{itemize}
  \item \code{init} is the name of the first user space 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, the main
    \code{init.rc} file itself, plus the extra file included from it
  \item By default, these included files hold either
    subsystem-specific initialisation (USB, Kernel Tracing), or
    hardware-specific instructions
  \item It relies on system properties, evaluated at runtime, that
    allows to have on the same system, configuration for several
    different platforms, that will be used only when they are
    relevant.
  \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{Syntax}
  \begin{itemize}
  \item Unlike most init script systems, the configuration relies on
    system event and system property changes, allowed by the
    daemon part of it
  \item This way, you can trigger actions not only at startup or at
    run-level changes like with traditional init systems, but also at
    a given time during system life
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Actions}
\begin{verbatim}
on <trigger>
  command
  command
\end{verbatim}
  \begin{itemize}
  \item Here are a few trigger types:
    \begin{itemize}
    \item \code{boot}
      \begin{itemize}
      \item Triggered when init is loaded
      \end{itemize}
    \item \code{<property>=<value>}
      \begin{itemize}
      \item Triggered when the given property is set to the given
        value
      \end{itemize}
    \item \code{device-added-<path>}
      \begin{itemize}
      \item Triggered when the given device node is added or removed
      \end{itemize}
    \item \code{service-exited-<name>}
      \begin{itemize}
      \item Triggered when the given service exits
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}
  \frametitle{Init triggers}
  \begin{itemize}
  \item Commands are also specific to Android, with sometimes a syntax very
    close to the shell one (just minor differences):
  \item The complete list of triggers, by execution order is:
    \begin{itemize}
    \item \code{early-init}
    \item \code{init}
    \item \code{early-fs}
    \item \code{fs}
    \item \code{post-fs}
    \item \code{early-boot}
    \item \code{boot}
    \end{itemize}
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Example}
\begin{verbatim}
import /init.${ro.hardware}.rc

on boot
   export PATH /sbin:/system/sbin:/system/bin
   export LD_LIBRARY_PATH /system/lib

   mkdir /dev
   mkdir /proc
   mkdir /sys

   mount tmpfs tmpfs /dev
   mkdir /dev/pts
   mkdir /dev/socket
   mount devpts devpts /dev/pts
   mount proc proc /proc
   mount sysfs sysfs /sys

   write /proc/cpu/alignment 4
\end{verbatim}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Services}
\begin{verbatim}
service <name> <pathname> [ <argument> ]*
   <option>
   <option>
\end{verbatim}
  \begin{itemize}
  \item Services are like daemons
  \item They are started by init, managed by it, and can be restarted
    when they exit
  \item Many options, ranging from which user to run the service as,
    rebooting in recovery when the service crashes too frequently, to
    launching a command at service reboot.
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{Example}
\begin{verbatim}
on device-added-/dev/compass
  start akmd

on device-removed-/dev/compass
  stop akmd

service akmd /sbin/akmd
  disabled
  user akmd
  group akmd
\end{verbatim}
\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 \code{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}
  \item While \code{ueventd.rc} is always taken into account,
    \code{ueventd.<platform>.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
  \end{itemize}
\end{frame}

\begin{frame}[fragile]
  \frametitle{ueventd.rc syntax}
\begin{verbatim}
<path>   <permission>  <user>  <group>
\end{verbatim}
  \begin{itemize}
  \item Example
  \end{itemize}
\begin{verbatim}
/dev/bus/usb/*            0660   root       usb
\end{verbatim}
\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 splitted 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}
  \fontsize{10}{10}\selectfont
  \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}
