Android 安全机制

翻译稿：

Permissions

This document describes how application developers can use the security features provided by Android. A more generalAndroid Security Overview is provided in the Android Open Source Project.

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 also separated into distinct identities. Linux thereby isolates applications from each other and from the system.

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.

Android是一种权限分离的操作系统，其中每个应用以唯一的身份标识（Linux用户ID和组ID）运行。系统的不同部分也分成不同的身份。因而 Linux吧应用之间以及应用与系统之间相互隔离起来。
附加细粒度的安全功能是通过一个“许可“的机制，限定特定的进程能够执行指定的操作以及给予对每一个资源点对点的访问的URI许可。

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 e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc.

Because Android sandboxes applications from each other, applications must explicitly share resources and data. They do this by declaring thepermissions 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.

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

Android安全体系结构的中心是，没有哪个应用陈旭默认可以执行对其他应用程序、操作系统或者用户有害的操作。其中包括读写用户的私有数据（如联系人或电子邮件），读写其它应用程序的文件，进行网络访问或唤醒设备。
由于内核让每一个应用程序运行在独立的沙盒之中，应用程序必须明确的分享资源及数据。他们通过声明他们所需要的沙盒未提供的权限。应用程序静态的声明他们所需要的权限，android系统在程序安装时提示用户同意它们获取这些权限。Dalvik虚拟机并不是安全的边界，因为应用程序可以执行本地代码。所有类型的应用程序——Java、native和混合的——均用相同的方式置于砂箱中并且有着相同的安全等级。

Application Signing

