Android doc|Getting Started| Training部分 --翻譯 Working with System Permissions

Working with System Permissions

To protect the system’s integrity and the user’s privacy, Android runs each app in a limited access sandbox. If the app wants to use resources or information outside of its sandbox, the app has to explicitly request permission. Depending on the type of permission the app requests, the system may grant the permission automatically, or the system may ask the user to grant the permission.

This class shows you how to declare and request permissions for your app.

為了保護系統的完整性和用戶的隱私，Android系統將每個app運行在一個限制訪問的沙盒裡。如果app想要訪問他所在沙盒之外的信息或者資源，app需要明確申請權限。根據app申請的權限類型，系統也許會自動承認權限，或者系統會問用戶是否給予app該權限。

這節課將向你展示如何為你的app聲明和申請權限。

Declaring Permissions

Every Android app runs in a limited-access sandbox. If an app needs to use resources or information outside of its own sandbox, the app has to request the appropriate permission. You declare that your app needs a permission by listing the permission in the App Manifest.

Android系統將每個app運行在一個限制訪問的沙盒裡。如果app想要訪問他所在沙盒之外的信息或者資源，app需要明確申請權限。你可以在App Manifest文件列出需要的權限以聲明你的app所需要的權限。

Depending on how sensitive the permission is, the system might grant the permission automatically, or the device user might have to grant the request. For example, if your app requests permission to turn on the device’s flashlight, the system grants that permission automatically. But if your app needs to read the user’s contacts, the system asks the user to approve that permission. Depending on the platform version, the user grants the permission either when they install the app (on Android 5.1 and lower) or while running the app (on Android 6.0 and higher).

根據該權限的敏感度，系統也許會自動承認權限，或者系統會問用戶是否給予app該權限。比如，如果你申請打開設備的閃光燈，系統會自動允許。但是如果你需要讀取用戶的聯系人信息，系統會問用戶是否允許該權限。根據運行的Android版本，用戶也許會在他們安裝app時（Android5.1或者更低）或者在運行app時（Android6.0或者更高）批准權限。

Determine What Permissions Your App Needs

As you develop your app, you should note when your app is using capabilities that require a permission. Typically, an app is going to need permissions whenever it uses information or resources that the app doesn’t create, or performs actions that affect the behavior of the device or other apps. For example, if an app needs to access the internet, use the device camera, or turn Wi-Fi on or off, the app needs the appropriate permission. For a list of system permissions, see Normal and Dangerous Permissions.

當你開發你的app時，當你使用到需要許可的功能的時候，你應該多加留意。通常，一個app，不管何時它使用 app沒有創建的信息或者資源或者，使用後會影響設備或者其他app的動作此時它需要許可。例如，一個app需要訪問網絡，使用設備照相機或者打開或關閉WiFi，aoo需要恰當的許可。查看系統許可列表，詳見通常和危險級別的許可。

Your app only needs permissions for actions that it performs directly. Your app does not need permission if it is requesting that another app perform the task or provide the information. For example, if your app needs to read the user’s address book, the app needs the READ_CONTACTS permission. But if your app uses an intent to request information from the user’s Contacts app, your app does not need any permissions, but the Contacts app does need to have that permission. For more information, see Consider Using an Intent.

你的app只需要它直接執行的動作的許可。app如果是請求其他app執行任務或者提供信息，就不需要許可。比如，你的app需要讀取用戶的通訊錄，app需要READ_CONTACTS許可。但是如果你的app使用一個意圖去向用戶的聯系人app請求信息，那就不需要READ_CONTACTS許可。更多信息參考Consider Using an Intent.

Add Permissions to the Manifest

To declare that your app needs a permission, put a element in your app manifest, as a child of the top-level element. For example, an app that needs to send SMS messages would have this line in the manifest:

聲明你的app需要的權限，將 元素放在你的app清單文件，作為頂級 元素的子元素。比如，一個app需要發送信息的許可，清單文件應該有這幾行：

    


    
        ...
    

The system’s behavior after you declare a permission depends on how sensitive the permission is. If the permission does not affect user privacy, the system grants the permission automatically. If the permission might grant access to sensitive user information, the system asks the user to approve the request. For more information about the different kinds of permissions, see Normal and Dangerous Permissions.

根據該權限的敏感度，系統也許會自動承認權限，或者系統會問用戶是否給予app該權限。

