原文链接：http://developer.android.com/guide/topics/security/security.html

编辑者：a06063175

更新时间：

* 安全性和权限*

本文档介绍了程序开发人员如何使用由Android提供的安全机制。在Android开源项目中提供一个更一般的Android安全性概述。

Android是一种各个权限相互独立的操作系统，在每个运行中的应用程序，具有鲜明的系统标识（Linux用户ID和组ID）。系统也被分成各个具有各自独立特性的部分。在这方面很像Linux，各个应用程序之间和系统之间也是相互独立的。

各种需要附加的功能通过“权限”这一机制予以提供，这种机制强制限制了每一次特定进程的具体操作。

* 安全架构*

Android安全架构设计的关键点是，在默认情况下，没有应用程序，有权限来执行任何将对其他应用程序、操作系统或者用户产生不利影响的操作。这包括读取或写入用户的私人数据（如通讯录或电子邮件），读取或写入另一个应用程序的文件，执行网络访问，维持设备运行状态等。

因为Android应用程序之间有沙盒机制的影响，应用程序必须明确地共享资源和数据。他们宣布， 他们需要基本沙箱未提供的附加功能的权限。应用静态宣布他们所需要的权限，Android系统在应用程序被安装时提示用户同意。Android有没有授予权限的动态（运行时），因为它的复杂性用户体验到不利于安全的机制。

用于构建应用程序的技术不依赖于应用程序沙箱。特别是Dalvik虚拟机是不是一个安全边界，任何应用程序可以运行本地代码（参见Android NDK）。所有类型的应用- Java中，本地和混合-沙箱中以同样的方式，从对方的相同程度的安全。

* 应用签名*

所有的Android应用程序（.apk文件）必须被该程序的开发者所持有签署证书进行签名。此证书必须能够证明应用程序的作者的身份。证书并不需要由证书颁发的机构签署：它是完全受认可的的，典型的，Android应用���序使用自签名证书。Android证书使用的目的是区分应用程序的开发者。这允许系统授予或拒绝应用程序访问签名级别的权限，并授予或拒绝应用程序给予就像Linux一样确认另一个应用程序的身份的要求。

* 用户ID和文件访问*

在安装时，Android 给每个包一个独特的Linux用户ID。包的该设备上的生命期间的身份仍然保持不变。在不同的设备，同样的包可能有不同的UID;重要的是，给定的设备上每个包都有一个不同的UID。

因为安全机制在进程级别上的强制执行，任何两个包中的代码不能正常运行在同一进程中，因为他们需要运行不同的Linux用户。您可以通过设置AndroidManifest.xml文件manifest标签中的 sharedUserId属性来使这些应用程序包被相同的UID所签名。这样，这两个包被视为是相同的应用程序并且具有相同的UID和文件的权限。请注意，为了保持安全，只有两个应用程序具有相同签名（并要求相同sharedUserId）签署将给予相同的UID。

应用程序中存储的任何数据将被按应用程序的用户ID分配，而不是一般地正常访问其他程序包。当通过getSharedPreferences(String, int))、openFileOutput(String, int))或者 openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory))创建一个新的文件时，你可以通过指定MODE_WORLD_READABLE和/或MODE_WORLD_WRITEABLE的标志来决定是否允许其他程序读/写该文件。设置这些标志时，该文件仍然属于你的应用程序，但其在全局的任何其他应用程序已经可以通过对权限进行适当的设置来读取和/或写入。

* 使用权限*

一个基本的Android应用程序有没有与之相关的权限，这意味着它不能做任何会产生不利影响的用户体验或读取设备上的任何数据。为了安全使用设备上的功能，你必须包括在您的AndroidManifest.xml一个或多个 声明您需要的的权限标签。

例如，一个应用程序，需要监测接收到的SMS消息将指定：

...

在申请安装时，由应用程序请求的权限授予给它的安装程序包的基础上对申报的权限和/或与用户的交互的应用程序的签名检查，没有与用户的检查，而应用程序是运行：它要么被授予特定的权限安装时，可以使用该功能需要，或没有被授予的权限和使用功能的任何企图将不提示用户的情���下失败。

很多时候，一个权限失败将导致在被抛出SecurityException返回给应用程序。然而，这并不保证到处发生。例如，sendBroadcast（意向）方法检查权限数据被传递到每个接收方法调用返回后，这样你就不会收到一个异常，如果有权限失败。然而，在几乎所有情况下，权限失败将被打印到系统日志。

Android系统提供的权限，可以发现在Manifest.permission。任何应用程序还可以定义和执行其自己的权限，因此，这是不全面的所有可能的权限列表。

在一些地方，你的程序的操作过程中可强制执行特定的权限：

    ·在进入系统调用，执行某些功能，以防止应用程序的时间。
    ·当开始一项活动，以防止应用程序启动其他应用程序的活动。
    ·发送和接收广播，来控制谁可以接收你的广播，或谁可以给你发送一个广播。
    ·当访问和经营上的内容提供商。
    ·绑定或启动服务。

* 声明和执法权限*

为了执行自己的权限，你必须首先在你的AndroidManifest.xml中通过使用一个或多个 标签声明他们。
例如，一个应用程序���要想要控制其他app启动他自己的Activity，可以宣布此操作的权限如下：

...

属性是必需的，这将使系统知道用户将使用什么样的权限，或者谁被允许持有该权限，就像链接文档中所述那样。

属性是可选的，只用来帮助系统向用户显示权限。你通常会要设置一个标准的系统组（在上市android.Manifest.permission_group），或在更罕见的情况下，以自己定义一个。这是首选使用现有的组，因为这简化UI显示给用户的权限。

