2. 程式人生 > >Android 6.0 執行時許可權管理最佳實踐

Android 6.0 執行時許可權管理最佳實踐

阿新 • • 發佈：2019-01-07

這是一篇遲來的部落格，Android M已經發布一年多了（6.0的變化），在Android M中許可權系統被重新設計，發生了顛覆性的變化，很多人把握不好這個變化，一是對這個許可權策略和套路還沒有摸透，二是沒有一個很好的實踐來支撐，在我的技術開發群裡很多人問我關於許可權的問題，往往我都沒有直接回答，因為這個問題不是一兩句說的清楚的，這幾點是今天我寫這篇部落格的原因。這裡有一切關於Android執行時許可權你需要知道的，包括如何在程式碼中實現，如果你以前不知道這些東西，現在來看也為時不晚，我將在詳解之後給你一個最佳的實踐方案。

AndPermission能解決大部分國產機遇到的許可權問題，請參考：

國產手機許可權適配方案

AndPermission特性

  1. 鏈式呼叫，一句話申請許可權，為你省去複雜的邏輯判斷。
  2. 支援註解回撥結果、支援Listener回撥結果。
  3. 拒絕一次某許可權後，再次申請該許可權時可使用Rationale向用戶說明申請該許可權的目的，在使用者同意後再繼續申請，避免使用者勾選不再提示而導致不能再次申請該許可權。
  4. 就算使用者拒絕許可權並勾選不再提示，可使用SettingDialog提示使用者去設定中授權。
  5. RationaleDialog和SettingDialog允許開發者自定義。
  6. AndPermission自帶預設對話方塊除可自定義外，也支援國際化。
  7. 支援在任何地方申請許可權，不僅限於Activity
    和Fragment等。

如果你的英文夠好，推薦你閱讀官網的文章：

關於執行時許可權

在舊的許可權管理系統中，許可權僅僅在App安裝時詢問使用者一次，使用者同意了這些許可權App才能被安裝（某些深度定製系統另說），App一旦安裝後就可以偷偷的做一些不為人知的事情了。

在Android6.0開始，App可以直接安裝，App在執行時一個一個詢問使用者授予許可權，系統會彈出一個對話方塊讓使用者選擇是否授權某個許可權給App（這個Dialog不能由開發者定製），當App需要使用者授予不恰當的許可權的時候，使用者可以拒絕，使用者也可以在設定頁面對每個App的許可權進行管理。

特別注意：

這個對話方塊不是開發者呼叫某個許可權的功能時由系統自動彈出，而是需要開發者手動呼叫，如果你直接呼叫而沒有去申請許可權的話，將會導致App崩潰。

也許你已經開始慌了，這對於使用者來說是好事，但是對於開發者來說我們不能直接呼叫方法了，我們不得不在每一個需要許可權的地方檢查並請求使用者授權，所以就引出了以下兩個問題。

哪些許可權需要動態申請

新的許可權策略講許可權分為兩類，第一類是不涉及使用者隱私的，只需要在Manifest中宣告即可，比如網路、藍芽、NFC等；第二類是涉及到使用者隱私資訊的，需要使用者授權後才可使用，比如SD卡讀寫、聯絡人、簡訊讀寫等。

此類許可權都是正常保護的許可權，只需要在AndroidManifest.xml中簡單宣告這些許可權即可，安裝即授權，不需要每次使用時都檢查許可權，而且使用者不能取消以上授權，除非使用者解除安裝App。

  • ACCESS_LOCATION_EXTRA_COMMANDS
  • ACCESS_NETWORK_STATE
  • ACCESS_NOTIFICATION_POLICY
  • ACCESS_WIFI_STATE
  • BLUETOOTH
  • BLUETOOTH_ADMIN
  • BROADCAST_STICKY
  • CHANGE_NETWORK_STATE
  • CHANGE_WIFI_MULTICAST_STATE
  • CHANGE_WIFI_STATE
  • DISABLE_KEYGUARD
  • EXPAND_STATUS_BAR
  • GET_PACKAGE_SIZE
  • INSTALL_SHORTCUT
  • INTERNET
  • KILL_BACKGROUND_PROCESSES
  • MODIFY_AUDIO_SETTINGS
  • NFC
  • READ_SYNC_SETTINGS
  • READ_SYNC_STATS
  • RECEIVE_BOOT_COMPLETED
  • REORDER_TASKS
  • REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
  • REQUEST_INSTALL_PACKAGES
  • SET_ALARM
  • SET_TIME_ZONE
  • SET_WALLPAPER
  • SET_WALLPAPER_HINTS
  • TRANSMIT_IR
  • UNINSTALL_SHORTCUT
  • USE_FINGERPRINT
  • VIBRATE
  • WAKE_LOCK
  • WRITE_SYNC_SETTINGS

