android6.0之前，所有的許可權都要求同意之後，app才能被安裝。6.0之後，動態許可權申請很好的處理了之前的強制行為，對使用者更加的友好。

新的許可權機制，將許可權分為兩大類，一種普通許可權，一種為危險許可權。普通許可權，在manifest中申請後，無需再主動申請；危險許可權，除了在manifest中申請，還需要主動呼叫API進行動態申請。如果你未在manifest中寫明危險許可權，即時通過API進行主動申請，也是無效的。

針對新的許可權機制，我們需要對許可權有個簡單的封裝，方便我們在專案中使用。

封裝方法如下：

 /**
     * 標準許可權檢查方法
     * 檢查所有的許可權，對未擁有的許可權進行主動申請。對已被拒絕的許可權，回撥處理。
     * @param permissions
     */
    public static void checkPermissions(Activity activity, int requestCode,OnDeniedListener listener, String... permissions) {
        //用於記錄未授權的許可權列表。
        ArrayList<String> deniedPermissions = new ArrayList<>();
        for (String permission : permissions) {
            //檢測未授權的許可權列表
            if (ActivityCompat.checkSelfPermission(activity, permission) == PERMISSION_DENIED) {
                //新增到許可權集合中
                deniedPermissions.add(permission);

            }
        }
        //遍歷未擁有的許可權
        for (String permission : deniedPermissions) {
            //如果該使用者已經點選不再提醒或拒絕，那麼返回true,說明使用者不想看到提醒許可權。

            boolean res = ActivityCompat.shouldShowRequestPermissionRationale(activity, permission);
            if (res) {
                Logger.i(permission + "");
                // 提示使用者未開啟許可權，說明為什麼要開啟許可權。然後引導使用者跳轉系統許可權設定介面。可以指定permission進行處理
                if(listener!=null)
                    listener.onDenied(permission);
                return;
            }
        }
        String[] ps = deniedPermissions.toArray(new String[deniedPermissions.size()]);
        if (ps.length > 0)
            ActivityCompat.requestPermissions(activity, ps, requestCode);


    }


    //檢測到使用者有許可權被拒絕不再提醒，進行回撥
    public interface OnDeniedListener{
        void onDenied(String permission);
    }
 

這種寫法中，判斷了shouldShowRequestPermissionRationale。這個方法作用是什麼？

我們看原始碼說明（蹩腳的英語翻譯）：

得到一個返回值，表示你是否應該向申請的許可權展示原理。如果你還沒有該許可權，並且你還沒有明確地向用戶表現出使用者同意該許可權後的好處，你都應該呼叫該方法。

例如，你編寫了一個照相app，請求相機許可權在使用者的意料之中，不用解釋為什麼需要這個許可權。然而，這個app還需要通過定位標識照片，一個不懂技術的使用者就想知道這個定位和拍照有什麼關係。這種情況下，你可能需要選擇展示該許可權的基本原理。

/**
     * 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.
     *
     * @see #checkSelfPermission(android.content.Context, String)
     * @see #requestPermissions(android.app.Activity, String[], int)
     */
    public static boolean shouldShowRequestPermissionRationale(@NonNull Activity activity,
            @NonNull String permission) {
        if (Build.VERSION.SDK_INT >= 23) {
            return activity.shouldShowRequestPermissionRationale(permission);
        }
        return false;
    }
 

危險許可權列表：

許可權組概念：同一許可權組中，如果已有一項危險許可權被授權，則同一組的其他許可權系統會立即授予該許可權，而無需與使用者進行任何互動。

注意：經過實踐測試，許可權組中更危險的許可權申請後，才會直接獲得其他許可權。怎麼理解這句話？比如定位許可權，如果你申請了FINE許可權，則直接就擁有COARSE許可權；如果你只申請了COARSE許可權，則還沒有FINE許可權，你必須要手動再申請FINE許可權，但這時不需要使用者同意就直接獲取了FINE許可權（如果都沒申請，是需要使用者手動點確認的）。還有讀寫儲存許可權也是一樣。

雖然都是簡單的東西，記錄下來，能方便自己檢視。