Android の Project Mainline について知っておくべきことすべて

Android の近年の最大の変更のうち、その重要性とは対照的に目立たなかったものの 1 つは、次の機能の導入でした。 プロジェクトのメインライン Android 10では。 Google は、Android リリース全体に特定のメインライン モジュールを含めることを義務付けています。 アンドロイド11 と一緒に入ってくる 必須のメインライン モジュールの合計は 25 個です. ここでは、Android のすべての Project Mainline モジュールのリストとともに、Project Mainline とは何か、そしてそれが何を解決することを目的としているのかについて説明します。

プロジェクトメインラインとは何ですか?

Project Mainline を正しく理解するには、少し巻き戻す必要があります。 数年前に遡ると、Android のアップデートに関する会話の多くは断片化の問題を中心にしていました。 断片化は、Ice Cream Sandwich - Lollipop の時代に Google が Android 上で解決すべき最大の課題の 1 つでした。 プラットフォームとしての Android は、ほぼ予測可能なパターンで定期的にアップデートを受けていますが、これらのアップデートが最終消費者の手に届くまでには、たとえ届いたとしても非常に長い時間がかかりました。 そのため、Google はプラットフォーム レベルで重大なバグやセキュリティ問題を修正していましたが、これらの変更の実際の展開には多くの要望が残されました。 アップデートの配信には、多くの仲介者 (SoC ベンダー、OEM、通信事業者など) と多くの可動部分が関与していました。 断片化の問題は、何らかの強力な攻撃を必要とせずに自動的に解決されるようには見えませんでした。 介入。

この問題に対処するための主要な取り組みの 1 つは、次のような形で行われました。 プロジェクト・トレブル Android 8.0 Oreo と並行して、Android の大幅な再設計が行われ、Android OS フレームワーク コンポーネントがベンダー HAL および Linux カーネルから分離されました。 Project Treble は本質的に、OS フレームワークをデバイス固有の下位レベルのソフトウェアから分離することで Android をモジュール化しました。 これにより、デバイス メーカー (OEM) は、シリコン メーカー (SoC ベンダー) がベンダー実装コードを更新するのを待つ必要がなくなり、OEM は Android OS フレームワークを独自に更新できるようになります。 その結果、OEM は新しい Android リリースをより迅速に採用できるようになります。 仲介業者 (SoC ベンダー) が最初に仕事を終えるまで待ってから、作業を開始します。 彼らのもの。

Android のアップデート状況は、Project Treble によってすぐに劇的に改善されたわけではありませんが、より広範な OEM が可能になりました Android 10 および Android 11 ベータ版への参加により、OEM はより多くのデバイスをより迅速にアップデートすることが容易になります。 タイムライン。 さらに、GSI (Generic System Image) の概念全体が、フォーラムのアフターマーケット開発に大きな影響を与えました。

開発者が Project Treble GSI を使用して 22 台の古いデバイスで Android 11 を起動

Project Mainline は、Project Treble の取り組みを拡張します。 Treble は、OS アップデートごとに OEM が SoC ベンダーに依存する度合いを減らしましたが、Mainline は、主要な OS コンポーネントにセキュリティ アップデートを提供する際に Google が OEM に依存する度合いを減らしました。 Project Mainline は、Treble の哲学を Android フレームワークのより重要な部分に拡張し、この方程式から依存する仲介者としての OEM を排除します。 Project Mainline の目的は、Google がフレームワーク コンポーネントとシステム アプリケーションの制御を奪うことです。 セキュリティと OEM から離れた開発の一貫性を維持するために重要です。 プロジェクト メインラインは正当に次のように呼ばれます。 の Project Treble 以来の Android への最大の変更.

Project Mainline の場合、Google は、Google Play Services フレームワークおよび Google Play ストアを通じて提供される Mainline モジュールを利用します。 各メインライン モジュールは、APK ファイル、APEX ファイル、または APK-in-APEX のいずれかとして配信されます。 メインライン モジュールが更新されると、ユーザーのデバイスに「Google Play システム アップデート」(GPSU) 通知が表示されます。 事実上、Google は、重要なコンポーネントにアップデートを配信するために、OEM がアップデートを展開するのを待つ必要を回避し、タスク自体を実行することを選択しました。

