1. 程式人生 > >Android PermissionChecker 許可權全面詳細分析和解決方案

Android PermissionChecker 許可權全面詳細分析和解決方案

原文:

http://www.2cto.com/kf/201512/455888.html

http://blog.csdn.net/yangqingqo/article/details/48371123

http://inthecheesefactory.com/blog/things-you-need-to-know-about-Android-m-permission-developer-edition/en

一、Marshmallow版本許可權簡介

android的許可權系統一直是首要的安全概念,因為這些許可權只在安裝的時候被詢問一次。一旦安裝了,app可以在使用者毫不知曉的情況下訪問許可權內的所有東西,而且一般使用者安裝的時候很少會去仔細看許可權列表,更不會去深入瞭解這些許可權可能帶來的相關危害。所以在android 6.0 Marshmallow版本之後,系統不會在軟體安裝的時候就賦予該app所有其申請的許可權,對於一些危險級別的許可權,app需要在執行時一個一個詢問使用者授予許可權。



二、舊版本app相容問題

  那麼問題來了,是不是所有以前釋出的app都會出現問題呢?答案是不會,只有那些targetSdkVersion 設定為23和23以上的應用才會出現異常,在使用危險許可權的時候系統必須要獲得使用者的同意才能使用,要不然應用就會崩潰,出現類似
java.lang.SecurityException: Permission Denial: reading com.android.providers.media.MediaProvider

的崩潰日誌。所以targetSdkVersion如果沒有設定為23版本或者以上,系統還是會使用舊規則:在安裝的時候賦予該app所申請的所有許可權。所以app當然可以和以前一樣正常使用了,但是還有一點需要注意的是6.0的系統裡面,使用者可以手動將該app的許可權關閉,如下圖


  
  那麼問題又來了,如果以前的老應用申請的許可權被使用者手動關閉了怎麼辦,應用會崩潰麼?我們來試一試
  這裡寫圖片描述
  好吧,可以慶幸了一下了,不會丟擲異常,不會崩潰,只不過呼叫那些被使用者禁止許可權的api介面返回值都為null或者0,所以我們只需要做一下判空操作就可以了,不判空當然還是會崩潰的嘍。


三、普通許可權和危險許可權列表

  現在對於新版本的許可權變更應該有了基本的認識,那麼,是不是所有許可權都需要去進行特殊處理呢?當然不是,只有那些危險級別的許可權才需要。

PROTECTION_NORMAL類許可權

當用戶安裝或更新應用時,系統將授予應用所請求的屬於 PROTECTION_NORMAL 的所有許可權(安裝時授權的一類基本許可權)。這類許可權包括:

android.permission.ACCESS LOCATIONEXTRA_COMMANDS 
android.permission.ACCESS NETWORKSTATE 
android.permission.ACCESS NOTIFICATIONPOLICY 
android.permission.ACCESS WIFISTATE 
android.permission.ACCESS WIMAXSTATE 
android.permission.BLUETOOTH 
android.permission.BLUETOOTH_ADMIN 
android.permission.BROADCAST_STICKY 
android.permission.CHANGE NETWORKSTATE 
android.permission.CHANGE WIFIMULTICAST_STATE 
android.permission.CHANGE WIFISTATE 
android.permission.CHANGE WIMAXSTATE 
android.permission.DISABLE_KEYGUARD 
android.permission.EXPAND STATUSBAR 
android.permission.FLASHLIGHT 
android.permission.GET_ACCOUNTS 
android.permission.GET PACKAGESIZE 
android.permission.INTERNET 
android.permission.KILL BACKGROUNDPROCESSES 
android.permission.MODIFY AUDIOSETTINGS 
android.permission.NFC 
android.permission.READ SYNCSETTINGS 
android.permission.READ SYNCSTATS 
android.permission.RECEIVE BOOTCOMPLETED 
android.permission.REORDER_TASKS 
android.permission.REQUEST INSTALLPACKAGES 
android.permission.SET TIMEZONE 
android.permission.SET_WALLPAPER 
android.permission.SET WALLPAPERHINTS 
android.permission.SUBSCRIBED FEEDSREAD 
android.permission.TRANSMIT_IR 
android.permission.USE_FINGERPRINT 
android.permission.VIBRATE 
android.permission.WAKE_LOCK 
android.permission.WRITE SYNCSETTINGS 
com.android.alarm.permission.SET_ALARM 
com.android.launcher.permission.INSTALL_SHORTCUT 
com.android.launcher.permission.UNINSTALL_SHORTCUT

