Domo Arigato Mr Androidato—An Introduction to the New Google Mobile Linux Framework, Android
The Android operating system is a multiprocess system, wherein system and application processes run within their own ID space. Security between applications and the system is maintained at the process level using standard Linux facilities, such as Discretionary Access Controls (DACs). When an application is installed, it is given a unique user ID on the system for the duration of its installation lifetime. This unique user ID affords the application a dedicated and protected execution stack within the Android system.
The default behavior of an Android application is to operate within its own container on objects it owns. In other words, Android applications have no permission to perform operations that might adversely impact the user experience or associated data. This behavior can be modified in two ways: 1) the programmer can explicitly share application space with another application, or 2) the programmer can explicitly share application components with other applications and the system. These exceptions are made through the application manifest file.
The manifest file, AndroidManifest.xml, is a file required in every application, and it resides in the root of the application folder. It not only provides a means for defining the security characteristics of your application, but it also provides an outline of your application in the form of exposed application components known as activities, intents, receivers, services and providers. More information on the manifest file is available on the Android Web site (see Resources).
Designed with reuse in mind, this layer enables programmers to piece together five types of components to create the basic building blocks of an application:
The first component, Views, represents the most basic piece of a user interface. Each view is responsible for managing the layout and events associated with the screen area it represents. Views can be grouped together to form Viewgroups and arranged into a hierarchical tree, with other views and Viewgroups. This tree forms a user interface for a particular application activity, such as entering a new contact into a contact book or adding a note to your diary.
The next component is the Content Provider. Content Providers enable a programmer to define a resource from which to pull or push data using a Content Universal Resource Indicator (ContentURI) wrapper and a Universal Resource Indicator (URI). Each ContentURI wraps around a unique type of data, such as contacts, settings and call logs, and provides helper methods for accessing associated data referenced through a URI. Programmers are free to dictate how they want to store, retrieve and modify publicly shared application data, but they must create the provider with a repeatable way to query and return data.
To accomplish this requirement, each URI must contain at least three components: the standard prefix of content://, the data authority and the data path to the content provider. An additional component can be added to the URI if the programmer wants to request a specific piece of data by unique ID, but the fourth component is only necessary when the application programmer is faced with having to know the exact ID of a record. When put together, a typical URI might look like content://contacts/people/42.
You also can use a URI to return a whole set of records. For instance, if you wanted to return the complete set of contacts, you would use content://contacts/people. Quite useful, no? But, what happens when you want to look up Ford in your contact book and can't remember the ID of the corresponding record? Android provides helper classes for each type of ContentURI for this exact situation, enabling users to find data provided by a particular Content Provider easily. The exact details on how to create, use and modify Content Providers, and how to use more-advanced concepts, like managed cursors, are explained in more detail on the Android Web site.
The next component is the Resource Manager. Resource Managers provide a way to work with application-associated files that do not contain code, such as icons, layouts and files associated with application internationalization and localization. Because all resource files are compiled into the binary at build time by the Android build system, Resource Managers are sensitive to where files are located in the source tree. To make build errors related to misplaced external files easier to avoid, all Android projects created through the Eclipse plugin contain a resource directory named res at the root of the application source tree. The resource directory contains subfolders for specific types of data, which the compiler searches and verifies application code against at build time. The exact details on dealing with Resource Managers are quite complex, and the specifications for dealing with Localization and Internationalization are not yet complete, so if you would like to know more, please follow the link provided in the Resources for this article.
The next component is the Notification Manager. Notification Managers provide developers with the ability to alert users to events occurring on their devices. Some examples include displaying a view in the form of a notification window when an e-mail arrives, alerting users to incoming calls by flashing the back light, or maybe even nagging users with a loud Britney Spears ring tone when the battery is running low. These are all typical examples of how you might use a Notification Manager in an Android application. The exact details on how to implement a Notification Manager also are located on the Android Web site (see Resources).
The final component of the Application Framework layer is the Activity Manager. Activity Managers are arguably the most important part of any application running in the Android framework. Activities are defined as user-performed atomic tasks that, when initiated by the user, elicit new behavior from the application. Such behavior might create a new view, retrieve data from a content provider or access underlying hardware to make a phone call. Such tasks are the foundation on which applications are built in the Android framework. Activity Managers are the components responsible for maintaining the navigation stack within an application and performing various housekeeping tasks based upon available resources and the particular state of an activity. In general, Activity Managers try to keep processes related to activities around for as long as possible, but at times, they might be forced to free up resources by terminating particular activities. More information about implementing Activity Managers is available on the Android Web site (see Resources).
- High-Availability Storage with HA-LVM
- Localhost DNS Cache
- DNSMasq, the Pint-Sized Super Dæmon!
- Real-Time Rogue Wireless Access Point Detection with the Raspberry Pi
- Days Between Dates: the Counting
- You're the Boss with UBOS
- The Usability of GNOME
- Multitenant Sites
- Linux for Astronomers
- PostgreSQL, the NoSQL Database