0. 结论

从 Android 9（API 级别 28）开始，系统会限制APP通过反射或JNI调用非Andorid SDK的接口。
项目的业务代码可以通过全局搜索检查非SDK接口的使用情况。
几乎所有第三方SDK（包括Android support库！！）都有大量通过反射调用非SDK api的情况。通常反射调用时都有try-catch，能够保证应用不崩，但实际功能受影响的程度无法评估。

点击跳转官方文档链接

1. 为什么要限制？

目前，开发者对于非SDK API的调用，一般是采取反射或JNI间接调用的方法进行的。由于Android是开源的，所以开发者对非公有SDK的调用十分混乱，Google为了进一步防止碎片化，规范开发者的API使用行为，于是开始限制开发者通过反射或JNI间接调用非Android SDK提供的api。

这个变更会影响所有运行在9.0及以上的Android系统的APP，无论该APP是否已经升级了Target SDK。

2. 怎么限制？

起初Android9.0发布时，谷歌为非SDK接口制定了白名单（whitelist）、灰名单（greylist）、黑名单(blacklist）。

whitelist，白名单内的api可以正常被调用。
greylist，灰名单的api可以被调用，但未来更高的TargetSDK版本可能会将其列入黑名单。
blacklist，黑名单的api的调用在运行时会抛出异常，如果没有进行处理，将导致APP的Crash，即使进行了try-catch，这些反射的函数/变量也无成功被调用。

后面Android 10.0发布后，非SDK接口的划分变成了：

greylist 无限制，可以正常使用。
blacklist 无论什么版本的手机系统，使用这些api，系统将会抛出错误。
greylist-max-o 受限制的灰名单。APP运行在版本<=8.0的系统里可以正常访问，targetSDK>8.0且运行在>8.0的手机会抛出异常。
greylist-max-p 受限制的灰名单。APP运行在版本<=9.0的系统里可以正常访问，targetSDK>9.0且运行在>9.0的手机会抛出异常。

下表说明了当您的应用尝试访问黑名单或者在高版本手机上访问受限制的灰名单中的非 SDK 接口时可能会出现的异常：

访问方式	结果
Dalvik 指令引用某个字段	抛出 NoSuchFieldError
Dalvik 指令引用某个方法	抛出 NoSuchMethodError
通过 Class.getDeclaredField() 或 Class.getField() 进行反射	抛出 NoSuchFieldException
通过 Class.getDeclaredMethod()、Class.getMethod() 进行反射	抛出 NoSuchMethodException
通过 Class.getDeclaredFields()、Class.getFields() 进行反射	结果中未获取到非 SDK 成员
通过 Class.getDeclaredMethods()、Class.getMethods() 进行反射	结果中未获取到非 SDK 成员
通过 env->GetFieldID() 进行 JNI 调用	返回 NULL，抛出 NoSuchFieldError
通过 env->GetMethodID() 进行 JNI 调用	返回 NULL，抛出 NoSuchMethodError

3. 怎么检测出非SDK接口的使用？

先前去官网下载veridex工具包。
解压veridex-mac.zip，其中appcompat.sh就用来扫描APK的脚本，hiddenapi-flags.csv里就是官方列举的非SDK接口列表。
目前该工具仅支持mac和linux运行。

3.1 veridex 工具扫描 APK

自动但不太准确，使用veridex 工具扫描 APK 的整个代码库（包括所有第三方库），并在结果中列举出发现的所有使用非 SDK 接口的行为。这个方法非常方便，但由于扫描范围覆盖项目依赖的第三方库，出来的结果可能比较庞大（甚至有几百个处于黑/灰名单的非SDK 接口调用，其中还有不少误判。
具体方法：
把apk文件放到上述的脚本目录下，只需要执行以下命令即可输出扫描结果到result.txt里：

./appcompat.sh --dex-file=app-debug.apk  >>result.txt

脚本里可以带上 --imprecise（不精确的），扫描出来的hidden api调用会很多，但是也包含了很多误判。

./appcompat.sh --dex-file=app-debug.apk  --imprecise >>result.txt

扫描结果的示例如下：

#51: Reflection greylist-max-o Landroid/animation/TimeAnimator;->mListener potential use(s):
       Landroid/support/v4/app/FragmentManagerImpl;->getAnimationListener(Landroid/view/animation/Animation;)Landroid/view/animation/Animation$AnimationListener;
#94: Reflection greylist Lcom/android/internal/R$dimen;->status_bar_height use(s):
       Lcom/demo/common/utils/SystemUtils;->getStatusBarHeight(Landroid/app/Activity;)I
#1340: Reflection blacklist Lcom/android/org/conscrypt/SSLParametersImpl;->setApplicationProtocols potential use(s):
       Lokhttp3/internal/platform/Jdk9Platform;->buildIfSupported()Lokhttp3/internal/platform/Jdk9Platform;

107 hidden API(s) used: 24 linked against, 83 through reflection
       91 in greylist
       0 in blacklist
       1 in greylist-max-o
       15 in greylist-max-p

use(s):左边是被调用的非SDK的api，并非常详细地列出了包名、类名、函数名（or变量名），以及其所属的名单级别（greylist or blacklist）。
use(s):右边就是调用了非SDK api的项目代码的位置。

比如上面扫描结果告诉我们：

#51：谷歌的Android-support库中的FragmentManagerImpl通过反射调用了greylist-max-o灰名单中的android/animation/TimeAnimator的mListener变量。
很明显，我们无法修改support库中的源码，只能等官方自己修复。
#94：项目里的demo/common/utils/SystemUtils的getStatusBarHeight方法通过反射获取了com.android.internal.R$dimen类中的status_bar_height变量，属于通过反射调用灰名单的非SDK api，暂时是没有问题。
#1340：项目里的okhttp3/internal/platform/Jdk9Platform的buildIfSupported方法通过反射调用了com/android/org/conscrypt/SSLParametersImpl的setApplicationProtocols方法，属于通过反射调用黑名单里的非SDK api。
很明显，这里我们要注意评估项目中的okhttp通过反射调用黑名单api的行为，需要评估是否会引起崩溃（有无try-catch），是否在9.0以上机型造成功能异常，这个就需要开发者根据具体的业务情况去做具体分析了。

实践

最终我在项目里跑脚本./appcompat.sh --dex-file=app-debug.apk --imprecise得出的结果是：

1900 hidden API(s) used: 24 linked against, 1876 through reflection
437 in greylist
236 in blacklist
1156 in greylist-max-o
71 in greylist-max-p

仔细阅读过扫描结果后可以发现，几乎所有第三方SDK（包括Android support库！！）都有大量通过反射调用非SDK api的情况。通常反射调用时都有try-catch，能够保证应用不崩，但实际功能受影响的程度无法评估。
所以对第三方库的适配方法是查看官网更新日志，并对第三方库进行升级。比如高德地图官网更新日志显示已经适配Android P&Q。

高德地图早已适配Android P&Q

3.2 全局搜索业务代码

手动但比较准确，上述的veridex扫描虽然很快捷，但是输出结果包含了第三方库对非SDK接口的使用情况，对于一般项目来说绝大部分非SDK接口的调用都在第三方库上，在veridex扫描结果中排查项目业务代码对非SDK接口的调用情况比较困难。所以可以通过最原始的办法————全局搜索 JAVA反射相关的api（搜索上面的表格里的getField、getMethod等关键字），与官方给出的hidden api list（上面提到的hiddenapi-flags.csv）做比对，就很容易排查中业务代码里对非SDK接口的调用情况。

全局搜索getField，发现项目通过反射获取了Toast类中的mTN成员变量

上图全局搜索getField，发现项目通过反射获取了Toast类中的mTN成员变量，在官方提供的hiddenapi-flags.csv中可以发现该成员变量是非SDK接口，且属于greylist-max-p受限制的灰名单。即这个反射可以在版本<=9.0的系统里正常获取到mTN变量，但在targetSDK>9.0且运行在>9.0的手机会抛出异常，由于业务代码对反射调用进行了try-catch，所以实际业务中拿到的是一个null，这个时候我们就可以真切地感受到谷歌官方对非SDK接口的限制，并评估具体的业务影响。

image.png

4 总结

以上就是我们在对项目适配Android9.0的过程中，如何应用谷歌针对非SDK接口的限制的排查方法。
谷歌官方的建议有点扯淡：

如果您的应用依赖于非 SDK 接口，则应该开始计划迁移到 SDK 接口或其他替代方案。如果您无法为应用中的功能找到使用非 SDK 接口的替代方案，可以向谷歌官方申请新的公共 API。

网上也有总结了一些绕开非SDK接口限制的方法，可以参考突破Android P非SDK API限制的几种代码实现。

适配Android P之非SDK接口限制的排查方法