请注意，标签和描述应提供的许可。这些都是字符串资源，可以向用户显示时，他们正在查看权限列表(android:label)或单一许可 ( android:description)。标签应该简短，描述的许可保护功能的关键部分。说明应该是一对的句子描述允许持有人做什么的权限。我们一般用两句话来描述，第一句描述权限，第二个警告用户如果授予程序该权限将会带来的可能的后果。

这里是一个描述CALL_PHONE权限的标签的例子：

你可以通过设置程序和shell命令：adb shell pm list permissions看一下目前在系统中定义的权限。使用设置程序，在设置>应用。选择一个应用程序通过向下翻屏可以看到该应用程序使用的权限。对于开发者来说， 可以通过adb '-s' 将权限项展示在一个列表中，就像用户看到的那样。

* 在AndroidManifest.xml执法权限*

高级别权限限制访问整个系统或应用程序组件可以通过你的AndroidManifest.xml应用 。这需要包括了android:permission所需的组件的属性，命名将用于控制访问它的权限。

Activity权限（适用于的标签）限制谁可以启动相关的活动。检查权限，在 Context.startActivity（）和 Activity.startActivityForResult（） ;如果调用方不具有所需的权限，然后从调用抛出SecurityException。

服务权限（应用于 的标签的）限制谁可以启动相关的服务或绑定。检查权限，在 Context.startService（） ， Context.stopService（）和 Context.bindService（） ;如果调用方不具有所需的权限，然后从调用抛出SecurityException。

BroadcastReceiver权限（应用的 标签）限制谁可以发送广播相关的接收。检查权限Context.sendBroadcast（）返回后 ，系统尝试提供提交给定的接收广播。因此，权限失败不会导致一个异常被抛出返回给调用者，它只是将不提供的意图。以同样的方式，可以提供权限为 Context.registerReceiver（） 来控制谁可以播放编程注册接收器。去的其他方式，权限可以调用Context.sendBroadcast（） 来限制，BroadcastReceiver对象被允许接收广播（见下文）时提供 。

ContentProvider的权限（应用于的 的标签）限制谁可以访问数据在ContentProvider的。不同于其他组成部分（内容提供商有一个重要的呼吁向他们提供额外的安全设施 的URI权限，这将在后面介绍），有两个独立的权限属性，您可以设置： 机器人：readPermission限制谁可以读取从供应商， 和 android ： writePermission限制谁可以写入。请注意，如果一个供应商的保护同时读取和写入权限，拿着只写权限，并不意味着你可以读取从一个供应商。检查的权限，当你第一次检索提供商（如果你没有任何权限，会抛出一个SecurityException），并作为执行对供应商的业务。使用 ContentResolver.query（）需要持有只读的权限;使用 ContentResolver.insert（）中， ContentResolver.update（） ， ContentResolver.delete（） 需要写权限。在所有这些情况下，不持有所需的权限，结果在 SecurityException被调用抛出。

* 发送广播时，执法权限*

除了 ​​执行谁可以发送意向注册BroadcastReceiver（如上所述）的权限，你也可以指定所需的权限，当发送广播。通过在调用Context.sendBroadcast（）)权限字符串，你需要接收器的应用，必须持有该权限，以便接收您的广播。

请注意，一个接收器和一个广播可以要求权限。发生这种情况时，必须通过两个权限检查的意图被传递到相关的目标。

* 其他权限执法*

任意细粒度的权限，可以随时到服务呼叫执行。这是与Context.checkCallingPermission（）) 方法来完成。调用所需的权限字符串，它将返回一个整数，指示是否已被授予该权限当前通话过程。请注意，这只能用来当你从另一个进程，通常是通过IDL接口出版服务，或在一些其他的方式给另一个进程，执行呼叫。

有一些其他有用的方法来检查权限。如果你有另一个进程的pid，你���以使用上下文方法Context.checkPermission（String，int，int）)的 检查针对该PID的权限。如果你有另一个应用程序的包名，你可以使用套装软体的直接的方法PackageManager.checkPermission（String，String）) ，找出特定包是否已被授予特定的权限。

* URI的权限*

时至今日，当我们用到content providers时，有关标准的系统权限的表述依旧不够充分。内容提供商可能要保护本身的读写权限，而其直接的客户也需要交给他们经营的其他应用特定的URI。一个典型的例子是在邮件应用程序的附件。由权限访问邮件，应当受到保护，因为这是敏感的用户数据。但是，即使一个图片浏览器获得到了一个图片附件的URI，这个图片浏览器也没有权限打开这个附件，因为它没有理由持有的权限来访问所有电子邮件的权限。

这个问题的解决是针对每一个URI的权限：当启动一个Activity，或返回一个Activity的结果时，调用者可以设置 Intent.FLAG_GRANT_READ_URI_PERMISSION 和/或 Intent.FLAG_GRANT_WRITE_URI_PERMISSION。这将授予Activity许可在Intent中接受访问特定的URI数据，不管它是否有权限在与Intent通信的content provider中访问相应的数据。

这种机制允许一个共同的功能式模型，用户交互（打开附件，选择从列表中的联系人等）驱动器特设给予细粒度的权限。通过应用只与其直接相关的行为，可能会成为减少其所需的权限的关键技巧。

细粒度的URI权限的授予不，但是，需要一些持有这些URI的content providers的合作。强烈建议，content providers实现该设施，并宣布他们支持：grantUriPermissions属性或 标签。

在Context.grantUriPermission())， Context.revokeUriPermission（）)和Context.checkUriPermission（）) 方法中,可以发现更多的信息。