Android Studio Hedgehog | 2023.1.1 (Tháng 11/2023)

Sau đây là các tính năng mới trong Android Studio Hedgehog.

Bản cập nhật nền tảng IntelliJ IDEA 2023.1

Android Studio Hedgehog có các bản cập nhật IntelliJ IDEA 2023.1, giúp cải thiện trải nghiệm IDE Studio. Để biết thông tin chi tiết về những thay đổi này, hãy xem ghi chú phát hành IntelliJ IDEA 2023.1.

Phân tích Android vitals trong App Quality Insights (Thông tin chi tiết về chất lượng ứng dụng)

App Quality Insights hiện bao gồm dữ liệu Android vitals để bạn có thể dễ dàng truy cập vào các chỉ số chính do Google Play thu thập và cải thiện trải nghiệm người dùng. Hãy dùng Android vitals để giải quyết các vấn đề liên quan đến độ ổn định của ứng dụng nhằm cải thiện chất lượng của ứng dụng trên Google Play.

Bạn có thể xem, lọc các vấn đề về Android vitals và chuyển từ dấu vết ngăn xếp sang mã hoá hoàn toàn trong cửa sổ công cụ App Quality Insights. Để bắt đầu, hãy làm theo các bước sau:

  1. Đăng nhập vào tài khoản nhà phát triển của bạn trong Android Studio bằng cách sử dụng biểu tượng hồ sơ ở cuối thanh công cụ.
  2. Mở App Quality Insights bằng cách nhấp vào cửa sổ công cụ trong Android Studio hoặc nhấp vào View > Tool Windows > App Quality Insights (Xem > Cửa sổ công cụ > Thông tin chi tiết về chất lượng ứng dụng).
  3. Nhấp vào thẻ Android vitals trong phần App Quality Insights.

Số liệu khác nhau giữa Android vitals và Crashlytics

Xin lưu ý rằng Android vitals và Crashlytics có thể báo cáo các giá trị khác nhau về số người dùng và sự kiện liên quan đến cùng một sự cố. Sự khác biệt này xảy ra vì Play và Crashlytics có thể phát hiện sự cố tại các thời điểm khác nhau và cho những người dùng khác nhau. Dưới đây là một vài lý do có thể dẫn đến sự khác biệt trong số liệu trên Play và Crashlytics:

  • Play phát hiện các sự cố xảy ra tại thời điểm khởi động, trong khi Crashlytics phát hiện các sự cố xảy ra sau khi SDK Crashlytics khởi động.
  • Nếu người dùng chọn không sử dụng tính năng báo cáo sự cố khi dùng điện thoại mới, thì các sự cố đó sẽ không được báo cáo cho Play. Tuy nhiên, Crashlytics phát hiện sự cố dựa trên chính sách quyền riêng tư của riêng ứng dụng.

Trình phân tích năng lượng mới

Kể từ Android Studio Hedgehog, Trình phân tích năng lượng sẽ hiển thị mức tiêu thụ năng lượng trên thiết bị. Bạn có thể xem dữ liệu mới này trong Trình theo dõi mức tiêu thụ năng lượng trên thiết bị (ODPM). ODPM phân đoạn dữ liệu theo các hệ thống phụ có tên là Đường dẫn năng lượng. Xem phần Đường dẫn năng lượng có thể phân tích để biết danh sách các hệ thống phụ được hỗ trợ.

Công cụ Theo dõi hệ thống ghi lại và hiển thị dữ liệu về mức tiêu thụ năng lượng. Đây là một phần của trình phân tích CPU. Dữ liệu này giúp bạn liên tưởng một cách trực quan mức tiêu thụ năng lượng của thiết bị với các hành động diễn ra trong ứng dụng. Trình phân tích năng lượng giúp bạn trực quan hoá dữ liệu này.

Trình phân tích năng lượng mới

Để xem dữ liệu của Trình phân tích năng lượng mới, hãy theo dõi hệ thống trên thiết bị Pixel 6 trở lên:

  1. Chọn View > Tool Windows > Profiler (Xem > Cửa sổ công cụ > Trình phân tích tài nguyên).
  2. Nhấp vào vị trí bất kỳ trong tiến trình CPU để mở Trình phân tích CPU và bắt đầu theo dõi hệ thống.

