隨著Android P預(yù)覽版的發(fā)布，谷歌在改進(jìn)系統(tǒng)穩(wěn)定性的措施上又增加了新的限制,即應(yīng)用程序引用非SDK接口，無(wú)論采用直接、反射、JNI獲取等手段都將受到限制。在谷歌提供的預(yù)覽版文檔&&App Compatibility Changes一節(jié)中，我們可以知道如下信息：

在Frameworkdocumented中列出了能訪(fǎng)問(wèn)的sdk

Android P.DP1提供了測(cè)試非SDK接口調(diào)用日志輸出

保留非SDK調(diào)用將會(huì)觸發(fā)的異常類(lèi)型

DP1限制效果預(yù)覽

在官方提供的鏡像環(huán)境下，當(dāng)運(yùn)行app時(shí),其調(diào)用非SDKMethods/ Fields(函數(shù)/字段)則會(huì)觸發(fā)保護(hù)機(jī)制而輸出如下日志信息：

Log Format：

Log header + Method/Field + API signatures+（Greylist, Callers）

Log Header日志頭部輸出標(biāo)識(shí)(Accessinghidden)

Method/Field表示當(dāng)前是方法還是字段

API signatures與文件中內(nèi)容格式等價(jià)

Methods

`class_descriptor>method_name(parameter_types)return_type`

Field編碼

`class_descriptor->field_name:field_type`

Greylist3個(gè)限制等級(jí)，分別由3個(gè)文件列表提供。

a)Light greylist

b)Dark greylist

c)blacklist

CallersJNI、reflection

實(shí)現(xiàn)原理

Greylist所列出的三個(gè)限制等級(jí)，其數(shù)據(jù)來(lái)源于3個(gè)文本文件，包含了要被限制的函數(shù)或者字段。它們位于系統(tǒng)源碼目錄，在系統(tǒng)源碼編譯階段完成從文本文件數(shù)據(jù)解析合并到dex格式文件的過(guò)程。(Dex文件中函數(shù)/字段被標(biāo)記階段，影響其access_flags_)

在art虛擬機(jī)內(nèi)部存在一個(gè)轉(zhuǎn)換過(guò)程。即將Dex格式中函數(shù)/字段被標(biāo)記的值再次轉(zhuǎn)換并存入art runtime訪(fǎng)問(wèn)標(biāo)志（access_flags_）。

App運(yùn)行時(shí)觸發(fā)任意系統(tǒng)函數(shù)調(diào)用，進(jìn)入art虛擬機(jī)內(nèi)部時(shí)根據(jù)art的訪(fǎng)問(wèn)標(biāo)志的值(access_flags_)識(shí)別出限制等級(jí)，從而達(dá)到限制非SDK調(diào)用的目的。

基于其上所描述，將分別從兩個(gè)維度(編譯階段,類(lèi)初始化階段(art) )進(jìn)行詳細(xì)介紹。

編譯階段

由編譯腳本控制3個(gè)文本文件

(hiddenapi-light-greylist.txt、hiddenapi-dark-greylist.txt、hiddenapi-blacklist.txt)

編譯腳本路徑：Framework/base/Android.mk

由編譯腳本可知道：

hiddenapi-blacklist.txt，hiddenapi-dark-greylist.txt來(lái)源于Framework/base/config目錄

hiddenapi-light-greylist.txt為private-dex.txt減去blacklist.txt與dark-greylist.txt的集合

（其中private-dex.txt位于目錄Out/target/common/obj/PACKAGING/）

注：

APIsignatures(函數(shù)/字段)在3個(gè)文件中具備唯一性

位于config目錄下的blacklist.txt、dark-greylist.txt內(nèi)容為。（用官方提供的鏡像測(cè)試發(fā)現(xiàn)存在dark-greylist數(shù)據(jù)，應(yīng)該是DP1源碼中末提供此數(shù)據(jù)）、

private-dex.txt為聲明私有方式的集合數(shù)據(jù)(此處待驗(yàn)證)

2.編譯階段生成hiddenapi

源碼位于: art/tools/hiddenapi

生成host可執(zhí)行程序：out/host/linux-x86/bin/hiddenapi

Linux-x86:編譯平臺(tái)和生成目錄對(duì)應(yīng)

3.處理dex、jar

在滿(mǎn)足1、2的前提下，在對(duì)應(yīng)的目錄下將會(huì)包含所需文件與程序，此時(shí)即可對(duì)dex進(jìn)行處理。經(jīng)過(guò)hiddenapi處理后，將完成對(duì)指定Dex文件中所有函數(shù)/字段重新標(biāo)記，通過(guò)修改其access_flags_字段值實(shí)現(xiàn)。

hiddenapi運(yùn)行參數(shù)：--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

編譯時(shí)腳本

路徑：build/core/definitions.mk

在源碼編譯后，請(qǐng)自行查閱編譯日志build-aosp_walleye.ninja（設(shè)備pixel 2）。

4.Hiddenapi解析

1）遍歷class.dex中的函數(shù)或者字段列表

2）IsOnApiList函數(shù)驗(yàn)證當(dāng)前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函數(shù)將2)中得到的二進(jìn)制數(shù)據(jù)與ClassDataMethod/ClassDataField結(jié)構(gòu)體中成員access_flags_原始值進(jìn)行處理后重新寫(xiě)入(注意leb128格式保存)

ClassDataMethod/ClassDataField結(jié)構(gòu)體成員access_flags_

b.其中access_flags_字段按bit存儲(chǔ)表示不同含義

Bit(2:0)表示存儲(chǔ)內(nèi)容為public(0b001)、private（0b010）、protect(0b100)

