隨著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