所有危險的Android系統許可權屬於許可權組，如果APP執行在Android 6.0 (API level 23)或者更高級別的裝置中，而且targetSdkVersion>=23時，系統將會自動採用動態許可權管理策略，如果你在涉及到特殊許可權操作時沒有申請許可權許可權而直接呼叫了相關程式碼，你的App可能就崩潰了，綜上所述你需要注意：

  • 此類許可權也必須在Manifest中申明，否則申請時不提示使用者，直接回調開發者許可權被拒絕。
  • 同一個許可權組的任何一個許可權被授權了，這個許可權組的其他許可權也自動被授權。例如一旦WRITE_CONTACTS被授權了，App也有READ_CONTACTS和GET_ACCOUNTS了。
  • 申請某一個許可權的時候系統彈出的Dialog是對整個許可權組的說明，而不是單個許可權。例如我申請READ_EXTERNAL_STORAGE，系統會提示"允許xxx訪問裝置上的照片、媒體內容和檔案嗎？"。

如果App執行在Android 5.1 (API level 22)或者更低級別的裝置中，或者targetSdkVersion<=22時（此時裝置可以是Android 6.0 (API level 23)或者更高），在所有系統中仍將採用舊的許可權管理策略，系統會要求使用者在安裝的時候授予許可權。其次，系統就告訴使用者App需要什麼許可權組，而不是個別的某個許可權。

  • CALENDAR（日曆）
    • READ_CALENDAR
    • WRITE_CALENDAR
  • CAMERA（相機）
    • CAMERA
  • CONTACTS（聯絡人）
    • READ_CONTACTS
    • WRITE_CONTACTS
    • GET_ACCOUNTS
  • LOCATION（位置）
    • ACCESS_FINE_LOCATION
    • ACCESS_COARSE_LOCATION
  • MICROPHONE（麥克風）
    • RECORD_AUDIO
  • PHONE（手機）
    • READ_PHONE_STATE
    • CALL_PHONE
    • READ_CALL_LOG
    • WRITE_CALL_LOG
    • ADD_VOICEMAIL
    • USE_SIP
    • PROCESS_OUTGOING_CALLS
  • SENSORS（感測器）
    • BODY_SENSORS
  • SMS（簡訊）
    • SEND_SMS
    • RECEIVE_SMS
    • READ_SMS
    • RECEIVE_WAP_PUSH
    • RECEIVE_MMS
  • STORAGE（儲存卡）
    • READ_EXTERNAL_STORAGE
    • WRITE_EXTERNAL_STORAGE

使用adb命令可以檢視這些需要授權的許可權組：

adb shell pm list permissions -d -g

使用adb命令同樣可以授權/撤銷某個許可權：

adb shell pm [grant|revoke] <permission-name>...

關於執行時許可權的一些建議

  1. 只請求你需要的許可權，減少請求的次數，或用隱式Intent來讓其他的應用來處理。

    1. 如果你使用Intent，你不需要設計介面，由第三方的應用來完成所有操作。比如打電話、選擇圖片等。
    2. 如果你請求許可權，你可以完全控制使用者體驗，自己定義UI。但是使用者也可以拒絕許可權，就意味著你的應用不能執行這個特殊操作。

  2. 防止一次請求太多的許可權或請求次數太多，使用者可能對你的應用感到厭煩，在應用啟動的時候，最好先請求應用必須的一些許可權，非必須許可權在使用的時候才請求，建議整理並按照上述分類管理自己的許可權：

    1. 普通許可權（Normal PNermissions）：只需要在Androidmanifest.xml中宣告相應的許可權，安裝即許可。
    2. 需要執行時申請的許可權（Dangerous Permissions）：
      • 必要許可權：最好在應用啟動的時候，進行請求許可的一些許可權（主要是應用中主要功能需要的許可權）。
      • 附帶許可權：不是應用主要功能需要的許可權(如：選擇圖片時，需要讀取SD卡許可權)。

  3. 解釋你的應用為什麼需要這些許可權：在你呼叫requestPermissions()之前，你為什麼需要這個許可權。

    1. 例如，一個攝影的App可能需要使用定位服務，因為它需要用位置標記照片。一般的使用者可能會不理解，他們會困惑為什麼他們的App想要知道他的位置。所以在這種情況下，所以你需要在requestpermissions()之前告訴使用者你為什麼需要這個許可權。

  4. 使用相容庫support-v4中的方法

