부제: 화면 없는 에뮬레이터 22종에서 158개 WindowInsets 캡처를 모으고, Firebase Test Lab 실기기 19종으로 검증하기까지
서두
1탄에서는 windowinsets.info에 필요한 Samsung Remote Test Lab 기기를 직접 조작하고, InsetsProbe가 측정한 JSON을 Vercel Function을 통해 GitHub PR로 보내는 흐름을 만들었다. 삼성 기기는 실제 기기에서 값을 얻을 수 있었지만, Pixel 기종을 추가할 때는 같은 방법을 쓸 수 없었다. Samsung RTL처럼 여러 Pixel 기기를 빌려 주는 환경이 없었기 때문이다.
대신 Android SDK에는 Pixel device profile과 AOSP emulator skin이 들어 있다. 그렇다면 Emulator 창을 띄우지 않는 headless 방식으로 가상 기기를 실행하고, InsetsProbe를 설치한 뒤 내비게이션 방식·화면·회전을 바꾸며 JSON을 모으면 된다. 처음에는 이 정도면 단순한 반복문으로 끝날 줄 알았다.
여기서 headless 부팅은 가상 기기의 화면 자체를 없애는 방식이 아니다. 호스트 컴퓨터에 Android Emulator 창을 띄우지 않고 백그라운드 프로세스로 실행하는 방식이다.
-no-window로 실행해도 가상 Android 안에서는 display와 SystemUI가 그대로 동작하므로 앱은 WindowInsets를 받을 수 있다. 마우스로 화면을 누르는 대신adb명령으로 앱 실행, 화면 회전, 접힘 상태와 내비게이션 방식을 조작한다.이번 측정에서는
-no-window -no-audio -no-snapshot -no-boot-anim을 함께 사용했다. 호스트의 Emulator 창과 오디오 출력을 만들지 않고, 저장된 snapshot을 복원하지 않으며, 부팅 애니메이션도 생략한 채 매번sys.boot_completed를 기다렸다. 사람이 Emulator UI를 보고 조작하지 않아도 같은 시작 조건에서 여러 AVD를 순서대로 측정하기 위한 설정이었다.
그런데 자동화할 대상은 앱 실행만이 아니었다. 바형 폰과 폴더블 내측 화면은 회전 방식이 달랐고, 접힘 상태를 바꾸는 순간 앱이 재생성되면서 이전 화면 라벨로 파일을 내보내기도 했다. 실기기용 업로드 키가 든 APK를 잘못 사용해 에뮬레이터 데이터가 실제 기기용 PR에 올라간 일도 있었다.
이 글은 Pixel 지원 전략을 바탕으로 headless AVD 측정을 자동화하고, Pixel 22종에서 158개 캡처를 수집한 뒤, Firebase Test Lab의 실제 Pixel 기기로 그 값을 검증하기까지 겪은 문제를 정리한 기록이다.
본론
먼저 자동화 범위를 정했다
측정 대상은 Android SDK에 device profile과 AOSP skin이 있는 Pixel로 한정했다. 2020년 이후 출시된 바형 Pixel과 모든 Pixel Fold, Pixel Tablet을 합쳐 22종이었다.
기종마다 필요한 조합은 달랐다.
| 형태 | 기종 수 | 기종당 조합 | 캡처 수 |
|---|---|---|---|
| 바형 폰 | 18 | 내비게이션 2종 × 회전 0·1·3 | 108 |
| 폴더블 | 3 | 커버 6개 + 내측 8개 | 42 |
| 태블릿 | 1 | 내비게이션 2종 × 회전 0·1·2·3 | 8 |
| 합계 | 22 | 158 |
바형 폰과 폴더블 커버는 일반적인 자동 회전에서 180°를 지원하지 않아 0·1·3만 측정했다. 폴더블 내측과 태블릿처럼 large screen으로 취급되는 화면은 네 방향을 모두 확인했다.
삼성 측정과 Pixel 측정은 무엇이 달랐나
두 제조사의 데이터를 모두 InsetsProbe로 읽었지만, 기기까지 도달하는 방법과 결과를 부르는 기준은 달랐다.
| 구분 | Samsung Galaxy | Google Pixel |
|---|---|---|
| 측정 환경 | Samsung RTL 또는 사용자가 가진 실기기 | Android SDK의 headless AVD |
| 화면 외형 | Samsung이 배포한 Galaxy Emulator Skin | Android SDK의 AOSP Pixel skin |
| 기기 조작 | 사람이 예약·설치·잠금 해제·화면 전환을 준비하고 Probe가 측정 | 스크립트가 AVD 부팅부터 화면·내비게이션·회전을 제어 |
| 결과 전달 | Probe가 Vercel Function을 거쳐 capture inbox PR로 업로드 | 로컬에서 JSON과 manifest를 pull한 뒤 importer로 등록 |
| 증거 등급 | 실제 기기 또는 RTL 실측 | AVD profile이 보고한 emulator 측정 |
| 주된 실패 지점 | 예약 시간, 원격 UI, APK 설치, 파일 다운로드 | adb 상태, fold·rotation 전환, APK provenance, 조합 누락 |
삼성 자동화는 사람이 원격 기기를 사용할 수 있게 준비한 다음부터 시작한다. Pixel은 AVD의 생성과 종료까지 로컬에서 제어할 수 있어 사람의 조작을 더 많이 없앨 수 있었다. 대신 Pixel 데이터에는 실제 제품이 아니라 특정 emulator version과 system image가 만든 값이라는 조건이 붙는다.
공통점도 있었다. 화면 모양을 skin에서 추정하지 않고 Android가 InsetsProbe에 전달한 값을 저장했다. 측정하지 못한 조합은 비워 두고, raw JSON과 출처를 보존한 뒤 검증을 통과한 값만 사이트에 연결했다.
전체 흐름은 다음과 같이 잡았다.
한 AVD 안에서 조합을 모두 측정한 뒤 종료하고 다음 기종으로 넘어간다. 여기서 manifest.json은 부가 정보가 아니라 측정값의 출처다. AVD 이름, device profile, skin, system image, build fingerprint, emulator version과 각 파일을 만든 방식을 함께 남긴다.
문제 1. 실기기용 APK가 에뮬레이터 데이터를 업로드했다
문제 발생
1탄에서 만든 InsetsProbe는 sweep이 끝나면 JSON을 실제 기기용 capture inbox에 업로드한다. 로컬에서 Pixel을 측정할 때도 같은 build output 경로의 APK를 사용했는데, 그 사이 실기기 측정을 위해 업로드 키가 포함된 APK가 다시 빌드됐다.
그 결과 에뮬레이터의 가로 캡처 하나가 실제 기기용 PR에 들어갔다. 이후 배치에서는 실행 중 APK가 키가 든 빌드로 교체된 사실을 확인하고 중단했다. 에뮬레이터 측정과 실기기 수집이 같은 APK 경로를 공유한 것이 원인이었다.
문제 해결
에뮬레이터용 Probe는 업로드 키를 비운 채 빌드하고, 결과 APK를 별도 경로에 복사해 고정했다.
./gradlew :app:assembleDebug -PinsetsProbeUploadKey=
python3 scripts/capture-emulator.py \
--apk /path/to/probe-keyless.apk \
--out /path/to/pixel-captures스크립트도 --apk로 받은 파일을 설치하기 전에 DEX 안에 설정된 업로드 키가 포함됐는지 검사한다. 키가 발견되면 측정을 시작하지 않는다. 빌드 명령을 문서에 적는 것만으로는 부족했다. 잘못된 APK를 넘겨도 실행 단계에서 막아야 같은 사고가 반복되지 않는다.
문제 2. 한 가지 회전 방식으로 모든 화면을 돌릴 수 없었다
문제 발생
InsetsProbe에는 앱이 직접 방향을 요청하며 회전을 순회하는 sweep 기능이 있다. 바형 폰과 폴더블 커버에서는 이 방식으로 rotation 0·1·3이 정상적으로 저장됐다.
하지만 Android 16 이상에서 large screen으로 취급되는 폴더블 내측 화면은 앱의 방향 요청을 무시했다. 같은 sweep을 실행해도 네 방향의 파일이 나오지 않았다. 반대로 화면 밖에서 user-rotation을 바형 폰에 적용하면 Launcher가 위에 있는 동안 세로 방향으로 되돌리는 문제가 있었다.
문제 해결
화면 성격에 따라 회전 방식을 나눴다.
- 바형 폰과 폴더블 커버: Probe의
--ez sweep true를 사용한다. - 폴더블 내측과 태블릿:
cmd window user-rotation lock N으로 화면을 돌린다.
외부에서 회전할 때는 dumpsys window displays의 mRotation=N을 확인한 다음 Probe를 실행한다. 회전 중에는 Probe의 capture guard가 저장을 거부하므로, 회전이 끝난 뒤 앱을 다시 실행해 한 번만 export한다.
파일 이름도 신뢰하지 않았다. JSON 안의 display.rotation을 읽어 실제 회전값과 맞는 파일만 가져왔다. 자동화가 요청한 방향과 Android가 실제로 적용한 방향은 다를 수 있기 때문이다.
문제 3. 접힘 상태를 바꾸자 이전 화면 이름으로 저장됐다
문제 발생
Pixel Fold AVD는 adb emu fold와 adb emu unfold로 커버와 내측 화면을 전환할 수 있다. 문제는 Probe가 실행 중인 상태에서 화면을 접거나 펼치면 Activity가 새 display configuration으로 재생성된다는 점이었다.
이 과정에서 export가 다시 실행되면 실제 화면은 바뀌었는데 파일에는 이전 screen 라벨이 남을 수 있었다. JSON이 정상적으로 만들어졌다는 사실만 보면 놓치기 쉬운 오류였다.
문제 해결
화면이나 내비게이션 방식을 바꾸기 전에 Probe를 항상 force-stop했다.
Probe 종료
→ fold/unfold 또는 navbar overlay 변경
→ committed device state와 navigation_mode 확인
→ Probe 재실행
→ JSON export접힘 상태는 cmd device_state state에서 CLOSED 또는 OPENED가 committed 상태가 될 때까지 기다렸다. 내비게이션 방식은 SystemUI overlay를 바꾼 뒤 settings get secure navigation_mode가 gesture 2, 3-button 0으로 바뀌었는지 확인했다.
폴더블 내측 캡처에서는 FLAT folding feature가 있어야 하고, 커버에는 folding feature가 없어야 한다. importer도 이 조건을 검사해 화면 라벨이 잘못 붙은 데이터를 등록하지 않는다.
문제 4. AVD 측정값을 Pixel 실기기 값이라고 부를 수 없었다
문제 발생
22종의 자동 측정이 끝났어도 남는 질문이 있었다. AVD device profile이 보고한 cutout과 rounded corner가 실제 Pixel 하드웨어와 같은가?
같은 Pixel 9 Pro Fold AVD를 Emulator 36.4.9와 37.1.11에서 다시 측정했을 때 값은 같았다. 이것은 자동화의 재현성은 보여 주지만 실기기와의 일치까지 증명하지는 않는다.
실기기와 비교하려면 실제 Pixel이 필요했다. 그렇다고 AVD 값과 실기기 값을 한 폴더에 섞으면, 나중에 어떤 숫자가 어디서 왔는지 구분할 수 없게 된다. 비교를 시작하기 전에 두 증거를 어떻게 나눠 둘지부터 정했다.
문제 해결
에뮬레이터 측정과 실기기 검증을 별도 증거로 보관했다.
- AVD JSON은
emulator-<date>폴더에 저장한다. - Firebase Test Lab JSON은
testlab-<date>폴더에 저장한다. - 사이트에는 AVD version, device profile, system image와 build를 표시한다.
- 출처는
emulator로 명시하고 Pixel 하드웨어 실측값이라고 표현하지 않는다. - 실기기 차이가 발견돼도 조건을 검토하기 전에는 AVD 값을 덮어쓰지 않는다.
자동화의 마지막 단계는 숫자를 많이 만드는 일이 아니라, 그 숫자가 어디에서 왔는지 잃지 않는 일이었다.
Firebase Test Lab 실기기로 AVD 값을 검증했다
Pixel 실기기는 Firebase Test Lab(FTL)에서 빌렸다. FTL은 원래 앱 테스트용 서비스지만, 물리 기기에 APK를 설치하고 지정한 디렉터리의 파일을 결과로 내려받을 수 있다. InsetsProbe가 JSON을 앱 전용 디렉터리에 저장하므로 이 경로만 열어 두면 측정 도구로 쓸 수 있었다.
측정은 Robo test로 실행했다. Robo test는 원래 앱 화면을 자동으로 탐색하는 테스트인데, 탐색 전에 Robo script로 원하는 동작을 먼저 실행할 수 있다. 여기서는 Probe를 켜서 한 번 export하고 곧바로 탐색을 끝내는 script만 사용했다.
[
{ "eventType": "ADB_SHELL_COMMAND", "command": "am force-stop info.windowinsets.probe" },
{ "eventType": "ADB_SHELL_COMMAND", "command": "rm -f /sdcard/Android/data/info.windowinsets.probe/files/*.json" },
{ "eventType": "ADB_SHELL_COMMAND", "command": "am start -W -n info.windowinsets.probe/.MainActivity --es screen phone --ez export true" },
{ "eventType": "WAIT", "delayTime": 5000 },
{ "eventType": "TERMINATE_CRAWL" }
]gcloud firebase test android run \
--type robo \
--app /tmp/insets-probe-ftl-keyless.apk \
--robo-script tools/insets-probe/testlab/phone-portrait.robo.json \
--device model=MODEL_ID,version=OS_VERSION_ID,locale=en,orientation=portrait \
--directories-to-pull /sdcard/Android/data/info.windowinsets.probe/files \
--timeout=2mAPK는 AVD 측정과 마찬가지로 업로드 키를 뺀 빌드를 복사해 고정했다. FTL 결과도 실기기 capture inbox로 올라가면 안 되기 때문이다. 비용은 처음 다섯 번은 무료 Spark 요금제로 돌렸고, 이후 전용 프로젝트에 결제 계정을 연결해 Blaze로 전환했다. Blaze에는 하루 30분의 물리 기기 무료 사용량이 있고, 그 이상은 기기-시간당 5달러다. 한 기기당 실행이 2분을 넘지 않도록 --timeout=2m으로 묶었다.
문제 5. Robo가 측정을 끝내고도 앱을 계속 탐색했다
문제 발생
첫 실행인 Pixel 10 Pro XL은 테스트 자체는 통과했지만 JSON이 5개 나왔다. 처음 script에는 export 뒤 ls로 파일을 확인하는 단계와 그 출력에 대한 정규식 검사가 있었다. 명령은 성공했는데 Robo는 이 검사를 script 실패로 처리했고, 남은 script를 건너뛴 채 자동 탐색 모드로 넘어갔다.
Robo는 Probe 화면의 버튼을 눌러 보고 Launcher와 Settings까지 돌아다녔다. 그 과정에서 Probe가 네 번 더 export했다. 게다가 남아 있던 세로 캡처는 바형 폰인데도 screen=main으로 저장돼 있었다. Probe의 화면 라벨은 사람이 지정하는 값이고 실제 화면을 바꾸지 않기 때문이다.
문제 해결
script에서 ls 검사를 빼고, 파일 확인은 결과를 내려받은 뒤 로컬에서 하도록 바꿨다. export 다음에는 곧바로 TERMINATE_CRAWL로 탐색을 끝낸다. 화면 라벨도 기종 형태에 맞춰 phone, 폴더블 내측, 태블릿 가로용 script를 따로 두었다.
첫 실행의 파일은 지우지 않고 증거로 남겼지만, 라벨이 틀린 캡처라 비교에는 쓰지 않았다. Pixel 10 Pro XL은 수정한 script로 다시 측정했다. 두 번째 실행부터는 모든 기기가 JSON 하나만 만들고 정상 종료했다.
문제 6. 같은 모델인데 실기기와 AVD 값이 달랐다
문제 발생
FTL 물리 기기 19종에서 각각 세로 gesture 캡처 하나를 받아 AVD 값과 비교했다. 카메라 모양을 나타내는 cutout path와 화면 모서리 반경부터 보면 결과는 네 갈래였다.
| 비교 결과 | 기종 |
|---|---|
| 기록 정밀도에서 일치 | Pixel 10 Pro Fold, 9 Pro Fold, 9, 8, 8a, 7, 7a, 6, 6a |
| 0.1–0.5 dp 차이 | Pixel 10 Pro XL, 9 Pro XL, 9 Pro, 8 Pro, 7 Pro |
| 눈에 띄는 차이 | Pixel 10 Pro (path 약 1.2 dp, corner 약 2 dp 작음), Pixel 10 (corner 약 2.3 dp 큼), Pixel 9a (corner 43.81 dp vs AVD 50.29 dp) |
AVD는 corner null | Pixel Fold 내측 (실기기 19.81/18.29 dp), Pixel Tablet (실기기 14/13.5 dp) |
더 헷갈린 것은 safe inset이었다. 카메라 path가 거의 같아도 OS가 잡는 cutout 제외 영역은 달랐다. Pixel 10 Pro XL의 상단 cutout inset은 실기기 66.05 dp, AVD 53 dp였다. Pixel 9는 65.90 dp와 54.10 dp, Pixel 6a는 반대로 44.95 dp와 50.29 dp였다. Pixel 10 Pro Fold 내측은 해상도까지 같았는데도 제외 영역이 160 px과 136 px으로 달랐다.
문제는 원인을 하드웨어 차이 하나로 돌릴 수 없다는 점이었다. AVD는 모두 Android 17(API 37)이었고 FTL 기기는 API 32–36이었다. 활성 해상도도 달랐다. Pixel 10 Pro XL 실기기는 1080×2404로 동작했지만 AVD profile은 1344×2992였다. Pixel Tablet은 처음에 실기기가 세로, AVD가 가로로 캡처돼 방향조차 맞지 않았다.
문제 해결
비교 조건부터 맞췄다. dp 값과 화면 크기 대비 geometry로 비교하고, Pixel Fold 내측과 Pixel Tablet은 AVD와 같은 크기·방향으로 다시 측정했다. 조건을 맞춘 뒤에도 두 기기는 실기기에만 rounded corner가 있었고, 상태 표시줄 inset도 실기기가 더 컸다(Fold 내측 41.90 dp vs 28.19 dp, Tablet 36 dp vs 24 dp).
그래도 AVD 값을 실기기 값으로 덮어쓰지 않았다. OS 버전이 다른 상태에서 한쪽을 정답으로 고르면, 하드웨어 차이와 OS 차이를 구분할 근거가 사라진다. 차이는 기종별로 PIXEL_HARDWARE_VALIDATION.md에 발견 사항으로 기록했다. 실기기 raw JSON과 action log, 결과 URL, SHA-256 checksum은 testlab-2026-09-28/에 따로 보관했다. 사이트 값은 계속 emulator 출처를 표시한다.
검증 결과
최종 등록된 결과는 다음과 같다.
- Pixel 22종에서 raw JSON 158개와 기종별 manifest를 수집했다.
- 바형 폰 18종은 각각 6개, 폴더블 3종은 각각 14개, Pixel Tablet은 8개였다.
- 등록된 최종 AVD는 Emulator 37.1.11.0과 Android 17 API 37 system image를 사용했다.
- Pixel 9 Pro Fold는 서로 다른 Emulator 버전에서도 같은 값을 냈다.
- 사이트에 사용하는 rotation 0 값은 importer가 모델, 해상도, 내비게이션 방식과 화면 상태를 검증한 데이터만 생성했다. 다른 방향은 원본 증거로 보관했다.
- Firebase Test Lab 물리 기기로 공개 Pixel 22종 중 19종을 spot check했다. 모든 실행이 기대한 모델과 API의 JSON을 하나씩 만들었고, 두 내비게이션 판별 방식도 일치했다.
- 19종 중 9종은 camera path와 corner가 AVD와 일치했고, 5종은 0.5 dp 이내였다. 나머지 차이는 발견 사항으로 남겼다.
다음에는 어떤 기기까지 대응할 수 있을까
현재 공개 범위는 Galaxy 120종과 Pixel 22종이다. 다음 확장은 기종 수만 늘리는 방식보다, 이번에 나눈 수집과 검증 구조를 재사용할 수 있는지를 먼저 본다.
가장 가까운 계획은 새 Pixel 대응이다. Android SDK에 새 device profile과 AOSP skin이 추가되면 scripts/pixel-devices.json에 사양과 출처를 등록하고 같은 headless 측정 흐름을 실행할 수 있다. 바형 폰, Fold, Tablet은 이미 서로 다른 화면·회전 행렬을 처리하므로 같은 형태의 후속 기종은 새 자동화 코드를 만들지 않고 추가하는 것이 목표다.
동시에 Pixel 실기기 검증 범위도 넓혀야 한다. Pixel 6 Pro와 Pixel 4a는 확인 당시 FTL 물리 기기 목록에 없었고, Pixel 5는 제공되는 API 30이 Probe의 최소 API 31보다 낮았다. 이번 spot check도 기종당 한 화면·한 방향의 gesture mode뿐이라 3-button navigation, 다른 회전, Fold 커버 화면은 아직 검증 대상이다.
그다음 후보는 Firebase Test Lab에서 물리 기기를 제공하는 다른 Android 제조사다. Pixel 지원 전략에는 다음 제품군을 후보로 두었다.
- Motorola moto g·edge
- Sony Xperia
- OnePlus, OPPO, realme, vivo
- Lenovo Tab P12 같은 Android 태블릿
이 기기들은 Probe로 값을 측정할 수 있어도 사이트에 바로 정식 등록할 수 있는 것은 아니다. 화면을 표현할 수 있는 공식 또는 재사용 가능한 artwork 출처가 먼저 확보돼야 한다. artwork가 없다면 측정값만 보관하거나 preview로 남기고, 제품 이미지를 보고 좌표를 추정하지 않을 계획이다.
더 긴 범위에는 Wear OS도 있다. 원형 화면은 휴대폰의 사각형 safe area와 모델이 달라 별도 Probe와 artwork가 필요하다. 현재는 휴대폰·폴더블·태블릿을 먼저 확장하고, Watch는 round-screen safe area를 추적할 수 있는 수집 경로가 완성된 뒤 다루려고 한다.
결론
삼성 측정 자동화가 원격 실기기에서 파일을 꺼내는 병목을 줄이는 일이었다면, Pixel 자동화는 여러 AVD의 상태 조합을 같은 조건으로 반복하는 일이었다. Pixel 측정의 핵심도 headless Emulator를 실행하는 명령 자체가 아니었다. 기기마다 다른 화면 상태와 회전 정책을 실제 Android 상태로 확인하고, 잘못된 APK와 불완전한 결과를 다음 단계로 넘기지 않는 경계를 만드는 일이었다.
capture-emulator.py는 AVD를 조작해 raw JSON과 provenance manifest를 만든다. import-emulator-captures.py는 그 결과를 다시 검증하고 사이트 데이터로 변환한다. 수집과 등록을 분리한 덕분에 스크립트가 끝났다는 이유만으로 측정값이 곧바로 공개되지 않는다.
두 파이프라인을 에이전트가 반복 실행할 수 있게 만든 것은 결국 측정 하네스였다. 범용 에이전트(Claude Code, Codex) 위에 프로젝트 전용 절차(skill), 계측 도구(InsetsProbe), 입력 경로, 검증 게이트, 증거 저장소를 얹는 구조는 같았지만, 각 층을 채우는 내용은 달랐다.
하네스 층 Samsung ( samsung-rtl-insets)Pixel ( pixel-emulator-insets)절차의 무게중심 예약·크레딧 규칙과 원격 UI 복구 단계 에뮬레이터 증거를 실기기 증거와 섞지 않는 규칙 조작 수단 브라우저 WebClient: 스크린샷, 좌표 탭, 페이지 JS adb셸:cmd,settings,adb emu fold제약 크레딧, 30분 예약, 지역·빌드 선택 디스크 공간과 부팅 시간 사람이 필요한 지점 삼성 로그인, 로컬 네트워크 권한, capture inbox 머지 측정 중에는 없음 Probe 빌드 업로드 키 포함, capture inbox PR로 업로드 키 없는 APK, 스크립트가 키 포함 APK를 거부 회전 Probe sweep, 앱 요청을 무시하는 화면은 RTL Rotate 컨트롤 폰 크기 화면은 Probe sweep, 큰 내부 화면은 cmd window user-rotation lock등록 inbox JSON에서 기종별 회전 레코드 생성 importer가 기종 모듈·AOSP skin·레지스트리를 재생성 삼성 하네스는 원격 기기 사용 시간과 UI 자동화에 묶여 있어서 skill의 대부분이 복구 절차와 크레딧 규칙이다. Pixel 하네스는 결정적인 스크립트라 skill의 대부분이 증거 등급을 지키는 규칙이다. 예를 들어 Flip 커버 화면이 가로로 돌지 않는다는 사실은 Probe sweep만으로는 측정 실패와 구분되지 않았다. RTL의 Rotate 컨트롤로 기기 자체를 돌려 다시 확인한 뒤에야 "미측정"이 아니라 "회전하지 않는 화면"으로 기록할 수 있었다. 두 하네스의 전체 비교는 MEASUREMENT_HARNESS.md에 정리해 두었다.
이 흐름으로 Pixel 22종의 반복 측정은 자동화했다. 이후 새 Pixel profile은 같은 파이프라인에 추가하고, 공식 artwork와 실기기 측정 경로를 확보한 제조사도 차례로 연결할 수 있다. 다만 에뮬레이터 값은 끝까지 에뮬레이터 값이고, 측정할 수 있다는 사실만으로 공개 가능한 기기가 되는 것도 아니다.
Firebase Test Lab 검증에서는 19종 중 9종이 camera path와 corner까지 AVD와 일치했다. 하지만 같은 모델이라도 OS 버전과 활성 해상도가 다르면 safe inset이 10 dp 이상 달라지기도 했다. 그래서 실기기 값은 AVD 값을 고치는 정답이 아니라, 나란히 보관하는 또 하나의 증거로 남겼다.
참고 자료
