一、Android5

1.ANDROID 5.0 行为变更：

声音和振动

（1）如果您当前使用 Ringtone、MediaPlayer 或 Vibrator 类向通知中添加声音和振动，则移除此代码，以便系统可以在“优先”模式中正确显示通知。取而代之的是，使用 Notification.Builder 方法添加声音和振动。

（2）以前，Android 使用 STREAM_MUSIC 作为主流式传输来控制平板电脑设备上的音量。在 Android 5.0 中，手机和平板电脑设备的主音量流式传输现已合并，由 STREAM_RING 或 STREAM_NOTIFICATION 进行控制。

（3）媒体播放

       如果您要实现显示媒体播放状态或传输控件的通知，请考虑使用新的 Notification.MediaStyle 模板，而不是自定义 RemoteViews.Remote View 对象。无论您选择使用哪个方法，请务必将通知的可见性设为 VISIBILITY_PUBLIC，以便可通过锁定屏幕访问您的控件。请注意，从 Android 5.0 开始，系统不再将 RemoteControlClient 对象显示在锁定屏幕上。如需了解详细信息，请参阅如果您的应用使用 RemoteControlClient.

（4）浮动通知               

现在，当设备处于活动状态时（即，设备未锁定且其屏幕已打开），通知可以显示在小型浮动窗口中（也称为“浮动通知”）。这些通知看上去类似于精简版的通知，只是浮动通知还显示操作按钮。用户可以在不离开当前应用的情况下处理或清除浮动通知。

可能触发浮动通知的条件示例包括：

用户的 Activity 处于全屏模式中（应用使用 fullScreenIntent）

通知具有较高的优先级并使用铃声或振动。

（5）绑定到服务

Context.bindService() 方法现在需要显式 Intent，如果提供隐式 intent，将引发异常。为确保应用的安全性，请使用显式 intent 启动或绑定 Service，且不要为服务声明 intent 过滤器。

（6）WebView

Android 5.0 更改了应用的默认行为。

如果您的应用是面向 API 级别 21 或更高级别：

默认情况下，系统会阻止混合内容和第三方 Cookie。要允许混合内容和第三方 Cookie，请分别使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。

系统现在可以智能地选择要绘制的 HTML 文档部分。这个新的默认行为有助于减少内存占用和提升性能。如果您要一次渲染整个文档，可通过调用 enableSlowWholeDocumentDraw() 停用此优化。

如果您的应用是面向低于 21 的 API 级别：系统允许混合内容和第三方 Cookie，并始终一次渲染整个文档。

（7）自定义权限

从 Android 5.0 开始，对于使用不同密钥签名的应用，系统会强制执行新的自定义权限唯一性限制。现在，设备上只有一个应用可以定义给定的自定义权限（按其名称确定），除非定义此权限的其他应用使用相同密钥签名

（8）与服务器握手的 TLS/SSL 被错误地拒绝或出现停顿。首选的修复方法是升级服务器以符合 TLS/SSL 协议

二、ANDROID 6.0

1. 行为变更

(1)  运行时权限

此版本引入了一种新的权限模式，如今，用户可直接在运行时管理应用权限。这种模式让用户能够更好地了解和控制权限，同时为应用开发者精简了安装和自动更新过程。用户可为所安装的各个应用分别授予或撤销权限。

对于以 Android 6.0（API 级别 23）或更高版本为目标平台的应用，请务必在运行时检查和请求权限。要确定您的应用是否已被授予权限，请调用新增的 checkSelfPermission() 方法。要请求权限，请调用新增的 requestPermissions() 方法。即使您的应用并不以 Android 6.0（API 级别 23）为目标平台，您也应该在新权限模式下测试您的应用。

如需了解有关在您的应用中支持新权限模式的详情，请参阅使用系统权限。如需了解有关如何评估新模式对应用的影响的提示，请参阅权限最佳做法。

(2)  低电耗模式和应用待机模式

此版本引入了针对空闲设备和应用的最新节能优化技术。这些功能会影响所有应用，因此请务必在这些新模式下测试您的应用。

低电耗模式：如果用户拔下设备的电源插头，并在屏幕关闭后的一段时间内使其保持不活动状态，设备会进入低电耗模式，在该模式下设备会尝试让系统保持休眠状态。在该模式下，设备会定期短时间恢复正常工作，以便进行应用同步，还可让系统执行任何挂起的操作。

应用待机模式：应用待机模式允许系统判定应用在用户未主动使用它时处于空闲状态。当用户有一段时间未触摸应用时，系统便会作出此判定。如果拔下了设备电源插头，系统会为其视为空闲的应用停用网络访问以及暂停同步和作业。

要详细了解这些节能变更，请参阅对低电耗模式和应用待机模式进行针对性优化。

(3)取消支持 Apache HTTP 客户端

Android 6.0 版移除了对 Apache HTTP 客户端的支持。如果您的应用使用该客户端，并以 Android 2.3（API 级别 9）或更高版本为目标平台，请改用 HttpURLConnection 类。此 API 效率更高，因为它可以通过透明压缩和响应缓存减少网络使用，并可最大限度降低耗电量。要继续使用 Apache HTTP API，您必须先在 build.gradle 文件中声明以下编译时依赖项：

android {

    useLibrary 'org.apache.http.legacy'

}

