Android Studio Hedgehog | 2023.1.1（2023 年 11 月）

以下是 Android Studio Hedgehog 中的新功能。

IntelliJ IDEA 2023.1 平台更新

Android Studio Hedgehog 包含 IntelliJ IDEA 2023.1 更新，这些更新改进了 Studio IDE 体验。如需详细了解相关变更，请参阅 IntelliJ IDEA 2023.1 版本说明。

在 App Quality Insights 中分析 Android Vitals

App Quality Insights 现在包含 Android Vitals 数据，因此您可以更轻松地访问 Google Play 收集的核心指标并提升用户体验。您可以使用 Android Vitals 解决与应用稳定性相关的问题，以帮助提升应用在 Google Play 中展示的质量。

您可以在 App Quality Insights 工具窗口中集中查看 Android Vitals 问题、过滤问题，以及从堆栈轨迹跳转到代码。如要开始使用，请按以下步骤操作：

  1. 在 Android Studio 中，通过工具栏末尾的个人资料图标 登录您的开发者账号。
  2. 点击 Android Studio 中的工具窗口或依次点击 View > Tool Windows > App Quality Insights 以打开 App Quality Insights。
  3. 点击 App Quality Insights 中的 Android Vitals 标签页。

Android Vitals 和 Crashlytics 中的数据有所不同

请注意，Android Vitals 和 Crashlytics 可能会针对与同一崩溃问题关联的用户数和事件数报告不同的值。之所以出现这些差异，是因为 Play 和 Crashlytics 可以在不同的时间针对不同的用户捕获崩溃问题。以下是导致 Play 计数和 Crashlytics 计数出现差异的几个原因：

  • Play 在启动开始时捕获崩溃问题，而 Crashlytics 捕获 Crashlytics SDK 初始化后发生的崩溃问题。
  • 如果用户在使用新手机时选择停用崩溃报告，则系统不会向 Play 报告这些崩溃问题；不过，Crashlytics 会根据应用自己的隐私权政策捕获崩溃问题。

新的功耗性能分析器

从 Android Studio Hedgehog 开始，功耗性能分析器会显示设备上的功耗。您可以在设备端电源轨监视器 (ODPM) 中查看这些新数据。ODPM 按称为 Power Rails 的子系统细分数据。如需查看受支持的子系统列表，请参阅可分析电源轨。

System Trace 会记录并显示功耗数据。它是 CPU 性能分析器的一部分。这些数据有助于您直观地将设备的功耗与应用中发生的操作相关联。借助功耗性能分析器，您可以直观地了解这些数据。

新的功耗性能分析器

如需查看新的功耗性能分析器中的数据，请在 Pixel 6 及更高版本的设备上获取系统轨迹：

  1. 依次选择 View > Tool Windows > Profiler。
  2. 点击 CPU 时间轴上的任意位置以打开 CPU 性能分析器并启动系统轨迹。

新的 App Links Assistant 可提供对应用中设置的深层链接的全面概览。App Links Assistant 会显示应用的 AndroidManifest.xml 文件中的所有现有深层链接，验证这些深层链接的配置是否正确，并提供自动修正错误配置的快速方法。

如需打开 App Links Assistant，请在 Android Studio 中依次转到 Tools > App Links Assistant。如需详细了解应用链接，请参阅添加 Android App Links。

实时编辑功能已更新手动模式快捷键

Android Studio Hedgehog 中的实时编辑针对手动模式（手动推送）添加了一个新的快捷键：Control+\（在 macOS 上为 Command+\）。如果您希望精确控制何时将更新部署到正在运行的应用，手动模式非常有用。例如，如果您要对文件进行大规模更改，并且不希望在设备上出现任何中间状态。您可以在实时编辑设置中或通过实时编辑界面指示器选择 Push Manually 或 Push Manually on Save。如需了解详情，请参阅 Jetpack Compose 实时编辑中的视频剪辑。

Compose Multipreview 模板

androidx.compose.ui:ui-tooling-preview1.6.0-alpha01+ 引入了新的 Multipreview API 模板：@PreviewScreenSizes、@PreviewFontScales、@PreviewLightDark 和 @PreviewDynamicColors，这样一来，只需一个注解，您就可以在常见场景中预览 Compose 界面。

