安卓应用基硅

安卓应用使用java语言进行编写。Android SDK tools把编译后的code连同所有数据和资源文件打包成apk文件。一个apk文件被认为是一个应用程序，使用安卓系统的设备可以通过安装apk文件，运行应用程序。

每个被安装于安卓设备上的应用程序都将在自己所属的security sandbox(安全沙箱)中运行。

• 安卓操作系统是一个多用户的linux系统，在系统中每个应用都是一个不同的用户。
• 系统默认为每一个应用程序设置a unique linux user id(此id只被系统调用，对于其它应用而言是不可知的)系统为每个应用所属的文件设置权限，使文件只能被设置的user id访问。
• Each 进程（Process）都有自己所属的vm,以致于应用程序的代码能同其它应用程序隔离运行。
• 默认，每个应用运行自己所属的linux process(进程)。当应用的任意组件需要执行时，Android将启动进程。当不需要时或者系统需要为其它应用释放内存时将关闭进程。

用这种方法，安卓系统实现了最小特权原则（the principle of least privilege）。换句话说，每个应用默认只能访问正常运行所要求的组件。This创建了一个安全的环境，应用程序不能访问未被授权的东东。

尽管如此，系统还提供了一些应用程序间共享数据的方法:

• 它使两个应用间共享相同的linux user id成为可能，在这种情况下，它们能访问彼此的文件。为了节约系统资源，具有相同user id的应用可又运行在同一个linux进程中和共享同一个vm(应用必须签署相同的证书)。
• 应用可又要求授权访问设备数据如联系人，短信信息，SD card,相机，蓝牙等。所有应用权限必须在安装时被用户授权。

关于安卓应用在系统中是怎么存在的。下面的文档将为你介绍：

• 核心框架组件设计你的应用。
• manifest文件用于声明组件及要求的应用程序的设备特性 （required device features for your application）.
• 与代码分离的资源文件和允许对应用程序进行优化又更好的与各种设备相兼容

Application Components（应用组件）

Application components are the essential building blocks of an Android application. Each component is a different point through which the system can enter your application. 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 role—each one is a unique building block that helps define your application's overall behavior.（应用组件是安卓应用的基本构建模块。每个组件都是一个不同的点，系统通过它可以进入你的应用。不是所有的组件都是用户实际的切入点，一些组件是相互依存的，但是每一个作为自己的实体存在并发挥着特殊的作用。每个组件都是用于定于应用全局行为的唯一构建模块）

There are four different types of application 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 application components（四大组件如下所示）:

Activities

An activity represents a single screen with a user interface. For example, an email application 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 application, each one is independent of the others. As such, a different application can start any one of these activities (if the email application allows it). For example, a camera application can start the activity in the email application 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 theActivitiesdeveloper guide.

（一个activity代表a single screen with a user interface。例如，一个email应用有一个activity用于显示一系列邮件，有一个activity用于撰写电子邮件，还有一个用于阅读邮件的activity。这几个activity一块工作形成拥有连贯用户体验的电子邮件应用程序，但是每个activity又都是彼此独立的。同样地，其它不同的应用可又启动这些activity中的任意一个（如果email应用允许）。例如，为了让用户共享照片，一个照相机应用可以启动在email应用中用于写新邮件的activity。通过继承Activity来创建activity。在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 application, 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 theServices developer guide.（service是运行于后台的组件，用于执行需要长时间运行的动作或执行远程进程的工作。服务不提供用户界面。例如，当用户需要使用不同的应用或者不阻碍与activity的用户交互的情况下获取网络数据的时候播放背景音乐）

Content providers

A content provider manages a shared set of application data. You can store the data in the file system, an SQLite database, on the web, or any other persistent storage location your application can access. Through the content provider, other applications 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 application 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 application and not shared. For example, theNote Pad sample application uses a content provider to save notes.（content provider用于管理不同应用之间数据的共享。你可以使用文件系统、sqlite数据库、互联网或者其它你的应用能访问到的持久存储单元存储数据。通过content rpovider其它应用可又查询甚至于修改数据（如果content provider允许的话））。例如，安卓系统提供用于管理用户联系人信息的content provider。同样的，拥有适当权限的应用可又查询content provider的部分（例如ContactsContract.Data）,用于读或写特定的联系人信息

