Android Google官方文檔解析之——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 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.
　　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是一個分隔權限的操做系統,每個應用程序在一個獨特的系統標識(Linux 用戶ID和羣組ID)下運行。系統的部分也也被分隔成明顯的身份。Linux所以將應用程序彼此和系統相互孤立開來。

　　Android細粒度的安全特性經過"許可"機制提供,強制限制某一個進程能夠執行的特殊操做,每個URI權限授予給特別的數據片。

　　這個文檔描述了應用程序開發者如何使用Android提供的安全特性。更通常的Android安全綜述在Android開源項目中提供。

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.
　　應用程序砂箱並不依賴於用於構造一個 應用程序的技術。尤爲是Dalik虛擬機不是一個安全邊界,任何應用均可以運行本地代碼(請查看Andorid NDK).全部應用程序的類型-Java型,本地型,混合型-一樣的都是砂箱的,彼此之間都有相同的安全程度。

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.
　　全部的APKs(.apk文件)必須用一個由開發者私有的祕鑰所對應的證書所簽名。這個證書定義了應用程序的做者。證書並不須要被認證受權中心簽名;它是爲Android應用程序完美典型的自簽名受權。在Android中證書的做用是區分應用程序做者。這容許系統授予或拒絕應用程序訪問簽名等級許可還有授予或取消一個應用程序的請求被做爲其餘應用程序賦予相同的Linux身份。

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 AndroidManifest.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.
　　由於安全實施發生在進程級別上,任意兩個包的代碼須要做爲不一樣的Linux用戶運行,因此他們不能正常的在同一個進程中運行。你能夠在每一個包的AndroidManifest.xml的「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, SQLiteDatabase.CursorFactory), 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, SQLiteDatabase.CursorFactory)方法,你可使用」MODE_WORLD_READABLE「或者「MODE_WORLD_WRITEABLE」標籤來運行任何其餘包來讀寫這個文件。當設置那些標籤的時候,文件仍然被你的應用程序擁有,可是他的全局讀寫權限已經被設置成全局適用的,因此對其餘應用程序來講都是可見的。

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 AndroidManifest.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:
　　一個基礎Android應用程序沒有默認的關聯權限,意圖是不能作任何對用戶體驗或是設備上的數據產生不利的影響的事。利用設備的受保護的特性,你必須在你的AndroidManifest.xml文件中包含一個或更多的<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>

　　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.
　　終於一個許可失敗將會致使一個」SecurityExcepton「異常被返回給應用程序。然而,這也不能被保證在每一處都會發生。例如」sendBroadcast(Intent)「方法檢查權限由於數據將被分發到每個接收者,在方法調用返回後,若是權限請求失敗你將不會接收到一個異常信息。然而,在大部分狀況下一個請求權限失敗的信息將會在系統日誌中打印出來。
　　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.

　　然而,在一個正常的用戶狀況下(好比說當app是從Google Play Store中安裝的),一個app如何用戶沒有授予這個app的每一項請求的權限將不能被安裝。因此你通常來講沒必要要擔憂由缺乏權限引發的運行時失敗由於單純的事實是若是你的應用被安裝成功那麼意味着你的app已經被授予了它須要的權限。
　　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.
　　權限被Android系統提供,它能在」Manifest.permission「中找到。任意的應用程序也能定義而後強制它本身的權限,因此這裏沒有一個綜合性全部可能的權限列表。

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.

特定的權限能夠被執行在你的程序操做的任何一個地方:

• 在調用進系統的時候,阻止應用程序執行某些功能。
• 當啓動一個Activity的時候,阻止應用程序啓動其餘程序的Activity。
• 發送和接收廣播通知的時候,控制誰能接收到你的廣播或是誰能給你發送廣播。
• 當訪問和操做某個content provider的時候
• 綁定或是開啓一個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.
　　警告:超時,新的限制條件可能要被添加到平臺中這樣,爲了用肯定的APIs,你的app必須請求一個以前並無的權限。由於目前app假定訪問那些APIs是自由可用的,Android或許會爲了不破壞新平臺版本的app,給app的清單申請新的權限請求。Android作出決定一個app是否須要權限,基於提供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 level 4的時候限制訪問共享存儲空間。若是你的targetSdkVersion是3或是更低,這個權限在較新的Android版本中會被添加進你的app中。
　　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.
　　注意若是這發生在你的app上,你在Google Play中的app列表將會顯示那些所須要的權限,即使你的應用也許實際上沒有須要。
　　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 Build.VERSION_CODES documentation.
　　爲避免這些發生,刪掉默認你不須要的權限,老是儘量更新你的targetSdkVersion爲最新的版本.你能夠在Build.VERSION_CODES文檔中查看每次發佈的時候有哪些權限被添加。

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:
　　爲了施行你本身的權限,你必須一開始就在你的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>

　　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.

　　<protectionLevel>屬性是必須的,它告訴系統用戶如何知道須要這個權限,或者誰被容許擁有這個權限,就像這個連接文檔中說的同樣。
<permissionGroup>屬性是可選的,只用於幫助系統給用戶展現權限信息。你將一般把這個這隻成一個標準的系統羣組組(在android.Manifest.permission_group中列出的)或是少見的一個你本身定義的羣組。更寧願使用一個已經存在的羣組,做爲給用戶展現的權限UI的簡化。
　　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:
　　既然一個標籤和描述應該提供給權限。當被以列表形式展現時,權限信息(android:label)或是一個簡單權限的詳細信息(android:description)會有字符串資源展現給用戶。標籤應該很短只有不多的描述字,幾句話就描述了功能,權限是受保護的。描述應該是一段話描述了權限容許持有者能作什麼。咱們的對描述的約定是兩句話,第一句描述權限,第二句警示使用者若是應用程序被授予了該權限會有聲明很差的事情發生。
　　這裏有一個CALL_PHONE權限的標籤和描述的例子:

