随着Android P預覽版的釋出，谷歌在改進系統穩定性的措施上又增加了新的限制,即應用程式引用非SDK接口，無論采用直接、反射、JNI擷取等手段都将受到限制。在谷歌提供的預覽版文檔&&App Compatibility Changes一節中，我們可以知道如下資訊：
在Frameworkdocumented中列出了能通路的sdk
Android P.DP1提供了測試非SDK接口調用日志輸出
保留非SDK調用将會觸發的異常類型
DP1限制效果預覽
在官方提供的鏡像環境下，當運作app時,其調用非SDKMethods/ Fields(函數/字段)則會觸發保護機制而輸出如下日志資訊：
Log Format：
Log header + Method/Field + API signatures+（Greylist, Callers）
Log Header日志頭部輸出辨別(Accessinghidden)
Method/Field表示目前是方法還是字段
API signatures與檔案中内容格式等價
Methods
`class_descriptor>method_name(parameter_types)return_type`
Field編碼
`class_descriptor->field_name:field_type`
Greylist3個限制等級，分别由3個檔案清單提供。
a)Light greylist
b)Dark greylist
c)blacklist
CallersJNI、reflection
實作原理
Greylist所列出的三個限制等級，其資料來源于3個文本檔案，包含了要被限制的函數或者字段。它們位于系統源碼目錄，在系統源碼編譯階段完成從文本檔案資料解析合并到dex格式檔案的過程。(Dex檔案中函數/字段被标記階段，影響其access_flags_)
在art虛拟機内部存在一個轉換過程。即将Dex格式中函數/字段被标記的值再次轉換并存入art runtime通路标志（access_flags_）。
App運作時觸發任意系統函數調用，進入art虛拟機内部時根據art的通路标志的值(access_flags_)識别出限制等級，進而達到限制非SDK調用的目的。
基于其上所描述，将分别從兩個次元(編譯階段,類初始化階段(art) )進行詳細介紹。
編譯階段
由編譯腳本控制3個文本檔案
(hiddenapi-light-greylist.txt、hiddenapi-dark-greylist.txt、hiddenapi-blacklist.txt)
編譯腳本路徑：Framework/base/Android.mk
由編譯腳本可知道：
hiddenapi-blacklist.txt，hiddenapi-dark-greylist.txt來源于Framework/base/config目錄
hiddenapi-light-greylist.txt為private-dex.txt減去blacklist.txt與dark-greylist.txt的集合
（其中private-dex.txt位于目錄Out/target/common/obj/PACKAGING/）
注：
APIsignatures(函數/字段)在3個檔案中具備唯一性
位于config目錄下的blacklist.txt、dark-greylist.txt内容為。（用官方提供的鏡像測試發現存在dark-greylist資料，應該是DP1源碼中末提供此資料）、
private-dex.txt為聲明私有方式的集合資料(此處待驗證)
2.編譯階段生成hiddenapi
源碼位于: art/tools/hiddenapi
生成host可執行程式：out/host/linux-x86/bin/hiddenapi
Linux-x86:編譯平台和生成目錄對應
3.處理dex、jar
在滿足1、2的前提下，在對應的目錄下将會包含所需檔案與程式，此時即可對dex進行處理。經過hiddenapi處理後，将完成對指定Dex檔案中所有函數/字段重新标記，通過修改其access_flags_字段值實作。
hiddenapi運作參數：--light-greylist=out/target/common/obj/PACKAGING/hiddenapi-light-greylist.txt--dark-greylist=out/target/common/obj/PACKAGING/hiddenapi-dark-greylist.txt --blacklist=out/target/common/obj/PACKAGING/hiddenapi-blacklist.txt
編譯時腳本
路徑：build/core/definitions.mk
在源碼編譯後，請自行查閱編譯日志build-aosp_walleye.ninja（裝置pixel 2）。
4.Hiddenapi解析
1）周遊class.dex中的函數或者字段清單
2）IsOnApiList函數驗證目前Method/Field是否存在檔案中，且能得到以下值中一種
HiddenApiAccessFlags::kWhitelist => 0b00
hiddenapi-light-greylist.txt=> HiddenApiAccessFlags::kLightGreylist => 0b01
hiddenapi-dark-greylist.txt => HiddenApiAccessFlags::kDarkGreylist=> 0b10
hiddenapi-blacklist.txt => HiddenApiAccessFlags::kBlacklist => 0b11
3）SetHidden函數将2)中得到的二進制資料與ClassDataMethod/ClassDataField結構體中成員access_flags_原始值進行處理後重新寫入(注意leb128格式儲存)
ClassDataMethod/ClassDataField結構體成員access_flags_
b.其中access_flags_字段按bit存儲表示不同含義
Bit(2:0)表示存儲内容為public(0b001)、private（0b010）、protect(0b100)
Bit(8)表示目前method是native
算法原理：由2)步驟中得到值0bxx(低位)
如果值的低位為1，則原值與kAccVisibilityFlags進行異或(^)操作
注：
access_flags_原值低3位有且隻有一位标記為1，其表示的意義為函數屬于(private、protect、public)中一種，當經過異或運算後，新值低3位中有2位标記為1.則表示低位已經被寫入。後續通過IsPowerOfTwo函數來校驗access_flags_是否被修改。（校驗思路：原值是否為2的幂次方，因為如果是2的幂次方隻能存在一個1）
算法原理：由2)步驟中得到值0bxx(高位)
如果值的高位為1，則根據access_flags_中第8位的原始值來決定與kAccDexHiddenBit/kAccDexHiddenBitNative進行或(|)操作。
access_flags_第8位(bit8)表示native。
：非native：則取值為kAccDexHiddenBit
1: native則取值為kAccDexHiddenBitNative
4) 完成access_flags_值的讀取和寫入，主要涉及以下函數
5) 最後一步，重新校驗dex頭部簽名
5.Hiddenapi處理後，完成從3個文本檔案資料與原始dex格式檔案的合并，即生成新的dex。
類初始化階段(art)
前面已經分析過在編譯階段hiddenapi程式是如何将3個配置檔案中每個函數/字段重新寫入dex檔案，在這個階段我們從ClassLinker中Loadfield/LoadMethod來分析如何将Dex結構體中的access_flags_值轉換為Art Runtime時所需的值（art結構體中access_flags_）。
以LoadField為例
檔案位于art/runtime/class_liner.cc
1.此處校驗是否是bootclassloader後，直接調用DecodeHiddenAccessFlags讀取Dex緩存中access_flag_的值。
2.DecodeHiddenAccessFlags調用的是HiddenApiAccessFlags中的DecodeFromDex函數
DecodeFromDex功能和EncodeFromDex是一個相反的過程。
EncodeFromDex将二進制資料(0bXX)按格式存入dex結構體中的access_flags_
DecodeFromDex讀取Dex結構體中的access_flags_中的值。并将2位bit轉換為0~3的整數。等價于前面提到的
0b01 HiddenApiAccessFlags::kLightGreylist
0b10 HiddenApiAccessFlags::kDarkGreylist
0b11 HiddenApiAccessFlags::kBlacklist
那麼對應關系如下：
hiddenapi-light-greylist.txt (0b01)、
hiddenapi-dark-greylist.txt (0b10)、
hiddenapi-blacklist.txt (0b11)
3.最後進入到EncodeForRuntime函數中，此函數的功能是将重新擷取的2位二進制資料寫入artmethod結構體中access_flags_中。以友善在art運作時進行最後校驗。
不同于dex檔案中access_flags_的存儲方式，由上述代碼可知，此處通過左移的方式将這2位二進制資料存儲到art結構體中成員access_flags_的最高位。
4.在app運作時，會校驗artmethod結構體中access_flags_最高2位的值
5.校驗的手段包括直接調用、反射、JNI擷取
1)關鍵調用過程
運作階段請自行查閱GetMethodID/GetFieldID調用流程，最終會進入 到ShouldBlockAccessToMember這個函數進行校驗
2)校驗過程
其校驗函數：ShouldBlockAccessToMember
源碼位于：Art/runtime/hidden_api.h
其中，GetMemberAction調用HiddenApiAccessFlags中DecodeFromRuntime擷取其傳回值
通過傳回值，就可以清楚的看到目前調用的函數或者字段是屬于哪個屬性。
kAllow = 0;此處對應關系：
0(0b00)：=>HiddenApiAccessFlags::kWhitelist
1(0b01)：hiddenapi-light-greylist.txt =>HiddenApiAccessFlags::kLightGreylist
2(0b10): hiddenapi-dark-greylist.txt =>HiddenApiAccessFlags::kDarkGreylist
3(0b11): hiddenapi-blacklist.txt =>HiddenApiAccessFlags::kBlacklist
AndroidP. DP1中通過Action的行為來判斷：
0(0b00) kAllow直接放過
1(0b01) kAllowButWarn放過，但日志警告
2(0b10) kAllowButWarnAndToast放過，且日志警告和彈窗
3(0b11) kDeny拒絕
日志輸出函數
總結
本文基于Android P.DP1研究非sdk限制機制的核心思路，其中忽略了一些細節。限于篇幅後續根據穩定版的改動再補充。如果有問題，歡迎大家在留言區指出與探讨！
http://kuaibao.qq.com/s/20180327G17Y3L00?refer=spider