(4)BoringSSL

Android 正在从使用 OpenSSL 库转向使用 BoringSSL 库。如果您要在应用中使用 Android NDK，请勿链接到并非 NDK API 组成部分的加密库，如 libcrypto.so 和 libssl.so。这些库并非公共 API，可能会在不同版本和设备上毫无征兆地发生变化或出现故障。此外，您还可能让自己暴露在安全漏洞的风险之下。请改为修改原生代码，以通过 JNI 调用 Java 加密 API，或静态链接到您选择的加密库。

(5) 蓝牙扫描需要定位权限 才能获得MAC地址，硬件标识符访问权

为给用户提供更严格的数据保护，从此版本开始，对于使用 WLAN API 和 Bluetooth API 的应用，Android 移除了对设备本地硬件标识符的编程访问权。WifiInfo.getMacAddress() 方法和 BluetoothAdapter.getAddress() 方法现在会返回常量值 02:00:00:00:00:00。

现在，要通过蓝牙和 WLAN 扫描访问附近外部设备的硬件标识符，您的应用必须拥有 ACCESS_FINE_LOCATION 或 ACCESS_COARSE_LOCATION 权限。

WifiManager.getScanResults()

BluetoothDevice.ACTION_FOUND

BluetoothLeScanner.startScan()

注：当运行 Android 6.0（API 级别 23）的设备发起后台 WLAN 或蓝牙扫描时，在外部设备看来，该操作的发起来源是一个随机化 MAC 地址。

(6) 通知

此版本移除了 Notification.setLatestEventInfo() 方法。请改用 Notification.Builder 类来构建通知。要重复更新通知，请重复使用 Notification.Builder 实例。调用 build() 方法可获取更新后的 Notification 实例。

adb shell dumpsys notification 命令不再打印输出您的通知文本。请改用 adb shell dumpsys notification --noredact 命令打印输出 notification 对象中的文本。

(7)音频管理器变更

不再支持通过 AudioManager 类直接设置音量或将特定音频流静音。setStreamSolo() 方法已弃用，您应该改为调用 requestAudioFocus() 方法。类似地，setStreamMute() 方法也已弃用，请改为调用 adjustStreamVolume() 方法并传入方向值 ADJUST_MUTE 或 ADJUST_UNMUTE。

(8)WLAN 和网络连接变更

此版本对 WLAN API 和 Networking API 引入了以下行为变更。

现在，您的应用只能更改由您创建的 WifiConfiguration 对象的状态。系统不允许您修改或删除由用户或其他应用创建的 WifiConfiguration 对象。

在之前的版本中，如果应用利用带有 disableAllOthers=true 设置的 enableNetwork() 强制设备连接特定 WLAN 网络，设备将会断开与移动数据网络等其他网络的连接。在此版本中，设备不再断开与上述其他网络的连接。如果您的应用的 targetSdkVersion 为 “20” 或更低，则会固定连接所选 WLAN 网络。如果您的应用的 targetSdkVersion 为 “21” 或更高，请使用多网络 API（如 openConnection()、bindSocket() 和新增的 bindProcessToNetwork() 方法）来确保通过所选网络传送网络流量。

(9)相机服务变更

在此版本中，相机服务中共享资源的访问模式已从之前的“先到先得”访问模式更改为高优先级进程优先的访问模式。对服务行为的变更包括：

根据客户端应用进程的“优先级”授予对相机子系统资源的访问权，包括打开和配置相机设备。带有对用户可见 Activity 或前台 Activity 的应用进程一般会被授予较高的优先级，从而使相机资源的获取和使用更加可靠；

当高优先级的应用尝试使用相机时，系统可能会“驱逐”正在使用相机客户端的低优先级应用。在已弃用的 Camera API 中，这会导致系统为被驱逐的客户端调用 onError()。在 Camera2 API 中，这会导致系统为被驱逐的客户端调用 onDisconnected()；

在配备相应相机硬件的设备上，不同的应用进程可同时独立打开和使用不同的相机设备。但现在，如果在多进程用例中同时访问相机会造成任何打开的相机设备的性能或能力严重下降，相机服务会检测到这种情况并禁止同时访问。即使并没有其他应用直接尝试访问同一相机设备，此变更也可能导致低优先级客户端被“驱逐”。

更改当前用户会导致之前用户帐户拥有的应用内活动相机客户端被驱逐。对相机的访问仅限于访问当前设备用户拥有的用户个人资料。举例来说，这意味着，当用户切换到其他帐户后，“来宾”帐户实际上无法让使用相机子系统的进程保持运行状态

三、ANDROID 7.0

1.行为变更

 Android 7.0 包括旨在延长设备电池寿命和减少 RAM 使用的系统行为变更。这些变更可能会影响您的应用访问系统资源，以及您的应用通过特定隐式 intent 与其他应用交互的方式。

1.低电耗模式

Android 6.0（API 级别 23）引入了低电耗模式，当用户设备未插接电源、处于静止状态且屏幕关闭时，该模式会推迟 CPU 和网络活动，从而延长电池寿命。而 Android 7.0 则通过在设备未插接电源且屏幕关闭状态下、但不一定要处于静止状态（例如用户外出时把手持式设备装在口袋里）时应用部分 CPU 和网络限制，进一步增强了低电耗模式。

