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 调用：