[Android各版本特性]Android 9.0 Pie

[Android各版本特性]专栏目录：
01. Android API 版本对照表
02. Android 4.4以前版本特性
03. 为什么以Android4.4做分界线
04. Android 4.4 Kitkat
05. Android 5.0 Android Lollipop
06. Android 6.0 Marshmallow
07. Android 7.0 Nougat
08. Android 8.0 Oreo
09. Android 9.0 Pie
10. Android 10
11. 总结（推荐）

1.利用 Wi-Fi RTT 进行室内定位

Android 9 添加了对 IEEE 802.11mc Wi-Fi 协议（也称为 Wi-Fi Round-Trip-Time (RTT)）的平台支持，从而让您的应用可以利用室内定位功能。

在运行 Android 9 且具有硬件支持的设备上，应用可以使用 RTT API 来测量与附近支持 RTT 的 Wi-Fi 接入点 (AP) 的距离。

设备无需连接到接入点即可使用 RTT。 为了保护隐私，只有手机可以确定与接入点的距离；接入点无此信息。

如果您的设备测量与 3 个或更多接入点的距离，您可以使用一个多点定位算法来预估与这些测量值最相符的设备位置。 结果通常精准至 1 至 2 米。

通过这种精确性，您可以打造新的体验，例如楼内导航、基于精细位置的服务，如无歧义语音控制（例如，“打开这盏灯”），以及基于位置的信息（如 “此产品是否有特别优惠？”）。

2.显示屏缺口支持

Android 9 支持最新的全面屏，其中包含为摄像头和扬声器预留空间的屏幕缺口。 通过 DisplayCutout 类可确定非功能区域的位置和形状，这些区域不应显示内容。 要确定这些屏幕缺口区域是否存在及其位置，请使用 getDisplayCutout() 函数。

3.渠道设置、广播和请勿打扰

Android 8.0 引入了通知渠道，允许您为要显示的每种通知类型创建可由用户自定义的渠道。 Android 9 通过下列变更简化通知渠道设置：

• 屏蔽渠道组：现在，用户可以针对某个应用在通知设置中屏蔽整个渠道组。 您可以使用 isBlocked() 函数确定何时屏蔽一个渠道组，从而不会向该组中的渠道发送任何通知。

  此外，您的应用可以使用全新的 getNotificationChannelGroup() 函数查询当前渠道组设置。

• 全新的广播 Intent 类型：现在，当通知渠道和渠道组的屏蔽状态发生变更时，Android 系统将发送广播 Intent。 拥有已屏蔽的渠道或渠道组的应用可以侦听这些 Intent 并做出相应的回应。

• NotificationManager.Policy 有 3 种新的“请勿打扰”优先级类别：

  • PRIORITY_CATEGORY_ALARMS 优先处理警报。
  • PRIORITY_CATEGORY_MEDIA 优先处理媒体源的声音，如媒体和语音导航。
  • PRIORITY_CATEGORY_SYSTEM 优先处理系统声音。

• NotificationManager.Policy 还有 7 种新的“请勿打扰”常量，可以用来抑制视觉中断：

  • SUPPRESSED_EFFECT_FULL_SCREEN_INTENT 防止通知启动全屏 Activity。
  • SUPPRESSED_EFFECT_LIGHTS 屏蔽通知灯。
  • SUPPRESSED_EFFECT_PEEK 防止通知短暂进入视图（“滑出”）。
  • SUPPRESSED_EFFECT_STATUS_BAR 防止通知显示在支持状态栏的设备的状态栏中。
  • SUPPRESSED_EFFECT_BADGE 在支持标志的设备上屏蔽标志。 如需了解详细信息，请参阅修改通知标志。
  • SUPPRESSED_EFFECT_AMBIENT 在支持微光显示的设备上屏蔽通知。
  • SUPPRESSED_EFFECT_NOTIFICATION_LIST 防止通知显示在支持列表视图（如通知栏或锁屏）的设备的列表视图中。

4.多摄像头支持和摄像头更新

在运行 Android 9 的设备上，您可以通过两个或更多物理摄像头来同时访问多个视频流。在配备双前置摄像头或双后置摄像头的设备上，您可以创建只配备单摄像头的设备所不可能实现的创新功能，例如无缝缩放、背景虚化和立体成像。 通过该 API，您还可以调用逻辑或融合的摄像头视频流，该视频流可在两个或更多摄像头之间自动切换。

