Aturan zona waktu

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

Pembaruan zona waktu (Android 10 dan yang lebih baru)

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

Update menggunakan proses berikut:

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

Untuk mengetahui detail tentang modul, lihat Komponen Sistem Modular.

Pembaruan zona waktu (Android 8.1–9)

Catatan: Fitur mekanisme pembaruan data zona waktu berbasis APK memiliki dihapus sepenuhnya dari Android 14 dan seterusnya dan tidak dapat ditemukan di kode sumbernya. Partner harus bermigrasi sepenuhnya ke Zona Waktu Modul mainline.

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

Tim library inti Android menyediakan file data yang diperlukan untuk memperbarui aturan zona waktu di perangkat Android stok. OEM dapat memilih untuk menggunakan file data saat membuat pembaruan zona waktu untuk perangkat mereka atau dapat membuat file data sendiri jika diinginkan. Dalam semua kasus, OEM tetap memegang kendali atas kualitas yang memberikan jaminan/pengujian, pengaturan waktu, dan peluncuran pembaruan aturan zona waktu perangkat yang didukung.

Kode sumber dan data zona waktu Android

Semua perangkat Android yang tersedia, bahkan yang tidak menggunakan fitur ini, memerlukan zona waktu data aturan dan harus dikirimkan dengan kumpulan data default aturan zona waktu dalam Partisi /system. Data ini kemudian digunakan oleh kode dari library berikut di hierarki sumber Android:

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

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

Komponen sistem Android yang memerlukan data aturan zona waktu, periksa hal-hal berikut lokasi terlebih dahulu:

• Kode libcore/ dan bionic/ menggunakan /data salinan tzdata dan tzlookup.xml .
• Kode ICU4J/ICU4C menggunakan file dalam /data dan kembali ke /system file untuk data yang tidak ada (untuk format, dilokalkan {i>string<i}, 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 dengan versi ICU, persyaratan platform Android, dan rilis lainnya perubahan. Android menyediakan file distro untuk rilis Android yang didukung bagi setiap Update IANA (selain memperbarui file sistem platform). Untuk menjaga perangkat terbaru, OEM dapat menggunakan file distro ini atau membuat file distro sendiri menggunakan pohon sumber Android (yang berisi skrip dan file lain yang dibutuhkan untuk membuat file distro).

Komponen pembaruan zona waktu

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

• Fungsionalitas layanan platform (timezone.RulesManagerService), yang dinonaktifkan secara {i>default<i}. OEM harus mengaktifkan fungsi melalui konfigurasi. RulesManagerService berjalan dalam proses dan tahapan server sistem operasi pembaruan zona waktu dengan menulis ke /data/misc/zoneinfo/staged. RulesManagerService dapat mengganti atau menghapus operasi bertahap.
• TimeZoneUpdater, aplikasi sistem yang tidak dapat diupdate (alias aplikasi Updater). OEM harus menyertakan aplikasi ini di image sistem perangkat yang menggunakan fitur tersebut.
• OEM TimeZoneData, aplikasi sistem yang dapat diupdate (alias aplikasi Data) yang membawa file distro ke perangkat dan membuatnya yang tersedia untuk aplikasi Updater. OEM harus menyertakan aplikasi ini di image sistem perangkat lain yang menggunakan fitur tersebut.
• tzdatacheck, biner waktu {i>booting<i} yang diperlukan untuk operasi pembaruan zona waktu yang benar dan aman.

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

Penginstalan distro

Proses penginstalan distro meliputi langkah-langkah berikut:

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

   Gambar 1. Update aplikasi data.

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

   Gambar 2. Pemeriksaan pembaruan pemicu.

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

     Gambar 3. Update aplikasi data, memanggil RulesManagerService.

   • Melakukan kueri aplikasi Data dengan mengkueri URL ContentProvider yang telah ditetapkan 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. Tujuan RulesManagerService mengonfirmasi ulang bahwa versi dan konten format distro telah sesuai untuk perangkat dan tahapan pemasangannya.
   • Minta uninstal (hal ini jarang terjadi). Misalnya, jika pembaruan APK di /data sedang dinonaktifkan atau di-uninstal dan perangkat kembali ke versi yang ada di /system.
   • Tidak melakukan apa pun. Terjadi saat distro aplikasi Data diketahui tidak valid.
   Dalam semua kasus, aplikasi Updater memanggil RulesManagerService dengan token pemeriksaan sehingga server sistem tahu bahwa pemeriksaan telah selesai dan berhasil.
   
   

   Gambar 5. Pemeriksaan selesai.

5. Mulai ulang dan tzdatacheck. Saat perangkat melakukan {i>booting<i}, biner {i>tzdatacheck<i} mengeksekusi semua operasi bertahap. Biner {i>tzdatacheck<i} dapat lakukan tugas berikut:
   • Menjalankan operasi bertahap dengan menangani pembuatan, penggantian, dan/atau penghapusan file /data/misc/zoneinfo/current sebelum komponen sistem lainnya telah terbuka dan mulai menggunakan file itu.
   • Periksa apakah file dalam /data sudah benar untuk versi saat ini versi platform, yang mungkin tidak terjadi jika perangkat baru saja menerima pembaruan sistem dan versi format distro telah berubah.
   • Pastikan versi aturan IANA sama atau lebih baru dari versi di /system. Tindakan ini melindungi sistem dari update sistem yang meninggalkan perangkat dengan data aturan zona waktu yang lebih lama daripada yang ada di /system gambar.

Keandalan

Proses instalasi {i>end-to-end <i}bersifat asinkron dan dibagi menjadi tiga OS proses-proses tersebut. Kapan pun selama instalasi, perangkat mungkin kehilangan daya, berjalan kehabisan ruang {i>disk<i}, atau mengalami masalah lain, yang menyebabkan pemeriksaan tidak lengkap. Dalam kasus terbaik yang tidak berhasil, aplikasi Updater memberi tahu sistem server bahwa server itu gagal; dalam kasus terburuk, RulesManagerService tidak menerima panggilan sama sekali.

Untuk menangani hal ini, kode server sistem melacak apakah pemicu telah selesai memeriksa pembaruan dan kode versi Data yang terakhir diperiksa Aplikasi tersebut. Saat perangkat tidak ada aktivitas dan mengisi daya, kode server sistem dapat memeriksa kondisi saat ini. Jika ditemukan pemeriksaan update yang tidak lengkap atau Data yang tidak terduga Versi aplikasi, tindakan ini secara spontan memicu pemeriksaan update.

Keamanan

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

• Masalah yang menunjukkan image sistem yang dikonfigurasi dengan buruk mencegah perangkat melakukan booting; contohnya termasuk konfigurasi aplikasi Data atau Updater yang buruk atau Updater atau Aplikasi Data tidak ada di /system/priv-app.
• Masalah yang menunjukkan aplikasi Data yang buruk telah diinstal tidak mencegah perangkat {i>booting<i} tetapi mencegah pemeriksaan pembaruan dipicu; contoh mencakup 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 halnya APK, aplikasi Data harus ditandatangani oleh kunci yang sama yang digunakan untuk menandatangani versi /system/priv-app. Aplikasi Data diharapkan memiliki nama dan kunci paket khusus OEM.

Mengintegrasikan pembaruan zona waktu

Untuk mengaktifkan fitur pembaruan zona waktu, OEM biasanya:

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

Persiapan

Sebelum memulai, OEM harus meninjau kebijakan, uji mutu, dan keamanan:

• Membuat kunci penandatanganan khusus aplikasi khusus untuk aplikasi Data mereka.
• Membuat strategi rilis dan pembuatan versi untuk update zona waktu untuk memahami perangkat mana yang akan diupdate dan bagaimana mereka dapat memastikan bahwa pembaruan hanya diinstal pada perangkat yang membutuhkannya. Misalnya, OEM mungkin ingin memiliki satu aplikasi Data untuk semua perangkat mereka atau dapat memilih untuk memiliki Aplikasi data untuk perangkat yang berbeda. Keputusan ini memengaruhi pilihan paket mungkin kode versi yang digunakan, dan strategi QA.
• Memahami apakah mereka ingin menggunakan data zona waktu Android bawaan dari AOSP atau membuatnya sendiri.

Membuat aplikasi Data

AOSP menyertakan 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 berada di packages/apps/TimeZoneData/oem_template. Contoh template mencakup target build untuk APK aplikasi Data sesungguhnya maupun 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 akan muncul hanya di Setelan > Layar Aplikasi.

Aplikasi Data dimaksudkan untuk dibangun dengan build tapas yang menghasilkan APK yang sesuai untuk ditambahkan ke image sistem (untuk rilis) dan ditandatangani serta didistribusikan melalui app store (untuk paket selanjutnya {i>update<i}). Untuk detail tentang cara menggunakan tapas, lihat Membangun Aplikasi data yang menggunakan tapas.

OEM harus menginstal aplikasi Data bawaan di image sistem perangkat di /system/priv-app. Untuk menyertakan APK bawaan (yang dihasilkan oleh tapas di image sistem, OEM dapat menyalin file contoh di packages/apps/TimeZoneData/oem_template/data_app_prebuilt. Tujuan template contoh juga menyertakan target build untuk menyertakan versi pengujian Aplikasi data di rangkaian pengujian.

Menyertakan aplikasi Updater dan Data di 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 aplikasi Updater dan aplikasi Data bawaan target.

Aplikasi Updater harus ditandatangani dengan kunci platform dan disertakan sebagai aplikasi sistem lainnya. Target didefinisikan dalam packages/apps/TimeZoneUpdater sebagai TimeZoneUpdater. Tujuan Penyertaan aplikasi data bersifat khusus OEM dan bergantung pada nama target yang dipilih untuk pra-build.

Mengonfigurasi server sistem

Untuk mengaktifkan pembaruan 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 {i>booting<i}. Jika konfigurasi mengganti berada di image vendor, yang diperbarui 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 mirip dengan Android standar rangkaian pengujian menggunakan Tradefed (seperti CTS dan VTS). OEM yang melakukan pengujian tersebut suite dapat menambahkan pengujian update zona waktu Android yang disediakan di lokasi:

• packages/apps/TimeZoneData/testing/xts menyertakan kode yang diperlukan untuk pengujian fungsional otomatis dasar.
• packages/apps/TimeZoneData/oem_template/xts berisi sampel struktur direktori untuk menyertakan pengujian dalam suite xTS yang mirip dengan Tradefed. Seperti halnya dengan direktori template lain, OEM diharapkan untuk menyalin dan menyesuaikan mereka.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt berisi konfigurasi waktu build untuk menyertakan APK pengujian siap pakai yang diperlukan oleh pengujian.

Membuat pembaruan zona waktu

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

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

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

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

Patch AOSP sistem/zona berisi file yang telah diupdate di system/timezone/input_data dan system/timezone/output_data. OEM yang perlu membuat produk lokal tambahan perbaikan dapat mengubah file input lalu menggunakan file dalam 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, yaitu disertakan secara otomatis saat APK aplikasi Data dibuat.

Langkah 2: Perbarui kode versi aplikasi Data

Pada langkah ini, OEM memperbarui kode versi aplikasi Data. Build otomatis mengambil distro.zip, namun versi baru Aplikasi data harus memiliki kode versi baru sehingga dianggap sebagai baru dan digunakan untuk mengganti aplikasi Data yang dipramuat atau aplikasi Data yang diinstal pada perangkat dengan memperbarui.

Saat membangun 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 (tetapi, kode versi pengujian harus lebih tinggi daripada versi image sistem). Untuk mengetahui detailnya, lihat contoh strategi kode versi skema; jika skema contoh atau skema serupa digunakan, pengujian itu kode versi tidak perlu diperbarui karena dijamin akan lebih daripada kode versi sebenarnya.

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

Pada langkah ini, OEM akan membuat ulang APK menggunakan tapas, menandatangani perintah yang dihasilkan APK, lalu uji dan rilis APK:

• Untuk perangkat yang belum dirilis (atau saat menyiapkan update sistem untuk perangkat yang dirilis), kirimkan APK baru di direktori bawaan aplikasi Data untuk memastikan bahwa image sistem dan pengujian xTS memiliki APK terbaru. OEM harus uji apakah file baru bekerja dengan benar (yaitu, file lulus CTS dan pengujian otomatis dan manual khusus OEM).
• Untuk perangkat yang dirilis dan tidak lagi menerima update sistem, APK yang ditandatangani mungkin hanya dirilis melalui {i>app store<i}.

OEM bertanggung jawab atas uji mutu dan menguji produk Aplikasi data di perangkat mereka sebelum dirilis.

Strategi kode versi aplikasi data

Aplikasi Data harus memiliki sesuai pembuatan versi Anda untuk memastikan bahwa perangkat menerima APK yang tepat. Sebagai misalnya, jika menerima update sistem yang berisi APK yang lebih lama dari satu diunduh dari app store, versi {i>app store<i} tersebut harus dipertahankan.

Kode versi APK harus menyertakan informasi berikut:

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

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

Contoh strategi kode versi

Contoh skema nomor pembuatan versi ini memastikan bahwa format distro yang lebih tinggi menggantikan versi format distro yang lebih rendah. AndroidManifest.xml menggunakan android:minSdkVersion untuk memastikan perangkat lama tidak menerima versi dengan format distro yang lebih tinggi daripada yang bisa mereka tangani.

Gambar 6. Contoh strategi kode versi.

Skema itu bisa dikemas lebih baik jika menggunakan biner daripada desimal, tetapi skema ini memiliki keuntungan karena dapat dibaca manusia. Jika rentang angka lengkap habis, nama paket aplikasi Data dapat berubah.

Nama versi adalah representasi detail yang dapat dibaca manusia, untuk contoh: 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 berbagai versi format utama. 2 secara numerik lebih tinggi dari 1, yang untuk memastikan bahwa perangkat yang lebih baru menerima versi format yang lebih tinggi. Tujuan 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 tahun 2017b untuk O-MR1 dan P. Secara numerik lebih tinggi, mereka menggantikan rilis IANA/revisi Android sebelumnya pendahulunya.
• Contoh 6 dan 7 menunjukkan rilis tahun 2018a untuk O-MR1 dan P.
• Contoh 8 menunjukkan penggunaan Y untuk menggantikan skema Y=0 secara keseluruhan.
• Contoh 9 menunjukkan penggunaan celah yang tersisa antara 3 dan 4 untuk memutar ulang apk tersebut.

Karena setiap perangkat mengirim APK default dengan versi yang sesuai dalam tidak ada risiko versi O-MR1 diinstal di perangkat P karena memiliki nomor versi yang lebih rendah dari versi {i>image<i} sistem P. J perangkat dengan versi O-MR1 yang diinstal di /data yang kemudian menerima update sistem ke P menggunakan versi /system sebagai preferensi untuk versi O-MR1 di /data karena versi P selalu lebih tinggi daripada aplikasi apa pun yang ditujukan untuk O-MR1.

Membangun aplikasi Data menggunakan tapas

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

Tapas adalah versi build Android yang lebih ramping yang menggunakan hierarki sumber yang dikurangi untuk menghasilkan versi distribusi aplikasi. OEM yang familier dengan sistem build Android normal harus mengenali membuat file dari build platform Android biasa.

Membuat manifes

Pengurangan pohon sumber biasanya dicapai dengan file manifes khusus yang hanya merujuk pada project Git yang dibutuhkan oleh sistem build dan untuk membangun . 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). Proyek 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 ini memanfaatkan beberapa project Git lain yang dibagikan dengan atau berisi library kode yang tidak bergantung pada OEM.

Cuplikan manifes berikut berisi kumpulan minimal project Git 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 sesuai.

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

Jalankan build tapas

Setelah hierarki sumber ditetapkan, 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-file ini dapat ditempatkan ke direktori bawaan untuk disertakan dalam image sistem dan/atau didistribusikan melalui app store untuk perangkat.