Android文档-开发者指南-第一部分:入门-中英文对照版-pdf

一、Introduction(入门)

0、Introduction to Android(引进到Android)

Android provides a rich application framework that

allows you to build innovative apps and games for

mobile devices in a Java language environment.

The documents listed in the left navigation provide

details about how to build apps using Android's

various APIs.

Android提供了丰富的应用程序框架，它允许您在Java语言环境中构建移动设备的创新应用程序和游戏。在左侧导航中列出的文档提供了有关如何使用Android的各种API来构建应用程序的详细信息。

To learn how apps work, start

withApp Fundamentals.

To begin coding right away,

readBuilding Your First App

要了解如何开发应用，从 应用基础

开始。

如何开始一个正确的编码，请参照

建立你的第一个应用程序。

Apps provide multiple entry points Apps adapt to different devices

应用程序提供多个入口点

Android apps are built as a combination of

distinct components that can be invoked

individually. For instance, an

individual activity provides a single screen for

a user interface, and a service independently

performs work in the background.

Android应用程序被构建为能够单独地被调用不同的部件的组合。例如，一个单独的Activity提供了一个单个屏幕上的用户界面，和一个Service独立地在后台中执行工作。

应用程序适应不同的设备

Android provides an adaptive app

framework that allows you to provide

unique resources for different device

configurations. For example, you can

create different XML layout files for

different screen sizes and the system

determines which layout to apply based

on the current device's screen size.

Android提供了一个自适应的应用程序框架，它允许您为不同的设备配置提供不同的资源。例如，您可以为不同的屏幕尺寸创建不同的XML布局文件并且系统决定了基于当前屏幕尺寸使用哪些布局。

You can query the availability of device

features at runtime if any app features

require specific hardware such as a

camera. If necessary, you can also

declare features your app requires so

app markets such as Google Play Store

do not allow installation on devices that

do not support that feature.

From one component you can start another

component using an intent. You can even

start a component in a different app, such an

activity in a maps app to show an address.

This model provides multiple entry points for

a single app and allows any app to behave as

a user's "default" for an action that other apps

may invoke.

从一个组件就可以使用一个Intent启动另一个组件。你甚至可以启动不同应用程序中的一个组件，比如启动一个地图应用中的Activity来显示地址。该模型为一个单一的应用程序提供了多个入口点，并允许任何应用程序的行为作为用户的“默认”，用于其他应用程序调用的Action

Learn more:







你可以在运行时查询设备功能的可用性，如果任何应用程序的功能需要特定的硬件如照相机。如果需要，你也可以定义你的应用程序需要的特性，，如Google Play商店不允许不支持该特性的设备安装。

Learn more:

Device Compatibility

Resources Overview

User Interface Overview

了解更多：

App Fundamentals

Intents and Intent Filters

Activities

了解更多：













应用基础

意图和意图过滤器

Activities







设备兼容性

资源概述

用户界面概述

1、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.

Android应用程序是用Java写的。Android SDK工具编译你的代码以及任何数据和资源文件为APK：一个Android包，这是一个以.apk为后缀的存档文件。一个APK文件包含了一个Android应用程序的所有内容，是Android平台的设备应用程序的安装文件。

Once installed on a device, each Android app lives

in its own security sandbox:

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

IN THIS DOCUMENT

App Components

Activating components

The Manifest File

Declaring components

Declaring component

capabilities

Declaring app requirements

App Resources

在本文档中

应用程序组件

激活组件

清单文件

声明组件

声明组件的能力

声明应用程序要求

应用程序资源



The Android operating system is a multi-user Linux system in which each app is a

different user.

Android是一个多用户的Linux操作系统，每一个应用都是一个不同的用户。



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.

默认情况下，系统关联每一个应用程序到不同的Linux用户Id(这个ID只被系统使用，应用程序是不知道的)。系统设置一个应用程序中的所有文件的权限，以便仅仅此应用程序的用户ID可以访问它们。



Each process has its own virtual machine (VM), so an app's code runs in isolation

from other apps.

每一个进程都有他自己的虚拟机(VM),所以应用程序的代码的运行独立于其他应用程序。



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.

默认情况下，每一个应用程序运行在他自己的Linux进程。当任何任用程序的祖先需要被执行的时候，Android启动这个程序的进程；当它不再需要时或系统必须恢复内存的其他应用程序，关闭该进程。

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.

在这种方式中，Android系统实现了最小特权原则。也就是说，每个应用程序，默认情况下，只能访问到它的工作所需要的最少的权限。这将创建一个非常安全地环境：每一个应用程序不能访问系统没有给予它权限的任何一个部分。

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

它可以让两个应用程序共享相同的Linux用户ID，在这种情况下，他们能够访问对方的文件。为了节省系统资源，应用程序使用相同的用户ID也可以运行在同一个Linux进程中，并共享相同的VM（并且应用程序也必须使用相同的证书签名）。



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.

一个应用程序能够请求权限去访问设备上的数据，比如用户的联系人信息、短信、SDCard、照相机、蓝牙等等。所有的应用程序权限必须在用户安装软件的时候给予授权。

That covers the basics regarding how an Android app exists within the system. The rest of

this document introduces you to:

这包括关于一个Android应用程序怎样存在于系统中存在的基本知识。本文档的其余部分向您介绍：



The core framework components that define your app.

定义您应用程序的的核心框架组件



The manifest file in which you declare components and required device features for

your app.

在您的应用程序Manifest文件中声明组件和所需设备功能



Resources that are separate from the app code and allow your app to gracefully

optimize its behavior for a variety of device configurations.

资源是独立于应用程序代码的，让你的应用程序，以优雅地行为为各种设备优化配置。

1.1、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.

应用程序组件是一个Android应用程序的基本构造块。每个组件都是一个不同的角度，通过该系统，可以进入你的应用程序。不是所有的组件都是为用户和一些互相依赖的实际的切入点，但每一个都作为一个独立的的实体，扮演着特定的角色——每一个都是一个可以帮助确定您的应用程序的整体行为独特的构建快。

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:

以下是四种类型的应用程序组件：

Activity

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.

一个Activity表示为单个屏幕的用户界面。比如，一个email应用程序可能用一个Activity显示新的email列表，用另一个Activity去写Activity，并且使用另外的Activity来阅读Email。虽然活动一起形成一个有凝聚力的用户体验的电子邮件应用程序，但是每一个都是相互独立的。同样的，不同的应用程序可以启动这些Activity中的任何一个(如果Email程序允许他这么做)。比如所，一个相机应用为了分享一张照片可以启动一个Email应用中的Activity来创建一个新的Email。

An activity is implemented as a subclass of

Activity and you can learn more about

it in the Activities developer guide.

你的应用中的Activity应该是继承了Activity的一个子类，如果想要了解更多，可以参照Activities开发指南。

Service

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.

一个Service是一个运行在后台的、执行耗时操作或者执行跨进程操作的组件。服务没有用户界面。比如所，当用户在其他应用程序的时候，一个服务可能在后台播放音乐或者它可能从网络上读取数据但并不会阻塞用户和Activity交互。另外一个组件，比如一个Activity，为了与Service交互，能够启动服务并且让它运行或者绑定到它。

A service is implemented as a subclass of

Service and you can learn more about it

in the Services developer guide.

你的应用中的Service应该是继承了Service的一个子类，如果你想了解更多，可以参照Services开发指南。

Content Provider

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

) to read and write information about a particular person.

一个content provider管理一个分享数据的集合。你能够存储数据到文件系统、SQLite数据库、在网络上或者任何其它的你能够访问的持久化存储位置。通过Content

Provider，其他应用程序能够查询或者修改数据（如果Content Provider允许它这么做）。比如说，Android系统提供了一个管理用户联系人信息的Content Provider。同样的，任何具有适当权限的应用程序能够查询Content Provider(比如) 去读取或者修改关于特定联系人的信息。

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.

