This chapter is from the book
This chapter is from the book
This chapter is from the book
The Android Platform
Android is an operating system and a software platform upon which applications are developed. A core set of applications for everyday tasks, such as Web browsing and email, are included on Android handsets.
As a product of the Open Handset Alliance’s vision for a robust and open source development environment for wireless, Android is an emerging mobile development platform. The platform was designed for the sole purpose of encouraging a free and open market that all mobile applications phone users might want to have and software developers might want to develop.
Android’s Underlying Architecture
The Android platform is designed to be more fault-tolerant than many of its predecessors. The handset runs a Linux operating system, upon which Android applications are executed in a secure fashion. Each Android application runs in its own virtual machine (Figure 1.8). Android applications are managed code; therefore, they are much less likely to cause the phone to crash, leading to fewer instances of device corruption (also called “bricking” the phone, or rendering it useless).
)
Figure 1.8 Diagram of the Android platform architecture.
The Linux Operating System
The Linux 2.6 kernel (Figure 1.9) handles core system services and acts as a hardware abstraction layer (HAL) between the physical hardware of the handset and the Android software stack.
)
Figure 1.9 Tux, the Linux kernel mascot.
Some of the core functions the kernel handles include
- Enforcement of application permissions and security
- Low-level memory management
- Process management and threading
- The network stack
- Display, keypad input, camera, WiFi, Flash memory, audio, and binder (IPC) driver access
Android Application Runtime Environment
Each Android application runs in a separate process, with its own instance of the Dalvik virtual machine (VM). Based on the Java VM, the Dalvik design has been optimized for mobile devices. The Dalvik VM has a small memory footprint and multiple instances of the Dalvik VM can run concurrently on the handset.
Security and Permissions
The integrity of the Android platform is maintained through a variety of security measures.
Applications as Operating System Users
When an application is installed, the operating system creates a new user profile associated with the application. Each application runs as a different user, with its own private files on the file system, a user ID, and a secure operating environment.
The application executes in its own process with its own instance of the Dalvik VM and under its own user ID on the operating system.
Explicitly Defined Application Permissions
To access shared resources on the system, Android applications register for the specific privileges they require. Some of these privileges enable the application to use phone functionality to make calls, access the network, and control the camera and other hardware sensors. Applications also require permission to access shared data containing private and personal information such as user preferences, user’s location, and contact information.
Applications might also enforce their own permissions by declaring them for other applications to use. The application can declare any number of different permission types, such as read-only or read-write permissions, for finer control over the application.
Limited Ad-Hoc Permissions
Applications that act as content providers might want to provide some on-the-fly permissions to other applications for specific information they want to share openly. This is done using ad-hoc granting and revoking of access to specific resources using Uniform Resource Identifiers (URIs).
URIs index specific data assets on the system, such as images and text. Here is an example of a URI that provides the phone numbers of all contacts:
content://contacts/phones
To understand how this permission process works, let’s look at an example.
Let’s say we’ve got an application that keeps track of the user’s public and private birthday wish lists. If this application wanted to share its data with other applications, it could grant URI permissions for the public wish list, allowing another application permission to access this list without explicitly having to ask for it.
Application Signing for Trust Relationships
All Android applications packages are signed with a certificate, so users know that the application is authentic. The private key for the certificate is held by the developer. This helps establish a trust relationship between the developer and the user. It also allows the developer to control which applications can grant access to one another on the system. No certificate authority is necessary; self-signed certificates are acceptable.
Developing Android Applications
The Android SDK provides an extensive set of application programming interfaces (APIs) that is both modern and robust. Android handset core system services are exposed and accessible to all applications. When granted the appropriate permissions, Android applications can share data among one another and access shared resources on the system securely.
Android Programming Language Choices
Android applications are written in Java (Figure 1.10). For now, the Java language is the developer’s only choice on the Android platform. There has been some speculation that other programming languages, such as C++, might be added in future versions of Android.
)
Figure 1.10 Duke, the Java mascot.
No Distinctions Made Between Native and Third-Party Applications
Unlike other mobile development platforms, there is no distinction between native applications and developer-created applications on the Android platform. Provided the application is granted the appropriate permissions, all applications have the same access to core libraries and the underlying hardware interfaces.
Android handsets ship with a set of native applications such as a Web browser and contact manager. Third-party applications might integrate with these core applications and even extend them to provide a rich user experience.
Commonly Used Packages
With Android, mobile developers no longer have to reinvent the wheel. Instead, developers use familiar class libraries exposed through Android’s Java packages to perform common tasks such as graphics, database access, network access, secure communications, and utilities (such as XML parsing).
The Android packages include support for
- Common user interface widgets (Buttons, Spin Controls, Text Input)
- User interface layout
- Secure networking and Web browsing features (SSL, WebKit)
- Structured storage and relational databases (SQLite)
- Powerful 2D and 3D graphics (SGL and OpenGL ES 1.0)
- Audio and visual media formats (MPEG4, MP3, Still Images)
- Access to optional hardware such as Location-Based Services (LBS), WiFi, and Bluetooth
Android Application Framework
The Android application framework provides everything necessary to implement your average application. The Android application lifecycle involves the following key components:
- Activities are functions the application performs.
- Groups of views define the application’s layout.
- Intents inform the system about an application’s plans.
- Services allow for background processing without user interaction.
- Notifications alert the user when something interesting happens.
Android Applications can interact with the operating system and underlying hardware using a collection of managers. Each manager is responsible for keeping the state of some underlying system service. For example, there is a LocationManager that facilitates interaction with the location-based services available on the handset. The ViewManager and WindowManager manage user interface fundamentals.
Applications can interact with one another by using or acting as a ContentProvider. Built-in applications such as the Contact manager are content providers, allowing third-party applications to access contact data and use it in an infinite number of ways. The sky is the limit.