Chapter IV - Android Runtime Services

Experiment: Observing healthd

Using the powerful strace(1) utility you can watch healthd behind the scenes: By attaching to its process ID (as root) and calling on the ptrace(2) API, strace(1) can get notifications of system calls. Because anything meaningful a process does goes through a system call, this will provide a detailed trace of the activity, and reveal the names of the sysfs files healthd uses to obtain its statistics, as shown in the following annotated output:

root@htc_m8wl:/ # ls -l /proc/$healthd_pid/fd | cut -c'1-10,55-'
lrwx------ 0 -> /dev/null                
lrwx------ 1 -> /dev/null
lrwx------ 2 -> /dev/null
l-wx------ 3 -> /dev/__kmsg__ (deleted)                   # Output: Log to kernel
lrwx------ 4 -> socket:[6951]                             # event_fd (Netlink socket)
lrwx------ 5 -> /dev/binder                               # binder_fd
lrwx------ 6 -> anon_inode:[eventpoll]                    # epollfd
l-wx------ 7 -> /dev/cpuctl/apps/tasks
l-wx------ 8 -> /dev/cpuctl/apps/bg_non_interactive/tasks 
lr-x------ 9 -> /dev/__properties__
root@htc_m8wl:/ # strace -p $healthd_pid
Process $healthd_pid attached - interrupt to quit
# healthd patiently polling (0xffffffff = indefinitely) until an fd signals an event
epoll_wait(0x6, 0xbebb5898, 0x2, 0xffffffff) = 1
# Netlink msg received on fd 4 (event_fd) - indicating core state change (going offline)
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000001}, 
msg_iov(1)=[{"offline@/devices/system/cpu/cpu1"..., 1024}], msg_controllen=24,  ....
# healthd's not interested, so it goes back to polling
epoll_wait(0x6, 0xbebb5898, 0x2, 0xffffffff) = 1
# message indicating change in battery status:
recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000001}, 
msg_iov(1)=[{"change@/devices/platform/htc_bat"..., 1024}], msg_controllen=24, 
{cmsg_len=24, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS{pid=0, uid=0, gid=0}}, 
msg_flags=0}, 0) = 488
# healthd goes into a flurry of statistics collection, opening and closing files:
open("/sys/class/power_supply/battery/present", O_RDONLY) = 10     # Is battery present?
read(10, "1\n", 16)                     = 2                        # Yes (1)            
close(10)                               = 0
open("/sys/class/power_supply/battery/capacity", O_RDONLY) = 10    # What is its capacity?
read(10, "96\n", 128)                   = 3                        # 96%
close(10)                               = 0
open("/sys/class/power_supply/battery/batt_vol", O_RDONLY) = 10    # Voltage?
read(10, "4303\n", 128)                 = 5
close(10)                               = 0
open("/sys/class/power_supply/battery/batt_temp", O_RDONLY) = 10   # Temperature?
read(10, "265\n", 128)                  = 4
close(10)                               = 0
open("/sys/class/power_supply/battery/status", O_RDONLY) = 10      # Charge status?
read(10, "Charging\n", 128)             = 9                        # Charging
close(10)                               = 0
open("/sys/class/power_supply/battery/health", O_RDONLY) = 10
read(10, "Good\n", 128)                 = 5
close(10)                               = 0
open("/sys/class/power_supply/battery/technology", O_RDONLY) = 10
read(10, "Li-poly\n", 128)              = 8
close(10)                               = 0
open("/sys/class/power_supply/ac/online", O_RDONLY) = 10
read(10, "0\n", 128)                    = 2
close(10)                               = 0
open("/sys/class/power_supply/usb/online", O_RDONLY) = 10        # USB is connected 
read(10, "1\n", 128)                    = 2
close(10)                               = 0
open("/sys/class/power_supply/usb/type", O_RDONLY) = 10
read(10, "USB\n", 128)                  = 4
close(10)                               = 0
open("/sys/class/power_supply/wireless/online", O_RDONLY) = 10   # Alas, no wireless charging 
read(10, "0\n", 128)                    = 2                      # for the M8
close(10)                               = 0
write(3, "<6>healthd: battery l=96 v=4 t=2".., 51) = 51 # Report to kernel log
ioctl(5, 0xc0186201, 0xbebb5070)        = 0             # Report to clients (BINDER_WRITE_READ)
epoll_wait(0x6, 0xbebb5898, 0x2, 0xffffffff) = ..       # Back to polling