這類許可權只需要在AndroidManifest.xml中簡單宣告這些許可權就好,安裝時就授權。不需要每次使用時都檢查許可權,而且使用者不能取消以上授權。

危險許可權

Permission GroupPermissions
android.permission-group.CALENDAR
  • android.permission.READ_CALENDAR
  • android.permission.WRITE_CALENDAR
android.permission-group.CAMERA
  • android.permission.CAMERA
android.permission-group.CONTACTS
  • android.permission.READ_CONTACTS
  • android.permission.WRITE_CONTACTS
  • android.permission.GET_ACCOUNTS
android.permission-group.LOCATION
  • android.permission.ACCESS_FINE_LOCATION
  • android.permission.ACCESS_COARSE_LOCATION
android.permission-group.MICROPHONE
  • android.permission.RECORD_AUDIO
android.permission-group.PHONE
  • android.permission.READ_PHONE_STATE
  • android.permission.CALL_PHONE
  • android.permission.READ_CALL_LOG
  • android.permission.WRITE_CALL_LOG
  • com.android.voicemail.permission.ADD_VOICEMAIL
  • android.permission.USE_SIP
  • android.permission.PROCESS_OUTGOING_CALLS
android.permission-group.SENSORS
  • android.permission.BODY_SENSORS
android.permission-group.SMS
  • android.permission.SEND_SMS
  • android.permission.RECEIVE_SMS
  • android.permission.READ_SMS
  • android.permission.RECEIVE_WAP_PUSH
  • android.permission.RECEIVE_MMS
  • android.permission.READ_CELL_BROADCASTS
android.permission-group.STORAGE
  • android.permission.READ_EXTERNAL_STORAGE
  • android.permission.WRITE_EXTERNAL_STORAGE
  android開發者官網也有相關描述:
  http://developer.android.com/training/permissions/requesting.html
  http://developer.android.com/guide/topics/security/permissions.html

  所以仔細去看看自己的app,對照列表,如果有需要申請其中的一個許可權,就需要進行特殊操作。還有一個比較人性的地方就是如果同一組的任何一個許可權被授權了,其他許可權也自動被授權。例如,一旦WRITE_EXTERNAL_STORAGE被授權了,app也有READ_EXTERNAL_STORAGE許可權了。

四、支援Marshmallow新版本許可權機制

關於許可權控制主要使用到

PermissionChecker類的checkSelfPermission();

ActivityCompat類的

   public static boolean shouldShowRequestPermissionRationale(@NonNull Activity activity,
            @NonNull String permission) 

Fragment類的

 public boolean shouldShowRequestPermissionRationale(@NonNull String permission) 

ActivityCompat類的

    public static void requestPermissions(final @NonNull Activity activity,
            final @NonNull String[] permissions, final int requestCode) 

Fragment類的

  public final void requestPermissions(@NonNull String[] permissions, int requestCode)

終於要開始支援android 6.0版本了,最先一步當然就是修改build.gradle檔案中的tragetSdkVersion和compileSdkVersion成23版本,同時使用compile ‘com.android.support:appcompat-v7:23.1.1’最新v7包。

android {
    compileSdkVersion 23
    ...

    defaultConfig {
        ...
        targetSdkVersion 23
        ...
    }
}
...
dependencies {
...
compile 'com.android.support:appcompat-v7:23.1.1'
  修改完後,感興趣的朋友可以直接打包在手機上測試一下,看看是不是會出現類似於上面我說的那些崩潰日誌。
  接著下一步當然就是要修改程式碼了,最原始程式碼,無任何處理:

private void startGetImageThread(){
....
    Uri uri = MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
    ContentResolver contentResolver = getContentResolver();
    //獲取jpeg和png格式的檔案,並且按照時間進行倒序
    Cursor cursor = contentResolver.query(uri, null, MediaStore.Images.Media.MIME_TYPE + "=\"image/jpeg\" or " +
    MediaStore.Images.Media.MIME_TYPE + "=\"image/png\"", null, MediaStore.Images.Media.DATE_MODIFIED+" desc");
    ....
}
  這段程式碼需要訪問外部儲存(相簿圖片),屬於危險級別的許可權,直接使用會造成應用崩潰,所以在這段程式碼執行之前我們需要進行特殊處理:

int hasWriteContactsPermission = checkSelfPermission(Manifest.permission.WRITE_EXTERNAL_STORAGE);

if (hasWriteContactsPermission != PackageManager.PERMISSION_GRANTED) {

Activity activty=this;

        ActivityCompat.requestPermissions(activty,new String[] {Manifest.permission.WRITE_EXTERNAL_STORAGE},
                CODE_FOR_WRITE_PERMISSION);
    return;
}
  寫完這段程式碼之後,就會出現如下系統dialog:
  
  緊接著就需要去處理DENY和ALLOW的回調了,重寫 Activity activity的ActivityCompat.OnRequestPermissionsResultCallback函式:

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
    if (requestCode == CODE_FOR_WRITE_PERMISSION){
        if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
            &&grantResults[0] == PackageManager.PERMISSION_GRANTED){
            //使用者同意使用write
            startGetImageThread();
        }else{
            //使用者不同意,自行處理即可
            finish();
        }
    }
}
  好了,這樣就算是簡單初步適配完成了。