Requesting Permissions at Run Time

Beginning in Android 6.0 (API level 23), users grant permissions to apps while the app is running, not when they install the app. This approach streamlines the app install process, since the user does not need to grant permissions when they install or update the app. It also gives the user more control over the app’s functionality; for example, a user could choose to give a camera app access to the camera but not to the device location. The user can revoke the permissions at any time, by going to the app’s Settings screen.

從Android6.0開始（API等級23），用戶會授予App許可在app運行的時候而不是安裝的時候。這優化了Android app的安裝流程，因為用戶不再需要在安裝或者升級app時授予app許可。這也給用戶更多的機會控制app的功能；比如，一個用戶可以給與一個app使用相機的許可而不給予定位的許可。進入app的設置界面。用戶可以隨時撤銷app的許可。

System permissions are divided into two categories, normal and dangerous:

系統許可分為2中，正常和危險級別：

Normal permissions do not directly risk the user’s privacy. If your

app lists a normal permission in its manifest, the system grants the

permission automatically.

Dangerous permissions can give the app access to the user’s

confidential data. If your app lists a normal permission in its

manifest, the system grants the permission automatically. If you list

a dangerous permission, the user has to explicitly give approval to

your app.

正常許可不會直接涉及用戶隱私。如果你的app清單文件列出了一個正常級別的許可，系統自動許可。

危險許可可能給予app訪問用戶機密數據的權限。如果你的app清單文件列出一個危險級別的許可，需要用戶明確給予app許可。

For more information, see Normal and Dangerous Permissions.

On all versions of Android, your app needs to declare both the normal and the dangerous permissions it needs in its app manifest, as described in Declaring Permissions. However, the effect of that declaration is different depending on the system version and your app’s target SDK level:

在Android的所有版本，不管是正常還是危險級別的許可，你的app都需要在清單文件列出，就如在Declaring Permissions中所描述的一樣。然而，你的定義根據不同的Android版本和SDK版本，效果可能不同。

If the device is running Android 5.1 or lower, or your app’s target

SDK is 22 or lower: If you list a dangerous permission in your

manifest, the user has to grant the permission when they install the

app; if they do not grant the permission, the system does not install

the app at all.

If the device is running Android 6.0 or higher, and your app’s target

SDK is 23 or higher: The app has to list the permissions in the

manifest, and it must request each dangerous permission it needs

while the app is running. The user can grant or deny each permission,

and the app can continue to run with limited capabilities even if the

user denies a permission request.

如果你的設備運行著Android5.1版本或者更低，或者你的app的目標SDK是22或者更低：如果你列出一個危險級別的許可，用戶必須在安裝app時授權；如果用戶不允許，系統就不會安裝app。

如果你的設備運行在Android6.0或者更高版本並且你的目標SDK是23或者更高：app需要在請單文件列出他的app許可，而且他每次運行時都會向用戶請求這個許可。用戶可以許可或者拒絕每個許可，app可以繼續以限制許可的方式運行即使用戶拒絕了一個許可請求。

Note: Beginning with Android 6.0 (API level 23), users can revoke permissions from any app at any time, even if the app targets a lower API level. You should test your app to verify that it behaves properly when it’s missing a needed permission, regardless of what API level your app targets.

注意：在Android6.0開始（API23），用戶可以隨時撤銷app的權限，即使app的目標版本是一個更低級別的API等級。不管你的目標API級別是多少，你都需要測試，保證你的app在缺失一些必須的許可也能正常運行。

This lesson describes how to use the Android Support Library to check for, and request, permissions. The Android framework provides similar methods as of Android 6.0 (API level 23). However, using the support library is simpler, since your app doesn’t need to check which version of Android it’s running on before calling the methods.

這節課描述如何使用Android支持類庫檢查和申請許可。Android框架在Android6.0（API23）提供相似的方法。然而，使用支持類庫更簡單，因為你的app在調用方法時不再需要檢查Android的版本。

Check For Permissions

If your app needs a dangerous permission, you must check whether you have that permission every time you perform an operation that requires that permission. The user is always free to revoke the permission, so even if the app used the camera yesterday, it can’t assume it still has that permission today.

如果你的app需要一個危險級別的許可，你每次執行一個需要那個許可的操作時都必須檢查你是否擁有那個許可。用戶可以自由撤銷app的許可，所以即使app昨天還可以使用攝像頭，今天它就不一定還能使用。