A content provider is implemented as a subclass of

ContentProvider

and must implement a standard set of APIs that enable other applications to perform transactions. For more information, see the Content Providers developer guide.（通过继承ContentProvider即可实现content provider）

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. Applications can also initiate broadcasts—for example, to let other applications 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 notificationto 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.（broadcast receiver用于响应系统范围内的广播通知的组件。许多源于系统的广播---如广播通告屏幕已关闭，电量低或者被拍照完成。应用可以开始广播---如，让其它应用知道一些数据已被下载到设备，对于它们来说这些数据是可用的。虽然broadcast receiver不显示用户界面，但是它们可以创建一个状态栏通知提醒用户，当一个广播事件发生的时候。通常，broadcast receiver对于其它组件而言，只是一个“gateway（途径）”，并且它总是被用于完成最简单的任务。例如，它应到创建一个 service 来执行基于该事件的一些任务。broadcast receiver 通过继承 

BroadcastReceiver

 类实现功能，并且每个广播实现了 

Intent

 对象。 你可以在 

BroadcastReceiver

 类部分了解更多。）

A unique aspect of the Android system design is that any application can start another application’s component. For example, if you want the user to capture a photo with the device camera, there's probably another application that does that and your application 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 application. Instead, you can simply start the activity in the camera application that captures a photo. When complete, the photo is even returned to your application so you can use it. To the user, it seems as if the camera is actually a part of your application.

（安卓系统的独特之处在于任何应用都可以启动其它应用的组件。例如，如果你想通过相机拍照，可能另一个应用已经实现了这个功能，不用再重新开发。你不需要包含甚至连链接拍照应用的代码都不需要。相反，你只需简单的启动拍照应用中用于拍照的activity。拍完后，照片甚至被送到你的应用，你可以直接使用。对于用户而言，看起来拍照应用就像你的应用的一部分）

When the system starts a component, it starts the process for that application (if it's not already running) and instantiates the classes needed for the component. For example, if your application starts the activity in the camera application that captures a photo, that activity runs in the process that belongs to the camera application, not in your application's process. Therefore, unlike applications on most other systems, Android applications don't have a single entry point (there's no

main()

function, for example).

（当系统启动一个组件时，就为该应用启动了进程 (即便还没有开始运行) 并对该组件所必需的类进行实例化。例如，如果你的应用程序启动了拍照应用的 activity 用于拍摄一张照片，该 activity 在属于摄像应用的进程中运行，而非你的应用程序进程中。因此，不像其他系统中的应用程序，Android 应用程序不存在单一的入口 (例如，没有 

main()

方法)。）

Because the system runs each application in a separate process with file permissions that restrict access to other applications, your application cannot directly activate a component from another application. The Android system, however, can. So, to activate a component in another application, you must deliver a message to the system that specifies yourintent to start a particular component. The system then activates the component for you.

（因为系统是在一个有着文件权限的独立进程中运行每一个应用，限制对其他应用程序的访问，你的应用程序不能直接激活其他应用程序的组件。 当然了，Android 系统可以。 因此为了激活其他应用程序的组件，你必须向系统发布一个消息，具体说明你的 intent（意图） 以启动一个特定组件。然后，系统为你激活该组件。）

Activating Components

Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called anintent. Intents bind individual components to each other at runtime (you can think of them as the messengers that request an action from other components), whether the component belongs to your application or another.

（四大组件中的三种 — activities, services, 和 broadcast receivers — 是由一个叫做  intent 的异步信息激活。 Intents 在运行时绑定一个独立组件给其他组件(你可以将它们理解为信使，其他组件通过它要求一个动作)，无论该组件属于你的或者其他的应用程序。）

An intent is created with an

Intent

object, which defines a message to activate either a specific component or a specifictype of component—an intent can be either explicit or implicit, respectively.

（intent 由 

