두 번째 화면의 정복：당백 박스로의 극简 데스크톱 이식, 그리고 ADB로는 측정할 수 없었던 하나의 길게 누르기 기능

첫 번째 화면의 정복은 TV에 속하고, 두 번째 화면은 박스에 속한다. 같은 철학을 더 새로운 안드로이드에서 재연해야 한다——그리고 재연의 과정에서, 성패를 진짜로 결정하는 것은 이식 자체가 아니라 대상 플랫폼에서 처음으로 나타나는 그 제약이었다.

一、박스 전량 스캔：마흔다섯 개의 제거가 모두 유지

당백 박스(192.168.5.17)로 옮겨 첫 번째로 한 일은 전량 스캔이며, 중점은 지난번 제거한 패키지가 OTA에 재설치되지 않았는지 보는 것이었다. 두 개의 「재설치」는 변별을 요했다——com.android.music는 매우 부분 문자열 오보일 가능성이 있다(유지하고 있는 com.android.musicfx에 매치했다), com.android.modulemetadata는 당시 일부러 회복한 것이다(Wi-Fi 크래시를 고친 그것). 정밀 매치로 재검하고 둘 다 배제했다.

마흔다섯 개의 제거가 모두 유지, 재설치 영. 시스템은 DBOX-A2, 안드로이드 12, 펌웨어는 변하지 않았고, 사용 가능 메모리 977MB, 저장 잔여 20GB(앱 캐시 1.67GB는 정리 가능).

현재 소비 대호의 랭킹은 문제를 여실히 보여준다——시스템 프레임워크 160MB는 움직일 수 없고, 당백 데스크톱 110MB(내용 홍보 포함), ktcp.video 81MB plus 수호 프로세스 21MB(기동 시 자동 시작), 소TV 55MB plus 통계 프로세스 37MB(기동 시 자동 시작). 실행 가능한 청단은 지난번 깊이 판 결론에 따라 모두 여전히 유효하며, 그중 수익이 가장 큰 하나는 당백 데스크톱을 교체하는 것이었다.

二、이식——안드로이드 12가 더 간단하지만 하나의 관건적인 덫

TV에서 쓴 극简 데스크톱을 적응할 수 있나? 가능하고, 게다가 TV보다 간단하다——박스는 안드로이드 12이고 원판의 minSdk 26가 기본으로 충족되어 강등은 불필요. 그러나 적응점이 세 개 있고, 그중 하나가 관건적이다：

안드로이드 11+의 패키지 가시성 제한. 원판 manifest의 <queries>는 LEANBACK_LAUNCHER 일종만을 선언하고 있어, 통상의 LAUNCHER 종류만을 선언하는 앱은 열거되지 않는다. 먼저 dumpsys package로 앱의 종류를 조사한다——안드로이드 12에서는 해석表을 포함하지 않는다——그 다음 cmd package query-activities로 바꾼다, 이것은 바로 우리의 데스크톱이 볼 수 있는 목록이다.

관건적인 확인——앱의 종류는 혼합이었다——ktcp, B站, btelly 등은 LEANBACK 종류이지만, 소TV(tv.yst)는 통상의 LAUNCHER 종류만, 당백 자신의 데스크톱/설정도 LAUNCHER 종류이다. 원판의 queries는 LEANBACK만을 선언하고 있어, 박스에 설치하면 소TV는 열거되지 않는다.

적응 방안은 이에 명확해졌다——<queries>에 통상의 LAUNCHER 종류를 추가한다. 동시에 Dock 설정을 박스의 네 개의 주력 앱으로 고친다——윤시팅 극광, bilibili, TVBox OSC, 소TV.

적응항	TV판(안드로이드6)	박스판(안드로이드12)
minSdk	26→23(강등 이식)	26가 기본으로 충족되어 변경 불필요
앱 가시성	이종류 쿼리	queries에 통상의 LAUNCHER 추가
Dock 설정	TV의 앱	네 개의 주력 앱
기동 시 포커스	예선 커서를 수복	마찬가지로 유효
입력원 버튼	숨김(입력 없음)	마찬가지로 자동 은폐

빌드, 설치, cmd package set-home-activity로 한 걸음에 기본 데스크톱으로 설정. HOME이 선택기를弹出했으므로, 키 조작으로 선택. 데스크톱이 움직이기 시작했다——박스 앱은 표지를 갖고 있어, TV의 아이콘보다 훨씬 아름답다.

재기동 검증——박스의 재기동 후 ADB는 자동 회복(persist 속성이 유효해, TV처럼 매번 수동으로 열 필요 없음), 게다가 기동해 바로 우리의 데스크톱으로 들어갔다. 사용 가능 메모리는 1.05GB(처음 866MB → 비대를 제거 후 977MB → 데스크톱 교체 후 1.05GB). 당백의 원래 데스크톱은 설치한 채로, 다만 기본이 아니게 된 것뿐이며, 언제든지 전환할 수 있다.