Content Provider也能够在读取或者写入你的应用的没有共享的私有数据。比如Note

Pad 例子应用程序使用Content Provider来保存日记。

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 Providersdeveloper guide.

你的应用中的ContentProvider应该是ContentProvider

的一个子类，并且为了让其他应用程序能够操作事务，必须实现一个标准的API集合。如果您想要得到更多的信息，可以参照Content Providers开发者指南。

Broadcast Receiver

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.

broadcast receiver是一个响应系统范围内发布的广播的组件。很多广播是从系统发布出来的——比如，一个广播通知屏幕已经关闭，电池电量低或者相机已经捕获了一张图片。应用程序也能够发出广播——比如，让其他应用程序知道某些数据已经被下载到设备上，可供它们使用。通过broadcast receiver不能够显示一个用户界面，当广播发生的时候，可以通过创建一个状态栏通知提示用户。更常见的是，一个broadcast

receiver仅仅是一个为了做一个非常短暂的事情的到其他组件的“网关”。 例如，它可能会启动一个服务来执行基于事件的一些工作。

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是一个继承自BroadcastReceiver的一个子类并且每一个broadcast传第一个Intent 对象。如果您想要获得更多数据，请参考BroadcastReceiver类。

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.

Android系统设计的一个特殊的层面是任何应用都能够启动其他应用的组件。例如，如果你想用户使用设备的相机去捕获一张图片，有可能您通过其他应用的去这么做，而不是自己开发一个Activity去这么做。你不需要把相机应用的代码放到你的应用中去，而是改为简单的启动相机应用的Activity去获得一张图片。当捕捉完成的时候，这张图片将返回到你的应用中，所以你能够使用它。对于用户来讲，相机就好像是你的应用程序的一部分。

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

当系统启动一个组建的时候，它开始一个这个应用的进程(如果他没有正在运行)，并且实例化这个组件所需要的类。例如说，如果你的应用启动一个Camera应用的Activity去不活一张图片，该Activity属于相机应用的进程中，而不是在你的用用的进程中。因此，不像其他大多数系统的应用程序，Android应用程序没有一个单独的入口点(例如，没有main()函数)

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.

由于每个应用程序运行在独立于其它应用程序文件权限的系统中，你的呢应用程序不能直接从另一个程序激活一个组件。但是Android系统可以，所以，要激活另一个应用程序的组件，则必须将消息传递到你的Intent所指定的特定组件中，然后系统为你激活那个组件。

1.1.1、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.

四个组建类型中的三个——Activity、Service、BroadcastReceiver——通过调用一个Intent的异步消息来激活。Intents在运行是绑定多个组件(你可以把它们看作是请求来自其他组件的动作信使)，无论这个组件是否属于你的应用。

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.

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

对于Activity和Service，意图定义了要执行的action（例如，“查看”或“发送”的东西），并且可以指定执行操作的数据的URI（其中包括了正在启动的组件可能需要知道的）。例如，一个意图可能传达给一个Activity显示一个图片或者打开一个网页的请求。在某些情况下，你就可以启动一个Activity来获得的结果，在这种情况下，该Activity也返回结果中的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").

对于广播接收机，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).

其他的组件类型，Content Provider不是通过Intent激活的。相反，它是通过一个ContentResolver发起的请求来激活的。Content Resolver处理与content Provider的所有直接的事务，并不需要Content Provider来执行事务，而是调用ContentResolver对象的方法。这是一个在Content Provider和请求信息的组件之间的一个抽象(为了安全性)。

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

你能够启动一个Activity(或者给它一些新的东西让它去执行)，通过startActivity() 或者

startActivityForResult()(如果你想要Activity返回一个结果的话)



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

您可以启动一个服务（或给予新的指令来持续服务）通过传递一个Intent 到startService()。或者你也可以通过传递一个绑定到服务Intent，以

bindService()



You can initiate a broadcast by passing an

Intent to methods

like

sendBroadcast(),

sendOrderedBroadcast(), or

sendStickyBroadcast().

你能够发布一个broadcast通过一个 发送一个Intent 到sendBroadcast()，sendOrderedBroadcast()或者

sendStickyBroadcast()



You can perform a query to a content provider by calling

query() on

a

ContentResolver.

你能够通过调用ContentResolver对象的query()方法来执行一个查询

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,

如果您想获得关于使用Intent的更多的信息，请参考Intents and Intent Filters 文档。还提供了下列文件有关激活特定组件的详细信息：

Activities， Services，BroadcastReceiver和Content Providers.

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

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.

定义应用程序必须的最小API Level ，应用程序使用API在这个基础之上。



Declare hardware and software features used or required by the app, such as a

camera, bluetooth services, or a multitouch screen.

定义应用程序使用或者必须的硬件和软件特性，比如Camera、蓝牙服务或者多点触摸屏幕。



API libraries the app needs to be linked against (other than the Android framework

APIs), such as the Google Maps library.

应用程序必须的API库（Android Framework以外的API），比如Google Maps

library.



And more

更多

1.2.1、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:

清单文件的主要任务是告知系统有关应用程序的组件。比如，清单文件像下面一样声明一个Activity：

android:name="eActivity"

android:label="@string/example_label" ... >

...

In the

element, the

android:icon attribute points to resources for an

icon that identifies the app.

在元素中，android:icon

属性定位的资源用于作为应用程序的图标。

In the

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.

在 元素中，android:name 属性指定了Activity

子类全限定名，android:label 属性指定了一个用户可见的用于整个Activity的字符串。

You must declare all app components this way:

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

 elements for activities

元素声明activity

 elements for services

元素声明Service

 elements for broadcast receivers

元素声明Broadcast Receiver

 elements for content providers

声明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().

Activity、Service和Content Provider仅仅包含在你的代码中，但是却没有在Manifest中声明，这对系统来讲是不可见的，因此，它们不能运行。然而，Broadcast

Receiver既可以在manifest也可以在代码中动态创建的声明（如

BroadcastReceiver对象），并通过调用

registerReceiver()方法注册到系统。

For more about how to structure the manifest file for your app, see The

Filedocumentation.

欲了解更多有关如何为您的应用程序构建manifest文件，请参阅 文档。

1.2.2、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.

如上面Activating Components(激活组件)所讨论的，你能够使用Intent

启动Activity、Service和Broadcast Receiver。你可以通过使用显式命名的目标组件(使用组件类名)的intent这么做.然而真正强大的意图是隐式意图的概念。一个隐含的意图只是简单地描述动作的执行（也可选择，当你想要执行的操作时的数据）的类型和允许系统找到可以执行的操作，并启动在设备上的组件。如果有多个组件能够执行指定的Action，将让用户选择使用哪一个应用程序执行。

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

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

当你在你的应用程序清单文件中声明一个Activity时候，你能够选择性的包含Intent Filter的能力，让它能够响应从其他应用发送过来的Intent。你能够通过为你组件增加一个子元素，定义一个Intent filter。

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:

例如，如果你构建一个Email应用程序的一个Activity用来创建新的email，你能够定义一个Intent filter去响应”send”intent(为了发送一个email)，像下面这样：

...

android:name="eEmailActivity">

/>

android:name="T" />

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.

然后，如果其他的应用程序创建了一个action为ACTION_SEND 的intent并且通过startActivity()来启动，系统能够启动你的Activity，以便用户可以起草和发送电子邮件。

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

更多关于创建intent filter的内容，请参考Intents and Intent Filters文档。

1.2.3、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.

有多种设备搭载Android，不是所有Android设备都提供相同的功能和能力。为了防止你的应用程序被安装在缺乏必要功能的设备上，这一点很重要，你应该在你的manifest文件中清楚地定义配置设备类型以满足你的应用程序必须的设备和软件要求，。大多数这些声明是仅供参考，系统不会读取它们，但外部服务，如Google Paly务必阅读它们，以提供用户在搜索满足他们设备的应用程序。

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:

例如，如果你的应用程序需要一个摄像头，并使用了Android 2.1（API级别 7），你应该声明以下的内容，在你的manifest文件中：

android:required="true" />

/>

...

Now, devices that do not have a camera and have an Android version lower than 2.1

cannot install your app from Google Play.

现在，如果你的设备没有摄像头或者你的Android系统低于2.1，那么你将不能通过Google Paly安装你的应用。

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.

然而，您也可以定义您的应用使用Camera，但是不是必须使用它。在这种情况下，你的应用必须设置required 属性为”false”,并且运行时检查设备是否有一个摄像头，并禁用任何相机功能（如适用）

More information about how you can manage your app's compatibility with different

devices is provided in the Device Compatibility document.

更多的关于怎样管理不同设备中你的应用程序能力，请参考Device Compatibility文档。

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

一个Android应用程序是由不仅仅是代码——它需要的资源是独立于源代码，如图像，音频文件，以及有关应用程序的视觉呈现任何内容。例如，你应该定义动画，菜单，样式，颜色，以及Activity用户界面的布局的XML文件。使用应用程序资源，可以很容易地更新你的应用程序的各种特性，而无需修改代码——通过提供两套替代资源——使您能够优化你的应用程序，适用于各种设备配置（如不同的语言和屏幕大小）。

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

(saved in the

res/drawable/ directory), the SDK tools generate a

resource ID named

, which you can use to reference the image and

insert it in your user interface.

对于您在您的Android项目包括所有的资源，在SDK编译工具定义一个唯一的整 数ID，你可以用它来 从您的应用程序的代码或从XML中定义的其他资源引用资源。例如，如果您的应用程序包含一个名为映像文件（保存在res/drawable/目录下），SDK工具生成一个名为资源ID

，您可以用它来 引用该 图片并将其插入在用户界面中。

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.

其中提供资源从源代码中分离出来的最重要的方面是能够让你为不同的设备配置提供替代资源。例如，通过定义在XML中的UI字符串，可以转换字符串成其他语言，并保存这些字符串在单独的文件。然后，基于语言限定词 ，你附加到资源目录的名称（如res/values-fr/法语字符串值）和用户的语言设置，Android系统应用相应的语言字符串到你的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.

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

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.

欲了解更多有关可以包括在您的应用程序的不同类型的资源，以及如何创建对于不同设备配置替代资源，阅读Providing Resources.

CONTINUE READING ABOUT: YOU MIGHT ALSO BE INTERESTED IN:

继续阅读有关：

Intents and Intent Filters

Information about how to use

the

Intent APIs to activate app

components, such as activities and

services, and how to make your app

components available for use by

other apps.

Activities

Information about how to create an

instance of the

Activity class,

which provides a distinct screen in

your application with a user interface.

Providing Resources

Information about how Android apps

are structured to separate app

resources from the app code,

including how you can provide

alternative resources for specific

device configurations.

意图和意图过滤器

有关如何使用这些信息意图 API来启动应用程序组件，如活动和服务，以及如何，以供其他应用程序使用您的应用程序的组件。

活动

有关如何创建该实例的信息活动类，它提供了一个独特的屏幕在你的应用程序的用户界面。

您可能也有兴趣：

Device Compatibility

Information about Android works on

different types of devices and an

introduction to how you can optimize

your app for each device or restrict

your app's availability to different

devices.

System Permissions

Information about how Android

restricts app access to certain APIs

with a permission system that

requires the user's consent for your

app to use those APIs.

设备兼容性

关于Android的信息适用于不同类型的设备，并介绍了如何优化你的应用程序为每个设备或限制您的应用程序的可用性，以不同的设备。

系统权限

关于Android如何限制应用程序访问某些API与许可制度，要求用户同意你的应用程序使用这些API的信息

提供资源

有关如何Android应用程序的结构，以资源的应用程序从应用程序代码中分离出来，包括如何可以为特定的设备配置提供替代资源的信息。

2、Device Compatibility(设备兼容性)

Android is designed to run on many different

types of devices, from phones to tablets and

IN THIS DOCUMENT

televisions. As a developer, the range of devices

provides a huge potential audience for your app.

What Does "Compatibility" Mean?

In order for your app to be successful on all these

Controlling Your App's Availability

devices, it should tolerate some feature variability

to Devices

and provide a flexible user interface that adapts

Device features

to different screen configurations.

Platform version

Android被设计运行于多种不同类型的设备之上，包括手机、平板电脑和电视等。作为一个开发者，这个设备返回为您的应用提供了巨大的潜在受众。为了让你的应用能够成功的在所有设备上运行，它就应该能容忍一些功能的变化并且提供适应不同屏幕配置的灵活的用户界面。

To facilitate your effort toward that goal, Android

provides a dynamic app framework in which you

can provide configuration-specific app

resources in static files (such as different XML

layouts for different screen sizes). Android then

loads the appropriate resources based on the

current device configuration. So with some

forethought to your app design and some

additional app resources, you can publish a

single application package (APK) that provides

an optimized user experience on a variety of

devices.

为了方便您的朝着这个目标努力，Android提供了一个动态的应用程序框架——你可以通过提供配置特定应用程序资源的静态文件（如不同的XML布局不同的屏幕尺寸）。然后Android加载基于当前的设备配置适当的资源。因此，考虑到您的应用程序的设计和一些额外的应用程序的资源，你可以发布一个应用程序包（APK），提供对各种设备的优化用户体验。

Screen configuration

Controlling Your App's

Availability for Business

Reasons

SEE ALSO

Filtering on Google Play

Providing Resources

Android Compatibility

在本文档中

什么是“兼容性”？

控制你的应用程序对设备的可用性

设备特性

平台版本

屏幕配置

控制你的应用程序出于商业原因的可用性

另请参阅

Google Play上的过滤在

If necessary, however, you can specify your

提供资源

app's feature requirements and control which

types of devices can install your app from Google

Android的兼容性

Play Store. This page explains how you can

control which devices have access to your apps,

and how to prepare your apps to make sure they

reach the right audience. For more information

about how you can make your app adapt to

different devices, read Supporting Different

Devices.

如果有必要，你可以指定你的应用程序的功能需求和控制哪些类型的设备可以从Google Play商店安装你的应用程序。本页说明如何控制哪些设备可以访问您的应用程序，以及如何准备你的应用程序，以确保他们到达正确的受众。有关如何使你的应用程序适应不同设备的更多信息，请阅读支持不同的设备。

2.1、What Does "Compatibility" Mean?( 什么是“兼容性”?)

As you read more about Android development, you'll probably encounter the term

"compatibility" in various situations. There are two types of compatibility: device

compatibility and app compatibility.

当你读到很多关于Android开发的内容时，你可能会遇到的各种情况的“兼容性”一词。有两种类型的兼容性：设备兼容性 和应用程序的兼容性。

Because Android is an open source project, any hardware manufacturer can build a

device that runs the Android operating system. Yet, a device is "Android

compatible" only if it can correctly run apps written for the Android execution

environment. The exact details of the Android execution environment are defined by

the Android compatibility program and each device must pass the Compatibility Test

Suite (CTS) in order to be considered compatible.

因为Android是一个开源工程，任何硬件设备制造商都能够构建一个运行Android操作系统的设备。然而，只有当它能够正确运行Android的运行环境编写的应用程序，设备才是“兼容Android的” 。在Android执行环境的具体细节由定义Android的兼容性计划，每个设备必须通过兼容性测试套件（CTS）才能被认为是兼容的。

As an app developer, you don't need to worry about whether a device is Android

compatible, because only devices that are Android compatible include Google Play

Store. So you can rest assured that users who install your app from Google Play Store

are using an Android compatible device.

