上篇：Android P 行为变更适配

Android P 这次有很多行为变更，其中不乏一些需要亟需适配的变更。

一、全面屏检测

在 Android 8.0 时代各个手机厂商就开始发布自己的全面屏手机，但是此时 Android 官方并未支持到该功能，所以各个厂商都各自实现了一套全面屏判断逻辑，对于开发者来说甚是麻烦。终于在 Android P 里官方收归了该功能的判断逻辑，Android P 和之后的版本完全可以使用官方 API 来判断全面屏，当然前提是第三方厂商按照 google 官方接口去实现。Android P 版本判断全面屏代码很简单，但是在适配过程中你可能会在网上发现如下判断代码：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    decorView.setOnApplyWindowInsetsListener(new View.OnApplyWindowInsetsListener() {
        @RequiresApi(api = 28)
        @Override
        public WindowInsets onApplyWindowInsets(View view, WindowInsets windowInsets) {
            if (windowInsets != null) {
                DisplayCutout cutout = windowInsets.getDisplayCutout();
                if (cutout != null) {
                    List<Rect> rects = cutout.getBoundingRects();
                    //通过判断是否存在rects来确定是否全面屏手机
                    if (rects != null && rects.size() > 0) {
                        isNotchScreen = true;
                    }
                }
            }
            return windowInsets;
        }
    });
}

这段代码确实可以判断出全面屏与否，但是会造成一个很严重的后果，就是在某些手机（pixel 和 vivo x21 均出现该情况）上底部导航栏会透明，导致应用内容会透到导航栏从而被遮挡，大大影响内容展示。最后经过仔细排查发现仅仅因为在上面那段代码中调用了 setOnApplyWindowInsetsListener 函数，该函数在 Android 官网有详细介绍，是用来在 Android 21 版本之后代替 fitSystemWindows 函数，目的是让 View 根据 Window 的缩进进行相应处理，调用后会影响系统状态栏和导航栏对应用内容的展示，对此的介绍资料网上有很多，就不赘述了。真正完美判断全面屏的代码如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.P) {
    WindowInsets windowInsets = decorView.getRootWindowInsets();
    if (windowInsets != null) {
        DisplayCutout displayCutout = windowInsets.getDisplayCutout();
        if (displayCutout != null) {
            List<Rect> rects = displayCutout.getBoundingRects();
            //通过判断是否存在rects来确定是否刘海屏手机
            if (rects != null && rects.size() > 0) {
                isNotchScreen = true;
            }
        }
    }
}

二、非 SDK API 适配详解

2.1 非 SDK API 名单介绍

Android P 版本最大最严格的特性变更应该非 SDK 接口限制莫属了。对于非 SDK API 里面的部分名单来说，就算在不修改 targetSdkVersion 的前提下，不管是直接、反射还是通过 JNI 调用都会造成调用失败、抛出 NoSuchFieldException或 NoSuchMethodException 等严重后果，该行为影响范围波及所有调用此接口的应用。

非 SDK API 名单总共分为三类：light grey list （浅灰名单）、dark grey list （深灰名单）、dark list（黑名单），详情：

2.2 非 SDK API 名单扫描

所以对于我们应用开发者来说，当前首要任务是适配深灰名单和黑名单。目前 google 官方提供了一个可以实时查询三个名单里面 API 列表的网站：https://android.googlesource.com/platform/frameworks/base/+/master/config/。在之前 DP 版本时开发者如果遇到了不得不使用的黑名单或者深灰名单 API，需要向 google 官方及时提出反馈（反馈url：https://issuetracker.google.com/issues/new?component=328403&template=1027267），申请将其移动到浅灰名单中，但是目前正式版本已经发布，未得知该申请通道是否仍有效。

详细了解了非 SDK API 之后，下一步当然是将应用代码里面的深灰名单和黑名单 API 调用找出来一一修改。目前官方提供了一个非常实用的扫描工具，该工具可以把应用里面三个类型名单的 API 调用都扫描出来（但是可能会有遗漏），使用方法也很简单：

打包一个应用 APK，建议使用 release 包，排除一些未使用到的单元测试类或者其他因素的影响，将 APK 放到工具指定目录下；
执行命令 ./appcompat.sh --dex-file=test.apk，在终端上会输出三个名单每个 API 的详细调用处: #1: Linking dark greylist Landroid/os/SystemProperties;->get(Ljava/lang/String;)Ljava/lang/String; use(s): Ltmsdkobf/gv;->a(Ljava/lang/String;)Ljava/lang/String; #2: Linking dark greylist Landroid/os/SystemProperties;->get(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String; use(s): Ltmsdkobf/gp;->b(Landroid/content/Context;)Ljava/lang/String; ....

2.3 非 SDK API 适配

经过上一步扫描出应用内非 SDK API 调用之后，接下来就可以直接开始适配。适配的原则是优先黑名单和深灰名单，浅灰名单在官方未有替代 API 之前可以暂时不适配，在 Android P 上运行也不会有任何问题。扫描完成之后，不出意外大家应该会有三类需要适配的 API 调用：

应用代码本身调用到了非 SDK API 接口；针对应用代码本身调用到了非 SDK API 接口，用的比较频繁的例如 SystemProperties.get，就需要去寻找另外一个可以替代的合法 API，如果找不到就只能认为该 API 调用失败从而走失败逻辑，如果实在必须要用到该 API 就

首页上一页 1 2 3 4 下一页尾页 1/4/4
【大中小】【打印】【繁体】【投稿】【收藏】【推荐】【举报】【评论】【关闭】【返回顶部】

上一篇：喜闻乐见-Android简介	下一篇：喜闻乐见-Android LaunchMode