Aturan zona waktu

Android 10 menghentikan penggunaan mekanisme update data zona waktu berbasis APK (tersedia di Android 8.1 dan Android 9) dan menggantinya dengan mekanisme update modul berbasis APEX. AOSP 8.1 hingga 13 masih menyertakan kode platform yang diperlukan OEM untuk mengaktifkan update berbasis APK, sehingga perangkat yang diupgrade ke Android 10 masih dapat menerima update data zona waktu yang disediakan partner melalui APK. Namun, mekanisme update APK tidak boleh digunakan di perangkat produksi yang juga menerima update modul karena update berbasis APK menggantikan update berbasis APEX (yaitu, perangkat yang menerima update APK akan mengabaikan update berbasis APEX).

Pembaruan zona waktu (Android 10 dan yang lebih tinggi)

Modul Data Zona Waktu yang didukung di Android 10 dan yang lebih tinggi memperbarui waktu musim panas (DST) dan zona waktu di perangkat Android, menyeragamkan data yang dapat sering berubah karena alasan agama, politik, dan geopolitik.

Update menggunakan proses berikut:

1. IANA merilis update pada Database Zona Waktu sebagai respons terhadap satu atau beberapa pemerintah yang mengubah aturan zona waktu di negara mereka.
2. Google atau partner Android menyiapkan update modul Data Zona Waktu (file APEX) yang berisi zona waktu yang diperbarui.
3. Perangkat pengguna akhir mendownload update, melakukan booting ulang, lalu menerapkan perubahan, setelah itu data zona waktu perangkat berisi data zona waktu baru dari update.

Untuk mengetahui detail tentang modul, lihat Komponen Sistem Modular.

Update zona waktu (Android 8.1–9)

Catatan: Fitur mekanisme update data zona waktu berbasis APK telah dihapus sepenuhnya dari Android 14 dan seterusnya, serta tidak dapat ditemukan di kode sumber. Partner harus sepenuhnya bermigrasi ke modul utama Zona Waktu.

Di Android 8.1 dan Android 9, OEM dapat menggunakan mekanisme berbasis APK untuk mengirimkan data aturan zona waktu yang telah diupdate ke perangkat tanpa memerlukan update sistem. Mekanisme ini memungkinkan pengguna menerima update tepat waktu (sehingga memperpanjang masa pakai perangkat Android) dan memungkinkan partner Android menguji update zona waktu secara terpisah dari update image sistem.

Tim library inti Android menyediakan file data yang diperlukan untuk memperbarui aturan zona waktu di perangkat Android standar. OEM dapat memilih untuk menggunakan file data ini saat membuat update zona waktu untuk perangkat mereka atau dapat membuat file data mereka sendiri jika diinginkan. Dalam semua kasus, OEM mempertahankan kontrol atas jaminan/pengujian kualitas, waktu, dan peluncuran update aturan zona waktu untuk perangkat yang didukungnya.

Kode sumber dan data zona waktu Android

Semua perangkat Android standar, bahkan yang tidak menggunakan fitur ini, memerlukan data aturan zona waktu dan harus dikirim dengan set data aturan zona waktu default di partisi /system. Data ini kemudian digunakan oleh kode dari library berikut di hierarki sumber Android:

• Kode terkelola dari libcore/ (misalnya, java.util.TimeZone) menggunakan file tzdata dan tzlookup.xml.
• Kode library native di bionic/ (misalnya, untuk mktime, panggilan sistem localtime) menggunakan file tzdata.
• Kode library ICU4J/ICU4C di external/icu/ menggunakan file icu .dat.

Library ini melacak file overlay yang mungkin ada di direktori /data/misc/zoneinfo/current. File overlay diharapkan berisi data aturan zona waktu yang lebih baik, sehingga memungkinkan perangkat diupdate tanpa mengubah /system.

Komponen sistem Android yang memerlukan data aturan zona waktu akan memeriksa lokasi berikut terlebih dahulu:

• Kode libcore/ dan bionic/ menggunakan salinan /data dari file tzdata dan tzlookup.xml.
• Kode ICU4J/ICU4C menggunakan file di /data dan melakukan penggantian ke file /system untuk data yang tidak ada (untuk format, string yang dilokalkan, dll.).

File distro

File distro .zip berisi file data yang diperlukan untuk mengisi direktori /data/misc/zoneinfo/current. File distro juga berisi metadata yang memungkinkan perangkat mendeteksi masalah pembuatan versi.

