Android 5.0 行为变更

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

如果您之前发布过 Android 应用，请注意您的应用可能受到 Android 5.0 中这些变化的影响。

如需详细了解新平台功能，请参阅 Android Lollipop 重要内容。

Android Runtime (ART)

在 Android 5.0 中，ART 运行时取代 Dalvik 成为平台默认设置。Android 4.4 中已引入处于实验阶段的 ART 运行时。

有关 ART 的新功能概述，请参阅 ART 简介。部分主要的新功能包括：

• 预先 (AOT) 编译
• 改进的垃圾回收 (GC)
• 改进的调试支持

大多数 Android 应用无需任何更改就可以在 ART 下工作。不过，部分适合 Dalvik 的技术并不适用于 ART。如需了解有关最重要问题的信息，请参阅在 Android Runtime (ART) 上验证应用行为。如存在以下情况，应特别注意：

• 您的应用使用 Java 原生接口 (JNI) 运行 C/C++ 代码。
• 您使用生成非标准代码的开发工具（例如，一些代码混淆工具）。
• 您使用与压缩垃圾回收不兼容的技术。

通知

请确保您的通知考虑了上述 Android 5.0 变更。要详细了解如何为 Android 5.0 及更高版本设计通知，请参阅通知设计指南。

Material Design 样式

在白色（或非常浅）的背景上使用深色文本绘制通知，以便与新的 Material Design 小部件匹配。请确保您的所有通知都与新的配色方案协调一致。如果您的通知看上去不协调，请进行修正：

• 使用 setColor() 在您的图标图像后面的圆形中设置重点色彩。
• 更新或移除使用色彩的资源。系统在操作图标和主要通知图标中忽略所有非阿尔法通道。您应假设这些图标仅支持阿尔法通道。系统用白色绘制通知图标，用深灰色绘制操作图标。

声音和振动

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

将设备设为 RINGER_MODE_SILENT 可使设备进入新的优先模式。如果您将设备设为 RINGER_MODE_NORMAL 或 RINGER_MODE_VIBRATE，则设备将退出优先模式。

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

锁定屏幕可见性

默认情况下，在 Android 5.0 中，通知现在显示在用户的锁定屏幕上。用户可以选择保护敏感信息不被公开，在此情况下，系统会自动删减通知显示的文本。要自定义此删减的通知，请使用 setPublicVersion()。

如果通知不包含个人信息，或者您想允许媒体播放控件显示在通知上，则调用 setVisibility() 方法并将通知的可见性级别设为 VISIBILITY_PUBLIC。

媒体播放

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

浮动通知

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

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

• 用户的 Activity 处于全屏模式中（应用使用 fullScreenIntent）
• 通知具有较高的优先级并使用铃声或振动

如果您的应用在以上任何情形下实现通知，请确保系统正确显示浮动通知。

媒体控件和 RemoteControlClient

RemoteControlClient 类现已弃用。请尽快切换到新的 MediaSession API。

Android 5.0 中的锁定屏幕不会为 MediaSession 或 RemoteControlClient 显示传输控件。不过，您的应用可以通过一个通知从锁定屏幕提供媒体播放控件。这让您的应用可以对媒体按钮的显示进行更多控制，同时为使用锁定设备和未锁定设备的用户提供一致的体验。

为实现此目的，Android 5.0 引入了一个新的 Notification.MediaStyle 模板。Notification.MediaStyle 将您使用 Notification.Builder.addAction() 添加的通知操作转换为精简按钮，嵌入到应用的媒体播放通知中。将您的会话令牌传递到 setSession() 方法以告知系统该通知控制进行中的媒体会话。

请务必将通知的可见性设为 VISIBILITY_PUBLIC，以将通知标记为安全，从而显示在任何锁定屏幕上（以安全方式或其他方式）。如需了解详细信息，请参阅锁定屏幕通知。

要让应用在 Android TV 或 Wear 平台上运行时显示媒体播放控件，则实现 MediaSession 类。如果您的应用需要在 Android 设备上接收媒体按钮事件，您还应实现 MediaSession。

getRecentTasks()

Android 5.0 中引入新的“并发文档和 Activity 任务”功能后（请参阅下文最近使用的应用屏幕中的并发文档和 Activity），为提升用户隐私的安全性，现已弃用 ActivityManager.getRecentTasks() 方法。对于向后兼容性，此方法仍会返回它的一小部分数据，包括调用应用自己的任务和可能的一些其他非敏感任务（如首页）。如果您的应用使用此方法检索它自己的任务，则改用 getAppTasks() 检索该信息。

Android NDK 中的 64 位支持

Android 5.0 引入了对 64 位系统的支持。64 位增强功能可增加地址空间和提升性能，同时仍完全支持现有的 32 位应用。64 位支持也可改进用于加密的 OpenSSL 的性能。此外，该版本还引入了新的原生媒体 NDK API，以及原生 OpenGL ES (GLES) 3.1 支持。