摄像头方面的其他改进还包括附加会话参数和 Surface 共享，前者有助于降低首次拍照期间的延迟，而后者则让摄像头客户端能够处理各种用例，而无需停止并启动摄像头视频流。 我们还针对基于显示屏的 flash 支持和 OIS 时间戳访问新增了一些 API，用以实现应用级的图像稳定化和特效。

5.适用于可绘制对象和位图的 ImageDecoder

Android 9 引入了 ImageDecoder 类，可提供现代化的图像解码方法。 使用该类取代 BitmapFactory 和 BitmapFactory.Options API。

ImageDecoder 让您可通过字节缓冲区、文件或 URI 来创建 Drawable 或 Bitmap。 要解码图像，请首先以编码图像的来源为参数，调用 createSource()。 然后，通过传递 ImageDecoder.Source 对象来调用 decodeDrawable() 或 decodeBitmap()，从而创建 Drawable] 或 Bitmap。 要更改默认设置，请将 OnHeaderDecodedListener 传递给 decodeDrawable() 或 decodeBitmap()。 ImageDecoder 调用 onHeaderDecoded()，以图像的默认宽度和高度（若已知）为参数。 如果编码图像是动画 GIF 或 WebP，decodeDrawable() 将返回 Drawable，它是 AnimatedImageDrawable 类的一个实例。

您可以使用不同的方法来设置图像属性：

• 要将解码的图像缩放到精确尺寸，请将目标尺寸传递给 setTargetSize()。 您也可以使用样图尺寸来缩放图像。 将样图尺寸直接传递给 setTargetSampleSize()。
• 要在缩放图像的范围内裁剪图像，请调用 setCrop()。
• 要创建可变位图，请将 true 传递给 setMutableRequired()。

通过 ImageDecoder 还可以为圆角或圆形遮罩之类的图像添加复杂的定制效果。 以 PostProcessor 类的一个实例作为参数使用 setPostProcessor()，执行您所需的任何绘图命令。

注：对 AnimatedImageDrawable进行后处理时，效果会出现在动画的所有帧中。

6.动画

Android 9 引入了 AnimatedImageDrawable 类，用于绘制和显示 GIF 和 WebP 动画图像。 AnimatedImageDrawable 的工作方式与 AnimatedVectorDrawable 的相似之处在于，都是渲染线程驱动 AnimatedImageDrawable 的动画。 渲染线程还使用工作线程进行解码，因此，解码不会干扰渲染线程的其他操作。 这种实现机制允许您的应用在显示动画图像时，无需管理其更新，也不会干扰应用界面线程上的其他事件。

可使用 ImageDecoder 的实例对 AnimatedImageDrawable 进行解码。

7.JobScheduler 中的流量费用敏感度

从 Android 9 开始，JobScheduler 可以使用运营商提供的网络状态信号来改善与网络有关的作业处理。

作业可以声明其预估的数据大小、信号预提取，并指定具体的网络要求。 JobScheduler 然后根据网络状态管理工作。 例如，当网络显示拥塞时，JobScheduler 可能会延迟较大的网络请求。 如果使用的是不按流量计费的网络，则 JobScheduler 可运行预提取作业以提升用户体验（例如预提取标题）。

添加作业时，确保使用 setEstimatedNetworkBytes()、setPrefetch() 和 setRequiredNetwork()（如果适用），以帮助 JobScheduler 正确处理工作。 在执行作业时，请确保使用 JobParameters.getNetwork() 返回的 Network 对象。 否则，您将隐式使用设备的默认网络，其可能不符合您的要求，从而导致意外的流量消耗。

8.统一生物识别身份验证对话框

在 Android 9 中，系统代表您的应用提供生物识别身份验证对话框。 该功能可创建标准化的对话框外观、风格和位置，让用户更加确信，他们在使用可信的生物识别凭据检查程序进行身份验证。

如果您的应用使用 FingerprintManager 向用户显示指纹身份验证对话框，请切换到改用 BiometricPrompt。 BiometricPrompt 依赖系统来显示身份验证对话框。 它还会改变其行为，以适应用户所选择的生物识别身份验证类型。

注：在应用中使用 BiometricPrompt 之前，应该先使用 hasSystemFeature()函数以确保设备支持 FEATURE_FINGERPRINT、FEATURE_IRIS 或 FEATURE_FACE。