Trợ lý mới về đường liên kết trong ứng dụng cung cấp thông tin tổng quan toàn diện về các đường liên kết sâu được thiết lập trong ứng dụng của bạn. Trợ lý hiển thị tất cả các đường liên kết sâu hiện có trong tệp AndroidManifest.xml của ứng dụng, xác thực xem cấu hình của các đường liên kết sâu đó có chính xác hay không, đồng thời đưa ra một cách thức nhanh chóng để tự động khắc phục lỗi cấu hình sai.

Để mở Trợ lý về đường liên kết trong ứng dụng, hãy chuyển đến Tools > App Links Assistant (Công cụ > Trợ lý về đường liên kết trong ứng dụng) trong Android Studio. Để biết thêm thông tin về đường liên kết trong ứng dụng, hãy xem bài viết Thêm Đường liên kết trong ứng dụng Android.

Phím tắt đã cập nhật cho chế độ thủ công của tính năng Chỉnh sửa trực tiếp

Tính năng Chỉnh sửa trực tiếp trong Android Studio Hedgehog bao gồm một phím tắt mới cho chế độ thủ công (Đẩy thủ công):Control+\ (Command+\ cho macOS). Chế độ thủ công sẽ hữu ích trong những trường hợp bạn muốn có quyền kiểm soát chính xác đối với thời điểm triển khai bản cập nhật cho ứng dụng đang chạy. Ví dụ: nếu bạn đang thực hiện thay đổi trong một tệp trên quy mô lớn và không muốn bất kỳ trạng thái trung gian nào được phản ánh trên thiết bị. Bạn có thể chọn giữa chế độ Push Manually (Đẩy thủ công) và Push Manually on Save (Đẩy thủ công khi lưu) trong phần cài đặt của tính năng Chỉnh sửa trực tiếp hoặc sử dụng chỉ báo Giao diện người dùng của tính năng này. Để biết thêm thông tin, hãy xem đoạn video về tính năng Chỉnh sửa trực tiếp dành cho Jetpack Compose.

Các mẫu Multipreview trong Compose

androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+ giới thiệu các mẫu Multipreview API (API nhiều bản xem trước) mới: @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark@PreviewDynamicColors, để với một chú thích, bạn có thể xem trước Giao diện người dùng Compose trong các tình huống thường gặp.

Trong Android Studio Hedgehog, một chế độ Thư viện mới đã được đưa vào tính năng Xem trước trong Compose. Nhờ đó, mỗi lần bạn có thể tập trung vào một bản xem trước và tiết kiệm tài nguyên khi kết xuất hình ảnh. Bạn nên sử dụng Chế độ thư viện khi cần lặp lại giao diện người dùng của ứng dụng và chuyển sang các chế độ khác, chẳng hạn như Lưới hoặc Danh sách, cũng như khi cần xem các biến thể giao diện người dùng.

Thông tin về trạng thái Compose trong trình gỡ lỗi

Trong trường hợp các phần trên giao diện người dùng Compose được kết hợp lại đột ngột, đôi khi bạn khó biết được lý do. Giờ đây, khi đặt điểm ngắt trong hàm có khả năng kết hợp, trình gỡ lỗi sẽ liệt kê các tham số của thành phần kết hợp và trạng thái của chúng. Nhờ vậy, bạn có thể dễ dàng xác định những thay đổi có thể đã dẫn đến việc kết hợp lại đó. Ví dụ: khi bạn tạm dừng một thành phần kết hợp, trình gỡ lỗi có thể cho bạn biết chính xác tham số nào có trạng thái "Changed" (Đã thay đổi) hoặc vẫn ở trạng thái "Unchanged" (Không thay đổi), nhờ đó mà bạn có thể điều tra nguyên nhân dẫn đến việc kết hợp lại một cách hiệu quả hơn.

Phản chiếu thiết bị

Giờ đây, bạn có thể phản chiếu thiết bị thực trong cửa sổ Running Devices (Thiết bị đang chạy) trong Android Studio. Bằng cách truyền trực tuyến màn hình của thiết bị thẳng tới Android Studio, bạn có thể thực hiện các thao tác phổ biến như khởi động ứng dụng và tương tác với ứng dụng, xoay màn hình, gập và mở điện thoại, thay đổi âm lượng, cũng như nhiều thao tác khác ngay từ chính IDE Studio.

