莫道桑榆晚,为霞尚满天。这篇文章主要讲述听说 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 里看看细节。
【听说 Android 9.0 要禁用 @Hide Api 的调用,你怎么看()】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 中的代码,权限级别和我们开发中编写的代码是一样的。所以这就存在两个方向的问题:
1、区分来自 Support Library 的调用和开发者调用。
2、一刀切,直接修改 Support Library 源码和系统源码,重新审视那些现在被标记为
@hide
的方法,将那些不会影响安全和隐私的 APIs 全部开放出来,允许开发者调用。下面我们继续开脑洞,仔细说说这些的区别。
1、区分调用来源
如果 Google 有办法区分调用来自哪里,然后针对不同的调用来源来实行不同的调用权限控制。
对开发者而言,实际上就是有漏洞可以让我们模拟成一个来自 Support Library 的调用,就依然可以绕过不允许调用
@hide
方法的限制,这个明显是有隐患的。2、一刀切
从现有 Support Library 中的代码可以看到,其实它使用的
@hide
方法,并不全都是涉及安全和隐私的。就拿最近分析的 Autosizing 来说,它其中大量的调用了一些 TextView 的诸如
getHorizontallyScrolling()
、getLineSpacingMultiplier()
、getLineSpacingExtra()
方法,这些方法其实并不触及安全和隐私。只是为了拿个文本控件的属性而已,能有什么不安全或者不隐私的?慎重考虑之后,拿掉这些方法的
@hide
就好了,开放调用,就不需要区分那么多了。结语以上都是我的简单猜测和开脑洞后的想法,说了这么多,Android 依然为向着安全、易用的方向发展,所以无论是限制或是不限制,都是为了让用户好的使用。
对 Google 可能会限制
@hide
APIs 的调用,你有什么独特的看法?欢迎在留言区分享!今天在承香墨影公众号的后台,回复『成长』。我会送你一些我整理的学习资料。推荐阅读:
我另外还维护了一个技术交流的微信群,有兴趣可以在公众号后台回复:"加群"
- 站在Android开发的角度,聊聊Airbnb的Lottie
- 这些工具,让你写博客的时候,只需要专注写作!
- 找了一天找不到 Bug ? 试试 Git 的二分法吧!!!
- 如何更精准的在 Github 上搜索开源库?你需要这些技巧!
- Android 开发,遇上 Emoji 头疼吗?
文章图片
推荐阅读
- 5xamarin.android 中如何对AndroidManifest.xml 进行配置和调整
- 安卓ConstraintLayout布局
- tomcat会自动解压webapps目录下的war包
- Android studio 导入项目错误Plugin with id‘com.XXXX
- weex 启动 android 模拟器(mac环境)
- linphone-android-客户端APP-工程解读
- 公众号都要做APP了!
- Error:(27, 13) Failed to resolve: com.android.support.constraint:constraint-layout:1.0.2约束布局constrai
- MUIHbuilder设置夜神模拟器运行APP项目