Any computer Operating System (OS) issoftware that manages various resources which are available to that computer. CPU, RAM, memory, printers, displays, etc. are allresources that require specific controls to allow smooth and efficientoperation of any computer and users interacting with it. There is no singleOperating System, but instead many ranging a variety of different devices andhardware. Android is an open source OS targeting mobile devices and is based onthe Linux kernel which was chosen for its proven track record and multi-taskingcapabilities. Although Android’s core isLinux, Android has a limited set of software and libraries that aren’t availableon a typical Linux distribution.
While based on Linux you would not be able torun applications built for various Linux distributions (e.g. Ubuntu, Debian, Fedora etc.) on Android devices. Androiduses the Linux kernel as a base from which to build which has a proven modelwith existing drivers including but not limited to memory, networking andprocess management. With that said, the standard Linux Kernel was modified tosupport the special needs of mobile devices. Such enhancements included alarm driver, Android shared memory driver,binder driver (for Inter-Process Communication), power management, low memory management,and a kernel debugger / logger. In addition to the standard capabilities andenhancements provided by the Linux Kernel, Android needs additional librariesto support higher level functionality.
A C library and well as a Java Runtime werecreated and optimized to run on what was called the Dalvik Virtual Machine, whichwas part of the Android stack in versions 4.4 or earlier. The Dalvik VM used a Just-In-Time approach wherecompilation of what are called .dex files (i.e. a distinct Android format calledDalvik) into byte code is done on demand. This is similar in some ways to whatis done in Java environment where .
class files are created; and converted intobyte code usable in Java. In an Android environment .class file(s) are created andconverted into a single .dex which is a Dalvik executable. Due to slow performancecharacteristics of a on demand compilation approach his hassince been replaced by the Android Runtime (ART) with an eye toward performanceimprovements. ART uses an Ahead-Of-Time approachwhere .dex files are compiled before they are needed.
This gives a large boostin performance and well as helping with battery life. In practice when using aDVM approach when you open an app, files get converted to their native code andwill only start working when the compilation is completed; until then the app won’trespond. Using an ART approach files are converted once and your done. Althoughthis takes some initial time and additional storage performance is improved asis battery life. 4 10 11 Giventhat Android is open-source, developers can build application functionality tosuit the requirements of any specific mobile device and specifications of thecarriers that market these devices. Although different devices may be runningthe same version of Android, modifications can provide a custom look and feelbased on carrier preferences. To that end, the Android Open Source Project wascreated and continues to be led by Google. Innovation is encouraged; however,to ensure integrity an “Android Compatibility Program” was created to guidedevelopers to achieve “Android Compatible” builds.
Although applications mustbe “minimalistic” (i.e. lightweight) they still must have the ability toaddress local broadband connectivity, smaller form factors, and therequirements of different marketers of these devices whom give it a specific”flavor” of that brand. There arespecific issues that come with the development of mobile applications. Oneobvious issue with mobile devices is the mobility of the device itself. Forexample, using magnetic data storage with moving parts, a large size andrelatively slow data access was not feasible.
Using flash memory which had asmall footprint, and eliminated moving parts provided stability fast accessspeeds. To achieve this Android originally used a file system known as “YetAnother Flash File System” (YAFFA). This had fast read time, and was resistantto the physical movement of a mobile device. As technology advanced, Androidswitched to EXT4 (Extended File System) to take advantage newer of dual coreprocessors allowing for multi-threading, as opposed to YAFFA which wassingle-threaded and likely to cause bottlenecks in devices with fasterprocessors. 4 9 Another issue was not related to the physicalnature of the device but one which has significant implications: the securityof the Android OS. Earlier versions of Android had very limited security capabilities,however, starting with Froyo version 2.
2 additional security features becamepart of the OS; password policies, and remote lock / wipe to start with. As newversions were released so were updated security features: encryption/cryptoAPI’s, certificate management, secure developer interfaces (i.e.
SSL), and facialunlock. As with any security measure intended to protect a user’s device, whilethese new features become available, the specific implementation of saidmeasure will determine how secure a device will be. For example, if acapability exists to define password policies, but an administrator definesweak policies, the device may be vulnerable to certain types of attacks.
5Device security was a main concern of Google, and as a resultof an inevitable effort to keep the user’s data secure, Google created an “AndroidSecurity Program” which consists of several components; design review, penetration testing, codereview, open source and community review as well as incident response and monthlysecurity updates. These process oriented mechanisms help to deliver securecode; however, Android also uses capabilities derived from the Linux Kernel. These include but arenot limited to user-based permissions, isolationof processes, secure inter-process communication and the ability to removeunnecessary and potentially insecure parts of the Kernel. Given Linux is amulti-user operating system a main security objective within the Kernel is to isolate user resources from oneanother.Android uses this capability to isolate application resources. Android uses a uniqueID assigned to each application which runs as a separate process with distinctpermissions. This is the basis for the application sandbox.
This is in contrastto Linux which may run multiple applications with the same permissions. TheLinux kernel enforces security (i.e. ID’s assigned to an application cannotinteract with other applications or gain access to data). Since the Sandbox iseffectively in the Kernel this model extends not only to application code but OSapplications as well.
All applications above the Kernel (see appendix A) willrun within the application Sandbox. This greatly enhances the protectionswithin the context of the Android environment. As an example, a fairly commonproblem such as memory corruption could lead to issues with applications thatrun within the same memory space. Such issues are limited within the context ofthe Android environment, given the isolation mechanisms derived from the LinuxKernel. The OS level Sandboxing will only allow impacts in the context of thatparticular application thus shielding others from potential flaws. 6 8Starting with version4.
3, the Android security model uses SELinux (Security Enhanced Linux inAndroid). This enforces mandatory access control (MAC) over all processes includingroot, which confines privileged processes and automates security policy. TheAndroid Open Source community has contributed to SELinux which has of course beenmade publicly available. As part of SELinux, Android can be set up in”enforcing mode” which means permissions denials are both logged and enforced. Violations arelogged by the kernel to dmesg(messages produced by device drivers) and logcat(dumps a log of system messages), which allows device manufacturers to reviewand refine their software to determine what policies should and should not beenforced. (Note I may put morestuff here)7Android has considerable flexibility.This flexibility can be thought of as an advantage to the developmentcommunity; however, such flexibility can also be its weakness.
As an example,there are three types of Android devices on the market: Google Lead, GoogleExperience and “Other” devices. Google Lead Devices and basically 100% Androidwith no OEM or Carrier customizations, Google Experience devices are CTS(Compatibility Test Suite) compliant which means they pass specific criteria oftesting for that version of Android, they have some carrier customization andsupport critical patches to WiFi security flaws (Google Promise). Other aredevices are not CTS compliant and have significant carrier modifications. Assuch although these implementations are all Android they are not created equal.9