据说 Android 9.0 要禁用 @Hide Api 的调用，你怎么看？

Android 9.0?

Hi，你们好，我是承香墨影！

距离 Android 8.0 发布，已通过了五个月，虽然如今占有率并不高，不过呢，Google 已经着手准备下一版本的 Android 系统。

上周，据快科技爆出来的消息，在 XDA社区 有人发现最近的 AOSP（Android Open Source Project）提交记录中，怀疑是下一代 Android 系统版本的代码：PI，这多是 Android 9.0 的版本名称。不过根据 Android 以前版本的命名习惯，Google 钟爱使用甜点来命名版本，不少人猜想 Pi多是 Pie（馅饼）的缩写。

在 AOSP 最新的 commit 中，还暴露出来一些特别的信息，可能会开始限制一些没有被文档说起的非公开 APIs 的调用，例如被标记为 @hide 的 APIs。

上面是 commit 的截图，有兴趣能够去这里 AOSP 里看看细节。

https://android-review.googlesource.com/c/platform/external/doclava/+/589515

简单看了一下这个 commit 的改动，能够看到，在 Stubs 中增长了一个 privateDexApiWriter，应该是用来记录这些被标记为 @hide 的方法。

具体用来作什么的，也没有深刻深究，不过单纯从这个 commit 里看到的内容猜想，应该是要着手限制一些 @hide APIs 的访问。

那么咱们继续开一下脑洞，想一想 Google 想要限制 @hide APIs 的调用，有那些须要考虑的。

@hide 方法

众所周知，Android 系统在迭代的过程当中，愈来愈重视安全这个因素。而有一些方法可能会涉及到系统安全、用户隐私或者其余一些缘由，总之有一些因素考量，在发布出来的时候，被 Google 标记为 @hide，表示并不但愿开发者去使用它们。

而这些标记为 @hide 的方法，咱们也是没法直接调用的，只能使用反射的方式去调用它们，这自己就是不安全的操做。

不过呢，咱们有时候确实为了实现一些功能，须要使用到这些被标记为 @hide 的方法。

从前面提到的 commit 的描述中，能够看到，这种限制是 Dex-level 层的，也就是它应该能够作到无视反射调用。例如加个权限限制，调用的时候判断无权调用则直接报错或者让你反射的时候调用，也没法起做用，其实都是限制的方式，如今还不用太深究原理。

Support Library

虽然 Google 是能够作到对 @hide 方法的限制的，不过有一点不知道你们注意到没有，那就是 Support Library 中，也包含了大量 @hide APIs 的调用。

例如最近说到的 Autosizing 功能的实现中，就专门用来写了一个方法，来作反射的调用，获取 TextView 中的一些属性值。

private <T> T invokeAndReturnWithDefault(@NonNull Object object, @NonNull final String methodName, @NonNull final T defaultValue) {
        T result = null;
        boolean exceptionThrown = false;

        try {
            // Cache lookup.
            Method method = getTextViewMethod(methodName);
            result = (T) method.invoke(object);
        } catch (Exception ex) {
            exceptionThrown = true;
            Log.w(TAG, "Failed to invoke TextView#" + methodName + "() method", ex);
        } finally {
            if (result == null && exceptionThrown) {
                result = defaultValue;
            }
        }

        return result;
    }
复制代码

Google 提供的一系列 Support Library 的库，本质上都是 Google 为开发者准备的一些 APIs 扩展包，可是它不一样于系统自己的 APIs。

咱们在开发 Android 的阶段，会指定一个 Api Level ，从 IDE 的表现来看，它会引用一个 android.jar ，本质上是为了咱们开发阶段可以成功编译而存在的，这个 Jar 包自己是不会被打包在 APK 中的。

在 Support Library 则不同，它只是 Google 提供的一个工具包，会真实的被编译进 APK 中，会占用 APK 的体积。这就是为何 Support v26 删除了一些方法来促使体积减少，是一件让人高兴的事情。

而若是 Google 对 @hide 方法进行了一刀切的限制以后，Support Library 中的一些功能，应该也会受到影响，由于本质上它就是咱们 Apk 中的代码，权限级别和咱们开发中编写的代码是同样的。

因此这就存在两个方向的问题：

一、区分来自 Support Library 的调用和开发者调用。

二、一刀切，直接修改 Support Library 源码和系统源码，从新审视那些如今被标记为 @hide 的方法，将那些不会影响安全和隐私的 APIs 所有开放出来，容许开发者调用。

下面咱们继续开脑洞，仔细说说这些的区别。

一、区分调用来源

若是 Google 有办法区分调用来自哪里，而后针对不一样的调用来源来实行不一样的调用权限控制。

对开发者而言，实际上就是有漏洞可让咱们模拟成一个来自 Support Library 的调用，就依然能够绕过不容许调用 @hide 方法的限制，这个明显是有隐患的。

二、一刀切

从现有 Support Library 中的代码能够看到，其实它使用的 @hide 方法，并不全都是涉及安全和隐私的。

就拿最近分析的 Autosizing 来讲，它其中大量的调用了一些 TextView 的诸如 getHorizontallyScrolling()、getLineSpacingMultiplier()、getLineSpacingExtra() 方法，这些方法其实并不触及安全和隐私。

只是为了拿个文本控件的属性而已，能有什么不安全或者不隐私的？慎重考虑以后，拿掉这些方法的 @hide 就行了，开放调用，就不须要区分那么多了。

结语

以上都是个人简单猜想和开脑洞后的想法，说了这么多，Android 依然为向着安全、易用的方向发展，因此不管是限制或是不限制，都是为了让用户好的使用。

对 Google 可能会限制 @hide APIs 的调用，你有什么独特的见解？欢迎在留言区分享！

今天在承香墨影公众号的后台，回复『成长』。我会送你一些我整理的学习资料。

我另外还维护了一个技术交流的微信群，有兴趣能够在公众号后台回复："加群"

推荐阅读：

• 站在Android开发的角度，聊聊Airbnb的Lottie
• 这些工具，让你写博客的时候，只须要专一写做！
• 找了一天找不到 Bug ? 试试 Git 的二分法吧！！！
• 如何更精准的在 Github 上搜索开源库？你须要这些技巧！
• Android 开发，赶上 Emoji 头疼吗？