I: The Evolution of Android's Architecture

Android version history

Over its six short years, Android has already undergone no less than 11 versions. When one considers the API versions (which map the internal set of APIs to the catchier condiment type), this number increases to 19. Enumerating the many framework features introduced in each version would be tedious and likely miss out on a few, so this section instead aims to provide a more technical look, focusing on those API differences at the system (rather than framework) level, as well as other noteworthy observations. Those seeking more information about changes are suggested to read the comprehensive Wikipedia Entry, or check the Android documentation for the respective versions.

Table 1-1 shows the Android version history, and maps the official release version to that of the API and the kernel. Note that the kernel versions don't necessarily match in all devices, as some vendors compile their own kernel.

Actual usage (and probably some personal) data is compiled by Google, and is made available through the Dashboards on the Android Developer Website. Since there are virtually no devices remaining with versions older than Froyo, this work does not make any attempt to discuss them.

Froyo

FroYo (Frozen Yogurt) was the first version of Android to support application installation on external media (i.e. SDCards). It additionally introduced the notion of Android Secure Containers (ASEC), in order to provide security for files on external media, which by its nature is usually FAT formatted volumes (The ASEC mechanism is discussed in Chapter 2). Another useful feature introduced in this version was USB tethering (connecting the device and using its Internet connection, as discussed in Chapter 15. Lastly, FroYo brought significant speed improved to Dalvik, with the introduction of Just-In-Time (JIT) compilation by a dedicated thread.

Gingerbread

Gingerbread was the first version of Android to gain widespread adoption, and with good reason: It introduced significant enhancements to the system. At the Dalvik layer, concurrent garbage collection was introduced, which improved application response time by running GC in parallel, rather than pausing the application during the process. Likewise, the JIT mechanism improved on Froyo's. The sensor APIs underwent a complete revamp, extending the sensor HAL to support more sensor types, and making them more accessible to native code. Support for native code was bolstered in other areas as well, providing native access to audio, graphics, storage and even the activity manager. Gingerbread was also first to introduce support for Near-Field-Communications (NFC), though it was only till later (with ICS) that NFC was to be adopted into ubiquity by Android vendors.

Another noteworthy addition is support for OBB - opaque binary blobs (referred to as "APK expansion files") as a workaround to the size limitation of application package sizes, and provide optional encryption. OBB files are discussed in Chapter 2. Last, but not least, Gingerbread adopted Ext4 in place of YAFFS as the default filesystem.

All these improvements aside, Gingerbread is actually most notorious for being the most insecure version of Android to date. Apart from glitches with the stock SMS app (which routed messages to the wrong recipients), it was riddled with quite a few vulnerabilities which led to an explosion in rootkit-grade malware.

Honeycomb

Honeycomb brought Android to tablets. In fact, it was a "tablet-only" release, in that the source tree was never fully released nor meant to be used for phones (though some vendors still tried to use it nonetheless). The main change was the introduction of fragments, which - like Windows' Multiple Document Interface (MDI) allow several client areas to coexist simultaneously, rather than the single layout architecture which was previously used.

Honeycomb also offered significant improvements in graphics - introducing hardware accelerated OpenGL rendering for 2D, and introduced Renderscript, which is Android's own GL-like language.

Another feature of importance was the advent of storage encryption. Honeycomb was the first version of Android to offer low level encryption of the user data partition, bringing it in line with iOS 4, which introduced it as well. The disk encryption in Android is carried out by the Linux device mapper, and can be thought of as the next step, following the Android Secure Storage which was introduced in Froyo.

More important than the user space features was the introduction of multi-core support into Android. Primarily, this involved a recompilation of the Linux kernel to support SMP (as can be seen with the BusyBox uname tool, or /proc/version). Tablets were the first devices to utilize multi-core architectures, which have since proliferated to all but the cheapest devices. The Android Documentation details the changes required for code to be SMP safe - most of these are primarily in native code, though some aspects apply to Java as well.

Honeycomb was the only version of Android whose source code was not made open (aside from select portions). This made some vendors wary, and brought to mind the fact that even though Android is free, Google still controls the system, and its licensing may change at any point in the future, if Google so sees fit.

Ice Cream Sandwich

Ice Cream Sandwich (ICS) brought many changes to Android, as can be expected from a 4.0 release. Aside from the myriad UI enhancements, those changes which were noticeable to users included significant connectivity enhancements - The Android VPN Framework, WiFi Direct and Android Beam.

ICS adds another API often overlooked by developers - the onTrimMemory() callback, which is called at times of memory pressure. According to the integer code specified, an application should release as much memory as possible. Note, however, that this API is advisory - applications can just choose to ignore the callback (which all too many, in fact, do).

JellyBean

JellyBean's most prominent user-facing feature is in its support for multiple users on the same device. This feature, more useful on tablets than phones (and formally only enabled on the former), allow several users to operate the device. Though only one user can be actively logged on, each user has a different UI, with separate widgets and applications and - most importantly - isolation of application data. We discuss the implementation of this feature in detail in Chapter 21. Windows 8 also supports multiple users, and iOS will likely join the trend with iOS 8.

In addition to this, and alongside the slew of UI features, JellyBean also provided application encryption and forward locking, building on FroYo's ASEC containers. One of the main drawbacks of Android's open nature at the time was that it was trivial to pirate apps by moving them between devices via the SDCard. ASEC provides a secure container for data, which can be encrypted by the application, and made readable only by the application's uid. This will, as mentioned, be covered in Chapter 2.

JellyBean went through three API versions, which introduced many changes, both over and under the hood. API 17 also brought SELinux to Android for the first time (as detailed in Chapter 21), and sealed a gaping USB debugging hole by forcing authentication over ADB. Notable changes in API 18 were support for OpenGL ES 3.0, Bluetooth Audio-Video Remote Control Profile (AVRCP) 1.3 and Bluetooth Low Energy (LE) support, as well as the App Ops service (whose UI was later removed in 4.4.1), which allows tweaking application permissions.

KitKat

Version 4.4 of Android, codename "KitKat", is (at the time of writing) the latest and greatest version of Android. It represents a genuine attempt by Google to combat the fragmentation of the Android universe: Though JellyBean is the single most popular version, a large percentage of devices still use old versions - notably GingerBread, which are not only obsolete, but hamper apps from running due to their old API versions. Additionally, middle and high-end market become saturated, and in the entry-level category Android faces competition from FireFox OS and others.

KitKat's "pet project" was "svelte", an initiative to enable a smooth experience on virtually any device, including low-end devices, with 512MB of RAM. Part of the rationale behind it is that a smoother OS with less resource requirements would enable all vendors - even those with entry level device - to offer the latest OS version, thereby ending fragmentation. Doing so involved many under-the-hood changes, such as rewriting framework code to use less memory, and starting services in a serial manner (to reduce memory pressure). A new API was added to detect low RAM devices (ActivityManager.isLowRamDevice(), which returns the value of the ro.config.low_ram property). Using this API, developers can detect the amount of RAM available, and plan resources accordingly. KitKat also added the procstats service to give developers as much information as possible on their application's footprint.

For those devices which do have RAM, KitKat utilizes a new feature of the Linux Kernel, called zRAM. This feature is in fact newer than KitKat itself, having only been officially stabilized and merged in version 3.14 (KitKat uses 3.4), but Google was an early adopter in both ChromeOS and Android. The features enables swapping to RAM, and thus overcomes one of the major limitations of mobile devices - the lack of swap on flash devices. While swapping to RAM might sound somewhat counterproductive, it is in fact a dramatic improvement, as the swapped pages are compressed (thus saving overall RAM usage) and quite fast to retrieve. This is discussed in Chapter 16.

By uncanny coincidence, compressed memory also made its debut in iOS version 7.0, a few months before KitKat was announced. Several other interesting features in KitKat may have borrowed from iOS 7.0 include a step counter (software-defined sensor, as an answer to Apple's M7), as well as timer coalescing and sensor batching. The latter two are a significant improvement that helps maximize battery life. To do so, Android actually reduces the granularity of timers and updates from sensors, so as to make them coincide at slightly larger intervals. This can greatly improve battery time - both directly (allowing CPU longer periods of idle time), and indirectly (reducing the overall number of wakeups, which are costly both in power and performance).

Other notable features in Kitkat include Bluetooth MAP support, Infrared Blaster (ConsumerIr) APIs, A new printing framework, and NFC host card emulation. Probably the most far reaching change, however, was unannounced and kept under the scenes: introducing the Android RunTime (ART) as a replacement to Dalvik. This likely signals a future drection for Android, as we discuss later in this chapter.

At the time of writing, KitKat has undergone two minor revisions, and its most recent version is 4.4.4. Those revisions are mostly bug fixes and camera enhancements, and do not change the API version, though internal APIs have been modified.

Experiment: Figuring out your device's Android version

Though vendors customize Android in a variety of ways, the basic underlying system is the same. Most Android users are familiar with the Settings >> System >> About Phone GUI, which provides details about the Android version used*. The relevant class is com.android.settings.DeviceInfoSettings (found under the AOSP's packages/apps/settings), which uses the android.os.Build class. The values, however, are obtained from system properties, so an often simpler way of getting to those values is directly, using the getprop tool. This is shown in Figure 1-1:

The property settings, which are generated from the AOSP and placed into /system/build.prop, hold true on modified builds as well - even those as heavily customized as Amazon's "FireOS". The most useful properties are ro.build.version.sdk (API version), and ro.build.fingerprint, which is itself an amalgam of several other properties, for example:

generic/sdk_phone_armv7/generic:5.0/LRX09D/1504858:eng/test-keys

Property	Describes
ro.product.manufacturer	Vendor id
ro.product.name	Device code name. For Google - fish names
ro.build.product:version.release	Product name and Android base version
ro.build.id	first letter: version (rest described in the documentation)
ro.build.version.incremental	Internal build number, auto-incremented by AOSP build system
ro.build.type	user: user facing, eng: Engineers/internal
ro.build.tags	release-keys: production system, actual certificates. test-keys: development

* - As of JellyBean, the "Build Version" provides the backdoor functionality to the Developer Settings (which include ADB), by clicking seven times on the view.

Android vs. Linux

Not just another Linux Distribution

Linux, the core of Android, has been around for well over a decade before Android was even conceived. Linux is a fully open source operating system, whose kernel started as a Master's Thesis of one, Linus Torvalds, and has since gained worldwide fame and adoption. A kernel alone, however, does not a full operating system make. Torvals decided to release his work as open source, and attracted developers who extended it further, by providing components for it - binaries both ported from other UN*X systems, as well as original ones. Linux exploded in popularity as a free alternative to the expensive UN*X systems of the time, effectively undercutting them and leading to the demise of most.

Along its rapid evolution, Linux attracted commercial interest. Companies, whose sole purpose was to package the kernel along with additional binaries, sprouted and provided "distributions" of Linux. These companies often provided Linux for free, basing their entire business model on support. At times, "professional" or "enterprise" grade distributions, containing custom tweaks or specialized tools, were provided, costing money to license.

Linux quickly became the de facto operating system of the embedded space. Contrary to other players in the field, such as Windows CE (which required too many resources), and real time operating systems such as PSOS or VxWorks (both of which involved heavy licensing fees), Linux offered a platform that was not only free, but fully customizable and light weight. One company, MontaVista, based its entire business model on porting Linux to the embedded space - notably, the ARM, MIPS and PowerPC architectures. The port provided for Embedded platforms the same functionality as that which was provided on the desktop - a fully featured shell environment. All for a generous licensing fee.

But developers needed more. Long gone are the days of shell interfaces, and all users (save for battle-hardened veterans) expect a graphical user interface from their operating system. Linux relied on X-Windows, the traditional UN*X Windows architecture, for its GUI. Setting up a GUI on an embedded platform was far from straightforward. Graphics programming using X-Windows API was also quite cumbersome. Additionally, vendors such as Montavista provided just the basic platform. Developers still had to port additional components and create their own, often having to start from scratch.

And then came Android.

Google spotted the promise in a mobile operating system back in 2005, when they acquired Android, then a small startup by Andy Rubin, in 2005. Android disappeared off the map, till its resurgence some years later, unsurprisingly shortly Apple's "iPhoneOS". Mobile vendors, trying to adapt to the revolutionary device, quickly wanted to provide a similar experience - and needed to catch up quickly.

Android's novelty arises from what it aims to provide - not just another Linux distribution - but a full software stack. The term "stack" implies several layers, and - indeed - Android provided not just the basic kernel and shell binaries, but also a self-contained GUI environment, and a rich set of frameworks. Coupled with a simple to use development language - Java - Android gives developers a true Rapid Application Development (RAD) environment, as they can draw on pre-written, well-tested code in the frameworks to access advanced functionality - such as Cameras, motion sensors, GUI Widgets and more - in a few lines of code. With features that at first borrowed heavily from iOS and later improved on them, Android became the de-facto OS for Mobile, much as Windows is for the Desktop, or Linux was elsewhere.

Android has since had its hegemony constantly reinforced by the feedback loop of its ecosystem - Android's "App MarketPlace", which quickly followed Apple's "App Store", adopted that model to allow developers to quickly distribute their apps in a manner far more (and indeed, some would say, too) relaxed with virtually no hurdles. The result is that Google Play (as the MarketPlace is now known) has surpassed the App Store and offers millions of apps. Adopting Android provides a mobile vendor with instant access and compatibility with those apps.

In a sense, Android has done to MontaVista and other Embedded Linux firms what Linux has done to UN*X and other competitors - undercutting by providing a totally free alternative. Google pushes Android for free, with no licensing fees (at least, for now), and fairly relaxed terms of use (though those are getting tighter, slowly but surely). No wonder, then, that Android has risen in only a few years to achieve almost total hegemony of about 80% of the global mobile market, leaving only a persistent bastion of iOS (presently at about 20%), along with nigh-insignificant dregs of Windows Mobile and BlackBerry. A mobile vendor basically has only very limited options in a choice of operating system: develop a homegrown one, or go with a ready made one. Nearly all opt for the latter*, and then the choice boils down to Android, or Windows Mobile. Microsoft has tried to follow the Android model and offer its system for free - but the effort was too little, and far too late - as it lacks the ecosystem. BlackBerry, on its own part, has ported the Android runtime to its own OS, hoping to win back market share by providing runtime compatibility with the multitude of Android Apps.

Commonalities and Divergences from Linux

Android is built on top of Linux, but modifies it in substantial ways - including some which break compatibility with the mainstream. The Android kernel source tree diverged from the mainline kernel around version 2.6.27, but has been converging since version 3.3. In user-mode, Google maintains the frameworks and runtime of the AOSP (Android Open Source Project) in an entirely separate repository. From a high-level perspective, though it's hard to quantify exactly how much the two OSes differ, a safe estimate would be that Android and Linux are about 95% alike at the kernel level, and about 65% or so at the user-mode.

This guesstimate is drawn by taking into consideration that, at the kernel level, aside from a few differences (ARM platform and drivers not withstanding), the rest of the kernel source is unmodified. Those differences (which include IPC, memory and logging enhancements) are collectively referred to as Androidisms, and most have in fact by now been merged into the mainline kernel. Androidisms are discussed in great detail detail in Chapter 19.

At the user-mode level, there is more of a divergence, introducing two entirely new components - the Dalvik runtime and the Hardware Abstraction Layer - as well as replacing glibc with Bionic, and providing a custom version of init, the system startup daemon. The underlying OS, however, still remains for the most part unmodified, with native binaries, processes and threads behaving as they do on Linux. This enables the approach taken in this book, of discussing low-level Linux-based approaches for debugging and tracing, as is discussed in Chapter 7 (for process, thread and memory management), and Chapter 8 (Debugging).

Android also makes more clever use of features present in Linux, though left unused in most desktop distributions. These include control groups, low-memory conditions (Linux oom, which Android expands on with its Low Memory Killer), and security features - capabilities and SElinux (as discussed in Chapter 21). We expand on the kernel features heavily employed by Android in Chapter 18.

* - Mobile device vendors are becoming increasingly uneasy with two major shortcomings of Android: The first, is the common feature base, which makes it hard to differentiate their product from others. The second, is increased dependency on Google, which actually strives to enforce the Android look and feel across devices. This has led some vendors (notably, Samsung) to look at alternatives (e.g. Tizen). At present, Android seems to be fully entrenched and not likely to lose dominance any time soon.

 

Figure 1-2 compares and contrasts the software stacks provided by Linux and Android. We then move to explore the notable differences, in turn.

Most developers are probably familiar with the Google-provided architectural diagram (returned by searching for "Android Architecture") ad nauseam (and, indeed, virtually all other books on Android include it in their introduction - often with the exact same colors). That diagram, in this author's opinion, is simplified and not at all accurate in its representation of layers (For example, JNI is entirely overlooked). As the layers unfold, this slightly different rendition of the architecture will hopefully "make sense" just as much as, if not more than, the traditional diagram.

The Android Frameworks

Android owes a key part of its success to its rich set of frameworks. Without them, Android would have likely ended up as just another embedded Linux distribution (and would have in fact gone the way of MontaVista, which was highly popular before Android made its debut). By providing the frameworks, Android facilitates the application creation process, allowing developers to use the higher-level Java language, rather than low-level C/C++. The addition of the frameworks further facilitates the process, as developers can draw on the plentiful APIs, which handle graphics, audio and hardware access. Unlike X-Windows and GNOME/KDE, these are far simpler, and operate in a much more straightforward manner.

Through the use of Java package naming, Android frameworks are divided into separate namespaces, according to their functionality. Packages in the android.* namespace are available for use by developers. Packages in com.android.* are internal. Android also supports most of the standard Java runtime packages in the java.* namespace. Table 1-2 shows the breakdown of frameworks by package, sorted by the API version they were introduced in, so as to give an idea as to the evolution of the operating system features. Note that the table only shows when frameworks made their debut, and does not show their expansion, which does occur in between API versions, as more classes are added.

 

Table 1-2: The Android Frameworks

Package Name	API	Contents
android.app	1	Application Support
android.content		Content providers
android.database		Database support, mostly SQLite
android.graphics		Graphics support
android.opengl		OpenGL Graphics support
android.hardware		Camera, input and sensor support
android.location		Location support
android.media		Media support
android.net		Network support built over java.net APIs (similar to iOS's CFNetwork)
android.os		Core OS Service and IPC support
android.provider		Built-in Android content-providers
android.sax		SAX XML Parsers
android.telephony		Core Telephony support
android.text		Text rendering
android.view		UI Components (similar to iOS's UIView)
android.webkit		Webkit browser controls
android.widget		Application widgets
android.speech	3	Speech recognition and Speech-to-Text
android.accounts	4	Support for account management and authentication.
android.gesture		Custom gesture support
android.accessibilityservice	5	Accessibility support
android.bluetooth		Bluetooth support
android.media.audiofx	9	Audio Effects support
android.net.sip		Support for VoIP using the Session Initiation Protocol (RFC3261)
android.os.storage		Support for Opaque Binary Blobs (OBB)
android.nfc		Support for Near Field Communication
android.animation	11	Animation of views and objects
android.drm		Digital Rights Management and copy protection
android.renderscript		RenderScript (OpenCL like computation language)
android.hardware.usb	12	USB Peripheral support
android.mtp		MTP/PTP support for connected cameras, etc
android.net.rtp		Support for the Real-Time-Protocol (RFC3501)
android.media.effect	14	Image and Video Effects support
android.net.wifi.p2p		Support for Wi-Fi Direct (Peer-To-Peer)
android.security		Support for keychains and keystores
android.net.nsd	16	Neighbor-Service-Discovery through Multicast DNS (Bonjour)
android.hardware.input		Input device listeners
android.hardware.display	17	External and virtual display support

 

Table 1-2 (cont.): The Android Frameworks

Package Name	API	Contents
android.hardware.location	18	Geofencing support
android.graphics.pdf	19	PDF Rendering
android.print		Support for external printing

In practice, the entire set of frameworks is bundled into several Java ARchive (.jar) files on the device, in /system/framework and - in L - precompiled into the boot.art file. Although the AOSP is open source, it can come in quite useful to locate a package directly in the JAR itself, which you can do by invoking dexdump (or the book's companion tool, dexter) on the classes.dex files inside the JARs.

The Dalvik Virtual Machine

Android's other notable addition is the introduction of the Dalvik Virtual Machine. This VM became key to making Android workable on mobile devices back when 256M of memory was considered "plenty". Dalvik was not the first type of Virtual Machine to be attempted on mobile devices - Sun Microsystems hoped to push Java 2 Mobile Edition (J2ME), but with very little success.

The Dalvik VM, though seemingly java-esque, is actually not a Java Virtual Machine. Though not too far-removed from one, it runs a different form of bytecode (called DEX, for Dalvik Executable), and is more optimized for efficiency and sharing memory than the Java Virtual Machine designed by Sun/Oracle. It is those optimizations which enabled it to prevail despite the strict constraints of mobile platforms, which have felled Java (specifically, J2ME) from gaining ground outside very limited implementations.

As this book goes to print, Dalvik is being superseded by the Android RunTime (ART), as described later in this chapter. Contrary to popular belief, however, this does not mean Dalvik is going away: Only the Just-In-Time (JIT) compilation aspect of it has been replaced, but the file format (DEX) is still very much alive, as are the key architectural concepts. We therefore discuss both Dalvik in ART in great detail in Chapter 10.

JNI

Android Applications run in the virtual machine, but at times need to escape it - usually to access hardware or other device (or chipset) specific features. Dalvik therefore allows the inclusion of native libraries (ELF shared objects) in application code, through the Java Native Interface (JNI).

Android has somewhat of a love/hate relationship with JNI. No doubt vendors would be happier with pure Dalvik applications, as those are confined in the VM, and thus remain agnostic to the underlying architecture. In this way, Android applications would run seamless on Intel, ARM, or any other architecture alike. On the other hand, the VM environment is not without its limits (especially when it concerns graphics) and drawbacks (notably decompilation). It is therefore not at all uncommon to see JNI used in applications optimizing for performance, or seeking resistance to reverse engineering. Google therefore provides the Native Development Kit (NDK), which developers can use to build native libraries (and binaries).

Not all applications use JNI, but in those that do, JNI libraries can be easily seen in the package (.apk) since they are in a separate folder: /lib/architecture. A good example of this can be found in the DropBox App (here in an output from a Galaxy Tab 3 10.1), providing JNI support for no less than four different architectures:

root@Tab3:/ # % unzip -l /system/app/Dropbox.apk | grep lib/
    17532  05-14-13 23:11   lib/armeabi-v7a/libDbxFileObserver.so
    17528  05-14-13 23:11   lib/armeabi/libDbxFileObserver.so
     9352  05-14-13 23:11   lib/x86/libDbxFileObserver.so
    71076  05-14-13 23:11   lib/mips/libDbxFileObserver.so

 

JNI normally works seamlessly across ARM devices (which comprise the vast majority), though processor version differences (e.g. ARMv6, ARMv7) do require different libraries (hence "armeabi" and "armeabi-v7a" in the output). When it comes to x86 architectures, JNI is a major headache for Intel, who would like to see more vendors use its chipsets for Android. Rather than depend on the app developers to compile an x86 specific version (most don't), Intel provides a closed-source ARM emulation called Houdini (discussed later in Chapter 7) as part of their Android distribution. This emulator, (along with a few minor modifications in Dalvik), enables ARM native libraries to work on Intel architectures.

Native Binaries

From the Linux perspective, all executables are ELF binaries. Android's critical system component are implemented in C/C++, and are compiled into native binaries. User applications are compiled into Dalvik bytecode, but the bytecode runs in the context of a Dalvik Virtual machine, which is, in and of itself, an ELF binary. Thus, while most developers remain oblivious to binaries, they nonetheless play an important role in Android.

Binaries are usually located in /system/bin, and /system/xbin (with a few critical binaries located in /sbin). Most binaries are usually the same across all devices, being part of the AOSP, but it is not uncommon to find additional binaries from the vendor or chipset manufacturer (e.g. mpdecision, on Qualcomm MSM multi-core devices). You can see a list of processes loaded from native binaries at any time by filtering the ps command, with the AOSP binaries highlighted:

shell@htc_m8wl:/ $ ps | grep " /" | cut -c1-22,55-  
root      1     0      /init
root      218   1      /sbin/ueventd
root      365   1      /sbin/healthd
system    367   1      /system/bin/servicemanager
root      368   1      /system/bin/vold
radio     369   1      /system/bin/rild
system    370   1      /system/bin/surfaceflinger
root      371   1      /system/bin/pnpmgr 
nobody    373   1      /system/bin/rmt_storage        # QCOM specific
radio     375   1      /system/bin/qmuxd              # QCOM specific
radio     376   1      /system/bin/netmgrd
root      379   1      /sbin/tpd
root      380   1      /system/bin/netd
root      384   1      /system/bin/debuggerd
drm       387   1      /system/bin/drmserver
media     388   1      /system/bin/mediaserver
install   389   1      /system/bin/installd
keystore  390   1      /system/bin/keystore
shell     391   1      /system/bin/dumpstate
root      393   1      /system/bin/thermal-engine     # QCOM specific
root      395   1      /system/bin/memlock            # HTC specific
root      397   1      /system/bin/clockd             # HTC Specific
system    400   1      /system/bin/qseecomd           # QCOM TrustZone 
root      404   1      /system/bin/cand           
system    505   400    /system/bin/qseecomd           # QCOM TrustZone
media_rw  844   1      /system/bin/sdcard
system    847   1      /system/bin/time_daemon        # QCOM specific
root      848   1      /system/bin/dmagent            # HTC specific: QCOM DIAG
nobody    850   1      /system/bin/hvdcp              # QCOM Quich charge support
system    851   1      /system/bin/wcnss_service      # QCOM WLan
root      852   1      /system/bin/htc_ebdlogd        # HTC Specific
root      868   852    /system/bin/logcat2
media     919   1      /system/bin/adsprpcd           # QCOM Application DSP
root      1170  1      /system/bin/logwrapper
wifi      1171  1170   /system/bin/wpa_supplicant
media_rw  1631  1      /system/bin/sdcard
root      1637  1      /system/bin/mpdecision         # QCOM SMP Policy
shell     12149 1      /sbin/adbd
shell     12277 12149  /system/bin/sh
camera    23853 1      /system/bin/mm-qcamera-daemon  # QCOM camera support

 

ELF is a Linux (and UN*X) standard, so the standard ELF parsing tools apply to Android as well. The NDK provides several of these tools as part of its cross compiler. We discuss and demonstrate their usage in detail throughout Chapter 8.

Bionic

Contrary to Linux distributions, which use GNU's LibC as their core runtime (the familiar libc.so), Android elects to use its own C-runtime library, which is called Bionic. This is touted as being motivated chiefly by simplicity, though in practice there is a legal consideration as well - The GNU public license (GPL) places limitations on code which can use GLibC (similar in some respects to GPL portions in the kernel), and Google sought to avoid that. Bionic is open source, but uses a hybrid of the BSD license (which is far more permissive for third party linkage) as well as Android's own license.

Omissions

Legal issues aside, Bionic is indeed more lightweight than GLibC, and more efficient for Android's purposes, leaving out features deemed unnecessary or too complicated. Notable omissions are:

• Streamlined system call support: Since system calls are called frequently, Bionic aims to optimize them by providing the thinnest wrappers possible. The system call stubs are generated with the help of bionic/libc/SYSCALLS.TXT. Some system calls are not at all exported.
• No support for System V IPC: Among the system calls not exported by Bionic are those dealing with UN*X System V Inter-Process-Communication (sem[ctl|get|op] and Shared Memory (shm[at|dt|get|ctl). This was a design decision in Android, deprecating these forms of IPC in favor of Android's own (ASHMem and Binder, described in Chapter 19 and Chapter 20, respectively).
• Limited Pthread functionality: On the one hand, Pthread support is built-in to Bionic (i.e. not a separate libpthread.so). On the other, the pthread support is not full, with the most notable feature missing is support for thread cancellation, via pthread_cancel. Mutex support is also stripped down, made more efficient by relying on the kernel's fast mutex (the futex(2) system call), but higher level IPC objects (e.g. rwlocks) have been left out.
• Limited C++ support: Though C++ is supported (indeed, most of Android's code is written in C++), exceptions are not. Likewise, the Standard Template Library (STL) is not included, though there is no restriction for linking against it manually.
• No support for Locales and/or wide characters: Bionic natively needs only ASCII, though Unicode is also supported via libutils.so

The omissions make sense, considering that most code is meant to be done in the virtual machine, and the VM itself is written to avoid needing these functions: For example, the VM has its own thread management and Unicode support (via ICU). These omissions do, however, pose challenges to native code developers, especially those who seek to port libraries and executables from Linux to Android, as we discuss later.

 

Additions

Bionic also adds quite a few features to the standard LibC, which are optimized for Android. These include:

• System Properties: Properties are a unique feature of Android, which allow both the system as well as applications to supply various configuration and operational parameters in a simple key/value store. This is similar to the notion of Java properties (and, in fact, is accessible through Java's System.properties). Android relies heavily on this mechanism, which is supplied through a shared memory region, accessible and read-only to all processes on the system, but settable only through /init. We discuss the implementation of properties in Chapter 4.
• Hard-coded UID/GID implementation: Rather than rely on the passwd and group files as traditional UN*X does, Android opts instead to hard-code the ids, and emulate getpwnam(3) and friends. The reasoning for this becomes clear when Android's security model is considered: Every application is assigned its own UID and GID (beginning with 10000) and those IDs are then mapped to the human readable app_uXXX (or, as of JellyBean, uXX_aYYY) format. Additionally, Android reserves the lower UID/GID range (1000-9999) for its own subsystems. The AIDs (defined along with directory permissions in android_filesystem_config.h) are described in more detail in Chapter 21, which deals with security.
• Built-in DNS resolution: Bionic integrates the DNS name-to-IP resolution code (traditionally in libresolv.so). The code used in Bionic is more secure (randomizes both source port and query ID, to mitigate birthday attacks), and introduces a novel feature - per-process DNS resolution. This allows capturing and redirecting DNS requests by specific applications, through the definition of net.dns.pid system properties. The DNS configuration itself is also stored in properties (net.dns#). The nsswitch.conf, which on Linux allows name resolution through alternate protocols (e.g. NIS, LDAP) is understandably not supported, though resolv.conf is still supported (in /system/etc).
• Hard coded services and protocols: Doing away with libresolv.so entirely, Android removes support for the protocols and services files (commonly found in /etc on UN*X), and emulates getservent(3) (through its internal __res_get_static()). getprotoent(3) is not supported.

Porting Challenges

As with the omissions, the additions pose a challenge when trying to port code the other way around - that is, from Android to Linux. If these could be overcome, one could ostensibly port Dalvik to Linux or other OSes (as indeed some developers have, discussed in Chapter 10), and have Android apps working on desktops, as well).

Bionic presents the main hurdle for porting code to and from Android. While to some extent compatible with GNU LibC, the additions and omissions described above do mean that some more advanced features - notably multithreading - will not port. For some source packages, however, all it takes is recompilation with the NDK. In this way, many tar ball packages can be ported for Android as well, tweaking the configure script and Makefile.

Keeping in mind both Android and Linux export the same system calls, it should come as no surprise that statically linked binaries are often fully compatible (keeping in mind the same underlying CPU architecture). Static linking imports the specific dependencies from the various libraries into the core of the executable. A noteworthy example is Intel's Houdini (discussed in Chapter 7), which is provided on x86/64 versions of Android. A more common example still is BusyBox, which is an all-in-one binary supplying various shell command functionality: An ARM compiled static binary of Busybox taken from embedded Linux is mostly compatible, although minor aspects (such as displaying Android AIDs) don't always work well.

 

It's worth noting that there are open issues in Bionic, specified in bionic/ABI-bugs.txt, which affect some esoteric, but nonetheless potentially important datatypes, such as (at the time of writing) time_t (32-bit time, which will blow up in 2038) and off_t (32-bit file offsets). Also, Bionic itself is optimized for 32-bit, and Apple's move to 64-bit will likely force Bionic (and, indeed, all of Android) to be ported to 64-bit, most likely with the version that will follow KitKat (as discussed later in this chapter).

Android Native Libraries

In addition to Bionic, Android contains quite a few other important libraries, which provide runtime support for Dalvik, the frameworks, and the system processes. Those are strewn around the source tree, so the following classifies them by the directories they are in (A full list of these can be found in Appendix A).

Core Libraries

The libraries in system/core mostly provide wrappers over kernel Androidisms, or implement additional functionality in user-mode, and include:

• libcutils: Provides convenient support functions for kernel exported data (e.g. /proc/cpuinfo), socket support, and Androidisms such as ASHMem.
• liblog: Which wraps the Android /dev/log mechanism, to provide a fast and efficient, ring-buffer based mechanism for logging.
• libion: Wrapping the ION Memory Allocator, which was introduced in 4.x (discussed in Chapter 19).
• libnl_2: Which wraps the Linux NetLink socket mechanism (described in Chapter 18).
• libpixelflinger: Used primarily by the SurfaceFlinger (the core of Android's Graphics stack, described in Chapter 14). "Flinging" refers to the act of composing two or more inputs so that in the case of graphics, for example, the resulting pixel is a (potentially alpha-blended) color combination of the ones merged.
• libsuspend: Which abstracts some aspects of power management, particulary those relating to sleep and suspension of the operating system.

Lesser libraries include:

• libdiskconfig: Abstracting disk (flash) configuration and partition management.
• libcorkscrew: Used by the debuggerd to unwind stacks and symbolicate application crashes ("tombstones").
• libmemtrack: providing process memory tracing services, with the help of hardware modules, if any.
• libmincrypt: providing basic implementations of RSA and SHA-[1|256], required for digital signature processing.
• libnetutils: Simplifying interface configuration and DHCP support.
• libsync: Which wraps the kernel's sync Androidism.
• libsysutils: Provides primitives used by system utilities. Includes Framework[Client|Listener|Command], Netlink[Event|Listener], Socket[Client|Listener] and ServiceManager
• libzipfile: Providing wrappers over zlib to handle zip files. Android uses zip extensively, with application packages (.apk files) being a special case of zip.

 

Framework support libraries

Libraries in frameworks/ provide native support services for the Android frameworks. Despite not being part of the "core", they are nonetheless important, and further classified by subdirectories.

• The frameworks/base/core/jni directory contains the very important libandroid_runtime.so, which provides the low level JNI support for the Dalvik VM. The directory contains the JNI components of over 85 framework (Dalvik-level) classes.
• The frameworks/base/services/jni directory contains the equally important libandroid_servers.so, which provides the low level JNI support the Android services.
• The frameworks/base/native/android directory contains libandroid.so, which provides a native interface to assets, storage manager, and more.
• Libraries in base/libs include libandroidfw.so and libhwui.so. The former provides miscellaneous support services such as zip file parsing and asset managements. The latter provides hardware accelerated UI rendering, via OpenGL and SKIA.
• Libraries in av handle media, audio and video. These include:
  • Camera HAL libraries - libcamera_client.so and libcamera_metadata.so (q.v. Chapter 11).
  • DRM Framework support (libdrmframework.so) supporting Android's Digital Rights Management mechanism.
  • Media support libraries - including libeffects.so, libmedia.so, libnbaio.so, libmediaplayerservice.so, and libstagefright.so.

  The subdirectory av/services contains further support libs for services - libcameraservice.so, libaudioflinger.so and libmedialog.so.

• Libraries in native/libs include:
  • libbinder: Binder support functions, discussed in depth in Chapter 20.
  • libdiskusage A tiny library providing directory sizing functions.
  • libgui: Provides GUI abstractions (such as the surface), built on top of libui.so
  • libinput: Provides basic primitives used by Android's input stack, as described in Chapter 12.
  • libui: Provides the native APIs for Windows and Buffers, used by surfaceflinger (not user events).

  The native/ subdirectory also contains the opengl/ directory, which hold EGL and OpenGLES, discussed in Chapter 14).

External Native Libraries

Android relies on quite a few "external" libraries. The name refers to their location in the Android source tree, and the fact that they are not formally a part of Android - rather, they are open source projects which lend powerful capabilities to the operating system.

There are well over 150 such external projects in the Android source tree, so this work does not make an attempt to cover them all. Table 1-3 nonetheless attempts to touch on the important ones:

 

Table 1-3: External projects in the Android source tree

Directory	Contents
bluetooth	Bluedroid library (libbluedroid.so), which supports user-mode bluetooth capabilities
icu4c	libicuuc and libicui18n, handling Unicode support and internationalization
mdnsresponder	Apple's Multicast DNS (Bonjour) - contains daemon (mdnsd) and library (libmdssd.so)
libselinux libsepol	SELinux support (JellyBean and later)
skia	The SKIA 2D graphics library (discussed in Chapter 14)
sqlite	The SQLite3 DB support, providing the core for many Android databases
svox	libttspico and libttscompat, for SVOX Pico Text-To-Speech Engine
tinyalsa	Minimal version of the Linux Advanced Sound Architecture (ALSA) library
webkit	The webkit browser core, used by WebView controls
zlib	Zlib - a library providing compression support for gzip and the like

Note that, once deployed on the device, external libraries are largely indistinguishable from those of the AOSP, since all libraries end up alongside one another in /system/lib. Similarly, it is possible your device has additional vendor-specific libraries in /system/lib (though by convention those should be placed in /vendor/lib).

Hardware Abstraction Layer

Android is meant to run on so many types of different devices - tablet, phones, STBs, treadmills, and what not - that the underlying hardware may greatly differ in its scope and support. In an effort to combat this, Android defines a Hardware Abstraction Layer (HAL) which aims to promote standardization by defining an adapter. Hardware vendors are free to implement their own drivers in kernel mode, but must supply a shim, to conform to the interface Android (and particularly, Dalvik) expects. The Hardware Abstraction Layer defines what an abstract camera, GPS, sensor, and other components look like to Android. This does not preclude vendors from extending or modifying functions - it only requires the vendor to drop the shim into /system/lib/hw, and the HAL - libhardware.so will automatically load them. Output 1-3 shows the HAL libraries used in the S5:

root@S5:/ # ls -l /system/lib/hw
..   9448 2014-03-09 18:21 audio.a2dp.default.so    # a2dp BT audio profile
..   5308 2014-03-09 18:21 audio.primary.default.so
.. 116348 2014-03-09 18:21 audio.primary.msm8974.so
..  17708 2014-03-09 18:21 audio.r_submix.default.so
..   9476 2014-03-09 18:21 audio.usb.default.so    # Audio over USB
..  13552 2014-03-09 18:21 audio_policy.msm8974.so # Audio Policy
. 1306732 2014-03-09 18:21 bluetooth.default.so    # BT, AOSP stock
.. 280728 2014-03-09 18:21 camera.msm8974.so       # Camera
...  5412 2014-03-09 18:21 consumerir.default.so   # Infra-Red
... 17640 2014-03-09 18:21 copybit.msm8974.so      # Hardware accelerated copy
... 26260 2014-03-09 18:21 flp.default.so          # Fused Location Provider
... 21756 2014-03-09 18:21 gps.default.so          # GPS
...  9736 2014-03-09 18:21 gralloc.default.so      # Graphics memory allocator, AOSP stock
... 14328 2014-03-09 18:21 gralloc.msm8974.so      # Graphics memory allocator, Qualcomm
.. 107820 2014-06-06 13:32 hwcomposer.msm8974.so   # Hardware accelerated surface composition
...  5308 2014-03-09 18:21 keystore.default.so     # Cryptographic storage
...  5308 2014-03-09 18:21 local_time.default.so
... 65412 2014-03-09 18:21 nfc_nci.MSM8974.so      # Near-Field-Connectivity
.... 5316 2014-03-09 18:21 power.default.so        # Power Mgmt, AOSP stock
... 21924 2014-03-09 18:21 sensorhubs.msm8974.so   # Sensors
... 54640 2014-06-06 13:32 sensors.msm8974.so

The Hardware Abstraction Layer is naturally a very important aspect of Android - both because it represents a divergence from Linux, and because it is instrumental in supporting the slew of Android devices. It is thus deserving of its own chapter.

Android Derivatives

Android Wear

With rumors of Apple supposedly working on an "iWatch", it's no surprise Google quickly rushed to announce "Android Wear". Android Wear is a version of Android optimized for wearable devices (which, at the time of writing, are a single-category domain, watches, though could ostensibly be extended to other wearable devices). At the core, Android Wear is the same Android used in phones and tablets, but the home activity (main screen) has been replaced by a simpler interface, with an emphasis on voice commands (owing to a watch's diminutive display) and notifications.

Android Wear, identified by "clockwork" in the ro.build.fingerprint property, can be thought of as a "slimmed down" version of Android. Unnecessary frameworks and services have been removed, both to conserve memory, as well as CPU (battery life being a major limiting factor of wearable devices). A comparison between the phone and Wear flavor of KitKat reveals that all telephony services (phone, iphonesubinfo, simponebook, isms), as well as print, appwidget, backup, usb, wallpaper, device_policy, and the drmManager have been removed in Wear. Applications have likewise been slashed from over 180MB (in about 60 packages) to a mere 12MB in only 16 packages, leaving only watch specific applications (ClockworkSetup.apk, ClockworkSettings.apk and the PrebuiltClockworkHome.apk launcher), or those that can operate on a small screen (in other words, the default com.android.* from KK are not present or loaded in Wear).

Android Wear devices are, at present, designed to serve as satellites for more capable devices, such as a smartphone or tablet. Their only connectivity is via BlueTooth, and most of their frameworks are stubs, which connect to the full featured ones on a phone. Samsung, an early adopter for its "Galaxy Gear" watch, is migrating away from Wear in favor of its homegrown Tizen, citing issues with battery life and limited functionality as being the key drivers.

Android TV

TV Makers have long been using proprietary OSes to run their device - Samsung's Tizen and LG's WebOS (formerly Palm/HP's) being the two most prominent examples. Google wishes to extend Android's hegemony into this space, as well (gaining the fringe benefits in the trove of user viewing habits). This is Google's second attempt at entering television, with their "Google TV" being less of a niche product than "Apple TV" is.

Android TV has yet to be officially released, though it will likely be released alongside (and based on) Android L. From the emulator images, one can discern the main difference is in the launcher (com.android.mclauncher, in /system/app/LeanbackLauncher.apk), the built in TV app (com.android.tv, in /system/priv-app/TV.apk), and the TV Content provider (com.android.providers.tv in /system/priv-app/TvProvider.apk). The content provider exports URIs in android.media.tv for input (the remote control), channel, program and watched_program. The latter three are stored in the provider database, /data/user/0/com.android.providers.tv/databases.

Android TV took a significant leap forward with the advent of L. Still, there's not much to detail about Android TV -- yet. No doubt, Android TV will likely evolve considerably in the future (especially shortly after whenever Apple unveils their own plans for extending Apple TV and iOS). Future enhancements would likely involve better streaming support, enhanced EPG (Electronic Programming Guide) functionality, integration with ChromeCast, and gaming platform support. But there is another foe to consider in the TV space - Amazon.

Android Auto

Shortly after Apple announced "CarPlay", integrating iOS 7 with cars, Google happened to announce "Android Auto", which aims to do surprisingly similar things: Provide a convenient interface to use mobile devices in cars, with access to useful apps such as navigation, the music player, and (of course) the phone. As with Android Wear, there's an emphasis on voice commands and notifications - this time not because of screen limitations, so much as the requirement for hands-free operation.

From the developer perspective, the important difference is that there is no need for a separate car-specific UI. In fact, there's no need for any UI in Android Auto, because the built-in system UI communicates with specific aspects of app functionality, and presents them as the "drawers", which are list driven menus. This enables the driver to select functions with the navigation buttons found on most steering wheels. Apps can still customize the built-in UI, by specifying icons and background images, but don't need to display any custom UI Views, as they would normally.

The formal SDK has yet to be released at the time of writing, but Google has already given some ideas about the interface changes, such as the launcher, and the drawer-based UI at the Android Auto website.

FireOS

One of the vendors to benefit most from Android was Amazon. The giant retailer made its foray into the tablet market with its Kindle line, which was based on a proprietary embedded Linux distribution, and an e-Ink display. With the Kindle Fire, Amazon modernized their tablet, using Android as the core operating system.

Much to Google's chagrin, however, Amazon fully customized their version of Android, and rebranded it as "FireOS". The interface was entirely revamped (sporting a "carousel" like selection of apps), the devices are locked and keyed to Amazon only - effectively useless without an Amazon ID, and any trace of Google - search, Play store, accounts, or otherwise - has been abolished. In a sense, this was a natural consequence of Android's open nature - Google made it free to gain hegemony among vendors (and harvest the rich data of device users), but did not prevent any vendor from entirely removing the Google apps and links (in fact, Nokia did the same thing, prior to its acquisition by Microsoft, as it developed a version of Android wherein all services are Microsoft's rather than Google).

From a technical perspective, FireOS's core is still very much Android. The changes are mostly cosmetic, and include removal of all things Google, and replacement with Amazon. Specifically:

• Carousel as the home activity: The familiar Android launcher has been replaced by Amazon's custom launcher, com.amazon.kindle.otter.
• Default Browser is "Silk": or, by its other name, com.amazon.cloud9. This is a WebKit based browser, heavily modified and optimized to use Amazon's Elastic Compute Cloud (EC2) to optimize web browsing.
• Google Play replaced by Amazon App Store: Internally referred to as com.amazon.windowshop and com.amazon.venezia.
• Amazon offers as screen saver: Utilizing Android's "Dreams" functionality to install a screen saver filled with ads. Internally, this is done by several components in the com.amazon.dcp package, and ads stored in /data/securedStorageLocation/dtcp/ (incidentally, revoking permissions on this folder effectively disables ads).
• Aggressive OTA updates: The com.amazon.dcp package contains a host of services meant to ensure the device is constantly up to date. Unlike other Android versions, FireOS doesn't ask to update - it just goes ahead and does so. (Automatic updates are explained in Chapter 3)

Amazon has taken several pages from Apple's playbook, most notably locking down the system to resist rooting (or at least, try) as well as prevent downgrading of the operating system once an update has been installed (which it often is, automatically). With FireOS as a whole, Amazon steps further away from the Google vision of Android, launching its own "Fire Phone", and its "Fire TV", each with proprietary interfaces and APIs.

Headless Android

Take Android, and remove Dalvik and its accompanying frameworks, and you are left with a system that has no GUI support. Such a system, however, is still valuable in its own right, as a base embedded Linux distribution, which has already been adapted to work with ARM and MIPS processors. Before the advent of Android, embedded Linux was a complicated and highly difficult environment, owing in large part to the complexity of building the cross-compiler toolchain, and the user mode libraries. Companies which provided this toolchain and environment (along with support) were highly sought after.

Android, however, completely disrupted the realm, turning the tables on the major Embedded Linux players. Rather than acquire a license for tens of thousand of dollars, embedded Linux now became entirely free - by simply downloading the Android sources and NDK, anyone can build and customize the system to their own needs. Android in its headless deployment now forms the basis for many systems which don't need GUI - sensors, appliances and others, and is likely to be a major player in the "Internet-of-Things" revolution, which promises to embed ARM and MIPS (and maybe Intel) processors in everything but the kitchen sink.

It's possible in Android to enjoy the best of both worlds - that is, both the rich frameworks, and a system with no UI. The system can be made to operate with no UI by setting the ro.headless system property. This allows developers to use the frameworks for various non-UI related tasks (such as interfacing with sensors), as well as benefit from the object orientation and other advanced aspects of the Dalvik and ART environments.

Pondering the Way Ahead

Prophecy is the gift of fools, but this author cannot help but contemplate the next direction to be taken by Android. The war between iOS and Android rages on, and it is more than likely that features that will appear in iOS 8 will serendipitously find their way into the next version of Android - though at the time of writing neither version has been released yet. Still, it seems rather clear from the present landscape as to some features will very likely be included in the next Android - Lollipop, Licorice, or whatever condiment name Google will choose for it.

64-Bit compatibility

With the introduction of the iPhone 5S, Apple caught the entire mobile industry by surprise, with the first 64-bit mobile architecture. This perplexed many, which were quick to dismiss it as useless marketing. 64-Bit support was initially discounted because its chief advantage, address spaces larger than 4GB, is in fact questionable in a mobile environment. Though some tablets already ship with RAM of 2GB, 4GB are still beyond the needs of most devices. 64-bit memory access is also slightly less efficient than 32-bit (involving more page table lookups), so many were quick to mock Apple for such a "feeble attempt at innovating" and a useless gimmick*.

In practice, however, there's more to 64-bit than meets the eye. Though ARM 64-bit processors still support 32-bit code, the native 64-bit (ARMv8) instruction set has been completely rewritten to be more efficient. Add to that, the width of 64-bit registers (and the larger register set), and the advantage quickly becomes apparent. The 64-bit architecture (along with some remarkable designs in Apple's custom A7 chip), blew past the performance of all other mobile processors, while maintaining an impresively low power footprint. In fact, this proved that the boasting quad and octo-cores was the useless gimmick, as Apple's flagship processor was still a dual-core. What more, adding more cores directly impacts power performance, so most cores are actually powered off the overwhelming majority of a device's last time.

The move - a vertical, rather than a horizontal expansion, thus proved to be a brilliant one, and an especially efficacious stratagem: Though requiring virtually no work in iOS other than a recompilation of the app, porting Android to 64-bit is a lengthy process. Android's core components - notably Dalvik and Bionic - are 32-bit optimized, and therefore need to be completely rewritten. The various ARM vendors need to adapt to the move (though Samsung was quick to announce their "next big thing" will naturally be 64-bit), which puts off 64-bit Android at least until the end of 2014, if not the beginning of 2015. Of all vendors, Intel has been quick to jump on the 64-bit wagon, since its mobile processors are already fully 64-bit native.

Android RunTime (ART)

Android still proves inferior to iOS in several aspects, not the least of which is power management. This can be traced back to its Linux foundations (which are geared towards an immobile desktop or server, where power is rarely a concern), but also due to its many layers. While layers provide for elegant abstrations, portability and other aspects of fine design, they are often dismal in terms of performance and power management, as they require more processing. The main layer in Android - Dalvik - involves significant processing, and even its many enhancements (e.g JIT compilation) still require much more work than native code would. By comparison, iOS's runtime and frameworks are implemented in Objective-C, which is an extension of standard C, and still very much native**.

The Android RunTime (ART) provides an alternative. Silently introduced in KitKat and dubbed "experimental", ART aims to use Ahead-of-Time (AOT) compilation, to LLVM and even native code, thus bring it on par with iOS performance. ART presently offers only small advantages in power and performance over Dalvik (on order of 10-20%), and in some tests also falls behind it. GIT commits, however, clearly show that ART will rise to be the default runtime in the version to follow KitKat, rather than Dalvik, which will remain supported as an optional backup and backward compatibility. As alluded to earlier in this chapter - Dalvik is far from dead: Applications will still be packaged with Dalvik bytecode (classes.dex), with ART taking over and compiling to native code only when deployed on the device (replacing the on-device optimization stage usually carried out by dexopt). Both Dalvik and ART are discussed in depth in Chapter 10).

Split-Screen

Android already has the necessary foundations to allow different activities to run in parallel to one another on a split screen: Samsung has extended the GUI for this capability, which is also supported in Windows 8, and with rumors abuzz for this feature to be added to the iPad in iOS 8.1, it makes sense to see it mainstream on Android. This is a purely framework-level feature, since from the native perspective there's no real change - the activities as processes run concurrently anyway. This could be a major step on the road to making Android a full desktop OS replacement, as well.

Android as a desktop OS

With so many tablets vying to become a desktop replacement, why not make Android a desktop OS? Microsoft introduced Windows 8, which took desktop Windows, and improved(?) it to support mobile devices - tablets and phones. Android would need to make the reverse transition, bringing its mobile support to desktops, which could then run Android apps.

Doing so is not necessarily that hard - as we discuss in Chapter 10, Dalvik's open source nature makes it quite portable, and implementations for other OSes - naturally, Linux, but also Windows, OS X and even iOS(!) exist. None of those are sponsored nor supported by Google, but with iOS and OS X edging closer and closer still to one another, some have postulated that OS X will soon run iOS apps (some have even go so far as to suggest Apple will make the transition to ARM on its Macs). If that were the case, the binding between the ecosystems would become a strong differentiator in iOS's favor, which Google will surely not ignore for long.

There are a few obstacles, however. For one, it's not trivial to support full desktop applications. The Linux OpenOffice and most other apps are already built on top of X-Windows (and GNOME or KDE), and thus would have to be adapted to Android. In addition, Android would have to be extended to support mice (though arguably its InputManager already supports cursor devices), and multiple windows (again, technically supported to an extent by the WindowManager). Last but not least is ChromeOS, which Google is developing as its answer to Windows, in the hopes of ousting the latter the same way Chrome usurped the lead to become the world's most popular browser.

Android and Project ARA

ARA (www.projectara.com) is the code name for a project developed by Google with the goal of producing a fully modular smartphone. The idea is to make all system components swappable - the CPU, display, storage - are all replaceable, much in the same way in the PC world it's a farily simple matter to install a new hard drive or graphics adapter. ARA is a vestige of Google's Motorola Mobility acquisition (since sold off to Lenovo), developered by the former's Advanced Technology and Projects (ATAP) division, which was retained by Google.

ARA makes the device, in effect, a chassis (more accurately, an endo skeleton), and components are separate modules - not unlike a PC. Electro permanent magnets (that can be turned on/off electronically, but do not require power for everyday use) hold modules in place. In theory, all components (save for the CPU, and possibly the display) are hot swappable (i.e. they can be replaced while the device is working). Coupled with 3D printing, this could lead to "printable" phone designs which could be downloaded, and an array of upgradeable modules which would render the annual full upgrades of mobile devices extinct.

As ARA is developed by Google, it's only natural that Android be the OS of choice for it. Supporting ARA, however, will require heavy modifications in Android - at the framework level, but even more so at the underlying Linux layers, all the way down to the kernel. Google has partnered with Linaro for these purposes, and is investing ridiculous sums of money at developing both the software and hardware necessary to standardize all the modules. ARA is still in its infancy as this book goes to print, with an estimate alpha release in 2015. If successful, however, a truly modular mobile device would amount to nothing less than a second coming of the mobile revolution - and Google wants to be there first this time.