2. Project Svelte：后台优化

Android 7.0 移除了三项隐式广播，以帮助优化内存使用和电量消耗。此项变更很有必要，因为隐式广播会在后台频繁启动已注册侦听这些广播的应用。删除这些广播可以显著提升设备性能和用户体验。

移动设备会经历频繁的连接变更，例如在 WLAN 和移动数据之间切换时。目前，可以通过在应用清单中注册一个接收器来侦听隐式 CONNECTIVITY_ACTION 广播，让应用能够监控这些变更。由于很多应用会注册接收此广播，因此单次网络切换即会导致所有应用被唤醒并同时处理此广播。

同理，在之前版本的 Android 中，应用可以注册接收来自其他应用（例如相机）的隐式 ACTION_NEW_PICTURE 和 ACTION_NEW_VIDEO 广播。当用户使用相机应用拍摄照片时，这些应用即会被唤醒以处理广播。

为缓解这些问题，Android 7.0 应用了以下优化措施：

面向 Android 7.0 开发的应用不会收到 CONNECTIVITY_ACTION 广播，即使它们已有清单条目来请求接受这些事件的通知。在前台运行的应用如果使用 BroadcastReceiver 请求接收通知，则仍可以在主线程中侦听 CONNECTIVITY_CHANGE。

应用无法发送或接收 ACTION_NEW_PICTURE 或 ACTION_NEW_VIDEO 广播。此项优化会影响所有应用，而不仅仅是面向 Android 7.0 的应用。

如果您的应用使用任何 intent，您仍需要尽快移除它们的依赖关系，以正确适配 Android 7.0 设备。Android 框架提供多个解决方案来缓解对这些隐式广播的需求。例如，JobScheduler API 提供了一个稳健可靠的机制来安排满足指定条件（例如连入无限流量网络）时所执行的网络操作。您甚至可以使用 JobScheduler 来适应内容提供程序变化。

如需了解有关 Android N 中后台优化以及如何改写应用的详细信息，请参阅后台优化。

3.  权限更改

Android 7.0 做了一些权限更改，这些更改可能会影响您的应用。

系统权限更改

为了提高私有文件的安全性，面向 Android 7.0 或更高版本的应用私有目录被限制访问　(0700)。此设置可防止私有文件的元数据泄漏，如它们的大小或存在性。此权限更改有多重副作用：

私有文件的文件权限不应再由所有者放宽，为使用 MODE_WORLD_READABLE 和/或 MODE_WORLD_WRITEABLE 而进行的此类尝试将触发 SecurityException。

注：迄今为止，这种限制尚不能完全执行。应用仍可能使用原生 API 或 File API 来修改它们的私有目录权限。但是，我们强烈反对放宽私有目录的权限。

传递软件包网域外的 file:// URI 可能给接收器留下无法访问的路径。因此，尝试传递 file:// URI 会触发 FileUriExposedException。分享私有文件内容的推荐方法是使用 FileProvider。

DownloadManager 不再按文件名分享私人存储的文件。

旧版应用在访问 COLUMN_LOCAL_FILENAME 时可能出现无法访问的路径。

面向 Android 7.0 或更高版本的应用在尝试访问 COLUMN_LOCAL_FILENAME 时会触发 SecurityException。

通过使用 DownloadManager.Request.setDestinationInExternalFilesDir() 或 DownloadManager.Request.setDestinationInExternalPublicDir() 将下载位置设置为公共位置的旧版应用仍可以访问 COLUMN_LOCAL_FILENAME 中的路径，但是我们强烈反对使用这种方法。对于由 DownloadManager 公开的文件，首选的访问方式是使用ContentResolver.openFileDescriptor()。

4.在应用间共享文件

对于面向 Android 7.0 的应用，Android 框架执行的 StrictMode API 政策禁止在您的应用外部公开 file:// URI。如果一项包含文件 URI 的 intent 离开您的应用，则应用出现故障，并出现 FileUriExposedException 异常。

要在应用间共享文件，您应发送一项 content:// URI，并授予 URI 临时访问权限。进行此授权的最简单方式是使用 FileProvider 类。如需了解有关权限和共享文件的详细信息，请参阅共享文件。

5.屏幕缩放

Android 7.0 支持用户设置显示尺寸，以放大或缩小屏幕上的所有元素，从而提升设备对视力不佳用户的可访问性。用户无法将屏幕缩放至低于最小屏幕宽度 sw320dp，该宽度是 Nexus 4 的宽度，也是常规中等大小手机的宽度。

6.无障碍改进

为提高平台对于视力不佳或视力受损用户的易用性，Android 7.0 做出了一些更改。这些更改一般并不要求更改您的应用代码，不过您应仔细检查并使用您的应用测试这些功能，以评估它们对用户体验的潜在影响.

7.NDK 应用链接至平台库

从 Android 7.0 开始，系统将阻止应用动态链接非公开 NDK 库，这种库可能会导致您的应用崩溃。此行为变更旨在为跨平台更新和不同设备提供统一的应用体验。即使您的代码可能不会链接私有库，但您的应用中的第三方静态库可能会这么做。因此，所有开发者都应进行相应检查，确保他们的应用不会在运行 Android 7.0 的设备上崩溃。如果您的应用使用原生代码，则只能使用公开 NDK API。

8.Android for Work