として GoogleはAndroidのウェブサイトでこう述べている:

モジュラー システム コンポーネントにより、Google と Android パートナーは、非侵入的な方法でエンドユーザー デバイスにアップデートを広範囲、迅速、シームレスに配布できます。 たとえば、メディア コーデックの断片化と重大なバグが組み合わさると、アプリの導入とユーザー エンゲージメントが大幅に遅くなる可能性があります。 メディア関連モジュールを頻繁に更新すると、コーデックの断片化が軽減され、さまざまな Android デバイス間でメディア アプリの動作の一貫性が高まり、重大なバグが修正されてユーザーの信頼が構築されます。

Android 10 以降では、選択したシステム コンポーネントがモジュールに変換され、その一部は APEX コンテナ形式 (Android 10 で導入) を使用し、一部は APK 形式を使用します。 モジュラー アーキテクチャにより、システム コンポーネントを重要なバグ修正などで更新できます。 下位レベルのベンダー実装や上位レベルのアプリに影響を与えることなく、必要に応じて改善を行います。 サービス。

として アルス テクニカ 言及:

Project Mainline、別名「Google Play システム アップデート」は、Android のコア システム コンポーネントをよりモジュール化して更新可能にするための主要な取り組みとして Android 10 に導入されました。 Mainline は、アプリのアップデートを配布するのと同じくらい簡単に、Play ストアを通じてコア Android コードを配布することを目的として、システム コンポーネント専用の新しい「APEX」ファイルタイプを導入しました。 以前は、Android で出荷可能なコード ブロックは APK だけでした。APK は、もともとサードパーティ アプリ用に設計されたファイルタイプでした。 これにはあらゆる種類のセキュリティ制限があり、起動プロセスの後半でしか起動できなかったため、APEX はより強力なシステム コンポーネントを念頭に置いて作成されました。 APEX は Google またはデバイスのメーカーのみが作成できるため、著しく強力になり、アプリ ランタイムなどの重要な起動コンポーネントを収容できます。

メインラインは単なる技術的なソリューションではなく、Android のより多くの部分を集中的に分散させることでもあります。 Google では、デバイス メーカーと交渉し、すべてのメーカーが同じブロックを出荷することに同意するようにします。 コード。 Mainline モジュールは最終的には出荷が必須となるため、Mainline は実際にはデバイス メーカーとの大規模なコラボレーションにより、エコシステム全体の 1 つのモジュールが全員のニーズを確実に満たせるようにします。 すべての Mainline モジュールが超強力な APEX モジュールであるわけではありません。一部のモジュールは、Google が配布する Android コードである単なる APK です。

プロジェクトのメインライン — モジュール

Android 10 では、Google は 13 の特定のメインライン モジュールを含めることを義務付けました。 Android 11 では、必須モジュールの総数は 25 です。 完全なリストといくつかの重要な詳細は次のとおりです。

上記の列にコンテキストを提供するために、「Android 11 にアップグレードされたデバイス、または Android 11 で起動されたデバイス」というタイトルの列には、モジュールが存在する必要があるかどうか (または存在してはならないかどうか) に関する詳細が含まれています。 Android 11 にアップグレードされているか、Android 11 で起動しているすべてのデバイスに、代替データが含まれているため、タイム ゾーン データの場合は存在します。 箱。 同様に、Android 10 で起動するデバイスには、いくつかのモジュールを含める必要があり、他のいくつかのモジュールを含めることが強く推奨されており、残りのモジュールはサポートされていません。 Android 10 にアップグレードされたデバイス (Android で起動されたデバイスとは対照的に) の場合、必要なモジュールのリストは短くなります。

各 Mainline モジュールは何をするのでしょうか?

各 Mainline モジュールの簡単な説明は次のとおりです。

アドバド