Note the sysfs psuedo files (/sys/class/power_supply/*) are standard - in practice they are symbolic links to the specific platform device nodes, which change between devices.

As an improvement on the above, you might want to send the strace into the background (by using &) and then disconnect and reconnect the USB cable. You will then see the netlink notification for battery change, followed by a change in /sys/class/power_supply/usb/online (from 1 to 0 on disconnect, or vice versa on connect).

logd (Android L)

Android L defines a new, much needed logging mechanism with its logd daemon. This daemon serves as a centralized user-mode logger (as opposed to Android's /dev/log/ files, implemented in kernel ring buffers), in a manner reminiscient of UN*X syslog. The service is defined in /init.rc as follows:

service logd /system/bin/logd
    class core
    socket logd stream 0666 logd logd
    socket logdr seqpacket 0666 logd logd
    socket logdw dgram 0222 logd logd
    seclabel u:r:logd:s0

Note this service is designed with not one, but three sockets:

• /dev/socket/logd:
• /dev/socket/logdw: A write-only socket (permissions 022 = -w--w--w-).
• /dev/socket/logdr: A read-write socket, designed for reading. Unlike the logd UN*X domain socket, this is a seqpacket (sequential packet) socket.

lmkd (Android L)

Android L uses another specialized core service class daemon called lmkd. It is defined in the /init.rc as follows:

service lmkd /system/bin/lmkd
    class core
    critical
    socket lmkd seqpacket 0660 system system

The lmkd daemon provides an interface to the kernel's Low Memory Killer mechanism, which is an Androidism of the kernel (that is, a feature present in Android kernels, but not Linux ones). The Low Memory Killer allows Android finer control over the Linux Out-Of-Memory (OOM) mechanism, which automatically selects and terminates tasks during memory pressure. This mechanism is described in detail in Chapter 18.

vold

The Android vold is a volume-management daemon. This concept, which originally appeared in the (now deceased) Solaris operating system, employs a user-space daemon to automatically mount file systems ("volumes") as they are detected by the kernel. Beginning with HoneyComb, vold also enables file system encryption, in particular /data. Listing 4-voldrc shows the definition of vold:

    service vold /system/bin/vold
    class core
    socket vold stream 0660 root mount
    ioprio be 2
  

The vold internally comprises three components:

• VolumeManager: Responsible for maintaining volume state, and handling various volume operations
• NetlinkManager: Responsible for listening on kernel netlink events of the blocksubsystems, by passing them to the volumeManager
• CommandListener: Responsible for listening on the /dev/socket/vold socket, for commands issued by the framework.

The main client of vold is com.android.server.MountService, though applications cannot call this service directly, and must instead use android.os.storage.StorageManager. The MountService maintains a NativeDaemonConnector which uses the client side of the socket to send commands to vold's CommandListener. Most Android devices have a vdc utility, which you can use to send these commands to vold yourself (as root). The utility is nothing more than a tiny UNIX domain socket client, whose source can be found in system/vold/vdc.c. The commands are shown in table 4-voldc:

Of particular interest is vold's filesystem encryption handling. The Android Documentation provides a detailed explanation of the process as implemented in Honeycomb, as does this book, next.

Decrypting filesystems

With Honeycomb, Android brings support for disk encryption. By extending Linux's dm-crypt mechanism, which already provides the foundation for the asec mechanism, Android enables the entire user data partition to be encrypted. The system partition still remains very much cleartext, because the system has to somehow boot, but this is quite fine - The system partition is, for all intents and purposes, identical on all devices, and never actually holds any user-specific data, so there would be little advantage in encrypting it.

The dm-crypt feature is described in more detail in Chapter 21. At a high level view, however, suffice it to say that dm-crypt transparently encrypts and decrypts block devices. The password required for doing so, however, needs to be supplied in user mode. Android derives the passcode or pattern the user is already using for the lock screen1, and uses the com.android.settings.CryptKeeper activity to prompt the user for the credentials required to unlock the device, without which /data cannot be mounted.

What follows, therefore, is a choreography between init (driving the system startup), vold (providing the actual mount services), and CryptKeeper (handling the UI displayed to the user). This is shown in figure 4-voldch:

During boot, init calls on the fs_mgr to mount the file systems. If none are encrypted, in sets the ro.crypto.state to "unencrypted" and enqueues any actions associated with the "nonencrypted" trigger - usually those services in the late_start class. If a file system is encrypted, however, an encrypted mount will obviously fail, unless the password is supplied. The fs_mgr mounts the filesystem instead as a tmpfs, and returns 1 to init, which sets ro.crypto.state to "encrypted", and informs vold of the need to decrypt /data (by setting vold.decrypt to 1). Prior to kitkat, vold would use the value of the ro.crypto.tmpfs_options property as mount options, but these options are now hardcoded. The mounting of /data is a prerequisite for loading the UI frameworks, since those need to write various files. As a temporary filesystem, however, the /data mount holds no data. When the vold.decrypt is set, the SystemServer only runs the "core" apps and services.

The com.android.settings.CryptKeeper activity registers itself as the home screen (using an IntentFilter), with a higher priority, so as to ensure it starts first. When it loads, it checks the value of vold.decrypt in its onCreate(). If unset, it simply exits, making room for the "real" home screen. If the filesystem is encrypted, however, the CryptKeeper start an async ValidationTask in its onStart() to contact the com.android.server.MountService, calling its getEncryptionState() to see if the partition is indeed properly encrypted.

Recall, that the MountService is connected to the vold socket. It can thus send the daemon the cryptfs cryptocomplete command. This makes vold check if the encryption is indeed recoverable (as it may be that the encryption has been interrupted, rendering /data unmountable, and forcing the user to do a recovery/reset). If the cryptocomplete operation is successful, the CryptKeeper calls setupUi to input the user for the decryption password or sequence. It passes this again to MountService, which sends it to vold as a cryptfs checkpw command.

If the password is correct, the MountService sends the cryptfs restart command. This makes vold update the vold.decrypt property to trigger_reset_main, and sleep for 2 seconds in the hopes that all the services loaded under the main class will be stopped, and the tmpfs /data can be unmounted. If the unmount is successful, vold remounts the (now unecrypted) /data partition, and again updates the vold.decrypt property - first to load_persist_props (since those reside in /data), next to trigger_post_fs_data (to get init to set up any paths in /data defined in /init.rc) and then to trigger_restart_framework, which makes init restart the frameworks. The properties must be defined in /init.rc to arm the approriate triggers, as shown in listing 4-initencact:

on nonencrypted
    class_start late_start

on charger
    class_start charger

on property:vold.decrypt=trigger_reset_main
    class_reset main

on property:vold.decrypt=trigger_load_persist_props
    load_persist_props


on property:vold.decrypt=trigger_post_fs_data
# This will call on post-fs-data, which must end with a post-fs-data-done
    trigger post-fs-data

on property:vold.decrypt=trigger_restart_min_framework
    class_start main

on property:vold.decrypt=trigger_restart_framework
    class_start main
    class_start late_start

on property:vold.decrypt=trigger_shutdown_framework
    class_reset late_start
    class_reset main

Encrypting filesystems

Encrypting file systems is handled in a similar manner to decrypting them. Once again, the UI is supplied by CryptKeeper, with the MountService providing the Dalvik level bridge to vold. The UI prompts the user for the encryption password, and verifies the device is on AC power, to prevent any power outage which may disrupt the encryption. The MountManager's encryptStorage method is called, which sends vold the cryptfs enablecrypto, with either wipe (to format /data before encrypting it) or inplace argument, and the password.

Upon getting the command and verifying it can proceed, vold sets the vold.decrypt to trigger_shutdown_framework. This causes init to stop all services but the core ones. This is exactly the mirror image of the state the system is in while booting, before the user password is entered, and /data can be safely unmounted. vold then sets vold.encrypt_progress to start at 0, and vold.decrypt to trigger_restart_min_framework, to get init to restart the main services.

Once again, CryptKeeper loads as the home app. Upon seeing vold.encrypt_progress, it loads the status bar UI.. If all goes well, the progress bar reaches 100%. If not, vold.encrypt_progress is set to an error_ string, and the user is left with no choice but to reset the device to defaults.

The technical aspects of encryption, as well as the kernel perspective, are discussed in Chapter21.

Network Services

service netd /system/bin/netd
    class main
    socket netd stream 0660 root system
    socket dnsproxyd stream 0660 root inet
    socket mdns stream 0660 root system
    socket fwmarkd stream 0660 root inet // Android L

Multicast DNS (mDNS) is a popular discovery protocol first adopted by Apple (as its "Bonjour" service). It is used extensively in iOS's family of "Air" protocols (e.g. "AirPlay"), and allows devices to find one another by sending a multicast request to group 224.0.0.253 (or IPv6's FF02::fc) and UDP port 5353. Unsurprisingly, Android chose to adopt this from iOS as well, and it serves as the basis for "WiFi Direct". Beginning with JellyBean, /init.rc defines the mDNS service as follows:

service mdnsd /system/bin/mdnsd
    class main
    user mdnsr
    group inet net_raw
    socket mdnsd stream 0660 mdnsr inet
    disabled
    oneshot

Because of its multicast capabilities, the service is granted membership in both the inet group (allowing general TCP/IP capabilities) and the net_raw group (allowing "advanced" capabilities, such as raw sockets and crafting non-standard IP packets). The service listens on /dev/socket/mdnsd (MDNS_UDS_SERVERPATH) for requests, and has another socket (/dev/socket/mdns) connected to netd.

Todo: Mention NsdService

The mDNS implementation is found in the external/mdnsresponder directory. It is largely the same as the open source mDNS project, with the Android specific modifications (such as the UNIX domain socket and Android logging) clearly marked by #ifdef __ANDROID__ blocks.

Though the acronym MTP is normally associated in Android (and elsewhere) with the Media Transfer Protocol, the mtpd couldn't be further from it - It is the daemon responsible for PPP and L2TP (but not IPSec). It is defined in /init.rc as follows:

service mtpd /system/bin/mtpd
    class main
    socket mtpd stream 600 system system
    user vpn
    group vpn net_admin inet net_raw
    disabled
    oneshot

The group permissions granted to mtpd reflect its need for network access (inet) setting up a network interface (net_admin), and tunneling IP (net_raw). As a oneshot and disabled service, the mtpd must be started manually. Indeed, the com.android.server.connectivity.Vpn does so (in its startLegacyVPN inner class). There is no programming interface for VPN functionality, which is meant to be started or stopped from the Android system GUI.

Racoon is a de facto standard VPN daemon. As an external project, it is not part of Android per se, but is used extensively (in both Android and iOS) to provide VPN services. VPN connectivity is discussed in Chapter 15.

service racoon /system/bin/racoon
    class main
    socket racoon stream 600 system system
    # IKE uses UDP port 500. Racoon will setuid to vpn after binding the port.
    group vpn net_admin inet
    disabled
    oneshot

Note that racoon starts as root (in order to bind the ISAKMP well known port, which is a privileged port), but then drops privileges. This is why it requires the extra group memberships, which (as we discuss in Chapter 21) allow network connectivity. From a strict security standpoint, it would have been better to relinquish root altogether, and use capabilities (in particular CAP_NET_BIND_SERVICE) instead. This is especially important considering racoon has had a history of exploits (and was in fact used to jailbreak iOS 5) before.

If your Android device is a phone or 3G/LTE connected tablet, rild is undoubtedly one of the more important system processes. The Radio Interface Layer Daemon provides virtually all the telephony capabilities for these devices, by interfacing with the baseband. It is defined in /init.rc as follows:

service ril-daemon /system/bin/rild
    class main
    socket rild stream 660 root radio
    socket rild-debug stream 660 radio system
    user root
    group radio cache inet misc audio log

Though most users don't give this a passing thought, the telephony APIs used in today's mobile devices aren't that far from the modems employed in the previous millenium. In fact, the low-level call control is still carried out with the same set of commands used by modems - the "AT" commands - which may be familiar to anyone who's ever used minicom and kermit back in the day. The rild is responsible for opening the telephony device (which is basically a serial port) and generating these commands.

As shown in the above definition, the daemon uses two sockets:

• /dev/socket/rild: This socket is the interface by means of which the phone application can connect to the daemon, and issue various phone-related requests (e.g. dialing, answering, hanging up). The socket is not meant to be used directly.
• /dev/socket/rild-debug: As the name implies, this socket is intended for use in debugging, and is undocumented save for the source of the debugCallback of libril. It defines a set of codes, which will cause requests to be artificially injected into the RIL. Table 4-rdc shows the codes and the resulting requests:
  
  

  Table 4-rdc: rild-debug codes and their resulting RIL requests

  	Request Issued	Function
  0	RIL_REQUEST_RESET_RADIO	Reset the radio
  1	RIL_REQUEST_RADIO_POWER	Power the radio off
  2	RIL_UNSOL_RESPONSE_VOICE_NETWORK_STATE_CHANGED	Calls voice network change callback
  3	RIL_REQUEST_OEM_HOOK_RAW	Enable the QXDM log
  4		Disable the QXDM log
  5	RIL_REQUEST_RADIO_POWER RIL_REQUEST_SET_NETWORK_SELECTION_AUTOMATIC	Power the radio on
  6	RIL_REQUEST_SETUP_DATA_CALL	Set up a data call
  7	RIL_REQUEST_DEACTIVATE_DATA_CALL	Deactivate (tear down) a data call
  8	RIL_REQUEST_DIAL	Dial a number
  9	RIL_REQUEST_ANSWER	Answer an incoming call
  10	RIL_REQUEST_HANGUP	Disconnectr an incoming call

The daemon also has its own debug facility - radio - which results in a dedicated logging device - /dev/log/radio. Inspecting this log file using logcat -b radio will dump plentiful amounts of debug information, which may (in some versions of Android) show the "AT" commands used by rild to dial numbers and establish codes.

If you look through the rild source, you might be suprised to find it consists of merely two files: the main rild.c and radiooptions.c. Most of the code is in libril and in other support libraries. The vendor usually supplies its own RIL implementation, so long as it conforms with the basic abstractions provided by the Android code. These abstractions are discussed in more detail in Chapter 15, which deals with connectivity.

The surfaceflinger provides the heart of the Android Graphics Stack. The notion of a "flinger", or in other words, a "compositor", is a component which merges one or more layers of input into a single layer of output. In the case of surfaceflinger, the components are graphics "surfaces" (instances of android.view.Surface), which are either rendered by the framework as the user lays out various views, or by the developer, in the case of raw or GL Surfaces. To communicate with the surfaceflinger, the framework looks up the SurfaceFlinger service using servicemanager. The flinger therefore needs no sockets, and its definition in /init.rc is a simple one:

service surfaceflinger /system/bin/surfaceflinger
    class main
    user system
    group graphics
    onrestart restart zygote

Android also uses the term "flinger" in its audio stack, with the "AudioFlinger" service, which is a component of mediaserver. This makes sense, as both flingers perform what is essentially the same function: adding bitmaps (surfaces) or samples (audio) together*. The surfaceflinger's architecture is quite complicated, and this hardly scratches its surface (no pun intended). Chapter 13 discusses this in more detail.

The bootanimation service is a small binary in /system/bin, which is started by /init as a placeholder while the media frameworks, and in particular surfaceflinger, are loading. It is defined in /init.rc thus:

service bootanim /system/bin/bootanimation
    class main
    user graphics
    group graphics
    disabled
    oneshot

The binary is essentially a very simple one - it starts up and looks for one of three zip files:

• /system/media/bootanimation-encrypted.zip: Used if the vold.decrypt property is set, indicating the file system is encrypted.
• /data/local/bootanimation.zip: Allowing the (advanced) user to drop their own animation file via adb push. If present, this will override the system boot animation.
• /system/media/bootanimation.zip: The system default animation, usually supplied by the device vendor

The three files are tried in order, and if none of them can be found, bootanimation defaults to alternating between two images - android-logo-[mask|shine].png, both hidden in the /assets/images folder in the /system/framework/framework-res.apk (you can easily see the png files yourself if you pull the framework-res.apk to your host and unzip the file).

Most device vendors will provide a bootanimation.zip with their logo or, in some cases, the carrier's logo. Likewise cyanogen and other Android "mods" deploy a zip of their own. Such zip files must contain a desc.txt, and an assortment of images which bootanimation will cycle through, as shown in Listing 4-ba. The first frame can be made to overlap with the ROM bootup image, if any, ensuring a smooth transition into the animation. Note that some vendors may drop the default binary in favor of their own animation and accompanying sound (e.g. as Samsung has done, with /system/bin/samsungani and proprietary qmg files). Alternatively, they may change the implementation to look at other directories (e.g. HTC One M8, looking for hTC_bootup_one.zip and vendor_boot.zip in /system/customize/resource). The Kindle's "FireOS" is somewhere in between, retaining the bootanimation binary, but modifying it to display the "Kindle Fire" logo rather than that of Android. Like most of the default binaries in the Android build, however, your device is very likely to contain the binary, even if it is unused. A quick way to figure out what files bootanimation is using is shown in the following experiment:

Experiment: Unpacking bootanimation.zip on a Nexus 5

The Nexus 5's boot animation is in /system/media/bootanimation.zip. You can pull it to a host using adb, and inspect its contents like so:

morpheus@Forge (~)$ adb pull /system/media/bootanimation.zip
1275 KB/s (1068873 bytes in 0.818s)
morpheus@Forge (~)$ unzip -t bootanimation.zip
Archive:  bootanimation.zip
    testing: desc.txt                 OK
    testing: part0/                   OK
    testing: part0/000.png            OK
    testing: part0/001.png            OK
	..
    testing: part1/057.png            OK
    testing: part1/058.png            OK
    testing: part1/059.png            OK
# After unzipping:
morpheus@Forge (~)$ cat desc.txt
1080 230 24
p 1 0 part0
p 0 0 part1
morpheus@Forge (~)$ file part1/000.png
000.png: PNG image data, 1080 x 230, 8-bit/color RGB, non-interlaced

The first line of the desc.txt specifies, in order, the width, height and frames-per-second (fps) of the boot animation. As shown above, this is consistent with the dimensions of the individual .png files.

The book's website contains miscellaneous boot animations you can experiment with on your device. Try dropping them into /data/local (searched before /system/media and see how easy it is to replace the boot animation. When you do, make sure the zip file is readable (if running bootanimation from adb as user shell), or else the animation will default to the "A N D R O I D" console text.

What makes bootanimation interesting is its raw (that is, non-framework) graphics capability. Since it is one of the first services to load, the frameworks have yet to initialize, leaving bootanimation to fend for itself using low level OpenGL and SKIA calls. These result in direct access to the device's frame buffer (/dev/graphics/fb0) directly, which is why is is run under uid graphics (the owner of the device node). We will take a close look at the low level graphics calls in Chapter 14.

The mediaserver is one of Android's most important components. It serves as a focal point for multimedia handling, controlling both playback and recording. It is defined in init.rc as follows:

service media /system/bin/mediaserver
    class main
    user media
    group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
    ioprio rt 4

As can be seen from the group membership, mediaserver requires permissions for audio, camera, network services, and the DRM framework (described next). The mediaserver, however, is really just a container for the actual services, somewhat like the concept of a service host (svchost.exe) in Windows. Table 4-mediasrv shows the services hosted:

KitKat's mediaserver lays the groundwork for extensions, by providing a registerExtensions() function, though at present no extensions are defined. We discuss the services in more detail in Chapter 11 and Chapter 13, for audio and video, respectively

drmserver

Android provides a Digital Rights Management (DRM) framework for copy-protected content, and the drmserver is the component responsible for being the focal point of all DRM requests. It is defined in /init.rc like so:

service drm /system/bin/drmserver
    class main
    user drm
    group drm system inet drmrpc

In truth, to say that Android provides a "framework" is somewhat of a misnomer, since it defines just the APIs, but not any actual content verification logic. The actual work is left for vendors to implement by a plug-in architecture. The plug-ins are shared object files, loaded by enumerating /vendor/lib/drm, and /system/lib/drm. The drmserver is thus quite small, consisting only of a main() with a few lines , which register a DrmManagerService (drm.drmManager) with the ServiceManager, and call on its internal DrmManager class to service incoming DRM calls from the framework, by finding the appropriate plug-in for the content.

shell@android:/ $ ls -l /vendor/lib/drm
/vendor/lib/drm: No such file or directory # No vendor specific DRM modules
1|shell@android:/ $ ls -l /system/lib/drm
-rw-r--r-- root     root        48336 2012-05-21 17:42 libdivxplugin.so
-rw-r--r-- root     root       117224 2012-05-21 17:42 libdrmwvmplugin.so
-rw-r--r-- root     root        68944 2012-05-21 17:42 libenyplugin.so
-rw-r--r-- root     root        48604 2012-05-21 17:42 libfwdlockengine.so
-rw-r--r-- root     root        65312 2012-05-21 17:42 libomaplugin.so
-rw-r--r-- root     root        48212 2012-05-21 17:42 libpiffplugin.so
-rw-r--r-- root     root        65012 2012-05-21 17:42 libplayreadyplugin.so
-rw-r--r-- root     root        64836 2012-05-21 17:42 libtzprplugin.so

To be considered valid and called by the DrmManager, a plug-in must conform to the DrmEngine specification defined in IDrmEngine.h. The DRM message flow is shown in Figure 4-drmflow:

The sources also include two plug-ins in frameworks/av/drm/libdrmframework/plugins: A sample "passthrough" DRM module, which can be used as a point of departure for plug-ins, and a "forward-lock" plug-in, implementing OMA V1 Forward Locking.

The remaining services in the main class are somewhat difficult to group, as they provide different facets of system support. Nonetheless, that does not make them any less important.

The installd daemon is responsible for package installation and removal. Whichever way a package is installed - by downloading the .apk directly, via Google Play or via adb install - installd gets involved in the process. The daemon itself, however, is passive, listening on a socket set up by init, over which commands (generated by the Android framework) are delivered. The socket is defined in the daemon's /init.rc service definition:

service installd /system/bin/installd
    class main
    socket installd stream 600 system system

Startup

startup of installd proceeds as shown in Figure s-ins:

Upon startup, the installd is charged with setting up and maintaining the directory structure where apps are to be installed. The base name is obtained from the ANDROID_DATA environment variable, set up by init to be /data. To this base, installd appends APP_SUBDIR (app/), PRIVATE_APP_SUBDIR (app-private/), APP_LIB_SUBDIR (app-lib) and MEDIA_SUBDIR (media/).

installd also obtains two other environment variables - ANDROID_ROOT (pointing to /system) and ASEC_MOUNTPOINT (pointing to /data/asec). Once it has deduced its directory structure, it proceeds to initialize the directories - making sure they exist (as /data initially starts up empty on factory default). As of Jellybean, installd is also charged with migrating the directory structure to allow multi-user. The steps taken are as follows:

• Create the /data/user directory, with ownership system:system and mode rwx--x--x
• Create a symbolic link from /data/user/0 to /data/data
• Upgrade /data/media to /data/media/0, moving any preexisting media there
• Create a /data/media/## directory for any other existing users
• Move OBBs from /data/media/0/Android/obb to /data/media/obb so they can be shared amongst users, and reduce overall filesystem usage
• Ensure user media folders (/data/media/##) exist and are media:media rwxrwx---.

Though it is started as root, as of Jellybean, the installd employs the principle of least privilege. One of the first calls it makes is to drop_privileges(), which sets the uid/gid to AID_INSTALL. It also makes use of Linux capabilities (q.v. Chapter 21) to maintain chown(2), setuid(2)/setgid(2) and DAC override, as it needs them to deploy and remove packages owned by different user and group ids.

Finally, installd acquires the control socket (/dev/socket/installd), and enters an accept loop, waiting for connections from client. Once a client forms a connection, an inner read/execute loop handles this connection until it closes (meaning that installd can only handle only one client at any given time). An interesting observation is the installd doesn't perform any verification of "caller id" on the socket, and relies on the socket being chmod()ed to system:system rw-------. Because only one client can be served at a time, there is the implicit assumption that it is held by the PackageManager. Note also, that installd performs no signature verification on APKs, assuming that its caller has done so already.

Commands

The framework uses the PackageManager, via the undocumented com.android.server.pm.Installer class, to provide a Dalvik-level API trusted applications can use in order to install or remove the various apps. The API methods are mapped to the commands sent over the socket (as strings, preceded by a two byte binary length),which are shown in table 4-instdcmds:

The phases of package installation are discussed in Chapter 6. The Installer service, which is the Java front-end to installd, is discussed in the next chapter.

The keystore service is, as its name implies, provides a storage service for keys. By design, it can provide storage for any arbitrary name-value pairs, though in practice it is only used for key storage. It is defined in /init.rc as follows:

service keystore /system/bin/keystore /data/misc/keystore
    class main
    user keystore
    group keystore drmrpc

The argument to the keystore daemon - /data/misc/keystore - is the directory used to hold the various keystore files. As of Jellybean, each user has its own keystore directory, with the primary user using /data/misc/keystore/0.

Unlike other daemons, keystore doesn't use a socket. It is accessible only via servicemanager, wherein it is published using the name android.security.keystore. The framework client of the keystore service is the java.security.KeyStore class. This is a developer-accessible class modeled after the Java standard, and is reasonably documented, but not fully so: There are quite a few other public methods available, which the Android documentation chooses to omit. There is also a keystore_cli command which allows command line native-level access to the keystore, though not all of the service methods are (at the time of writing) implemented. Table 4-keystorecmds shows the commands exposed by the class and service, showing the commands not implemented by the cli as grayed.

Access to keys is governed by uid (hence its use as an argument), so each application effectively has its own private store.In addition, similar to the ACLs hard coded in init, the keystore daemon maintains a user_perms array of permissions, with specific exclusions for AID_SYSTEM (all access), AID_VPN and AID_WIFI (get, sign and verify only) and AID_ROOT (get only).

The keystore implementation, and cryptography in general, is discussed in Chapter 21.

debuggerd

Try as hard as developers will, their applications will inevitably face bugs, which will result in crashes. In order to fix those bugs, there must be an efficient mechanism to collect the crash data. On a desktop system, the crash results in a core dump - but that is simply not an option in a mobile device. Core dumps are often very large - in the hundreds of MB and sometimes more - and space is limited. What more, even if the core dump was saved, it's not a trivial matter to move such large files out of the device.

Similar to iOS's CrashReporter, Android introduces debuggerd. This small daemon is normally dormant, listening on its socket, until an application crashes. All processes on Android, by virtue of linkage with bionic, automatically install a signal handler for the lethal signals, shown in table 4-dbgrsig:

All signals use the same action, debuggerd_signal_handler, which establishes a connection to debuggerd over its socket, and sends it a message. The message wakes up the daemon, and makes it engrave a tombstone. A tombstone is, essentially, a crash report, which debuggerd generates by attaching to the failing process (using Linux's ptrace(2) APIs), catching its signal for it, and inspecting its memory. This way, rather than a full core dump, a tombstone can (hopefully) capture the essence of a crash and perform the basic crash processing. Tombstones are created in /data/tombstones, and are discussed in detail in Chapter6.

If the debug.db.uid property is set to the uid of the crashing process, debuggerd freezes the process in its final death throes and waits for user to start gdbserver. It logs a message which can be easily seen in logcat:

I/DEBUG   (   24): ********************************************************
I/DEBUG   (   24): * Process pid has been suspended while crashing.  To
I/DEBUG   (   24): * attach gdbserver for a gdb connection on port 5039
I/DEBUG   (   24): * and start gdbclient:
I/DEBUG   (   24): *
I/DEBUG   (   24): *     gdbclient app_process :5039 pid
I/DEBUG   (   24): *
I/DEBUG   (   24): * Wait for gdb to start, then press HOME or VOLUME DOWN key
I/DEBUG   (   24): * to let the process continue crashing.
I/DEBUG   (   24): ********************************************************

The debuggerd uses the low level Linux EV_* APIs (discussed in Chapter 11) to wait until the user presses one of the keys, and lights up the debug (red) led on the device to draw the user's attention. We discuss the debuggerd in general and tombstones in particular, in Chapter 7.

Not all Android devices necessary support SDCards - but in those which do, the sdcard daemon provides the user-mode support.

Though last, both alphabetically and in this chapter, the zygote is hardly the least of all services. It provides the core support for all of the Android Framework Runtime services, in the form of an initialized empty Dalvik Virtual Machine, stopped just shy of the main class loading. The /init.rc definition is as follows:

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
    class main
    socket zygote stream 660 root system
    onrestart write /sys/android_power/request_state wake
    onrestart write /sys/power/state on
    onrestart restart media
    onrestart restart netd

As the listing shows, zygote's "true name" is app_process. The name "zygote" however, is far more apt, as this process mimics, in some senses, its namesake. Just like the biological zygote, this process is full of unlimited potential - it can load any Dalvik class specified, and can become any user. This, however, is a one-way process (again, just like the biological parallel). The rest of the command line provides the arguments, all of which but the double-dashed get passed directly to the Dalvik VM. The last two arguments get processed by app_process itself, and result in the VM loading the Zygote class, and fork()ing to start the system_server process. The app_process can also accept a --nice-name argument to rename itself.

The system_server process goes on to load all of the Android runtime frameworks, whereas the Zygote binds its socket (/dev/socket/zygote) to listen for incoming requests. When such requests will arrive, they will contain a class name to load, and Zygote will similarly fork() and load the classes - which will result in the creation of a new app. A new "Life" will be born. But all these apps, and indeed zygote itself, are, from the Linux perspective, merely instances of app_process, which renames itself accordingly (and you can verify with an ls -l /proc/pid/exe).

We discuss the internals of both Zygote and system_server in depth in Chapter 8.