Format file distro bergantung pada rilis Android karena kontennya berubah sesuai dengan versi ICU, persyaratan platform Android, dan perubahan rilis lainnya. Android menyediakan file distro untuk rilis Android yang didukung untuk setiap update IANA (selain mengupdate file sistem platform). Untuk menjaga agar perangkat mereka tetap terupdate, OEM dapat menggunakan file distro ini atau membuat file distro mereka sendiri menggunakan hierarki sumber Android (yang berisi skrip dan file lain yang diperlukan untuk membuat file distro).

Komponen update zona waktu

Update aturan zona waktu melibatkan transmisi file distro ke perangkat dan penginstalan file yang aman di dalamnya. Transfer dan penginstalan memerlukan hal berikut:

• Fungsi layanan platform (timezone.RulesManagerService), yang dinonaktifkan secara default. OEM harus mengaktifkan fungsi melalui konfigurasi. RulesManagerService berjalan dalam proses server sistem dan melakukan penahapan operasi update zona waktu dengan menulis ke /data/misc/zoneinfo/staged. RulesManagerService juga dapat mengganti atau menghapus operasi yang sudah dipentaskan.
• TimeZoneUpdater, aplikasi sistem yang tidak dapat diupdate (alias aplikasi Updater). OEM harus menyertakan aplikasi ini dalam image sistem perangkat yang menggunakan fitur ini.
• OEM TimeZoneData, aplikasi sistem yang dapat diupdate (alias aplikasi Data) yang membawa file distribusi ke perangkat dan membuatnya tersedia untuk aplikasi Updater. OEM harus menyertakan aplikasi ini dalam image sistem perangkat yang menggunakan fitur ini.
• tzdatacheck, biner waktu booting yang diperlukan untuk pengoperasian update zona waktu yang benar dan aman.

Hierarki sumber Android berisi kode sumber generik untuk komponen di atas, yang dapat dipilih oleh OEM untuk digunakan tanpa modifikasi. Kode pengujian disediakan agar OEM dapat memeriksa secara otomatis bahwa mereka telah mengaktifkan fitur dengan benar.

Penginstalan distro

Proses penginstalan distro mencakup langkah-langkah berikut:

1. Aplikasi data diperbarui melalui download atau sideload app store. Proses server sistem (melalui kelas timezone.RulesManagerServer/timezone.PackageTracker) memantau perubahan pada nama paket aplikasi Data khusus OEM yang dikonfigurasi.
   
   

   Gambar 1. Pembaruan aplikasi Data.

2. Proses server sistem memicu pemeriksaan update dengan menyiarkan intent bertarget dengan token sekali pakai yang unik ke Aplikasi Updater. Server sistem melacak token terbaru yang dibuatnya sehingga dapat menentukan kapan pemeriksaan terbaru yang dipicunya telah selesai; token lainnya diabaikan.
   
   

   Gambar 2. Memicu pemeriksaan update.

3. Selama pemeriksaan update, aplikasi Updater melakukan tugas berikut:
   • Mengirim kueri status perangkat saat ini dengan memanggil RulesManagerService.
     
     

     Gambar 3. Aplikasi data diperbarui, memanggil RulesManagerService.

   • Mengirim kueri ke aplikasi Data dengan mengirim kueri ke URL ContentProvider yang ditentukan dengan baik dan spesifikasi kolom untuk mendapatkan informasi tentang distro.
     
     

     Gambar 4. Update aplikasi Data, dapatkan info tentang distro.

4. Aplikasi Updater mengambil tindakan yang sesuai berdasarkan informasi yang dimilikinya. Tindakan yang tersedia meliputi:
   • Minta penginstalan. Data distro dibaca dari aplikasi Data dan diteruskan ke RulesManagerService di server sistem. RulesManagerService mengonfirmasi ulang bahwa versi dan konten format distro sesuai untuk perangkat dan melakukan penyiapan penginstalan.
   • Meminta penginstalan (hal ini jarang terjadi). Misalnya, jika APK yang diupdate di /data dinonaktifkan atau di-uninstal dan perangkat kembali ke versi yang ada di /system.
   • Tidak melakukan apa pun. Terjadi saat distro aplikasi Data ditemukan tidak valid.
   Dalam semua kasus, aplikasi Updater memanggil RulesManagerService dengan token pemeriksaan sehingga server sistem mengetahui bahwa pemeriksaan telah selesai dan berhasil.
   
   

   Gambar 5. Pemeriksaan selesai.