Android Studio Hedgehog 在 Compose Preview 中引入了一个新的 Gallery 模式，该模式可让您一次专注于一个预览，并节省渲染资源。如果您需要对应用的界面进行迭代和切换到其他模式（例如 Grid 或 List），以及需要查看界面变体，我们建议您使用 Gallery Mode。

调试程序中的 Compose 状态信息

如果 Compose 界面的某些部分意外重组，有时很难理解原因。现在，在可组合函数上设置断点时，调试程序列出了可组合项的参数及其状态，以便您更轻松地识别可能导致重组的更改。例如，当您暂停某个可组合项时，调试程序可以确切告知您哪些参数已“已更改”或哪些参数“未更改”，以便您更高效地调查重组的原因。

设备镜像

现在，您可以在 Android Studio 的 Running Devices 窗口中镜像实体设备。通过将设备的显示屏直接流式传输到 Android Studio，您可以直接在 Studio IDE 中执行常见操作，例如启动应用并与其交互、旋转屏幕、折叠和展开手机、更改音量等。

当有设备连接到启用了 USB 或无线调试的计算机时，设备镜像始终可用。您可以使用 Running Devices 窗口或 Device Manager (View > Tool Windows > Device Manager) 开始和停止镜像。您还可以在设置中自定义启用设备镜像的时间（依次点击 Settings > Tools > Device Mirroring）。

“Running Devices”界面

已知问题

某些设备可能无法以足够的比特率编码，因此无法支持设备镜像。在这些情况下，您可能会在 Running Devices 窗口中看到错误，以及类似于以下内容的日志。

2023-06-01 15:32:22,675 [  56094]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - Too many video encoder errors:
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - encoder: c2.android.vp8.encoder
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - mime type: video/x-vnd.on2.vp8
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max resolution: 640x640
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - min resolution: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - alignment: 2x2
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate: 960
2023-06-01 15:32:22,676 [  56095]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max frame rate for 288x640: 960
2023-06-01 15:32:22,870 [  56289]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - max bitrate: 20000000
2023-06-01 15:32:22,871 [  56290]   WARN - ScreenSharingAgent Samsung SM-A045F API 33 - terminated with code 1

隐私权声明

Android Studio 可以根据设备镜像设置，自动为任何已连接的配对设备启动设备镜像。这可能会导致通过 adb tcpip 命令连接的设备出现信息披露，因为镜像信息和命令是通过未加密通道传递的。此外，Android Studio 会使用未加密的通道与 adb 服务器通信，因此主机上的其他用户可能会拦截镜像信息。

硬件输入转发

您现在可以将工作站硬件输入（例如鼠标和键盘）透明转发到已连接的实体和虚拟设备。如需启用透明转发，请在 Running Devices 窗口中点击目标设备的 Hardware input 图标 。

直接从“Running Devices”窗口管理设备

您现在可以直接从 Running Devices 窗口中启动 Android 虚拟设备 (AVD) 或开始镜像实体设备，只需点击 + 图标并选择设备即可操作。如需停止 AVD 或停止镜像实体设备，请关闭设备标签页。

“Running Devices”中的“Device”下拉菜单

嵌入式布局检查器

从 Android Studio Hedgehog Canary 2 开始，您可以直接在 Running Devices 工具窗口中运行布局检查器。这项实验性功能可以节省屏幕空间，有助于在单个工具窗口中整理界面调试工作流。在嵌入式模式下，您可以显示视图层次结构、检查每个视图的属性，以及访问其他常用的布局检查器功能。如需访问所有选项，您仍然需要在独立窗口中运行布局检查器（在 Windows 中依次点击 File > Settings > Experimental > Layout Inspector 或在 macOS 中依次点击 Android Studio > Settings > Experimental > Layout Inspector）。

嵌入式布局检查器的一个限制是，3D 模式仅在快照中可用。

为帮助我们改进嵌入式布局检查器，请向我们发送反馈。

新界面改进