Android 7.0 包含一些针对面向 Android for Work 的应用的变更，包括对证书安装、密码重置、二级用户管理、设备标识符访问权限的变更。如果您是要针对 Android for Work 环境开发应用，则应仔细检查这些变更并相应地修改您的应用

四、Android 8.0

1.行为变更

Android 8.0 除了提供诸多新特性和功能外，还对系统和 API 行为做出了各种变更。本文重点介绍您应该了解并在开发应用时加以考虑的一些主要变更。

其中大部分变更会影响所有应用，而不论应用针对的是何种版本的 Android。不过，有几项变更仅影响针对 Android 8.0 的应用。为清楚起见，本页面分为两个部分：针对所有 API 级别的应用和针对 Android 8.0 的应用。

针对所有 API 级别的应用

这些行为变更适用于 在 Android 8.0 平台上运行的 所有应用，无论这些应用是针对哪个 API 级别构建。所有开发者都应查看这些变更，并修改其应用以正确支持这些变更（如果适用）。

一.  后台执行限制

Android 8.0 为提高电池续航时间而引入的变更之一是，当您的应用进入已缓存状态时，如果没有活动的组件，系统将解除应用具有的所有唤醒锁。

此外，为提高设备性能，系统会限制未在前台运行的应用的某些行为。具体而言：

现在，在后台运行的应用对后台服务的访问受到限制。

应用无法使用其清单注册大部分隐式广播（即，并非专门针对此应用的广播）。

默认情况下，这些限制仅适用于针对 O 的应用。不过，用户可以从 Settings 屏幕为任意应用启用这些限制，即使应用并不是以 O 为目标平台。

1. Android 8.0 还对特定函数做出了以下变更：

如果针对 Android 8.0 的应用尝试在不允许其创建后台服务的情况下使用 startService() 函数，则该函数将引发一个 IllegalStateException。

新的 Context.startForegroundService() 函数将启动一个前台服务。现在，即使应用在后台运行，系统也允许其调用 Context.startForegroundService()。不过，应用必须在创建服务后的五秒内调用该服务的 startForeground() 函数。

如需了解详细信息，请参阅后台执行限制。

多个 Android 应用和服务可以同时运行。 例如，用户可以在一个窗口中玩游戏，同时在另一个窗口中浏览网页，并使用第三个应用播放音乐。

同时运行的应用越多，对系统造成的负担越大。 如果还有应用或服务在后台运行，这会对系统造成更大负担，进而可能导致用户体验下降；例如，音乐应用可能会突然关闭。

(1)在很多情况下，您的应用都可以使用 JobScheduler 作业替换后台服务。 例如，CoolPhotoApp 需要检查用户是否已经从朋友那里收到共享的照片，即使该应用未在前台运行。

(2)在 Android 8.0 之前，创建前台服务的方式通常是先创建一个后台服务，然后将该服务推到前台。

Android 8.0 有一项复杂功能；系统不允许后台应用创建后台服务。 因此，Android 8.0 引入了一种全新的方法，即 Context.startForegroundService()，以在前台启动新服务。

在系统创建服务后，应用有五秒的时间来调用该服务的 startForeground() 方法以显示新服务的用户可见通知。

如果应用在此时间限制内未调用 startForeground()，则系统将停止服务并声明此应用为 ANR。

2.广播限制

如果应用注册为接收广播，则在每次发送广播时，应用的接收器都会消耗资源。 如果多个应用注册为接收基于系统事件的广播，这会引发问题；触发广播的系统事件会导致所有应用快速地连续消耗资源，从而降低用户体验。

为了缓解这一问题，Android 7.0（API 级别 25）对广播施加了一些限制，如后台优化中所述。

Android 8.0 让这些限制更为严格。

针对 Android 8.0 的应用无法继续在其清单中为隐式广播注册广播接收器。 隐式广播是一种不专门针对该应用的广播。 例如，ACTION_PACKAGE_REPLACED 就是一种隐式广播，因为它将发送到注册的所有侦听器，让后者知道设备上的某些软件包已被替换。

不过，ACTION_MY_PACKAGE_REPLACED 不是隐式广播，因为不管已为该广播注册侦听器的其他应用有多少，它都会只发送到软件包已被替换的应用。

应用可以继续在它们的清单中注册显式广播。

应用可以在运行时使用 Context.registerReceiver() 为任意广播（不管是隐式还是显式）注册接收器。

需要签名权限的广播不受此限制所限，因为这些广播只会发送到使用相同证书签名的应用，而不是发送到设备上的所有应用。

在许多情况下，之前注册隐式广播的应用使用 JobScheduler 作业可以获得类似的功能。

例如，一款社交照片应用可能需要不时地执行数据清理，并且倾向于在设备连接到充电器时执行此操作。

之前，应用已经在清单中为 ACTION_POWER_CONNECTED 注册了一个接收器；当应用接收到该广播时，它会检查清理是否必要。 为了迁移到 Android 8.0，应用将该接收器从其清单中移除。

应用将清理作业安排在设备处于空闲状态和充电时运行。

注：很多隐式广播当前均已不受此限制所限。 应用可以继续在其清单中为这些广播注册接收器，不管应用针对哪个 API 级别。 有关已豁免广播的列表，请参阅隐式广播例外。

3.迁移指南