Intent

 对象创建，Intent定义了一个信息来用于激活一个特定组件或者一个特定组件类型 — 一个 intent 可以是显式的也可是隐式的。）

For activities and services, an intent defines the action to perform (for example, to "view" or "send" something) and may specify the URI of the data to act on (among other things that the component being started might need to know). For example, an intent might convey a request for an activity to show an image or to open a web page. In some cases, you can start an activity to receive a result, in which case, the activity also returns the result in an

Intent

(for example, you can issue an intent to let the user pick a personal contact and have it returned to you—the return intent includes a URI pointing to the chosen contact).

（对于 activities 和 services， intent 定义了需要执行的动作 (例如，去 "浏览" 或者 "发送" 一些内容) 并且可能指定操作所需数据的 URI  (尤其是组件启动时可能需要知道的资源)。例如， 一个 intent 可能会传达一个activity请求以展示一张图像或打开一个 web 页面的请求。在一些情况下，你会启动一个 activity 用于接收一个结果，此时，该 activity 也会在一个 

Intent

 中返回该结果(例如，你可以设计一个 intent 使得用户选择一个联系人并将其返回给你 — 返回的 intent 包括一个指向选定联系人的 URI)。）

For broadcast receivers, the intent simply defines the announcement being broadcast (for example, a broadcast to indicate the device battery is low includes only a known action string that indicates "battery is low").

（对于 broadcast receivers，intent 简单定义了需要广播的通知内容 (例如， 表示电池电量低的 broadcast 仅包括一个知名的活动字符串表示 "电池电量低")。）

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

There are separate methods for activiting each type of component:

• 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

  .

For more information about using intents, see the Intents and Intent Filters document. More information about activating specific components is also provided in the following documents:Activities,Services,

BroadcastReceiver

andContent Providers.

The Manifest File（清单文件）

Before the Android system can start an application component, the system must know that the component exists by reading the application's

AndroidManifest.xml

file (the "manifest" file). Your application must declare all its components in this file, which must be at the root of the application project directory.

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

• Identify any user permissions the application requires, such as Internet access or read-access to the user's contacts.
• Declare the minimum API Levelrequired by the application, based on which APIs the application uses.
• Declare hardware and software features used or required by the application, such as a camera, bluetooth services, or a multitouch screen.
• API libraries the application needs to be linked against (other than the Android framework APIs), such as theGoogle Maps library.
• And more

Declaring components（声明组件）

The primary task of the manifest is to inform the system about the application's components. For example, a manifest file can declare an activity as follows:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>      

In the

<application>

element, the

android:icon

attribute points to resources for an icon that identifies the application.

In the

<activity>

element, the

android:name

attribute specifies the fully qualified class name of the

Activity

subclass and the

android:label

attributes specifies a string to use as the user-visible label for the activity.

You must declare all application components this way:

• <activity>

  elements for activities

• <service>

  elements for services

• <receiver>

  elements for broadcast receivers

• <provider>

  elements for content providers

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()

.

For more about how to structure the manifest file for your application, see theThe AndroidManifest.xml Filedocumentation.

Declaring component capabilities

As discussed above, in Activating Components, you can use an

Intent

to start activities, services, and broadcast receivers. You can do so by explicitly naming the target component (using the component class name) in the intent. However, the real power of intents lies in the concept of intent actions. With intent actions, you simply describe the type of action you want 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 theintent filters provided in the manifest file of other applications on the device.

When you declare a component in your application's manifest, you can optionally include intent filters that declare the capabilities of the component so it can respond to intents from other applications. You can declare an intent filter for your component by adding an

<intent-filter>

element as a child of the component's declaration element.

For example, an email application with an activity for composing a new email might declare an intent filter in its manifest entry to respond to "send" intents (in order to send email). An activity in your application can then create an intent with the “send” action (

ACTION_SEND

), which the system matches to the email application’s “send”activity and launches it when you invoke the intent with

startActivity()

.

For more about creating intent filters, see the Intents and Intent Filters document.

