動態請求許可權

從Android 6.0（API 23）開始，允許使用者在應用執行時決定是否允許許可權，而不是在應用安裝的時候。這種方法簡化了應用的安裝過程，因為使用者在安裝或更新應用的時候不需要允許許可權。他也讓使用者對應用的功能有更多的控制；例如，使用者可以選擇給予相機應用相機的許可權但是不允許使用裝置位置的許可權。使用者可進入應用設定隨時撤銷許可權。

系統許可權被分為兩種型別，正常的（normal）和敏感的（dangerous）：

• 正常的許可權不會直接讓使用者的隱私處於危險中。如果你的應用在清單檔案中列入了正常的許可權，系統會自動允許這些許可權。

• 敏感許可權給予應用方位使用者的機密資料。如果你的應用在清單檔案中列入危險類許可權，會明確地讓使用者對你的應用允許許可權。

在所有的Android版本中，你的應用需要在清單檔案中去申明它需要的正常的和危險的許可權。然而，宣告的影響是不同的，依賴於系統版本和你應用的目標SDK等級：

• 如果裝置執行在Android 5.1或更低，或者你的應用的 target SDK是22或者更低；如果你在清單檔案中加入了敏感許可權，當他們在安裝應用的時候必須同意權限；如果他們不同意許可權，系統則不會安裝應用。

• 如果裝置執行在Android 6.0或更高的版本，或者你的應用的 target SDK是23或者更高。應用必須在manifest檔案中加入許可權，而且在應用執行過程中必須在它需要的時候請求每一個危險的許可權。使用者可以允許或者拒絕每一個許可權，即使使用者拒絕了一個許可權的請求而應用可以在限制功能地繼續執行。

注意： 從Android6.0（API 23）開始，使用者可以在任何時候撤銷任何應用的許可權，即使應用目標SDK低於23。你應該測試你的用用驗證它正常的表現當它缺少需要的許可權，不管你的應用的target SDK等級是多少。

檢查許可權

如果你的應用需要一個敏感許可權，你必須檢查是否具有許可權當你每次執行一個操作需要一個許可權時。使用者總是可以自由地撤銷許可權，所以，即使應用昨天使用了相機，但是今天可能沒有相機許可權。

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

請求許可權

如果你的應用需要一個敏感許可權加入到manifest檔案中，他必須徵求使用者允許許可權。Android提供了一些方法讓你可以去請求一個許可權。呼叫這些方法會彈出一個標準的Android彈出框，你不能自定義。

解釋你的應用為什麼需要許可權

在某些情況中，你可能想要幫助使用者理解你的應用個為什麼需要一個許可權。例如，如果一個使用者執行一個相機應用，應用請求使用相機許可權，使用者對此並不會感到驚奇，但是，使用者並不理解為什麼應用想要訪問使用者的位置或者聯絡人。在你請求一個許可權之前，你應該考慮向用戶提供一個解釋。記住，如果你不想用解釋說服使用者；如果你提供太多的解釋，使用者可能發現應用令他沮喪並解除安裝它。

如果使用者已經關閉了許可權請求，你可能需要提供一個解釋。如果使用者堅持嘗試使用一個功能但需要請求一個許可權，但總是關閉許可權請求，可能說明使用者沒有理解應用為什麼需要該功能這個許可權。在這種情況下，去展示一個解釋可能是一個好主意。

為了幫助這種情況，使用者可能需要一個解釋，Android提供了一個實用的方法， 。如果應用以前請求過這個許可權並且被使用者拒絕了那麼這個方法會返回 true 。

注意： 如果使用者在許可權請求系統彈出框關閉許可權請求而且選擇不在提示，這個方法返回 false 。如果一個裝置已經禁止了應用的那個許可權這個方法也會返回 false。

請求你需要的許可權

如果你的應用沒有你需要的許可權，你必須呼叫 方法去請求合適的許可權。你的應用通過許可權請求，會有一個整型的請求碼唯一標識這個許可權請求。這個方法是非同步的，當用戶操作這個彈出框後他會立即返回，系統呼叫應用的回撥方法跟結果。