默认情况下，这些更改仅影响针对 O 的应用。 不过，用户可以从 Settings 屏幕为任意应用启用这些限制，即使应用并不是以 O 为目标平台。

您可能需要更新应用，使其符合新限制。

了解您的应用如何使用服务。 如果您的应用依赖某些在它处于空闲时于后台运行的服务，您需要替换这些服务。

可能的解决方法包括：

如果处于后台时您的应用需要创建一个前台服务，请使用新的 NotificationManager.startServiceInForeground()

方法，而不是创建一个后台服务，然后尝试将其推到前台。

如果服务容易被用户注意，请将其设为前台服务。 例如，播放音频的服务始终应为前台服务。

使用 NotificationManager.startServiceInForeground()

而不是 startService() 创建服务。

寻找一种使用计划作业实现服务功能的方式。 如果服务未在执行容易立即被用户注意到的操作，一般情况下，您都能够使用计划作业。

发生网络事件时，请使用 FCM 选择性地唤醒您的应用，而不是在后台轮询。

在应用正常处于前台之前，请推迟后台工作。

检查在您应用的清单中定义的广播接收器。 如果您的清单为显式广播声明了接收器，您必须予以替换。 可能的解决方法包括：

通过调用 Context.registerReceiver() 而不是在清单中声明接收器的方式在运行时创建接收器。

使用计划作业检查条件是否会触发隐式广播。

4. Android 后台位置限制

为降低功耗，无论应用的目标 SDK 版本为何，Android 8.0 都会对后台应用检索用户当前位置的频率进行限制。

为节约电池电量、保持良好的用户体验和确保系统健康运行，在运行 Android 8.0 的设备上使用后台应用时，降低了后台应用接收位置更新的频率。此行为变更会影响包括 Google Play 服务在内的所有接收位置更新的应用。

为降低功耗，无论应用的目标 SDK 版本为何，Android 8.0 都会对后台应用检索用户当前位置的频率进行限制。

（1）系统会对前台应用和后台应用进行区分。应用满足以下任一条件即视为前台应用：

它具有可见的 Activity，无论 Activity 处于启动还是暂停状态。

它具有前台服务。

另一个前台应用通过绑定到应用的其中一个服务或使用应用的其中一个内容提供程序与应用相连。

如果以上所有条件均不满足，应用即视为后台应用。

（2）优化应用的位置行为

考虑在您的应用接收位置更新不频繁的情况下其后台运行用例是否根本无法成功。如果属于这种情况，您可以通过执行下列操作之一提高位置更新的检索频率：

将您的应用转至前台。

使用应用中的某个前台服务。激活此服务时，您的应用必须在通知区显示一个持续性的通知。

使用 Geofencing API 的元素（例如 GeofencingApi 接口），这些元素针对最大限度减少耗电进行了专门优化。

使用被动位置侦听器，它可以在后台应用加快位置请求频率时提高位置更新的接收频率。

注：如果您的应用需要访问的位置历史记录包含时间频繁更新，请使用批处理版本的 Fused Location Provider API 元素，例如 FusedLocationProviderApi 接口。当您的应用运行于后台时，此 API 会以高于非批处理版本 API 的频率接收用户的位置。但切记，您的应用批量接收更新的频率仍仅为每小时几次。

（3）受影响的 API

对后台应用位置检索行为的更改影响下列 API：

Fused Location Provider (FLP)

如果您的应用运行在后台，位置系统服务只会根据 Android 8.0 行为变更中定义的间隔，按每小时几次的频率为其计算新位置。即使您的应用请求进行更频繁的位置更新，也仍是如此。

如果您的应用运行在前台，与 Android 7.1.1（API 级别 25）相比，在位置采样率上不会有任何变化。

Geofencing

后台应用可以高于接收 Fused Location Provider 更新的频率接收地理围栏转换事件。

地理围栏事件的平均响应时间是大约每两分钟一次。

GNSS Measurements 和 GNSS Navigation Messages

当您的应用位于后台时，注册用于接收 GnssMeasurement 和 GnssNavigationMessage 输出的回调会停止执行。

Location Manager

提供给后台应用的位置更新只会根据 Android 8.0 行为变更中定义的间隔，按每小时几次的频率提供。

注：如果运行您的应用的设备安装了 Google Play 服务，强烈建议您改用 Fused Location Provider (FLP)。

WLAN 管理器

startScan() 方法对后台应用执行完整扫描的频率仅为每小时数次。如果不久之后后台应用再次调用此方法， WifiManager 类将提供上次扫描所缓存的结果。

五、Android 9.0

行为变更

Android 9 利用人工智能技术，让手机可以为您提供更多帮助。现在，手机变得更智能、更快，并且还可以随着您的使用进行调整

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) 的距离。 设备必须已启用位置服务并开启 Wi-Fi 扫描（在 Settings > Location 下），同时您的应用必须具有 ACCESS_FINE_LOCATION 权限。

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

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

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

2. 显示屏缺口支持

显示各种屏幕缺口尺寸的开发者选项界面

通过使用模拟器测试屏幕缺口。

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

全新的窗口布局属性 layoutInDisplayCutoutMode 让您的应用可以为设备屏幕缺口周围的内容进行布局。 您可以将此属性设为下列值之一：

LAYOUT_IN_DISPLAY_CUTOUT_MODE_DEFAULT