5. Mulai ulang dan tzdatacheck. Saat perangkat melakukan booting berikutnya, biner tzdatacheck akan menjalankan operasi bertahap. Biner tzdatacheck dapat melakukan tugas berikut:
   • Jalankan operasi bertahap dengan menangani pembuatan, penggantian, dan/atau penghapusan file /data/misc/zoneinfo/current sebelum komponen sistem lain membuka dan mulai menggunakan file.
   • Pastikan file di /data sudah benar untuk versi platform saat ini, yang mungkin tidak benar jika perangkat baru saja menerima update sistem dan versi format distro telah berubah.
   • Pastikan versi aturan IANA sama atau lebih baru dari versi di /system. Hal ini melindungi dari update sistem yang membuat perangkat memiliki data aturan zona waktu yang lebih lama daripada yang ada dalam image /system.

Keandalan

Proses penginstalan end-to-end bersifat asinkron dan dibagi di tiga proses OS. Kapan saja selama penginstalan, perangkat dapat kehilangan daya, kehabisan ruang disk, atau mengalami masalah lain, sehingga pemeriksaan penginstalan tidak selesai. Dalam kasus tidak berhasil terbaik, aplikasi Updater memberi tahu server sistem bahwa pembaruan tidak berhasil; dalam kasus tidak berhasil terburuk, RulesManagerService tidak menerima panggilan sama sekali.

Untuk menanganinya, kode server sistem melacak apakah pemeriksaan update yang dipicu telah selesai dan kode versi terakhir yang diperiksa dari Aplikasi Data. Saat perangkat dalam kondisi tidak digunakan dan sedang diisi dayanya, kode server sistem dapat memeriksa status saat ini. Jika menemukan pemeriksaan update yang tidak lengkap atau versi Aplikasi Data yang tidak terduga, aplikasi akan secara spontan memicu pemeriksaan update.

Keamanan

Jika diaktifkan, kode RulesManagerService di server sistem akan melakukan beberapa pemeriksaan untuk memastikan sistem aman digunakan.

• Masalah yang menunjukkan image sistem yang dikonfigurasi dengan buruk mencegah perangkat melakukan booting; contohnya mencakup konfigurasi aplikasi Updater atau Data yang buruk atau aplikasi Updater atau Data tidak dalam /system/priv-app.
• Masalah yang menunjukkan bahwa aplikasi Data yang buruk telah diinstal tidak mencegah perangkat melakukan booting, tetapi mencegah pemeriksaan update dipicu; contohnya termasuk kurangnya izin sistem yang diperlukan atau aplikasi Data tidak mengekspos ContentProvider pada URI yang diharapkan.

Izin file untuk direktori /data/misc/zoneinfo diterapkan menggunakan aturan SELinux. Seperti APK lainnya, aplikasi Data harus ditandatangani dengan kunci yang sama dengan yang digunakan untuk menandatangani versi /system/priv-app. Aplikasi Data diharapkan memiliki nama paket dan kunci khusus OEM.

Mengintegrasikan pembaruan zona waktu

Untuk mengaktifkan fitur update zona waktu, OEM biasanya:

• Membuat aplikasi Data mereka sendiri.
• Sertakan aplikasi Updater dan Data dalam build image sistem.
• Konfigurasi server sistem untuk mengaktifkan RulesManagerService.

Persiapan

Sebelum memulai, OEM harus meninjau kebijakan, jaminan kualitas, dan pertimbangan keamanan berikut:

• Membuat kunci penandatanganan khusus aplikasi untuk aplikasi Data mereka.
• Buat strategi rilis dan pembuatan versi untuk update zona waktu guna memahami perangkat mana yang akan diupdate dan cara memastikan bahwa update hanya diinstal di perangkat yang memerlukannya. Misalnya, OEM mungkin ingin memiliki satu aplikasi Data untuk semua perangkatnya atau memilih untuk memiliki aplikasi Data yang berbeda untuk perangkat yang berbeda. Keputusan ini memengaruhi pilihan nama paket, kemungkinan kode versi yang digunakan, dan strategi QA.
• Pahami apakah mereka ingin menggunakan data zona waktu Android standar dari AOSP atau membuat data zona waktu mereka sendiri.

Membuat aplikasi Data