作为一个应用程序开发人员，您不必担心设备是否兼容的Android，因为只有那些兼容Android的设备，才被包含在Google Play商店。所以，你可以放心，只有使用Android兼容设备的用户才能从Google Paly商店安装您的应用程序。

However, you do need to consider whether your app is compatible with each potential

device configuration. Because Android runs on a wide range of device configurations,

some features are not available on all devices. For example, some devices may not

include a compass sensor. If your app's core functionality requires the use of a compass

sensor, then your app is compatible only with devices that include a compass sensor.

但是，你需要考虑的是您的应用程序与每个潜在的设备配置是否兼容。因为Android运行在多种设备上，某些功能可能不适用于所有设备。例如，某些设备可能不包括罗盘传感器。如果你的应用程序的核心功能需要使用指南针传感器，那么你的应用程序是只与包括指南针传感器的设备兼容。

2.2、Controlling Your App's Availability to Devices(控制您的应用对设备的可用性)

Android supports a variety of features your app can leverage through platform APIs.

Some features are hardware-based (such as a compass sensor), some are software-based (such as app widgets), and some are dependent on the platform version. Not

every device supports every feature, so you may need to control your app's availability to

devices based on your app's required features.

你的应用可以通过平台使用Android支持多种特性的APIs。有些特性是基于硬件（如指南针传感器），有些是基于软件的（如应用程序窗口小部件），以及一些依赖于平台的版本。不是每个设备支持的所有特性，所以你可能需要控制你的应用程序的可用性，根据你的应用程序的所需的特性设备。

To achieve the largest user-base possible for your app, you should strive to support as

many device configurations as possible using a single APK. In most situations, you can

do so by disabling optional features at runtime and providing app resources with

alternatives for different configurations (such as different layouts for different screen

sizes). If necessary, however, you can restrict your app's availability to devices through

Google Play Store based on the following device characteristics:







Device features

Platform version

Screen configuration

为了让你的应用程序得到最大的用户群，你应该努力使单个APK，支持尽可能多的设备配置。在大多数情况下，您可以在运行时禁用可选功能，以及为不同的配置方案提供应用程序资源 （如为不同的屏幕大小提供不同的布局）。如果有必要，您可以通过Google Play商店基于以下设备特性限制您的应用程序对设备的可用性：







设备特性

平台版本

屏幕配置

2.2.1、Device features(设备特性)

In order for you to manage your app’s availability based on device features, Android

defines feature IDs for any hardware or software feature that may not be available on all

devices. For instance, the feature ID for the compass sensor

is

FEATURE_SENSOR_COMPASS and the feature ID for app widgets

is

FEATURE_APP_WIDGETS.

为了让您能够管理基于设备特性的应用程序的可用性，Android为可能无法使用的所有设备的任何硬件或软件特性的定义了特性ID。例如，对于指南针传感器的特性ID是FEATURE_SENSOR_COMPASS、应用程序小部件的特性ID是FEATURE_APP_WIDGETS。

If necessary, you can prevent users from installing your app when their devices don't

provide a given feature by declaring it with a

element in your

app's manifest file.

如果有必要，你可以在你的应用程序的元素清单文件中声明一个给定的功能的，以阻止设备不满足条件的时候，用户安装你的应用。

For example, if your app does not make sense on a device that lacks a compass sensor,

you can declare the compass sensor as required with the following manifest tag:

举例来讲，如果你的应用程序需要安装到装有指南针传感器的设备上，你可以在manifest标签下添加如下的标签来限定：

android:required="true" />

...

Google Play Store compares the features your app requires to the features available on

each user's device to determine whether your app is compatible with each device. If the

device does not provide all the features your app requires, the user cannot install your

app.

Google Paly商店会比较你的应用程序所必须的以及用户的设备上可用的特性，以确定您的应用是否和用户的设备兼容。如果设备不能提供你的应用所需要的所有特性的话，用户就不能安装你的应用。

However, if your app's primary functionality does not require a device feature, you should

set the

required attribute to

"false" and check for the device feature at runtime. If the

app feature is not available on the current device, gracefully degrade the corresponding

app feature. For example, you can query whether a feature is available by

calling

hasSystemFeature() like this:

然而，如果你的应用程序的主要功能并不是必须一个设备特性，你应该设置required为”false”，然后在运行时所需要的检查设备特性。如果这个设备特性在当前设备上不可用，你应该优雅地去掉相应的应用程序的功能。比如所，你能够通过调用hasSystemFeature()方法来判断特性是否可用，像下面这样：

PackageManager pm = getPackageManager();

if (!temFeature(E_SENSOR_COMPASS)) {

// This device does not have a compass, turn off the compass

feature

disableCompassFeature();

}

For information about all the filters you can use to control the availability of your app to

users through Google Play Store, see the Filters on Google Play document.

有关所有你能够通过Google Play商店控制您的应用的可用性的过滤器的信息，可以参考 Google Play上的过滤器 文件。

Note: Some system permissions implicitly require the availability of a device feature. For

example, if your app requests permission to access to

BLUETOOTH, this implicitly requires

the

FEATURE_BLUETOOTH device feature. You can disable filtering based on this feature

and make your app available to devices without Bluetooth by setting

the

required attribute to

"false" in the

tag. For more information

about implicitly required device features, read Permissions that Imply Feature

Requirements.

注意：一些 system permissions 隐含的需要一些设备特性必须可用。比如说：如果你的应用请求一个访问BLUETOOTH的权限，这隐含的必须具有

FEATURE_BLUETOOTH设备特性。你能够通过设置标签的required属性为”false”来禁止没有蓝牙设备的机器过滤掉您的应用。

2.2.2、Platform version(平台版本)

Different devices may run different versions of the Android platform, such as Android 4.0

or Android 4.4. Each successive platform version often adds new APIs not available in

the previous version. To indicate which set of APIs are available, each platform version

specifies an API level. For instance, Android 1.0 is API level 1 and Android 4.4 is API

level 19.

不同的设备可以运行不同版本的Android平台，如Android 4.0或Android 4.4。每个后续的平台版本往往增加在以前的版本无法使用的新API。每个平台版本指定一个API级别来指出哪些是可用的APIs。举例来说，Android1.0的API级别是1和Android 4.4的API级别是19。

The API level allows you to declare the minimum version with which your app is

compatible, using the

manifest tag and its

minSdkVersion attribute.

API级别允许你定义你的应用在哪一个最小的版本上时可用的，使用mianfest中的标签的minSdkVersion 属性来指定。

For example, the Calendar Provider APIs were added in Android 4.0 (API level 14). If

your app cannot function without these APIs, you should declare API level 14 as your

app's minimum supported version like this:

比如说， Calendar Provider APIS是在Android4.0(API级别是14)上增加的。如果你的应用程序不能没有这些函数，那么你能够像下面这样定义你的应用最低支持API级别为14：

android:targetSdkVersion="19" />

...

The

minSdkVersion attribute declares the minimum version with which your app is

compatible and the

targetSdkVersion attribute declares the highest version on which

you've optimized your app.

minSdkVersion 属性定义了你的应用可以使用的最小版本，而targetSdkVersion 属性声明你优化你的应用程序的最高版本。

Each successive version of Android provides compatibility for apps that were built using

the APIs from previous platform versions, so your app should always be compatible with

future versions of Android while using the documented Android APIs.

Android的每个后续版本向以前版本的API平台构建的应用程序提供了兼容性，所以应该使你的应用程序使用的 Android API应该总是兼容Android的未来版本。

Note: The

targetSdkVersion attribute does not prevent your app from being installed

on platform versions that are higher than the specified value, but it is important because it

indicates to the system whether your app should inherit behavior changes in newer

versions. If you don't update the

targetSdkVersion to the latest version, the system

assumes that your app requires some backward-compatibility behaviors when running on

