Googleは、2023年からAndroidのLinuxカーネル機能を「アップストリームファースト」の開発モデルに切り替える計画だ。 さらに詳しく知りたい方は読み続けてください。
同じ文の中に「Android」と「断片化」という単語があると、おそらくすぐに次のようなことが頭に浮かぶでしょう。 Android版分布図. Android OS のアップデートが全面的に展開されるのが遅いと不満を言うときに、ほとんどの人が非難する企業がいくつかありますが、Google ができることは限られています。 力 OEM はアップデートをより迅速に開発し、展開できるようになります。 ただし、Google にできることは、開発時間を短縮し、アップデートを展開するコストを削減することです。
開発負担を軽減するための Google の長期プロジェクトにおける最初の主要な取り組みは、 プロジェクト・トレブル. 2017 年に Android 8.0 Oreo とともに発表された Project Treble は、OS フレームワークをベンダー実装 (HAL およびデバイス固有の Linux カーネル フォーク) から分離することで Android をモジュール化しました。 これにより、ベンダーからの更新されたコードを必要とせずに最新バージョンを起動できるため、Android OEM は最新の AOSP フレームワーク上で OS をリベースすることが容易になりました。 その結果、OEM はカスタム Android フォークを以前よりも迅速に準備できるようになり、ひいては主要な OS アップデートをより迅速に展開できるようになりました。
Google の計画の次のステップは、主要な Android コンポーネントへのアップデートの配信を効率化することでした。 Googleはこの取り組みをこう呼びました プロジェクトのメインライン 2019年にAndroid 10とともに導入されたとき。 Google は基本的に主要な OS コンポーネントを管理し、OEM がコンポーネントを変更することを禁止しました。 次に、Google Play 経由で配信メカニズムをセットアップし、OEM が自らパッチを適用するのを待たずに、これらの主要コンポーネントへのアップデートをリモートでロールアウトできるようにしました。 Mainline により、デバイスが重要な OS コンポーネントの更新バージョンを受け取る速度が大幅に向上し、Android エコシステム全体のセキュリティが向上しました。
しかし、次に起こることはさらに重要であり、おそらく Google の長期戦略の中で最も重要な部分です。 以前、Treble が OS フレームワークを Android から分離することでどのようにモジュール化したかを指摘したとき、 ベンダーの実装には、そのベンダーの一部として「デバイス固有の Linux カーネル フォーク」が含まれています コード。 デスクトップ上の Linux に詳しい人なら誰でも、そこに問題があることに気づくでしょう。なぜそれがクローズド ソース ベンダーのコードと一緒にまとめられているのでしょうか? 問題は、Android デバイスには Linux カーネルが同梱されているものの、そのカーネルには 多く ツリー外のコード。
どうやってそこにたどり着いたのでしょうか？ この問題は、Google ソフトウェア エンジニアの Todd Kjos によって概説されています。 今年の Linux 配管工カンファレンス （経由 アルステクニカ) は、メインライン Linux カーネルが Android デバイスに出荷される前に数回フォークされるためです。 Google は、各メインライン Linux カーネルを「Android共通カーネル" ブランチは、メインライン リリースを厳密に追跡しますが、Android 固有のパッチをいくつか追加します。 Qualcomm、MediaTek、Samsung などの SoC ベンダーがフォークする それ 彼らが作る各 SoC のカーネル。 OEM は、その SoC 固有のカーネルを取得し、追加のパッチを追加して、出荷したい特定のハードウェアのサポートを実装します。
こうした変化により、「デバイス上で実行されているコードの最大 50% がツリー外のコードです (アップストリームの Linux または AOSP 共通カーネルからのものではありません)。」とGoogleによれば。 これらのデバイスにはツリー外のコードが大量にあるため、アップストリームの変更をマージするのは長くて困難なプロセスになります。 OEM は Linux カーネルで発見された脆弱性に対するパッチを実装するためにさらに努力する必要があるため、これはデバイスのセキュリティにとって有害です。 さらに、これにより、ほとんどの Android デバイスは何年も前のカーネル リリースのままになり、新しい Linux カーネル機能を利用できなくなることになります。
この問題に対処するために、Google は Android Generic Kernel Image (GKI) の開発に取り組んでいます。GKI は、本質的には ACK ブランチから直接コンパイルされたカーネルです。 GKI は、SoC ベンダーと OEM のカスタマイズをプラグイン モジュールに分離し、ツリー外のコードを排除し、Google がカーネルのアップデートをエンドユーザーに直接プッシュできるようにします。 Google は 1 年以上にわたり、Play ストア経由で GKI アップデートを配信する方法に取り組んできました。 Mainline モジュールの使用による.
私たちの情報源によると、次の方法で起動するデバイスは、 アンドロイド12 Linux カーネル 5.10 が同梱されている場合は、Google 署名付きのブート イメージを展開する必要があります。 Google 独自の ピクセル6 シリーズは、そのまま Android 12 を搭載して発売され、Linux カーネル 5.10 を搭載して出荷されるため、この 2 つの携帯電話は、GKI を搭載して出荷される最初の大衆向けデバイスとなる可能性があります。
さらに、GoogleのTodd Kjos氏は、同社が新しいLinuxカーネル機能について「アップストリームファースト」の開発モデルに移行する計画であることを明らかにした。 これにより、Google は新しいコードがメインライン Linux カーネルに最初に配置されるようになり、Android デバイスに配置されるツリー外のコードが増えることで生じる将来の技術的負債を軽減できます。
今週開催された Linux Plumbers Conference で、Kjos 氏は次のように述べました。 「ツリー外のモジュールは私たちのユースケースにとって非常に重要であるため、常にエクスポートのセットと、異なるもの、またはこれに加えていくつかのものがあることが予想されます。 しかし、このプロジェクト全体は、可能な限り多くのツリー外のパッチを削除し、可能な限り調整することを目的とした複数年にわたるプロジェクトです。 上流の。" Google は、既存機能のアップストリームとベンダー変更の分離に向けた作業を 2022 年末までに完了することを目指しています そして、同社は 2023 年から、このような問題を回避するためにこの「上流ファースト」開発モデルを採用する予定です。 未来。