Google PixelはもはやAOSPのリファレンスデバイスではない

 (9to5google.com)
2 ポイント 投稿者 GN⁺ 2025-06-13 | 1件のコメント | WhatsAppで共有
  • GoogleはAndroid 16のソースコードをAOSPで公開したが、Pixelハードウェアリポジトリは公開しなかった
  • Pixelのデバイスツリーおよび関連コードが非公開となったことで、コミュニティの一部では「AOSP廃止」ではないかという疑念が出た
  • Googleは**"AOSPは中止されない"**と公式に否定し、今後もAOSPソースコードの公開と更新を継続すると改めて確認した
  • 今後AOSPは、既存ハードウェアに依存しない基準ターゲット(reference target) を志向し、柔軟かつ低コストなCuttlefishなどの仮想デバイス／汎用化デバイス（GSI）中心へ移行する予定
  • カスタムROM開発者やセキュリティ研究者にとって、OSアップデートや研究が難しくなる可能性がある

Android 16リリースとソースコード公開をめぐる問題

  • Android 16のリリースとともに、GoogleはPixelハードウェアリポジトリとデバイスツリー(Device tree)コードを公開しなかった
    • これまではAOSPとあわせてPixelハードウェア向けコードも提供されており、カスタムAndroid ROM開発で不可欠な役割を果たしてきた
  • このため、カスタムROM開発者やセキュリティ研究者は、カスタムOS開発、最新Androidアップデート、およびセキュリティ脆弱性の研究で困難に直面するとみられる

AOSPに関するGoogleの公式見解

  • コミュニティの一部で「AOSPが終了する」という噂が広がったが、Android部門VPのSeang Chauは
    • "AOSPはなくならない"
    • "AOSPの更新に引き続き取り組む" と公式に否定した
  • ただし、Androidチームの公式回答では、今後Pixelデバイスツリーなどはもはや提供しないことが示唆されている
  • AOSPが提供する基準(reference)ターゲットは、特定ハードウェアから独立した形を目指す
    • Googleを含むいかなる特定ハードウェアにも依存しない、柔軟で設定可能かつ低コストな基準デバイスを志向する
    • ここ数年、コミュニティではCuttlefish（リファレンスデバイス）とGSIターゲットをソースからビルドし、テストや開発用途で使ってきた
    • これらの基準デバイスは今後も開発者に公開される予定だ

カスタムROMおよびセキュリティコミュニティへの影響

  • Googleは公式に、AOSPへの継続的な支援意思を強調している
  • しかし、直接的なハードウェアサポートがなくなることで、カスタムROMの作成や保守、あるいはセキュリティ研究において、開発難易度が高まり参入障壁も大きく上昇すると予想される

関連記事