如果设备不支持生物识别身份验证，可以回退为使用 createConfirmDeviceCredentialIntent() 函数验证用户的 PIN 码、图案或密码。

9.具有密钥轮转的 APK 签名方案

Android 9 新增了对 APK Signature Scheme v3 的支持。该架构提供的选择可以在其签名块中为每个签名证书加入一条轮转证据记录。 利用此功能，应用可以通过将 APK 文件过去的签名证书链接到现在签署应用时使用的证书，从而使用新签名证书来签署应用。

注：运行 Android 8.1（API 级别 27）或更低版本的设备不支持更改签名证书。 如果应用的 minSdkVersion 为 27 或更低，除了新签名之外，可使用旧签名证书来签署应用。

10.后台对传感器的访问受限

Android 9 限制后台应用访问用户输入和传感器数据的能力。 如果您的应用在运行 Android 9 设备的后台运行，系统将对您的应用采取以下限制：

• 您的应用不能访问麦克风或摄像头。
• 使用连续报告模式的传感器（例如加速度计和陀螺仪）不会接收事件。
• 使用变化或一次性报告模式的传感器不会接收事件。

如果您的应用需要在运行 Android 9 的设备上检测传感器事件，请使用前台服务。

11.限制访问

1. 限制访问电话号码
2. 限制访问通话记录
3. 限制访问 Wi-Fi 位置和连接信息
4. 在应用处于空闲状态时，不能再访问相机、麦克风或 SensorManager 传感器。

Android 9 引入 CALL_LOG 权限组并将 READ_CALL_LOG、WRITE_CALL_LOG 和 PROCESS_OUTGOING_CALLS 权限移入该组。 在之前的 Android 版本中，这些权限位于 PHONE 权限组。

在 Android 9 中，应用进行 Wi-Fi 扫描的权限要求比之前的版本更严格。

12.Java UTF 解码器

UTF-8 是 Android 中的默认字符集。 UTF-8 字节序列可由 String(byte[] bytes) 之类的 String 构造函数解码。

Android 9 中的 UTF-8 解码器遵循比以前版本中更严格的 Unicode 标准： 这些变更包括：

• 非最短形式的 UTF-8（例如 <C0, AF>）被视为格式不正确。
• 替代形式的 UTF-8（例如 U+D800…U+DFFF）被视为格式不正确。
• 最大的子部分被单个 U+FFFD 取代。 例如，在字节序列“41 C0 AF 41 F4 80 80 41”中，最大子部分为“C0”、“AF”和“F4 80 80”。其中“F4 80 80”可以是“F4 80 80 80”的初始子序列，但“C0”不能是任何形式正确的代码单位序列的初始子序列。 因此，输出应为“A\ufffd\ufffdA\ufffdA”。
• 要在 Android 9 或更高版本中解码修改后的 UTF-8/CESU-8 序列，请使用 DataInputStream.readUTF() 函数或 NewStringUTF() JNI 函数。

13.枚举相机

在 Android 9 设备上运行的应用可以通过调用 getCameraIdList() 发现每个可用的摄像头。 应用不应假定设备只有一个后置摄像头或只有一个前置摄像头。

例如，如果您的应用有一个用来切换前置和后置摄像头的按钮，则设备可能有多个前置或后置摄像头可供选择。 您应浏览一下摄像头列表，检查每个摄像头的特征，然后决定向用户显示哪些摄像头。

14.前台服务

如果应用以 Android 9 或更高版本为目标平台并使用前台服务，则必须请求 FOREGROUND_SERVICE 权限。这是普通权限，因此，系统会自动为请求权限的应用授予此权限。

如果以 Android 9 或更高版本为目标平台的应用尝试创建前台服务且未请求 FOREGROUND_SERVICE，则系统会抛出 SecurityException。

15.Apache HTTP 客户端弃用

在 Android 6.0 中，我们移除了对 Apache HTTP 客户端的支持。从 Android 9 开始，该内容库已从 bootclasspath 中移除，且默认情况下应用无法使用它。

要继续使用 Apache HTTP 客户端，以 Android 9 及更高版本为目标平台的应用可以向其 AndroidManifest.xml 添加以下内容：

<uses-library android:name="org.apache.http.legacy" android:required="false"/>

