Android 12的行为变更和版本兼容思路

一年一度的产品线兼容活动又开始了。Android系统每更新一次系统，对开发者而言都是持续而漫长的挑战。

自15年6.0的兼容以来，每年给公司产品线app做版本兼容，成了我每年的保留节目……

结束完产品线app对鸿蒙系统的兼容适配后，今天开始搞Android12的兼容处理工作。

同学们，android12预览版已出，工头叫我们搬砖了。

目的

产品线app兼容Android12

思路

先看看官方的时间规划，以便我们了解官方每个时间节点在做什么，最重要的是知道他的beta版什么时候出，什么时候最终发行，国内四大厂商的系统版本一般在最终beta后1-2个月发布新系统更新，这个时间点对于需要立刻兼容新系统的app来说，可以说deadline了。

在这个时间内：

1.分析Android12变更；

2.根据android12的变更分析产品要变更的点；

3.搭建验证环境，初步验证现在产品；

4.总结明确产品需要变更兼容的点；

5.识别主要风险和变更难点；

6.分解变更点，评估编码时间；

7.根据项目周期，分配人员，分配任务模块；

8.编码完成后自测；

9.自动化压力测试，功能性测试；

10.测试人员测试用例覆盖；

11.灰度发布；

12.根据埋点上报的信息决定是否全面发布；

Android12时间线

由于每年都做新版本兼容，即大方向上只要查看Android12相较于Android 11的变动就好，剩余的就是自动化压力测试，功能流程测试作为补充。

Android12平台行为更改：所有应用

用户体验

沉浸式手势导航改进

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秒。此项更改使短期任务有机会在其通知出现之前完成。

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

• 该服务与包含action buttons.的通知相关联。
• 该服务拥有 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;

安全

不信任的触摸事件被阻止

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

受影响的应用

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

• 需要SYSTEM_ALERT_WINDOW 权限的叠加层 ，例如使用TYPE_APPLICATION_OVERLAY，使用FLAG_NOT_TOUCHABLE标志的窗口 。
• 使用该FLAG_NOT_TOUCHABLE标志的活动窗口。
• Toast messages.

例外情况

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

• 您的应用内的互动。您的应用会显示叠加层，并且叠加层仅在用户与您的应用进行交互时才会显示。
• 受信任的窗口。这些窗口包括（但不限于）以下内容：
  • 辅助功能窗口
  • 输入法编辑器（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命令：

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

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

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

应用无法关闭系统对话框

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

如果您的应用程序以Android 12为目标，则会出现a 。

例外情况

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

• 您的应用正在运行instrumentation test。
• 您的应用程序以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接口的替代方法，则应请求新的公共API。

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

针对目标版本为Android 12应用的变更

隐私

WebView中的Modern SameSite cookie行为

Android的WebView组件基于Chromium（Chromium），Chromium是支持Google Chrome浏览器的开源项目。去年，Chromium对第三方Cookie的处理方式进行了更改，以提供更高的安全性和隐私性，并为用户提供更高的透明度和控制力。这些更改已经向许多Chrome用户推出，并且从Android 12开始，这些更改现在已应用于WebView。

SameSitecookie的属性控制它是否可以与任何请求一起发送，还是只能与相同站点的请求一起发送。Android 12中的WebView的基本版本（版本89.0.4385.0）包括以下隐私保护更改，这些更改改进了第三方Cookie的默认处理并有助于防止意外的跨站点共享：

• 没有SameSite属性的Cookie被视为SameSite=Lax。
• 带有的CookiesSameSite=None还必须指定Secure属性，这意味着它们需要安全的上下文，并应通过HTTPS发送。
• 现在，站点的HTTP和HTTPS版本之间的链接被视为跨站点请求，因此，除非将cookie适当地标记为，否则不会发送cookie SameSite=None; Secure。

对于开发人员，一般指南是在关键用户流中标识跨站点Cookie的依存关系，并确保SameSite 在需要时使用适当的值显式设置属性。您必须明确指定允许在跨网站或从HTTP到HTTPS的同一站点导航中使用的cookie。

有关这些更改的Web开发人员的完整指南，请参阅SameSite Cookies解释和Schemeful SameSite。

在您的应用程序中测试SameSite行为

