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 上的應用程式品質。

無論是要查看、篩選 Android Vitals 問題，還是從堆疊追蹤跳至程式碼，全都可透過「App Quality Insights」工具視窗完成。如要開始，請按照下列步驟操作：

  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 會按照名為電源軌的子系統區隔資料。如需支援的子系統清單，請參閱「可分析的電源軌」。

系統追蹤記錄會記載並顯示耗電量資料，此為 CPU 分析器功能的一環。這項資料會透過圖表，說明裝置耗電量與應用程式內操作的關聯。電源分析器能夠以圖表的方式呈現這項資料。

新版電源分析器

如要查看新版電源分析器中的資料，請使用 Pixel 6 後續裝置取得系統追蹤：

  1. 依序選取「View」>「Tool Windows」>「Profiler」。
  2. 按一下 CPU 時間軸中的任一處，即可開啟 CPU 分析器並啟動系統追蹤。

新版應用程式連結小幫手提供總覽，可讓您全面瞭解應用程式中設定的深層連結。小幫手會顯示應用程式 AndroidManifest.xml 檔案中所有現有的深層連結、驗證這些深層連結的設定是否正確，並支援快速自動修正錯誤設定。

如要開啟應用程式連結小幫手，請在 Android Studio 中依序點選「Tools」>「App Links Assistant」。如要進一步瞭解應用程式連結，請參閱「新增 Android 應用程式連結」。

即時編輯功能適用的更新版手動模式快速鍵

在 Android Studio Hedgehog 中，即時編輯功能加入了適用於手動模式 (手動推送) 的快速鍵：Control + \ 鍵 (macOS 則為 Command + \ 鍵)。如果您想精確控制何時應將更新部署到執行中的應用程式，手動模式就能派上用場。舉例來說，假設您要對檔案進行大規模變更，且不希望裝置顯示任何中繼狀態，可以前往「即時編輯」設定選擇「Push Manually」或「Push Manually on Save」，或是使用即時編輯 UI 指標。詳情請觀看 Live Edit for Jetpack Compose (Jetpack Compose 即時編輯功能) 的短片。

Compose Multipreview 範本

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ 導入了全新的 Multipreview API 範本：@PreviewScreenSizes、@PreviewFontScales、@PreviewLightDark，以及 @PreviewDynamicColors，因此您只要使用單一註解，即可在常見情境中預覽 Compose UI。

在 Android Studio Hedgehog 中，Compose 預覽功能推出了全新的 Gallery 模式，可讓您一次專心瀏覽一個預覽畫面，節省轉譯資源。如果您需要在應用程式 UI 上疊代，建議您使用 Gallery 模式；當需要查看 UI 變化版本時，請切換至其他模式 (例如格狀或清單檢視)。

偵錯工具的 Compose 狀態資訊

如果 Compose UI 的某些部分意外重組，有時可能難以瞭解原因。現在，在可組合函式上設定中斷點時，偵錯工具會列出可組合函式的參數及其狀態，方便您更輕鬆找出可能導致重組的異動。舉例來說，當您在可組合函式上暫停時，偵錯工具可以明確顯示哪些參數「已變更」或依然「未變更」，以利您更有效地調查重組原因。

裝置鏡像功能

您現在可以在 Android Studio 的「Running Devices」視窗中，為實體裝置建立鏡像。只要將裝置的畫面直接串流至 Android Studio，即可直接利用 Studio IDE 本身執行常用操作，例如啟動應用程式並與其互動、旋轉螢幕、折疊及展開手機、調整音量等等。

每當有裝置連線至已啟用 USB/無線偵錯功能的電腦，就一律可以使用裝置鏡像功能。如要啟動及停止鏡像作業，請開啟「Running Devices」視窗或「Device Manager」 (依序點選「View」>「Tool Windows」>「Device Manager」)。您也可以在設定 (依序點選「Settings」>「Tools」>「Device Mirroring」) 中自訂啟用裝置鏡像的時機。

「Running Devices」UI

已知問題

部分裝置在編碼時，位元率可能不足以支援裝置鏡像功能。在這些情況下，您可能會在「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」中的裝置下拉式選單

內嵌版面配置檢查器

