ハクソク

世界を動かす技術を、日本語で。

Androidがデバイス上のADBを制限する可能性がある

2026年7月25日原文(kitsumed.github.io)

概要

  • Google IssueTracker での新機能提案に関する非公式情報の解説
  • On-Device ADB接続 の制限案とその影響についての議論
  • セキュリティ上の懸念と 正当なユースケース のバランス
  • 利用者や開発者ができる フィードバック方法 の提案
  • ADBの基本概要と On-Device ADB の重要性の整理

Google IssueTracker発のOn-Device ADB制限案とその影響

  • 本記事は Google公式発表 ではなく、IssueTracker上の開発者コメントを元にした内容
  • On-Device ADB接続 を制限する提案が進行中であり、「悪意のある利用者」からの保護が理由
  • この制限は Shizuku など多くの開発者・パワーユーザー向けツールに影響
  • 公式スレッドへの 低品質なコメントやスパム は開発者の負担増・議論の閉鎖リスクを高めるため控えるべき
  • 独自のユースケースや技術的な解決策がある場合は 具体的かつ建設的な意見 を投稿推奨
    • 既出のユースケースには +1ボタン で賛同表明と通知設定のみを推奨

ADB（Android Debug Bridge）とは

  • Googleが開発したデバッグ用プロトコル で、Android端末の詳細操作を可能にするツール
  • 本来は USB接続 が前提だったが、後に TCP/IP や Wireless Debugging （Android 11以降）など多様な接続方式に対応
  • ADBは高い権限 を持つため、開発者・パワーユーザーの必須ツール

On-Device ADB接続とは

  • 元々はPCとAndroid端末の二台構成 を想定して設計
  • 近年は Termux等の端末エミュレータ を使い、端末内でADBクライアントを起動し、 ループバック（127.0.0.1） で接続する利用が広がる
  • この仕組みは libadb-android や Shizuku など、多数のオープンソースツールの基盤
  • ニッチなユースケース ながら、障害者支援や開発効率化など多彩な用途で活用

提案されている変更内容

  • ADB Daemon（ADBD）の待受インターフェースを選択可能 にする新機能の提案
  • 重大なセキュリティ脆弱性（CVE-2026-0073）を契機に議論開始
  • wlan0（Wi-Fiインターフェース）のみ許可 する案が出ており、これによりOn-Device ADBやVPN経由ADBなど多くの利用形態が破綻

セキュリティ上の懸念と正当な利用

  • Google側は On-Device ADBを主に悪用手段と見なす傾向
  • 実際には 人間の操作が不可欠 であり、悪意あるアプリ単独での権限昇格は不可能
  • 典型的な攻撃シナリオでは、 ADBやデバッグ設定の有効化など明確なユーザー操作 が必要
  • デフォルトで制限しつつも、 ユーザーが明示的に解除できる永続設定 が望ましい
  • Accessibility権限やデバイス管理者同様、 リスクと利便性のバランス を取るべき

On-Device ADBがもたらすエコシステム

  • App Manager、libadb-android、Canta、aShell、ShizuWall、ShizuCallRecorder、Shizuku など、独自ツール群の発展
  • 本来の設計意図を超えた 開発者・パワーユーザー向け機能 の拡大
  • 制限が厳しすぎると 障害者や特殊ニーズのユーザー が不利益を被る恐れ

結論と今後のアクション

  • On-Device ADB制限 はセキュリティ強化の観点から一定の合理性
  • しかし、 正当なユースケース を無視した一律遮断は問題
  • 明確なリスク説明とユーザー選択権の確保 が必要
  • 技術的な利用者は IssueTrackerへの建設的なフィードバック が推奨される
  • 公式議論への参加時は 冷静かつ具体的な意見 を心がけること

要点まとめ：

  • Google IssueTracker でのOn-Device ADB制限案
  • セキュリティ対策 と 開発者・障害者支援 のバランス
  • ユーザーによる明示的な選択肢 の必要性
  • 建設的なフィードバック で議論への貢献

Hackerたちの意見

やっと子供たちが安全になって、私の銀行口座も守られるわ！

└

/s

https://archive.ph/gla4i プライベートにされるかもしれないからね。

もちろん、こうなるのは予想通りだったよ。次は、サイドローディングの24時間制限が無期限になるって言うの？

└

それは、質問「その前に逃げるための実行可能な代替手段があるのか？」への答え次第で、無期限になる可能性が高いです。市場を完全に制圧する必要はなくて、Googleがためらうくらいのもので十分です。法的な理由でGoogleが動きにくくなるような感じですね。FirefoxがChromeに対して理想的にあるべき姿みたいな。

これって、ユーザーがアンロックされた電話に物理的にアクセスできる唯一の人だって前提だよね。政府機関や空港のセキュリティ、今じゃ教師までアクセスできるし。こういう攻撃は簡単に自動化できるから、低賃金の労働者でもできちゃうんだよね。

└

これは、ADBが動いているっていう大きな警告を追加することで解決できるよ。機能を削除するんじゃなくてね。

スレッドをスパムするのは、Googleの開発者が問題をロックして、貴重なコミュニティのフィードバックを無視したり、この変更についての公のアップデートを完全に止めたりするだけだよ。だから、何も変わらない（彼らは「貴重なコミュニティのフィードバック」をロックすることもできるし、彼らを困らせるのは批判そのものだからね）。だから、自由に賛成の意を表していいよ。

└

ブログ記事で、Googleの開発者が重要なユースケースを「見落とした」り「誤解した」っていう暗示があるけど、もし彼らがそれについて知らされていたら再考するだろうっていうのは、正直言って失礼だよ。

└

こういう記事がHNやReddit、他のフォーラムに出ると、誰かの考えを変える希望は失われるね。Githubの問題でも同じことが起こる。自分でその問題を確認してないけど、ここにあるってことは、もう手遅れかもしれないし、たぶん溢れかえっちゃうだろうね。Googleは時々アプリ開発者からフィードバックを受け取るけど、明らかに自社のチームの意見の方が、この記事のようなハックに頼るオープンソース開発者よりも重要なんだと思う。ADBデーモンがアプリからループバックアドレス経由でADBセッションを開始して通話録音を可能にするために設計されてないのは明らかだよね。https://xkcd.com/1172/ がまたやってきた。これが変化を嫌う開発者が間違っているわけではない。Google自身が以前にダイヤラーに通話録音機能を追加したから、明らかに彼らが支持している機能なんだ。それでもADBチームは少しセキュリティを強化するべきだと思うけどね。

セキュリティの向上には基本的に賛成だけど、ここではあまりメリットが見えないな。この攻撃ベクトルは、ユーザーが開発者設定を有効にしていて、かつリモートADBが有効になっている必要があるから、99.9%のユーザーには現実的な攻撃ベクトルじゃないと思う。残りの0.1%も多分自分が何をしているか分かってるだろうし。提案されている他の変更（特定のインターフェースやIPアドレスへのアクセス制限）は良さそうだけど、なんで開発者がlocalhostへのアクセスを制限できるようにしないの？ShizukuやCantaをブロックしようとしてるようにしか見えないよ。

└

これは、kimwolf（今は6つ以上のボットネットも）のおかげじゃない？住宅用プロキシソフトを知らずに使っている人たちを利用して、tcp/5555で127.0.0.1へのアウトバウンド接続を許可して認証したり、wgetを実行したり、ddosマルウェアのAPKを取得してインストールするローダーを落としたりするっていう。

Hacker Newsで議論の続きを見る