Introduction to Android

Android provides a rich application framework that allows you to build innovative apps and
games for mobile devices in a Java language environment. The documents listed in the left
navigation provide details about how to build apps using Android's various APIs.
If you're new to Android development, it's important that you understand the following
fundamental concepts about the Android app framework:
Apps provide multiple entry points

Android apps are built as a combination of distinct components that can be invoked individually.
For instance, an individual activity provides a single screen for a user interface, and a service
independently performs work in the background.
From one component you can start another component using an intent. You can even start a
component in a different app, such as an activity in a maps app to show an address. This model
provides multiple entry points for a single app and allows any app to behave as a user's "default"
for an action that other apps may invoke.
Apps adapt to different devices

Android provides an adaptive app framework that allows you to provide unique resources for
different device configurations. For example, you can create different XML layout files for
different screen sizes and the system determines which layout to apply based on the current
device's screen size.
You can query the availability of device features at runtime if any app features require specific
hardware such as a camera. If necessary, you can also declare features your app requires so app
markets such as Google Play Store do not allow installation on devices that do not support that
feature.
Application Fundamentals

Android apps are written in the Java programming language. The Android SDK tools compile
your codealong with any data and resource filesinto an APK: an Android package, which is
an archive file with an .apk suffix. One APK file contains all the contents of an Android app and
is the file that Android-powered devices use to install the app.
Once installed on a device, each Android app lives in its own security sandbox:

The Android operating system is a multi-user Linux system in which each app
is a different user.

By default, the system assigns each app a unique Linux user ID (the ID is
used only by the system and is unknown to the app). The system sets
permissions for all the files in an app so that only the user ID assigned to that
app can access them.

Each process has its own virtual machine (VM), so an app's code runs in
isolation from other apps.

By default, every app runs in its own Linux process. Android starts the
process when any of the app's components need to be executed, then shuts
down the process when it's no longer needed or when the system must
recover memory for other apps.

In this way, the Android system implements the principle of least privilege. That is, each app, by
default, has access only to the components that it requires to do its work and no more. This
creates a very secure environment in which an app cannot access parts of the system for which it
is not given permission.
However, there are ways for an app to share data with other apps and for an app to access system
services:

It's possible to arrange for two apps to share the same Linux user ID, in which
case they are able to access each other's files. To conserve system resources,
apps with the same user ID can also arrange to run in the same Linux process
and share the same VM (the apps must also be signed with the same
certificate).

An app can request permission to access device data such as the user's
contacts, SMS messages, the mountable storage (SD card), camera,
Bluetooth, and more. All app permissions must be granted by the user at
install time.

That covers the basics regarding how an Android app exists within the system. The rest of this
document introduces you to:

The core framework components that define your app.

The manifest file in which you declare components and required device
features for your app.

Resources that are separate from the app code and allow your app to
gracefully optimize its behavior for a variety of device configurations.

App Components

App components are the essential building blocks of an Android app. Each component is a
different point through which the system can enter your app. Not all components are actual entry
points for the user and some depend on each other, but each one exists as its own entity and plays
a specific roleeach one is a unique building block that helps define your app's overall behavior.
There are four different types of app components. Each type serves a distinct purpose and has a
distinct lifecycle that defines how the component is created and destroyed.
Here are the four types of app components:
Activities
An activity represents a single screen with a user interface. For example, an
email app might have one activity that shows a list of new emails, another
activity to compose an email, and another activity for reading emails.
Although the activities work together to form a cohesive user experience in
the email app, each one is independent of the others. As such, a different app
can start any one of these activities (if the email app allows it). For example,
a camera app can start the activity in the email app that composes new mail,
in order for the user to share a picture.

An activity is implemented as a subclass of Activity and you can learn more about it in
the Activities developer guide.
Services
A service is a component that runs in the background to perform long-running
operations or to perform work for remote processes. A service does not
provide a user interface. For example, a service might play music in the
background while the user is in a different app, or it might fetch data over the
network without blocking user interaction with an activity. Another
component, such as an activity, can start the service and let it run or bind to
it in order to interact with it.

A service is implemented as a subclass of Service and you can learn more about it in the
Services developer guide.
Content providers
A content provider manages a shared set of app data. You can store the data
in the file system, an SQLite database, on the web, or any other persistent
storage location your app can access. Through the content provider, other
apps can query or even modify the data (if the content provider allows it). For
example, the Android system provides a content provider that manages the
user's contact information. As such, any app with the proper permissions can
query part of the content provider (such as ContactsContract.Data) to read
and write information about a particular person.

Content providers are also useful for reading and writing data that is private to your app
and not shared. For example, the Note Pad sample app uses a content provider to save
notes.
A content provider is implemented as a subclass of ContentProvider and must
implement a standard set of APIs that enable other apps to perform transactions. For more
information, see the Content Providers developer guide.
Broadcast receivers
A broadcast receiver is a component that responds to system-wide broadcast
announcements. Many broadcasts originate from the systemfor example, a
broadcast announcing that the screen has turned off, the battery is low, or a
picture was captured. Apps can also initiate broadcastsfor example, to let
other apps know that some data has been downloaded to the device and is
available for them to use. Although broadcast receivers don't display a user
interface, they may create a status bar notification to alert the user when a
broadcast event occurs. More commonly, though, a broadcast receiver is just
a "gateway" to other components and is intended to do a very minimal
amount of work. For instance, it might initiate a service to perform some work
based on the event.

A broadcast receiver is implemented as a subclass of BroadcastReceiver and each

broadcast is delivered as an Intent object. For more information, see the
BroadcastReceiver class.
A unique aspect of the Android system design is that any app can start another apps component.
For example, if you want the user to capture a photo with the device camera, there's probably
another app that does that and your app can use it, instead of developing an activity to capture a
photo yourself. You don't need to incorporate or even link to the code from the camera app.
Instead, you can simply start the activity in the camera app that captures a photo. When
complete, the photo is even returned to your app so you can use it. To the user, it seems as if the
camera is actually a part of your app.
When the system starts a component, it starts the process for that app (if it's not already running)
and instantiates the classes needed for the component. For example, if your app starts the activity
in the camera app that captures a photo, that activity runs in the process that belongs to the
camera app, not in your app's process. Therefore, unlike apps on most other systems, Android
apps don't have a single entry point (there's no main() function, for example).
Because the system runs each app in a separate process with file permissions that restrict access
to other apps, your app cannot directly activate a component from another app. The Android
system, however, can. So, to activate a component in another app, you must deliver a message to
the system that specifies your intent to start a particular component. The system then activates
the component for you.