三、이동 모드——「설정을 고쳐 다시 빌드」를 한 마디로 바꾸다

주인이 물었다——이 앱의 드래그 정렬이나 Dock 앱 변경을 직접 기능으로 만들 수 있나?

가능하고, 게다가 해야 한다——그것이 바로 완전한 데스크톱 체험이다. 지금 Dock을 고리려면 다시 빌드가 필요해, 확실히 반인간이다. 그래서 리모컨 이동 모드를 추가한다——길게 누르기 OK로 앱을 집어 올리고 → 방향키로 이동(첫 번째 줄이 Dock이며, 들어가면 가입, 나오면 이탈) → OK로 내리고, 순서는 자동 저장.

구현에서는 먼저 영속화 저장소 클래스를 세우고, 다음에 AppAdapter를 고친다(인터페이스에 두 개의 콜백을 추가, 길게 누르기 라우팅, 영속화 순서, 이동 메서드), Holder의 방향키 리스너에 OK 키 처리를 더하고, reload의 순서 로직을 사용자 저장의 순서가 있으면 우선해서 그것을 쓰도록 고치고, 마지막으로 MainActivity에 이동 모드의 완전한 구현과 돌아가기 키 취소를 더하고, 문자열 자원을 중영으로 보충한다.

컴파일 때 작은 구멍을 밟았다——AppAdapter.java:248가 기호를 찾지 못한다——lambda는 Adapter의 onBindViewHolder 안에 있고, getBindingAdapterPosition()는 Holder의 메서드이므로 h.로 호출해야 한다. 고치면 통과했다.

四、ADB로는 측정할 수 없었던 하나의 기능

이동 모드가 완성되고, 검증 때 한 벽에 부딪혔다——길게 누르기 테스트는 실제로는 클릭이 되었다——input --longpress가 효과가 없고 바로 첫 번째 Dock 앱을 기동했다. 다시 시도해도, 역시 탭으로 bilibili를 기동한다. input --help를 조사하니, 길게 누르기 파라미터를 지원하지 않는다. 실퇴——이 박스의 input --longpress는 길게 누르기를 지원하지 않는다.

ADB 경로에서는 길게 누르기를 측정할 수 없다. 그러나 예비 입구를 하나 더할 수 있다——MENU 키——일부 리모컨에는 메뉴 키가 있고, adb에서도 테스트할 수 있다. 이중 보험.

MENU 키가 유효해졌다——데스크톱은 여전히 포그라운드에 있고(앱은 기동하지 않음), 이동 모드가 활성화되고, 프롬프트가 정상으로 표시되었다——「방향키移动 위치（첫 번째 줄은 Dock），OK 저장，돌아가기 취소」, 윤시팅 극광은 집어 올린 상태에 있다. 영속화의 확인에 성공——데스크톱 재기동 후 Dock의 순서는 bilibili가 첫 번째, 윤시팅 극광이 두 번째로 유지되었다——교체는 저장되었다.

이에 최종 상태는——MENU 키 입구는 완전히 사용 가능함이 검증되었고；길게 누르기 OK 입구는 adb에서는 모형할 수 없어, 리모컨으로의 실측이 필요하다. 길게 누르기가 효과가 없으면, MENU 키는 완전히 쓸 수 있는 대안이다.

五、덤으로 발견——앱 내의 기동 광고

테스트 중 길게 누르기가 효과가 없어, 잘못해서 ktcp.video(윤시팅 극광)를 기동했고, 그것이 기동 시 전체 화면의 징동 광고를 띄웠다(취多多, ReachMax 광고 네트워크).

이것은 앱 자신의 기동 광고이며, 시스템 광고가 아니다. 주인이 박스에 광고가 없다고 한 것은 시스템 층면을 가리키고, 이것은 ktcp 앱 내부의 행동이다. 처리할 것인지는 주인이 정하는 것이고, 그의 앱에는 건드리지 않는다.

六、숙제와 롤백

TV 쪽의 데스크톱은 아직 구판(이동 모드 없음)이고, ADB는 펌웨어에 꺼져 있어, 갱신하고 싶으면 한 번 열어주면 동기화할 수 있다. 롤백의 길은 세 가지 모두 남겼다——당백 데스크톱으로 전환은 set-home-activity 한 줄, Dock 앱을 고치는 것은 한 마디면 이 분 재빌드, 극简 데스크톱을 제거하는 것은 adb uninstall 한 줄.

두 번째 화면의 정복은 여기서 완료되었다. 그리고 그것이 남긴 경험은 첫 번째 화면보다 값어치가 있다——같은 이념을 새로운 플랫폼에 가져갈 때, 어려운 것은 결코 이식이 아니라, 거기서 처음으로 나타나는 제약을 발견하는 것이다——이번에는 <queries>에 써넣지 않은 한 종류였다.