ContextCompat.checkSelfPermission()
ActivityCompat.requestPermissions()
ActivityCompat.shouldShowRequestPermissionRationale()

幾個重要的方法與常量解釋

  • PackageManager中的兩個常量：

    • PackageManager.PERMISSION_DENIED：該許可權是被拒絕的。
    • PackageManager.PERMISSION_GRANTED：該許可權是被授權的。

  • Activity中或者Fragment都會有以下幾個方法：

int checkSelfPermission(String)
void requestPermissions(int, String...)
boolean shouldShowRequestPermissionRationale(String)
void onRequestPermissionsResult()

上述四個方法中，前三個方法在support-v4的ActivityCompat中都有，建議使用相容庫中的方法。最後一個方法是使用者授權或者拒絕某個許可權組時系統會回撥Activity或者Fragment中的方法。

checkSelfPermission() 檢查許可權

  1. 檢查某一個許可權的當前狀態，你應該在請求某個許可權時檢查這個許可權是否已經被使用者授權，已經授權的許可權重複申請可能會讓使用者產生厭煩。
  2. 該方法有一個引數是許可權名稱，有一個int的返回值，用這個值與上面提到的兩個常量做比較可判斷檢查的許可權當前的狀態。
if (ContextCompat.checkSelfPermission(context, Manifest.permission.READ_CONTACTS)
        != PackageManager.PERMISSION_GRANTED) {
    // 沒有許可權，申請許可權。
}else{
    // 有許可權了，去放肆吧。
}

requestPermissions() 申請許可權

  1. 請求使用者授權幾個許可權，呼叫後系統會顯示一個請求使用者授權的提示對話方塊，App不能配置和修改這個對話方塊，如果需要提示使用者這個許可權相關的資訊或說明，需要在呼叫 requestPermissions() 之前處理，該方法有兩個引數：
    • int requestCode，會在回撥onRequestPermissionsResult()時返回，用來判斷是哪個授權申請的回撥。
    • String[] permissions，許可權陣列，你需要申請的的許可權的陣列。
  2. 由於該方法是非同步的，所以無返回值，當用戶處理完授權操作時，會回撥Activity或者Fragment的onRequestPermissionsResult()方法。

對於Activity我們直接呼叫requestPermissions(int, String[])即可，不過這個方法是在api leve 23以上，所以我們為了適配可以是使用相容包提供的方法：

ActivityCompat.requestPermissions(activity, new String[]{Manifest.permission.READ_CONTACTS}, MMM);

對於support包的Fragment就可以直接呼叫requestPermissions(int, String[])，對於app包的Fragment就需要做版本判斷了，這樣就顯得比較麻煩。

onRequestPermissionsResult() 處理許可權結果回撥

  1. 該方法在Activity/Fragment中應該被重寫，當用戶處理完授權操作時，系統會自動回撥該方法，該方法有三個引數：
    • int requestCode，在呼叫requestPermissions()時的第一個引數。
    • String[] permissions，許可權陣列，在呼叫requestPermissions()時的第二個引數。
    • int[] grantResults，授權結果陣列，對應permissions，具體值和上方提到的PackageManager中的兩個常量做比較。
@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MMM: {
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // 許可權被使用者同意，可以去放肆了。
            } else {
                // 許可權被使用者拒絕了，洗洗睡吧。
            }
            return;
        }
    }
}