AOSP mencakup semua kode sumber dan aturan build yang diperlukan untuk membuat aplikasi Data di packages/apps/TimeZoneData, dengan petunjuk dan contoh template untuk AndroidManifest.xml dan file lain yang ada di packages/apps/TimeZoneData/oem_template. Contoh template mencakup target build untuk APK aplikasi Data yang sebenarnya dan target tambahan untuk membuat versi pengujian aplikasi Data.

OEM dapat menyesuaikan aplikasi Data dengan ikon, nama, terjemahan, dan detail lainnya. Namun, karena aplikasi Data tidak dapat diluncurkan, ikon hanya muncul di layar Setelan > Aplikasi.

Aplikasi Data dimaksudkan untuk dibangun dengan build tapas yang menghasilkan APK yang sesuai untuk ditambahkan ke image sistem (untuk rilis awal) serta ditandatangani dan didistribusikan melalui app store (untuk update berikutnya). Untuk mengetahui detail tentang penggunaan tapas, lihat Membangun aplikasi Data menggunakan tapas.

OEM harus menginstal aplikasi Data yang telah dibuat sebelumnya di image sistem perangkat di /system/priv-app. Untuk menyertakan APK bawaan (yang dihasilkan oleh proses build tapas) dalam image sistem, OEM dapat menyalin file contoh di packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Template contoh juga menyertakan target build untuk menyertakan versi pengujian aplikasi Data dalam rangkaian pengujian.

Sertakan aplikasi Updater dan Data dalam image sistem

OEM harus menempatkan APK aplikasi Updater dan Data di direktori /system/priv-app image sistem. Untuk melakukannya, build image sistem harus secara eksplisit menyertakan target yang telah dibuat sebelumnya untuk aplikasi Updater dan aplikasi Data.

Aplikasi Updater harus ditandatangani dengan kunci platform dan disertakan seperti aplikasi sistem lainnya. Target ditentukan dalam packages/apps/TimeZoneUpdater sebagai TimeZoneUpdater. Pencantuman aplikasi Data khusus OEM dan bergantung pada nama target yang dipilih untuk pra-build.

Mengonfigurasi server sistem

Untuk mengaktifkan update zona waktu, OEM dapat mengonfigurasi server sistem dengan mengganti properti konfigurasi yang ditentukan dalam frameworks/base/core/res/res/values/config.xml.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Penggantian konfigurasi harus ada di image sistem (bukan vendor atau lainnya) karena perangkat yang salah konfigurasi dapat menolak untuk melakukan booting. Jika penggantian konfigurasi ada di image vendor, mengupdate ke image sistem tanpa aplikasi Data (atau dengan nama paket aplikasi Data/Updater yang berbeda) akan dianggap sebagai kesalahan konfigurasi.

Pengujian xTS

xTS mengacu pada rangkaian pengujian khusus OEM yang serupa dengan rangkaian pengujian Android standar menggunakan Tradefed (seperti CTS dan VTS). OEM yang memiliki rangkaian pengujian tersebut dapat menambahkan pengujian update zona waktu Android yang disediakan di lokasi berikut:

• packages/apps/TimeZoneData/testing/xts menyertakan kode yang diperlukan untuk pengujian fungsional otomatis dasar.
• packages/apps/TimeZoneData/oem_template/xts berisi contoh struktur direktori untuk menyertakan pengujian dalam rangkaian xTS seperti Tradefed. Seperti direktori template lainnya, OEM diharapkan menyalin dan menyesuaikan dengan kebutuhan mereka.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt berisi konfigurasi waktu build untuk menyertakan APK pengujian bawaan yang diperlukan oleh pengujian.

Membuat pembaruan zona waktu

Saat IANA merilis serangkaian aturan zona waktu baru, tim library inti Android membuat patch untuk mengupdate rilis di AOSP. OEM yang menggunakan sistem Android standar dan file distro dapat mengambil commit ini, menggunakannya untuk membuat versi baru aplikasi Data mereka, lalu merilis versi baru untuk mengupdate perangkat mereka dalam produksi.

Karena aplikasi Data berisi file distro yang terkait erat dengan versi Android, OEM harus membuat versi baru aplikasi Data untuk setiap rilis Android yang didukung yang ingin diupdate oleh OEM. Misalnya, jika OEM ingin menyediakan update untuk perangkat Android 8.1, 9, dan 10, mereka harus menyelesaikan prosesnya tiga kali.

