首先需要强调的是，为什么要突破限制，因为安卓中许多技术需求需要使用系统隐藏 API 完成。目前大量的安卓应用都会通过反射或 JNI 方式使用到系统隐藏 API, 这其中包括几乎全部插件化框架，典型的是对 AssetManager 中隐藏 API 的使用。开发新的项目也不可避免地会使用到系统隐藏 API。Android P 的这一限制会导致许多安卓应用以及开源框架在 Android P 上运行出现崩溃。因此突破此限制有很重要的意义。
另外，目前的几个方法均已在 Android P(Preview 1) 的手机上测试通过，均为有效。只要将来放出的 Android P 源码依然使用此限制原理，那么这些方法就保证有效。
最后，文中的几种方法均不会产生副作用。
一、概要
本文基于对Android P(Preview 1)的源码分析,实现了三种绕过对调用隐藏API限制的方法,有效性均已得到验证，能够成功调用系统隐藏API。
二、限制原理
首先抛开Android P的具体实现过程，安卓系统要实现限制用户代码调用系统隐藏API，至少要做以下两个区分：
必须区分一个Method（或Field）对用户代码是隐藏的还是公开的。只有隐藏的才需要进行限制。
必须区分调用者的身份：是用户代码调用的还是系统代码（例如Activity类）调用的。只有用户代码调用时才需要进行限制。
具体到Android P的代码实现，它会在所有通过反射方式和JNI方式获取Method和Field的地方调用以下函数判断是否用户代码调用了系统的隐藏API(位于art/runtime/hidden_api.h），如果这个函数返回true，那么说明用户代码调用了系统的隐藏API，Android P（Preview1）会通过log发出警告，用户代码仍然能够获取到正确的Method或Field，在后续版本中获取到的Method或Field极有可能为空。
那么它是如何进行上述两个区分的呢？
每个Method（或Field）都有一个对应的access_flags_（uint32_t类型），原本这个值通过一些特定位（bit）表明其属性（public，private，static等），但是还有一些保留的未定义的位，Android P就利用未定义的几个位，表明这个Method（或Field）是对用户代码隐藏的还是公开的。
通过回溯调用栈找到调用者所在的Class，然后判断这个Class的ClassLoader是否为BootStrapClassLoader，如果是BoootStrapClassLoader那么就认为调用者是系统代码，否则就认为调用者是用户代码。fn_caller_in_boot就是一个函数指针，它用来判断调用者是否是BootStrapClassLoader，反射调用和JNI调用时fn_caller_in_boot指向不同的函数，具体细节可查看源码。
下面我们以调用android.app.ActivityThread类的currentActivityThread这个隐藏方法为例，讲解绕过限制的方法。
三、绕过方法
方法一
通过上面的论述结合源码分析，我们发现只有在通过反射方式和JNI方式获取Method和Field时，系统才有可能拦截对隐藏API的获取，也就是说直接调用是可以的！因此方法一的核心思想就是想方设法直接调用系统隐藏API。具体实现时需要用Provided方式提供Module或自定义android.jar。下面以一个例子说明实现过程。
我们新建一个普通的android工程，在其MainActivity中直接调用ActivityThread.currentActivityThread()；发现IDE提示找不到类ActivityThread，这是因为在sdk的android.jar（位于SDK/platforms/android-XX目录下）中并没有这个类的声明，但是在实际运行时这个类是存在于系统中的。我们的解决方法是以Provided方式提供一个Module，在此Module中提供需要的类（Provided方式是为了编译通过，这样的Module的代码并不会编译到最终的apk中）。具体操作如下：
新建一个Module，其类型为Java Library，命名为libfakeandroid，然后在app的build.gradle中以Provided方式依赖libfakeandroid
之后在libfakeandroid中新建一个类android.app.ActivityThread，并添加需要调用的隐藏API，如下
完成以上操作之后，MainActivity中就能直接调用ActivityThread.currentActivityThread()；方法了。在Android P（Preview1）系统上运行不会出现警告log，成功！
注意：如果需要调用的隐藏API所在的类已经位于android.jar中，Provided方式不再适用，此时需要自定义android.jar,将需要的Method或Field添加到android.jar中。
优点：实现起来非常简单方便，并且稳定性很好。
缺点：只能调用访问权限为public和default的Method和Field，不能直接调用protected和private的。
方法二