Android 6.0 開發者對系統權限的使用與練習（Permissions Best Practices）

Android 6.0 開發者對系統權限的使用與練習（Permissions Best Practices）

在安裝的過程中，用戶很容易忽略權限請求。如果一個用戶對應用感覺沮喪或者擔心洩漏個人信息，那麼這些用戶就會不用他或者卸載它。如何規避這個問題呢？

Consider Using an Intent

在很多的案例中，你可能會在兩種實現方式中做出選擇，你可以是的你的app擁有一個權限，也可以通過Intent的方式讓另一個app幫你實現相關功能。

例如，一款應用需要通過照相機獲取圖片，你可以通過請求CAMERA權限，該權限可以使得你的app可以直接控制相機。你的應用能夠用camera的api控制相機和獲取圖片。這種方式可以使你的應用完全的控制拍照過程中，並允許相機界面融合到應用中。

然而，如果你不需要全部的控制權，你可以使用Intent 的ACTION_IMAGE_CAPTURE請求圖片。當你發送這個Intent,系統就會提供幾個相機的app可選項（前提是沒有設置默認使用的應用） ，用戶可以選擇一個相機應用，然後通過onActivityResult()方法獲得返回值。

同理，如果你需要撥打一個電話，使用用戶的聯系人列表等等，你可以創建一個Intent，或者直接向用戶請求權限。每一種方式都有利有弊。

如果你申請一個戶權限：

當你進行一個操作的時候，你的app控制了用戶的體驗。然而過多的控制，會增加應用的復雜度，因為你需要設計適當的UI。

在運行時（API>=23）或者安裝時，用戶被提示授予權限許可。在這之後，你的應用在進行時時無需和用戶進行額外的交互。然而，如果用戶沒有授予權限或者撤銷了，你的應用將無法正常運行。

如果使用intent 的方式：

你不需要為了運行設計UI。處理該Intent的應用將提供UI。然而，由於打開的是另外的應用，這也就意味著，你不能控制用戶的交互體驗了。在你通過intent啟動的app中，由於不是你自己設計的界面，所以用戶的交互是不受你控制的。

如果你通過intent啟動的這個應用，用戶沒有一個默認的應用，系統就會彈出一個窗口，讓用戶選擇一個app。如果用戶沒有設置一個默認啟動的，每次進行該操作的時候，都會彈出一個選擇窗口。

Only Ask for Permissions You Need

每一次的權限請求，都是強迫用戶去做出一個選擇。你應該最少的向用戶去請求權限。如果用戶的版本大於等於Android6.0，每當用戶嘗試使用一些需要權限的新特性的時候，你的應用都會彈出一個請求權限的窗口。如果是在早前的版本中，權限列表是在安裝的時候提示給用戶的。如果權限列表太長或者看起來不舒服，用戶可能不去安裝這個應用。為了處理這些問題，你應該最少程度的請求權限。

你可以用intent的方式代替。如果你的新特性需要一個權限，你可以讓另一個app幫你實現這個功能。

Don't Overwhelm the User

如果用戶的系統是大於等於Android6.0，用戶必須在程序運行時去授予權限。如果你一次性讓面對用戶很多的權限請求，你可能使你的用戶收到打擊，退出你的應用。相反的，你應該在什麼時候使用，什麼時候想用戶請求。

在應用中，一個或多個權限往往是必要的。這種情況，一啟動app，我們就要想用戶請求。例如，你做了一個攝影的應用。這個應用需要用戶的Camera權限。當用戶第一次啟動應用，他們不會對你的權限請求感到困惑。但是如果這款應用有一個特色的紅能，向你的通訊錄好友風向圖片，你不能上來就去請求用戶的R EAD_CONTACT權限。你應該在分享的時候去向用戶請求權限。

如果你的應用提供了向導，最好是在向導結束之後在向用戶請求權限。

Explain Why You Need Permissions

當你調用requestPermission()方法的時候，系統就會彈出彈出權限申請彈窗，但是這裡沒有表述你為什麼需要這個權限。在很多案例中，用戶會感到困惑。一個比較不錯的注意是在調用requestPermission（）之前，向用戶解釋你為什麼需要這個權限。

例如：一個攝影app，想要用定位服務在圖片上打上標志。一個普通的用戶可能不明白為什麼一個圖片需要使用定位，會感到很困惑。在這個案例中，一個好主意是在requestPermission（）之前向用戶解釋。

另一種方式，你可以把權限請求融合在向導中。在向導中，你可以向用戶展示app的特殊功能點，並且向用戶展示你為什麼需要這個權限。比如。這個攝影的app，就可以在向導中表明”向聯系人分享照片“這個特色功能，然後告訴你用戶你需要聯系人列表這個權限。然後向用戶申請。這個應用可以能過通過調用requestPermission（）方法，向用戶請求權限。當然，不是每一個用戶都會看完你的向導，所以你還是要在用戶使用該功能的時候，檢測用戶是否授權，如果沒有，還要彈窗向用戶申請該權限。

Test for Both Permissions Models

在Android6.0中，通過在運行時請求權限代替了安裝時。因為這個原因，你必須在更廣泛的條件下測試你的應用。在Android6.0之前我們有充足的理由相信，我們的程序運行了，就有了足夠的權限，因為這些權限已經在manifest文件中聲明。在新的權限模型中，就不可以這樣了。

在大於等於API23的情況下，你需要確定你的權限：

·IDentify your app’s current permissions andthe related code paths.

·Test user flows across permission-protectedservices and data.

·Test with various combinations of grantedor revoked permissions. For example, a camera app might listCAMERA,READ_CONTACTS, andACCESS_FINE_LOCATIONin itsmanifest. You should test the app with each of these permissions turned on andoff, to make sure the app can handle all permission configurations gracefully.

·Use theadbtoolto manage permissions from the command line:

o Listpermissions and status by group:

$ adb shell pm list permissions -d -g

o Grantor revoke one or more permissions:

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

·Analyze your app for services that usepermissions.