adbd モジュールは、コマンドライン adb および IDE デバッグ セッションを管理します。 adbd をモジュール化することで、Google はパフォーマンスの向上とバグ修正をより迅速に提供できるようになります。 過去の一部のバグはバッテリーの消耗に関連しており、携帯電話が故障するまでデバイスが 100% の CPU を使用し続ける可能性があるため、これは非常に重要です。 したがって、adb はアプリ開発者や OEM によってテストに広く使用されているため、これらの修正を公開することは Google にとって非常に重要です。

Android ニューラル ネットワーク API ランタイム

これは、アプリとバックエンド ドライバーの間に位置するライブラリです。 この API は、モバイル デバイス上で計算集約的な機械学習操作を実行し、ハードウェア アクセラレーションによる推論操作を可能にする Android C API です。

携帯ブロードキャスト

セル ブロードキャストは、緊急および非緊急アラート (AMBER アラートなど) を指します。 このモジュールは、これらの警報に関するタスクと、ワイヤレス緊急警報の SMS デコードやジオフェンシングなどのその他の補助機能に関係します。

コンクリプト

Conscrypt モジュールは、Android の TLS 実装と、キー ジェネレーター、暗号、メッセージ ダイジェストなどのその他の暗号化機能を処理します。 これをモジュールとして出荷することで、Google は OTA アップデートに依存することなく、セキュリティの改善を加速できるようになります。

DNSリゾルバー

名前が示すように、DNS リゾルバーは DNS を解決します。つまり、人間が判読できる URL を IP アドレスに変換します。 このモジュールには DNS スタブリゾルバーを実装するコードが含まれており、これをモジュールとして出荷することで、Google は DNS 傍受や構成更新攻撃に対するユーザー保護を強化できます。

ドキュメントUI

ドキュメント UI は、ドキュメントのアクセス許可を処理するコンポーネントの特定のファイルへのアクセスを制御するモジュールです。 Google が述べているように、ストレージへのアクセスと権限をモジュールにすると、エンド ユーザーのプライバシーとセキュリティが向上します。 ランタイム リソース オーバーレイ (RRO) 機能により、OEM は必要に応じてエクスペリエンス (ファイル アプリを参照) をテーマにすることができます。 に。 モジュールとして、すべての Google Android デバイスに同じドキュメント UI エクスペリエンスが付属します。

拡張サービス

このモジュールには、通知ランキング、自動入力テキスト マッチング戦略、ストレージ キャッシュ、パッケージ ウォッチドッグ、その他のサービスなどのコア OS 機能のフレームワーク コンポーネントが含まれています。

IPsec/IKEv2 ライブラリ

このライブラリ モジュールは、インターワーキング無線 LAN に関する新機能と既存の機能に関係します。 (IWLAN) および VPN (キー、アルゴリズム、トンネルなどのセキュリティ パラメーターのネゴシエーションなど) 構成。 これらの機能をモジュール化することの目的は、エコシステムの一貫性を促進し、セキュリティと相互運用性の問題を迅速に解決する方法を提供することです。

これらは 3 つの分岐したモジュールですが、相互に依存する機能を持っています。 これらのメディア モジュールは、メディア タイプとコードを処理し、ExoPlayer と対話し、トランスポート コントロールと再生情報をフレームワークに公開し、インデックス付きメタデータを最適化します。 覚えて Stagefright、Android を変えたエクスプロイト そして、プラットフォームに毎月のセキュリティ更新という概念そのものをもたらしたのでしょうか？ このエクスプロイトはメディア再生ライブラリ内の脆弱性に依存していました。 そのため、メディア コンポーネントをモジュール化することで、このターゲットにされることが多いコンポーネントでセキュリティ バグが見つかった場合に、Google が迅速かつ広範囲に対応できるようになります。

このモジュールの機能はその名前からすぐにわかりますが、その目的は明らかではありません。 モジュール メタデータ モジュールには、デバイス上のモジュールのリストに関するメタデータが含まれています。 それで終わりです。

ネットワーク スタック コンポーネント、ネットワーク スタック権限設定、キャプティブ ポータル ログイン