Android Studio 的新界面为该 Studio IDE 带来了更现代、更简洁的外观和风格。我们听取了到目前为止大家的反馈，并修复了与 Android Studio Hedgehog 中的以下功能相关的问题：

  • 紧凑模式
  • 支持垂直或水平拆分
  • 适用于 macOS 的项目标签页
  • 修复了无干扰模式
  • 用于始终显示工具窗口操作的高级设置

SDK 升级助理更新

SDK 升级助理提供了分步向导流程，可帮助您进行 targetSdkVersion 升级。以下是对 Android Studio Hedgehog 中的 SDK 升级助理的更新：

  • 了解升级到 Android 14 的重大变更
  • 添加了相关性过滤器，移除了一些不必要的步骤
  • 对于某些更改，精确指出需要在代码中进行更改的确切位置

仅针对目标 API 级别停用 build 优化

您现在可以针对目标设备 API 级别停用 IDE 优化。默认情况下，Android Studio 会针对要部署到的目标设备的 API 级别定制 dex 处理流程，从而缩短总体构建时间。要关闭此功能，请依次前往 File > Settings > Experimental（在 macOS 上，请依次前往 Android Studio > Settings > Experimental），然后取消选中 Optimize build for target device API level only。请注意，关闭此构建优化功能可能会增加构建时间。

[仅限 Windows] 最大限度地降低杀毒软件对构建速度的影响

Build Analyzer 会告知您杀毒软件是否可能会影响构建性能。如果杀毒软件（如 Windows Defender）对 Gradle 使用的目录进行实时扫描，就可能会产生影响。Build Analyzer 会推荐一个要从主动扫描中排除的目录列表，如果可能，还会提供一个链接，供您将这些目录添加到 Windows Defender 文件夹排除列表中。

不再支持 Eclipse Android Development Tool 项目

Android Studio Hedgehog 及更高版本不支持导入 Eclipse ADT 项目。您仍可以打开这些项目，但系统无法再将其识别为 Android 项目。如果您需要导入此类项目，可以使用较低版本的 Android Studio。如果给定版本的 Android Studio 无法导入您的项目，您可以尝试使用更低的版本。使用较低版本的 Android Studio 将项目转换为 Android 项目后，您可以使用 AGP 升级助理在最新版本的 Android Studio 中处理该项目。

将 Firebase Test Lab 设备与 Gradle 管理的设备搭配使用

使用 AGP 8.2.0-alpha03 或更高版本时，您可以在使用 Gradle 管理的设备的情况下，在 Firebase Test Lab 设备上大规模运行自动化插桩测试。利用 Test Lab，您可以在各种 Android 设备（包括实体设备和虚拟设备）上同时运行测试。这些测试在远程 Google 数据中心运行。得益于 Gradle 管理的设备 (GMD) 的支持，构建系统现在可以根据项目的 Gradle 文件中的配置，全面管理针对这些 Test Lab 设备运行的测试。

开始使用 Gradle 管理的 Firebase Test Lab 设备