如果您的应用程序使用WebView，或者如果您管理使用Cookie的网站或服务，则建议您在Android 12 WebView上测试流程。如果发现问题，则可能需要更新cookie以支持新的SameSite行为。

监视登录和嵌入内容中的问题，以及登录流程，购买流程和其他身份验证流程，在这些流程中，用户从不安全的页面开始，然后过渡到安全的页面。

要使用WebView测试应用程序，必须通过完成以下任一步骤来为要测试的应用程序启用新的SameSite行为：

• 通过 在WebView devtools中切换UI标志webview-enable-modern-cookie-same-site，在测试设备上手动启用SameSite行为。 通过这种方法，您可以在运行Android 5.0（API级别21）或更高版本（包括Android 12）和WebView 89.0.4385.0或更高版本的任何设备上进行测试。
• 将您的应用编译为以Android 12为目标targetSdkVersion。 如果使用这种方法，则必须使用运行Android 12和WebView 89.0.4385.0或更高版本的设备。

注意：由于已知问题会影响Android 12 Developer Preview 1中的WebView，因此您目前无法在Android 12上启用或测试Schemeful Same-Site更改。我们已在内部解决此问题，以后将包括在内。开发人员预览版。同时，您仍然可以在Android 12上测试您的应用程序是否有其他SameSite更改（默认情况下 ，请参见SameSite = Lax，并且SameSite = None必须是安全的）。

有关在Android上进行WebView的远程调试的信息，请参阅《远程调试Android设备入门》。

其他资源

有关SameSite现代行为以及Chrome和WebView的首次发布的详细信息，请访问Chromium SameSite更新页面。如果您在WebView或Chromium中发现错误，则可以在公共Chromium问题跟踪器中报告该错误。

ADB backup备份限制

为了帮助保护私人应用程序数据，Android 12更改了该adb backup命令的默认行为。对于面向Android 12的应用程序，当用户运行adb backup命令时，应用程序数据将从从设备导出的任何其他系统数据中排除。

如果您的测试或开发工作流程使用依赖于应用程序数据adb backup，您现在可以通过在应用程序的清单文件中设置android:debuggable 来选择导出应用程序的数据 true。

注意：为帮助保护您的应用程序数据，请记住在发布应用程序之前将其设置android:debuggable 为false。

安全

更安全的组件导出

如果您的应用程序以Android 12为目标并且包含 使用 intent filters的activities， services, broadcast receivers，则必须显式声明android:exported这些应用程序组件的 属性。

警告：如果活动，服务或广播接收者使用 intent filters，并且没有明确声明的值 android:exported，则您的应用不能安装在运行Android 12的设备上。 如果您尝试在使用Android Studio时安装此类应用程序，则 Logcat将显示以下错误消息：

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

如果您的应用没有为android:exported需要的时间声明值，Logcat将提供以下错误消息：

Targeting S+ (version 10000 and above) requires that an explicit value for \
android:exported be defined when intent filters are present

以下代码段显示了一个包含 intent filters且已针对Android 12正确配置的服务示例：

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

待处理的Intent必须声明可变性

如果您的应用程序针对Android 12，则必须指定PendingIntent应用程序创建的每个对象的可变性。此附加要求可提高应用程序的安全性。

要声明给定PendingIntent对象是可变的或不可变的 ，请分别使用 PendingIntent.FLAG_MUTABLE 或 PendingIntent.FLAG_IMMUTABLE标志。如果您的应用尝试在PendingIntent未设置任何可变性标志的情况下创建对象，则系统会抛出 IllegalArgumentException，并且Logcat中会显示以下消息：

PACKAGE_NAME: Targeting S+ (version 10000 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.

尽可能创建不可变的挂起Intent

在大多数情况下，您的应用应创建不可变的PendingIntent对象，如以下代码片段所示。如果PendingIntent对象是不可变的，则应用程序无法修改Intent以调整调用Intent的结果。

PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(),
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE);

但是，某些应用程序需要创建可变PendingIntent对象，而不是：

• 一个通知中直接回复动作需要改变的剪辑数据PendingIntent是与答复相关联的对象。通常，您可以通过将FILL_IN_CLIP_DATA标记作为fillIn()方法传递给方法来 请求此更改。
• 如果您的应用 使用a将对话放入bubble 中PendingIntent，则Intent应该是可变的，以便系统可以应用正确的标志，例如 FLAG_ACTIVITY_MULTIPLE_TASK 和 FLAG_ACTIVITY_NEW_DOCUMENT。