To check if you have a permission, call the ContextCompat.checkSelfPermission() method. For example, this snippet shows how to check if the activity has permission to write to the calendar:

為了確認你是否擁有這個許可，調用ContextCompat.checkSelfPermission() 方法。比如下面這個代碼片段展示了如何檢查一個Activity是否擁有權限改寫日歷。

// Assume 假定 this Activity is the current activity
int permissionCheck = ContextCompat.checkSelfPermission(thisActivity,
        Manifest.permission.WRITE_CALENDAR);

If the app has the permission, the method returns PackageManager.PERMISSION_GRANTED, and the app can proceed with the operation. If the app does not have the permission, the method returns PERMISSION_DENIED, and the app has to explicitly ask the user for permission.

如果app擁有權限，方法返回PackageManager.PERMISSION_GRANTED，app可以繼續執行操作。如果沒有許可，方法返回PERMISSION_DENIED，app必須明確問用戶申請這個許可。

Request Permissions

If your app needs a dangerous permission that was listed in the app manifest, it must ask the user to grant the permission. Android provides several methods you can use to request a permission. Calling these methods brings up a standard Android dialog, which you cannot customize.

如果你的app需要一個在app清單文件列出的危險級別的許可，它必須問用戶來許可這個權限。Android提供了幾種方法來申請權限。調用這些方法可以調出一個你無法定制的標准的Android對話框。

Explain why the app needs permissions

Figure 1. System dialog prompting the user to grant or deny a permission.

圖1.系統對話框，提示用戶許可或者拒絕一個權限。

In some circumstances, you might want to help the user understand why your app needs a permission. For example, if a user launches a photography app, the user probably won’t be surprised that the app asks for permission to use the camera, but the user might not understand why the app wants access to the user’s location or contacts. Before you request a permission, you should consider providing an explanation to the user. Keep in mind that you don’t want to overwhelm the user with explanations; if you provide too many explanations, the user might find the app frustrating and remove it.

在一些情況下，你可能想幫助用戶理解為什麼你的app需要一個許可。比如，如果一個用戶啟動一個攝影app，但是用戶也許不理解為什麼app需要訪問自己的地址或者聯系人。在你申請權限之前，你應該考慮提供一個解釋給用戶。記住不要用這些解釋淹沒用戶。如果你提供了過多的解釋，用戶會覺得你的app很令人懊惱，然後就刪了你的app。

One approach you might use is to provide an explanation only if the user has already turned down that permission request. If a user keeps trying to use functionality that requires a permission, but keeps turning down the permission request, that probably shows that the user doesn’t understand why the app needs the permission to provide that functionality. In a situation like that, it’s probably a good idea to show an explanation.

你可以使用的提供解釋的一個方法是在用戶已經拒絕了許可的時候。如果用戶仍然想要那個需要權限的功能但是卻拒絕授權，那也許是用戶沒有理解為什麼app需要這個許可。在這種情況下，也許你給用戶解釋一下是一個好時機。

To help find situations where the user might need an explanation, Android provides a utiltity method, shouldShowRequestPermissionRationale(). This method returns true if the app has requested this permission previously and the user denied the request.

為了幫助用戶在哪邊需要一個解釋，Android提供了一個實用方法，shouldShowRequestPermissionRationale()。如果app之前申請了這個權限並且用戶拒絕了這個請求，這個方法返回true

Note: If the user turned down the permission request in the past and chose the Don’t ask again option in the permission request system dialog, this method returns false. The method also returns false if a device policy prohibits the app from having that permission.

注意：如果用戶過去拒絕了許可並且在系統對話框選擇了“Don’t ask again”選項，方法會返回false。如果設備本身禁止app擁有這個許可，方法也會返回false。

Request the permissions you need

If your app doesn’t already have the permission it needs, the app must call one of the requestPermissions() methods to request the appropriate permissions. Your app passes the permissions it wants, and also an integer request code that you specify to identify this permission request. This method functions asynchronously: it returns right away, and after the user responds to the dialog box, the system calls the app’s callback method with the results, passing the same request code that the app passed to requestPermissions().