shouldShowRequestPermissionRationale()

  1. 望文生義，是否應該顯示請求許可權的說明。
  2. 第一次請求許可權時，使用者拒絕了，呼叫shouldShowRequestPermissionRationale()後返回true，應該顯示一些為什麼需要這個許可權的說明。
  3. 使用者在第一次拒絕某個許可權後，下次再次申請時，授權的dialog中將會出現“不再提醒”選項，一旦選中勾選了，那麼下次申請將不會提示使用者。
  4. 第二次請求許可權時，使用者拒絕了，並選擇了“不再提醒”的選項，呼叫shouldShowRequestPermissionRationale()後返回false。
  5. 裝置的策略禁止當前應用獲取這個許可權的授權：shouldShowRequestPermissionRationale()返回false 。
  6. 加這個提醒的好處在於，使用者拒絕過一次許可權後我們再次申請時可以提醒該許可權的重要性，免得再次申請時使用者勾選“不再提醒”並決絕，導致下次申請許可權直接失敗。

綜上所述，整合程式碼後：

if (ContextCompat.checkSelfPermission(this, Manifest.permission.READ_CONTACTS) != PackageManager.PERMISSION_GRANTED) {
    // 沒有許可權。
    if (ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.READ_CONTACTS)) {
            // 使用者拒絕過這個許可權了，應該提示使用者，為什麼需要這個許可權。
    } else {
        // 申請授權。
        ActivityCompat.requestPermissions(thisActivity, new String[]{Manifest.permission.READ_CONTACTS}, MMM);
    }
}

...

@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MMM: {
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // 許可權被使用者同意，可以去放肆了。
            } else {
                // 許可權被使用者拒絕了，洗洗睡吧。
            }
            return;
        }
    }
}

總結

從上面來看，判斷很多，邏輯也很多，這樣就加重了我們開發的負擔，加上很多人反饋說國產手機有各種各樣的bug，這樣相容起來就更加麻煩了，那麼下面我就為大家介紹一個開源內褲來解決這一系列問題。

AndPermission

  • Gradle
compile 'com.yanzhenjie:permission:1.0.6'
  • Maven
<dependency>
  <groupId>com.yanzhenjie</groupId>
  <artifactId>permission</artifactId>
  <version>1.0.5</version>
  <type>pom</type>
</dependency>
  • Eclipse 請放棄治療

使用介紹

我建議看官去Github下載Demo並閱讀本文會幫助你理解。

申請許可權

// 在Activity：
AndPermission.with(activity)
    .requestCode(100)
    .permission(Manifest.permission.WRITE_CONTACTS)
    .rationale(...)
    .callback(...)
    .start();

// 在Fragment：
AndPermission.with(fragment)
    .requestCode(100)
    .permission(
        // 多個許可權，以陣列的形式傳入。
        Manifest.permission.WRITE_CONTACTS,
        Manifest.permission.READ_SMS
    )
    .rationale(...)
    .callback(...)
    .start();

// 在其它任何地方：
AndPermission.with(context)
    .requestCode(100)
    .permission(
        Manifest.permission.WRITE_CONTACTS,
        Manifest.permission.READ_SMS
    )
    .rationale(...)
    .callback(...)
    .start();

接受回撥結果

接受回撥結果目前有兩種方式：一、Listener方式，二、註解方式。

方式一：Listener方式回撥

在callback()方法傳入PermissionListener即可，授權成功或者失敗至少會回撥其中一個方法。

AndPermission.with(context)
    ...
    .requestCode(200)
    .callback(listener)
    .start();

private PermissionListener listener = new PermissionListener() {
    @Override
    public void onSucceed(int requestCode, List<String> grantedPermissions) {
        // 許可權申請成功回撥。

        // 這裡的requestCode就是申請時設定的requestCode。
        // 和onActivityResult()的requestCode一樣，用來區分多個不同的請求。
        if(requestCode == 200) {
            // TODO ...
        }
    }

    @Override
    public void onFailed(int requestCode, List<String> deniedPermissions) {
        // 許可權申請失敗回撥。
        if(requestCode == 200) {
            // TODO ...
        }
    }
};

方式二：註解方式回撥

在callback()方法傳入你的回撥方法所在例項的物件即可。

AndPermission.with(context)
    ...
    .requestCode(300)
    .callback(this)
    .start();