以下步骤介绍了如何开始将 Firebase Test Lab 设备与 GMD 搭配使用。请注意，这些步骤使用 gcloud CLI 提供用户凭据，这些凭据可能不适用于所有开发环境。如需详细了解应根据您的需求使用哪种身份验证流程，请参阅应用默认凭据的工作原理。

  1. 如需创建 Firebase 项目，请前往 Firebase 控制台。点击添加项目，然后按照屏幕上的提示创建项目。记住项目 ID。

    <ph type="x-smartling-placeholder">
  2. 如需安装 Google Cloud CLI，请按照 安装 gcloud CLI。
  3. 配置本地环境。
    1. 在 gcloud 中关联到您的 Firebase 项目： 
        gcloud config set project FIREBASE_PROJECT_ID

    2. 授权使用您的用户凭据以访问 API。我们建议 通过传递 服务账号 JSON 文件上传到 Gradle 中（使用 模块级 build 脚本中的 DSL：

      Kotlin

        firebaseTestLab {
    ...
    serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE))
  }

      Groovy

        firebaseTestLab {
    ...
    serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE)
  }

      或者，您也可以使用以下终端手动授权 命令：

        gcloud auth application-default login

    3. 可选：将您的 Firebase 项目添加为配额项目。此步骤为 只有在超出 Test Lab 的免费配额。 

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
      <ph type="x-smartling-placeholder">

  4. 启用必需的 API。

    在 Google Developers Console“API 库”页面、 启用 Cloud Testing API 和 Cloud Tool Results API 在控制台顶部的搜索框中输入这些 API 名称 然后点击每个 API 的概览页面上的启用 API。

  5. 配置 Android 项目。

    1. 在顶级构建脚本中添加 Firebase Test Lab 插件：

      Kotlin

        plugins {
    ...
    id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
  }

      Groovy

        plugins {
    ...
    id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
  }

    2. 在 gradle.properties 文件中启用自定义设备类型：

        android.experimental.testOptions.managedDevices.customDevice=true

    3. 在模块级构建脚本中添加 Firebase Test Lab 插件：

      Kotlin

        plugins {
    ...
    id "com.google.firebase.testlab"
  }

      Groovy

        plugins {
    ...
    id 'com.google.firebase.testlab'
  }

    在 Gradle 管理的 Firebase Test Lab 设备上创建和运行测试

    您可以在模块级构建脚本中指定适用于 Gradle 的 Firebase Test Lab 设备，用于测试应用。以下代码示例将创建一个搭载 API 级别 30 的 Pixel 3，作为 Gradle 管理的 Test Lab 设备（称为 ftlDevice）。当您将 com.google.firebase.testlab 插件应用于模块时，firebaseTestLab {} 代码块将可用。支持的最低 Android Gradle 插件版本是 8.2.0-alpha01。

    Kotlin

    firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    Groovy

    firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

    如需使用您配置的 Gradle 管理的 Test Lab 设备运行测试，请使用以下命令。device-name 是您在 Gradle 构建脚本中配置的设备名称（例如 ftlDevice），BuildVariant 是要测试的应用 build 变体。请注意，Gradle 不会并行运行测试，也不会支持 Test Lab 设备的其他 Google Cloud CLI 配置。

    在 Windows 上：

    gradlew device-nameBuildVariantAndroidTest

    在 Linux 或 macOS 上：

    ./gradlew device-nameBuildVariantAndroidTest

    测试输出包括指向包含测试报告的 HTML 文件的路径。您还可以将测试结果导入 Android Studio 以供进一步分析，方法是在该 IDE 中依次点击 Run > Test History。

    创建设备组并运行测试

    如需扩大测试规模，请将多台 Gradle 管理的 Firebase Test Lab 设备添加到一个设备组，然后用单个命令在所有这些设备上运行测试。假设您按如下方式设置了多台设备：

    firebaseTestLab {
  managedDevices {
    create("GalaxyS23Ultra") { ... }
    create("GalaxyZFlip3") { ... }
    create("GalaxyZFold3") { ... }
    create("GalaxyTabS2") { ... }
  }
}

    如需将它们添加到名为 samsungGalaxy 的设备组，请使用 groups {} 代码块：

    firebaseTestLab {
  managedDevices {...}
}