Bạn luôn dùng được tính năng phản chiếu thiết bị khi có các thiết bị được kết nối với máy tính đã bật tính năng gỡ lỗi qua Wi-Fi hoặc USB. Bạn có thể bắt đầu và dừng tính năng phản chiếu bằng cách sử dụng cửa sổ Running Devices (Thiết bị đang chạy) hoặc Device Manager (Trình quản lý thiết bị) (View > Tool Windows > Device Manager (Xem > Cửa sổ công cụ > Trình quản lý thiết bị)). Bạn cũng có thể tuỳ chỉnh thời điểm kích hoạt tính năng phản chiếu thiết bị trong phần cài đặt (Settings > Tools > Device Mirroring (Cài đặt > Công cụ > Phản chiếu thiết bị)).

Giao diện người dùng của thiết bị đang chạy

Vấn đề đã biết

Một số thiết bị có thể không mã hoá được ở tốc độ bit đủ để hỗ trợ tính năng phản chiếu thiết bị. Trong những trường hợp này, bạn có thể thấy lỗi tương tự như sau trong cửa sổ Running Devices (Thiết bị đang chạy) cũng như các nhật ký.

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

Thông báo về quyền riêng tư

Tuỳ vào chế độ cài đặt tính năng phản chiếu thiết bị, Android Studio có thể tự động bắt đầu tính năng phản chiếu thiết bị đối với mọi thiết bị đã kết nối và ghép nối. Điều này có thể dẫn đến việc tiết lộ thông tin cho các thiết bị được kết nối bằng lệnh adb tcpip vì thông tin và lệnh phản chiếu được truyền qua một kênh không được mã hoá. Ngoài ra, Android Studio sử dụng một kênh không mã hoá để giao tiếp với máy chủ adb. Do đó, những người dùng khác có thể chặn thông tin phản chiếu trên máy chủ của bạn.

Chuyển tiếp thiết bị đầu vào phần cứng

Giờ đây, bạn có thể bật tính năng chuyển tiếp minh bạch các thiết bị đầu vào phần cứng trên máy trạm (chẳng hạn như chuột và bàn phím) đến thiết bị thực và thiết bị ảo đã kết nối. Để bật tính năng chuyển tiếp minh bạch, hãy nhấp vào biểu tượng Thiết bị đầu vào phần cứng của thiết bị mục tiêu trong cửa sổ Running Devices (Thiết bị đang chạy).

Quản lý thiết bị ngay trong cửa sổ Thiết bị đang chạy

Giờ đây, bạn có thể khởi động một Thiết bị Android ảo (AVD) hoặc bắt đầu phản chiếu một thiết bị thực, ngay trong cửa sổ Running Devices (Thiết bị đang chạy) bằng cách nhấp vào biểu tượng + rồi chọn một thiết bị. Để dừng AVD hoặc dừng phản chiếu một thiết bị thực, hãy đóng thẻ Device (Thiết bị).

Trình đơn thả xuống thiết bị trong phần Running Devices (Thiết bị đang chạy)

Layout Inspector nhúng

Kể từ Android Studio Hedgehog Canary 2, bạn có thể chạy Layout Inspector ngay trong cửa sổ công cụ Running Devices (Thiết bị đang chạy). Tính năng thử nghiệm này bảo toàn không gian màn hình và giúp sắp xếp quy trình gỡ lỗi giao diện người dùng trong một cửa sổ công cụ. Ở chế độ nhúng, bạn có thể cho hiện một hệ phân cấp khung hiển thị, kiểm tra thuộc tính của từng khung hiển thị và truy cập vào các tính năng thường dùng khác của Layout Inspector. Để sử dụng tập hợp đầy đủ các tuỳ chọn, bạn vẫn cần phải chạy Layout Inspector trong một cửa sổ độc lập (File > Settings > Experimental > Layout Inspector (Tệp > Cài đặt > Thử nghiệm > Layout Inspector) trên Windows hoặc Android Studio > Settings > Experimental > Layout Inspector (Android Studio > Cài đặt > Thử nghiệm > Layout Inspector) trên macOS).

Một hạn chế của Layout Inspector nhúng là chế độ 3D chỉ có trong các snapshot (ảnh chụp nhanh).