All Android applications (.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 doesnot 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.

所有的Android应用程序（apk文件）必须使用一个开发人员掌握私钥的证书进行签名。该证书用于识别应用程序的作者。该证书并不需要由证书颁发机构进行签名：它是非常宽松的，典型的Android应用程序使用自签名的证书。Android证书的主要目的是要区分应用程序的作者。这样可以让系统可以给予或拒绝应用程序使用签名级别的权限或者让系统这可以允许或拒绝应用程序请求和其它应用程序相同的身份标识。

User IDs and File Access

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.

Because security enforcement happens at the process level, the code of any two packages can not normally run in the same process, since they need to run as different Linux users. You can use thesharedUserId attribute in theAndroidManifest.xml'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.

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 withgetSharedPreferences(String, int),openFileOutput(String, int), oropenOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use the MODE_WORLD_READABLE and/orMODE_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.

在安装的时候，Android给予每个程序包不同的Linux用户ID。软件包在设备上的生命周期中身份标识保持不变在。在不同的设备上，同样的软件包有着不同的身份标识，重要的是每个包都有不同的身份标识在给定的设备上。

安全在进程级别上实现，任意两个程序包的代码不能正常运行在同一进程中，因为他们需要以不同的Linux用户运行。可以使用每个程序包的AndroidManifest.xml中的manifest标签中的shareUserId属性将它们分配相同的用户ID。这样做的主要目的是为了安全，这两个包将被视作为同一个应用程序，拥有相同的用户ID和文件的权限。为了保持安全，只有具有相同签名（并请求同样的sharedUserId）的应用程序才会分配通用的用户ID。
任何由应用程序存储的数据将被赋予应用程序的用户ID，正常情况不能被其它应用程序访问。当使用getSharedPreferences(String,int), openFileOutput(String,int), or openOrCreateDatabase(String,int, SQLiteDatabase.Curso**ctory)创建一个新的文件时，可以使用MODE_WORLD_READABLE或MODE_WORLD_WRITEABLE标志允许任何其他应用程序来读/写入文件。当设置这些标志，该文件仍然为创建文件的应用程序所拥有，但其全局读写权限已经被设置，所以任何其他应用程序可以看到它。

Using Permissions

A basic Android application has no permissions associated with it, meaning it can not 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 yourAndroidManifest.xml one or more <uses-permission> tags declaring the permissions that your application needs.

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

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

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: it either was granted a particular permission when installed, and can use that feature as desired, or the permission was not granted and any attempt to use the feature will fail 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.

The permissions provided by the Android system can be found at Manifest.permission. Any application may also define and enforce its own permissions, so this is not a comprehensive list of all possible permissions.

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.
• 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.
• Binding to or starting a service.

一个基本的Android应用程序没有任何的权限，这意味着它不能做任何会对用户体验或设备上的任何数据造成不利影响的操作。为了使用该设备的保护功能，必须在AndroidManifest.xmlone文件中的一个或多个<uses-permission>标签上声明应用程序所需要的权限。
例如，一个应用程序需要监控接收短信会注明：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>

应用程序在安装时，应用程序所需的权限被安装者基于签名的应用程序所声明的权限交互的进行授权。应用程序运行时不会进行权限检查，它们或者成功执行所拥有的权限，或者试图尝试自己不拥有的权限而失败并且不会对用户有任何提示。

通常一个请求权限的失败将导致应用程序抛出一个SecurityException异常。但这不一定会发生。例如，sendBroadcast(Intent)方法在所有数据被投递到接收者，当方法返回后才会进行对于数据的权限检查，所以不能接收到任何权限异常。几乎所有情况下，权限异常将会记录在日志中。

所有Android系统提供的权限可以在Manifest.permission中找到。任何应用程序也可以定义并执行其自己的权限，所以这不是所有可能的权限的详细清单。

·        特定的权限可能在程序执行的几个时刻执行：

·        当调用系统调用时，阻止应用程序执行特定的功能。

·        启动一个Activity时，组织程序打开一个Activity。

·        在发送或接受广播时，控制谁可以接受你的广播或者谁可以向你发送广播。

·        谁可以访问或操作一个特定的内容提供商。

·        绑定或者启动一项服务。

Declaring and Enforcing Permissions

To enforce your own permissions, you must first declare them in your AndroidManifest.xml using one or more <permission> 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:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.me.app.myapp" >
    <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"
        android:label="@string/permlab_deadlyActivity"
        android:description="@string/permdesc_deadlyActivity"
        android:permissionGroup="android.permission-group.COST_MONEY"
        android:protectionLevel="dangerous" />
    ...
</manifest>

The <protectionLevel> 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 <permissionGroup> 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 android.Manifest.permission_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.

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.

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

    <string name="permlab_callPhone">directly call phone numbers</string>
    <string name="permdesc_callPhone">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.</string>

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:

$ 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

...

为了实现应用程序自己的权限，必须先在AndroidManifest.xml中使用一个或多个<permission>标签声明它们。
例如，一个应用程序要控制谁可以启动其Activity可以声明此操作的权限如下：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.me.app.myapp" >
    <permission android:name="com.me.app.myapp.permission.DEADLY_ACTIVITY"
        android:label="@string/permlab_deadlyActivity"
        android:description="@string/permdesc_deadlyActivity"
        android:permissionGroup="android.permission-group.COST_MONEY"
        android:protectionLevel="dangerous" />
    ...
</manifest>

<protectionLevel>属性是必需的描述在这个标签中，它告诉系统怎样通知用户当其它应用程序需要该权限或者谁可以持有该权限。

<permissionGroup>属性是可选的，用于帮助系统展示的权限给用户。您通常会希望将它设置为一个标准的系统组（在android.Manifest.permission_group中）或由自己定义了一个较罕见的案例。这是首选使用现有的组，用于简化权限UI展示给用户。

注意，这两个标签和说明应用于的说明权限。用户在查看的权限列表(android:label)或单个权限( android:description)的细节时，这些内容被展现。标签应该简洁的介绍权限保护的关键功能。用几个简单的句子描述拥有该权限可以做什么。我们的惯例是用两个句子，第一句描述权限，第二句警告用户当授权该权限后会发生什么。

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

    <string name="permlab_callPhone">directly callphone numbers</string>
    <string name="permdesc_callPhone">Allows theapplication to call
        phone numbers without your intervention. Maliciousapplications may
        cause unexpected calls on your phone bill. Notethat this does not
        allow the application to call emergency numbers.</string>

可以通过shell命令 adb shell pm list permissions来查看现在系统上的权限定义。特别地，-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 callphone numbers

...

Enforcing Permissions in AndroidManifest.xml

High-level permissions restricting access to entire components of the system or application can be applied through your AndroidManifest.xml. 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.

Activity permissions (applied to the <activity> tag) restrict who can start the associated activity. The permission is checked during Context.startActivity() and Activity.startActivityForResult(); if the caller does not have the required permission then SecurityException is thrown from the call.

Service permissions (applied to the <service> tag) restrict who can start or bind to the associated service. The permission is checked during Context.startService(), Context.stopService() and Context.bindService(); if the caller does not have the required permission then SecurityException is thrown from the call.

BroadcastReceiver permissions (applied to the <receiver> tag) restrict who can send broadcasts to the associated receiver. The permission is checked after Context.sendBroadcast() 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 Context.registerReceiver() to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when calling Context.sendBroadcast() to restrict which BroadcastReceiver objects are allowed to receive the broadcast (see below).

ContentProvider permissions (applied to the <provider> 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 ContentResolver.query() requires holding the read permission; using ContentResolver.insert(), ContentResolver.update(), ContentResolver.delete() requires the write permission. In all of these cases, not holding the required permission results in a SecurityException being thrown from the call.

限制对整个系统组件或应用程序访问的高级别的权限在中AndroidManifest.xml应用。

高级别权限限制访问的系统或应用程序的全部组件都可以通过yourAndroidManifest.xml应用。所有这需要的是一个机器人，包括：对所需的组件权限属性，命名将使用它来控制存取权限。
活动权限（适用于<activity>标签）限制谁可以启动相关的活动。检查duringContext.startActivity的权限（）和Activity.startActivityForResult（）;如果调用方没有所要求的权限thenSecurityException是从调用抛出。
服务权限（适用于<service>标记）限制谁可以启动或绑定到相关的服务。检查过程中的权限Context.startService（），Context.stopService（）和Context.bindService（）;如果调用方没有所要求的权限，然后SecurityException的是从调用抛出。

 

1 Android 安全机制概述

Android 是一个权限分离的系统 。 这是利用 Linux 已有的权限管理机制，通过为每一个 Application 分配不同的 uid 和 gid ， 从而使得不同的 Application 之间的私有数据和访问（ native 以及 java 层通过这种 sandbox 机制，都可以）达到隔离的目的 。 与此 同时， Android 还 在此基础上进行扩展，提供了 permission 机制，它主要是用来对 Application 可以执行的某些具体操作进行权限细分和访问控制，同时提供了 per-URI permission 机制，用来提供对某些特定的数据块进行 ad-hoc 方式的访问。

1.1 uid 、 gid 、 gids

Android 的权限分离的基础是建立在 Linux 已有的 uid 、 gid 、 gids 基础上的 。

UID 。 Android 在 安装一个应用程序，就会为 它 分配一个 uid （参考 PackageManagerService 中的 newUserLP 实现）。其中普通 A ndroid 应用程序的 uid 是从 10000 开始分配 （参见 Process.FIRST_APPLICATION_UID ）， 10000 以下是系统进程的 uid 。

GID 。对 于普通应用程序来说， gid 等于 uid 。由于每个应用程序的 uid 和 gid 都不相同， 因此不管是 native 层还是 java 层都能够达到保护私有数据的作用 。

GIDS 。 gids 是由框架在 Application 安装过程中生成，与 Application 申请的具体权限相关。 如果 Application 申请的相应的 permission 被 granted ，而且 中有对应的 gid s ， 那么 这个 Application 的 gids 中将 包含这个 gid s 。

uid gid gids 的 详细 设置过程：

请参考 Act i vityManagerService 中的 startProcessLocked 。在通过 zygote 来启动一个 process 时，直接将 uid 传给 给了 gid 。再通过 zygote 来 fork 出新的进程（ zygote.java 中的 forkAndSpecialize ），最终在 native 层（ dalvik_system_zygote.c ）中的 forkAndSpecializeCommon 中通过 linux 系统调用来进行 gid 和 uid 和 gids 的设置。

1.2 permission

一个权限主要包含三个方面的信息：权限的名称；属于的权限组；保护级别。一个权限组是指把权限按照功能分成的不同的集合。每一个权限组包含若干具体权限，例如在 COST_MONEY 组中包含 android.permission.SEND_SMS ， android.permission.CALL_PHONE 等和费用相关的权限。

每个权限通过 protectionLevel 来标识保护级别： normal ， dangerous ， signature ， signatureorsystem 。不同的保护级别代表了程序要使用此权限时的认证方式。 normal 的权限只要申请了就可以使用； dangerous 的权限在安装时需要用户确认才可以使用； signature 和 signatureorsystem 的权限需要使用者的 app 和系统使用同一个数字证书。

Package 的权限信息主要 通过在 AndroidManifest.xml 中通过一些标签来指定。如 <permission> 标签， <permission-group> 标签 <permission-tree> 等标签。如果 package 需要申请使用某个权限，那么需要使用 <use-permission> 标签来指定。

2 Android permission 管理机制

2.1 Framework permission 机制

2.1.1 安装入口

permission 的初始化，是指 permission 的向系统申请，系统进行检测并授权，并建立相应的数据结构。绝大多数的情况下 permission 都是从一个 package 中扫描所得，而这发生在 package 安装和升级的时候。一般有如下几种 安装入口：

n packageInstaller ， package 被下载安装时会触发使用。 packageInstaller 会通过 AppSecurityPermissions 来检查 dangerous 的权限，并对用户给出提示。

n pm 命令 。

n adb install 。最终还是 调用 pm install 来安装 apk 包。

n 拷贝即安装。 PackageManagerService 中使用 AppDirObserver 对 /data/app/ 进行监视 ，如果有拷贝即触发安装。

这些安装方式 最终都会通过调用 PackageManagerService 中的函数来完成程序的安装。

2.1.2 permission 创建

第一步，从 AndroidManifest.xml 中提取 permission 信息。主要提取如下信息：

² shared uid

指定与其它 package 共享同一个 uid 。

² permission

提取 permissions 标签指定属性。它使用 permissionInfo 来描述一个权限的基本信息。需要指定 protectedLevel 信息，并指定所属 group 信息。它将被添加到这个 package 的 permissions 这个 list 结构中。

² permission-tree

提取 permissions-tree 标签属性。 permissions-tree 也通过 permissionInfo 来描述，并被添加到 package 的 permissions 这个 list 结构中。 permission-tree 只是一个名字空间，用来向其中动态添加一些所谓 Dynamic 的 permission ，这些 permission 可以动态修改。这些 permission 名称要以 permission-tree 的名称开头。它本身不是一种权限，没有 protectedLevel 和所属 group 。只是保存了所属的 packge 和权限名（带有 package 前缀的）。

² permission-group

定义 permission 组信息，用 PermissionGroup 表示。本身不代表一个权限，会添加进入 package 的 permissionGroups 这个 list 中。

² uses-permission

定义了 package 需要申请的权限名。将权限名添加到 package 的 requestedPermissions 这个 list 中。

² adopt-permissions

将该标签指定的 name 存入 package 的 mAdoptPermissions 这个 list 中。 Name 指定了这个 package 需要从 name 指定的 package 进行权限领养。在 system package 进行升级时使用。

第二步。获取 Package 中的证书，验证，并将签名信息保存在 Package 结构中。

1. 如果该 package 来自 system img （系统 app ），那么只需要从该 Package 的 AndroidManifest.xml 中获取签名信息，而无需验证其完整性。但是如果这个 package 与其它 package 共享一个 uid ，那么这个共享 uid 对应的 sharedUser 中保存的签名与之不一致，那么签名验证失败。

2. 如果是普通的 package ，那么需要提取证书和签名信息，并对文件的完成性进行验证。

第三步。如果是普通的 package ，那么清除 package 的 mAdoptPermissions 字段信息（系统 package 升级才使用）。

第四步。如果在 AndroidManifest.xml 中指定了 shared user ，那么先查看全局 list 中（ mSharedUsers ）是否该 uid 对应的 SharedUserSetting 数据结构，若没有则新分配一个 uid ，创建 SharedUserSetting 并保存到全局全局 list （ mSharedUsers ）中。

mUserIds 保存了系统中已经分配的 uid 对应的 SharedUserSetting 结构。每次分配时总是从第一个开始轮询，找到第一个空闲的位置 i ，然后加上 FIRST_APPLICATION_UID 即可。

第五步。创建 PackageSettings 数据结构。并将 PackageSettings 与 SharedUserSetting 进行绑定。其中 PackageSettings 保存了 SharedUserSetting 结构；而 SharedUserSetting 中会使用 PackageSettings 中的签名信息填充自己内部的签名信息，并将 PackageSettings 添加到一个队列中，表示 PackageSettings 为其中的共享者之一。

在创建时，首先会以 packageName 去全局数据结构 mPackages 中查询是否已经有对应的 PackageSettings 数据结构存在。如果已经存在 PackageSettings 数据结构（比如这个 package 已经被 uninstall ，但是还没有删除数据，此时 package 结构已经被释放）。那么比较该 package 中的签名信息（从 AndroidManifest 中扫描得到）与 PackageSettings 中的签名信息是否匹配。如果不匹配但是为 system package ，那么信任此 package ，并将 package 中的签名信息更新到已有的 PackageSettings 中去，同时如果这个 package 与其它 package 共享了 uid ，而且 shared uid 中保存的签名信息与当前 package 不符，那么签名也验证失败。

第六步。如果 mAdoptPermissions 字段不为空，那么处理 permission 的领养（从指定的 package 对应的 PackageSettings 中，将权限的拥有者修改为当前 package ，一般在 system app 升级的时候才发生，在此之前需要验证当被领养的 package 已经被卸载，即检查 package 数据结构是否存在）。

第七步。添加自定义权限。将 package 中定义的 permissionGroup 添加到全局的列表 mPermissionGroups 中去；将 package 中定义的 permissions 添加到全局的列表中去（如果是 permission-tree 类型，那么添加到 mSettings.mPermissionTrees ，如果是一般的 permission 添加到 mSettings.mPermissions 中）。

第八步。清除不一致的 permission 信息。

1. 清除不一致的 permission-tree 信息。如果该 permission-tree 的 packageSettings 字段为空，说明还未对该 package 进行过解析（若代码执行到此处时 packageSettings 肯定已经被创建过），将其 remove 掉。如果 packageSettings 不为空，但是对应的 package 数据结构为空（说明该 package 已经被卸载，但数据还有保留），或者 package 数据结构中根本不含有这个 permission-tree ，那么将这个 permission-tree 清除。

2. 清除不一致的 permission 信息。如果 packageSettings 或者 package 结构为空（未解析该 package 或者被卸载，但数据有保留），或者 package 中根本没有定义该 permission ，那么将该 permission 清除。

第九步。对每一个 package 进行轮询，并进行 permission 授权。

1. 对申请的权限进行检查，并更新 grantedPermissions 列表

2. 如果其没有设置 shared user id ，那么将其 gids 初始化为 mGlobalGids ，它从 permission.xml 中读取。

3. 遍历所有申请的权限，进行如下检查

1 ）如果是该权限是 normal 或者 dangerous 的。通过检查。

2 ）如果权限需要签名验证。如果签名验证通过。还需要进行如下检查

* 如果程序升级，而且是 system package 。那么是否授予该权限要看原来的 package 是否被授予了该权限。如果被授予了，那么通过检查，否则不通过。

* 如果是新安装的。那么检查通过。

4. 如果 3 中检查通过，那么将这个 permission 添加到 package 的 grantedPermissions 列表中，表示这个 permission 申请成功（ granted ）。申请成功的同时会将这个申请到的 permission 的 gids 添加到这个 package 的 gids 中去。

5. 将 permissionsFixed 字段标准为 ture ，表示这个 packge 的 permission 进行过修正。后续将禁止对非 system 的 app 的权限进行再次修正。

2.1.3 Dynamic permission 的管理

PackageManagerService 提供了 addPermission/ removePermission 接口用来动态添加和删除一些权限。但是这些权限必须是所谓的动态权限（ BasePermission.TYPE_DYNAMIC ）。

一个 Package 如果要添加 Dynamic permissions ，首先必须要在 manifest 中申明 <permission-tree> 标签，它实际上是一个权限的名字空间（例如，“ com.foo.far ”这个权限就是 permission-tree “com.foo ”的成员），本身不是一个权限。一个 Package 只能为自己的 permission-tree 或者拥有相同的 uid 的 package 添加或者删除权限。

Package 不能够通过这种接口去修改在 manifest 中静态申请的权限，否则抛出异常。

首先查找这个 permission 在全局 permission 列表 mSettings.mPermissions 中是否存在。如果存在，而且类型为 BasePermission.TYPE_DYNAMIC 那么根据传入的权限信息修改全局表中的权限信息，并触发 permissions.xml 的持久化。

如果在全局的 permission 列表 mSettings.mPermissions 中没有找到，先找到这个 permission 所在 permissionTree ，然后添加到全局 permission 列表 mSettings.mPermissions 中去，并触发 permissions.xml 的持久化。

2.1.4 Uri permission 的管理

下面两个 接口 主要用于 Uri permission 的管理 （其实现在 ActivityManagerService 中）。

// 为指定的 uid 和 targetPkg 添加对某个 content Uri 的读或者写权限。

public void grantUriPermission(IApplicationThread caller, String targetPkg, Uri uri, int mode) throws RemoteException;

// 清除所有通过 grantUriPermission 对某个 Uri 授予的权限。

public void revokeUriPermission(IApplicationThread caller, Uri uri, int mode) throws RemoteException;

grantUriPermission 主要的实现过程分析。

grantUriPermission 分析：

1. 验证 caller 的 ProcessRecord 和 targetPkg 不为空。否则检测不通过。

2. 验证所请求的 mode 为 Intent.FLAG_GRANT_READ_URI_PERMISSION 或者为 Intent.FLAG_GRANT_WRITE_URI_PERMISSION ，否则不通过。

3. 确保参数 Uri 是一个 content Uri 。否则，则检测不通过。

4. 通过 Uri 得到目标 ContentProvider ，如果不存在，则检测不通过。

5. 从 PackageManagerService 中获得 targetPkg 对应的 uid 。

6. 检查 target uid 所对应的 package 是否真正需要这个权限？

先判断要申请的是读还是写权限，然后查看对应的 ContentProvider 中对应的 readPermission writePermission 字段是否保存了权限名称。 如果该字段不为空，则以 target uid 和该权限名去PackageManagerService 中去查找该 uid 是否被 granted 了该权限。如果已经获得了该权限，那么无需再去为这个 Activity 去申请这个 Uri 权限了，返回。否者继续执行如下操作。

7. 检查这个 ContentProvider 的 grantUriPermissions 开关变量，是否允许对其它 package 进行权限的 grant 操作。如果禁止，那么抛出异常。

8. 检查这个 ContentProvider 是否设置了 Uri 的过滤类型 uriPermissionPatterns ，如果设置了过滤类型，则将需要申请权限的 Uri 与之匹配。匹配不同过，则抛出异常。

9. 检查调用者自己是否有权限访问这个 Uri 。如果没有，抛出异常。

10. 从 mGrantedUriPermissions 中取得 target uid 对应的 HashMap<Uri, UriPermission> 数据结构。用 target uid 和 Uri 生成 UriPermission 并保存在 mGrantedUriPermissions 中。

revokeUriPermission 实现分析。

找到该 Uri 对应的 ContentProvider ，然后删除 mGrantedUriPermissions 中与 Uri 对应的所有权限。

2.2 permission 的动态检查

这里的动态检查是指是 package 在程序运行过程中进行某些操作或者数据访问时才进行的 check ，与之对应的是应用程序安装或者升级时 PackageManagerService 通过扫描包中的静态权限信息相对应。

系统与权限 检查 相关的机制的实现主要集中在 PackageManagerService 和 ActivityManagerService 中。 ActivityManagerService 主要负责的是底层的 uid 层次的身份检查； PackageManagerService 则维护了 uid 到自己拥有的和被授予的权限的一张表。在通过 ActivityManagerService 的身份检查后， PackageManagerService 根据请求者的 uid 来查看这张表，判断其是否具有相应的权限。

除此之外， per-URI permission 机制的实现也需要一张表，它维护在 ActivityManagerService 中，它建立了从 content URI 到被授权访问这个 URI 的 component 之间的映射。但是它也需要借助 PackageManagerService 的机制来辅助实现。

2.2.1 framework 提供的接口

Android framework 中提供了一些接口用来对外来的访问（包括自己）进行权限检查 。 这些接口 主要通过 ContextWrapper 提供，具体实现在 ContextImpl 中 。如果 package 接受到外来访问者的操作请求，那么可以调用这些接口进行权限检查。一般情况下可以把这些接口的检查接口分为两种，一种是返回错误，另一种是抛出异常。

主要包含如下几组：

n permission 和 uid 检查 API

下面这一组接口主要用来检查某个调用（或者是其它 package 或者是自己）是否拥有访问某个 permission 的权限。参数中 pid 和 uid 可以指定，如果没有指定，那么 framework 会通过 Binder 来获取调用者的 uid 和 pid 信息，加以填充。返回值为 PackageManager.PERMISSION_GRANTED 或者 PackageManager.PERMISSION_DENIED 。

public int checkPermission(String permission, int pid, int uid) // 检查某个 uid 和 pid 是否有 permission 权限

public int checkCallingPermission(String permission) // 检查调用者是否有 permission 权限，如果调用者是自己那么返回 PackageManager.PERMISSION_DENIED

public int checkCallingOrSelfPermission(String permission) // 检查自己或者其它调用者是否有 permission 权限

下面这一组和上面类似，如果遇到检查不通过时，会抛出异常，打印消息 。

public void enforcePermission(String permission, int pid, int uid, String message)

public void enforceCallingPermission(String permission, String message)

public void enforceCallingOrSelfPermission(String permission, String message)

n per-URI 检查 API

为某个 package 添加访问 content Uri 的读或者写权限。

public void grantUriPermission(String toPackage, Uri uri, int modeFlags)

public void revokeUriPermission(Uri uri, int modeFlags)

检查某个 pid 和 uid 的 package 是否拥有 uri 的读写权限，返回值表示是否被 granted 。

public int checkUriPermission(Uri uri, int pid, int uid, int modeFlags)

public int checkCallingUriPermission(Uri uri, int modeFlags)

public int checkCallingOrSelfUriPermission(Uri uri, int modeFlags)

public int checkUriPermission(Uri uri, String readPermission,String writePermission, int pid, int uid, int modeFlags)

检查某个 pid 和 uid 的 package 是否拥有 uri 的读写权限，如果失败则抛出异常，打印消息 。

public void enforceUriPermission(Uri uri, int pid, int uid, int modeFlags, String message)

public void enforceCallingUriPermission(Uri uri, int modeFlags, String message)

public void enforceCallingOrSelfUriPermission(Uri uri, int modeFlags, String message)

public void enforceUriPermission(Uri uri, String readPermission, String writePermission,int pid, int uid, int modeFlags, String message)

2.2.2 实现分析

ContextImpl.java 中提供的 API ，其实都是由 ActivityManagerService 中的如下几个接口进行的封装。

public int checkPermission(String permission, int pid, int uid) throws RemoteException; // 主要用于一般的 permission 检查

public int checkUriPermission(Uri uri, int pid, int uid, int mode) throws RemoteException; // 主要用于 Content Uri 的 permission 检查

n checkPermission 的实现分析

1. 如果传入的 permission 名称为 null ，那么返回 PackageManager.PERMISSION_DENIED 。

2. 判断调用者 uid 是否符合要求 。

1 ） 如果 uid 为 0 ，说明是 root 权限的进程，对权限不作控制。

2 ） 如果 uid 为 system server 进程的 uid ，说明是 system server ，对权限不作控制。

3 ） 如果是 ActivityManager 进程本身，对权限不作控制。

4 ）如果调用者 uid 与参数传入的 req uid 不一致，那么返回 PackageManager.PERMISSION_DENIED 。

3. 如果通过 2 的检查后，再 调用 PackageManagerService.checkUidPermission ，判断 这个 uid 是否拥有相应的权限，分析如下 。

1 ） 首先它通过调用 getUserIdLP ，去 PackageManagerService.Setting.mUserIds 数组中，根据 uid 查找 uid （也就是 package ）的权限列表。一旦找到，就表示有相应的权限。

2 ） 如果没有找到，那么再去 PackageManagerService.mSystemPermissions 中找。这些信息是启动时，从 /system/etc/permissions/platform.xml 中读取的。这里记录了一些系统级的应用的 uid 对应的 permission 。

3 ）返回结果 。

n 同样 checkUriPermission 的实现 主要在 ActivityManagerService 中，分析如下：

1. 如果 uid 为 0 ，说明是 root 用户，那么不控制权限。

2. 否则，在 ActivityManagerService 维护的 mGrantedUriPermissions 这个表中查找这个 uid 是否含有这个权限，如果有再检查其请求的是读还是写权限。

3 Android 签名机制

关于签名机制，其实分两个阶段。

包扫描阶段需要进行完整性和证书的验证。普通 package 的签名和证书是必须要先经过验证的。具体做法是对 manifest 下面的几个文件进行完整性检查。完整性检查包括这个 jar 包中的所有文件。如果是系统 package 的话，只需要使用 AndroidMenifest.xml 这个文件去提取签名和验证信息就可以了。

在权限创建阶段。如果该 package 来自 system img （系统 app ），那么 trust it ，而且使用新的签名信息去替换就的信息。前提是如果这个 package 与其它 package 共享一个 uid ，那么这个共享 uid 对应的 sharedUser 中保存的签名与之不一致，那么签名验证失败。有些时候系卸载一个 app ，但是不删除数据，那么其 PackageSettings 信息会保留，其中会保存签名信息。这样再安装是就会出现不一致。

3.1 Android Package 签名原理

android 中系统和 app 都是需要签名的。可以自己通过 development/tools/make_key 来生成公钥和私钥。

android 源代码中提供了工具 ./out/host/linux-x86/framework/signapk.jar 来进行手动签名。签名的主要作用在于限制对于程序的修改仅限于同一来源。系统中主要有两个地方会检查。如果是程序升级的安装，则要检查新旧程序的签名证书是否一致，如果不一致则会安装失败；对于申请权限的 protectedlevel 为 signature 或者 signatureorsystem 的，会检查权限申请者和权限声明者的证书是否是一致的。签名相关文件可以从 apk 包中的 META-INF 目录下找到。

signapk.jar 的源代码在 build/tools/signapk ，签名主要有以下几步：

l 将除去 CERT.RSA ， CERT.SF ， MANIFEST.MF 的所有文件生成 SHA1 签名

首先将除了 CERT.RSA ， CERT.SF ， MANIFEST.MF 之外的所有非目录文件分别用 SHA-1 计算摘要信息，然后使用 base64 进行编码，存入 MANIFEST.MF 中。 如果 MANIFEST.MF 不存在，则需要创建。存放格式是 entry name 以及对应的摘要

l 根据 之前计算的 SHA1 摘要信息，以及 私钥生成 一系列的 signature 并写入 CERT.SF

对 整个 MANIFEST.MF 进行 SHA1 计算，并将摘要信息存入 CERT.SF 中 。然后对之前计算的所有摘要信息使用 SHA1 再次计算数字签名，并写入 CERT.SF 中。

l 把公钥和签名信息写入 CERT.RST

把之前整个的签名输出文件 使用私有密钥计算签名。同时将签名结果，以及之前声称的公钥信息写入 CERT.RSA 中保存。

3.2 Package 的签名验证

安装时对一个 package 的签名验证的主要逻辑在 JarVerifier.java 文件的 verifyCertificate 函数中实现。 其主要的思路是通过提取 cert.rsa 中的证书和签名信息，获取签名算法等信息，然后按照之前对 apk 签名的方法进行计算，比较得到的签名和摘要信息与 apk 中保存的匹配。

第一步。提取证书信息，并对 cert.sf 进行完整性验证。

1. 先找到是否有 DSA 和 RSA 文件 ，如果找到则对其进行 decode ，然后读取其中的所有的证书列表（这些证书会被保存在 Package 信息中，供后续使用）。

2. 读取这个文件中的签名数据信息块列表，只取第一个签名数据块。读取其中的发布者和证书序列号。

3. 根据证书序列号，去匹配之前得到的所有证书，找到与之匹配的证书。

4. 从之前得到的签名数据块中读取签名算法和编码方式等信息

5. 读取 cert.sf 文件，并计算整个的签名，与数据块中的签名（编码格式的）进行比较，如果相同则完整性校验成功。

第二步。使用 cert.sf 中的摘要信息，验证 MANIFEST.MF 的完整性。

在 cert.sf 中提取 SHA1-Digest-Manifest 或者 SHA1-Digest 开头的签名 数据块 （ -Digest-Manifest 这个是整个 MANIFEST.MF 的摘要 信息，其它的是 jar 包中其它文件的摘要信息 ）， 并逐个对这些数据块 进行验证。验证的方法是，现将 cert.sf 看做是很多的 entries ，每个 entries 包含了一些基本信息，如这个 entry 中使用的摘要算法（ SHA1 等），对 jar 包中的哪个文件计算了摘要，摘要结果是什么。 处理时先找到每个摘要数据开中的文件信息，然后从 jar 包中读取，然后使用 -Digest 之前的摘要算法进行计算，如果计算结果与摘要数据块中保存的信息的相匹配，那么就完成验证。