The AndroidManifest.xml file is the control file that tells the system what to do with all the top-level components (specifically activities, services, intent receivers, and content providers described below) you've created. For instance, this is the "glue" that actually specifies which Intents your Activities receive.
<manifest> The root node of the file, describing the complete contents of the package. Under it you can place:
<uses-permission> Requests a security permission that your package must be granted in order for it to operate correctly. See the Security Model document for more information on permissions. A manifest can contain zero or more of these elements. <permission> Declares a security permission that can be used to restrict which applications can access components or features in your (or another) package. See the Security Model document for more information on permissions. A manifest can contain zero or more of these elements.
<instrumentation> Declares the code of an instrumentation component that is available to test the functionality of this or another package. See Instrumentation for more details. A manifest can contain zero or more of these elements.
<application> Root element containing declarations of the application-level components contained in the package. This element can also include global and/or default attributes for the application, such as a label, icon, theme, required permission, etc. A manifest can contain zero or one of these elements (more than one application tag is not allowed). Under it you can place zero or more of each of the following component declarations:
<activity> An Activity is the primary facility for an application to interact with the user. The initial screen the user sees when launching an application is an activity, and most other screens they use will be implemented as separate activities declared with additional activity tags. Note: Every Activity must have an <activity> tag in the manifest whether it is exposed to the world or intended for use only within its own package. If an Activity has no matching tag in the manifest, you won't be able to launch it.
Optionally, to support late runtime lookup of your activity, you can include one or more <intent-filter> elements to describe the actions the activity supports:
<intent-filter> Declares a specific set of Intent values that a component supports, in the form of an IntentFilter . In addition to the various kinds of values that can be specified under this element, attributes can be given here to supply a unique label, icon, and other information for the action being described.
<action> An Intent action that the component supports.
<category> An Intent category that the component supports.
<type> An Intent data MIME type that the component supports.
<scheme> An Intent data URI scheme that the component supports.
<authority> An Intent data URI authority that the component supports.
<path> An Intent data URI path that the component supports.
<receiver> An IntentReceiver allows an application to be told about changes to data or actions that happen, even if it is not currently running. As with the activity tag, you can optionally include one or more <intent-filter> elements that the receiver supports; see the activity's <intent-filter> description for more information.
<service> A Service is a component that can run in the background for an arbitrary amount of time. As with the activity tag, you can optionally include one or more <intent-filter> elements that the receiver supports; see the activity's <intent-filter> description for more information.
<provider> A ContentProvider is a component that manages persistent data and publishes it for access by other applications.
Activity 活動 ( 通常指一個畫面 single screen)
Each activity is implemented as a single class that extends the Activity base class
Your class will display a user interface composed of Views and respond to events.
For example, a text messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. Each of these screens would be implemented as an activity
Action and Intent
Android uses a special class called an Intent to move from screen to screen
The two most important parts of the intent data structure are the action and the data to act upon.
Typical values for action are MAIN (the front door of the activity), VIEW, PICK, EDIT
For example, to view contact information for a person, you would create an intent with the VIEW action and the data set to a URI representing that person.
A View is an object that knows how to draw itself to the screen. Android user interfaces are comprised of trees of Views. If you want to perform some custom graphical technique (as you might if you're writing a game, or building some unusual new user interface widget) then you'd create a View.
An Intent is a simple message object that represents an "intention" to do something. For example, if your application wants to display a web page, it expresses its "Intent" to view the URI by creating an Intent instance and handing it off to the system. The system locates some other piece of code (in this case, the Browser) that knows how to handle that Intent, and runs it. Intents can also be used to broadcast interesting events (such as a notification) system-wide.
You can use an IntentReceiver when you want code in your application to execute in reaction to an external event,
for example, when the phone rings, or when the data network is available, or when it's midnight. Intent receivers do not display a UI, although they may use the NotificationManager to alert the user if something interesting has happened. Intent receivers are registered in AndroidManifest.xml, but you can also register them from code using Context.registerReceiver() .
Your application does not have to be running for its intent receivers to be called; the system will start your application, if necessary, when an intent receiver is triggered. Applications can also send their own intent broadcasts to others with Context.broadcastIntent() .
A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process, depending on its needs. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.
A Service is code that is long-lived and runs without a UI.
A good example of this is a media player playing songs from a play list. In a media player application, there would probably be one or more activities that allow the user to choose songs and start playing them. However, the music playback itself should not be handled by an activity because the user will expect the music to keep playing even after navigating to a new screen.
In this case, the media player activity could start a service using Context.startService() to run in the background to keep the music going. The system will then keep the music playback service running until it has finished. (You can learn more about the priority given to services in the system by reading Lifecycle of an Android Application .)
Note that you can connect to a service (and start it if it's not already running) with the Context.bindService() method. When connected to a service, you can communicate with it through an interface exposed by the service. For the music service, this might allow you to pause, rewind, etc.
A Notification is a small icon that appears in the status bar. Users can interact with this icon to receive information. The most well-known notifications are SMS messages, call history, and voicemail, but applications can create their own. Notifications are the strongly-preferred mechanism for alerting the user of something that needs their attention
A ContentProvider is a data storehouse that provides access to data on the device; the classic example is the ContentProvider that's used to access the user's list of contacts. Your application can access data that other applications have exposed via a ContentProvider, and you can also define your own ContentProviders to expose data of your own.
Applications can store their data in files, an SQLite database, or any other mechanism that makes sense.
A content provider, however, is useful if you want your application's data to be shared with other applications.
A content provider is a class that implements a standard set of methods to let other applications store and retrieve the type of data that is handled by that content provider
Lifecycle of an Android Application
In most cases, every Android application runs in its own Linux process.
This process is created for the application when some of its code needs to be run, and will remain running until it is no longer needed and the system needs to reclaim its memory for use by other applications.
It is important that application developers understand how different application components (in particular Activity , Service , and IntentReceiver ) impact the lifetime of the application's process. Not using these components correctly can result in the system killing the application's process while it is doing important work.
A common example of a process lifecycle bug is an IntentReceiver that starts a thread when it receives an Intent in its onReceiveIntent() method, and then returns from the function. Once it returns, the system considers that IntentReceiver to be no longer active, and thus its hosting process no longer needed (unless other application components are active in it). Thus, it may kill the process at any time to reclaim memory, terminating the spawned thread that is running in it.
The solution to this problem is to start a Service from the IntentReceiver, so the system knows that there is still active work being done in the process.
Hierarchy of Screen Elements
A Tree-Structured UI
How a Child Specifies Its Position and Size
Storing, Retrieving and Exposing Data
Preferences A lightweight mechanism to store and retrieve key/value pairs of primitive data types. This is typically used to store application preferences.
Files You can store your files on the device or on a removable storage medium. By default, other applications cannot access these files.
Databases The Android APIs contain support for SQLite. Your application can create and use a private SQLite database. Each database is private to the package that creates it.
Content Providers A content provider is a optional component of an application that exposes read/write access to an application's private data, subject to whatever restrictions it wants to impose. Content providers implement a standard request syntax for data, and a standard access mechanism for the returned data. Android supplies a number of content providers for standard data types, such as personal contacts.
Network Don't forget that you can also use the network to store and retrieve data.
The combination of startSubActivity() and onActivityResult() can be thought of as an asynchronous RPC (remote procedure call) and forms the recommended way for Activities to invoke each other and share services