App Fundamentals

Application Fundamentals

Android apps are written in the java programming language. The Android SDK tools compile our code --- along with any data and resource files --- into 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:

a>The Android operating system is a multi-user linux system in which each app is a different user

b>By default,the system assigns each app a unique Linux system user ID(the ID is uses 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.

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

d>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. 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:

a>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).

b>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.

App Components

activities:

An activity represents a single screen with a user interface.

Services:

A service is a component that runs in the background to perform long-running operations or to perform work for remote processes.And A service does not provide a user interface.

Content providers:

A content provider manages a shared set of app data. We can store the data in the file system,an SQLite database, on the web, or any other persistent storage location our app can access.Through the content provider, other apps can query or even modify the data(if the content provider allows it).

Content providers are also useful for reading and writing data that is private to our app and not shared.

Broadcast receivers:

A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate form the system. Apps can also initiate broadcasts.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. Many commonly, a broadcast receiver is just a "gateway" to other components and is intended to do a very minimal amount of work.

A unique aspect of the Android system design is that any app can start another app's component.

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. Therefore, unlike apps on most other systems, Android apps don't have a single entry point (there's no main() function).

Because the system runs each app in a separate process with file permissions that restrict access to other apps, our app cannot directly activate a component from another app. The Android system, however, can. So, to activate a component in another app, we must deliver a message to the system that specifies our intent to start a particular component. The system then activates the component for us.

Activating Components

Three of the four component type --- activities, services,and broadcast receivers --- are activated by an asynchronous message called an intent.

An intent is created with an Intent object, which defines a message to activate either a specific component or a specific type of component --- an intent can be either explicit or implicit, respectively.

For activities and services, an intent defines the action to perform (for example, to "view" or "send" something) and many specify the URI of the data to act on (among other things that component being started might need to know).

For broadcast receivers, the intent simply defines the announcement being broadcast.

The other component type, content provider, is not activated by intents. Rather, it is activated when targeted by a request from a ContentResolver.

There are separate methods for activating each type of component:

a>We can start an activity (or give it something new to do) by passing an intent to startActivity() or startActivityForResult() (when you want the activity to return a result).

b>We can start a service (or give new instructions to an ongoing service) by passing an intent to startService(). Or we can bind to the service by passing an intent to bindService().

c>We can initiate a broadcast by passing an intent to methods like sendBroadcast(), sendOrderedBroadcast(), or sendStickyBroadcast().

d>We can perform a query to a content provider by calling query() on a ContentResolver.

The Manifest File

Before the Android system can start an app component, the system must know that the component exists by reading the app's AndroidManifest.xml file (the "manifest" file). Our app must declare all its components in this file, which must be at the root of the app project directory.

The manifest does a number of things in addition to declaring the app's components, such as:

a>Identify any user permissions the app requires.

b>Declare the minimum API Level required, based on which APIs the app uses.

c>Declare hardware and software features used or required by the app.

d>API libraries the app needs to be linked against (other than the Android framework APIs), such as the Google Maps library.

e>And more.

Declaring components

The primary task of the manifest is to inform the system about the app's components.

We must declare all app components this way:

a> <activity> elements for activities

b> <service> elements for services

c> <receiver> elements for broadcast receivers

d> <provider> elements for content provider

Activities, services, and content providers that you include in your source but do not declare in the manifest are not visible to the system and, consequently, can never run. However, broadcast receivers can be either declared in the manifest or created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling registerReceiver().

Declaring component capabilities

We can use an Intent to start activities, services, and broadcast receivers.

The way the system identifies the components that can response to an intent is by comparing the intent received to the intent filters provided in the manifest file of other apps on the device.

When we declare an activity in our app's manifest, we can optionally include intent filters that declare the capabilities of the activity so it can respond to intents from other apps. We can declare an intent filter for our component by adding an <intent-filter> element as a child of the component's declaration element.

Declaring app requirements

There are a variety of devices powered by Android and not all of them provide the same features and capabilities. In order to prevent our app from being installed on devices the lack features needed by our app, it's important that we clearly define a profile for the types of devices our app supports by declaring device and software requirements in our manifest file. Most of these declarations are information only and the system does not read them, but external services such as Google Play do read them in order to provide filtering for users when they search for apps from their device.

App Resources

An Android app is composed of more than just code --- it requires resources that are separate from the source code.

For every resource that we include in our Android project, the SDK build tools define a unique integer ID, which we can use to reference the resource from our app code or from other resources defined in XML.

One of the most important aspect of providing resources separate from our source code is the ability for we to provide alternative resources for different device configurations.

Android supports many different qualifiers for our alternative resources. The qualifier is a short string that we include in the name of our resource directories in order to define the device configuration for which those resources should be used. As another example, we should often create different layouts for our activities, depending on the device's screen orientation and size.