// 成功回撥的方法，用註解即可，這裡的300就是請求時的requestCode。
@PermissionYes(300)
private void getPermissionYes(List<String> grantedPermissions) {
    // TODO 申請許可權成功。
}

@PermissionNo(300)
private void getPermissionNo(List<String> deniedPermissions) {
    // TODO 申請許可權失敗。
}

如果你會用了，你就可以大刀闊斧的幹了，部落格中講到的各種複雜邏輯，AndPermission自動完成。

Rationale能力

Android執行時許可權有一個特點，在拒絕過一次許可權後，再此申請該許可權，在申請框會多一個[不再提示]的複選框，當用戶勾選了[不再提示]並拒絕了許可權後，下次再申請該許可權將直接回調申請失敗。
因此Rationale功能是在使用者拒絕一次許可權後，再次申請時檢測到已經申請過一次該許可權了，允許開發者彈窗說明申請許可權的目的，獲取使用者的同意後再申請許可權，避免使用者勾選不再提示，導致不能再次申請許可權。

方式一：使用AndPermssion預設MD風格對話方塊

AndPermission.with(this)
    ...
    .requestCode(...)
    .rationale((requestCode, rationale) ->
        // 此對話方塊可以自定義，呼叫rationale.resume()就可以繼續申請。
        AndPermission.rationaleDialog(context, rationale).show()
    )
    .start()

方式二：自定義對話方塊

AndPermission.with(this)
    ...
    .requestCode(...)
    .rationale(rationaleListener)
    .start()

/**
 * Rationale支援，這裡自定義對話方塊。
 */
private RationaleListener rationaleListener = (requestCode, rationale) -> {
    AlertDialog.newBuilder(this)
        .setTitle("友好提醒")
        .setMessage("你已拒絕過定位許可權，沒有定位定位許可權無法為你推薦附近的妹子，你看著辦！")
        .setPositiveButton("好，給你", (dialog, which) -> {
            rationale.resume();
        })
        .setNegativeButton("我拒絕", (dialog, which) -> {
            rationale.cancel();
        }).show();
};

提示使用者在系統設定中授權

當用戶拒絕許可權並勾選了不再提示時，此時再次申請許可權時將會直接回調申請失敗，因此AndPermission提供了一個供使用者在系統Setting中給我們授權的能力。

我們在授權失敗的回撥方法中新增如下程式碼，以下三種選擇一種即可：

// 是否有不再提示並拒絕的許可權。
if (AndPermission.hasAlwaysDeniedPermission(activity, deniedPermissions)) {
    // 第一種：用AndPermission預設的提示語。
    AndPermission.defaultSettingDialog(activity, 400).show();

    // 第二種：用自定義的提示語。
    AndPermission.defaultSettingDialog(activity, 400)
    .setTitle("許可權申請失敗")
    .setMessage("您拒絕了我們必要的一些許可權，已經沒法愉快的玩耍了，請在設定中授權！")
    .setPositiveButton("好，去設定")
    .show();

    // 第三種：自定義dialog樣式。
    SettingService settingService = AndPermission.defineSettingDialog(activity, 400);
    ...
    // 你的dialog點選了確定呼叫：
    settingService.execute();
    // 你的dialog點選了取消呼叫：
    settingService.cancel();
}

如果你是在Activity/Fragment中呼叫的上述程式碼，那麼當用戶在系統Setting中操作完成後，會回撥Activity/Fragment中的這個方法： 

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    switch (requestCode) {
        case 400: { // 這個400就是你上面傳入的數字。
            // 你可以在這裡檢查你需要的許可權是否被允許，並做相應的操作。
            break;
        }
    }
}

混淆

  1. 如果使用Listener接受回撥結果，不用任何配置。
  2. 使用註解的方式回撥結果，在proguard中新增如下配置：
-keepclassmembers class ** {
    @com.yanzhenjie.permission.PermissionYes <methods>;
}
-keepclassmembers class ** {
    @com.yanzhenjie.permission.PermissionNo <methods>;
}

國產手機適配方案