如果你的app還沒有它需要的許可，app必須調用一個requestPermissions()方法以申請適當的許可。你的app除了需要傳遞它所需要的申請的許可之外，還需要有一個標志申請的integer值。這個方法是異步的：他會立刻返回，之後用戶響應那個請求許可的對話框時，系統會使用之前調用 requestPermissions()傳的integer值來調用app的回調方法。

The following code checks if the app has permission to read the user’s contacts, and requests the permission if necessary:

下面的代碼檢查是否app擁有讀取用戶聯系人的許可，如果需要會申請許可：

// Here, thisActivity is the current activity
if (ContextCompat.checkSelfPermission(thisActivity,
                Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {

    // Should we show an explanation?
    if (ActivityCompat.shouldShowRequestPermissionRationale(thisActivity,
            Manifest.permission.READ_CONTACTS)) {

        // Show an expanation to the user *asynchronously* -- don't block
        // this thread waiting for the user's response! After the user
        // sees the explanation, try again to request the permission.

    } else {

        // No explanation needed, we can request the permission.

        ActivityCompat.requestPermissions(thisActivity,
                new String[]{Manifest.permission.READ_CONTACTS},
                MY_PERMISSIONS_REQUEST_READ_CONTACTS);

        // MY_PERMISSIONS_REQUEST_READ_CONTACTS is an
        // app-defined int constant. The callback method gets the
        // result of the request.
    }
}

Note: When your app calls requestPermissions(), the system shows a standard dialog box to the user. Your app cannot configure or alter that dialog box. If you need to provide any information or explanation to the user, you should do that before you call requestPermissions(), as described in Explain why the app needs permissions.

注意：當你調用requestPermissions時，系統會展現一個標准的Android對話框給用戶。這個對話框，你無法做任何修改。如果你想給用戶一些解釋，需要在調用requestPermissions之前做，正如在前面的一節：Explain why the app needs permissions中解釋的一樣。

Handle the permissions request response

When your app requests permissions, the system presents a dialog box to the user. When the user responds, the system invokes your app’s onRequestPermissionsResult() method, passing it the user response. Your app has to override that method to find out whether the permission was granted. The callback is passed the same request code you passed to requestPermissions(). For example, if an app requests READ_CONTACTS access it might have the following callback method:

當你的app申請權限時，系統會向用戶顯示一個對話框。當用戶響應完畢，系統調用你app的onRequestPermissionsResult回調方法，並將用戶的回應傳遞進去。你的app必須重寫這個方法以確定用戶到底有沒有准許這個許可。回調方法會使用你之前調用requestPermissions()申請許可時的那個integer值。比如，如果app申請READ_CONTACTS權限，他或許會有下面的回調方法。

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_PERMISSIONS_REQUEST_READ_CONTACTS: {
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

                // permission was granted, yay! Do the
                // contacts-related task you need to do.

            } else {

                // permission denied, boo! Disable the
                // functionality that depends on this permission.
            }
            return;
        }

        // other 'case' lines to check for other
        // permissions this app might request
    }
}

The dialog box shown by the system describes the permission group your app needs access to; it does not list the specific permission. For example, if you request the READ_CONTACTS permission, the system dialog box just says your app needs access to the device’s contacts. The user only needs to grant permission once for each permission group. If your app requests any other permissions in that group (that are listed in your app manifest), the system automatically grants them. When you request the permission, the system calls your onRequestPermissionsResult() callback method and passes PERMISSION_GRANTED, the same way it would if the user had explicitly granted your request through the system dialog box.

系統顯示的對話框描述了你的app需要的權限組；他不會列出什麼特別的權限。比如，如果你申請READ_CONTACTS權限，系統對話框僅僅說你的app需要訪問用戶的聯系人。對於同一個權限組用戶只需要批准一次。如果你的app申請了這個許可組中其他的許可（比如在清單文件中列舉的），系統會自動批准。當你申請這個權限時，系統會調用你的onRequestPermissionsResult並傳入PERMISSION_GRANTED，方式跟你通過系統對話框來申請許可是一樣的。

Note: Your app still needs to explicitly request every permission it needs, even if the user has already granted another permission in the same group. In addition, the grouping of permissions into groups may change in future Android releases. Your code should not rely on the assumption that particular permissions are or are not in the same group.

注意：你的app仍然需要明確的申請他需要的每一個許可，即使用戶可能已經在app申請同一個權限組時批准了這個許可。另外，許可的分組可能會在將來的Android版本中改變。你的代碼不應該去猜測某些權限應該在或不在同一個分組中。

