다음은 Android 스튜디오 Hedgehog의 새로운 기능입니다.
IntelliJ IDEA 2023.1 플랫폼 업데이트
Android 스튜디오 Hedgehog에는 스튜디오 IDE 환경을 개선하는 IntelliJ IDEA 2023.1 업데이트가 포함되어 있습니다. 변경사항에 관한 자세한 내용은 IntelliJ IDEA 2023.1 출시 노트를 참고하세요.
App Quality Insights에서 Android vitals 분석
Google Play에서 수집한 핵심 측정항목에 더 쉽게 액세스하고 사용자 경험을 개선할 수 있도록 이제 App Quality Insights에 Android vitals 데이터가 포함됩니다. Android vitals를 사용하여 앱 안정성과 관련된 문제를 해결하면 Google Play에서 앱의 품질을 개선하는 데 도움이 됩니다.
App Quality Insights 도구 창에서 Android vitals 문제를 보고 이를 필터링하고 스택 트레이스에서 코드로 이동할 수 있습니다. 시작하려면 다음 단계를 따르세요.
- 툴바 끝에 있는 프로필 아이콘
을 사용하여 Android 스튜디오의 개발자 계정에 로그인합니다. - Android 스튜디오의 도구 창을 클릭하거나 View > Tool Windows > App Quality Insights를 클릭하여 App Quality Insights를 엽니다.
- App Quality Insights에서 Android vitals 탭을 클릭합니다.
Android vitals와 Crashlytics의 다른 수치
Android vitals와 Crashlytics는 동일한 비정상 종료와 관련된 사용자 및 이벤트 수 값을 다르게 보고할 수 있습니다. 이러한 불일치가 발생하는 이유는 Play와 Crashlytics가 서로 다른 시간에 서로 다른 사용자의 비정상 종료를 포착할 수 있기 때문입니다. 다음은 Play 수와 Crashlytics 수가 다를 수 있는 몇 가지 이유입니다.
- Play는 부팅 시 시작되는 비정상 종료를 포착하지만 Crashlytics는 Crashlytics SDK 초기화 후 발생하는 비정상 종료를 포착합니다.
- 사용자가 새 휴대전화를 구매할 때 비정상 종료 보고를 선택 해제하면 이러한 비정상 종료는 Play에 보고되지 않습니다. 하지만 Crashlytics는 앱의 자체 개인정보처리방침에 따라 비정상 종료를 포착합니다.
새로운 전원 프로파일러
Android 스튜디오 Hedgehog부터 전원 프로파일러에 기기의 전원 소모량이 표시됩니다. 이 새로운 데이터는 온디바이스 전원 레일 모니터(ODPM)에서 확인할 수 있습니다. ODPM은 전원 레일이라는 하위 시스템을 기준으로 데이터를 분류합니다. 지원되는 하위 시스템 목록은 프로파일링 가능한 전원 레일을 참고하세요.
시스템 트레이스는 전원 소모량 데이터를 기록하고 표시합니다. 전원 프로파일러는 CPU 프로파일러의 일부입니다. 이 데이터는 기기의 전원 소모량을 앱에서 발생하는 동작과 시각적으로 연관짓는 데 도움이 됩니다. 전원 프로파일러를 사용하면 이 데이터를 시각화할 수 있습니다.
새로운 전원 프로파일러의 데이터를 보려면 Pixel 6 이상 기기에서 시스템 트레이스를 사용하세요.
- View > Tool Windows > Profiler를 선택합니다.
- CPU 타임라인의 아무 곳이나 클릭하여 CPU 프로파일러를 열고 시스템 트레이스를 시작합니다.
새로운 App Links Assistant
새로운 App Links Assistant는 앱에 설정된 딥 링크에 관한 포괄적인 개요를 제공합니다. App Links Assistant는 앱의 AndroidManifest.xml 파일에 기존의 모든 딥 링크를 표시하고, 이러한 딥 링크의 구성이 올바른지 확인하고, 구성 오류를 자동으로 수정하는 빠른 방법을 제공합니다.
App Links Assistant를 열려면 Android 스튜디오에서 Tools > App Links Assistant로 이동합니다. 앱 링크에 관한 자세한 내용은 Android App Links 추가를 참고하세요.
실시간 편집이 수동 모드 단축키로 업데이트됨
Android 스튜디오 Hedgehog의 실시간 편집에 수동 모드를 위한 새로운 단축키(Push Manually)인 Control+\(macOS는 Command+\)가 포함되어 있습니다. 수동 모드는 실행 중인 애플리케이션에 업데이트가 배포되는 시점을 정밀하게 제어하려는 경우에 유용합니다. 예를 들어 파일을 대규모로 변경할 때 중간 상태가 기기에 반영되지 않도록 할 수 있습니다. 실시간 편집 설정에서 또는 실시간 편집 UI 표시기를 사용하여 Push Manually와 Push Manually on Save 중에서 선택할 수 있습니다. 자세한 내용은 Jetpack Compose 실시간 편집의 동영상 클립을 참고하세요.
Compose 다중 미리보기 템플릿
androidx.compose.ui:ui-tooling-preview 1.6.0-alpha01+에서는 하나의 주석으로 일반적인 시나리오에서 Compose UI를 미리 볼 수 있도록 새로운 다중 미리보기 API 템플릿인 @PreviewScreenSizes, @PreviewFontScales, @PreviewLightDark, @PreviewDynamicColors가 도입되었습니다.
Compose 미리보기 갤러리 모드
Android 스튜디오 Hedgehog에서는 한 번에 하나의 미리보기에 집중하고 렌더링 리소스를 절약할 수 있도록 Compose 미리보기에 새로운 갤러리 모드가 도입되었습니다. 앱 UI를 반복해야 하고 UI 변형을 확인할 때 그리드와 목록 같은 다른 모드로 전환해야 하는 경우 갤러리 모드를 사용하세요.
디버거의 Compose 상태 정보
Compose UI는 그 일부분이 예기치 않게 재구성되는 이유를 이해하기 어려울 때가 있습니다. 이제 구성 가능한 함수에 중단점을 설정할 때 재구성의 원인이 될 수 있는 변경사항을 더 쉽게 식별할 수 있도록 디버거에 컴포저블의 매개변수와 상태가 나열됩니다. 예를 들어 컴포저블에서 일시중지하면 디버거를 통해 '변경'되었거나 '변경되지 않은' 상태로 유지된 매개변수를 정확히 확인하여 재구성의 원인을 더 효율적으로 조사할 수 있습니다.
기기 미러링
이제 Android 스튜디오의 Running Devices 창에서 실제 기기를 미러링할 수 있습니다. 기기 화면을 Android 스튜디오로 직접 스트리밍하면 스튜디오 IDE 자체에서 바로 앱 시작하기, 앱과 상호작용하기, 화면 회전하기, 휴대전화 접기 및 펼치기, 볼륨 변경하기와 같은 일반적인 작업을 실행할 수 있습니다.
기기 미러링은 USB 또는 무선 디버깅이 사용 설정된 컴퓨터에 연결된 기기가 있는 경우 항상 사용할 수 있습니다. Running Devices 창 또는 기기 관리도구(View > Tool Windows > Device Manager)를 사용하여 미러링을 시작하고 중지할 수 있습니다. 설정(Settings > Tools > Device Mirroring)에서 기기 미러링이 활성화되는 시점을 맞춤설정할 수도 있습니다.
알려진 문제
일부 기기는 기기 미러링을 지원하기에 충분한 비트 전송률로 인코딩하지 못할 수 있습니다. 이러한 상황에서는 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 스튜디오는 연결 및 페어링된 기기의 기기 미러링을 자동으로 시작할 수 있습니다. 따라서 adb tcpip 명령어로 연결된 기기의 정보가 공개될 수 있습니다. 미러링 정보와 명령어가 암호화되지 않은 채널을 통해 전달되기 때문입니다. 또한 Android 스튜디오는 암호화되지 않은 채널을 사용하여 adb 서버와 통신하므로 미러링 정보를 호스트 머신의 다른 사용자가 가로챌 수 있습니다.
하드웨어 입력 전달
이제 마우스, 키보드와 같은 워크스테이션 하드웨어 입력을 연결된 실제 기기와 가상 기기로 투명하게 전달하는 기능을 사용 설정할 수 있습니다. 투명 전달을 사용 설정하려면 Running Devices 창에서 대상 기기에 대해 Hardware input 
을 클릭합니다.
Running Devices 창에서 직접 기기 관리
이제 + 아이콘을 클릭하고 기기를 선택하여 Running Devices 창에서 직접 Android Virtual Device(AVD)를 시작하거나 실제 기기의 미러링을 시작할 수 있습니다. AVD 또는 실제 기기의 미러링을 중지하려면 기기 탭을 닫으세요.
삽입된 Layout Inspector
Android 스튜디오 Hedgehog 카나리아 2부터 Running Devices 도구 창에서 직접 Layout Inspector를 실행할 수 있습니다. 이 실험용 기능은 화면 공간을 보존하며 단일 도구 창에서 UI 디버깅 워크플로를 구성하는 데 도움이 됩니다. 삽입 모드에서는 뷰 계층 구조를 표시하고, 각 뷰의 속성을 검사하고, 다른 일반적인 Layout Inspector 기능에 액세스할 수 있습니다. 전체 옵션에 액세스하려면 독립형 창에서 Layout Inspector를 실행해야 합니다(Windows: File > Settings > Experimental > Layout Inspector, macOS: Android 스튜디오 > Settings > Experimental > Layout Inspector).
삽입된 Layout Inspector는 3D 모드를 스냅샷에서만 사용할 수 있다는 제한사항을 갖습니다.
삽입된 Layout Inspector를 개선할 수 있도록 의견을 보내 주세요.
새로운 UI 개선사항
Android 스튜디오의 새로운 UI는 스튜디오 IDE에 더 현대적이고 깔끔한 디자인을 적용합니다. 개발자 여러분의 의견을 바탕으로 Android 스튜디오 Hedgehog에서 다음과 같은 기능과 관련된 문제를 해결했습니다.
- 좁게 모드
- 수직 또는 수평 분할 지원
- macOS용 프로젝트 탭
- Distraction Free Mode 수정
- 도구 창 작업을 항상 표시하기 위한 고급 설정
SDK 업그레이드 어시스턴트 업데이트
SDK 업그레이드 어시스턴트는 targetSdkVersion 업그레이드에 도움이 되는 단계별 마법사 흐름을 제공합니다. 다음은 Android 스튜디오 Hedgehog에 적용된 SDK 업그레이드 어시스턴트 업데이트입니다.
- Android 14로의 업그레이드에 관한 브레이킹 체인지 보기
- 관련성 필터를 추가하여 일부 불필요한 단계 삭제
- 일부 변경사항에 대해 코드에서 변경해야 할 정확한 위치 가리키기
대상 API 수준에 대해서만 빌드 최적화 사용 중지
이제 대상 기기 API 수준에 대해 IDE 최적화를 비활성화할 수 있습니다. 기본적으로 Android 스튜디오는 배포할 대상 기기의 API 수준에 맞게 덱싱 프로세스를 조정하여 전체 빌드 시간을 줄입니다. 이 기능을 사용 중지하려면 File > Settings > Experimental(macOS: Android 스튜디오 > Settings > Experimental)로 이동하여 Optimize build for target device API level only를 선택 해제합니다. 이 빌드 최적화를 사용 중지하면 빌드 시간이 늘어날 수 있습니다.
[Windows 전용] 바이러스 백신 소프트웨어가 빌드 속도에 미치는 영향 최소화
빌드 분석 도구는 바이러스 백신 소프트웨어가 빌드 성능에 영향을 줄 수 있는지 알려 줍니다. 이는 Windows Defender와 같은 바이러스 백신 소프트웨어가 Gradle에서 사용하는 디렉터리를 실시간 검사하는 경우에 발생할 수 있습니다. 빌드 분석 도구는 활성 검사에서 제외할 디렉터리 목록을 추천하며 가능한 경우 Windows Defender 폴더 제외 목록에 추가할 링크를 제공합니다.
Eclipse Android 개발 도구 프로젝트가 더 이상 지원되지 않음
Android 스튜디오 Hedgehog 및 이후 버전에서 Eclipse ADT 프로젝트 가져오기를 지원하지 않음 이러한 프로젝트는 열 수는 있지만 더 이상 Android 프로젝트로 인식되지 않습니다. 이 유형의 프로젝트를 가져와야 하는 경우 이전 버전의 Android 스튜디오를 사용하면 됩니다. 특정 버전의 Android 스튜디오에서 프로젝트를 가져올 수 없는 경우 그보다 이전 버전으로 시도해 보세요. 이전 버전의 Android 스튜디오를 사용하여 프로젝트를 Android 프로젝트로 변환한 후에는 AGP 업그레이드 어시스턴트를 사용하여 최신 Android 스튜디오 버전에서 이 프로젝트로 작업할 수 있습니다.
Gradle 관리 기기에서 Firebase Test Lab 기기 사용
AGP 8.2.0-alpha03 및 이후 버전을 사용하는 경우 Gradle 관리 기기를 사용할 때 Firebase Test Lab 기기에서 자동화된 계측 테스트를 대규모로 실행할 수 있습니다. Test Lab을 사용하면 다양한 Android 기기(실제 기기와 가상 기기 모두 포함)에서 동시에 테스트를 실행할 수 있습니다. 이러한 테스트는 원격 Google 데이터 센터에서 실행됩니다. Gradle 관리 기기(GMD)의 지원으로 이제 빌드 시스템에서 프로젝트의 Gradle 파일 구성을 기반으로 이러한 Test Lab 기기에 실행 중인 테스트를 완전히 관리할 수 있습니다.
Gradle 관리 Firebase Test Lab 기기 시작하기
다음 단계에서는 GMD에서 Firebase Test Lab 기기를 사용하는 방법을 설명합니다. 이 단계에서는 gcloud CLI를 사용하여 사용자 인증 정보를 제공하며, 이 내용은 일부 개발 환경에는 적용되지 않을 수 있습니다. 필요에 따라 사용할 인증 프로세스를 자세히 알아보려면 애플리케이션 기본 사용자 인증 정보의 작동 방식을 참고하세요.
Firebase 프로젝트를 만들려면 Firebase Console로 이동합니다. 프로젝트 추가를 클릭하고 화면의 프롬프트에 따라 프로젝트를 만듭니다. 프로젝트 ID를 기억합니다.
<ph type="x-smartling-placeholder">- Google Cloud CLI를 설치하려면 gcloud CLI 설치의 단계를 따르세요.
- 로컬 환경을 구성합니다.
- gcloud에서 Firebase 프로젝트에 연결합니다.
gcloud config set project FIREBASE_PROJECT_ID
API 액세스를 위한 사용자 인증 정보 사용을 승인합니다. 권장 조치 인코더에 전달하여 서비스 계정 JSON 파일을 DSL을 모듈 수준 빌드 스크립트에 추가합니다.
Kotlin
firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }
Groovy
firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }
또는 다음 터미널을 사용하여 수동으로 승인할 수도 있습니다. 명령어:
gcloud auth application-default login
선택사항: Firebase 프로젝트를 할당량 프로젝트로 추가합니다. 이 단계는 500ms를 초과하는 경우에만 필요합니다. Test Lab 무료 할당량.
<ph type="x-smartling-placeholder">gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
- gcloud에서 Firebase 프로젝트에 연결합니다.
필요한 API를 사용 설정합니다.
Google Developers Console API 라이브러리 페이지 사용 설정 Cloud Testing API 및 Cloud Tool Results API API 이름을 콘솔 상단의 검색창에 입력하고 각 API의 개요 페이지에서 API 사용 설정을 클릭합니다.
Android 프로젝트를 구성합니다.
최상위 빌드 스크립트에 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 }
gradle.properties파일에서 맞춤 기기 유형을 사용 설정합니다.android.experimental.testOptions.managedDevices.customDevice=true
모듈 수준 빌드 스크립트에 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를
ftlDevice라는 Gradle 관리 Test Lab 기기로 만듭니다.firebaseTestLab {}블록은com.google.firebase.testlab플러그인을 모듈에 적용할 때 사용할 수 있습니다. 지원되는 최소 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에서 실행 > 테스트 기록을 클릭하면 테스트 결과를 Android 스튜디오로 가져와서 추가로 분석할 수도 있습니다.
기기 그룹에서 테스트 만들기 및 실행
테스트 규모를 확장하려면 기기 그룹에 여러 개의 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 } } }