原文作者：Google
原文地址：http://developer.android.com/intl/zh-cn/training/permissions/best-practices.html
原文版權：Creative Commons 2.5 Attribution License
譯文作者：Jianan - [email protected]
版本信息：本文基於2016-05-04版本翻譯
譯文版權：CC BY-NC-ND 4.0，允許複製轉載，但必須保留譯文作者署名及譯文鏈接，不得演繹和用於商業用途
前言
app的權限請求很容易讓用戶反感。當用戶覺得一個app用起來很麻煩，或者覺得這個app不知道要拿用戶的信息去做什麼事情時，用戶可能會避免使用甚至是完全卸載掉這個app。下面的權限最佳運用方式能夠幫助你避免這些糟糕的用戶體驗。
考慮使用Intent
在很多情況下，app執行一個任務都會有兩種可供選擇的方式。你可以讓你的app親自請求系統權限來執行一個操作，你也可以讓你的app發送一個Intent給其它app來代替執行這個操作。
舉個例子，假設你的app需要使用設備的攝像頭拍一張照片。你的app可以申請CAMERA權限，這個權限允許你的app直接訪問攝像頭。請求這個權限之後，你的app才能使用攝像頭的API來控制攝像頭並拍攝一張照片。這種方式能夠使你完全控制整個拍照的過程，還能夠將拍照界面UI整合到你的app裏面。
然而，如果你不需要像這樣完全控制整個拍照流程，那麼你可以使用一個ACTION_IMAGE_CAPTURE Intent來請求獲取一張圖片。當你發送這個Intent請求之後，系統會提示用戶選擇一個拍照app（如果系統還沒有設定默認拍照app的情況下）。之後，用戶可以使用選擇的拍照app拍攝一張照片，這個拍照app會通過onActivityResult() 方法返回一張圖片。
同樣的，如果你需要打電話、訪問用戶通訊錄等等，你都可以創建一個合適的Intent來完成這件事情。當然，你都可以直接申請系統權限後直接訪問響應的對象進行處理。下面是這兩種方式的的優缺點。
如果你申請權限：
- 當你在執行目標操作的時候，你能夠完全控制整個過程中的用戶體驗。但是，這樣全面的控制你的任務流程勢必會增加實現的複雜程度，例如你需要設計一個合適的UI。
- （基於用戶的android設備版本）不管是在app運行的過程中還是在安裝app的時候，用戶會被提示授權至少一次。在這之後，你的app才能直接執行相應的操作，不再需要用戶的授權互動。但是，如果用戶拒絕授權（或者在過後撤銷了授權），那麼你的app將完全無法執行對應的操作。
如果你使用Intent：
- 你不需要爲對應的操作設計UI，接收Intent請求的app會提供相應的UI。這意味着你無法控制整個過程的用戶體驗。用戶可能會與你從來沒有見過的app進行交互操作。
- 如果用戶沒有設定處理該操作的默認app，系統將會提供用戶選擇一個app。也就是，如果用戶沒有指定一個默認的操作處理app，每次用戶執行響應的操作都會彈出一個額外的對話框。
只申請你需要的權限
每一次你請求一個權限，你都是在強制用戶做出一個決定。你應該儘量減少這些請求的次數。如果用戶的android設備系統版本是6.0（API Level 23）或者更高，每次用戶嘗試一個需要申請權限的新功能時，app都必須中斷用戶的操作要求授權。如果用戶的android設備系統是更早的版本，用戶就需要在安裝app的時候授權每一個app需要的權限。這種情況下，如果權限列表過長或者看起來不合理，用戶可能就選擇不安裝你的app了。基於這些原因，你都應該儘量減少你的app需要申請的權限。
通常情況下，你都可以替代使用Intent來避免申請權限。如果一個功能對於你的app來說並不是非常核心的模塊，你就應該考慮讓其它的app來完成這個功能，詳情請參考上面考慮使用Intent章節。
不要騷擾用戶
如果用戶的設備運行着android 6.0（API level 23）或者更高的系統版本，在運行app的過程中，用戶就必須對每一個需要的權限進行授權。如果你一次向用戶申請過多的權限，你就可能騷擾到用戶，導致他們放棄你的app。因此，你應該只申請你需要的權限。
在一些情況下，有些權限對於你的app來說是必須的，那麼在app一啓動的時候就申請這些權限是比較合理的。例如，如果你寫了一個拍照app，這個app需要訪問設備攝像頭。當用戶第一次啓動這個app的時候，他們就不會驚訝這個app爲什麼需要申請攝像頭權限。但如果這個app還有一個功能是分享照片給用戶的通訊錄聯繫人，那你就不應該在第一次啓動的時候申請READ_CONTACTS權限。相反的，你應該等到用戶使用“分享”功能的時候再申請聯繫人權限。
如果你的app能提供一個教程，那麼最好在教程的結尾解釋app需要的必要權限。
解釋爲什麼你需要權限
當你調用requestPermission() 方法後系統彈出的授權對話框會說明你的app需要什麼權限，但是不會解釋爲什麼需要權限。在一些情況下，用戶可能會對這些權限申請感到疑惑。因此，在調用requestPermission() 方法之前向用戶解釋你的app爲什麼需要這個權限是一種很好的做法。
例如，一個拍照app可能需要使用地理位置服務來標識拍攝的照片。一般用戶可能不知道一張圖片裏面可以包含地理位置信息，他們可能就會對拍照app需要獲取地理位置信息感到疑惑。類似這樣的情況，在app調用requestPermission() 方法之前向用戶解釋這個功能就很有意義了。
通知用戶的一種途徑可以是在app的教程指南中列舉所有需要的權限解釋。在這個教程指南中可以輪流展示app的每一個功能，在展示的過程中解釋每一個功能需要的權限。例如，拍照app的教程指南可以演示它的“分享圖片給聯繫人”功能，在演示過程中告訴用戶app需要權限來查看用戶的聯繫人。之後，app可以調用requestPermission() 方法來請求用戶授權訪問對應的功能。當然，不是每一個用戶都會查看教程指南，所以你在app的正常操作過程中一樣要時時檢查權限是否已經授權。
測試所有的權限模式
從android 6.0（API level 23）開始，用戶可以在運行過程中授權或者撤銷權限，而不是在安裝app的時候就要求這麼做。這就導致了一個結果，你必須測試你的app在多種多樣的權限授權組合模式下的運行情況。在android 6.0之前的版本上，你可以合理的斷定你的app如果安裝運行起來了，那麼app的manifest文件聲明的所有權限都已經授權。但在新的權限管理模式下，你不能再這麼簡單的下結論。
下面的小提示可以幫助你確認在API level 23或者更高版本設備上出現的權限相關的代碼問題：
- 確認你的app當前的權限，以及相關代碼的位置。
- 測試用戶經權限保護的服務和數據。
- 測試已授權或者已被撤權的各種權限組合。例如，一個拍照app可能在manifest文件中列舉了CAMERA、READ_CONTACTS、ACCESS_FINE_LOCATION權限。你就必須測試每一種權限的開啓或者關閉，確保app能夠優雅的處理所有權限的授權或拒絕組合模式。需要注意的是，從android 6.0開始，用戶能夠授權或者禁止任意app的權限，不管這個app的target API level是22還是更低的版本。
- 在終端上使用adb工具管理權限：
- 分組列舉權限和狀態：
$ adb shell pm list permissions -d -g
- 授權或者取消一個或多個權限：
$ adb shell pm [grant|revoke] <permission-name> ...
- 分組列舉權限和狀態：
- 分析你的app那些使用權限的service。