For example, suppose you list both READ_CONTACTS and WRITE_CONTACTS in your app manifest. If you request READ_CONTACTS and the user grants the permission, and you then request WRITE_CONTACTS, the system immediately grants you that permission without interacting with the user.

比如，假設你申請了 READ_CONTACTS 和WRITE_CONTACTS的許可。如果申請READ_CONTACTS已經被批准了，那麼系統會自動許可WRITE_CONTACTS權限，而不會打擾用戶。

If the user denies a permission request, your app should take appropriate action. For example, your app might show a dialog explaining why it could not perform the user’s requested action that needs that permission.

如果用戶拒絕了許可，你的app應該做出恰當的行為。比如，你的app也許會向用戶解釋的需要權限的理由。

When the system asks the user to grant a permission, the user has the option of telling the system not to ask for that permission again. In that case, any time an app uses requestPermissions() to ask for that permission again, the system immediately denies the request. The system calls your onRequestPermissionsResult() callback method and passes PERMISSION_DENIED, the same way it would if the user had explicitly rejected your request again. This means that when you call requestPermissions(), you cannot assume that any direct interaction with the user has taken place.

當系統問用戶去確認是否批准權限時，用戶可以選擇是否下次不再詢問是否批准此權限。在那種情況下，任何時候app調用requestPermissions來申請許可時，系統直接拒絕。系統調用onRequestPermissionsResult並傳入PERMISSION_DENIED，就跟用戶明確拒絕許可一樣。這意味著當你調用requestPermissions時，你並不能和用戶直接交互。

Permissions Best Practices

It’s easy for an app to overwhelm a user with permission requests. If a user finds the app frustrating to use, or the user is worried about what the app might be doing with the user’s information, they may avoid using the app or uninstall it entirely. The following best practices can help you avoid such bad user experiences.

對於一個app來說，權限申請很容易惹惱用戶。如果一個用戶發現一個app用起來很煩人，或者用戶擔心app會對自己的信息做什麼，他們也許會避免使用app或者直接整個刪除app。下面的這些練習可以幫你避免這些差勁的用戶體驗。

Consider Using an Intent

In many cases, you can choose between two ways for your app to perform a task. You can have your app ask for permission to perform the operation itself. Alternatively, you can have the app use an intent to have another app perform the task.

在很多情況下，你可以有兩種方式來執行一個任務。你可以讓你自己的app來執行這個操作，或者，你可以讓app使用一個Intent去打開另一個app，讓另外的app執行這個任務。

For example, suppose your app needs to be able to take pictures with the device camera. Your app can request the CAMERA permission, which allows your app to access the camera directly. Your app would then use the camera APIs to control the camera and take a picture. This approach gives your app full control over the photography process, and lets you incorporate the camera UI into your app.

比如，假設你的app需要能夠使用設備的攝像頭拍照。你的app可以申請CAMERA 權限，這樣直接可以讓你的app有權限拍照。你的app之後可以用camera的API來控制攝像頭拍照。這個方法讓你的app完全控制拍照過程，並且讓你把拍照的UI界面包含進你的app。

However, if you don’t need such complete control, you can use an ACTION_IMAGE_CAPTURE intent to request an image. When you send the intent, the system prompts the user to choose a camera app (if there isn’t already a default camera app). The user takes a picture with the selected camera app, and that app returns the picture to your app’s onActivityResult() method.

然而，如果你不需要完全的控制，你可以使用一個 ACTION_IMAGE_CAPTURE的意圖去申請一個圖片。當你發送這個意圖，系統會提示用戶選擇一個照相的app（如果還沒有一個默認的照相app）。用戶會用選擇的app拍張照片，那個拍照app通過onActivityResult()方法返回照片。

Similarly, if you need to make a phone call, access the user’s contacts, and so on, you can do that by creating an appropriate intent, or you can request the permission and access the appropriate objects directly. There are advantages and disadvantages to each approach.

相似的，如果你需要打電話，訪問用戶的通訊錄或者其他什麼權限，你可以通過創建一個恰當的意圖來實現，或者你可以直接請求許可，並直接得到相應的對象。這兩種方法都有利有弊。

If you use permissions:

如果你使用權限：