LAYOUT_IN_DISPLAY_CUTOUT_MODE_SHORT_EDGES

LAYOUT_IN_DISPLAY_CUTOUT_MODE_NEVER

可以按以下方法在任何运行 Android 9 的设备或模拟器上模拟屏幕缺口：

启用开发者选项。

在 Developer options 屏幕中，向下滚动至 Drawing 部分并选择 Simulate a display with a cutout。

选择屏幕缺口的大小。

注：我们建议您通过使用运行 Android 9 的设备或模拟器测试屏幕缺口周围的内容显示

3. 通知

Android 9 引入了多个通知增强功能，可供以 API 级别 28 及以上版本作为目标平台的开发者使用

将回复另存为草稿：当用户无意中关闭一个短信通知时，您的应用可以检索系统发送的 EXTRA_REMOTE_INPUT_DRAFT。 您可以使用此 extra 预填充应用中的文本字段，以便用户可以完成他们的回复。

确定对话是否为群组对话。您可以使用 setGroupConversation() 以明确确定对话是否为群组对话。

为 Intent 设置语义操作：setSemanticAction() 函数允许您为操作提供语义含义，如“标记为已读”、“删除”和“回复”等。

SmartReply：Android 9 支持在您的短信应用中提供相同的建议回复。 使用 RemoteInput.setChoices() 为用户提供一组标准回复。

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

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

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

在 Android 9 中，多摄像头 API支持单色摄像头，适用于具有 FULL 或 LIMITED 功能的设备。 单色输出通过 YUV_420_888 格式实现，Y 为灰度，U (Cb) 为 128，V (Cr) 为 128。

在受支持的设备上，Android 9 还支持外置 USB/UVC 摄像头。

5. 动画

Android 9 引入了 AnimatedImageDrawable 类，用于绘制和显示 GIF 和 WebP 动画图像

6.HDR VP9 视频、HEIF 图像压缩和 Media API

Android 9 新增了对 High Dynamic Range (HDR) VP9 Profile 2 的内置支持，因此，现在您可以在支持 HDR 的设备上为用户提供来自 YouTube、Play Movies 和其他来源的采用 HDR 的影片。

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

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

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

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

8.自动填充框架

Android 9 引入了多项改进，自动填充服务可以利用这些改进进一步增强用户填写表单时的体验。 如需详细了解如何在您的应用中使用自动填充功能，请参阅自动填充框架指南。

9.安全增强功能

Android 9 引入了若干安全功能，详见以下各节摘要说明：

Android Protected Confirmation

运行 Android 9 或更高版本的受支持设备赋予您使用 Android Protected Confirmation 的能力。 使用该工作流时，您的应用会向用户显示提示，请他们批准一个简短的声明。 应用可以通过这个声明再次确认，用户确实想完成一项敏感事务，例如付款。

如果用户接受该声明，Android 密钥库会收到并存储由密钥哈希消息身份验证代码 (HMAC) 保护的加密签名。 Android 密钥库确认消息的有效性之后，您的应用可以使用在可信执行环境 (TEE) 下通过 trustedConfirmationRequired 生成的密钥来签署用户已接受的消息。 该签名具有很高的可信度，它表示用户已看过声明并同意其内容。

注意：Android Protected Confirmation 不会为用户提供安全信息通道。 应用无法承担 Android 平台所提供机密性保证之外的任何其他保证。 尤其是，请勿使用该工作流显示您通常不会显示在用户设备上的敏感信息。

如需获得 Android Protected Confirmation 新增支持方面的指导，请参阅 Android Protected Confirmation 指南。

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

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

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

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

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

硬件安全性模块

运行 Android 9 或更高版本的受支持设备可拥有 StrongBox Keymaster，它是位于硬件安全性模块中的 Keymaster HAL 的一种实现。 该模块包含以下组成部分：

自己的 CPU。

安全存储空间。

真实随机数生成器。

可抵御软件包篡改和未经授权线刷应用的附加机制。

检查存储在 StrongBox Keymaster 中的密钥时，系统会通过可信执行环境 (TEE) 证实密钥的完整性。

如需了解有关使用 Strongbox Keymaster 的更多信息，请参阅硬件安全性模块。

10.无障碍功能

Android 9 引入了针对无障碍功能框架的增强功能，让您能够更轻松地为应用的用户提供更好的体验。

11.DEX 文件的 ART 提前转换

在运行 Android 9 或更高版本的设备上，Android 运行时 (ART) 提前编译器通过将应用软件包中的 DEX 文件转换为更紧凑的表示形式，进一步优化了压缩的 Dalvik Executable 格式 (DEX) 文件。 此项变更可让您的应用启动更快并消耗更少的磁盘空间和内存。

这种改进特别有利于磁盘 I/O 速度较慢的低端设备

12.设备端系统跟踪

Android 9 允许您通过设备记录系统跟踪记录，然后与您的开发团队分享这些记录的报告。 该报告支持多种格式，包括 HTML。

通过收集这些跟踪记录，您可以获取与应用进程和线程相关的计时数据，并查看其他类型的具有全局意义的设备状态。

注：您无需设置您的代码来记录跟踪记录，但这样做可以帮助您查看应用代码的哪些部分可能会导致线程挂起或界面卡顿。