自 Android Studio Hedgehog Canary 2 起，您可以直接在「Running Devices」工具視窗中執行版面配置檢查器。這項實驗功能除了節省畫面空間，還可將 UI 偵錯工作流程整理在單一工具視窗中。在內嵌模式下，您可以顯示檢視區塊階層、檢查每個檢視區塊的屬性，以及存取其他常見的版面配置檢查器功能。如要存取完整的選項，您仍需在獨立視窗中執行版面配置檢查器 (在 Windows 為依序點選「File」>「Settings」>「Experimental」>「Layout Inspector」；在 macOS 為依序點選「Android Studio」>「Settings」>「Experimental」>「Layout Inspector」)。

提醒您，內嵌版面配置檢查器有一項限制，那就是 3D 模式只能在快照中使用。

歡迎提供寶貴意見，協助我們強化內嵌版面配置檢查器。

經強化的新版 UI

Android Studio 的新版 UI 為 Studio IDE 帶來更現代、更簡潔的外觀和風格。我們聽取大家目前為止提供的意見，修正了與 Android Studio Hedgehog 中以下功能相關的問題：

  • 精簡模式
  • 支援垂直或水平分割
  • macOS 適用的專案分頁
  • 修正「無干擾模式」問題
  • 用於隨顯工具視窗動作的進階設定

SDK 升級工具更新

SDK 升級工具提供逐步設定精靈流程，可協助您升級 targetSdkVersion。以下是 Android Studio Hedgehog 中 SDK 升級工具的更新內容：

  • 說明升級至 Android 14 的破壞性變更
  • 新增了關聯性篩選器，移除部分不必要的步驟
  • 針對某些變更，精確指出程式碼中需要變更的位置

僅針對目標 API 級別停用建構最佳化功能

您現在可以針對目標裝置 API 級別停用 IDE 最佳化功能。根據預設，Android Studio 會找出您要部署的目標裝置並按其 API 級別自訂 DEX 處理程序，藉此縮短整體建構時間。如要關閉這項功能，請依序點選「File」>「Settings」>「Experimental」(在 macOS 上則請依序點選「Android Studio」>「Settings」>「Experimental」，然後取消勾選「Optimize build for target device API level only」。請注意，關閉這項建構最佳化功能後，建構時間可能會增加。

[僅限 Windows] 將防毒軟體對建構速度的影響降至最低

如果防毒軟體可能會影響版本效能，版本分析器會通知您。舉例來說，當防毒軟體 (例如 Windows Defender) 對 Gradle 使用的目錄執行即時掃描時，就可能發生這種情況。版本分析器會建議要從主動掃描作業中排除的目錄清單，如果可以，也會提供連結讓您將目錄新增至 Windows Defender 的資料夾排除清單。

不再支援 Eclipse Android 開發工具專案

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。

  2. 如要安裝 Google Cloud CLI，請按照「安裝 gcloud CLI」中的步驟操作。
  3. 設定本機環境。
    1. 在 gcloud 中連結至 Firebase 專案：
        gcloud config set project FIREBASE_PROJECT_ID

    2. 授權使用您的使用者憑證存取 API。建議您在模組層級建構指令碼中使用 DSL，將服務帳戶 JSON 檔案傳遞至 Gradle 以進行授權：

      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

  4. 啟用必要的 API。

    請前往 Google Developers Console API 程式庫頁面，在控制台頂端的搜尋框中輸入這些 API 名稱，然後在總覽頁面中按一下各個 API 的「啟用 API」，啟用 Cloud Testing API 和 Cloud Tool Results 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 是要測試的應用程式建構變化版本。請注意，Gradle 不會同時執行測試，也無法支援 Test Lab 裝置的其他 Google Cloud CLI 設定。

    Windows：

    gradlew device-nameBuildVariantAndroidTest

    Linux 或 macOS：

    ./gradlew device-nameBuildVariantAndroidTest

    測試輸出內容會包含測試報告的 HTML 檔案路徑。您也可以在 IDE 中依序點選「Run」>「Test History」，將測試結果匯入 Android Studio 以便深入分析。

    在裝置群組上建立及執行測試

    如要擴大測試範圍，請將多個 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 的 0.0.1-alpha05 版 Gradle 外掛程式，才能使用智慧型資料分割。

    如要啟用智慧型資料分割，請指定每個資料分割中測試所需的時間。您應將目標資料分割的時間長度設為至少比 timeoutMinutes 少五分鐘，以免資料分割作業在測試完成前遭到取消。

    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
    }
  }
}