Your app has full control over the user experience when you perform the operation. However, such broad control adds to the complexity of your task, since you need to design an appropriate UI.

The user is prompted to give permission once, either at run time or at install time (depending on the user’s Android version). After that, your app can perform the operation without requiring additional interaction from the user. However, if the user doesn’t grant the permission (or revokes it later on), your app becomes unable to perform the operation at all.

當你執行操作時你的app可以完全控制用戶行為。然而，這個完全的控制是你的任務復雜化，因為你需要設計合適的UI。用戶可能在運行app時或者安裝時（依賴用戶的Android版本） 被提示來給予權限 。在那之後，如果用戶不授予權限（或者之後收回權限），你的app就會完全無法執行那個操作。

If you use an intent:

如果你使用意圖：

You do not have to design the UI for the operation. The app that handles the intent provides the UI. However, this means you have no control over the user experience. The user could be interacting with an app you’ve never seen.

你不需要為那個動作設計UI。處理你發送來的意圖的app會提供UI。然而，這意味著你不能控制用戶的操作。用戶可能與一個你從來不知道的app交互。

If the user does not have a default app for the operation, the system prompts the user to choose an app. If the user does not designate a default handler, they may have to go through an extra dialog every time they perform the operation.

如果用戶沒有默認的app去執行那個操作，系統會提示用戶去選擇一個app。如果用戶沒有指定一個默認的handler，這就需要每天都通過一個對話框來執行那個操作。

Only Ask for Permissions You Need

Every time you ask for a permission, you force the user to make a decision. You should minimize the number of times you make these requests. If the user is running Android 6.0 (API level 23) or later, every time the user tries some new app feature that requires a permission, the app has to interrupt the user’s work with a permission request. If the user is running an earlier version of Android, the user has to grant every one of the app’s permissions when installing the app; if the list is too long or seems inappropriate, the user may decide not to install your app at all. For these reasons, you should minimize the number of permissions your app needs.

每次你申請一個權限，你強制用戶去做一個決定。你應該讓這種情況發生次數最小化。如果用戶使用的Android版本是6.0（API23）或者更新的版本，每次用戶嘗試一下新的需要權限的app功能，app需要打斷用戶的操作來進行權限許可請求。如果用戶用的是低於6.0的版本，用戶安裝時需要許可這些權限；如果用戶發現這個許可的list很長或者看起來不合適，用戶可能覺得不會安裝app。因為這些原因，你應該將你的權限申請數最小化。

Quite often your app can avoid requesting a permission by using an intent instead. If a feature is not a core part of your app’s functionality, you should consider handing the work over to another app, as described in Consider Using An Intent.

你可以避免直接請求權限，而通過發送一個intent的情況是相當常見的。如果一個功能並非你的app功能的核心部分，你應該考慮在其他app處理這個工作，正如在Consider Using An Intent一節所述。

Don’t Overwhelm the User

If the user is running Android 6.0 (API level 23) or later, the user has to grant your app its permissions while they are running the app. If you confront the user with a lot of requests for permissions at once, you may overwhelm the user and cause them to quit your app. Instead, you should ask for permissions as you need them.

如果用戶的版本是Android6.0或者之後的，用戶需要在app運行時批准權限。如果你讓用戶一下子面對許多的請求，你可能惹怒用戶，導致他們卸載你的app。取而代之，你應該在你需要權限的時候在請求權限。

In some cases, one or more permissions might be absolutely essential to your app. It might make sense to ask for all of those permissions as soon as the app launches. For example, if you make a photography app, the app would need access to the device camera. When the user launches the app for the first time, they won’t be surprised to be asked for permission to use the camera. But if the same app also had a feature to share photos with the user’s contacts, you probably should not ask for the READ_CONTACTS permission at first launch. Instead, wait until the user tries to use the “sharing” feature and ask for the permission then.

在一些情況下，一個或多個權限可能對你的app相當重要。此時在app一運行起來就問用戶批准這些權限可能說得通。比如，如果你在做一個攝影app，app可能需要使用攝像頭的權限。當用戶第一次運行app時，當被要求來許可照相機權限時他們不會感到意外。但是如果同一個app，有一個分享照片給用戶聯系人的功能，你也許不應該在第一次運行時就問用戶申請READ_CONTACTS 權限。相反的，直到用戶嘗試使用“分享”功能是再問用戶來批准這個權限。