Android 9.0行为变更：所有应用

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

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

您的应用不能访问麦克风或摄像头。

使用连续报告模式的传感器（例如加速度计和陀螺仪）不会接收事件。

使用变化或一次性报告模式的传感器不会接收事件。

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

2.限制访问通话记录

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

对于需要访问通话敏感信息（如读取通话记录和识别电话号码）的应用，该 CALL_LOG 权限组为用户提供了更好的控制和可见性。

如果您的应用需要访问通话记录或者需要处理去电，则您必须向 CALL_LOG 权限组明确请求这些权限。 否则会发生 SecurityException。

注：因为这些权限已变更组并在运行时授予，用户可以拒绝您的应用访问通话记录信息。 在这种情况下，您的应用应该能够妥善处理无法访问信息的状况。

如果您的应用已经遵循运行时权限最佳做法，则可以处理权限组的变更

3.限制访问电话号码

在未首先获得 READ_CALL_LOG 权限的情况下，除了应用的用例需要的其他权限之外，运行于 Android 9 上的应用无法读取电话号码或手机状态。

与来电和去电关联的电话号码可在手机状态广播（比如来电和去电的手机状态广播）中看到，并可通过 PhoneStateListener 类访问。 但是，如果没有 READ_CALL_LOG 权限，则 PHONE_STATE_CHANGED 广播和 PhoneStateListener 提供的电话号码字段为空。

要从手机状态中读取电话号码，请根据您的用例更新应用以请求必要的权限：

要通过 PHONE_STATE Intent 操作读取电话号码，同时需要 READ_CALL_LOG 权限和 READ_PHONE_STATE 权限。

要从 onCallStateChanged() 中读取电话号码，只需要 READ_CALL_LOG 权限。 不需要 READ_PHONE_STATE 权限。

4.对使用非 SDK 接口的限制

为帮助确保应用稳定性和兼容性，此平台对某些非 SDK 函数和字段的使用进行了限制；无论您是直接访问这些函数和字段，

还是通过反射或 JNI 访问，这些限制均适用。 在 Android 9 中，

您的应用可以继续访问这些受限的接口；该平台通过 toast 和日志条目提醒您注意这些接口。 如果您的应用显示这样的 toast，

则必须寻求受限接口之外的其他实现策略。 如果您认为没有可行的替代策略，您可以提交错误以请求重新考虑此限制

5.现在强制执行 FLAG_ACTIVITY_NEW_TASK 要求

在 Android 9 中，您不能从非 Activity 环境中启动 Activity，除非您传递 Intent 标志 FLAG_ACTIVITY_NEW_TASK。 如果您尝试在不传递此标志的情况下启动 Activity，则该 Activity 不会启动，系统会在日志中输出一则消息。

6.屏幕旋转变更

从 Android 9 开始，对纵向旋转模式做出了重大变更。 在 Android 8.0（API 级别 26）中，用户可以使用 Quicksettings 图块或 Display 设置在自动屏幕旋转和纵向旋转模式之间切换。 纵向模式已重命名为旋转锁定，它会在自动屏幕旋转关闭时启用。 自动屏幕旋转模式没有任何变更。

当设备处于旋转锁定模式时，用户可将其屏幕锁定到顶层可见 Activity 所支持的任何旋转。 Activity 不应假定它将始终以纵向呈现。 如果顶层 Activity 可在自动屏幕旋转模式下以多种旋转呈现，则应在旋转锁定模式下提供相同的选项，根据 Activity 的 screenOrientation 设置，允许存在一些例外情况（见下表）。

请求特定屏幕方向（例如，screenOrientation=landscape）的 Activity 会忽略用户锁定首选项，并且行为与 Android 8.0 中的行为相同。

可在 Android Manifest 中，或以编程方式通过 setRequestedOrientation() 在 Activity 级别设置屏幕方向首选项。

旋转锁定模式通过设置 WindowManager 在处理 Activity 旋转时使用的用户旋转首选项来发挥作用。 用户旋转首选项可能在下列情况下发生变更。 请注意，恢复设备的自然旋转存在偏差，对于外形与手机类似的设备通常设置为纵向：

当用户接受旋转建议时，旋转首选项变为建议方向。

当用户切换到强制纵向应用（包括锁定屏幕或启动器）时，旋转首选项变为纵向。

下表总结了常见屏幕方向的旋转行为：

屏幕方向    行为

未指定、user    在自动屏幕旋转和旋转锁定下，Activity 可以纵向或横向（以及颠倒纵向或横向）呈现。 预期同时支持纵向和横向布局。

userLandscape    在自动屏幕旋转和旋转锁定下，Activity 可以横向或颠倒横向呈现。 预期只支持横向布局。

userPortrait    在自动屏幕旋转和旋转锁定下，Activity 可以纵向或颠倒纵向呈现。 预期只支持纵向布局。

fullUser    在自动屏幕旋转和旋转锁定下，Activity 可以纵向或横向（以及颠倒纵向或横向）呈现。 预期同时支持纵向和横向布局。

旋转锁定用户将可选择锁定到颠倒纵向，通常为 180o。

sensor、fullSensor、sensorPortrait、sensorLandscape    忽略旋转锁定模式首选项，视为自动屏幕旋转已启用。 请仅在例外情况下并经过仔细的用

