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

總結

以上是生活随笔為你收集整理的Android P 调用隐藏API限制原理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。