android应用基础开发

Application Fundamentals

Android apps are written in the Java programming language. The Android SDK tools compile your 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:

• 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. The user has to explicitly grant these permissions. For more information, see Working with System Permissions.

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 role—each 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 Activitiesdeveloper 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 Servicesdeveloper 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 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.

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 app’s 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.

Activating Components

Three of the four component types—activities, services, and broadcast receivers—are activated by an asynchronous message called an intent. 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 app or another.

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

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

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 activating each type of component:

• You can start an activity (or give it something new to do) by passing an Intent to startActivity() orstartActivityForResult() (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 tostartService(). 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 and Content Providers.

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, such as:

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

Declaring components

The primary task of the manifest is to inform the system about the app'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 app.

In the <activity> element, the android:name attribute specifies the fully qualified class name of theActivity subclass and the android:label attribute specifies a string to use as the user-visible label for the activity.

You must declare all app 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 app, see The AndroidManifest.xml File documentation.

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 implicit intents. An implicit intent simply describes the type of action to perform (and, optionally, the data upon which you’d like to perform the action) and allows 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.

When you declare an activity in your app's manifest, you can optionally include intent filters that declare the capabilities of the activity so it can respond to intents from other apps. 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, 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 passes it to startActivity(), the system may start your activity so the user can draft and send an email.

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

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 your app from being installed on devices that lack features needed by your app, it's important that you clearly define a profile for the types of devices your app 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 Google Play do read them in order to provide filtering for users when they search for apps from their device.

For example, if your app requires a camera and uses APIs introduced in Android 2.1 (API Level 7), you should declare these as requirements in your manifest file like this:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />
    ...
</manifest>

Now, devices that do not have a camera and have an Android version lower than 2.1 cannot install your app from Google Play.

However, you can also declare that your app uses the camera, but does not require it. In that case, your app must set the required attribute to "false" and check at runtime whether the device has a camera and disable any camera features as appropriate.

More information about how you can manage your app's compatibility with different devices is provided in theDevice Compatibility document.

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 example, you should define animations, menus, styles, colors, and the layout of activity user interfaces with XML files. Using app resources makes it easy to update various characteristics of your app without modifying code and—by providing sets of alternative resources—enables you to optimize your app 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 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.

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 language qualifier that 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 different device configurations, read Providing Resources.

Android应用程序都写在Java编程语言。一：在Android SDK工具使用的任何数据和资源文件-成APK编译代码，沿着Android包，它与归档文件.apk文件后缀。一个APK文件包含一个Android应用程序的所有内容，并且是Android设备用于安装应用程序的文件。

一旦设备上安装，每个Android应用程序住在自己的安全沙箱：

• Android操作系统是一个多用户的Linux系统中，每个应用程序是不同的用户。
• 默认情况下，系统将分配每个应用了独特的Linux用户ID（该ID是由系统只使用，是未知的应用程序）。该系统为所有的文件权限的应用程序，以便只分配给该应用程序的用户ID可以访问它们。
• 每个进程都有自己的虚拟机（VM），所以应用程序的代码从其他应用程序隔离运行。
• 默认情况下，每一个应用程序在自己的Linux进程中运行。Android的启动过程中，当任何一个应用程序的组件需要被执行，然后关闭过程中，当它不再需要或系统必须为其他应用程序恢复内存。

这样一来，Android系统实现了最小权限原则。也就是说，每一个应用程序，默认情况下，只有到它需要做的工作并没有更多的组件的访问。这将创建在其中的应用程序不能访问它没有获准部分系统非常安全的环境。

不过，也有一个应用与其他应用程序和应用程序访问系统服务数据的方法：

• 这是可能的两个应用程序共享相同的Linux用户ID，在这种情况下，他们能够互相访问对方的文件安排。为了节约系统资源，拥有相同的用户ID的应用程序也可以安排在同一个Linux进程运行，并共享相同的VM（即应用程序也必须使用相同的证书签名）。
• 应用程序可以请求权限访问设备数据，如用户的联系人，短信，可安装存储（SD卡），摄像头，蓝牙，等等。用户必须明确授予这些权限。欲了解更多信息，请参阅 使用系统权限的使用。

这涉及对Android应用程序在系统中如何存在的基础。本文的其余部分向您介绍：

• 定义你的应用程序的核心框架组件。
• manifest文件中声明组件和所需的设备功能，为您的应用程序。
• 资源是从应用程序代码分开，并允许您的应用程序优雅地优化自己的行为，适用于各种设备的配置。

应用组件

应用组件是一个Android应用程序的最重要的基石。每个组件都是一个不同的角度，通过该系统可以进入你的应用程序。并非所有的组件对于用户的实际切入点和一些互相依赖，但每一个存在作为自己的实体，扮演一个特定的角色，每个人都是一个独特的建筑块，它帮助定义应用的整体行为。

有四种不同类型的应用程序组件。每种类型提供不同的目的，并具有明显的生命周期，它定义了如何创建组件和销毁。

这里有四种类型的应用程序组件：

活动

一个 活动代表具有一个用户接口的单一屏幕。例如，电子邮件应用程序可能有一个活动，显示新的电子邮件列表，另一个活动撰写电子邮件，和另一项活动阅读电子邮件。虽然活动共同形成的电子邮件应用程序一个有凝聚力的用户体验，每一个都是相互独立的。因此，不同的应用程序可以启动这些活动中的任何一个（如电子邮件应用程序允许）。例如，相机应用可以就在构成新的邮件，以便为用户共享一个图象的电子邮件应用程序的活性。

一个活动被实现为的子类的活动，你可以学到更多关于它的活动 开发人员指南。

服务

一个 服务是在后台运行，执行长时间运行的操作或为远程进程执行工作的一个组成部分。服务不提供用户界面。例如，一个服务可能，而用户是在一个不同的应用程序在背景中播放的音乐，或者它可能不会阻塞与一个活动的用户交互获取网络上的数据。另一组件，如一个活动，可以启动该服务，并让它运行或与其结合，以与它进行交互。

服务实现为的子类服务，您可以了解更多有关它在服务开发者指南。

内容提供商

一个 内容提供商管理一组共享应用程序数据。你可以存储数据在文件系统，SQLite数据库，在网络上，或任何其他持久性存储位置您的应用程序可以访问。通过内容提供商，其他应用程序可以查询甚至修改数据（如果内容提供商允许）。例如，Android系统提供了管理用户的联系人信息的内容提供商。因此，有相应权限的任何应用程序可以查询内容提供商（如部分 ContactsContract.Data）读取和写某个人的信息。

内容提供商也用于读取和写入数据是私有的，以您的应用程序，而不是共享有用。例如，笔记本示例应用程序使用一个内容提供商，以节省笔记。

内容提供商实现为一个子类的ContentProvider 和必须实现一组标准的API，使其他应用程序来执行交易。欲了解更多信息，请参阅内容提供商开发指南。

广播接收机

一个 广播接收机是响应全系统广播通知的成分。许多广播从系统中，例如发起，广播宣布，该显示屏已经关闭，电池电量低，或图片被抓获。应用程序也可以发起广播-例如，为了让其他应用程序知道一些数据已经下载到设备上，并为他们提供使用。虽然广播接收机不显示用户界面，它们可以 创建一个状态栏通知 当广播事件发生时，以提醒用户。更常见的是，虽然，一种广播接收机仅仅是一个“网关”到其他组件，并打算做工作的一个非常小的量。例如，它可能会启动一个服务来执行基于事件的一些工作。

广播接收器实现为的子类广播接收器 ，每个广播是作为一个意图对象。欲了解更多信息，请参阅广播接收器类。

Android系统设计的一个独特的方面是，任何应用程序可以启动另一个应用程序的组件。例如，如果你希望用户捕捉设备相机中的照片，还有可能是另外一个应用程序，这是否和你的应用程序可以使用它，而不是开发活动给自己拍摄照片。不需要掺入或者甚至从相机应用链接到代码。相反，你可以简单地开始捕捉照片的相机应用的活动。完成后，照片甚至还给你的应用程序，所以你可以使用它。对于用户来说，它好像相机其实就是你的应用程序的一部分。

当系统启动一个组件，它会启动过程的应用程序（如果它尚未运行），并实例化所需组件的类。例如，如果你的应用程序开始在捕捉照片的相机应用程序的活动，该活动在所属的相机应用，而不是在你的应用程序的进程的进程中运行。因此，与大多数其他系统的应用，Android应用没有一个单一的入口点（有没有的main（）函数，例如）。

由于该系统运行在与限制访问其他应用文件权限一个单独的进程每个应用程序，应用程序不能直接激活另一个应用程序的组件。而Android系统，但是，可以。因此，要激活的组件在其他应用程序，你必须向指定你的系统中传递信息的意图启动特定组件。然后，系统激活组件为您服务。

激活组件

四个组件类型的活动，服务和广 ​​播的三个接收器，通过一个异步消息激活称为意图。意图在运行时（你可以把它们想象成那些要求从其他组件的动作使者）单个组件相互结合，组件是否属于您的应用程序或其他。

意图与一个创建意图对象，它定义了一个消息，以激活一个特定的组件或特定类型组件的意图可以是显式的或隐式的，分别。

为活动和服务，意图定义要执行的操作（例如，“查看”或“发送”的东西），并且可以指定URI中的数据的作用于（除其他事项外，该组件被启动可能需要知道）。例如，意图可能传达的请求的活动，以显示图像或打开一个网页。在某些情况下，你就可以开始一个活动收到结果，在这种情况下，该活动也返回一个结果意向（例如，您可以发出一个意图，让用户选择一个个人联系人，并将它归还给你了-THE返回意图包括一个URI指向选中的联系人）。

用于广播接收机中，意图仅定义正在广播的通告（例如，广播，以指示该设备的电池为低仅包括一个公知的操作字符串，表示“电池低”）。

其它组分的类型，内容提供者，不意图激活。相反，当通过从一个请求目标被激活ContentResolver的。内容解析器处理与内容提供商的所有直接交易，这样一个与供应商执行交易组件并不需要，而是调用上的方法ContentResolver的对象。这使得内容提供者和组分请求信息（安全性）之间的抽象层。

有激活每种类型的组件的单独的方法：

• 你可以开始一个活动（或给它一些新的东西做的），通过传递意图给startActivity（）或startActivityForResult（） （当你想活动返回的结果）。
• 您可以启动服务（或者给一个持续的服务新的指令），通过传递意图给startService（） 。或者，你可以通过一个绑定到服务意向到 bindService（） 。
• 你可以通过传递一个启动广播意向到方法，如 sendBroadcast（） ，sendOrderedBroadcast（） ，或sendStickyBroadcast（） 。
• 你可以通过调用执行查询到内容提供商查询（）上ContentResolver的。

有关使用意图的更多信息，请参阅意图和意图过滤器的文件。：在下面的文档还提供了有关激活特定组件的详细信息活动，服务，广播接收器和内容提供商。

清单文件

之前Android系统可以启动一个应用程序组件，系统必须知道该组件通过阅读应用程序的存在的AndroidManifest.xml文件（以下简称“清单”文件）。您的应用程序必须申报其在该文件中的所有组件，它们必须在应用程序项目目录的根目录。

清单做了一些除了声明应用程序的组件，如事情：

• 确定所有用户权限的应用程序需要，如互联网接入或以只读方式访问用户的联系人。
• 声明最低API级别 的应用程序需要，在此基础上的API应用程序使用。
• 声明由应用程序使用或所需的硬件和软件功能，如摄像头，蓝牙服务，或者多点触摸屏。
• API库的应用程序需要对（除Android的框架API），如链接谷歌地图图书馆。
• 和更多

声明组件

清单的首要任务是要通知系统应用程序的组件。例如，如下清单文件可以宣布任何活动：

<？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>

在<应用程序> 元素中，安卓图标属性指向资源标识的应用程序的图标。

在<活动>元素中，机器人：名称属性指定的完全限定类名的活动子和机器人：标签属性指定的字符串作为该活动的用户可见的标签使用。

你必须这样声明所有的应用程序组件：

• <活动>的活动元素
• <服务>对服务的元素
• <接收器>广播接收器元素
• <提供商>为内容提供商元素

你在你的源代码，包括但并不在清单申报活动，服务和内容提供商都没有对系统可见的，因此，不能运行。然而，广播接收机既可以在清单中声明或在代码中动态创建（如 广播接收器通过调用对象），并在系统中注册registerReceiver（） 。

欲了解更多有关如何构建清单文件为您的应用程序，请参见AndroidManifest.xml文件 文档。

声明组件功能

如上所述，在激活的组件，你可以使用一个 意图开始活动，服务和广 ​​播接收器。您可以通过显式指定在意向目标组件（使用组件类名）这样做。但是，意图的真正力量在于这个概念隐含的意图。隐式意图只是简单地描述要执行的操作（以及任选在其要执行的操作中的数据），并允许该系统来查找可以执行的操作，并启动它的设备上的组件的类型。如果有可以执行由意图描述的动作的多个组件，然后，用户选择要使用哪一个。

系统识别出能够为一个意图作出反应的成分的方法是通过比较收到的意图意图过滤器在设备上的其他应用程序的清单文件中提供。

当你声明你的应用清单的活动，您可以选择包括申报活动的能力，因此它可以从其他应用程序响应意图意图过滤器。您可以通过添加一个声明为组件的意图过滤器<意图过滤器>元素作为组件的声明元素的子元素。

举例来说，如果你已经建立了一个电子邮件应用程序与撰写新的电子邮件活动，您可以声明意图过滤器响应“发送”的意图（以发送新邮件）是这样的：

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

然后，如果另一个应用程序创建一个与意图ACTION_SEND行动，并把它传递给startActivity（） ，该系统可以开始你的活动，以便用户可以起草和发送电子邮件。

欲了解更多有关创建意图过滤器，请参阅意图和意图过滤器的文件。

声明应用需求

有各种搭载Android的设备，而不是所有的人都提供相同的特性和功能。为了防止您的应用程序被安装在没有通过您的应用程序需要的功能的设备，这一点很重要，你清楚你的清单文件中声明设备和软件要求定义的类型的设备您的应用程序支持文件。大多数这些声明是仅供参考，系统不会读取他们，但外部服务，如谷歌播放做阅读它们，以便为用户提供过滤当他们搜索从他们的设备的应用程序。

例如，如果你的应用需要一个摄像头，并使用了Android 2.1（API的推出API级别 7），你应该声明这些在你这样的清单文件的要求：

<manifest ... > 
    <uses-feature  android:name = "android.hardware.camera.any" 
                  android:required = "true"  /> 
    <uses-sdk  android:minSdkVersion = "7"  android:targetSdkVersion = "19"  /> 
    ... 
</manifest>

现在，那些设备不有一个摄像头，并拥有Android版 ​​本低超过2.1无法安装谷歌从您的应用程式。

但是，您也可以声明你的应用程序使用的摄像头，但并不 需要它。在这种情况下，您的应用程序必须设置必需的属性为“假”，并在运行时检查设备是否有一个摄像头，并禁用任何拍照功能为宜。

在中提供了有关如何管理不同的设备上应用程序的兼容性的更多信息设备兼容性 文档。

应用资源

一个Android应用程序组成的不仅仅是更多的代码，它需要是独立的从源代码资源，如与应用程序的视觉呈现图片，音频文件，和任何东西。例如，您应该定义动画，菜单，样式，颜色，以及活动的用户界面与XML文件的布局。使用应用程序的资源可以很容易地更新应用的各种特性，而无需修改代码和提供成套替代资源，可以优化您的应用程序，适用于各种设备配置（如不同的语言和屏幕尺寸）。

对于您在Android项目包括每个资源的SDK构建工具定义一个唯一的整 ​​数ID，您可以使用从您的应用程序代码或在XML中定义的其他资源引用的资源。例如，如果您的应用包含一个名为图像文件logo.png（保存在RES /绘制/目录），SDK工具生成名为资源ID R.drawable.logo，您可以使用引用图像并将其插入在用户界面中。

其中一个从源代码提供独立资源的最重要的方面是您为不同的设备配置提供备用资源的能力。例如，通过在XML定义UI字符串，可以翻译字符串成其他语言，并保存在单独的文件的字符串。然后，根据语言限定词 ，你追加到资源目录的名称（如RES /值-FR /法语字符串值）和用户的语言设置，Android系统应用相应的语言字符串到你的UI。

Android支持很多不同的预选赛为您替代资源。限定符是您在资源目录的名称包括，以确定应该用于何种这些资源的设备配置的短字符串。再举一个例子，你应该经常为你的活动创建不同的布局，具体取决于设备的屏幕方向和大小。例如，当设备屏幕处于纵向（高），您可能希望有按钮的布局是垂直的，但是当屏幕处于横向（宽），按钮应水平排列。要改变取决于方向的布局，可以定义两个不同的布局和应用适当的限定符每个版面的目录名。然后，系统自动应用根据当前的设备方向的适当布局。

欲了解更多有关不同类型的资源，您可以在您的应用程序以及如何为不同的设备配置替代资源，阅读提供了资源。