第二の画面の征服：当貝盒子への極簡デスクトップ移植、そして ADB では測れなかった一つの長押し機能

第一の画面の征服はテレビに属し、第二の画面は盒子に属する。同じ哲学をより新しいアンドロイドで再演しなければならない——そして再演の過程で、成否を本当に決めるのは移植そのものではなく、対象平台で初めて現れるあの制約であった。

一、盒子の全量スキャン：四十五個のアンインストールがすべて保持

当貝盒子（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（起動時自動起動）、小电视 55MB plus 統計プロセス 37MB（起動時自動起動）。実行可能な清単は前回の深掘り結論に従いすべて依然有効であり、その中で収益が最大の一つは当貝デスクトップを置き換えることであった。

二、移植——アンドロイド 12 はより簡単、しかし一个の关键的な罠

テレビで使った極簡デスクトップを適配できるか？　できる、しかもテレビより簡単である——盒子はアンドロイド 12 であり、原版の minSdk 26 がネイティブに満たされ降級は不要。しかし適配点が三つあり、その一つが关键である：

アンドロイド 11+ のパッケージ可視性制限。 原版 manifest の <queries> は LEANBACK_LAUNCHER 一类のみを宣言しており、通常の LAUNCHER 类のみを宣言するアプリは列挙されない。まず dumpsys package でアプリの類別を調べる——アンドロイド 12 では解析表を含まない——その後 cmd package query-activities に切り替える、これはまさに私たちのデスクトップが見える清単である。

关键的な確認——アプリの類別は混合であった——ktcp、B站、btelly などは LEANBACK 类であるが、小电视（tv.yst）は通常の LAUNCHER 类のみ、当貝自身のデスクトップ/設定も LAUNCHER 类である。原版の queries は LEANBACK のみを宣言しているため、盒子にインストールすると小电视は列挙されない。

適配方案はこうして明確となった——<queries> に通常の LAUNCHER 类を追加する。同時に Dock 設定を盒子の四つの主力アプリに改める——云视听极光、bilibili、TVBox OSC、小电视。

適配項	テレビ版（アンドロイド6）	盒子版（アンドロイド12）
minSdk	26→23（降級移植）	26 がネイティブに満たされ変更不要
アプリ可視性	二類別クエリ	queries に通常の LAUNCHER を追加
Dock 設定	テレビのアプリ	四つの主力アプリ
起動時フォーカス	予選カーソルを修復	同じく有効
入力源ボタン	隠す（入力なし）	同じく自動隠蔽

ビルド、インストール、cmd package set-home-activity で一步にしてデフォルトデスクトップに設定。HOME が選択子を弹出したので、キー操作で選択。デスクトップが動き出した——盒子アプリはカバーを帯びており、テレビのアイコンよりずっと美しい。

再起動検証——盒子の再起動後 ADB は自動回復（persist 属性が有効で、テレビのように毎回手動で開く必要なし）、しかも起動して直接私たちのデスクトップに入った。空きメモリは 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 アプリ内部の振る舞いである。扱うかどうかは主人が決めることで、彼のアプリには触れない。

六、宿題とロールバック

テレビ側のデスクトップはまだ旧版（移動モードなし）であり、ADB はファームウェアに切られているので、更新したければ一度開き直せば同期できる。ロールバックの道は三つすべて残された——当貝デスクトップに切り戻すは set-home-activity 一本、Dock アプリを改めるは一声で二分の再ビルド、極簡デスクトップをアンインストールするは adb uninstall 一本。

第二の画面の征服はここに完了した。そしてそれが残した経験は第一の画面より値打ちがある——同じ理念を新しい平台に持っていくとき、難しいのは決して移植ではなく、そこで初めて現れる制約を発見することである——今回は <queries> に書き漏れた一つの類別であった。