Android 5.0 行为变更

API 级别：21

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

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

如需简要了解新平台功能，请改为参阅 Android Lollipop 亮点。

视频

Dev Byte：Android 5.0 的新变化

Dev Byte：通知

Android 运行时 (ART)

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

如需简要了解 ART 的新功能，请参阅 ART 简介。部分主要的新功能包括：

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

大多数 Android 应用应该无需任何更改就能在 ART 下运行。不过，Dalvik 采用的一些技术并不适用于 ART。如需了解最重要问题，请参阅在 Android 运行时 (ART) 上验证应用行为。如存在以下情况，应特别注意：

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

通知

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

Material Design 样式

通知使用深色文本在白色（或非常浅色）背景上绘制，以与新的 Material Design widget 相匹配。请确保所有通知都与新的配色方案相得益彰。如果通知看起来错误，请进行修复：

  • 使用 setColor() 可在图标图片后面的圆圈中设置强调色。
  • 更新或移除涉及颜色的素材资源。系统会在操作图标和主通知图标中忽略所有非 Alpha 通道。您应假设这些图标仅限 Alpha 测试。系统以白色绘制通知图标，以深灰色绘制操作图标。

提示音和振动

如果您目前使用 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 修订版本 10c。如需详细了解 NDK 的重要变更和 bug 修复，请参阅修订版 10c 版本说明。

绑定到服务

Context.bindService() 方法现在需要显式 Intent，如果给定隐式 intent，则会抛出异常。为了确保应用的安全性，请在启动或绑定 Service 时使用显式 intent，并且不要为服务声明 intent 过滤器。

WebView

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

  • 如果您的应用以 API 级别 21 或更高级别为目标平台：
    • 默认情况下，系统会屏蔽混合内容 Cookie 和第三方 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 平台版本（低至 Android 2.3）中提供这些变更。

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

例如，服务器可能仅支持 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 或更早的协议，并忽略它不理解的 TLS 扩展。在某些情况下，在服务器软件升级之前，在服务器上停用 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 取消了对锁屏 widget 的支持；它继续支持主屏幕上的 widget。