Google の汎用カーネルイメージは、Android の断片化問題の解決に向けた次のステップです

Google の汎用カーネルイメージは、Android の断片化の問題を解決することを目的としていますが、これは複雑なテーマです。仕組みは次のとおりです。

Google は Android の断片化を減らすことに何年も取り組んできましたが、その原因の 1 つは Android の固有の性質と、選択と自由という両刃の剣です。この分野では数え切れないほどの OEM が活動しており、どの OEM も自社のデバイスに独自の変更を加えたいと考えています。問題は、Android OS のアップデートが全体的に展開されるのが遅いように見えるが、OEM にデバイスのアップデートを強制するために Google が実際にできることはあまりないことだ。したがって、Google ができる次善の策は、更新プロセスをできるだけ簡単かつスムーズにすることです。

Android アップデートの苦痛を軽減する

開発負担を軽減するための 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 エコシステム全体のセキュリティが向上しました。

ただし、Treble に関して言えば、現実的には、Linux カーネルをクローズドソースベンダーのコードと一緒に扱うべきではありません。トッド・ジョース今年の Linux 配管工カンファレンス以前、Android のフラグメンテーションに関して直面する困難について説明しましたが、現在ではその多くが、OEM がデバイスに同梱する Linux カーネルを中心にしています。文脈として、Google は各メインライン Linux カーネルを「Android共通カーネル」 (ACK) ブランチ。メインラインリリースを厳密に追跡しますが、Android 固有のパッチをいくつか追加します。 Qualcomm、MediaTek、Samsung などの SoC ベンダーがフォークするそれ彼らが作る各 SoC のカーネル。 OEM は、その SoC 固有のカーネルを取得し、追加のパッチを追加して、出荷したい特定のハードウェアのサポートを実装します。

上の図は、デバイスのカーネルが、Linux LTS カーネルから遠く離れた抽象化された複数の変更レイヤーをどのように通過するかを示しています。簡略化するために、Linux カーネルから開始し、いくつかの変更を加えて Android 共通カーネルにマージします。そこから、Android 共通カーネルは、独自の修正と変更を加えてベンダーカーネル (Qualcomm、MediaTek など) にマージされます。最後に、ベンダーカーネルは OEM のデバイス固有のカーネルにマージされます。この段階までに、デバイスのカーネルは、最初の Linux LTS カーネルからは遠く離れています。

これらすべてのフォークの結果、Android デバイス上で実行されているコードの 50% もがツリー外のコードになっています。これは、アップストリームの Linux または AOSP 共通カーネルからのものではないことを意味します。このため、アップストリームの変更をマージすることが非常に困難になります (時間とコストがかかることは言うまでもありません)。 OEM にとって、そうする動機はありませんが、そのような行為はデバイスのセキュリティに悪影響を与える可能性があります。これは、多くの Android デバイスが古い LTS カーネルリリースのままになっている理由でもあり、デバイスが新しい Linux カーネル機能にアクセスできなくなるという副作用があります。

Android は断片化されており、Google もそれを認識している

Google はこれが問題であることを十分に認識しており、「」というセクションさえ設けています。断片化のコストAndroid 開発者向けドキュメントの「 Googleはこう言っています 「ほとんどの主力デバイスには、少なくとも 18 か月以上前のカーネルバージョンが付属しています。」. さらに悪いことに、Google はこうも言っています。「Android 10 は 3.18、4.4、4.9、4.14、および 4.19 カーネルをサポートしていますが、場合によっては 2017 年の Android 8 以降、新しい機能で強化されていません。」このため、新しい Linux カーネルバージョンを必要とする機能を追加することが困難になります。 Linux カーネル 3.18 は、Android 5.0 Lollipop が Android の最新バージョンだった 2014 年 12 月にリリースされました。これは明らかに問題であり、プラットフォームの足かせとなる可能性があります。