7.Apache HTTP 客户端弃用影响采用非标准 ClassLoader 的应用

在 Android 6.0 中，我们取消了对 Apache HTTP 客户端的支持。

此变更对大多数不以 Android 9 或更高版本为目标的应用没有任何影响。 不过，此变更会影响使用非标准 ClassLoader 结构的某些应用，即使这些应用不以 Android 9 或更高版本为目标平台。

如果应用使用显式委托到系统 ClassLoader 的非标准 ClassLoader，则应用会受到影响。

 在 org.apache.http.* 中查找类时，这些应用需要委托给应用 ClassLoader。 如果它们委托给系统 ClassLoader，则应用在 Android 9 或更高版本上将失败并显示 NoClassDefFoundError，因为系统 ClassLoader 不再识别这些类。 为防止将来出现类似问题，一般情况下，应用应通过应用 ClassLoader 加载类，而不是直接访问系统 ClassLoader。

 8.枚举相机

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

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

Android Q(Android 10)

行为变更：所有应用

Android Q 平台包含一些行为变更，这些变更可能会影响您的应用。以下行为变更将影响在 Android Q 上运行的所有应用，无论其采用哪种 targetSdkVersion 都不例外。您应该测试您的应用，然后根据需要进行更改以适当地支持这些变更（如果适用）。

非 SDK 接口限制

为了帮助确保应用稳定性和兼容性，Android 平台开始限制您的应用可在 Android 9（API 级别 28）中使用哪些非 SDK 接口。Android Q 包含更新后的受限非 SDK 接口列表（基于与 Android 开发者之间的协作以及最新的内部测试）。我们的目标是在限制使用非 SDK 接口之前确保有可用的公开替代方案。

如果您不打算以 Android Q 为目标平台，那么其中一些变更可能不会立即对您产生影响。虽然您目前可以使用灰名单中的一些非 SDK 接口（取决于您应用的目标 API 级别），但如果您使用任何非 SDK 方法或字段，则应用无法运行的风险终归较高。

如果您不确定自己的应用是否使用了非 SDK 接口，则可以测试该应用进行确认。如果您的应用依赖于非 SDK 接口，则应该开始计划迁移到 SDK 替代方案。不过，我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案，则应该请求新的公共 API。

要了解详情，请参阅非 SDK 接口在 Android Q 中的受限情况出现变化以及对非 SDK 接口的限制。

手势导航（这个国内厂商早都有了）

从 Android Q 开始，用户可以在设备中启用手势导航。如果用户启用手势导航，则会影响设备上的所有应用，无论应用是否以 Android Q 为目标平台，都是如此。例如，如果用户从屏幕边缘向内滑动，系统会将该手势解读为“返回”导航，除非应用针对屏幕的相应部分明确替换该手势。

为了确保您的应用与手势导航兼容，您需要将应用内容扩展到屏幕边缘，并适当地处理存在冲突的手势。有关信息，请参阅手势导航文档。

NDK

Android Q 包含以下 NDK 方面的变更。

共享对象不得包含文本重定位

Android 6.0（API 级别 23）已禁止在共享对象中使用文本重定位。代码必须按原样加载，且不得修改。此变更可以缩短应用的加载时间并提高安全性。

在 Android Q 测试版 1 和 2 中，SELinux 对以 Android 8.0（API 级别 26）及更高版本为目标平台的应用强制执行此限制。从 Android Q 测试版 3 开始，将对以 Android Q（API 级别 29）及更高版本为目标平台的应用强制执行此限制。如果这些应用继续使用包含文本重定位的共享对象，则出现故障的风险较高。

安全性

Android Q 包含以下安全性方面的变更。

移除了应用主目录的执行权限

以 Android Q 为目标平台的不受信任的应用无法再针对应用主目录中的文件调用 exec()。这种从可写应用的主目录执行文件的行为违反了 W^X。应用应该仅加载嵌入到应用的 APK 文件中的二进制代码。

此外，以 Android Q 为目标平台的应用无法针对已执行 dlopen() 的文件中的可执行代码进行内存中修改。这包括含有文本重定位的所有共享对象 (.so) 文件。

WLAN 直连广播

在 Android Q 中，以下与 WLAN 直连相关的广播不再具有粘性。

WIFI_P2P_CONNECTION_CHANGED_ACTION

WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

如果您的应用依赖于在注册时接收这些广播（因为其之前一直具有粘性），请在初始化时使用适当的 get() 方法获取信息。

WLAN 感知功能

Android Q 扩大了支持范围，现在可以使用 WLAN 感知数据路径轻松创建 TCP/UDP 套接字。要创建连接到 ServerSocket 的 TCP/UDP 套接字，客户端设备需要知道服务器的 IPv6 地址和端口。这在之前需要通过频外方式进行通信（例如使用 BT 或 WLAN 感知第 2 层消息传递），或者使用其他协议（例如 mDNS）通过频内方式发现。而借助 Android Q，可以将此类消息作为网络设置的一部分进行传递。

服务器可以执行以下任一操作：

初始化 ServerSocket 并设置或获取要使用的端口。

将端口信息指定为 WLAN 感知网络请求的一部分。

————————————————

版权声明：本文为CSDN博主「冉航--小虾米」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：https://blog.csdn.net/gaoxiaoweiandy/java/article/details/83216001