1. App Fundamentals
2. Device Compatibility
3. System Permissions
1. App Fundamentals
1.1 App Components
<1>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.
<2>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.
<3>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.
<4>Broadcast Receivers
A broadcast receiver is a component that responds to system-wide broadcast announcements. Many broadcasts originate from the
system—for example, a broadcast announcing that the screen has turned off, the battery is low, or a picture was captured. Apps
can also initiate broadcasts—for 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
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.
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.
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
1.2 Activating Components
Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called intent
The other component type, content provider, is not activated by intents. Rather, it is activated when targeted by a request from a
ContentResolver. The content resolver handles all direct transactions with the content provider so that the component that's
performing transactions with the provider doesn't need to and instead calls methods on the ContentResolver object. This leaves
a layer of abstraction between the content provider and the component requesting information (for security).
Examples:
You 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).
You can start a service (or give new instructions to an ongoing service) by passing an Intent to startService(). Or you can bind to
the service by passing an Intent to bindService().
You can initiate a broadcast by passing an Intent to methods like sendBroadcast(), sendOrderedBroadcast(), or sendStickyBroadcast().
You can perform a query to a content provider by calling query() on a ContentResolver
1.3 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). Your 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:
<1>Identify any user permissions the app requires,
<2>Declare the minimum API Level required by the app, based on which APIs the app uses
<3>Declare hardware and software features used or required by the app, such as a camera, bluetooth services, or a multitouch
screen.
<4>API libraries the app needs to be linked against
<5>and more
1.4 Declaring component capabilities
the real power of intents lies in the concept of implicit intents. An implicit intent simply describe the type of action to perform
(and optionally, the data upon which you’d like to perform the action) and allow the system to find a component on the device that
can perform the action and start it. If there are multiple components that can perform the action described by the intent, then the
user selects which one to use.
The way the system identifies the components that can respond to an intent is by comparing the intent received to the intent filters
provided in the manifest file of other apps on the device.
For example, if you've built an email app with an activity for composing a new email, you can declare an intent filter to respond to "send"
intents (in order to send a new email) like this:
<manifest ... > ... <application ... > <activity android:name="com.example.project.ComposeEmailActivity"> <intent-filter> <action android:name="android.intent.action.SEND" /> <data android:type="*/*" /> <category android:name="android.intent.category.DEFAULT" /> </intent-filter> </activity> </application> </manifest>
Then, if another app creates an intent with the ACTION_SEND action and pass it to startActivity(), the system may start your activity so
the user can draft and send an email.
1.5 App Resources
An Android app is composed of more than just code—it requires resources that are separate from the source code, such as images,
audio files, and anything relating to the visual presentation of the app
For every resource that you include in your Android project, the SDK build tools define a unique integer ID, which you can use to
reference the resource from your app code or from other resources defined in XML. For example, if your app contains an image file
named logo.png (saved in the res/drawable/ directory), the SDK tools generate a resource ID named R.drawable.logo, which you can
use to reference the image and insert it in your user interface.
2. Device Compatibility
3. System Permissions