the latest version. For example, among the behavior changes in Android 4.4, alarms

created with the

AlarmManager APIs are now inexact by default so the system can batch

app alarms and preserve system power, but the system will retain the previous API

behavior for your app if your target API level is lower than "19".

注意：

targetSdkVersion属性不会阻止你的应用程序被安装在平台上比规定值高的版本上，但它是非常重要的，因为它表明该系统的应用程序是否应该继承在新版本中的行为变化。如果你不更新

targetSdkVersion到最新版本，当在最新版本上运行时，系统假设你的应用程序需要一些向后兼容的行为。例如，在Android 4.4中行为的变化后，现在在默认情况，创建alarms的AlarmManager API是不精确的，系统能批量应用alarms来保护系统电源，但系统会对你的应用程序保留以前的API的行为，如果你的目标的API级别比“19”低。

However, if your app uses APIs added in a more recent platform version, but does not

require them for its primary functionality, you should check the API level at runtime and

gracefully degrade the corresponding features when the API level is too low. In this case,

set the

minSdkVersion to the lowest value possible for your app's primary functionality,

then compare the current system's version,

SDK_INT, to one the codename constants

in

N_CODES that corresponds to the API level you want to check. For

example:

但是，如果你的应用程序使用的一个较新的平台版本新增的API，但不要求他们为其主要功能，你应该在运行时检查API级别，如果API级别太低，应该适当的减少相应的功能。在这种情况下，设置minSdkVersion为可能的最低值，你的应用程序硬件检查当前本和相应的API级别的值：SDK_INT是你的SDK级别，N_CODES是你要要检查对应的API级别的一个常量。例如：

if (_INT < N_OMB) {

// Running on something older than API level 11, so disable

// the drag/drop features that use ClipboardManager APIs

disableDragAndDrop();

}

2.2.3、Screen configuration(屏幕配置)

Android runs on devices of various sizes, from phones to tablets and TVs. In order to

categorize devices by their screen type, Android defines two characteristics for each

device: screen size (the physical size of the screen) and screen density (the physical

density of the pixels on the screen, known as DPI). To simplify the different

configurations, Android generalizes these variants into groups that make them easier to

target:

Android运行在不同屏幕大小的设备上，从手机到平板电脑和电视。为了通过他们的屏幕类型分类设备，Android为每个设备定义了两种特性：屏幕尺寸（屏幕的物理尺寸）和屏

幕像素密度（该像素在屏幕上的物理密度，称为DPI）。为了简化不同的配置，把他它们归纳成以下几种分类：



Four generalized sizes: small, normal, large, and xlarge.

四种广义的尺寸：small, normal, large以及xlarge.



And several generalized densities: mdpi (medium), hdpi (hdpi), xhdpi (extra high),

xxhdpi (extra-extra high), and others.

和几个广义密度：mdpi (medium), hdpi (hdpi), xhdpi (extra high), xxhdpi (extra-extra

high), 以及其它的

By default, your app is compatible with all screen sizes and densities, because the

system makes the appropriate adjustments to your UI layout and image resources as

necessary for each screen. However, you should optimize the user experience for each

screen configuration by adding specialized layouts for different screen sizes and

optimized bitmap images for common screen densities.

默认情况下，您的应用程序应该兼容所有的屏幕尺寸和密度，因为系统会进行适当的调整，以便为每个屏幕设置必需的UI布局和图像资源。然而，你可以通过增加专门的布局，不同的屏幕大小和常见的屏幕密度和优化的位图图像来优化每个屏幕配置的用户体验。

For information about how to create alternative resources for different screens and how

to restrict your app to certain screen sizes when necessary, read Supporting Different

Screens.

有关如何为不同的屏幕创建替代资源，以及如何在必要时限制你的应用程序的某些屏幕尺寸的信息，请阅读支持不同的屏幕。

2.3、Controlling Your App's Availability for Business Reasons(控制你的应用程序出于商业原因的可用性)

In addition to restricting your app's availability based on device characteristics, it’s

possible you may need to restrict your app’s availability for business or legal reasons. For

instance, an app that displays train schedules for the London Underground is unlikely to

be useful to users outside the United Kingdom. For this type of situation, Google Play

Store provides filtering options in the developer console that allow you to control your

app’s availability for non-technical reasons such as the user's locale or wireless carrier.

除了根据设备特性限制你的应用程序的可用性，你可能需要根据商业原因或法律原因限制你的应用程序的可用性。例如，英国以外的用户不太可能用到一个用于伦敦地铁显示列车时刻表的应用程序。对于这种情况，Google Play商店提供了在开发者控制台，让您控制对于非技术原因您的应用程序的可用性，例如用户的语言环境或无线运营商过滤选项。

Filtering for technical compatibility (such as required hardware components) is always

based on information contained within your APK file. But filtering for non-technical

reasons (such as geographic locale) is always handled in the Google Play developer

console.

过滤技术的兼容性（如需要的硬件组件）总是基于包含在您的APK文件信息。但过滤非技术原因（如地理区域）总是在Google Play开发者控制台处理。

CONTINUE READING ABOUT: YOU MIGHT ALSO BE INTERESTED IN:

Providing Resources System Permissions

Information about how Android apps How Android restricts app access to

are structured to separate app certain APIs with a permission system

resources from the app code, including that requires the user's consent for

how you can provide alternative your app to use those APIs.

resources for specific device

系统权限

configurations.

如何让用户同意许可权限，根据权限系Filters on Google Play

统限制Android访问某些APIs。

Information about the different ways

that Google Play Store can prevent

your app from being installed on

different devices.

继续阅读相关内容：

提供资源

有关如何在Android应用程序的结构中，如何把资源从应用程序代码中分离出来，包括如何可以为特定的设备配置提供替代资源的信息。

Google Play上的过滤

有关不同的方式，Google Play存储的信息可以防止你的应用程序被安装在不同的设备。

3、System Permissions(系统权限)

Android is a privilege-separated operating

system, in which each application runs

with a distinct system identity (Linux user

ID and group ID). Parts of the system are

IN THIS DOCUMENT

Security Architecture

also separated into distinct identities.

Linux thereby isolates applications from

each other and from the system.

Android是一个权限分隔的操作系统，其中每个应用程序运行在具有鲜明的标识系统（Linux的用户ID和组ID）。在系统的部分也分成不同的标识。Linux的应用程序以及系统应用程序彼此隔离。

Additional finer-grained security features

are provided through a "permission"

mechanism that enforces restrictions on

the specific operations that a particular

process can perform, and per-URI

permissions for granting ad hoc access to

specific pieces of data.

通过”permission“机制提供一个额外的细粒度安全特性，针对一个特定的进程可以强制执行具体的操作限制，并且每个URI提供访问临时访问特定的数据块的权限。

This document describes how application

developers can use the security features

provided by Android. A more

general Android Security Overview is

provided in the Android Open Source

Project.

本文档介绍了应用程序开发人员如何使用Android提供的安全功能。Android安全性概述Android开源项目提供一个更通用的使用说明。

Application Signing

User IDs and File Access

Using Permissions

Declaring and Enforcing Permissions

...in

...when Sending Broadcasts

Other Permission Enforcement

URI Permissions

在本文档中

安全架构

应用程序签名

用户ID和文件访问

使用权限

声明和强制执行权限

在... 中

...发送广播时

其他权限执行

URI权限

3.1、Security Architecture(安全架构)

A central design point of the Android security architecture is that no application, by

default, has permission to perform any operations that would adversely impact other

applications, the operating system, or the user. This includes reading or writing the user's

private data (such as contacts or emails), reading or writing another application's files,

performing network access, keeping the device awake, and so on.

Android的安全架构的一个核心设计就是：没有应用程序能够获得在默认情况下执行任何操作，将其他应用程序，对操作系统或用户产生不利影响的许可。这包括读取或写入用户