要使用 Android 5.0 中提供的 64 位支持，请从 Android NDK 页面下载和安装 NDK Revision 10c。有关对 NDK 进行的重要变更和问题修复的更多信息，请参阅 Revision 10c 版本说明。

绑定到服务

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

WebView

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

• 如果您的应用是面向 API 级别 21 或更高级别：
  • 默认情况下，系统会阻止混合内容和第三方 Cookie。要允许混合内容和第三方 Cookie，请分别使用 setMixedContentMode() 和 setAcceptThirdPartyCookies() 方法。
  • 系统现在可以智能地选择要绘制的 HTML 文档部分。这个新的默认行为有助于减少内存占用和提升性能。如果您要一次渲染整个文档，可通过调用 enableSlowWholeDocumentDraw() 停用此优化。
• 如果您的应用是面向低于 21 的 API 级别：系统允许混合内容和第三方 Cookie，并始终一次渲染整个文档。

自定义权限唯一性要求

根据权限概述中所述，Android 应用可以定义以专有方式管理组件访问权限的自定义权限，无需使用平台预定义的系统权限。应用在其清单文件中声明的 <permission> 元素中定义自定义权限。

少数情况下定义自定义权限是合规且安全的方法。不过，创建自定义权限有时并无必要，甚至可能会给应用带来潜在风险，具体取决于分配给权限的保护级别。

Android 5.0 其中一项行为变更确保只有一个应用可以定义给定自定义权限，除非使用与定义权限的其他应用相同的密钥进行签名。

使用重复的自定义权限的应用

任何应用都可以定义它需要的任何自定义权限，因此，可能会出现多个应用定义相同的自定义权限的情况。例如，如果两个应用提供相似的功能，它们可能会为其自定义权限派生出相同的逻辑名称。应用可能还纳入了本身包含相同自定义权限定义的通用公共库或代码示例。

在 Android 4.4 和更早的版本中，用户可以在给定设备上安装多个此类应用，不过系统会分配由第一个安装的应用指定的保护级别。

从 Android 5.0 开始，对于使用不同密钥签名的应用，系统会强制执行新的自定义权限唯一性限制。现在，设备上只有一个应用可以定义给定的自定义权限（按其名称确定），除非定义此权限的其他应用使用相同密钥签名。如果用户尝试安装的应用具有重复自定义权限且签名密钥不同于定义此权限的驻留应用，则系统将阻止安装。

您的应用需要注意的事项

在 Android 5.0 和更新的版本中，应用可以和以前一样继续定义自己的自定义权限，并通过 <uses-permission> 机制请求其他应用的自定义权限。不过，对于 Android 5.0 中引入的新要求，您应仔细评估可能给您的应用带来的影响。

下面是一些需要考虑的因素：

• 您的应用是否在其清单文件中声明任何 <permission> 元素？如果是，那么这些权限是否确实是您的应用或服务正常运行不可或缺的？或者，能否使用系统默认权限代替它们？
• 如果您的应用中具有 <permission> 元素，您是否知道它们来自哪里？
• 您实际上是否打算让其他应用通过 <uses-permission> 请求您的自定义权限？
• 您是否在您包含 <permission> 元素的应用中使用样板文件或示例代码？那些权限元素确实是不可或缺的吗？
• 您的自定义权限使用的名称是简单名称还是基于其他应用可能共享的通用术语？

新安装和更新

如上所述，在运行 Android 4.4 或更早版本的设备上新安装和更新您的应用不会受影响，且行为没有任何变化。在运行 Android 5.0 或更新版本的设备上进行新安装和更新时，如果应用定义一个已由现有驻留应用定义的自定义权限，则系统会阻止安装您的应用。

使用 Android 5.0 系统更新的现有安装

如果您的应用使用自定义更新且已广泛分发和安装，那么，当用户收到将设备升级到 Android 5.0 的更新时，您的应用可能会受影响。在安装系统更新后，系统重新验证已安装的应用，包括检查它们的自定义权限。如果您的应用定义一个已由另一个通过验证的应用定义的自定义权限，且您的应用没有使用与该应用相同的密钥签名，则系统不会重新安装您的应用。

建议

在运行 Android 5.0 或更新版本的设备上，我们建议您立即检查您的应用，进行任何所需的调整，并尽快向您的用户发布更新版本。

• 如果您在应用中使用自定义权限，则考虑它们的来源以及您是否确实需要它们。从您的应用中移除所有 <permission> 元素，除非您确定它们是应用正常运行所必需的元素。
• 尽可能考虑使用系统默认权限替代您的自定义权限。
• 如果您的应用需要自定义权限，则重命名您的自定义权限，使其成为您的应用独有的权限，例如，将它们追加到应用的完整软件包名称。
• 如果您有一组使用不同密钥签名的应用，且这些应用通过自定义权限访问共享组件，则确保此自定义权限在共享组件中仅定义一次。使用共享组件的应用不应自己定义自定义权限，而应通过 <uses-permission> 机制请求访问权限。
• 如果您有一组使用相同密钥签名的应用，则每个应用都可以根据需要定义相同的 自定义权限， 系统允许以常规方式安装这些应用。