たとえば、Code Aurora Forum (略して CAF) は、さまざまな Qualcomm Snapdragon SoC のソースコードをホストしています。 SoCとしてのクアルコムベンダーは、フォークされたバージョンの Linux カーネルを OEM/ODM に配布し、それらの企業は出荷時にデバイス固有の変更を追加します。デバイス。これにより、いくつかの層の断片化が追加されます。さらに、クアルコムは、同社の各 Snapdragon モバイルプラットフォーム向けに Android を最適化するために、AOSP フレームワークに変更を加えています。クアルコムは、修正された Linux カーネル、AOSP フレームワーク、およびその他のソフトウェアツールを、ボードサポートパッケージ (BSP) の一部としてパートナーに非公開で配布しています。 CAF は、Qualcomm が Linux カーネルの変更と AOSP フレームワークの変更を公的に公開する場所です。

この CAF リリースは、純粋な AOSP ではなく出発点として使用したいカスタム ROM 開発者にとって役立ちます。フォーラムの「CAF ベース」ROM. 何年もの間、非常に多くのミッドレンジスマートフォンに電力を供給していたと思われるSnapdragon 625を覚えていますか? これは Linux カーネル 3.18 でリリースされ、クアルコムがカーネルソースを更新して公開したのは、2018 年の終わり頃 (チップセットの発売から 2 年後) になってからです。カフェ msm8953 (Snapdragon 625 のチップセット名) では、Linux カーネル 4.9 のサポートが提供されます。問題は、ほとんどの OEM が携帯電話はこの新しい Linux カーネルバージョンに更新されません。特に、チップの登場から 2 年経ったミッドレンジの携帯電話はそうではありません。解放されました。確かに、そのようなメジャーなカーネルのアップデートがそもそも行われることは非常にまれですが、重要なのは、 もっている 実際に起こったことなので、単なる不可能なシナリオではありません。

全体的に見て、現在の Android の断片化は、控えめに言ってもめちゃくちゃです。この断片化を修正しようとする Google の最新の試みは、汎用カーネルイメージ (GKI) の形で行われています。

汎用カーネルイメージの紹介

この断片化に対処するために、Google は Android 汎用カーネルイメージ (GKI) に取り組みました。これは本質的に、ACK ブランチから直接コンパイルされたカーネルです。 GKI は、SoC ベンダーと OEM のカスタマイズをプラグインモジュールに分離し、ツリー外のコードを排除し、Google がカーネルのアップデートをエンドユーザーに直接プッシュできるようにします。 Google は 1 年以上にわたり、Play ストア経由で GKI アップデートを配信する方法に取り組んできました。 Mainline モジュールの使用による.

その結果、Linux カーネル 5.10.43 以降を実行する Android 12 で起動するデバイスは、次のいずれかを実行する必要があります。ミシャール・ラーマンによれば.

Google 署名付きブートイメージをデプロイする

または

GKI によってエクスポートされた KMI のサブセットである KMI (カーネルモジュールインターフェイス) をエクスポートするカーネルを使用してブートイメージをデプロイします。 GKI によって公開される UAPI のスーパーセットであるユーザー空間 API をエクスポートし、対応する GKI のすべての機能をサポートしますバージョン

ベンダーは GKI にプラグインするモジュールを作成できますが、GKI の考え方は、Google がカーネルの変更を処理する責任を負うというものです。カーネルモジュールインターフェイス (KMI、これについては記事の後半で詳しく説明します) は、ツリー外のコードが事実上配置されることが期待される場所です。

Google Pixel 6 シリーズは、Android 12 をそのまま搭載して発売され、Linux カーネル 5.10 が搭載されており、GKI が搭載された最初のスマートフォンです。 Google は Play ストアを通じてカーネルを更新する可能性があるため、カーネルの更新が頻繁に行われる可能性もあります。 LTS カーネルのアップデートは通常毎週リリースされるため. いずれにせよ、これは現在面倒な OTA 経由の更新方法よりもはるかに優れたシステムですが、これは本質的に GMS フレームワークに関連付けられていることを意味します。

Google は単に GKI を次のように定義しています。

これは ACK ソースから構築されています。
これは、単一カーネルのバイナリに加え、アーキテクチャごと、LTS リリースごとに関連するロード可能なモジュールを備えたものです (現時点では arm64 のみ) android11-5.4 そして android12-5.4).
関連する ACK がサポートされているすべての Android プラットフォームリリースでテストされています。 GKI カーネルバージョンの存続期間中、機能の非推奨はありません
これにより、特定の LTS 内のドライバーに安定した KMI が公開されます。
SoC やボード固有のコードは含まれません。

