校驗requestcode是否合法：
繼續接着上一次https://www.cnblogs.com/webor2006/p/12757460.html的權限申請框架源碼進行分析，這一次則需要分析最最核心的API了：
這塊稍復雜一些，慢慢來，不着急：
所以此條件是滿足的，看一下它里面做了啥？
Activity.requestPermissions()：
繼續往下：
這個目前咱們還木有重寫過，所以先放一放，先繼續往下分析着，回頭再來分析它：
那咱們來看一下構建這個Intent的細節：
那怎么來驗證這一點呢？其實我們可以運行用adb dump一下Activity的信息就能驗證出來，下面來試一下，先在manifest中添加訪問SDcard的權限：
然后再運行一下：
此時來看一下這個權限彈窗是不是一個Activity，如下：
此時會輸出一大堆東西，在最后可以看到相關Activity的信息，如下：
確實是的，那咱們瞅一下這個Activity源碼，上AndroidXRef上看一下：
分析GrantPermissionsActivity授權界面的邏輯：
看一下onCreate()的邏輯：
記得這里設置了一個監聽回調，在下面的分析中會要用到的：
而最終UI的顯示也是封裝在GrantPermissionsViewHandlerImpl中的，如下：
咱們重點來分析一下授權的邏輯，當然我們得點擊界面的“始終允許”按鈕，所以看一下點擊事件的邏輯：
此時則回到Activity中來：
PackageManager.grantRuntimePermission()：
接下來就可以回到Android Studio中來查看進一步的授權細節了：
找具體實現類：
此時又有IBinder通訊了，到PackageManagerService中來查找一下：
而它又往里調用了，注意這里有一個回調，最終結果的處理都會回到這個回調里面來分析的：
繼續往里跟進去：
然后分析關鍵代碼，此時就會到這：
好，回到主流程繼續：
此時則回到上面提到的回調中來看一下回調處理：
其實也就是寫到配置文件當中了，這里就不細分析了，再回到授權的主界面來，此時就會執行到這了：
onRequestPermissionsResult()回調處理：
此時授權界面就消失了，接下來則會回到執行我們界面的Activity.onResume()方法，而底層最終會執行到這：
然后跟進去：
其中REQUEST_PERMISSIONS_WHO_PREFIX還記得是在哪傳遞的么？就是在我們申請權限時傳遞的，回憶一下：
所以看一下這塊的邏輯：
此時咱們就可以在咱們自己的Activity重寫這個方法處理授權邏輯了：
至此整個申請授權的主流程就分析完了，還是很多細節的。
總結：
最后用圖來總結一下整體授權的流程：