Vui lòng gửi cho chúng tôi ý kiến phản hồi để giúp chúng tôi cải thiện Layout Inspector nhúng.

Các điểm cải tiến trong giao diện người dùng mới

Giao diện người dùng mới của Android Studio mang đến một giao diện hiện đại hơn, rõ ràng hơn cho IDE Studio. Cho đến nay, chúng tôi đã lắng nghe ý kiến phản hồi của bạn và đã khắc phục các vấn đề liên quan đến các tính năng sau trong Android Studio Hedgehog:

  • Chế độ thu gọn
  • Hỗ trợ chia tách theo chiều dọc hoặc chiều ngang
  • Các thẻ Project (Dự án) cho macOS
  • Sửa lỗi cho chế độ không gây mất tập trung
  • Chế độ cài đặt nâng cao để luôn hiện các thao tác trên cửa sổ công cụ

Các điểm mới của Trợ lý nâng cấp SDK

Trợ lý nâng cấp SDK cung cấp quy trình hướng dẫn từng bước để giúp bạn nâng cấp targetSdkVersion. Dưới đây là các điểm mới của Trợ lý nâng cấp SDK trong Android Studio Hedgehog:

  • Xem những thay đổi có thể gây lỗi khi nâng cấp lên Android 14
  • Thêm bộ lọc mức độ liên quan để loại bỏ một số bước không cần thiết
  • Đối với một số thay đổi, xác định chính xác vị trí cần thực hiện thay đổi trong mã

Chỉ tắt tính năng tối ưu hoá bản dựng cho cấp độ API mục tiêu

Giờ đây, bạn có thể tắt tính năng tối ưu hoá IDE cho cấp độ API của thiết bị mục tiêu. Theo mặc định, Android Studio giúp giảm tổng thời gian xây dựng bằng cách điều chỉnh quy trình tạo tệp dex cho cấp độ API của thiết bị mục tiêu mà bạn đang triển khai. Để tắt tính năng này, hãy chuyển đến File > Settings > Experimental (Tệp > Cài đặt > Thử nghiệm) (Android Studio > Settings > Experimental (Android Studio > Cài đặt > Thử nghiệm) trên macOS) và bỏ chọn Optimize build for target device API level only (Chỉ tối ưu hoá bản dựng cho cấp API của thiết bị mục tiêu). Xin lưu ý rằng việc tắt tính năng tối ưu hoá bản dựng này có thể làm tăng thời gian xây dựng.

[Chỉ dành cho Windows] Giảm thiểu tác động của phần mềm diệt virus đến tốc độ bản dựng

Trình phân tích bản dựng sẽ cho bạn biết liệu phần mềm diệt virus có thể ảnh hưởng đến hiệu suất của bản dựng hay không. Điều này có thể xảy ra nếu phần mềm diệt virus (chẳng hạn như Windows Defender) đang quét các thư mục mà Gradle sử dụng theo thời gian thực. Trình phân tích bản dựng đề xuất một danh sách các thư mục mà bạn nên loại trừ khỏi quá trình quét đang hoạt động. Nếu có thể, công cụ này sẽ cung cấp một đường liên kết để thêm các thư mục đó vào danh sách loại trừ thư mục của Windows Defender.

Các dự án Android Development Tool (ADT) của Eclipse không còn được hỗ trợ nữa

Các phiên bản từ Android Studio Hedgehog trở lên không hỗ trợ nhập các dự án ADT của Eclipse. Bạn vẫn có thể mở các dự án này nhưng hệ thống không còn nhận dạng được các dự án này là dự án Android. Nếu cần nhập loại dự án này, bạn có thể sử dụng phiên bản Android Studio cũ. Nếu một phiên bản Android Studio cụ thể không thể nhập dự án của bạn, thì bạn có thể thử với một phiên bản cũ hơn. Sau khi dự án được chuyển thành một dự án Android bằng phiên bản Android Studio cũ hơn, bạn có thể sử dụng Trợ lý nâng cấp AGP để thao tác trên dự án đó bằng phiên bản Android Studio mới nhất.

Sử dụng các thiết bị trong Phòng thử nghiệm Firebase bằng thiết bị do Gradle quản lý