Bit(8)表示當(dāng)前method是native

算法原理：由2)步驟中得到值0bxx(低位)

如果值的低位為1，則原值與kAccVisibilityFlags進(jìn)行異或(^)操作

注：

access_flags_原值低3位有且只有一位標(biāo)記為1，其表示的意義為函數(shù)屬于(private、protect、public)中一種，當(dāng)經(jīng)過(guò)異或運(yùn)算后，新值低3位中有2位標(biāo)記為1.則表示低位已經(jīng)被寫(xiě)入。后續(xù)通過(guò)IsPowerOfTwo函數(shù)來(lái)校驗(yàn)access_flags_是否被修改。（校驗(yàn)思路：原值是否為2的冪次方，因?yàn)槿绻?的冪次方只能存在一個(gè)1）

算法原理：由2)步驟中得到值0bxx(高位)

如果值的高位為1，則根據(jù)access_flags_中第8位的原始值來(lái)決定與kAccDexHiddenBit/kAccDexHiddenBitNative進(jìn)行或(|)操作。

access_flags_第8位(bit8)表示native。

：非native：則取值為kAccDexHiddenBit

1: native則取值為kAccDexHiddenBitNative

4) 完成access_flags_值的讀取和寫(xiě)入，主要涉及以下函數(shù)

5) 最后一步，重新校驗(yàn)dex頭部簽名

5.Hiddenapi處理后，完成從3個(gè)文本文件數(shù)據(jù)與原始dex格式文件的合并，即生成新的dex。

類(lèi)初始化階段(art)

前面已經(jīng)分析過(guò)在編譯階段hiddenapi程序是如何將3個(gè)配置文件中每個(gè)函數(shù)/字段重新寫(xiě)入dex文件，在這個(gè)階段我們從ClassLinker中Loadfield/LoadMethod來(lái)分析如何將Dex結(jié)構(gòu)體中的access_flags_值轉(zhuǎn)換為Art Runtime時(shí)所需的值（art結(jié)構(gòu)體中access_flags_）。

以L(fǎng)oadField為例

文件位于art/runtime/class_liner.cc

1.此處校驗(yàn)是否是bootclassloader后，直接調(diào)用DecodeHiddenAccessFlags讀取Dex緩存中access_flag_的值。

2.DecodeHiddenAccessFlags調(diào)用的是HiddenApiAccessFlags中的DecodeFromDex函數(shù)

DecodeFromDex功能和EncodeFromDex是一個(gè)相反的過(guò)程。

EncodeFromDex將二進(jìn)制數(shù)據(jù)(0bXX)按格式存入dex結(jié)構(gòu)體中的access_flags_

DecodeFromDex讀取Dex結(jié)構(gòu)體中的access_flags_中的值。并將2位bit轉(zhuǎn)換為0~3的整數(shù)。等價(jià)于前面提到的

0b01 HiddenApiAccessFlags::kLightGreylist

0b10 HiddenApiAccessFlags::kDarkGreylist

0b11 HiddenApiAccessFlags::kBlacklist

那么對(duì)應(yīng)關(guān)系如下：

hiddenapi-light-greylist.txt (0b01)、

hiddenapi-dark-greylist.txt (0b10)、

hiddenapi-blacklist.txt (0b11)

3.最后進(jìn)入到EncodeForRuntime函數(shù)中，此函數(shù)的功能是將重新獲取的2位二進(jìn)制數(shù)據(jù)寫(xiě)入artmethod結(jié)構(gòu)體中access_flags_中。以方便在art運(yùn)行時(shí)進(jìn)行最后校驗(yàn)。

不同于dex文件中access_flags_的存儲(chǔ)方式，由上述代碼可知，此處通過(guò)左移的方式將這2位二進(jìn)制數(shù)據(jù)存儲(chǔ)到art結(jié)構(gòu)體中成員access_flags_的最高位。

4.在app運(yùn)行時(shí)，會(huì)校驗(yàn)artmethod結(jié)構(gòu)體中access_flags_最高2位的值

5.校驗(yàn)的手段包括直接調(diào)用、反射、JNI獲取

1)關(guān)鍵調(diào)用過(guò)程

運(yùn)行階段請(qǐng)自行查閱GetMethodID/GetFieldID調(diào)用流程，最終會(huì)進(jìn)入 到ShouldBlockAccessToMember這個(gè)函數(shù)進(jìn)行校驗(yàn)

2)校驗(yàn)過(guò)程

其校驗(yàn)函數(shù)：ShouldBlockAccessToMember

源碼位于：Art/runtime/hidden_api.h

其中，GetMemberAction調(diào)用HiddenApiAccessFlags中DecodeFromRuntime獲取其返回值

通過(guò)返回值，就可以清楚的看到當(dāng)前調(diào)用的函數(shù)或者字段是屬于哪個(gè)屬性。

kAllow = 0;此處對(duì)應(yīng)關(guān)系：

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中通過(guò)Action的行為來(lái)判斷：

0(0b00) kAllow直接放過(guò)

1(0b01) kAllowButWarn放過(guò)，但日志警告

2(0b10) kAllowButWarnAndToast放過(guò)，且日志警告和彈窗

3(0b11) kDeny拒絕

日志輸出函數(shù)

總結(jié)

本文基于Android P.DP1研究非sdk限制機(jī)制的核心思路，其中忽略了一些細(xì)節(jié)。限于篇幅后續(xù)根據(jù)穩(wěn)定版的改動(dòng)再補(bǔ)充。如果有問(wèn)題，歡迎大家在留言區(qū)指出與探討！

http://kuaibao.qq.com/s/20180327G17Y3L00?refer=spider

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。