AndPermission是嚴格按照Android系統的執行時許可權設計的，並最大限度上相容了國產手機，目前發現的國產手機bug及解決方案：

  • 部分中國廠商生產手機（例如小米某型號）的Rationale功能，在第一次拒絕後，第二次申請時不會返回true，並且會回撥申請失敗，也就是說在第一次決絕後預設勾選了不再提示，所以建議一定使用SettingDialog：提示使用者在系統設定中授權。
  • 部分中國廠商生產手機（例如小米、華為某型號）在申請許可權時，使用者點選確定授權後，還是回撥我們申請失敗，這個時候其實我們是擁有許可權的，所以我們可以在失敗的方法中使用AppOpsManager進行許可權判斷，AndPermission已經封裝好了：
if(AndPermission(context, permission1, permission2)) {
    // 執行操作。
}
  • 部分中國廠商生產手機（例如vivo、pppo某型號）在使用者允許許可權，並且回調了許可權授權陳功的方法，但是實際執行程式碼時並沒有這個許可權，建議開發者在回撥成功的方法中也利用AppOpsManager判斷下：
if(AndPermission(context, permission1, permission2)) {
    // 執行操作。
} else {
    // 提醒使用者手機問題，請使用者去Setting中授權。這裡可以使用AndPermission的SettingDialog。
}
  • 部分開發者反饋，在某些手機的Setting中授權後實際，檢查時還是沒有許可權，部分執行程式碼也是沒有許可權，這種手機真的相容不到了，我也覺得沒必要相容了，建議直接放棄這種平臺。

最後希望咱中國Android手機廠商早日修復這些問題，祝你們事業越來越成功，產品越做越好。

相關推薦

Android 6.0 執行時許可權管理最佳實踐

這是一篇遲來的部落格，Android M已經發布一年多了（6.0的變化），在Android M中許可權系統被重新設計，發生了顛覆性的變化，很多人把握不好這個變化，一是對這個許可權策略和套路還沒有摸透，二是沒有一個很好的實踐來支撐，在我的技術開發群裡很多人問我

Android 6.0執行時許可權勾選不再詢問後該如何處理？

Android 6.0執行時許可權勾選不再詢問後該如何處理？ 當第一次請求許可權申請被拒絕後再進行第二次申請時，對話方塊中會多出一個 不再詢問 的複選框。如果勾選了該複選框並且拒絕請求，那麼以後將無法再申請該許可權。也就是說在呼叫 requestPermissions() 後，onRequest

Android 6 0 執行時許可權處理

分享一下我老師大神的人工智慧教程！零基礎，通俗易懂！http://blog.csdn.net/jiangjunshow 也歡迎大家轉載本篇文章。分享知識，造福人民，實現我們中華民族偉大復興！        

Android 6 0 執行時許可權處理完全解析

                     一、概述ok，本篇文章目的之一就是對執行時許可權處理的一個介紹，以及對目前許可權相關的庫的一些瞭解。當然非常推薦閱讀官網許可權相關文章：本文也是在上述文章基礎上理解、實驗以及封裝。二、執行時許可權的變化及特點對於6.0以下的許可權及在安裝的時候，根據許可權宣告產生一個

以呼叫系統相機拍照為例瞭解Android 6.0執行時許可權

首先扯點別的，聽說這個週末是好天氣，想約她一起去公園賞賞梅花，只有我自己估計她也不一定去啊，哈哈。 在android6.0及以上系統，Android在安裝一個應用的時候不再需要列出一大堆許可權，讓使用者點選同意以後才可以安裝。Instead， 當應用在執行的時

談談Android 6.0執行時許可權理解

前言 　谷歌在2015年8月份時候，釋出了Android 6.0版本，代號叫做“棉花糖”（Marshmallow ），其中的很大的一部分變化，是在使用者許可權授權上，或許是感覺之前預設授權的不合理，現在6.0出來，使得使用者許可權授權變得合理。這可能也是參考IOS系統的，只有在使用者需要使用許可權的時候，才

Android 6.0執行時許可權申請和一些坑

1.概述 大家知道在Android6.0（Api23）之前,使用者許可權的申請都是在AndroidManifest.xml 宣告的，而在6.0之後，對某些涉及到使用者隱私的許可權可在執行時根據使用者的需要動態授予。如果你的應用設定targetSdkVersio

Android 6.0 執行時許可權處理