注意：拥有的最低 SDK 为 23 或更低的应用需要有 android:required=“false” 属性，因为在 API 级别低于 24 的设备上，org.apache.http.legacy 库不可用。（在这些设备上，Apache HTTP 类在 bootclasspath 中提供。）

除了使用运行时 Apache 库，应用还可以将自己的 org.apache.http 库版本打包到其 APK 中。如果要进行此操作，您必须重新打包该库（使用一个类似于 Jar Jar 的实用程序），以避免运行时中提供的类存在类兼容性问题。

16.电源管理

Android 9（API 级别 28）引入了一些新功能来改进设备电源管理。 这些变化，连同先前版本中已经存在的功能，有助于确保将系统资源提供给最需要它们的应用。

电源管理功能可以分为两个类别：

应用待机群组
系统将根据用户的使用模式限制应用对 CPU 或电池等设备资源的访问。 这是 Android 9 中新增的一项功能。
省电模式改进
开启省电模式后，系统会对所有应用施加限制。 这是一项已有的功能，但在 Android 9 中得到了改进。

注：这些变化适用于所有应用，无论它们是否以 Android 9 为目标。

应用待机群组

Android 9 引入了一项新的电池管理功能，即应用待机群组。 应用待机群组可以基于应用最近使用时间和使用频率，帮助系统排定应用请求资源的优先级。 根据使用模式，每个应用都会归类到五个优先级群组之一中。 系统将根据应用所属的群组限制每个应用可以访问的设备资源。

五个群组按照以下特性将应用分组：

活跃
如果用户当前正在使用应用，应用将被归到“活跃”群组中，例如：

• 应用已启动一个 Activity
• 应用正在运行前台服务
• 应用的同步适配器与某个前台应用使用的 content provider 关联
• 用户在应用中点击了某个通知

如果应用处于“活跃”群组，系统不会对应用的作业、报警或 FCM 消息施加任何限制。

工作集
如果应用经常运行，但当前未处于活跃状态，它将被归到“工作集”群组中。 例如，用户在大部分时间都启动的某个社交媒体应用可能就属于“工作集”群组。 如果应用被间接使用，它们也会被升级到“工作集”群组中 。

如果应用处于“工作集”群组，系统会对它运行作业和触发报警的能力施加轻度限制。 如需了解详细信息，请参阅电源管理限制。

常用
如果应用会定期使用，但不是每天都必须使用，它将被归到“常用”群组中。 例如，用户在健身房运行的某个锻炼跟踪应用可能就属于“常用”群组。

如果应用处于“常用”群组，系统将对它运行作业和触发报警的能力施加较强的限制，也会对高优先级 FCM 消息的数量设定限制。 如需了解详细信息，请参阅电源管理限制。

极少使用
如果应用不经常使用，那么它属于“极少使用”群组。 例如，用户仅在入住酒店期间运行的酒店应用就可能属于“极少使用”群组。

如果应用处于“极少使用”群组，系统将对它运行作业、触发警报和接收高优先级 FCM 消息的能力施加严格限制。系统还会限制应用连接到网络的能力。 如需了解详细信息，请参阅电源管理限制。

从未使用
安装但是从未运行过的应用会被归到“从未使用”群组中。 系统会对这些应用施加极强的限制。

系统会动态地将每个应用归类到某个优先级群组，并根据需要重新归类。 系统可能会依靠某个使用机器学习的预加载应用确定每个应用的使用可能性，并将应用归类到合适的群组。 如果设备上不存在系统应用，系统默认将基于应用的最近使用时间对它们进行排序。 更为活跃的应用将被归类到为应用提供更高优先级的群组，从而让应用可以使用更多系统资源。 具体而言，群组决定应用运行作业的频率，应用可以触发报警的频率，以及应用可以接收高优先级 Firebase 云信息传递 (FCM) 消息的频率。 这些限制仅在设备使用电池电量时适用，如果设备正在充电，系统不会对应用施加这些限制。

每个制造商都可以设定自己的标准来归类非活跃应用。 您不应当尝试影响应用所属的群组。 相反，您应当将精力放在确保应用在所属的群组内良好运行上。 您的应用可以通过调用新函数 UsageStatsManager.getAppStandbyBucket() 查找当前属于哪个群组。

注：位于 低电耗模式白名单中的应用不适用基于应用待机群组的限制。