Android 6.0 開發人員對系統許可權的使用與練習（Permissions Best Practices）

標籤：

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, and ACCESS_FINE_LOCATION in 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 the adb toolto 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] <permission-name> ...

·        Analyze your app for services that usepermissions.

如果您覺得我的分享對您有用，掃一掃關注我吧。

Android 6.0 開發人員對系統許可權的使用與練習（Permissions Best Practices）