ネットワーク スタック コンポーネント モジュールは、一般的な IP サービス、ネットワーク接続の監視、キャプティブ ログイン ポータルの検出を提供します。 権限設定モジュールは、他のモジュールがネットワーク関連のタスクを実行できるようにする権限を定義します。 Captive Portal Login モジュールは、Captive Portal、つまり次の場合に表示される Web ページを扱います。 特定の公衆 Wi-Fi ネットワークに接続しており、ユーザーはインターネットにアクセスするために詳細を入力するよう求められます。 アクセス。

パーミッションコントローラー

このモジュールは、アクセス許可の付与と管理に関する更新可能なプライバシー ポリシーと UI 要素を提供します。 これが Package Installer の動作に見覚えがあると思われる場合、それは実際にそうなっているからです。 実行時の権限の付与、管理、使用状況の追跡などの機能は、Android 9 までのパッケージ インストーラー アプリの一部でした。 Android 10 では、パッケージ インストーラー アプリがセクションに分割され、アクセス許可ロジックを更新できるようになります。 Permission Controller モジュールは APK ファイルとして配信され、Android 11 では、モジュールは長期間使用されなかったアプリの実行時権限を自動的に取り消すことができます。

SDK拡張機能

このモジュールは理解するのが少し難しく、したがって説明するのが難しくなります。 すべての Android リリースには SDK レベルが割り当てられます (通常は、以前のバージョンから +1)。 アプリが特定の SDK をターゲットとする場合、開発者は Android リリースに伴うプラットフォームの動作と API の変更を考慮していると想定されます。

SDK 拡張モジュールは、デバイスの「拡張 SDK」レベルを決定し、アプリが拡張 SDK レベルをクエリするための API を公開します。 公式ドキュメントに記載されているのはこれだけです。 アルステクニカ、 ただし、言及 これは、Play ストアを通じて出荷されるセカンダリ API レイヤーである可能性が高いと考えられます。

Statsd、テレメトリ トレイン バージョン パッケージ

Statsd はデバイス メトリクスの収集を担当します。 一方、Telemetry Train バージョン パッケージには、アクティブなコードや独自の機能は含まれていません。 これには、Google によればメトリクス関連モジュールのセットである「Telemetry Train」のバージョン番号が含まれているだけです。 Google Play はバージョン番号に基づいてセキュリティ パッチのバージョンをエンド ユーザーに表示し、メトリクス関連モジュールのアップデートが利用可能かどうかを判断します。

テザリング

テザリング モジュールは、Wi-Fi、USB、Bluetooth、またはイーサネットを介して、デバイスのインターネット接続を接続されている他のクライアント デバイスと共有します。 このモジュールには、テザリング コンポーネントとその依存関係が含まれています。 このテザリング モジュールを使用することで、OEM は単一の標準リファレンス実装に依存し、デバイス間で一貫したエクスペリエンスを実現できます。

タイムゾーンデータ

タイム ゾーン データ モジュールは、Android デバイスの夏時間 (DST) とタイム ゾーンを更新し、両方のデータを標準化します。 宗教的、政治的、地政学的な理由やエコシステム全体の更新メカニズムに応じて、かなり頻繁に変更されます。 Android 8.1 と Android 9 では、APK ベースのタイムゾーン データ更新メカニズムが使用されていましたが、Android 10 では、APEX ベースのモジュール更新メカニズムに置き換えられました。 Google は、AOSP には APK ベースのアップデートに必要なプラットフォーム コードが引き続き含まれていると述べています。 Android 10 にアップグレードしたデバイスでも、パートナーが提供するタイムゾーン データの更新を、 APK。 ただし、Google は、APK ベースのアップデートが APEX ベースのアップデートに優先すると警告しています。

Wi-Fi

Wi-Fi機能用のモジュールです。 エンドユーザーは、Android デバイス間で一貫した Wi-Fi エクスペリエンスを得ることができるほか、モジュールのアップデートやアプリを通じて相互運用性の問題を修正できるようになりました。 開発者はプラットフォームの断片化を軽減でき、OEM はキャリアの要件を満たすと同時に、個別のコストも削減できます。 カスタマイズ。

---

この記事で、Google の Android エコシステムにとって Project Mainline がいかに重要であるかを理解していただければ幸いです。