用户体验

沉浸式手势导航改进

Android 12简化了沉浸式模式，使手势导航更加轻松，并且与观看视频和读书等活动的其余部分更加一致。应用仍然可以防止 全屏游戏体验中的意外手势，因此用户在玩游戏时不会意外退出游戏；现在，所有其他全屏或身临其境的体验都允许用户一键浏览手机。

要做到这一点，对于非粘性身临其境的体验现有的行为（BEHAVIOR_SHOW_BARS_BY_TOUCH， BEHAVIOR_SHOW_BARS_BY_SWIPE）已被弃用Android中12开始，他们已被替换缺省行为（BEHAVIOR_DEFAULT），允许比划着一个刷卡隐藏系统栏时。此标志根据模式显示不同的视觉和功能行为：

• 在三键模式下，视觉和功能行为与12之前的Android版本中的沉浸模式相同。
• 在手势导航模式下，行为如下：
  • 在视觉上，它与Android 11及更低版本中的沉浸模式相同。
  • 从功能上讲，即使隐藏了栏，也允许使用手势。系统后部仅需要一次滑动即可调用，而无需使用Android 11的两次滑动。无需其他滑动即可拉下通知栏或开始回家。

BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE对于Android 12，粘性沉浸模式（）并未更改。请注意此功能具有以下向后兼容性：

• 对于以Android 11和更低版本为目标的在Android 12上运行的应用：
  • BEHAVIOR_SHOW_TRANSIENT_BARS_BY_SWIPE 在功能和视觉上都表现相同。
  • 默认设置映射到BEHAVIOR_SHOW_BARS_BY_SWIPE。
• 对于在Android 11（API级别30）及更低版本（针对Android 12）上运行的应用：
  • 除了BEHAVIOR_SHOW_BARS_BY_TOUCH 映射到之外，预期具有相同的行为BEHAVIOR_SHOW_BARS_BY_SWIPE。
  • 确保将您的SDK级别更新为新的默认值（BEHAVIOR_SHOW_BARS_BY_SWIPE）。否则，BEHAVIOR_SHOW_BARS_BY_TOUCH 保留默认值。

前台服务通知延迟

为了为Android 12上的短期运行的前台服务提供简化的体验，系统可以将某些前台服务的前台服务通知显示延迟10秒。此更改使短期任务有机会在其通知出现之前完成。

如果前台服务至少具有以下特征之一，则系统在服务启动后立即显示关联的通知：

• 该服务与包含操作按钮的通知关联。
• 该服务拥有 foregroundServiceType 的connectedDevice，mediaPlayback，mediaProjection，或phoneCall。
• 该服务提供了在通知的category属性中定义的与电话，导航或媒体播放有关的用例。 注意：这些用例可能会在将来的Android 12 Developer Preview版本中进行更改。
• 该服务已通过setShowForegroundImmediately() 在设置通知时进行调用来退出行为更改 。

隐私

Netlink MAC地址限制

Android 12进一步限制了所有非系统应用程序对设备MAC地址（不可重置的标识符）的访问，无论目标API级别如何。

相关API会返回空值或占位符值，具体取决于应用程序的目标SDK版本：

• 如果您的应用针对Android 12，则API返回null。
• 如果您的应用定位到Android 11或更低版本，则API返回硬编码的占位符值： 02:00:00:00:00:00

开发人员应该使用ConnectivityManager ，而不是低级别的API，如NetworkInterface， getifaddrs()或网络链路插槽。当开发人员调用NetworkInterface.getHardwareAddress() 其代码时，logcat输出显示： CompatibilityChangeReporter: Compat change id reported: 170188668;