Declaring application 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 your application from being installed on devices that lack features needed by your application, it's important that you clearly define a profile for the types of devices your application supports by declaring device and software requirements in your manifest file. Most of these declarations are informational only and the system does not read them, but external services such as Android Market do read them in order to provide filtering for users when they search for applications from their device.

For example, if your application requires a camera and uses APIs introduced in Android 2.1 (API Level 7), you should declare these as requirements in your manifest file. That way, devices that donot have a camera and have an Android version lower than 2.1 cannot install your application from Android Market.

However, you can also declare that your applicaiton uses the camera, but does notrequire it. In that case, your application must perform a check at runtime to determine if the device has a camera and disable any features that use the camera if one is not available.

Here are some of the important device characteristics that you should consider as you design and develop your application:

Screen size and density

In order to categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical dimensions of the screen) and screen density (the physical density of the pixels on the screen, or dpi—dots per inch). To simplify all the different types of screen configurations, the Android system generalizes them into select groups that make them easier to target.

The screen sizes are: small, normal, large, and extra large.

The screen densities are: low density, medium density, high density, and extra high density.

By default, your application is compatible with all screen sizes and densities, because the Android system makes the appropriate adjustments to your UI layout and image resources. However, you should create specialized layouts for certain screen sizes and provide specialized images for certain densities, using alternative layout resources, and by declaring in your manifest exactly which screen sizes your application supports with the

<supports-screens>

element.

For more information, see the Supporting Multiple Screensdocument.

Input configurations

Many devices provide a different type of user input mechanism, such as a hardware keyboard, a trackball, or a five-way navigation pad. If your application requires a particular kind of input hardware, then you should declare it in your manifest with the

<uses-configuration>

element. However, it is rare that an application should require a certain input configuration.

Device features

There are many hardware and software features that may or may not exist on a given Android-powered device, such as a camera, a light sensor, bluetooth, a certain version of OpenGL, or the fidelity of the touchscreen. You should never assume that a certain feature is available on all Android-powered devices (other than the availability of the standard Android library), so you should declare any features used by your application with the

<uses-feature>

element.

Platform Version

Different Android-powered devices often run different versions of the Android platform, such as Android 1.6 or Android 2.3. Each successive version often includes additional APIs not available in the previous version. In order to indicate which set of APIs are available, each platform version specifies an API Level (for example, Android 1.0 is API Level 1 and Android 2.3 is API Level 9). If you use any APIs that were added to the platform after version 1.0, you should declare the minimum API Level in which those APIs were introduced using the

<uses-sdk>

element.

It's important that you declare all such requirements for your application, because, when you distribute your application on Android Market, Market uses these declarations to filter which applications are available on each device. As such, your application should be available only to devices that meet all your application requirements.

For more information about how Android Market filters applications based on these (and other) requirements, see theMarket Filtersdocument.

Application Resources

An Android application 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 application. For example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using application resources makes it easy to update various characteristics of your application without modifying code and—by providing sets of alternative resources—enables you to optimize your application for a  variety of device configurations (such as different languages and screen sizes).

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 application code or from other resources defined in XML. For example, if your application 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.

One of the most important aspects of providing resources separate from your source code is the ability for you to provide alternative resources for different device configurations. For example, by defining UI strings in XML, you can translate the strings into other languages and save those strings in separate files. Then, based on a languagequalifierthat you append to the resource directory's name (such as

res/values-fr/

for French string values) and the user's language setting, the Android system applies the appropriate language strings to your UI.

Android supports many different qualifiers for your alternative resources. The qualifier is a short string that you include in the name of your resource directories in order to define the device configuration for which those resources should be used. As another example, you should often create different layouts for your activities, depending on the device's screen orientation and size. For example, when the device screen is in portrait orientation (tall), you might want a layout with buttons to be vertical, but when the screen is in landscape orientation (wide), the buttons should be aligned horizontally. To change the layout depending on the orientation, you can define two different layouts and apply the appropriate qualifier to each layout's directory name. Then, the system automatically applies the appropriate layout depending on the current device orientation.

For more about the different kinds of resources you can include in your application and how to create alternative resources for various device configurations, see theApplication Resources developer guide.