如果您的应用创建了可变PendingIntent对象，则强烈建议您使用明确的 intent 并填写 ComponentName。这样，每当另一个应用程序调用PendingIntent并将控制权传递回您的应用程序时，该应用程序中的同一组件始终会启动。

测试未决的Intent可变性更改

要确定您的应用是否缺少可变性声明，请在Android Studio中查找以下lint warning ：

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

在开发人员预览期间，您可以通过关闭PENDING_INTENT_EXPLICIT_MUTABILITY_REQUIRED 应用程序兼容性标志来禁用此系统行为以进行测试

不安全地启动嵌套Intent

为了提高平台安全性，Android 12提供了调试功能，可在您的应用执行不安全的嵌套intent启动时向您发出警告 。一个嵌套的intent是在另一个inten额外传递了一个inten。如果您的应用程序执行以下两个操作，则会发生StrictMode违例。

1. 您的应用程序从交付的inten的额外内容中取消了一个嵌套的Intent。
2. 你的应用程序将立即开始一个应用程序组件使用嵌套的inten，如使Intent进入 startActivity()， startService()或 bindService()。

配置您的应用程序以检测不安全的嵌套inten启动

要检查应用程序中嵌套Intent的不安全启动，请detectUnsafeIntentLaunch() 在配置时调用 VmPolicy，如以下代码片段所示。如果您的应用程序检测到违反StrictMode的行为，则可能要停止执行应用程序以保护潜在的敏感信息。

注意：如果您的应用定位到Android 12并 detectAll() 在其VmPolicy定义中使用，则该detectUnsafeIntentLaunch()方法会自动调用。

protected void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build());
}

更负责任地使用Intent

您的应用程序可能会启动嵌套的Intent，以在应用程序内部的组件之间导航，或代表另一个应用程序执行操作。为了最大程度地减少在两种情况下遇到StrictMode违规的机会，请执行以下操作：

• 嵌套Intent的内部启动：确保未导出这些组件。
• 跨应用程序启动嵌套Intent：使用a PendingIntent代替嵌套Intent。这样，当PendingIntent从其包含的内容中取消打包时 Intent，应用程序组件可以PendingIntent使用调用进程的身份来启动。此配置允许提供程序应用程序将回调发送到调用应用程序的任何组件，包括未导出的组件。 有关如何识别这种情况以及对应用程序进行更改的更多详细信息，请阅读 有关中型Android嵌套Intent的博客文章。

表现

前台服务启动限制

除少数特殊情况外，以Android 12为目标的应用程序无法在后台运行时启动前台服务。如果应用程序在后台运行时尝试启动前台服务，则会发生异常（少数特殊情况除外）。考虑在您的应用程序在后台运行时使用 WorkManager安排和开始工作。

要了解有关您的应用如何受到影响以及如何基于这些更改来更新应用的更多信息，请阅读有关前台服务启动限制的指南。您还可以浏览 GitHub上的 WorkManagerSample。

无法从服务或广播接收者创建Notification trampolines

当用户与通知交互时 ，某些应用程序会通过启动应用程序组件来响应通知点击，该组件最终会启动用户最终看到并与之交互的活动。这个应用程序组件被称为notification trampoline。

为了提高应用程序性能和用户体验，面向Android 12的应用程序无法从用作通知蹦床的服务或 广播接收器启动活动 。换句话说，在用户点击通知或通知中的action button，您的应用无法startActivity() 在服务或广播接收器内部进行调用 。

当您的应用尝试从充当通知蹦床的服务或广播接收器启动活动时，系统会阻止该活动启动，并且Logcat中会显示以下消息 ：

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

更新您的应用

如果您的应用从充当通知蹦床的服务或广播接收器启动活动，请完成以下迁移步骤：

1. 创建PendingIntent与以下活动之一关联的对象：
   • 用户点击通知后看到的活动（首选）。
   • 蹦床活动或启动用户点击通知后看到的活动的活动。
2. 使用PendingIntent在上一步中创建的对象作为构建通知的一部分。

切换行为

在开发人员预览版中测试应用程序时，可以使用NOTIFICATION_TRAMPOLINE_BLOCK应用程序兼容性标志启用和禁用此限制。

非SDK接口限制

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

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

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

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