Langkah 1: Perbarui file data sistem/zona waktu dan eksternal/icu

Pada langkah ini, OEM mengambil commit Android standar untuk system/timezone dan external/icu dari cabang release-dev di AOSP dan menerapkan commit tersebut ke salinan kode sumber Android mereka.

Patch AOSP sistem/zona waktu berisi file yang diperbarui di system/timezone/input_data dan system/timezone/output_data. OEM yang perlu melakukan perbaikan lokal tambahan dapat mengubah file input, lalu menggunakan file tersebut di system/timezone/input_data dan external/icu untuk membuat file di output_data.

File yang paling penting adalah system/timezone/output_data/distro/distro.zip, yang otomatis disertakan saat APK aplikasi Data dibuat.

Langkah 2: Perbarui kode versi aplikasi Data

Pada langkah ini, OEM mengupdate kode versi aplikasi Data. Build akan otomatis mengambil distro.zip, tetapi aplikasi Data versi baru harus memiliki kode versi baru agar dikenali sebagai baru dan digunakan untuk menggantikan aplikasi Data pramuat atau aplikasi Data yang diinstal di perangkat oleh update sebelumnya.

Saat mem-build aplikasi Data menggunakan file yang disalin dari package/apps/TimeZoneData/oem_template/data_app, Anda dapat menemukan kode versi/nama versi yang diterapkan ke APK di Android.mk:

TIME_ZONE_DATA_APP_VERSION_CODE :=
TIME_ZONE_DATA_APP_VERSION_NAME :=

Entri serupa dapat ditemukan di testing/Android.mk (namun, kode versi pengujian harus lebih tinggi daripada versi image sistem). Untuk mengetahui detailnya, lihat skema strategi kode versi contoh; jika skema contoh atau skema serupa digunakan, kode versi pengujian tidak perlu diupdate karena dijamin lebih tinggi daripada kode versi sebenarnya.

Langkah 3: Bangun ulang, tanda tangani, uji, dan rilis

Pada langkah ini, OEM membangun ulang APK menggunakan tapas, menandatangani APK yang dihasilkan, lalu menguji dan merilis APK:

• Untuk perangkat yang belum dirilis (atau saat menyiapkan update sistem untuk perangkat yang sudah dirilis), kirimkan APK baru di direktori bawaan aplikasi Data untuk memastikan bahwa image sistem dan pengujian xTS memiliki APK terbaru. OEM harus menguji apakah file baru berfungsi dengan benar (yaitu, lulus CTS dan semua pengujian otomatis dan manual khusus OEM).
• Untuk perangkat yang dirilis dan tidak lagi menerima update sistem, APK bertanda tangan mungkin hanya dirilis melalui app store.

OEM bertanggung jawab atas jaminan kualitas dan pengujian aplikasi Data yang diupdate di perangkat mereka sebelum dirilis.

Strategi kode versi aplikasi data

Aplikasi Data harus memiliki strategi pembuatan versi yang sesuai untuk memastikan perangkat menerima APK yang benar. Misalnya, jika update sistem diterima yang berisi APK yang lebih lama daripada yang didownload dari app store, versi app store harus dipertahankan.

Kode versi APK harus menyertakan informasi berikut:

• Versi format distro (utama + minor)
• Nomor versi yang bertambah (buram)

Saat ini, level API platform sangat berkorelasi dengan versi format distro karena setiap level API biasanya dikaitkan dengan versi ICU baru (yang membuat file distro tidak kompatibel). Pada masa mendatang, Android dapat mengubahnya sehingga file distro dapat berfungsi di beberapa rilis platform Android (dan level API tidak digunakan dalam skema kode versi aplikasi Data).

Contoh strategi kode versi

Skema penomoran versi contoh ini memastikan bahwa versi format distro yang lebih tinggi menggantikan versi format distro yang lebih rendah. AndroidManifest.xml menggunakan android:minSdkVersion untuk memastikan bahwa perangkat lama tidak menerima versi dengan versi format distro yang lebih tinggi daripada yang dapat ditanganinya.

Gambar 6. Contoh strategi kode versi.

Skema ini dapat dikemas lebih baik jika menggunakan biner, bukan desimal, tetapi skema ini memiliki keunggulan karena dapat dibaca manusia. Jika rentang angka penuh habis, nama paket aplikasi Data dapat berubah.