五、處理不再提醒

  如果使用者拒絕某授權。下一次彈框,使用者會有一個“不再提醒”的選項的來防止app以後繼續請求授權。

  

  如果這個選項在拒絕授權前被使用者勾選了。下次為這個許可權請求requestPermissions時,對話方塊就不彈出來了,系統會直接回調onRequestPermissionsResult函式,回撥結果為最後一次使用者的選擇。所以為了應對這種情況,系統提供了一個shouldShowRequestPermissionRationale()函式,這個函式的作用是幫助開發者找到需要向用戶額外解釋許可權的情況,這個函式:
應用安裝後第一次訪問,直接返回false;第一次請求許可權時,使用者拒絕了,下一次shouldShowRequestPermissionRationale()返回 true,這時候可以顯示一些為什麼需要這個許可權的說明;第二次請求許可權時,使用者拒絕了,並選擇了“不再提醒”的選項時:shouldShowRequestPermissionRationale()返回 false;裝置的系統設定中禁止當前應用獲取這個許可權的授權,shouldShowRequestPermissionRationale()返回false;  注意:第二次請求許可權時,才會有“不再提醒”的選項,如果使用者一直拒絕,並沒有選擇“不再提醒”的選項,下次請求許可權時,會繼續有“不再提醒”的選項,並且shouldShowRequestPermissionRationale()也會一直返回true。
  所以利用這個函式我們可以進行相應的優化,針對shouldShowRequestPermissionRationale函式返回false的處理有兩種方案。第一種方案:如果應用是第一次請求該許可權,則直接呼叫requestPermissions函式去請求許可權;如果不是則代表使用者勾選了’不再提醒’,彈出dialog,告訴使用者為什麼你需要該許可權,讓使用者自己手動開啟該許可權。連結:http://stackoverflow.com/questions/32347532/android-m-permissions-confused-on-the-usage-of-shouldshowrequestpermissionrati 。第二種方案:在onRequestPermissionsResult函式中進行檢測,如果返回PERMISSION_DENIED,則去呼叫shouldShowRequestPermissionRationale函式,如果返回false代表使用者已經禁止該許可權(上面的3和4兩種情況),彈出dialog告訴使用者你需要該許可權的理由,讓使用者手動開啟。連結:http://stackoverflow.com/questions/30719047/android-m-check-runtime-permission-how-to-determine-if-the-user-checked-nev  處理方法已經有了,修改一下程式碼,我這裡就以第二種方案來處理了:
 
@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions, int[] grantResults) {
    if (requestCode == CODE_FOR_WRITE_PERMISSION){
        if (permissions[0].equals(Manifest.permission.WRITE_EXTERNAL_STORAGE)
            &&grantResults[0] == PackageManager.PERMISSION_GRANTED){
            //使用者同意使用write
            startGetImageThread();
        }else{
            //使用者不同意,向用戶展示該許可權作用
            if (!ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.WRITE_EXTERNAL_STORAGE)) {
                AlertDialog dialog = new AlertDialog.Builder(this)
                        .setMessage("該相簿需要賦予訪問儲存的許可權,不開啟將無法正常工作!")
                        .setPositiveButton("確定", new DialogInterface.OnClickListener() {
                            @Override
                            public void onClick(DialogInterface dialog, int which) {
                                finish();
                            }
                        })
                        .setNegativeButton("取消", new DialogInterface.OnClickListener() {
                            @Override
                            public void onClick(DialogInterface dialog, int which) {
                                finish();
                            }
                        }).create();
                dialog.show();
                return;
            }
            finish();
        }
    }
}
  當勾選不再提醒,並且拒絕之後,彈出dialog,提醒使用者該許可權的重要性:
  
  


六、使用相容庫


  以上的程式碼在6.0版本上使用沒有問題,但是在之前就有問題了,最簡單粗暴的解決方法可能就是利用Build.VERSION.SDK_INT >= 23這個判斷語句來判斷了,方便的是SDK 23的v4包加入了專門類進行相關的處理:

ContextCompat.checkSelfPermission()被授權函式返回PERMISSION_GRANTED,否則返回PERMISSION_DENIED ,在所有版本都是如此。ActivityCompat.requestPermissions()這個方法在6.0之前版本呼叫,OnRequestPermissionsResultCallback 直接被呼叫,帶著正確的 PERMISSION_GRANTED或者PERMISSION_DENIED。ActivityCompat.shouldShowRequestPermissionRationale()在6.0之前版本呼叫,永遠返回false。  用v4包的這三方法,完美相容所有版本!下面是程式碼:
//使用相容庫就無需判斷系統版本
int hasWriteContactsPermission = ContextCompat.checkSelfPermission(getApplication(), Manifest.permission.WRITE_EXTERNAL_STORAGE);
if (hasWriteContactsPermission == PackageManager.PERMISSION_GRANTED) {
    startGetImageThread();
}
//需要彈出dialog讓使用者手動賦予許可權
else{
    ActivityCompat.requestPermissions(PickOrTakeImageActivity.this, new String[]{Manifest.permission.WRITE_EXTERNAL_STORAGE}, CODE_FOR_WRITE_PERMISSION);

}

  onRequestPermissionsResult函式不變。後兩個方法,我們也可以在Fragment中使用,用v13相容包:FragmentCompat.requestPermissions() and FragmentCompat.shouldShowRequestPermissionRationale()和activity效果一樣。



七、一次請求多個許可權


  當然了有時候需要多個許可權,可以用上面方法一次請求多個許可權。當然最重要的是不要忘了為每個許可權檢查“不再提醒”的設定。
List<string> permissionsNeeded = new ArrayList<string>();
permissionsNeeded.add(Manifest.permission.ACCESS_FINE_LOCATION);
permissionsNeeded.add(Manifest.permission.READ_CONTACTS);
permissionsNeeded.add(Manifest.permission.WRITE_CONTACTS);
requestPermissions(permissionsNeeded.toArray(new String[permissionsList.size()]), CODE_FOR_MULTIPLE_PERMISSION);</string></string>
  最後在onRequestPermissionsResult函式中一個個處理返回結果即可。


八、第三方庫簡化程式碼


  當然早就有第三方庫來幫忙做這些事情了:
  Github上的開源專案 PermissionHelper和hotchemi’s PermissionsDispatcher


九、APP處於執行狀態下,被撤銷許可權


  如果APP正在執行中,使用者進入設定-應用程式頁面去手動撤銷該APP許可權,會出現什麼情況呢?哈哈,系統又會接著彈出許可權請求對話方塊,挺好挺好:
  
  這樣就沒有問題了吧O(∩_∩)O~
  上面的測試環境為genymotion6.0模擬器,有朋友跟我反映在6.0nexus 6p真機上會直接退出應用,所以這個應該還和測試環境有關。


使用相容庫support-v4中的方法The v4 support library also contains theclass, which provides several static utility methods for apps that use IPC to provide services for other apps. For example,checks whether an IPC made by a particular package has a specified permission.
Note:When your app calls the framework'smethod, the system shows a standard dialog box to the user. Your appcannotconfigure or alter that dialog box. If you need to provide any information or explanation to the user, 當呼叫 時,系統會顯示一個獲取許可權的提示對話方塊,當前應用不能配置和修改這個對話方塊,如果需要提示使用者一些這個許可權相關的資訊或說明,需要在呼叫 之前處理。

To help find the situations where you need to provide extra explanation, the system provides themethod. 

This method returnstrueif the app has requested this permission previously and the user denied the request. 

That indicates that you should probably explain to the user why you need the permission.

If the user turned down the permission request in the past and chose theDon't ask againoption in the permission request system dialog, this method returnsfalse

The method also returnsfalseif the device policy prohibits the app from having that permission.


注意:上面的:第二次請求許可權時,才會有“不在提醒”的選項,如果使用者一直拒絕,並沒有選擇“不在提醒”的選項,下次請求許可權時,會繼續有“不在提醒”的選項

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.

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.

根據方法說明:
顯示許可權說明:是根據你的應用中使用的許可權分類來的:
1.使用者容易知道應用需要獲取的許可權:如一個拍照應用,需要攝像頭的許可權,是很正常,不用提示。
2.一些使用者感覺困惑的一些許可權:如:分享圖片,還需要獲取位置的許可權,這個需要提示使用者:為什麼需要這個許可權。