Khi sử dụng AGP 8.2.0-alpha03 trở lên, bạn có thể chạy các kiểm thử đo lường tự động ở quy mô lớn trên các thiết bị trong Phòng thử nghiệm Firebase khi dùng các thiết bị do Gradle quản lý. Phòng thử nghiệm cho phép bạn chạy đồng thời các quá trình kiểm thử trên nhiều loại thiết bị Android, cả thiết bị thực và ảo. Các quá trình kiểm thử này chạy trong các trung tâm dữ liệu từ xa của Google. Với sự hỗ trợ của các thiết bị do Gradle quản lý (GMD), giờ đây, hệ thống xây dựng có thể quản lý hoàn toàn các quá trình kiểm thử chạy trên các thiết bị trong Phòng thử nghiệm này dựa trên cấu hình trong các tệp Gradle của dự án.

Làm quen với các thiết bị trong Phòng thử nghiệm Firebase do Gradle quản lý

Các bước sau đây mô tả cách bắt đầu sử dụng các thiết bị trong Phòng thử nghiệm Firebase bằng GMD. Xin lưu ý rằng các bước này sử dụng Giao diện dòng lệnh (CLI) của gcloud để cung cấp thông tin đăng nhập của người dùng. Thông tin đăng nhập này có thể không sử dụng được trong một số môi trường phát triển. Để biết thêm thông tin về quy trình xác thực cần sử dụng cho nhu cầu của bạn, hãy xem phần Cách hoạt động của Thông tin xác thực mặc định của ứng dụng.

  1. Để tạo một dự án Firebase, hãy chuyển đến bảng điều khiển của Firebase. Nhấp vàoAdd project (Thêm dự án) rồi làm theo lời nhắc trên màn hình để tạo một dự án. Ghi nhớ mã dự án của bạn.

  2. Để cài đặt Google Cloud CLI, hãy làm theo các bước trong phần Cài đặt gcloud CLI.
  3. Định cấu hình môi trường cục bộ.
    1. Liên kết đến dự án Firebase của bạn trong gcloud:
        gcloud config set project FIREBASE_PROJECT_ID
        
    2. Cho phép sử dụng thông tin đăng nhập của người dùng để có quyền truy cập API. Bạn nên uỷ quyền bằng cách truyền tệp JSON của tài khoản dịch vụ cho Gradle bằng cách sử dụng DSL trong tập lệnh bản dựng cấp mô-đun:

      Kotlin

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

      Groovy

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

      Ngoài ra, bạn có thể cấp quyền theo cách thủ công bằng cách sử dụng cửa sổ dòng lệnh sau :

        gcloud auth application-default login
        
    3. Không bắt buộc: Thêm dự án Firebase ở dạng dự án hạn mức. Bước này là chỉ cần thiết nếu bạn vượt quá hạn mức không mất phí cho Phòng thử nghiệm.

        gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
        
  4. Bật các API bắt buộc.

    Trong trang Thư viện API Google Developers Console, bật Cloud Testing APIAPI Kết quả của Cloud Tool bằng cách nhập các tên API này vào hộp tìm kiếm ở đầu bảng điều khiển và sau đó nhấp vào Bật API trên trang tổng quan cho từng API.

  5. Định cấu hình dự án Android của bạn.

    1. Thêm trình bổ trợ Phòng thử nghiệm Firebase vào tập lệnh bản dựng cấp cao nhất:

      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. Bật các loại thiết bị tuỳ chỉnh trong tệp gradle.properties:

        android.experimental.testOptions.managedDevices.customDevice=true
        
    3. Thêm trình bổ trợ Phòng thử nghiệm Firebase vào tập lệnh bản dựng cấp mô-đun:

      Kotlin

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

      Groovy

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

    Tạo và chạy kiểm thử trên thiết bị trong Phòng thử nghiệm Firebase do Gradle quản lý

    Bạn có thể chỉ định một thiết bị cho Phòng thử nghiệm Firebase để Gradle sử dụng cho việc kiểm thử ứng dụng của bạn trong tập lệnh bản dựng cấp mô-đun. Mã mẫu sau đây sẽ tạo một Pixel 3 chạy API cấp 30 ở dạng một thiết bị trong Phòng thử nghiệm do Gradle quản lý có tên là ftlDevice. Khối firebaseTestLab {} sẽ có sẵn khi bạn áp dụng trình bổ trợ com.google.firebase.testlab cho mô-đun của mình. Phiên bản tối thiểu được hỗ trợ của trình bổ trợ Android cho Gradle là 8.2.0-alpha01.

    Kotlin

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

    Groovy

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

    Để chạy kiểm thử bằng các thiết bị (mà bạn đã định cấu hình) trong Phòng thử nghiệm do Gradle quản lý, hãy dùng lệnh sau. device-name là tên của thiết bị mà bạn đã định cấu hình trong tập lệnh bản dựng Gradle (chẳng hạn như ftlDevice) và BuildVariant là biến thể bản dựng của ứng dụng mà bạn muốn kiểm thử. Xin lưu ý rằng Gradle không chạy kiểm thử song song hoặc hỗ trợ các cấu hình Google Cloud CLI khác cho các thiết bị trong Phòng thử nghiệm.

    Trên Windows:

    gradlew device-nameBuildVariantAndroidTest
    

    Trên Linux hoặc macOS:

    ./gradlew device-nameBuildVariantAndroidTest
    

    Kết quả kiểm thử bao gồm một đường dẫn đến tệp HTML có báo cáo kiểm thử. Bạn cũng có thể nhập kết quả kiểm thử vào Android Studio để phân tích thêm bằng cách nhấp vào Run > Test History (Chạy > Nhật ký kiểm thử) trong IDE.

    Tạo và chạy kiểm thử trên một nhóm thiết bị

    Để mở rộng quy mô kiểm thử, hãy thêm nhiều thiết bị trong Phòng thử nghiệm Firebase do Gradle quản lý vào một nhóm thiết bị, sau đó chạy kiểm thử trên tất cả các thiết bị đó bằng một lệnh duy nhất. Giả sử bạn đã thiết lập nhiều thiết bị như sau:

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

    Để thêm các thiết bị đó vào một nhóm thiết bị có tên là samsungGalaxy, hãy sử dụng khối 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"])
            }
          }
        }
      }
    }
    

    Để chạy kiểm thử trên tất cả các thiết bị trong nhóm thiết bị, hãy dùng lệnh sau:

    Trên Windows:

    gradlew group-nameGroupBuildVariantAndroidTest
    

    Trên Linux hoặc macOS:

    ./gradlew group-nameGroupBuildVariantAndroidTest
    

    Tối ưu hoá các lần chạy kiểm thử bằng tính năng phân đoạn thông minh

    Hoạt động kiểm thử trên các thiết bị trong Phòng thử nghiệm do Gradle quản lý hiện có hỗ trợ tính năng phân đoạn thông minh. Tính năng phân đoạn thông minh sẽ tự động phân phối các hoạt động kiểm thử của bạn trên các phân đoạn sao cho mỗi phân đoạn chạy thời gian gần tương tự nhau, giúp giảm công sức phân bổ thủ công và tổng thời gian chạy kiểm thử. Tính năng phân đoạn thông minh sử dụng nhật ký kiểm thử hoặc thông tin về khoảng thời gian chạy các chương trình kiểm thử trước, nhằm phân phối các chương trình kiểm thử theo cách tối ưu. Xin lưu ý rằng bạn cần có phiên bản 0.0.1-alpha05 của trình bổ trợ Gradle cho Phòng thử nghiệm Firebase để sử dụng tính năng phân đoạn thông minh.

    Để bật tính năng phân đoạn thông minh, hãy chỉ định lượng thời gian diễn ra hoạt động kiểm thử trong mỗi phân đoạn. Bạn nên đặt thời lượng phân đoạn mục tiêu sao cho ít hơn timeoutMinutes tối thiểu là 5 phút để tránh trường hợp phân đoạn bị huỷ trước khi quá trình kiểm thử có thể hoàn tất.

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

    Để tìm hiểu thêm, hãy đọc bài viết các tuỳ chọn DSL mới.

    Cập nhật DSL cho các thiết bị trong Phòng thử nghiệm Firebase do Gradle quản lý

    Bạn có thể định cấu hình các tuỳ chọn DSL khác để giúp tuỳ chỉnh quá trình chạy kiểm thử hoặc di chuyển các tuỳ chọn DSL từ những giải pháp khác mà có thể bạn đang sử dụng. Hãy xem một số tuỳ chọn trong số này như mô tả trong đoạn mã sau.

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