TLS/SSL 默认配置变更

Android 5.0 针对 HTTPS 和其他 TLS/SSL 通信引入了对应用使用的默认 TLS/SSL 配置的变更：

• TLSv1.2 和 TLSv1.1 协议现已启用，
• AES-GCM (AEAD) 加密套件现已启用，
• MD5、3DES、导出和静态密钥 ECDH 加密套件现已停用，
• 首选使用 Forward Secrecy 加密套件（ECDHE 和 DHE）。

在下面列出的少数情况下，这些变更可能会导致 HTTPS 或 TLS/SSL 连接断开。

请注意，来自 Google Play 服务的安全性 ProviderInstaller 自 Android 2.3 开始就已在 Android 平台版本上提供这些变更。

服务器不支持任何已启用的加密套件

例如，服务器可能仅支持 3DES 或 MD5 加密套件。首选的修复方法是改进服务器的配置，以启用更强更现代的加密套件和协议。理想情况下，应启用 TLSv1.2 和 AES-GCM 以及 Forward Secrecy 加密套件（ECDHE、DHE），且最好使用后者。

也可以修改应用以使用自定义 SSLSocketFactory 与服务器通信。出厂时应精心设计以创建 SSLSocket 实例，除默认加密套件外，此实例还应启用服务器所需的部分加密套件。

应用对用于连接服务器的加密套件做出错误的假设

例如，某些应用包含中断的自定义 X509TrustManager，因为它预计 authType 参数将成为 RSA，但出现了 ECDHE_RSA 或 DHE_RSA。

服务器不支持 TLSv1.1、TLSv1.2 或新的 TLS 扩展

例如，与服务器握手的 TLS/SSL 被错误地拒绝或出现停顿。首选的修复方法是升级服务器以符合 TLS/SSL 协议。这使服务器可以成功地协商这些更新的协议或协商 TLSv1 或更早的协议，并忽略它不理解的传输层安全协议扩展程序。在某些情况下，在服务器上禁用 TLSv1.1 和 TLSv1.2 可以作为权宜之计，直到升级服务器软件。

也可以修改应用以使用自定义 SSLSocketFactory 与服务器通信。出厂时应精心设计以创建 SSLSocket 实例，该实例仅包含已启用且服务器可以正确为其提供支持的协议。

支持托管配置文件

设备管理员可以向设备添加托管配置文件。此配置文件由管理员所有，让管理员控制托管配置文件的同时，允许由用户控制其自己的个人配置文件及其存储空间。此变更会通过下列方式影响您的现有应用的行为。

处理 Intent

设备管理员可以从托管配置文件限制对系统应用的访问权限。在此情况下，如果应用从托管文件触发一个通常由该应用处理的 intent，且托管文件上没有适合此 intent 的处理程序，则此 intent 会引发异常。例如，设备管理员可以限制托管配置文件上的应用访问系统的相机应用。如果您的应用在托管配置文件上运行，并为 MediaStore.ACTION_IMAGE_CAPTURE调用 startActivityForResult()，且托管配置文件上没有可以处理此 intent 的应用，则会导致 ActivityNotFoundException。

为防止出现此情况，您可以在触发任何 intent 之前检查是否至少有一个适合此 intent 的处理程序。要检查是否存在有效的处理程序，请调用 Intent.resolveActivity()。您可以在轻松拍照：使用相机应用拍摄照片中查看执行上述操作的示例。

在各个配置文件中共享文件

每个配置文件都有自己的文件存储空间。文件 URI 指的是文件存储空间中的特定位置，这意味着在一个配置文件上有效的文件 URI 在另一个文件上是无效的。对于只访问自己创建的文件的应用而言，这通常不是什么问题。不过，如果应用向某个 intent 附加文件，则附加文件 URI 并不安全，因为在某些情况下，可能会在其他配置文件上处理该 intent。例如，设备管理员可能会指定图像采集事件应由个人配置文件上的相机应用处理。如果此 intent 由托管配置文件上的应用触发，则相机需要能够将图像写入托管配置文件的应用可以读取的位置。

为安全起见，如果您需要将文件附加到某个可能会从一个配置文件移动到另一个配置文件的 intent，您应为该文件创建并使用内容 URI。有关共享文件及内容 URI 的更多信息，请参阅共享文件。例如，设备管理员可能会制定将由个人配置文件中的相机处理的 ACTION_IMAGE_CAPTURE 白名单。触发的 intent 的 EXTRA_OUTPUT 应包含指定照片应存储在何处的内容 URI。相机应用可以将图像写入该 URI 指定的位置，触发 intent 的应用将能够读取该文件，即使应用位于其他配置文件上。

已移除锁定屏幕小部件支持

Android 5.0 移除了对锁定屏幕小部件的支持；它继续为主屏幕上的小组件提供支持。