的私人数据（如联系人或电子邮件），读取或写入另一个应用程序的文件，执行网络访问，保持设备常亮，等等。

Because each Android application operates in a process sandbox, applications must

explicitly share resources and data. They do this by declaring the permissions they need

for additional capabilities not provided by the basic sandbox. Applications statically

declare the permissions they require, and the Android system prompts the user for

consent at the time the application is installed. Android has no mechanism for granting

permissions dynamically (at run-time) because it complicates the user experience to the

detriment of security.

因为每一个应用程序工作在一个进程的沙箱中，应用程序并须明确的分享资源和数据。他他们这样做是通过声明权限，他们需要的不是提供基本沙箱的附加功能。应用程序静态申报他们所需要的权限，Android系统会在安装应用程序时提示，以取得同意用户。Android有没有机制可以动态地授予权限（在运行时），因为它使得用户体验更为复杂对安全不利。

The application sandbox does not depend on the technology used to build an application.

In particular the Dalvik VM is not a security boundary, and any app can run native code

(see the Android NDK). All types of applications — Java, native, and hybrid — are

sandboxed in the same way and have the same degree of security from each other.

应用程序沙箱不依赖于用于构建应用程序的技术。尤其是Dalvik虚拟机不是一个安全边界，任何应用程序可以运行本地代码（请参阅Android NDK）。所有类型的应用程序——

Java，本地和混合类型的——被沙箱以同样的方式以及彼此具有相同安全性保护着。

3.2、Application Signing(应用程序签名)

All APKs (.apk files) must be signed with a certificate whose private key is held by their

developer. This certificate identifies the author of the application. The certificate

does not need to be signed by a certificate authority; it is perfectly allowable, and typical,

for Android applications to use self-signed certificates. The purpose of certificates in

Android is to distinguish application authors. This allows the system to grant or deny

applications access to signature-level permissions and to grant or deny an

application's request to be given the same Linux identity as another application.

所有的APK（.apk文件）必须使用由他们的开发者持有的证书的私钥签署。此证书用于标识应用程序的作者。该证书并不需要由证书颁发机构签署; 这是完全允许的，典型情况下，Android应用程序使用自签名证书。Android证书的目的是区分应用程序的作者。这允许系统来允许或拒绝应用程序访问签名级别的权限，并授予或拒绝另一个应用程序申请的请求给予相同的Linux身份。

3.3、User IDs and File Access(用户ID和文件访问)

At install time, Android gives each package a distinct Linux user ID. The identity remains

constant for the duration of the package's life on that device. On a different device, the

same package may have a different UID; what matters is that each package has a

distinct UID on a given device.

安装时，Android分配给每个包一个独特的Linux用户ID。在这个设备上，这个包的标示符保持恒定。在不同的设备，同样的包可能有一个不同的UID; 重要的是，在给定的设备上每个包都有一个不同的UID。

Because security enforcement happens at the process level, the code of any two

packages cannot normally run in the same process, since they need to run as different

Linux users. You can use the

sharedUserId attribute in

the

's

manifest tag of each package to have them assigned the

same user ID. By doing this, for purposes of security the two packages are then treated

as being the same application, with the same user ID and file permissions. Note that in

order to retain security, only two applications signed with the same signature (and

requesting the same sharedUserId) will be given the same user ID.

因为安全强制发生在进程级别，任何两个包的代码无法正常在同一个进程中运行，因为它们需要运行为不同的Linux用户。您可以在

中manifest标签中使用sharedUserId属性让每个包分配相同的用户ID。通过这样做是为了安全性，这两个包视作为同一个应用程序，使用相同的用户ID和文件权限。需要注意的是，为了保留安全性，只有两个具有相同签名（和请求相同sharedUserId）的应用程序才被给予相同的用户ID。

Any data stored by an application will be assigned that application's user ID, and not

normally accessible to other packages. When creating a new file

with

getSharedPreferences(String, int),

openFileOutput(String, int),

or

openOrCreateDatabase(String, int, Factory), you

can use the

MODE_WORLD_READABLE and/or

MODE_WORLD_WRITEABLE flags to allow any

other package to read/write the file. When setting these flags, the file is still owned by

your application, but its global read and/or write permissions have been set appropriately

so any other application can see it.

一个程序存储任何数据都关联到这个应用程序的用户ID，并且默认情况下不能访问其他包的文件。当使用getSharedPreferences(String, int),

openFileOutput(String,

int), 或者

openOrCreateDatabase(String, int,

Factory)

这几个方法的时候，你能使用MODE_WORLD_READABLE

和/或

MODE_WORLD_WRITEABLE 标识来允许任何其它的包去读写这个文件。当设置这些标志的时候，这些文件仍然是由你的应用程序拥有的，但是它的全局读取和/或写入权限被设置为全局，所以任何其他应用程序可以看到它。

3.4、Using Permissions(使用权限)

A basic Android application has no permissions associated with it by default, meaning it

cannot do anything that would adversely impact the user experience or any data on the

device. To make use of protected features of the device, you must include in

your

one or more

tags declaring the

permissions that your application needs.

一个基本的Android应用程序没有与之关联的缺省权限，意味着它不能干任何影响用户体验或对设备上的任何数据造成不利影响事情。为了使用被设备保护的功能，您必须在您的中包含一个或多个你的应用需要的标签。

For example, an application that needs to monitor incoming SMS messages would

specify:

比如说，一个应用程序需要监听接收到的短消息，可以像下面这样做：

package="" >

...

At application install time, permissions requested by the application are granted to it by

the package installer, based on checks against the signatures of the applications

declaring those permissions and/or interaction with the user. No checks with the user are

done while an application is running; the app is either granted a particular permission

when installed, and can use that feature as desired, or the permission is not granted and

any attempt to use the feature fails without prompting the user.

在安装应用程序时，应用程序通过安装程序包请求权限，授予它声明的权限和/或与用户交互基于应用程序的签名检查。当一个应用程序运行时不再做用户检查; 安装时，应用程序要么是被授予特定权限，并根据需要可以使用该功能，或者不被许可，安装时不提示用户，任何尝试使用该功能将失败。

Often times a permission failure will result in a

SecurityException being thrown back

to the application. However, this is not guaranteed to occur everywhere. For example,

the

sendBroadcast(Intent) method checks permissions as data is being delivered to

each receiver, after the method call has returned, so you will not receive an exception if

there are permission failures. In almost all cases, however, a permission failure will be

printed to the system log.

很多时候，请求权限失败将导致SecurityException被抛出到应用程序。但是，这不能保证一定会发生。例如，sendBroadcast(Intent)作为数据被传递到每个Receiver，该

方法调用之后返回，所以如果有权限失败你将不会收到一个异常。但是，在几乎所有情况下，一个失败的权限将被打印到系统日志。

However, in a normal user situation (such as when the app is installed from Google Play

Store), an app cannot be installed if the user does not grant the app each of the

requested permissions. So you generally don't need to worry about runtime failures

caused by missing permissions because the mere fact that the app is installed at all

means that your app has been granted its desired permissions.

然而，在一个普通的用户情况下(比如当应用从Google Play商店上安装)，如果用户没有赋予应用所请求的权限，一个应用不能被安装。所以你一般不需要担心造成丢失权限导致的运行失败，因为该应用程序被安装意味着你的应用程序已经获得其所需的权限。

The permissions provided by the Android system can be found

at

sion. Any application may also define and enforce its own

permissions, so this is not a comprehensive list of all possible permissions.

由Android系统提供的权限可以在这里找到sion。任何应用程序也可以定义并执行其自己的权限，所以这不是所有可能的权限的完整列表。

A particular permission may be enforced at a number of places during your program's

operation:

你的程序的运行过程中在一些地方特定的权限可能被强制执行：



At the time of a call into the system, to prevent an application from executing certain

functions.

