Editors note: This is the first in a two-part series of articles on the basic features and capabilities common to all Android platforms, excerpted from the authors' book The Android Developer’s Cookbook.
The Android operating system (OS) has come a long way since the announcement of the Open Handset Alliance in late 2007. The idea of an open source OS for embedded systems was not new, but Google aggressively backing it definitely has helped push Android to the forefront in just a few years. Many wireless carriers in multiple countries across various communication protocols have one or more Android phones available. Other embedded devices, such as tablets, netbooks, televisions, set-top boxes, and even automobiles, have also adopted the Android OS. This article discusses various general aspects of Android useful for a developer. It provides a foundation for the creation of Android applications.
Device diversity and quick adaptation have helped Android grow its user base, but it comes with potential challenges for developers. Applications need to support multiple screen sizes, resolution ratios, keyboards, hardware sensors, OS versions, wireless data rates, and system configurations. Each can lead to different and unpredictable behavior, but testing applications across all environments is an impossible task.
Android has therefore been constructed to ensure as uniform an experience across platforms as possible. By abstracting the hardware differences, Android OS tries to insulate applications from device-specific modifications while providing the flexibility to tune aspects as needed. Future-proofing of applications to the introduction of new hardware platforms and OS updates is also a consideration. This mostly works as long as the developer is well aware of this systematic approach. Still, as with any embedded platform, extensive testing of applications is required.
Google provides assistance to third-party developers in many forms as Android Development Tool (ADT) plugins for Eclipse (also as standalone tools) including real-time logging capabilities, a realistic emulator that runs native ARM code, and in-field error reports from users to developers of Android Market applications.
Android has some interesting dichotomies. Knowing about them upfront is useful not only in understanding what Android is, but what it is not. Android is an embedded OS that relies on the Linux kernel for core system services, but it is not embedded Linux. For example, standard Linux utilities such as X-windows and GNU C libraries are not supported.
Writing applications for Android utilizes the Java framework, but it is not Java. Standard Java libraries such as Swing are not supported. Other libraries such as Timer are not preferred; they have been replaced by Android’s own libraries, which are optimized for usage in a resource-constrained, embedded environment. The Android OS is open source, which means developers can view and use any of the system source code, including the radio stack. This source code is one of the first resources for seeing examples of Android code in action, and it helps clarify the usage when documentation is lacking. This also means developers can utilize the system in the same way as any core application and can swap out system components for their own components. However, Android devices do contain some proprietary software that is inaccessible to developers (such as Global Positioning System (GPS) navigation).
A final dichotomy of Android OS is that Google is also backing Chrome OS. Android OS is built for embedded platforms, and Chrome OS is built for cloud-based platforms. However, which is the best choice for embedded devices that live in the cloud?
Netbooks, which fill the gap between smart phones and laptop computers, could presumably go either way (and they have). Android has started to utilize the cloud more. Does that mean Chrome OS’s days are numbered? Google also backs a web-based market, so Chrome OS enjoys the same developer leverage that Android currently has. This points to a convergence that might have been in the cards all along.
There are more than 40 Android phones in the market from more than ten manufacturers. Other hardware also runs Android, such as tablets and televisions. Software can access information on the target device using the android. os. Build class, for example:
Android-supported hardware shares some common features due to the nature of the operating system. The Android OS is organized into the following images:
Bootloader – Initiates loading of the boot image during startup
Boot image – Kernel and RAMdisk
System image – Android operating system platform and apps
Data image – User data saved across power cycles
Recovery image – Files used for rebuilding or updating the system
Radio image – Files of the radio stack
These images are stored on nonvolatile flash memory, so they are protected when the device powers down. The flash memory is used like read-only memory (hence, some call it ROM), but can it be rewritten as necessary (for example, with over-the-air Android operating system updates).
On startup, the microprocessor executes the bootloader to load the kernel and RAMdisk to RAM for quick access. The microprocessor then executes instructions and pages portions of the system and data images into RAM as needed. The radio image resides on the baseband processor, which connects to the radio hardware.
Hardware differences on Android devices
The hardwareavailable on each Android device varies. In general, most of thedifferences are transparent to the developer and not covered furtherhere. However, a few hardware differences are important to understand toassist in writing device-independent code. Screens, user input methods,and sensors are discussed here.
Twotechnologies used for displays are liquid crystal displays (LCD) andlight-emitting diodes (LED). The two specific choices in Android phonesare thin-film transistor (TFT) LCDs and active-matrix organic LEDdisplays (AMOLED). A benefit of TFT displays is a longer lifetime. Abenefit of AMOLED displays is no need for backlighting and thereforedeeper blacks and lower power.
Overall, Android devices arecategorized into small, normal, and large screens and low-, medium-, andhigh-pixel density. Note that the actual pixel density might vary butwill be chosen as one of these. A summary of currently available devicescreens is shown in Table 1 .
2. User input methods
Touchscreens enable users to interact with the visual display. There are three types of touchscreen technology:
Resistive – Two resistive material layers sit on top of a glass screen. When afinger, stylus, or any object applies pressure, the two layers touchtogether and the location of the touch can be determined. Resistivetouchscreens are cost-effective, but only 75 percent of the light showsthrough, and until recently,multitouch was not possible.
Capacitive – A charged material layer is overlaid on a glass screen. When a fingeror any conductive object touches the layer, some charge is drawn off,changing the capacitance, which is measured to determine the location ofthe touch. Capacitive touchscreens allow as much as 90 percent of thelight through, although accuracy can be less than resistive.
Surface Acoustic Wave – This uses a more advanced method that sends and receives ultrasonicwaves. When a finger or any object touches the screen, the waves areabsorbed. The waves are measured to determine the location of the touch.It is the most durable solution, but more suitable for large-scalescreens such as automatic bank tellers. All Android devices use eitherresistive or capacitive touchscreen technology, and with a few earlyexceptions, all support multitouch.
In addition, each Androiddevice needs an alternative method to access the screen. This is throughone of the following methods:
D-pad (directional pad) – An up-down-right-left type of joystick
Trackball – A rolling ball acting as a pointing device that is similar to a mouse
Trackpad – A special rectangular surface acting as a pointing device
Smartphonesare becoming sensor hubs in a way, opening a rich experience for users.Other than the microphone that every phone has, the first additionalsensor introduced on phones was the camera. Different phone cameras havevarying capabilities, and this is an important factor for people inselecting a device. The same type of diversity is now seen with theadditional sensors.
Most smartphones have at least three basicsensors: a three-axis accelerometer to measure gravity, a three-axismagnetometer to measure the ambient magnetic field, and a temperaturesensor to measure the ambient temperature. Overall, it is important tounderstand each Android model has different underlying hardware. Thesedifferences can lead to varying performance and accuracy of the sensors.However, some key features of Android are major selling points anddifferentiators. It is good to be aware of these strong points ofAndroid and utilize them as much as possible.
Multiprocess and app widgets
TheAndroid OS does not restrict the processor to a single application at atime. The system manages priorities of applications and threads within asingle application. This has the benefit that background tasks can berun while a user engages the device in a foreground process. Forexample, while a user plays a game, a background process can check stockprices and trigger an alert as necessary. App Widgets are miniapplications that can be embedded in other applications (such as theHome screen). They can process events, such as start a music stream orupdate the outside temperature, while other applications are running.Multiprocessing has the benefit of a rich user experience. However, caremust be taken to avoid power-hungry applications that drain thebattery.
Touch, gestures, and multitouch
Thetouchscreen is an intuitive user interface for a hand-held device. Ifutilized well, it can transcend a need for detailed instructions. After afinger touches the screen, drags and flings are natural ways tointeract with graphics. Multitouch provides a way to track more than onefinger down at the same time. This is often used to zoom or rotate aview. Some touch events are available transparently to the developerwithout the need to implement their detailed behaviors. Custom gesturescan be defined as needed. It is important to try to maintain aconsistent usage of touch events as compared to other applications. Hardand Soft Keyboards One feature on a pocket device that galvanizes usersis whether it should have a physical (also called hard) keyboard orsoftware (also called soft) keyboard. The tactile feedback and definiteplacement of keys provided by a hard keyboard tends to make typing muchfaster for some, whereas others prefer the sleek design and convenienceoffered by a software- only input device.
With the large varietyof Android devices available, either type can be found. A side effectfor developers is the need to support both. One downside of a softkeyboard is a portion of the screen needs to be dedicated to the input.This needs to be considered and tested for any user interface (UI)layout.
Next in Part 2: Programming aids and capabilities.
This article is based on content from The Android Developer’s Cookbook , by James Steele and Nelson To, used by permission from Addison Wesley, Pearson Education.
Nelson To has developed many applications in the Android market for suchcompanies and organizations as Think Computer, AOL, Stanford Universityand Logitech.
James Steele , previously apost-doctoral candidate at Massachusetts Institute of Technology, nowworks in Silicon Valley aiding companies in bringing research projectsto production systems in both the consumer and mobile markets.