執行時許可權介紹 Android 6.0在我們原有的AndroidManifest.xml宣告許可權的基礎上， 又新增了執行時許可權動態檢測，以下許可權都需要在執行時判斷： 執行時許可權處理 Android6.0系統預設為targetSdkVersion小於23的應用預設授予了所申請的所有許可權，

android 6.0執行時許可權應用之相簿圖片選取

public class MainActivity extends AppCompatActivity { public static final int REQUEST_CODE=200; public static final int REQUEST_C

Android 6.0 執行時許可權處理完全解析

一、概述 ok，本篇文章目的之一就是對執行時許可權處理的一個介紹，以及對目前許可權相關的庫的一些瞭解。 當然非常推薦閱讀官網許可權相關文章： 本文也是在上述文章基礎上理解、實驗以及封裝。 二、執行時許可權的變化及特點 對於6.0以下

Android 6.0 執行時許可權檢查分析

Android版本升級到6.0之後，為了一改往日安全受人詬病的形象，將許可權授權的安裝時授予的基礎上，對於一部分危險的許可權採用動態控制授權的方式。類似國內手機安全助手許可權控制的功能。一、許可權控制組： 以上的9組許可權在本次修改的範圍之內，可能有人要問了，明明有一些許可

Android 6.0執行時許可權第三方庫的使用-----RxPermissions

執行時許可權的講解在前一篇部落格已經算是說的比較清楚了，這裡就不說了，如果對6.0這個新特性不是很瞭解的朋友建議先看看（地址：http://blog.csdn.net/qq_33923079/article/details/53428756），那麼本篇就直接說怎

Android 6.0 執行時許可權

什麼時候需要考慮執行時許可權 執行時許可權是Android6.0推出的安全機制，當你的app執行在 Android 6.0 及以上裝置上，使用危險許可權（下面介紹）的時候。 既targetSdkVer

Android 6.0 執行時許可權機制瞭解與應用

  目前的安卓手機系統版本普遍都在5.0、6.0以上甚至7.0、8.0。在Andorid 6.0系統之後開始引入了執行時許可權這個機制。許可權機制在android中原本就有的在manifest中編寫的permission標籤，而新增的執行時許可權則是將容易暴露使用者隱私的一些

Android 6.0執行時獲取許可權詳解

最近在工作過程中會遇到，明明已經在AndroidManifest.xml中配置了許可權，但是就是沒有作用，百度了之後才發現現在在應用系統大於等於6.0的手機上面，需要動態的獲取許可權。就是當你需要這個許可權的時候，需要手機給使用者一個提示選擇是否同意開啟這個許

6.0執行時許可權與targetSdkVersion選擇

targetSDKVersion 簡單來說就代表著你的App能夠適配的系統版本，意味著你的App在這個版本的手機上做了充分的 前向 相容性處理和實際測試。其實我們寫程式碼時都是經常幹這麼一件事，就是 if(Build.VERSION.SDK_INT >= 23) {

安卓6.0執行時許可權處理方案

    許可權檢查一般放在APP的入口，比如說閃屏頁splashactivity中或者baseapplication中。     其中需要兩個類，一個是PermissionChecker，一個是PermissionsActivity。第一個是用來檢測當前是否已經獲取到了申請

談談Android 6.0 的動態許可權管理

1.前言 大家都知道Android 6.0的新特性之一就是應用許可權的管理。也就是說凡是涉及使用者隱私的許可權，使用者可以自己去設定管理了。然而在6.0以前，我們安裝一款APP是默認同意此APP所需的所有許可權（比如定位、訪問通訊錄），不同意就不能安裝。當然，

Android 6.0動態申請許可權時，許可權框閃一下就消失的問題；

Android 藍芽BLE開發需要位置許可權，不然掃描不到周圍的藍芽資訊； 位置許可權申請： if (Build.VERSION.SDK_INT < 23){return;} //判斷是否有許可權 if (ContextCompat.checkSelfPermis

Android學習筆記-Android6.0執行時許可權

Android許可權機制，在Android6.0之前，其實一直很簡單，在AndroidManifest.xml中進行許可權宣告，通過一個Intent呼叫即可。 以打電話為例： <uses-permission android:name="andro