Android の APEX Q: Project Treble 以来最大の出来事は何ですか?

APEX の実装は、おそらく Project Treble の導入以来、Google が直面してきた最大の悩みです。 APEX とは何ですか? その導入により Android はどう変わりますか?

APEX の背後にある考え方自体は、日常の GNU/Linux ディストリビューションではかなり一般的です。つまり、Linux ライブラリ セットの特定のセクションを対象としたパッケージの更新です。 しかし、Android がすべてのシステム ライブラリと フレームワークは、ほとんどの Linux ディストリビューションで使用される通常の RW (読み取り/書き込み) パーティションとは対照的に保存され、標準的なアップグレード プロセスをレンダリングします。 不適切です。

ライブラリは、他のプログラムで使用できるプリコンパイルされたコードです。 よく使用されるメソッドを Android アプリが呼び出すためのライブラリに作成できるため、複数のアプリにわたって同じコードを再実装する必要がなくなるため、APK のサイズが削減されます。 /system/lib および /system/lib64 ディレクトリには、プリインストールされたシステム ライブラリが多数あります。 Android システム ライブラリは通常、個別に更新されるのではなく、OTA アップデートを介して Android プラットフォームのアップグレードの一部として更新されます。 一方、Linux ディストリビューションのライブラリは個別に更新される場合があります。 APEXの導入により、AndroidのシステムライブラリもAndroidアプリと同様に個別に更新できるようになります。 この主な利点は、アプリ開発者が OEM による完全なシステム アップグレードの展開を待たずに、更新されたライブラリを利用できることです。 APEX の仕組みについて技術的に詳しく見てみましょう。

APEX はライブラリの更新方法をどのように変えるのでしょうか?

APEX は、Android が /system とは異なる非標準パーティションからすべてのライブラリとファイルをロードする方法を Google に再考させた（というより、強制しつつある）エコシステムです。

まず最初に、共有ライブラリと静的ライブラリの違いを指定する必要があります。 共有ライブラリは、それ自体で実行するために必要なコードがすべて含まれていないが、実際には他のライブラリに「リンク」されているライブラリ (通常は libkind.so という名前のファイル) です。 コードを提供するのに対し、静的ライブラリは、ご想像のとおり、他のライブラリに依存せず、すべてが静的に含まれるライブラリです。 ファイル。

Android はこれまで、ライブラリ パス (Linux の世界では LD_LIBRARY_PATH と呼ばれる) を単一のファイルで構成してきました。 ld.config.txt [0] を呼び出して、バイナリまたは別のバイナリで必要な共有ライブラリの許可された検索パスを構成します 図書館。 これらのパスは構成にハードコーディングされており、拡張できません。 読み取り専用のシステム パーティションを含むこのレイアウトでは、ユーザーが OTA Android アップデートをインストールしない限り、ライブラリを更新できなくなります。 Google はこの問題を修正し、単一の APEX パッケージに、パッケージに含まれる追加の (および更新された) ライブラリ パスを含む独自の ld.config.txt を提供できるようにすることで、検索パスを拡張できるようにしました。

この措置により主要な問題の 1 つは修正されましたが、克服すべき重大な問題がまだいくつか残っていました。 まず第一に、ABI (アプリケーション バイナリ インターフェイス) の安定性です。 ライブラリは、アップグレードされたライブラリでも他のアプリやライブラリが同じプロトコルで動作し続けることができるように、常に安定したインターフェイスのセットをエクスポートする必要があります。 Google は、APEX ライブラリ間で安定した C インターフェイスを作成することにより、これに積極的に取り組んでいます。

ただし、APEX はライブラリとバイナリだけに限定されません。 実際、これには構成ファイル、タイムゾーン更新、および一部の Java フレームワーク (執筆時点では conscrypt) が含まれる場合があります。

AOSP が提供する現在の APEX パッケージの例をいくつか示します。

• com.android.runtime: ART およびバイオニック ランタイム (バイナリとライブラリ)
• com.android.tzdata: TimeZone および ICU データ (ライブラリおよび構成データ)
• com.android.resolv: ネットワーク関連のリクエストを解決するために Android によって使用されるライブラリ (ライブラリ)
• com.android.conscrypt: Java セキュリティ プロバイダー (Java フレームワーク)

APEX パッケージはどのようにインストールされ、構成されますか?