下面程式碼是檢查應用是否有許可權去閱讀用的聯絡人，如果有需要就請求許可權：

// 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.
    }
}

注意： 當你的應用呼叫 requestPermissions()方法時，系統會向用戶展示標準的對話方塊。你不能配置或者修對話方塊。如果你需要想用提供任何資訊或者解釋，你應該在呼叫 requestPermissions() 前去進行操作，正如 解釋你的應用為什麼需要許可權 中的描述。

處理許可權請求響應

當你的應用請求許可權時，系統會想用展示一個對話方塊。當用戶做出回覆後，系統會呼叫你應用的 方法。你的應用必須重寫這個方法，去找出許可權是否被允許。這個回撥介面跟requestPermissions()方法有一個相同的請求碼。例如，如果一個應用請求 訪問，他的回撥方法可能像下面這樣：

@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
    }
}

對話方塊會展示你的應用需要的許可權所述的許可權組，它不會列出具體的許可權。例如，如果你請求 READ_CONTACTS 許可權，系統對話方塊僅僅說你的應用需要訪問裝置的聯絡人。對於每個許可權組使用者只需要允許一次。如果你的應用請求任何其他的許可權在那個組裡，系統會自動地允許他們。當你請求許可權時，如果使用者在系統對話方塊中已經明確的允許你的請求，系統呼叫onRequestPermissionsResult() 方法，並且通過 PERMISSION_GRANTED。

注意： 你的應用仍然需要明確地請求每一個它需要的許可權，即使使用者已經允許了同組裡的另一個許可權。另外，在未來的Android版本中群組的許可權分組可能會有改變。你的程式碼不應該依賴特定的許可權是不是在一個組裡。

例如，假設你應用的manifest檔案中既有 READ_CONTACTS 許可權又有 WRITE_CONTACTS 許可權。如果你請求 READ_CONTACTS 並且使用者允許了改許可權，然後你請求 WRITE_CONTACTS ，系統會立即允許許可權而不和使用者互動。

如果使用者拒絕一個許可權請求，你的應用應該採取適當的處理。例如，你的應用可能展示一個對話方塊，解釋它為什麼需要許可權去執行使用者請求的操作。

當系統詢問使用者允許許可權時，使用者可以有選擇的告訴系統不用在此詢問許可權。在這種情況下，任何時候，應用使用 requestPermissions() 方法去在次請求許可權時，系統會立即拒絕請求。如果使用者已經明確的拒絕了你的請求，系統會呼叫 onRequestPermissionsResult() 方法並且通過PERMISSION_DENIED 。這意味著當你呼叫 requestPermissions() 方法時，你不能在使用者操作的地方產生預期的效果。

正常許可權（Normal Permissions）

在API 23中，下面許可權被定義為正常許可權

• ACCESS_LOCATION_EXTRA_COMMANDS
• ACCESS_NETWORK_STATE
• ACCESS_NOTIFICATION_POLICY
• ACCESS_WIFI_STATE
• BLUETOOTH
• BLUETOOTH_ADMIN
• BROADCAST_STICKY
• CHANGE_NETWORK_STATE
• CHANGE_WIFI_MULTICAST_STATE
• CHANGE_WIFI_STATE
• DISABLE_KEYGUARD
• EXPAND_STATUS_BAR
• GET_PACKAGE_SIZE
• INSTALL_SHORTCUT
• INTERNET
• KILL_BACKGROUND_PROCESSES
• MODIFY_AUDIO_SETTINGS
• NFC
• READ_SYNC_SETTINGS
• READ_SYNC_STATS
• RECEIVE_BOOT_COMPLETED
• REORDER_TASKS
• REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
• REQUEST_INSTALL_PACKAGES
• SET_ALARM
• SET_TIME_ZONE
• SET_WALLPAPER
• SET_WALLPAPER_HINTS
• TRANSMIT_IR
• UNINSTALL_SHORTCUT
• USE_FINGERPRINT
• VIBRATE
• WAKE_LOCK
• WRITE_SYNC_SETTINGS

敏感許可權(Dangerous permissions)

原文連結

鄙人英語能力有限，翻譯難免有誤，請讀者多多包含！ 也歡迎指正。