开发人员可以使用调用的兼容性标志[RETURN_NULL_HARDWARE_ADDRESS](/reference/compat-framework-changes?db=dac-team#return_null_hardware_address) 来切换NetworkInterface.getHardwareAddress() 启用或02:00:00:00:00:00禁用时返回null的行为。

安全

不信任的触摸事件被阻止

为了维护系统安全性和良好的用户体验，Android 12会阻止应用程序在覆盖层以不安全的方式遮盖应用程序时使用触摸事件。换句话说，系统会阻止通过某些窗口的触摸，但有一些例外。

受影响的应用

此更改会影响选择让触摸通过其窗口（例如通过使用 FLAG_NOT_TOUCHABLE 标志）的应用。几个示例包括但不限于以下示例：

• 需要SYSTEM_ALERT_WINDOW 权限的叠加层 ，例如使用TYPE_APPLICATION_OVERLAY，使用FLAG_NOT_TOUCHABLE标志的窗口 。
• 使用该FLAG_NOT_TOUCHABLE标志的活动窗口。
• 敬酒消息。

例外情况

在以下情况下，允许“通过”触摸：

• 您的应用内的互动。您的应用会显示叠加层，并且叠加层仅在用户与您的应用进行交互时才会显示。
• 受信任的窗口。这些窗口包括（但不限于）以下内容：

  • 辅助功能窗口

  • 输入法编辑器（IME）窗口

  • 助手窗口

  • *注意：Windows类型 **不受信任。TYPE_APPLICATION_OVERLAY

• 隐形窗户。窗口的根视图为 GONE或 INVISIBLE。
• 完全透明的窗口。该alpha窗口的 属性为0.0。
• 足够透明的系统警报窗口。当组合的不透明度小于或等于系统对触摸的最大遮盖不透明度时，系统认为一组系统警报窗口是足够透明的。在Developer Preview 1中，最大不透明度为0.8，但是此值稍后可能在Developer Preview中更改。

检测何时阻止了不受信任的触摸

如果触摸动作被系统阻止， Logcat会记录以下消息：

Untrusted touch due to occlusion by PACKAGE_NAME

测试变更

默认情况下，在运行Android 12 Developer Preview 1的设备上，不信任的触摸被阻止。要允许不信任的触摸，请在终端窗口中运行以下ADB命令：

＃特定的应用程序
adb shell可以禁用BLOCK_UNTRUSTED_TOUCHES com 。例子。应用程序

＃所有应用程序＃如果在触摸被阻止时仍希望看到Logcat消息警告，请使用1而不是0。adb shell设置将global block_untrusted_touches 0

要将行为恢复为默认行为（阻止了不信任的触摸），请运行以下命令：

＃一个特定的应用程序
adb shell兼容重置BLOCK_UNTRUSTED_TOUCHES com 。例子。应用程序

＃所有应用程序
adb shell设置都放入全局block_untrusted_touches 2

应用无法关闭系统

为了在与应用程序和系统进行交互时改善用户控制，从 ACTION_CLOSE_SYSTEM_DIALOGS Android 12开始不推荐使用intent操作。除少数特殊情况外，当您的应用程序尝试调用包含此操作的intent时，系统会执行以下操作之一在您应用的目标SDK版本上：

• 如果您的应用程序以Android 12为目标，SecurityException则会出现a 。
• 如果您的应用定位到Android 11（API级别30）或更低版本，则该意图不会执行，并且Logcat中会显示以下消息 ： E ActivityTaskManager权限被拒绝：\
  从\广播的android.intent.action.CLOSE_SYSTEM_DIALOGS
  com.package.name需要android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS，\
  放下广播。

例外情况

在以下情况下，应用仍可以在Android 12上关闭系统对话框：

• 您的应用正在运行测试。
• 您的应用定位到Android 11或更低版本，并且在通知抽屉的顶部显示一个窗口。 注意：如果您的应用定位到Android 12，则ACTION_CLOSE_SYSTEM_DIALOGS在这种情况下无需使用 。这是因为，如果您的应用程序startActivity() 在通知抽屉顶部有一个窗口的同时调用 ，则系统会自动关闭通知抽屉。
• 您的应用定位到Android 11或更低版本。此外，用户可能已经使用通知的操作按钮与通知进行了交互，并且您的应用正在响应该用户操作来处理服务或广播接收器。

非SDK接口限制

Android 12包括基于与Android开发人员的协作以及最新的内部测试而更新的受限非SDK接口列表。只要有可能，在限制非SDK接口之前，请确保可以使用公共替代方案。

如果您的应用程序未针对Android 12，则其中的某些更改可能不会立即影响您。但是，尽管您目前可以使用某些非SDK接口（取决于应用程序的目标API级别），但是使用任何非SDK方法或字段始终会带来破坏应用程序的高风险。

如果不确定您的应用程序是否使用非SDK接口，则可以测试您的应用程序 以找出答案。如果您的应用依赖于非SDK界面，则应开始计划向SDK替代产品的迁移。不过，我们了解到某些应用程序具有使用非SDK接口的有效用例。如果您找不到在应用程序中为功能使用非SDK接口的替代方法，则应请求一个新的Public API。

要了解有关此版本Android中的更改的更多信息，请参阅Android 12中非SDK接口限制的更新。要大致了解有关非SDK接口的更多信息，请参阅非SDK接口限制。