APEX パッケージは、(開発のこの時点では) 便利な ADB によってインストールできる単純な zip アーカイブ (APK のような) です。 その後、ユーザー自身がパッケージ マネージャー (Google Play など) を介して、または Android パッケージを介して手動で インストーラ）。

ZIP レイアウトは次のとおりです。

それについて詳しく見ていきましょう。

apex_manifest.json はパッケージ名とバージョンを指定します。

apex_payload.img は、マイクロ ファイルシステム イメージ (EXT4 としてフォーマット) です。

他のファイルは、パッケージのインストールに使用される検証プロセスの一部です。 みてみましょう。

の存在 AndroidManifest.xmlたとえ主にアプリケーションで使用されているとしても、標準の APK インストールに使用される実装のほとんどがこれらのパッケージでも再利用されることを理解するのに役立ちます。 実際には、それらを区別するために拡張子のみがチェックされます。

の メタ-INF/ ディレクトリにはパッケージ証明書があり、通常の APK と同じメカニズムを使用します。 したがって、これらのパッケージは ユーザーがアップデートをインストールする前に、実行時に秘密キーと公開キーのペアによって検証されます。 しかし、Google にとってそれだけでは十分ではなかったため、さらに 2 層のセキュリティを追加しました。 dm-verity を使用してイメージの整合性をチェックし、AVB (Android Verified Boot) 検証を使用してイメージが信頼できるソースからのものであることを確認しています。 最悪の場合、APEX パッケージは拒否されます。

すべての検証手順が成功すると、イメージは有効としてマークされ、次回の再起動時にシステム バリアントを置き換えます。

起動時にイメージはどのようにインストールされますか?

まず、デバイス (エミュレーター) に現在インストールされている APEX を見てみましょう

ご覧のとおり、プリインストールされたパッケージは /system/apex/ に保存されており、現在はすべてバージョン番号 1 です。 しかし、APEX がアクティブ化されると何が起こるでしょうか? ここでも例として com.android.tzdata を使用します。

デバイスを再起動して、logcat を分析しましょう。

最初の 2 行は、パッケージの出所と配置先を理解するのに十分な情報を提供します。 インストール済み: /apex/、Android Q で導入された新しいディレクトリ。アクティブ化されたファイルを保存するために使用されます。 パッケージ。

パッケージが AVB で正常に検証され、公開キーが一致すると、ループ デバイスを使用して APEX が /dev/block/loop0 にマウントされ、システムから EXT4 ファイル システムにアクセスできるようになります。 ループデバイスは、ファイルをブロックデバイスとしてアクセスできるようにし、そのファイルの内容をマウントポイントとしてアクセスできるようにする疑似デバイスです。

この時点では、@1 サフィックス (パッケージのバージョンを示す) があるため、APEX はまだ使用されていません。 最終的にパッケージが正常にアクティベートされたことをシステムに知らせるために、パッケージは Android が tzdata が存在することを積極的に期待する /apex/com.android.tzdata にバインドマウントされます。 バインド マウントは、別のポイントにある既存のディレクトリまたはファイルをオーバーレイします。 [1]

APEX 実装は、AOSP の単一リポジトリに完全に含まれています。 [2] apexd (APEX デーモン) ディレクトリには、Android 上で実行されるコードが含まれています。 apexer ディレクトリには、ビルド システムが APEX パッケージを作成するために使用するコードが含まれています。

目的は何ですか?

現時点では、私にできることは推測することだけです。 私の最も推測するのは、Google が APEX パッケージのコアセットを作成しようとしており、それを Google が更新して作成できる可能性があるということです。 ベンダー間で共有される Android の統合ベースコアにより、「システム」のみのアップデートが可能になりますが、単一のパッケージを使用します 更新情報。

すべてのデバイスが APEX をサポートする予定ですか?

いいえ。たとえば、apexd では、すべての Android モジュールを更新するために、起動直後に /data/apex が使用可能になる必要があります。 FDE (フルディスク暗号化) を使用すると、ユーザーがデバイスのロックを解除するまで /data/apex が暗号化され、システムの APEX バリアントのみが起動時に読み込まれるため、APEX は基本的に役に立たなくなります。 それ以外では、すべてのデバイスが APEX をサポートしている必要がありますが、いくつかのカーネル パッチが必要です (その多くは、ループ デバイスを使用しているときに Google によって発見された修正です)。 [3] [4]

---

出典 [0], [1], [2], [3], [4]