1件のコメント

 
GN⁺ 2025-06-13
Hacker Newsの意見

  • 変に思われるかもしれないが、最近Pixelを買った唯一の理由は、買ってすぐにGrapheneOSをインストールするつもりだったからだ。ここまで本当に満足のいく結果を体験している。仕事に関わることでない限り、Googleが関わるものはできるだけ避けるようにしている。Googleについて嫌いな部分が多すぎるからだ。もちろん、Googleにそうしたバイナリブロブを提供し続ける義務があるわけではないが、長年やってきたことを予告もなく突然やめる姿勢には、またしても失望させられる。さまざまなサービスを終了するときのように、事前に十分な告知をすべきだったと思う。バイナリを配布し続け、動作保証をするのが追加の負担であることは理解できるが、実際のところ彼らは内部ではどうせその作業をしているはずだ。私の推測では、Googleは一部のGrapheneOSユーザーのために端末で損をするよりも、クローズドなエコシステムやデータマイニング、広告といった二次的に収益化できるものに注力するという戦略的選択をしたのだと思う

    • 私もまったく同じ理由でPixelを購入した。今ではほぼあらゆるレイヤーで追跡が行われていることを皆わかっているので、Pixelを買ってすぐGrapheneOSを書き込むのが最も賢い選択だと思う。うちのすべてのスマホ（妻のものも私のものも）で同じように使っている。Play ServicesやGoogleアプリ、Facebookのようなものもまったく気にしなくていい。自分の人生がターゲティング広告や、将来何に使われるかわからないデータの一部になってほしくない。これほどプライバシーに無頓着な人が多いことのほうがむしろ不思議だ

    • 甘めの評価だな。私もまったく同じことをしている

    • 「Googleが十分な事前告知なしにバイナリ提供を打ち切った」という主張には少し違う見方をしている。文書化されていない挙動に依存しておいて、変わったからと抗議するのはおかしい。ソフトウェアエンジニアなら、そういうものに依存しないのが常識だ。もし誰かがPixelを文鎮として使っていて、カメラの出っ張りのせいでもう使えなくなった状況を例に出したとして、それを会社のせいにするのと同じだと思う

  • Pixel（あるいは昔のNexus）のような実際の一般消費者向けハードウェアを買って、AOSPとプロプライエタリなブロブを取得し、特別な作業なしですべてのハードウェアが動作するビルドを作れたことには本当に感謝している。Cuttlefishのほうがより効果的なリファレンスデバイスかもしれないが、PixelのようにGrapheneOSなどの用途で端末を幅広く活用できる点とは違う。自分の手元で直接ビルドしたAndroidを実機で動かす体験には、VM上では得られない魅力があると思う

    • 記事によれば、GSI(Generic System Image)もリファレンスデバイスとしてサポートされており、これは実機により近い選択肢だ。ただ、GSIにはいろいろ不便な点があり、端末の低レベルな仕様（パーティション方式・Android初回出荷バージョンなど）によってビルドの種類がまちまちだ。それでも代替手段として悪くはない。最近ではGKI(Google Generic Kernel Image)というものも登場していて、（カスタムモジュール・ブロブを除けば）新しい端末なら動作するよう設計されている。ただし、これはLinuxカーネルのメインラインとは別物で、今でも多くのカスタムパッチが当てられたダウンストリームブランチだ。それでも、実機に依存せず統一された方法でテストや開発をしやすくしてくれる

  • GrapheneOSは問題の状況を誇張し、自分で失敗した（「オオカミ少年」効果）と思う。明らかに嘘だとわかる批判には、企業側も反論しやすい。「Google is killing AOSP」のような主張は目立ちはするが、企業が反論の論理を示すにはあまりにも容易な話だ。今起きているのは、GrapheneOSがGoogleの善意に依存してバイナリブロブを得ていたという状況であり、Googleには何の義務もないのだから、自分たちなりの理由があって提供をやめただけだ。しかもGrapheneOSが法的・独占に関する論点に言及したことで、開発者たちはそもそも関わらなくなり、法務部門に回されるだけになる

    • 具体的に何が誇張だというのか気になる。何が嘘なのか、GrapheneOSが過去にもそうだったのか、具体的にどの部分が間違っているのか知りたい

    • 今回の件をきっかけに、GrapheneOSがPixel以外のより広い端末群もサポートするようになるのではと思う。実際、すでにそうしているべきだったとも思うし、ハードウェア対応が多少劣っても、それがなくても依然として素のAndroidより圧倒的に安全だ

    • Googleは事実上の独占企業の二社のうち一社なのだから、Googleを積極的に擁護する必要はないという立場だ

  • Pixelのハードウェアリポジトリ（デバイスツリー、ドライバのバイナリなど）がなければ、カスタムAndroid ROMがOSアップデートを開発するのは非常に難しくなるのではないかと以前から心配している。セキュリティ研究にも影響があるかもしれない

    • とりわけGrapheneOS公式Twitterでこうした内容が投稿されていて、なおさら心配だ

  • GrapheneOSがなければ、たぶんiPhoneに移ると思う。長い間GrapheneOSを使ってきて、不要なGoogle要素のない軽くてシンプルな感覚がとても気に入っていた。もうGoogle公式のPixelは自分には合わない

  • Google Graveyardの一覧にまた一つ追加だ。自分でコントロールできないのなら、Pixelを使う理由はもうない。iPhoneをまた使ってみて、欠点を受け入れつつ多くの利点を享受するつもりだ

  • 「AOSPは生きている、エミュレータでも使える」という類いの反論を思い出す。記事では「ここ数年、開発者たちはCuttlefish（GitHubのリファレンス）やGSIターゲットをソースからビルドしてリファレンスターゲットとして使ってきた。今後もテスト・開発目的で提供を維持する」と説明している。私はAOSP初心者なのだが、実際こうしたリファレンスデバイスはカスタムROM開発に実用的なのか、それとも見せかけの主張なのか、コミュニティ視点で知りたい

  • GrapheneOSがPixelでうまく動いていた理由は、たぶんこれが関係していたのではないかと思う。最初の障壁を越えたあとで中核となる変更点を理解できれば、むしろより多くの端末へサポートが広がる可能性もあるのではと期待している

    • 一部だけ正しい。公式FAQによれば主な理由は、(1) メモリタグ付けのような最高水準のハードウェアセキュリティ機能、(2) 迅速なパッチ提供、(3) 長期の公式サポートだ

    • あるいは今回の変更によって、GrapheneOSが今後は新規デバイスを一切サポートしない方向に進む可能性もある

  • GrapheneOSこそがPixelを買う唯一の理由だった

  • やや重複した内容だ 関連リンク