android {
  ...
  testOptions {
    managedDevices {
      groups {
        create("samsungGalaxy") {
          targetDevices.add(devices["GalaxyS23Ultra"])
          targetDevices.add(devices["GalaxyZFlip3"])
          targetDevices.add(devices["GalaxyZFold3"])
          targetDevices.add(devices["GalaxyTabS3"])
        }
      }
    }
  }
}

    如需在设备组中的所有设备上运行测试，请使用以下命令：

    在 Windows 上：

    gradlew group-nameGroupBuildVariantAndroidTest

    在 Linux 或 macOS 上：

    ./gradlew group-nameGroupBuildVariantAndroidTest

    利用智能分片优化测试运行

    在 Gradle 管理的 Test Lab 设备上进行测试现在支持智能分片。智能分片可自动将测试分布到多个分片，使每个分片的运行时间大致相同，从而减少手动分配工作量并缩短总体测试运行时长。智能分片会使用您的测试历史记录或与之前运行测试所花时间有关的信息，以最佳方式分发测试。请注意，您需要安装适用于 Firebase Test Lab 的 Gradle 插件 0.0.1-alpha05 版本，才能使用智能分片。

    如需启用智能分片，请指定每个分片中测试应花费的时间。您应将目标分片时长设置为至少比 timeoutMinutes 少 5 分钟，以避免分片在测试完成之前被取消的情况。

    firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

    如需了解详情，请参阅新 DSL 选项。

    更新了适用于 Gradle 管理的 Firebase Test Lab 设备的 DSL

    您可以配置更多 DSL 选项，以帮助自定义测试运行，或者从您可能已经在使用的其他解决方案进行迁移。请参阅以下代码段中介绍的其中一些选项。

    firebaseTestLab {
  ...

  /**
   * A path to a JSON file that contains service account credentials to access to
   * a Firebase Test Lab project.
   */
  serviceAccountCredentials.set(file("your_service_account_credentials.json"))


  testOptions {
    fixture {
      /**
       * Whether to grant permissions on the device before tests begin.
       * Available options are "all" or "none".
       *
       * Default value is "all".
       */
      grantedPermissions = "all"

      /**
       * Map of files to push to the device before starting the test.
       *
       * The key is the location on the device.
       * The value is the location of the file, either local or in Google Cloud.
       */
      extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
      extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"

      /**
       * The name of the network traffic profile.
       *
       * Specifies network conditions to emulate when running tests.
       *
       * Default value is empty.
       */
      networkProfile = "LTE"
    }

    execution {
      /**
       * The maximum time to run the test execution before cancellation,
       * measured in minutes. Does not include the setup or teardown of device,
       * and is handled server-side.
       *
       * The maximum possible testing time is 45 minutes on physical devices
       * and 60 minutes on virtual devices.
       *
       * Defaults to 15 minutes.
       */
       timeoutMinutes = 30

      /**
       * Number of times the test should be rerun if tests fail.
       * The number of times a test execution should be retried if one
       * or more of its test cases fail.
       *
       * The max number of times is 10.
       *
       * The default number of times is 0.
       */
      maxTestReruns = 2

      /**
       * Ensures only a single attempt is made for each execution if
       * an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
       * Normally, two or more attempts are made by Firebase Test Lab if a
       * potential infrastructure issue is detected. This is best enabled for
       * latency sensitive workloads. The number of execution failures might be
       * significantly greater with `failFast` enabled.
       *
       * Defaults to false.
       */
      failFast = false

      /**
       * The number of shards to split the tests across.
       * 
       * Default to 0 for no sharding.
       */
      numUniformShards = 20

      /**
      * For smart sharding, the target length of time each shard should takes in
      * minutes. Maxes out at 50 shards for physical devices and 100 shards for
      * virtual devices.
      *
      * Only one of numUniformShards or targetedShardDurationMinutes can be set.
      *
      * Defaults to 0 for no smart sharding.
      */
      targetedShardDurationMinutes = 15
    }

    results {
      /**
       * The name of the Google storage bucket to store the test results in.
       *
       * If left unspecified, the default bucket is used.
       *
       * Please refer to Firebase Test Lab permissions for required permissions
       * for using the bucket.
       */
      cloudStorageBucket = "bucketLocationName"

      /**
       * Name of test results for the Firebase console history list.
       * All tests results with the same history name are grouped
       * together in the Firebase console in a time-ordered test history list.
       *
       * Defaults to the application label in the APK manifest in Flank/Fladle.
       */
      resultsHistoryName = "application-history"

      /**
       * List of paths to copy from the test device's storage to the test
       * results folder. These must be absolute paths under /sdcard or
       * /data/local/tmp.
       */
      directoriesToPull.addAll(
        "/sdcard/path/to/something"
      )

      /**
       * Whether to enable video recording during the test.
       *
       * Disabled by default.
       */
      recordVideo = false

      /**
       * Whether to enable performance metrics. If enabled, monitors and records
       * performance metrics such as CPU, memory, and network usage.
       *
       * Defaults to false.
       */
      performanceMetrics = true
    }
  }
}