Android中使用shouldShowRequestPermissionRationale判斷權限被禁止

轉載請註明出處：https://blog.csdn.net/yeluofengchui/article/details/91126163

前言

Android6.0之後的有些權限需要去動態獲取，這個過程中呢，我們或許會遇到這麼幾個方法。
1.ContextCompat.checkSelfPermission 檢查權限是否允許
2.ActivityCompat.requestPermissions 請求某個或某幾個權限
3.onRequestPermissionsResult 手動請求權限之後的結果回調
4.shouldShowRequestPermissionRationale ？？？

其中前三個的用途都非常清楚，大家也都知道怎麼用的，這裏不做過多解釋，今天主要看下咱們的主角shouldShowRequestPermissionRationale，看下它是幹什麼用的。從shouldShowRequestPermissionRationale這麼長的方法名，解釋出來就是“應不應該解釋下請求這個權限的目的”，接下來，咱們先看它的官方註釋。

官方解釋

 /**
     * Gets whether you should show UI with rationale for requesting a permission.
     * You should do this only if you do not have the permission and the context in
     * which the permission is requested does not clearly communicate to the user
     * what would be the benefit from granting this permission.
     * <p>
     * For example, if you write a camera app, requesting the camera permission
     * would be expected by the user and no rationale for why it is requested is
     * needed. If however, the app needs location for tagging photos then a non-tech
     * savvy user may wonder how location is related to taking photos. In this case
     * you may choose to show UI with rationale of requesting this permission.
     * </p>
     *
     * @param activity The target activity.
     * @param permission A permission your app wants to request.
     * @return Whether you can show permission rationale UI.

蹩腳翻譯

獲取是否應顯示具有請求權限理由的UI，只有在沒有權限並且上下文的情況下不能清晰明瞭的表明爲什麼需要這個權限時才應該這樣做。舉例，你要是實現一個照相的app，用戶可以明白你爲什麼需要照相的權限，然而app卻需要定位信息去給照片做標註，一個非技術又精明的用戶可能很好奇一個拍照APP怎麼會想要定位權限。在這種情況下您可以選擇在請求定位權限之前先在UI上解釋下爲什麼需要它。
返回：你是否可以展示權限的解釋說明

  看完之後你明白了嗎？講真，我是真不明白，這段註釋只說明了Google工程師設計這個方法的初衷是什麼，具體有什麼功能，怎麼用的，從這裏我真的還看不錯來。

#網絡資源參考
Android6.0動態權限shouldShowRequestPermissionRationale的含義這篇文章，說明的是比較有價值的：

以某個權限爲例，
1.第一次請求權限時ActivityCompat.我使用的是8.0系統的手機=false;
2、第一次請求權限被禁止，但未選擇【不再提醒】ActivityCompat.shouldShowRequestPermissionRationale=true;
3、允許某權限後ActivityCompat.shouldShowRequestPermissionRationale=false;
4、 禁止權限，並選中【禁止後不再詢問】ActivityCompat.shouldShowRequestPermissionRationale=false；
文章中記錄的結果和我真實手機跑程序打印的結果是一致的（我使用的是8.0系統的手機）。

shouldShowRequestPermissionRationale的功能價值何在

在此之前先說明下，由於不同的系統廠商定製的結果，
1.有的手機某些權限清單註冊了權限就能用，不用動態申請（因爲系統會在安裝時自動app分配一些權限，具體怎麼分配的這裏暫不做討論）；
2.有的手機在彈出授權時選擇拒絕就默認了不再彈出；
3.有的沿用了原生系統的規則；
4.設置-應用-權限中權限分“允許、詢問、拒絕”三個級別，但是有的權限只有“允許、拒絕”兩個級別；

這裏先統一下名詞：
允許 – 權限通過
拒絕–拒絕了但是還允許詢問
禁止–拒絕了且不再允許詢問（如4中所述的“拒絕”先定義爲禁止）

從前面就可以看出來，這個方法大部分情況下是放回false的，只有被用戶拒絕了權限，再次獲取纔會得到true；如果沒有申請過，或者禁止了權限，都是返回的false。所以很多人想要通過shouldShowRequestPermissionRationale去判斷是否權限被禁止，有時候是並不準確的，真要說怎樣會準確的獲取到權限被禁止的情況，那就是：

1.在requestPermissions之後在
onRequestPermissionsResult中獲取到沒給權限，並且shouldShowRequestPermissionRationale是false，此時可以認定該權限被用戶禁止了；
2.還有一個點是是在onRequestPermissionsResult的參數值第三個參數grantResults是null,此時權限也是被拒絕的。（權限被拒絕後再次調用requestPermissions，沒有返回結果）

總結

shouldShowRequestPermissionRationale，回到最初的解釋“應不應該解釋下請求這個權限的目的”。
1.都沒有請求過這個權限，用戶不一定會拒絕你，所以你不用解釋，故返回false;
2.請求了但是被拒絕了，此時返回true，意思是你該向用戶好好解釋下了；
3.請求權限被禁止了，也不給你彈窗提醒了，所以你也不用解釋了，故返回fasle;
4.請求被允許了，都給你權限了，還解釋個啥，故返回false。

Google的初衷大概就是第一次requestPermissions的時候被拒絕時給你一次解釋的機會，所以是讓你在請求權限的回調中使用的。
#其它
動態權限的適配就是檢測、請求，然後看回調，再通過了權限後再去執行自己的方法，但是真正用的時候又很麻煩，每次調用相機、短信、打電話、訪問通訊錄、定位等等都要請求權限，寫一堆跟業務無關的代碼，是不是很煩呢？
最近整理了一個關於方便管理動態權限的庫，一個EasyPermission的權限管理庫，幫你申請動態權限
附github源碼：https://github.com/githubZYQ/easypermission

轉載請註明出處：https://blog.csdn.net/yeluofengchui/article/details/91126163