在执行系统调用的时候，以防止应用程序执行某些功能。



When starting an activity, to prevent applications from launching activities of other

applications.

当启动一个Activity的时候，以防止其他应用启动Activity



Both sending and receiving broadcasts, to control who can receive your broadcast or

who can send a broadcast to you.

发送和接收广播，来控制谁可以接收你的广播或者谁可以发送广播给您



When accessing and operating on a content provider.

当访问和操作Content Provider的数据的时候



Binding to or starting a service.

绑定或者启动一个服务的时候

Caution: Over time, new restrictions may be added to the platform such that, in order to

use certain APIs, your app must request a permission that it previously did not need.

Because existing apps assume access to those APIs is freely available, Android may

apply the new permission request to the app's manifest to avoid breaking the app on the

new platform version. Android makes the decision as to whether an app might need the

permission based on the value provided for the

targetSdkVersion attribute. If the value

is lower than the version in which the permission was added, then Android adds the

permission.

注意：随着时间的推移，新的限制可能被添加到该平台，您的应用程序必须请求它以前不不需要的权限，只有这样才能使用某些API。因为现有的应用程序假定访问这些API是免费提供的，Android的可能应用这些新的权限请求到应用程序的清单，以避免破坏新平台版本的应用程序。Android根据targetSdkVersion 属性的值做出决定，一个应用程序是否可能需要这些权限。如果该值小于这个权限加入的平台版本，那么Android添加这个权限。

For example, the

WRITE_EXTERNAL_STORAGE permission was added in API level 4 to

restrict access to the shared storage space. If your

targetSdkVersion is 3 or lower,

this permission is added to your app on newer versions of Android.

例如，WRITE_EXTERNAL_STORAGE权限在API级别4加入限制访问共享存储空间。如果您targetSdkVersion为3或更低，此权限在新版本的Android将被添加到您的应用程序。

Beware that if this happens to your app, your app listing on Google Play will show these

required permissions even though your app might not actually require them.

要注意的是，如果发生这种情况，您的应用程序，Google Play上您的应用程序列表将显示这些所需的权限，即使您的应用程序可能无法真正需要他们。

To avoid this and remove the default permissions you don't need, always update

your

targetSdkVersion to be as high as possible. You can see which permissions

were added with each release in the

N_CODESdocumentation.

为了避免这种情况，并删除你不需要的默认权限，需要更新你的targetSdkVersion 要尽可能地高。你可以在N_CODES文档看到每个版本添加的哪些权限 。

3.5、Declaring and Enforcing Permissions(声明和强制执行权限)

To enforce your own permissions, you must first declare them in

your

using one or more tags.

要执行你自己的权限，必须首先在你的

中使用一个或多个

标签声明它们。

For example, an application that wants to control who can start one of its activities could

declare a permission for this operation as follows:

例如，要控制谁可以启动它的Activity之一，应用程序可以像下面这样声明操作权限：

xmlns:android="/apk/res/android"

package="" >

android:name="_ACTIVITY"

android:label="@string/permlab_deadlyActivity"

android:description="@string/permdesc_deadlyActivity"

android:permissionGroup="_MONEY"

android:protectionLevel="dangerous" />

...

The

attribute is required, telling the system how the user is to be

informed of applications requiring the permission, or who is allowed to hold that

permission, as described in the linked documentation.

属性是必需的，告诉系统用户是如何被告知应用程序需要的权限，或者谁被允许持有该权限，链接的文档中有详细的说明

The

attribute is optional, and only used to help the system display

permissions to the user. You will usually want to set this to either a standard system

group (listed in

sion_group) or in more rare cases to one

defined by yourself. It is preferred to use an existing group, as this simplifies the

permission UI shown to the user.

属性是可选的，并且只用于帮助系统显示权限给用户。你通常会希望将其设置为一个标准的系统组（列表在sion_group）或更罕见的情况下给一个自己定义的。优先使用现有的组，因为这简化了显示给用户的使用权限的用户界面。

Note that both a label and description should be supplied for the permission. These are

string resources that can be displayed to the user when they are viewing a list of

permissions (android:label) or details on a single permission

(

android:description). The label should be short, a few words describing the key

piece of functionality the permission is protecting. The description should be a couple

sentences describing what the permission allows a holder to do. Our convention for the

description is two sentences, the first describing the permission, the second warning the

user of what bad things can happen if an application is granted the permission.

注意，label和description是permission应该提供的。它们的字符串资源能够在它们显示permission列表的时候(android:label)或者显示一个permission的详情的时候(android:description)显示给用户。标签应尽量短，用几句话描述permission所保护的关键部分。描述应该是一两句描述了允许权限持有人能做什么。我们的描述约定是两句

话，第一描述权限，第二个警告用户：如果这个权限被授予一个应用程序被会发生什么样不好的事情。

Here is an example of a label and description for the CALL_PHONE permission:

下面是CALL_PHONE权限的一个label和description的例子：

directly call phone

numbers

Allows the application to call

phone numbers without your intervention. Malicious

applications may

cause unexpected calls on your phone bill. Note that this

does not

allow the application to call emergency numbers.

You can look at the permissions currently defined in the system with the Settings app and

the shell command

adb shell pm list permissions. To use the Settings app, go to

Settings > Applications. Pick an app and scroll down to see the permissions that the app

uses. For developers, the adb '-s' option displays the permissions in a form similar to how

the user will see them:

你可以从设置中或者使用shell命令的adb shell pm list permissions查看应用程序所具有的权限。如果要从设置中查看：进入设置>应用程序，选择一个应用程序，然后向下滚动以查看该应用程序使用的权限。对于开发人员，adb “-S” 选项显示权限形式类似于下面这样：

$ adb shell pm list permissions -s

All Permissions:

Network communication: view Wi-Fi state, create Bluetooth

connections, full

Internet access, view network state

Your location: access extra location provider commands, fine (GPS)

location,

mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone

numbers

...

3.5.1、Enforcing Permissions in (在中执行权限)

High-level permissions restricting access to entire components of the system or

application can be applied through your

. All that this requires is

including an

android:permission attribute on the desired component, naming the

permission that will be used to control access to it.

可以通过你的应用限制用户进入系统组件或整个应用程序的的高级别权限。这必须包含一个

android:permission

属性所需的组件，命名的权限将被用来控制对它的访问。

Activity permissions (applied to the

tag) restrict who can start the

associated activity. The permission is checked

during

ctivity() and

ctivityForResult(); if

the caller does not have the required permission then

SecurityException is thrown

from the call.

Activity 权限(应用到标签)限制谁能启动相关的Activity。权限检查将在ctivity() and

ctivityForResult();的时候执行；如果你没有权限调用的话，将会抛出

SecurityException

异常。

Service permissions (applied to the

tag) restrict who can start or bind to the

associated service. The permission is checked

during

ervice(),

rvice() and

rvice(); if the caller does not have the required permission then

SecurityException is

thrown from the call.

Service 权限(应用于

标签)将限制谁能够启动或者绑定相关的Service。权限检查将在ervice(),

rvice() and

rvice();的时候执行。如果你没有权限调用这些方法的话，将会抛出SecurityException

异常。

BroadcastReceiver permissions (applied to the

tag) restrict who can

send broadcasts to the associated receiver. The permission is

checked after

oadcast() returns, as the system tries to deliver the

submitted broadcast to the given receiver. As a result, a permission failure will not result

in an exception being thrown back to the caller; it will just not deliver the intent. In the

same way, a permission can be supplied to

erReceiver() to control

who can broadcast to a programmatically registered receiver. Going the other way, a

permission can be supplied when calling

oadcast() to restrict which

BroadcastReceiver objects are allowed to receive the broadcast (see below).