Googleは、2023年までに「アップストリームファースト」の開発モデルを採用できる立場にいたいとさえ考えている。これにより、Google は新しいコードがメインライン Linux カーネルに最初に組み込まれるようになり、Android デバイス上でツリー外のコードによって発生する「技術的負債」を削減できるようになります。

カーネルモジュールインターフェイス (KMI)

カーネルモジュールインターフェイス (KMI) は、Android で進行中の断片化に対する Google のソリューションの一部です。本質的に、SoC とボードのサポートはコアカーネルには配置されなくなり、代わりにロード可能なモジュールに移動されます。モジュールが更新されるため、カーネルとモジュールの両方を独立して更新できます。 /lib/modules. GKI 自体は可能な限りクリーンで汎用的なものであることが想定されており、これはツリー外のコードを別個のモジュールにオフロードすることで可能になります。

テッド・ジョース役で説明しました今年の Linux Plumbers Conference では、「数年にわたる大きな取り組みは、すべてのハードウェア固有のコードを汎用カーネルからベンダーモジュールに取り出すことです。非同期で出荷できるように、これらのベンダーモジュールと汎用カーネルの間に安定したインターフェイスが必要です。」 GKI 1.0 は本質的に「コンプライアンステスト」です。

実際、GKI 互換性とは、デバイスが Generic System Image (GSI) を使用した VTS および CTS-on-GSI+GKI テストに合格することを意味します。 GKI カーネルは、GKI ブートイメージをブートパーティションにフラッシュし、GSI システムイメージをシステムにフラッシュすることによってインストールされます。パーティション。ベンダーテストスイート (VTS) は、Project Treble と互換性があるとみなされるためにすべてのデバイスが合格する必要がある自動テストです。 Google のアプリケーションスイートにアクセスするには、互換性テストスイート (CTS) が必要です。

デバイスには別の製品カーネルが付属しており、GKI が提供していないロード可能なモジュールを使用できます。ただし、製品カーネルと GKI カーネルは両方とも、同じ Vendor_boot および Vendor パーティションからモジュールをロードする必要があります。したがって、すべての製品カーネルは同じバイナリカーネルモジュールインターフェイス (KMI) を持つ必要があります。

上の図は、Google が何をするかを示しています。望むそして、それを達成するための方法を説明します。ジェネリックカーネルモジュールと GKI モジュールは AOSP の一部となり、GKI は Android フレームワークおよびベンダーが実装するハードウェアアブストラクションレイヤー (HAL) と通信できます。ベンダーがカーネルに含めたい特定の独自コード (カメラドライバーなど) は、代わりに、KMI を介して GKI の拡張機能となるベンダーモジュールにプッシュされます。

GKI が Android の断片化問題の解決にどのように役立つか

Google はスマートフォンの開発プロセスの合理化に多大な努力を払ってきました。すべての OEM は独自のブランドアイデンティティを望んでおり、すべての OEM は自社のデバイスの所有権を取得できるようにしたいと考えています。 Android One プログラムとは異なり、Android スマートフォンは、GMS ライセンスを取得するために Google が定めた一連のルールを遵守している限り、ほぼ自由に使用できます。しかし、これまで Google は、Android デバイス開発において君臨するためにあまり多くのことをしてきませんでした。 Project Treble、Mainline などの変更、そして Android では GKI がかなり新しくなりました歴史。

しかし、それは役に立つでしょうか？そうなるはずだが、それは数年に渡る取り組みとなり、将来的には目に見える形で実を結ぶことになるだろう。これは Android 12 で起動するデバイスにのみ適用されます。つまり、GKI を持たないデバイスは今後何年も続くことになります。これは Project Treble が発表されたときの批判でもありましたが、現在発売されているすべてのデバイスがそれをサポートしていることは明らかです。これらには時間がかかりますが、Google がゆっくりと Android の統治を引き始めるにつれて、すべての OEM の開発プロセスが緩和されます。 Android エコシステムの一部は、Android で使用される Linux カーネルを完全に制御したいと考えている場合でも、スマートフォン。