<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:
　　你能夠經過你的app設置還有adb shell命令行的pm命令列出權限列表的方式來查看當前系統定義的權限。使用app設置,進入Setting->Application。選擇一個應用向下滑來查看這個應用使用的權限。對於開發者來講,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

...

 

Enforcing Permissions in AndroidManifest.xml在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.
　　高等級的權限約束進入系統的所有組件或是能夠經過AndroidManifest.xml文件實施的應用程序。這所須要的是在所須要的組件上包含一個」android:permission「屬性,給權限命名將被用於控制對其組件的訪問。
　　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.
　　Activity權限(適用於<activity>標籤)限制了誰能啓動所關聯的Activity。這個權限在」Context.startActivity()「還有」Activity.startActivityForResult()「期間檢查;若是調用者沒有須要的權限那麼SecurityException異常將從調用者返回。
　　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.
　　Service權限(適用於<service>標籤)限制了誰能啓動或是綁定到所關聯的service上。這個權限將會在Context.startService(),Context.stopService()還有Context.bindService()期間被檢查;若是調用者沒有須要的權限那麼SecurityException異常將從調用者返回。
　　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).
　　BroadcastReceiver權限(適用於<receiver>標籤)限制了誰能發送廣播到所關聯的接收者。這個權限將會在Conext.sendBroadcast()方法返回以後檢查,隨着系統嘗試分發提交的廣播給給定的接收者。結果,權限失敗將不會做爲一個異常結果返回給調用者;它將不只分發intent。一樣的,一個權限能被提供給Context.registerReceiver來控制誰能給以程序方式註冊的接受者發送廣播。另外一方面來講,一個權限能被提供,當調用Context.sendBroadcast()方法來限制哪個BroadcastReceiver對象容許接收廣播(見下文)。
　　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.
　　ContentProvider權限(適用於<provider>標籤)限制了誰能在ContentProvider中使用數據。(Conent providers 有一個很重要的額外安全設施,他們在URI Permission中可用將在後面提到。)不像其餘組件,有兩個你能夠設置的分隔開的組件屬性:」android:readPermission「限制誰可用從provider中讀數據,還有」android:writePermission「限制誰可用往provide中寫數據。既然若是一個provider提供讀和寫的權限保護,只有些權限並不意味着你能夠從provider中讀取數據。當你第一次檢索一個provider(若是你沒有其中任何一個權限,SecurityException異常將會被拋出)這個權限將會被檢查,隨着你在該provider中執行操做。使用ConentResolver.query()方法須要持有讀權限;使用ContentResolver.insert(),ConentResolver.update(),ConentResolver.delete()須要寫權限。在全部那些狀況下,沒有持有所需的權限調用者都會收到一個SecurityException異常。

Other Permission Enforcement 其餘的權限實施

　　Arbitrarily(武斷的,專橫的,反覆無常的) fine-grained permissions can be enforced at any call into a service. This is accomplished with the Context.checkCallingPermission() 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.
　　雜亂的細粒度權限能夠被執行在任意進入服務的調用。使用Conext.checkCallingPermission()方法是完美的。調用一個須要的權限字符串而後它會返回一個代表是否這個權限已經被當前調用進程過的整型值。注意這隻能當你在執行一個從其餘進程進入的調用時被使用,一般經過設備發佈的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 Context.checkPermission(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 PackageManager.checkPermission(String, String) to find out whether that particular package has been granted a specific permission.
　　還有一些有用的方法來檢查權限。若是你有其餘進程的pid,你能夠用Context的這個方法Context.checkPermission(String,int,int)來檢查那個進程的pid的權限。若是你有其餘應用程序的包名,你能夠直接用PackageManager的方法PackageManager.checkPermission(String,String)方法來找到是否獨特的包已經被授予了特定的權限。

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想要保護他本身經過讀寫權限,然而它的直接客戶也須要爲他們傳遞特殊的URIs到其餘的應用來操做。一個典型的例子是一個郵件應用程序中的附件。進入郵件應該被權限保護,由於有用戶的敏感數據。而後若是一個指向一個圖形附件的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 Intent.FLAG_GRANT_READ_URI_PERMISSION and/or Intent.FLAG_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.
　　解決這個問題的辦法是per-URI權限:當啓動一個Activity或是給一個Activity返回一個結果的時候,調用者能夠設置intent.FLAG_GRANT_READ_URI_PERMISSION或是Intent.FLAG_GRANT_WRITE_URI_PERMISSION。這授予接受Activity訪問intent中的特定數據URI的權限,不論是否有訪問content provider相對應的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 <grant-uri-permissions> tag.

　　More information can be found in the Context.grantUriPermission(), Context.revokeUriPermission(), and Context.checkUriPermission() methods. 　　細粒度的URI權限授予須要content provider持有那些URIs來的協做。強烈推薦content provider實現這些設施,而後經過"android:grantUriPermissions"標籤或是"<grant-uri-permission>"標籤訂義他們他們支持它。 　　更多信息能夠查看Context.grantUriPermission(), Context.revokeUriPermission(), 還有 Context.checkUriPermission()方法。