Nama versi adalah representasi detail yang dapat dibaca manusia, misalnya: major=001,minor=001,iana=2017a, revision=1,respin=2. Contohnya ditampilkan dalam tabel berikut.

• Contoh 1 dan 2 menunjukkan dua versi APK untuk rilis IANA 2017a yang sama dengan versi format utama yang berbeda. 2 secara numerik lebih tinggi dari 1, yang diperlukan untuk memastikan perangkat yang lebih baru menerima versi format yang lebih tinggi. minSdkVersion memastikan bahwa versi P tidak akan diberikan ke perangkat O.
• Contoh 3 adalah revisi/perbaikan untuk 1 dan secara numerik lebih tinggi dari 1.
• Contoh 4 dan 5 menunjukkan rilis 2017b untuk O-MR1 dan P. Karena secara numerik lebih tinggi, versi ini menggantikan rilis IANA/revisi Android sebelumnya dari pendahulunya masing-masing.
• Contoh 6 dan 7 menunjukkan rilis 2018a untuk O-MR1 dan P.
• Contoh 8 menunjukkan penggunaan Y untuk menggantikan sepenuhnya skema Y=0.
• Contoh 9 menunjukkan penggunaan celah yang tersisa antara 3 dan 4 untuk memutar ulang APK.

Karena setiap perangkat dikirim dengan APK default yang diberi versi dengan tepat dalam image sistem, tidak ada risiko versi O-MR1 diinstal pada perangkat P karena memiliki nomor versi yang lebih rendah daripada versi image sistem P. Perangkat dengan versi O-MR1 yang diinstal di /data, lalu menerima update sistem ke P, akan menggunakan versi /system daripada versi O-MR1 di /data karena versi P selalu lebih tinggi daripada aplikasi yang ditujukan untuk O-MR1.

Membangun aplikasi Data menggunakan tapas

OEM bertanggung jawab untuk mengelola sebagian besar aspek aplikasi Data zona waktu dan mengonfigurasi image sistem dengan benar. Aplikasi Data dimaksudkan untuk dibangun dengan build tapas yang menghasilkan APK yang sesuai untuk ditambahkan ke image sistem (untuk rilis awal) serta ditandatangani dan didistribusikan melalui toko aplikasi (untuk update berikutnya).

Tapas adalah versi yang lebih ramping dari sistem build Android yang menggunakan hierarki sumber yang lebih kecil untuk menghasilkan versi aplikasi yang dapat didistribusikan. OEM yang memahami sistem build Android normal akan mengenali file build dari build platform Android normal.

Buat manifes

Pohon sumber yang dikurangi biasanya dicapai dengan file manifes kustom yang hanya merujuk ke project Git yang diperlukan oleh sistem build dan untuk mem-build aplikasi. Setelah mengikuti petunjuk di Membuat aplikasi Data, OEM harus memiliki setidaknya dua project Git khusus OEM yang dibuat dengan menggunakan file template di packages/apps/TimeZoneData/oem_template:

• Satu project Git berisi file aplikasi seperti manifes dan file build yang diperlukan untuk membuat file APK aplikasi (misalnya, vendor/oem/apps/TimeZoneData). Project ini juga berisi aturan build untuk APK pengujian yang dapat digunakan oleh pengujian xTS.
• Satu project Git berisi APK bertanda tangan yang dihasilkan oleh build aplikasi untuk disertakan dalam build image sistem dan pengujian xTS.

Build aplikasi memanfaatkan beberapa project Git lain yang dibagikan dengan build platform atau berisi library kode independen OEM.

Cuplikan manifes berikut berisi kumpulan project Git minimal yang diperlukan untuk mendukung build O-MR1 aplikasi Data zona waktu. OEM harus menambahkan project Git khusus OEM (yang biasanya mencakup project yang berisi sertifikat penandatanganan) ke manifes ini, dan dapat mengonfigurasi cabang yang berbeda dengan tepat.

   <!-- 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" />

Menjalankan build tapas

Setelah hierarki sumber dibuat, panggil build tapas menggunakan perintah berikut:

source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2'  TARGET_BUILD_VARIANT=userdebug

Build yang berhasil akan menghasilkan file di direktori out/dist untuk pengujian. File ini dapat ditempatkan ke dalam direktori prebuilts untuk disertakan dalam image sistem dan/atau didistribusikan melalui app store untuk perangkat yang kompatibel.