自定义通知更改

Android 12会更改完全自定义通知的外观和行为。以前，自定义通知能够使用整个通知区域并提供自己的布局和样式。这导致了反模式，可能会使用户感到困惑或在不同设备上引起布局兼容性问题。

对于定位到Android 12的应用，带有自定义内容视图的通知将不再使用完整的通知区域；而是，系统应用标准模板。此模板可确保自定义通知在所有状态下都与其他通知具有相同的修饰，例如通知的图标和扩展功能（处于折叠状态）以及通知的图标，应用程序名称和折叠功能（处于扩展状态）。此行为与的行为几乎相同 Notification.DecoratedCustomViewStyle。

通过这种方式，Android 12使所有通知在视觉上保持一致并易于扫描，并为用户提供了可发现的熟悉的通知扩展。

下图显示了标准模板中的自定义通知：

以下示例显示了自定义通知如何以折叠状态和展开状态呈现：

Android中12中的变化影响定义的定制子类的应用程序 Notification.Style，或使用 Notification.Builder的方法 setCustomContentView(RemoteViews)， setCustomBigContentView(RemoteViews)和setCustomHeadsUpContentView(RemoteViews)。

如果您的应用使用的是完全自定义的通知，建议您尽快使用新模板进行测试。

1. 启用自定义通知更改：
   1. 改变你的应用程序的targetSdkVersion，以S使新的行为。
   2. 重新编译。
   3. 在运行Android 12的设备或模拟器上安装您的应用。
2. 测试所有使用自定义视图的通知，确保它们在阴影中看起来像您期望的那样。在测试时，请考虑以下因素并进行必要的调整：
   • 自定义视图的尺寸已更改。通常，自定义通知的高度要小于以前。在折叠状态下，自定义内容的最大高度已从106dp降低到48dp。同样，水平空间也更少。
   • 所有通知均可针对以Android 12为目标的应用进行扩展。通常，这意味着，如果您使用setCustomContentView，则还需要使用setBigCustomContentView 来确保折叠状态和展开状态一致。
   • 为了确保“抬头”状态看起来像您期望的那样，请不要忘记将通知通道的重要性提高到“高”（屏幕弹出）。

连接性

当针对Android 12及更高版本的设备在具有硬件支持的设备上运行时，在创建与对等设备的连接时，使用对等连接不会断开您现有的Wi-Fi连接。要检查是否支持此功能，请使用 WifiManager.isMultiStaConcurrencySupported()。

搭建Android12验证环境

设置一个Android模拟器

配置Android模拟器以运行Android 12是探索新功能和API以及测试Android 12行为更改的绝佳解决方案。设置仿真器既方便又快捷，可以让您仿真各种屏幕站点和设备特性。

您可以通过以下操作在Android Studio内部设置模拟器：

1. 安装最新的Android Studio预览版。
2. 在Android Studio中，点击工具> SDK管理器。
3. 在“ SDK工具”选项卡中，选择最新版本的Android Emulator，然后单击“确定”。如果尚未安装最新版本，此操作将安装最新版本。
4. 在Android Studio中，点击工具> AVD管理器，然后按照说明创建新的Android虚拟设备（AVD）。 确保选择Pixel 3、3a，4、4a或5设备定义和64位Android 12模拟器系统映像。请注意，Android 12不支持32位Android模拟器系统映像。如果尚未安装与设备定义匹配的Android 12系统映像，请单击“发行名称”旁边的“下载”以获取该映像。
5. 返回AVD Manager中的虚拟设备列表，然后双击您的Android 12虚拟设备以启动它。

Flash或手动安装系统映像

可供刷机的设备

Pixel 5, Pixel 4a, Pixel 4a (5G), Pixel 4, Pixel 3a, Pixel 3a XL, Pixel 3, and Pixel 3 XL

刷机方法

使用 Android Flash Tool 将映像刷新到设备上。

如果您希望手动刷新设备，则可以在Pixel下载页面上为设备获取Android 12系统映像。有关如何将系统映像刷新到设备的信息，请参见下载页面上的一般说明。当您需要对测试进行更多控制时，例如对于自动化测试或回归测试，此方法很有用。

参考文章

https://developer.android.google.cn/about/versions/12/behavior-changes-all#close-system-dialogs https://developer.android.google.cn/about/versions/12/behavior-changes-12