CASE STUDY 1: UNIX, LINUX, AND ANDROID
<?xml version="1.0" encoding="utf-8"?>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
<data android:mimeType="*/*" />
Basic structure of AndroidManifest.xml.
is the part of Android that keeps track of all application
packages. It parses every application’s manifest, collecting and indexing the infor-
mation it finds in them.
With that information, it then provides facilities for clients
to query it about the currently installed applications and retrieve relevant infor-
mation about them.
It is also responsible for installing applications (creating stor-
age space for the application and ensuring the integrity of the apk) as well as
everything needed to uninstall (cleaning up everything associated with a previously
Applications statically declare their entry points in their manifest so they do
not need to execute code at install time that registers them with the system.
design makes the system more robust in many ways: installing an application does
not require running any application code, the top-level capabilities of the applica-
tion can always be determined by looking at the manifest, there is no need to keep
a separate database of this information about the application which can get out of
sync (such as across updates) with the application’s actual capabilities, and it guar-
antees no information about an application can be left around after it is uninstalled.
This decentralized approach was taken to avoid many of these types of problems
caused by Windows’ centralized Registry.
Breaking an application into finer-grained components also serves our design
goal of supporting interoperation and collaboration between applications.
tions can publish pieces of themselves that provide specific functionality, which
other applications can make use of either directly or indirectly.
This will be illus-
trated as we look in more detail at the four kinds of components that can be pub-
Above the package manager sits another important system service, the
While the package manager is responsible for maintaining static infor-
mation about all installed applications, the activity manager determines when,
where, and how those applications should run.
Despite its name, it is actually
responsible for running all four types of application components and implementing
the appropriate behavior for each of them.
is a part of the application that interacts directly with the user
through a user interface. When the user launches an application on their device,
this is actually an activity inside the application that has been designated as such a
main entry point.
The application implements code in its activity that is responsi-
ble for interacting with the user.
The example email manifest shown in Fig. 10-51 contains two activities. The
first is the main mail user interface, allowing users to view their messages; the sec-
ond is a separate interface for composing a new message. The first mail activity is
declared as the main entry point for the application, that is, the activity that will be
started when the user launches it from the home screen.
Since the first activity is the main activity, it will be shown to users as an appli-
cation they can launch from the main application launcher.
If they do so, the sys-
tem will be in the state shown in Fig. 10-52. Here the activity manager, on the left
side, has made an internal
instance in its process to keep track of
One or more of these activities are organized into containers called
, which roughly correspond to what the user experiences as an application.
this point the activity manager has started the email application’s process and an
instance of its
for displaying its main UI, which is associated