Android 10 では、Android 8.1 と Android 9 で使用可能だった APK ベースでタイムゾーン データを更新するメカニズムのサポートが終了し、APEX ベースのモジュール更新メカニズムに置き換えられました。AOSP 8.1 から 13 には、OEM が APK ベースで更新するのに必要なプラットフォーム コードが引き続き含まれているため、Android 10 にアップグレードするデバイスでは、APK を通じてパートナーが提供するタイムゾーン データ更新を引き続き受信できます。ただし、APK ベースのアップデートは APEX ベースのアップデートよりも優先される（つまり、APK アップデートを受け取ったデバイスは APEX ベースのアップデートを無視する）ので、モジュールのアップデートも受け取る製品版デバイスでは、APK 更新メカニズムを使用すべきではありません。
タイムゾーン アップデート（Android 10 以降）
Android 10 以降でサポートされている Time Zone Data モジュールは、Android デバイスの夏時間（DST）とタイムゾーンを更新し、宗教的、政治的、地政学的な理由で頻繁に変更される可能性のあるデータを標準化します。
更新プロセスは次のとおりです。
- 1 か国以上の政府が自国のタイムゾーン ルールを変更したことに対応して、IANA がタイムゾーン データベースのアップデートをリリースします。
- Google または Android パートナーが、更新されたタイムゾーンを含む Time Zone Data モジュールのアップデート（APEX ファイル）を作成します。
- エンドユーザーのデバイスがアップデートをダウンロードし、再起動して変更を適用します。その後、デバイスのタイムゾーン データにアップデートの新しいタイムゾーン データが含まれます。
モジュールの詳細については、モジュラー システム コンポーネントをご覧ください。
タイムゾーン アップデート（Android 8.1～9）
注: APK ベースのタイムゾーン データ更新メカニズムは Android 14 以降では完全に削除されており、ソースコードに存在しません。パートナーは、Time Zone Mainline モジュールに完全に移行する必要があります。
Android 8.1 と Android 9 では、OEM が APK ベースのメカニズムを使用して、タイムゾーン ルールの更新済みデータをデバイスにプッシュできます。システム アップデートは不要です。このメカニズムにより、ユーザーはタイムリーなアップデートを受け取ることができ（これにより Android デバイスの耐用寿命が延びます）、Android パートナーはシステム イメージのアップデートとは関係なくタイムゾーンのアップデートをテストできます。
Android コアライブラリ チームは、ストック Android デバイスでタイムゾーン ルールを更新するために必要なデータファイルを提供します。OEM は、デバイスのタイムゾーン アップデートを作成する際、こうしたデータファイルを使用したり、必要に応じて独自のデータファイルを作成したりできます。いずれの場合でも、OEM は、サポートするデバイスにおけるタイムゾーン ルールのアップデートの品質保証、品質テスト、タイミング、リリースを引き続き管理します。
Android のタイムゾーンのソースコードとデータ
該当する機能を使用しない場合でも、ストック Android デバイスはすべて、タイムゾーン ルールデータを必要とします。/system パーティションにデフォルトのタイムゾーン ルールデータを一式含めて出荷する必要があります。このデータは、以下のような Android ソースツリーのライブラリ コードで使用されます。
libcore/のマネージコード（たとえばjava.util.TimeZone）はtzdataファイルとtzlookup.xmlファイルを使用します。bionic/のネイティブ ライブラリ コード（たとえばmktimeの場合、localtime システムコール）はtzdataファイルを使用します。external/icu/の ICU4J / ICU4C ライブラリ コードは icu.datファイルを使用します。
こうしたライブラリは、/data/misc/zoneinfo/current ディレクトリに存在する可能性のあるオーバーレイ ファイルを追跡します。オーバーレイ ファイルには改善されたタイムゾーン ルールデータが含まれていると想定されるので、/system を変更せずにデバイスを更新できます。
タイムゾーン ルールデータを必要とする Android システム コンポーネントは、まず以下のような場所を確認します。
libcore/とbionic/のコードはtzdataファイルとtzlookup.xmlファイルの/dataコピーを使用します。- ICU4J / ICU4C コードは
/dataのファイルを使用し、存在しないデータ（形式、ローカライズされた文字列など）については/systemファイルにフォールバックします。
distro ファイル
distro の .zip ファイルには、/data/misc/zoneinfo/current ディレクトリにデータを入力するのに必要なデータファイルが含まれています。distro ファイルには、デバイスでバージョニングの問題を検出できるようにするメタデータも含まれています。
distro ファイル形式は、ICU のバージョン、Android プラットフォームの要件、その他のリリースの変更によってコンテンツが変更されるため、Android リリースに依存します。Android は、プラットフォーム システム ファイルの更新だけでなく、IANA から更新があるたびに、サポートする Android リリースの distro ファイルを提供します。デバイスを最新の状態に保つために、OEM はこうした distro ファイルを使用できます。または、Android ソースツリー（distro ファイルの生成に必要なスクリプトとその他のファイルが含まれます）を使用して独自の distro ファイルを作成することもできます。
タイムゾーン アップデート コンポーネント
タイムゾーン ルールのアップデートには、デバイスに対する distro ファイルの転送と、その中に含まれるファイルの安全なインストールが含まれます。転送とインストールには以下が必要です。
- プラットフォーム サービス機能（
timezone.RulesManagerService）。デフォルトでは無効になっています。OEM は、構成を通じてこの機能を有効にする必要があります。RulesManagerServiceは、システム サーバー プロセスで実行され、/data/misc/zoneinfo/stagedに書き込むことでタイムゾーンの更新オペレーションをステージングします。RulesManagerServiceは、すでにステージングされているオペレーションを置換または削除することもできます。 -
TimeZoneUpdater。更新不可のシステムアプリ（別名「アップデータ アプリ」）です。OEM は、この機能を使用するデバイスのシステム イメージにこのアプリを含める必要があります。 - OEM
TimeZoneData。デバイスに distro ファイルを転送してアップデータ アプリで利用できるようにする、更新可能なシステムアプリ（別名「データアプリ」）です。OEM は、この機能を使用するデバイスのシステム イメージにこのアプリを含める必要があります。 tzdatacheck。タイムゾーンを正確かつ安全に更新するために必要な起動時のバイナリです。
Android ソースツリーには、上記のコンポーネントの汎用ソースコードが含まれており、OEM はそれらを変更なしで使用できます。OEM が機能を正しく有効にしたことを自動的に確認できるように、テストコードが提供されています。
distro のインストール
distro のインストール プロセスには次の手順プが含まれます。
- アプリストアでのダウンロードまたはサイドローディングでデータアプリが更新されます。システム サーバー プロセス（
timezone.RulesManagerServer/timezone.PackageTrackerクラスを使用）は、OEM 固有の構成済みデータアプリ パッケージ名に対する変更を監視します。
図 1. データアプリの更新
- 1 回限りの一意のトークンを使用してターゲット インテントをアップデータ アプリにブロードキャストすることで、システム サーバー プロセスが更新の確認をトリガーします。システム サーバーは、生成した最新のトークンをトラッキングして、トリガーした最新の確認がいつ完了したかを判別できます。他のトークンは無視されます。
図 2. 更新の確認をトリガーする
- 更新の確認中、アップデータ アプリは次のタスクを実行します。
- RulesManagerService を呼び出して、現在のデバイスの状態をクエリします。
図 3. データアプリの更新: RulesManagerService の呼び出し
- 適切に定義された ContentProvider URL と列の仕様をデータアプリにクエリして、distro に関する情報を取得します。
図 4. データアプリの更新: distro に関する情報の取得
- RulesManagerService を呼び出して、現在のデバイスの状態をクエリします。
- 自身が持っている情報に基づいて、アップデータ アプリが適切なアクションを実行します。以下のようなアクションが可能です。
- インストールをリクエストする。distro データがデータアプリから読み取られ、システム サーバーの RulesManagerService に渡されます。RulesManagerService は、distro 形式のバージョンとコンテンツがそのデバイスに適していることを再確認し、インストールをステージングします。
- アンインストールをリクエストする（まれなケース）。たとえば、
/dataの更新済みの APK が無効化またはアンインストール中で、デバイスが/systemにあるバージョンに戻る場合です。 - 何もしない。データアプリの distro が無効であることが検出されると発生します。
図 5. 確認の完了
- 再起動して tzdatacheck を実行します。デバイスが次に起動するとき、tzdatacheck バイナリはステージングされたオペレーションを実行します。tzdatacheck バイナリは、以下のタスクを行えます。
- 他のシステム コンポーネントがファイルを開いて使用を開始する前に、
/data/misc/zoneinfo/currentファイルの作成、置換、削除を処理することで、ステージングされたオペレーションを実行します。 /dataにあるファイルが現在のプラットフォーム バージョンに合っていることを確認します。デバイスがシステム アップデートを受け取ったばかりで、distro 形式のバージョンが変更されている場合は、該当しないことがあります。- IANA ルールのバージョンが
/systemと同じバージョンか、より新しいものであることを確認します。これにより、/systemイメージに存在するものより古いタイムゾーン ルールデータがデバイスに残るようなシステム アップデートから保護します。
- 他のシステム コンポーネントがファイルを開いて使用を開始する前に、
信頼性
エンドツーエンドのインストール プロセスは非同期であり、3 つの OS プロセスに分かれます。インストール中のどの時点でも、デバイスの電源が切れる、ディスク容量が不足する、または他の問題が発生することで、インストール チェックが不完全になることがあります。成功しなかった場合、アップデータ アプリは、失敗したことをシステム サーバーに通知しようとします。最悪の場合、RulesManagerService はまったく呼び出されません。
こうしたケースを扱うため、システム サーバーコードは、トリガーされた更新の確認が完了したかどうかと、データアプリの最後に確認されたバージョン コードが何であるかを追跡します。デバイスがアイドル状態で充電されているときに、システム サーバーコードは現在の状態を確認できます。更新の確認の未完了、または想定外のデータアプリ バージョンが検出された場合、更新の確認が自動的にトリガーされます。
セキュリティ
有効にすると、システム サーバーの RulesManagerService コードが複数のチェックを行って、システムを安全に使用できることを確認します。
- システム イメージが正しく設定されていないという問題（アップデータ アプリまたはデータアプリの設定が正しくない、あるいはアップデータ アプリまたはデータアプリが
/system/priv-appにないなど）があると、デバイスは起動しません。 - データアプリが正しくインストールされていないという問題（必要なシステム権限がない、または想定される URI でデータアプリが ContentProvider を公開していないなど）でデバイスが起動しなくなることはありませんが、更新の確認が行われません。
/data/misc/zoneinfo ディレクトリのファイル権限は、SELinux ルールを使用して適用されます。他の APK と同様に、データアプリは、/system/priv-app バージョンの署名に使用されるものと同じ鍵で署名される必要があります。データアプリには、OEM 固有の専用のパッケージ名と鍵が必要です。
タイムゾーン アップデートを統合する
OEM は通常、次のようにしてタイムゾーン アップデート機能を有効にします。
- 独自のデータアプリを作成する。
- アップデータ アプリとデータアプリをシステム イメージビルドに含める。
- RulesManagerService を有効にするようにシステム サーバーを構成する。
準備
はじめに、OEM は以下のポリシー、品質保証、セキュリティに関する考慮事項を確認する必要があります。
- データアプリ専用の、アプリ固有の署名鍵を作成する。
- タイムゾーン アップデートのリリースとバージョニングの戦略を作成し、どのデバイスを更新するか、またどのようにして必要なデバイスにのみアップデートをインストールするかを把握する。たとえば、OEM はすべてのデバイスに対して単一のデータアプリを使用する場合、またはデバイスごとに異なるデータアプリを使用する場合があります。この判断は、パッケージ名や QA 戦略の選択のほか、場合によって、使用するバージョン コードに影響します。
- AOSP のストック Android のタイムゾーン データを使用するか、独自のタイムゾーン データを作成するかを確認する。
データアプリを作成する
AOSP の packages/apps/TimeZoneData には、データアプリの作成に必要なソースコードとビルドルールがすべて含まれています。packages/apps/TimeZoneData/oem_template には、AndroidManifest.xml とその他のファイルに関する手順とテンプレート例があります。テンプレート例には、実際のデータアプリ APK のビルド ターゲットと、データアプリのテスト バージョンを作成するための追加ターゲットの両方が含まれます。
OEM は、独自のアイコン、名前、翻訳、その他の詳細情報を使用して、データアプリをカスタマイズできます。ただしデータアプリは起動できないため、アイコンは [設定] > [アプリ] 画面にのみ表示されます。
データアプリは、システム イメージに追加するのに適した APK を生成する tapas ビルドでビルドされ（初回リリースの場合）、署名され、アプリストアを通じて配布される（後続のアップデートの場合）ことが想定されています。tapas の使用方法の詳細については、tapas を使用したデータアプリのビルドをご覧ください。
OEM は、デバイスのシステム イメージにあらかじめ組み込まれているデータアプリを /system/priv-app にインストールする必要があります。ビルド済み APK（tapas ビルドプロセスで生成）をシステム イメージに含めるために、OEM は packages/apps/TimeZoneData/oem_template/data_app_prebuilt のサンプル ファイルをコピーできます。テンプレート例には、データアプリのテスト バージョンをテストスイートに含めるためのビルド ターゲットも含まれています。
システム イメージにアップデータ アプリとデータアプリを追加する
OEM は、アップデータ アプリとデータアプリの APK を、システム イメージの /system/priv-app ディレクトリに配置する必要があります。そのためには、アップデータ アプリとデータアプリのビルド済みターゲットを、システム イメージビルドに明示的に含める必要があります。
アップデータ アプリは、他のシステムアプリと同様に、プラットフォーム鍵で署名されて追加されている必要があります。ターゲットは packages/apps/TimeZoneUpdater で TimeZoneUpdater として定義されます。追加するデータアプリは OEM 固有であり、事前ビルドで選択したターゲット名に依存します。
システム サーバーを構成する
タイムゾーン アップデートを有効にするため、OEM は frameworks/base/core/res/res/values/config.xml で定義された構成プロパティをオーバーライドしてシステム サーバーを構成します。
| プロパティ | 説明 | オーバーライドは必須か？ |
|---|---|---|
config_enableUpdateableTimeZoneRules |
true に設定して RulesManagerService を有効にする必要があります。 |
○ |
config_timeZoneRulesUpdateTrackingEnabled |
true に設定してシステムにデータアプリの変更をリッスンさせる必要があります。 |
○ |
config_timeZoneRulesDataPackage |
OEM 固有のデータアプリのパッケージ名。 | ○ |
config_timeZoneRulesUpdaterPackage |
デフォルトのアップデータ アプリ用に設定されています。別のアップデータ アプリ実装を提供する場合にのみ変更します。 | × |
config_timeZoneRulesCheckTimeMillisAllowed |
RulesManagerService によってトリガーされている更新の確認と、インストール、アンイストール、または何もしないレスポンスとの間に許容される時間。この時点の後、自発的な信頼性トリガーが生成されることがあります。 | × |
config_timeZoneRulesCheckRetryCount |
RulesManagerService がそれ以上の生成を停止するまでに許容される、連続して失敗した更新の確認の数。 | × |
誤って設定されたデバイスは起動を拒否する可能性があるため、設定のオーバーライドは（ベンダー イメージなどではなく）システム イメージに含める必要があります。設定のオーバーライドがベンダー イメージにある場合、データアプリのない（またはデータアプリ / アップデータ アプリのパッケージ名が異なる）システム イメージへの更新は誤った設定と見なされます。
xTS テスト
xTS とは、Tradefed を使用する標準の Android テストスイート（CTS や VTS など）に似た OEM 固有のテストスイートのことです。このようなテストスイートがある OEM は、以下の場所にある Android タイムゾーン更新テストを追加できます。
packages/apps/TimeZoneData/testing/xts。基本的な自動機能テストに必要なコードが含まれています。packages/apps/TimeZoneData/oem_template/xts。Tradefed のような xTS スイートにテストを含めるためのサンプル ディレクトリ構造が含まれています。他のテンプレート ディレクトリと同様に、OEM は必要に応じてコピーし、カスタマイズします。packages/apps/TimeZoneData/oem_template/data_app_prebuilt。テストに必要なビルド済みテスト APK を含めるためのビルド時設定が含まれています。
タイムゾーン アップデートを作成する
IANA がタイムゾーン ルールの新しいセットをリリースすると、Android コアライブラリ チームは AOSP でリリースを更新するためのパッチを生成します。ストック Android システムと distro ファイルを使用している OEM は、これらのコミットを選択し、それを使用してデータアプリの新しいバージョンを作成した後、リリースして製品版のデバイスを更新できます。
データアプリには Android バージョンと密接に関連する distro ファイルが含まれるため、OEM は、更新するデータアプリの新しいバージョンを、サポート対象の Android リリースごとに作成する必要があります。たとえば、OEM が Android 8.1、9、10 のデバイスにアップデートを提供する場合、プロセスを 3 回実施する必要があります。
ステップ 1: system/timezone と external/icu のデータファイルの更新
このステップでは、OEM は AOSP の release-dev ブランチから system/timezone と external/icu のストック Android コミットを取得して、Android ソースコードのコピーに適用します。
system/timezone AOSP パッチには、system/timezone/input_data と system/timezone/output_data の更新済みファイルが含まれます。追加のローカル修正を行う必要がある OEM は、入力ファイルを変更してから、system/timezone/input_data と external/icu にあるファイルを使用して output_data にファイルを生成できます。
最も重要なファイルは system/timezone/output_data/distro/distro.zip であり、これはデータアプリ APK のビルド時に自動的に追加されます。
ステップ 2: データアプリのバージョン コードの更新
このステップでは、OEM はデータアプリのバージョン コードを更新します。ビルドが distro.zip を自動的に選択しますが、新しいバージョンのデータアプリには新しいバージョン コードが必要です。新しいデータアプリはそれによって新しいアプリとして認識され、プリロードされたデータアプリまたは以前のアップデートでデバイスにインストールされたデータアプリを置き換えるために使用されます。
package/apps/TimeZoneData/oem_template/data_app からコピーしたファイルを使用してデータアプリをビルドする場合、APK に適用されるバージョン コード、バージョン名は Android.mk にあります。
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
同様のエントリは testing/Android.mk にもあります（ただし、テスト バージョン コードはシステム イメージ バージョンより後のものである必要があります）。詳細については、バージョン コード戦略スキームの例をご覧ください。このスキームの例または同様のスキームが使用されている場合、テスト バージョン コードは実際のバージョン コードより後のものであることが保証されるため、更新する必要はありません。
ステップ 3: 再ビルド、署名、テスト、リリース
このステップでは、OEM は tapas を使用して APK を再ビルドし、生成された APK に署名してから、APK をテストしてリリースします。
- リリースされていないデバイスの場合（またはリリース済みデバイスのシステム アップデートを準備する場合）、データアプリのビルド済みディレクトリに新しい APK を送信して、システム イメージと xTS テストの APK を最新版にします。OEM は、新しいファイルが正常に動作することをテストする（つまり、CTS と OEM 固有の自動テストと手動テストに合格する）必要があります。
- システム アップデートを受け取らなくなったリリース済みデバイスの場合、署名された APK はアプリストア経由でのみリリースされる可能性があります。
OEM は、品質保証を行い、リリース前にデバイス上で更新対象のデータアプリをテストする責任があります。
データアプリのバージョン コード戦略
デバイスが正しい APK を受け取るようにするには、データアプリに適切なバージョニング戦略が必要です。たとえば、アプリストアからダウンロードした APK より古い APK を含むシステム アップデートを受け取った場合、アプリストアのバージョンを保持する必要があります。
APK バージョン コードには、以下の情報を含める必要があります。
- distro 形式のバージョン（メジャー + マイナー）
- 増分（不透明）バージョン番号
現在のところ、プラットフォームの API レベルは distro 形式のバージョンと強い相関があります。これは、各 API レベルが通常、ICU の新しいバージョンと関連付けられるためです（そのため、distro ファイルに互換性がありません）。今後、Android はこれを変更して、1 つの distro ファイルが複数の Android プラットフォーム リリースで機能するようになる可能性があります（データアプリのバージョン コードスキームで API レベルは使用されません）。
バージョン コード戦略の例
このバージョニング番号スキームの例では、上位バージョンの distro 形式が下位バージョンの distro 形式よりも優先されます。AndroidManifest.xml は、android:minSdkVersion を使用して、古いデバイスが処理できるバージョンよりも上位バージョンの distro 形式でバージョンを受け取らないようにします。
図 6. バージョン コード戦略の例
| 例 | 値 | 目的 |
|---|---|---|
| Y | 予約済み | 今後の代替スキーム / テスト APK を可能にします。初期値は（暗黙的に）0 です。基になる型は符号付き 32 ビット int 型であるため、このスキームは今後、番号付けスキームのリビジョンを 2 つまでサポートします。 |
| 01 | メジャー形式バージョン | 10 進 3 桁のメジャー形式バージョンを記録します。distro 形式は 10 進 3 桁をサポートしていますが、ここでは 2 桁しか使用しません。API レベルごとに予想されるメジャー インクリメントが 100 に達する可能性はほとんどありません。メジャー バージョン 1 は API レベル 27 に相当します。 |
| 1 | マイナー形式バージョン | 10 進 3 桁のマイナー形式バージョンを記録します。distro 形式は 10 進 3 桁をサポートしていますが、ここでは 1 桁しか使用しません。10 に達する可能性はほとんどありません。 |
| X | 予約済み | 製品版リリースでは 0 です（テスト用の APK では異なる場合があります）。 |
| ZZZZZ | 不透明なバージョン番号 | オンデマンドで割り当てられる 10 進数。必要に応じてインタースティシャル アップデートを可能にするためのギャップが含まれます。 |
10 進数ではなく 2 進数を使用したほうがより効率よく詰められますが、このスキームには、人が読めるという利点があります。範囲内の番号をすべて使い果たすと、データアプリのパッケージ名が変更されることがあります。
バージョン名は major=001,minor=001,iana=2017a, revision=1,respin=2 のように、詳細を人が読める形式で表します。次の表に例を示します。
| No. | バージョン コード | minSdkVersion | {メジャー形式バージョン},{マイナー形式バージョン},{IANA ルール バージョン},{リビジョン} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a,revision=1 |
| 2 | 21000010 | P | major=002,minor=001,iana=2017a,revision=1 |
| 3 | 11000020 | O-MR1 | major=001,minor=001,iana=2017a,revision=2 |
| 4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a,revision=1 |
| 7 | 21000030 | P | major=002,minor=001,iana=2018a,revision=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | major=001,minor=001,iana=2017a,revision=2,respin=2 |
- 例 1 と例 2 は、同じ 2017a IANA リリースに対する、メジャー形式バージョンの異なる 2 つの APK バージョンを示しています。例 2 は数値的に例 1 よりも大きく、これは、新しいほうのデバイスが上位の形式バージョンを受け取るようにするために必要です。minSdkVersion は、P バージョンが O デバイスに供給されないようにします。
- 例 3 は例 1 のリビジョン / 修正で、数値的に例 1 より大きくなっています。
- 例 4 と例 5 は、O-MR1 と P の 2017b リリースを示しています。数値が大きくなっており、以前の IANA リリース / Android リビジョンをそれぞれ置き換えています。
- 例 6 と例 7 は、O-MR1 と P の 2018a リリースを示しています。
- 例 8 は、Y=0 スキームを完全に置き換えるための Y の使用方法を示しています。
- 例 9 は、3 と 4 の間のギャップを利用して APK を再スピンする方法を示しています。
各デバイスで適切なバージョンの APK がシステム イメージにデフォルトで組み込まれて出荷される際、O-MR1 バージョンは P システム イメージ バージョンよりもバージョン番号が下位なので、P デバイスにインストールされるリスクはありません。/data に O-MR1 バージョンがインストールされているデバイスが P へのシステム アップデートを受け取ると、 /data の O-MR1 バージョンより優先して /system のバージョンが使用されます。これは、P バージョンが常に O-MR1 向けのどのアプリよりも上位であるためです。
tapas を使用してデータアプリをビルドする
OEM には、タイムゾーン データアプリのほとんどの要素を管理し、システム イメージを正しく構成する責任があります。データアプリは、システム イメージに追加するのに適した APK を生成する tapas ビルドでビルドされ（初回リリースの場合）、署名され、アプリストアを通じて配布される（後続のアップデートの場合）ことが想定されています。
tapas は Android ビルドシステムの軽量バージョンであり、縮小されたソースツリーを使用してアプリの配布可能バージョンを生成します。通常の Android ビルドシステムに精通している OEM は、通常の Android プラットフォーム ビルドに含まれるビルドファイルを認識しているはずです。
マニフェストを作成する
通常、ソースツリーの縮小は、ビルドシステムおよびアプリのビルドに必要な Git プロジェクトのみを参照するカスタム マニフェスト ファイルによって行われます。OEM は、データアプリを作成する手順を実施した後、packages/apps/TimeZoneData/oem_template にあるテンプレート ファイルを使用して、OEM 固有の Git プロジェクトを 2 つ以上作成する必要があります。
- 一方の Git プロジェクトには、アプリ APK ファイルの作成に必要なマニフェストやビルドファイルなどのアプリファイルを含めます（例:
vendor/oem/apps/TimeZoneData）。このプロジェクトには、xTS テストで使用できるテスト APK のビルドルールも含めます。 - もう一つの Git プロジェクトには、システム イメージビルドと xTS テストに含めるためにアプリビルドによって生成された、署名済み APK を含めます。
アプリビルドは、プラットフォーム ビルドと共有される、または OEM に依存しないコード ライブラリが含まれる、他の複数の Git プロジェクトを活用します。
次に示すマニフェスト スニペットには、タイムゾーン データアプリの O-MR1 ビルドをサポートするために必要な Git プロジェクトの最小セットが含まれています。OEM は、このマニフェストに OEM 固有の Git プロジェクト（通常これには署名証明書を含むプロジェクトを含めます）を追加する必要があり、それに応じて別のブランチを構成できます。
<!-- Tapas Build -->
<project
path="build"
name="platform/build">
<copyfile src="core/root.mk" dest="Makefile" />
</project>
<project
path="prebuilts/build-tools"
name="platform/prebuilts/build-tools"
clone-depth="1" />
<project
path="prebuilts/go/linux-x86"
name="platform/prebuilts/go/linux-x86"
clone-depth="1" />
<project
path="build/blueprint"
name="platform/build/blueprint" />
<project
path="build/kati"
name="platform/build/kati" />
<project
path="build/soong"
name="platform/build/soong">
<linkfile src="root.bp" dest="Android.bp" />
<linkfile src="bootstrap.bash" dest="bootstrap.bash" />
</project>
<!-- SDK for system / public API stubs -->
<project
path="prebuilts/sdk"
name="platform/prebuilts/sdk"
clone-depth="1" />
<!-- App source -->
<project
path="system/timezone"
name="platform/system/timezone" />
<project
path="packages/apps/TimeZoneData"
name="platform/packages/apps/TimeZoneData" />
<!-- Enable repohooks -->
<project
path="tools/repohooks"
name="platform/tools/repohooks"
revision="main"
clone_depth="1" />
<repo-hooks
in-project="platform/tools/repohooks"
enabled-list="pre-upload" />
tapas ビルドを実行する
ソースツリーが確立されたら、次のコマンドを使用して tapas ビルドを呼び出します。
source build/envsetup.shtapasmake -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
正常にビルドされると、out/dist ディレクトリにテスト用のファイルが生成されます。これらのファイルは、システム イメージに含めるために prebuilts ディレクトリに配置したり、互換性のあるデバイス用にアプリストアを介して配布したりできます。