If your app provides a tutorial, it may make sense to request the app’s essential permissions at the end of the tutorial sequence.

如果你的app提供一個小提示之類的東西，在最後申請app的必要權限，也許講得通。

Explain Why You Need Permissions

The permissions dialog shown by the system when you call requestPermissions() says what permission your app wants, but doesn’t say why. In some cases, the user may find that puzzling. It’s a good idea to explain to the user why your app wants the permissions before calling requestPermissions().

當你調用requestPermissions方法來表名你的app需要的權限時，系統會顯示權限對話框 ，但是並不會說為什麼需要這些權限。在一些情況下，用戶就會感到莫名其妙。在你調用requestPermissions方法前解釋一下你為什麼需要這些權限也許是一個好主意。

For example, a photography app might want to use location services so it can geotag the photos. A typical user might not understand that a photo can contain location information, and would be puzzled why their photography app wants to know the location. So in this case, it’s a good idea for the app to tell the user about this feature before calling requestPermissions().

比如，一個攝影app也許會需要定位服務，以便標記照片的位置。一個普通的用戶或許不會明白為什麼拍個照片需要包含位置信息，並且會困惑為什麼攝影app需要知道地址信息。

One way to inform the user is to incorporate these requests into an app tutorial. The tutorial can show each of the app’s features in turn, and as it does this, it can explain what permissions are needed. For example, the photography app’s tutorial could demonstrate its “share photos with your contacts” feature, then tell the user that they need to give permission for the app to see the user’s contacts. The app could then call requestPermissions() to ask the user for that access. Of course, not every user is going to follow the tutorial, so you still need to check for and request permissions during the app’s normal operation.

提示用戶為什麼app需要包含其他的許可的一個方式。輔助性提示文字可以依次向用戶展示app的功能，如果這麼做了，就可以解釋為什麼需要這個權限。比如攝影app的輔助文字可以寫成“分享你的照片給你的聯系人”功能，然後高速用戶他們需要訪問聯系人。當然，不是每一個用戶都會跟著導讀文字，所以在app通常操作時你仍然需要檢查並且申請權限。

Test for Both Permissions Models

Beginning with Android 6.0 (API level 23), users grant and revoke app permissions at run time, instead of doing so when they install the app. As a result, you’ll have to test your app under a wider range of conditions. Prior to Android 6.0, you could reasonably assume that if your app is running at all, it has all the permissions it declares in the app manifest. Under the new permissions model, you can no longer make that assumption.

從Android6.0開始，用戶在app運行時可以收回權限，而不是在安裝app的時候了。因此，你將必須在更多的條件下測試你的app。Android6.0之前，你可以確信，如果你的app在運行，那麼app久擁有它在清單文件所列舉的權限。在新的權限模式下，你不能再做這種斷言了。

The following tips will help you identify permissions-related code problems on devices running API level 23 or higher:

下面的貼士將幫助你解決在Android6.0版本，區分依賴許可的代碼問題。

- Identify your app’s current permissions and the related code paths. 區分你的app現在的權限和相關的代碼部分

- Test user flows across permission-protected services and data.測試權限被限制時的服務和數據

- Test with various combinations of granted or revoked permissions. For

example, a camera app might list CAMERA, READ_CONTACTS, and

ACCESS_FINE_LOCATION in its manifest. You should test the app with

each of these permissions turned on and off, to make sure the app can

handle all permission configurations gracefully. Remember, beginning

with Android 6.0 the user can turn permissions on or off for any app,

even an app that targets API level 22 or lower.測試許可和拒絕權限的多種組合。比如，一個攝影app也許在清單文件列舉了CAMERA，READ_CONTACTS，ACCESS_FINE_LOCATION 。你應該測試你的app，在它有和沒有的情況下，以確保app可以完美地處理所有權限配置。記住，在Android6.0，用戶隨時可以同意或者拒絕app的許可。

- Use the adb tool to manage permissions from the command line:使用adb工具來管理權限的命令行命令：

- List permissions and status by group:分組列舉許可及其狀態：

$ adb shell pm list permissions -d -g

    - Grant or revoke one or more permissions:許可或者拒絕一個或者多個權限：

$ adb shell pm [grant|revoke]  ...

Analyze your app for services that use permissions.分析你的app的使用到權限的服務。