BroadcastReceiver 权限(应用于

标签)将限制谁能够发送广播到相关的receiver。这个权限检查将在oadcast()方法返回之后进行，随后系统试图将提交的广播发送到给定的Receiver。其结果是，一个权限异常不会被抛回给调用者; 它只是无法发送Intent。以同样的方式，使用权限可以传递给erReceiver() 方法来控制谁谁能够广播以编程方式注册的Receiver。另外一种方式，权限可以在当做参数传递给

oadcast() 方法来限制哪些BroadcastReceiver对象可以接收广播（见下文）。

ContentProvider permissions (applied to the

tag) restrict who can access

the data in a

ContentProvider. (Content providers have an important additional

security facility available to them called URI permissions which is described later.) Unlike

the other components, there are two separate permission attributes you can

set:

android:readPermission restricts who can read from the provider, and

android:writePermission restricts who can write to it. Note that if a provider is

protected with both a read and write permission, holding only the write permission does

not mean you can read from a provider. The permissions are checked when you first

retrieve a provider (if you don't have either permission, a SecurityException will be

thrown), and as you perform operations on the provider. Using

() requires holding the read permission;

using

(),(),

() requires the write permission. In all of these cases, not holding the required

permission results in a

SecurityException being thrown from the call.

ContentProvider 权限 (应用于

标签) 将限制谁能够访问ContentProvider中的数据。(Content provider有一个非常重要的额外的安全技巧称为 URI的权限。这将在后面介绍)不像其他的组件一样，有两个不同的属性可以设置：android:readPermission 限制谁能从Provider中读取数据；android:writePermission 限制谁能往Provider中写入数据；请注意，如果一个Provider同时具有读和写权限的保护，只拿着写权限并不意味着你可以从Provider读取。权限检查是在你得到Provider并且在它之上第一次执行一个操作的时候执行的(如果你没有任何一个权限，一个SecurityException将被抛出)。使用()必须具有读权限；使用() ，()，

()必须具有写权限；在所有的情况下，不具备必须的权限的结果就是抛出一个SecurityException。

3.5.2、Enforcing Permissions when Sending Broadcasts(当发送广播的时候执行权限)

In addition to the permission enforcing who can send Intents to a

registered

BroadcastReceiver (as described above), you can also specify a required

permission when sending a broadcast. By oadcast() with a

permission string, you require that a receiver's application must hold that permission in

order to receive your broadcast.

除了执行谁可以发送Intent到注册的BroadcastReceiver（如上所述）之外，您也可以发送广播时指定必需的权限。通过调用oadcast()与permission字符串，为了接受你的广播，程序必须具有相应的权限才可以。

Note that both a receiver and a broadcaster can require a permission. When this

happens, both permission checks must pass for the Intent to be delivered to the

associated target.

注意，Receiver和Broadcast必须具有相同的权限。当这一切发生的时候,这两个权限检查必须通过意图传递给相关的目标。

3.5.3、Other Permission Enforcement(其它权限的执行)

Arbitrarily fine-grained permissions can be enforced at any call into a service. This is

accomplished with the

allingPermission() method. Call with a

desired permission string and it will return an integer indicating whether that permission

has been granted to the current calling process. Note that this can only be used when

you are executing a call coming in from another process, usually through an IDL interface

published from a service or in some other way given to another process.

任意细粒度的权限可以在调用任何一个服务执行。这是allingPermission()完成的。调用传入一个所需的字符串,它将返回一个整数表示权限是否被授予当前调用进程。注意,这只是用于当你执行一个来自另一个进程的调用的时候,通常通过一个IDL接口发布服务或以其它方式传递给另一个进程。

There are a number of other useful ways to check permissions. If you have the pid of

another process, you can use the Context

method

ermission(String, int, int) to check a permission

against that pid. If you have the package name of another application, you can use the

direct PackageManager method

ermission(String,

String) to find out whether that particular package has been granted a specific

permission.

还有一些其他有用的方法来检查权限。如果你有另一个进程的PID，您可以使用Context的方法ermission(String, int, int)检查该pid的权限。如果您有其他应用程序的包名，则可以使用直接PackageManager方法ermission(String, String) 来找出特定的包是否已授予特定权限。

3.6、URI Permissions(URI权限)

The standard permission system described so far is often not sufficient when used with

content providers. A content provider may want to protect itself with read and write

permissions, while its direct clients also need to hand specific URIs to other applications

for them to operate on. A typical example is attachments in a mail application. Access to

the mail should be protected by permissions, since this is sensitive user data. However, if

a URI to an image attachment is given to an image viewer, that image viewer will not

have permission to open the attachment since it has no reason to hold a permission to

access all e-mail.

到目前为止所描述的标准的权限系统在使用Content Provider的时候往往是不足够的。Content Provider可能希望保护自己的读取和写入权限，而其直接的用户还需要手工指定URI到对他们进行操作的其他应用程序。一个典型的例子是邮件应用程序的附件。访问邮件应该得到权限的保护，因为这是敏感的用户数据。但是，如果URI图片附件传递给一个图像浏览器，该图像浏览器将没有权限打开附件，因为它没有理由持有以访问所有电子邮件的权限。

The solution to this problem is per-URI permissions: when starting an activity or returning

a result to an activity, the caller can

set

_GRANT_READ_URI_PERMISSION and/or

_GRANT_WRITE_URI_PERMISSION. This grants the receiving activity permission access the specific data

URI in the Intent, regardless of whether it has any permission to access data in the

content provider corresponding to the Intent.

解决这个问题是的方案是每个URI权限：启动一个Activity或返回一个结果到一个Activity的时候，调用者可以设置_GRANT_READ_URI_PERMISSION和/或

_GRANT_WRITE_URI_PERMISSION。这将授予接收Activity权限访问特定数据的URI的意图，不管它是否有访问ContentProvider中对应的Intent的任何数据的权限。

This mechanism allows a common capability-style model where user interaction (opening

an attachment, selecting a contact from a list, etc) drives ad-hoc granting of fine-grained

permission. This can be a key facility for reducing the permissions needed by

applications to only those directly related to their behavior.

这种机制允许一个通用的能力-风格模型，其中用户交互（打开一个附件，从列表中选择一个联系人，等等）驱动特别授予细粒度的权限。这可能是一个关键的措施减少应用程序所需的权限，只需要关心那些直接关系到他们的行为的权限。

The granting of fine-grained URI permissions does, however, require some cooperation

with the content provider holding those URIs. It is strongly recommended that content

providers implement this facility, and declare that they support it through

the

android:grantUriPermissions attribute or

tag.

确实授予细粒度的URI的权限，但是，需要和Content Provide合作拿到这些URI。强烈建议Content Provider实现这种方案，并通过支持它的

android：grantUriPermissions属性或

标签定义出来。

More information can be found in

the

riPermission(),

UriPermission(),

riPermission() methods.

更多信息可以在

riPermission(),

UriPermission()和riPermission() 方法找到。

CONTINUE READING ABOUT: YOU MIGHT ALSO BE INTERESTED IN:

Permissions that Imply Feature Device Compatibility

Requirements Information about Android works on

Information about how requesting some different types of devices and an

permissions will implicitly restrict your introduction to how you can optimize

app to devices that include the your app for each device or restrict your

corresponding hardware or software app's availability to different devices.

feature.

Android Security Overview

A detailed discussion about the Android

API reference for the manifest tag that platform's security model.

declare's your app's required system

设备兼容性

permissions.

关于Android适用于不同类型的设备的sion

信息，并介绍了如何优化你的应用程序API reference for all system permissions.

为每个设备或限制您的应用程序的可用性，以不同的设备。

特性的隐式必需权限

有关如何必需一些权限的信息将隐式限Android的安全性概述

制您的应用程序，包括相应的硬件或软关于Android平台的安全模型的详细讨件功能的设备。 论。

使用清单标签，声明的你的应用程序所需的系统权限的API参考。

sion

对于所有系统权限的API参考。