Android 10 menghentikan 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 akan memperbarui waktu musim panas (DST) dan zona waktu di perangkat Android, menstandarkan data yang dapat sering berubah karena alasan agama, politik, dan geopolitik.
Update menggunakan proses berikut:
- IANA merilis update untuk Database Zona Waktu merilis pembaruan sebagai respons terhadap satu atau beberapa pemerintah yang mengubah aturan zona waktu di negara mereka.
- Google atau partner Android menyiapkan update modul Data Zona Waktu (file APEX) yang berisi zona waktu yang diperbarui.
- Perangkat pengguna akhir mendownload update, memulai ulang, lalu menerapkan perubahan, setelah itu data zona waktu perangkat akan berisi data zona waktu baru dari update.
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 telah dihapus sepenuhnya dari Android 14 dan seterusnya dan tidak dapat ditemukan dalam kode sumber. Partner harus bermigrasi sepenuhnya ke modul Mainline Zona Waktu.
Di Android 8.1 dan Android 9, OEM dapat menggunakan mekanisme berbasis APK untuk mengirim data aturan zona waktu yang diperbarui 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 bawaan. OEM dapat memilih untuk menggunakan file data ini saat membuat pembaruan zona waktu untuk perangkat mereka atau dapat membuat file data mereka sendiri jika diinginkan. Dalam semua kasus, OEM mempertahankan kontrol atas jaminan/pengujian kualitas, pengaturan waktu, dan peluncuran update aturan zona waktu untuk perangkat yang didukung.
Data dan kode sumber zona waktu Android
Semua perangkat Android stok, bahkan yang tidak menggunakan fitur ini, memerlukan data aturan zona waktu
dan harus dikirimkan dengan kumpulan data aturan zona waktu default di
partisi /system. Data ini kemudian digunakan oleh kode dari
library berikut dalam hierarki sumber Android:
- Kode terkelola dari
libcore/(misalnya,java.util.TimeZone) menggunakan filetzdatadantzlookup.xml. - Kode library native di
bionic/(misalnya, untukmktime, panggilan sistem localtime) menggunakan filetzdata. - Kode library ICU4J/ICU4C di
external/icu/menggunakan file.daticu.
Library ini melacak file overlay yang mungkin ada di
direktori /data/misc/zoneinfo/current. File overlay diharapkan
berisi data aturan zona waktu yang ditingkatkan, sehingga memungkinkan perangkat diupdate
tanpa mengubah /system.
Komponen sistem Android yang memerlukan data aturan zona waktu akan memeriksa lokasi berikut terlebih dahulu:
- Kode
libcore/danbionic/menggunakan salinan/datadari filetzdatadantzlookup.xml. - Kode ICU4J/ICU4C menggunakan file di
/datadan kembali ke file/systemuntuk data yang tidak ada (untuk format, string yang dilokalkan, dll.).
File distro
File .zip distro 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 perubahan rilis lainnya. Android menyediakan file distro untuk rilis Android yang didukung untuk setiap update IANA (selain memperbarui file sistem platform). Agar perangkat mereka selalu yang terbaru, OEM dapat menggunakan file distro ini atau membuat file mereka sendiri menggunakan hierarki sumber Android (yang berisi skrip dan file lain yang diperlukan untuk membuat file distro).
Komponen pembaruan zona waktu
Pembaruan 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.RulesManagerServiceberjalan dalam proses server sistem dan melakukan operasi update zona waktu dengan menulis ke/data/misc/zoneinfo/staged.RulesManagerServicejuga dapat mengganti atau menghapus operasi yang telah di-staging. -
TimeZoneUpdater, aplikasi sistem yang tidak dapat diupdate (atau aplikasi Updater). OEM harus menyertakan aplikasi ini dalam image sistem perangkat yang menggunakan fitur tersebut. - OEM
TimeZoneData, aplikasi sistem yang dapat diupdate (alias aplikasi Data) yang membawa file distro ke perangkat dan menyediakannya untuk aplikasi Updater. OEM harus menyertakan aplikasi ini di image sistem perangkat yang menggunakan fitur tersebut. -
tzdatacheck, biner waktu booting yang diperlukan untuk pengoperasian update zona waktu yang benar dan aman.
Hierarki sumber Android berisi kode sumber umum untuk komponen di atas, yang dapat dipilih oleh OEM untuk digunakan tanpa modifikasi. Kode pengujian diberikan untuk memungkinkan OEM secara otomatis memeriksa apakah mereka telah mengaktifkan fitur dengan benar.
Penginstalan distro
Proses penginstalan distro meliputi langkah-langkah berikut:
- Aplikasi data diupdate melalui download app store atau
sideload. Proses server sistem (melalui
class
timezone.RulesManagerServer/timezone.PackageTracker) mengawasi perubahan pada nama paket aplikasi Data khusus OEM yang dikonfigurasi.
Gambar 1. Update aplikasi data.
- Proses server sistem memicu pemeriksaan update dengan
menyiarkan intent yang ditargetkan dengan token unik sekali pakai ke Aplikasi
Updater. Server sistem melacak token terbaru yang dihasilkannya sehingga
dapat menentukan kapan pemeriksaan terbaru yang dipicunya telah selesai; token
lainnya akan diabaikan.
Gambar 2. Pemeriksaan pembaruan pemicu.
- Selama pemeriksaan update, aplikasi Updater akan melakukan
tugas-tugas berikut:
- Mengkueri status perangkat saat ini dengan memanggil RulesManagerService.
Gambar 3. Update aplikasi data, memanggil RulesManagerService.
- Membuat kueri aplikasi Data dengan membuat kueri URL ContentProvider dan
spesifikasi kolom yang ditentukan dengan baik untuk mendapatkan informasi tentang distro.
Gambar 4. Update aplikasi data, dapatkan info tentang distro.
- Mengkueri status perangkat saat ini dengan memanggil RulesManagerService.
- Aplikasi Updater akan 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. AturanManagerService mengonfirmasi ulang bahwa versi dan konten format distro sudah sesuai untuk perangkat dan tahap penginstalan.
- Meminta uninstal (hal ini jarang terjadi). Misalnya, jika APK
yang diupdate di
/datadinonaktifkan atau di-uninstal dan perangkat dikembalikan ke versi yang ada di/system. - Tidak melakukan apa pun. Terjadi saat distro aplikasi Data ditemukan tidak valid.
Gambar 5. Pemeriksaan selesai.
- Mulai ulang dan tzdatacheck. Saat perangkat melakukan booting berikutnya,
biner tzdatacheck akan mengeksekusi operasi yang di-staging. Biner tzdatacheck dapat
melakukan tugas berikut:
- Jalankan operasi bertahap dengan menangani pembuatan, penggantian,
dan/atau penghapusan file
/data/misc/zoneinfo/currentsebelum komponen sistem lainnya telah membuka dan mulai menggunakan file. - Pastikan file di
/datasudah benar untuk versi platform saat ini, yang mungkin tidak terjadi 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.
- Jalankan operasi bertahap dengan menangani pembuatan, penggantian,
dan/atau penghapusan file
Keandalan
Proses penginstalan menyeluruh bersifat asinkron dan dibagi menjadi tiga proses OS. Selama penginstalan, perangkat dapat kehilangan daya, kehabisan ruang disk, atau mengalami masalah lain, yang menyebabkan pemeriksaan penginstalan tidak selesai. Dalam kasus terbaik yang tidak berhasil, aplikasi Updater akan memberi tahu server sistem bahwa aplikasi tidak berhasil; dalam kasus terburuk yang tidak berhasil, RulesManagerService tidak menerima panggilan sama sekali.
Untuk menangani hal ini, kode server sistem melacak apakah pemeriksaan update yang dipicu telah selesai dan kode versi Aplikasi Data yang terakhir diperiksa. Saat perangkat tidak ada aktivitas 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, pemeriksaan update akan langsung terpicu.
Keamanan
Jika diaktifkan, kode RulesManagerService di server sistem akan melakukan beberapa pemeriksaan untuk memastikan bahwa sistem aman digunakan.
- Masalah yang menunjukkan image sistem yang dikonfigurasi dengan buruk akan mencegah perangkat
di-booting; contohnya termasuk konfigurasi aplikasi Updater atau Data yang buruk atau
aplikasi Updater atau Data tidak berada di
/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
diberlakukan menggunakan aturan SELinux. Seperti APK lainnya, aplikasi Data harus ditandatangani oleh
kunci yang sama dengan 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, jaminan kualitas, dan pertimbangan keamanan berikut:
- Membuat kunci penandatanganan khusus per aplikasi untuk aplikasi Data mereka.
- Buat strategi rilis dan pembuatan versi untuk update zona waktu guna memahami perangkat mana yang akan diupdate dan bagaimana perangkat tersebut dapat memastikan bahwa update hanya diinstal di perangkat yang membutuhkannya. Misalnya, OEM mungkin ingin memiliki satu aplikasi Data untuk semua perangkat mereka atau dapat memilih untuk memiliki aplikasi Data yang berbeda untuk perangkat yang berbeda. Keputusan ini memengaruhi pilihan nama paket, mungkin kode versi yang digunakan, dan strategi QA.
- Pahami apakah mereka ingin menggunakan data zona waktu Android stok 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 lainnya yang berada 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 sendiri. Namun, karena aplikasi Data tidak dapat diluncurkan, ikon hanya muncul di layar Setelan > Aplikasi.
Aplikasi Data dimaksudkan untuk dibuat 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 selanjutnya). Untuk mengetahui detail tentang penggunaan tapas, lihat Mem-build aplikasi Data menggunakan tapas.
OEM harus menginstal aplikasi Data yang telah di-build 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. Contoh
template juga menyertakan target build untuk menyertakan versi pengujian
aplikasi Data dalam rangkaian pengujian.
Menyertakan 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 aplikasi Updater dan target
bawaan aplikasi Data.
Aplikasi Updater harus ditandatangani dengan kunci platform dan disertakan sebagai
aplikasi sistem lainnya. Target ditentukan di
packages/apps/TimeZoneUpdater sebagai TimeZoneUpdater. Penyertaan aplikasi data bersifat 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 di
frameworks/base/core/res/res/values/config.xml.
| Properti | Deskripsi | Penggantian Diperlukan? |
|---|---|---|
config_enableUpdateableTimeZoneRules |
Harus ditetapkan ke true untuk mengaktifkan RulesManagerService. |
Ya |
config_timeZoneRulesUpdateTrackingEnabled |
Harus ditetapkan ke true agar sistem memproses perubahan pada
aplikasi Data. |
Ya |
config_timeZoneRulesDataPackage |
Nama paket aplikasi Data khusus OEM. | Ya |
config_timeZoneRulesUpdaterPackage |
Dikonfigurasi untuk aplikasi Updater default. Hanya ubah jika menyediakan implementasi aplikasi Updater yang berbeda. | Tidak |
config_timeZoneRulesCheckTimeMillisAllowed |
Waktu yang diizinkan antara pemeriksaan update yang dipicu oleh RulesManagerService dan respons penginstalan, uninstal, atau tindakan tidak dilakukan. Setelah tahap ini, pemicu keandalan spontan mungkin akan dibuat. | Tidak |
config_timeZoneRulesCheckRetryCount |
Jumlah pemeriksaan update berurutan yang tidak berhasil diizinkan sebelum RulesManagerService berhenti membuat lebih banyak. | Tidak |
Penggantian konfigurasi harus ada dalam image sistem (bukan vendor atau lainnya) karena perangkat yang salah dikonfigurasi dapat menolak untuk melakukan booting. Jika penggantian konfigurasi ada dalam image vendor, mengupdate ke image sistem tanpa aplikasi Data (atau dengan nama paket aplikasi Data/Updater yang berbeda) akan dianggap sebagai konfigurasi yang salah.
Pengujian xTS
xTS mengacu pada rangkaian pengujian khusus OEM yang serupa dengan rangkaian pengujian Android standar yang 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/xtsmenyertakan kode yang diperlukan untuk pengujian fungsional otomatis dasar.packages/apps/TimeZoneData/oem_template/xtsberisi contoh struktur direktori untuk menyertakan pengujian dalam suite xTS seperti Tradefed. Seperti direktori template lainnya, OEM diharapkan untuk menyalin dan menyesuaikan dengan kebutuhan mereka.packages/apps/TimeZoneData/oem_template/data_app_prebuiltberisi 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 akan membuat patch untuk mengupdate rilis di AOSP. OEM yang menggunakan sistem Android dan file distro bawaan dapat mengambil commit ini, menggunakannya untuk membuat versi baru aplikasi Data, lalu merilis versi baru untuk mengupdate perangkat 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 dan ingin diupdate oleh OEM. Misalnya, jika OEM ingin menyediakan update untuk perangkat Android 8.1, 9, dan 10, OEM tersebut harus menyelesaikan proses ini tiga kali.
Langkah 1: Perbarui file data sistem/zona waktu dan eksternal/icu
Pada langkah ini, OEM mengambil commit Android stok 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 membuat perbaikan lokal
tambahan 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, yang
otomatis disertakan saat APK aplikasi Data di-build.
Langkah 2: Perbarui kode versi aplikasi Data
Pada langkah ini, OEM akan mengupdate kode versi aplikasi Data. Build
otomatis mengambil distro.zip, tetapi versi baru
aplikasi Data harus memiliki kode versi baru sehingga dikenali sebagai baru dan digunakan untuk
mengganti aplikasi Data yang dimuat sebelumnya 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 (tetapi, kode versi pengujian harus lebih tinggi dari versi image sistem). Untuk mengetahui detailnya,
lihat contoh skema strategi
kode versi; jika skema contoh atau skema serupa digunakan, kode versi
pengujian tidak perlu diperbarui karena dijamin lebih tinggi
dari kode versi sebenarnya.
Langkah 3: Build ulang, tanda tangani, uji, dan rilis
Pada langkah ini, OEM mem-build 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 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, file lulus CTS serta pengujian otomatis dan manual khusus OEM).
- Untuk perangkat yang dirilis yang tidak lagi menerima update sistem, APK yang ditandatangani mungkin hanya dirilis melalui app store.
OEM bertanggung jawab atas jaminan kualitas dan menguji 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 bahwa perangkat menerima APK yang tepat. 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 inkremental (buram)
Saat ini, API level platform berkorelasi kuat dengan versi format distro karena setiap level API biasanya dikaitkan dengan ICU versi baru (yang membuat file distro tidak kompatibel). Di 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
Contoh skema nomor pembuatan versi ini memastikan bahwa versi format distro yang lebih tinggi akan menggantikan versi format distro yang lebih rendah.
AndroidManifest.xml menggunakan android:minSdkVersion untuk
memastikan perangkat lama tidak menerima versi dengan versi format
distro yang lebih tinggi dari yang dapat ditanganinya.
Gambar 6. Contoh strategi kode versi.
| Contoh | Nilai | Tujuan |
|---|---|---|
| Y | Sudah diperuntukkan | Memungkinkan skema alternatif/APK pengujian di masa mendatang. Awalnya (secara implisit) 0. Karena jenis dasarnya adalah jenis int 32-bit bertanda tangan, skema ini mendukung maksimal dua revisi skema penomoran mendatang. |
| 01 | Versi format utama | Melacak versi format utama 3 digit desimal. Format distro mendukung 3 digit desimal tetapi hanya 2 digit yang digunakan di sini. Hal ini tidak mungkin mencapai 100 mengingat penambahan besar yang diharapkan per level API. Versi utama 1 setara dengan API level 27. |
| 1 | Versi format minor | Melacak versi format minor 3 digit desimal. Format distro mendukung 3 digit desimal, tetapi hanya 1 digit yang digunakan di sini. Kemungkinan tidak akan mencapai 10. |
| X | Sudah diperuntukkan | 0 untuk rilis produksi (dan mungkin berbeda untuk APK pengujian). |
| ZZZZZ | Nomor versi buram | Angka desimal yang dialokasikan sesuai permintaan. Menyertakan celah untuk memungkinkan update interstisial dilakukan jika diperlukan. |
Skema dapat dikemas dengan lebih baik jika biner digunakan, bukan desimal, tetapi skema ini memiliki keunggulan karena dapat dibaca manusia. Jika rentang angka penuh telah 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.
| # | Kode versi | minSdkVersion | {Versi format utama},{Versi format minor},{Versi aturan IANA},{Revisi} |
|---|---|---|---|
| 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 |
- 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 bahwa perangkat yang lebih baru menerima versi format yang lebih tinggi. minSdkVersion memastikan bahwa versi P tidak akan disediakan 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. Dengan angka yang lebih tinggi, versi ini menggantikan rilis IANA/revisi Android sebelumnya dari pendahulunya.
- Contoh 6 dan 7 menunjukkan rilis 2018a untuk O-MR1 dan P.
- Contoh 8 menunjukkan penggunaan Y untuk sepenuhnya mengganti skema Y=0.
- Contoh 9 menunjukkan penggunaan celah yang tersisa antara 3 dan 4 untuk memutar ulang apk.
Karena setiap perangkat mengirim APK default dengan versi yang sesuai di
image sistem, tidak ada risiko versi O-MR1 diinstal di perangkat P
karena nomor versinya lebih rendah daripada versi image sistem P. Perangkat
dengan versi O-MR1 yang diinstal di /data yang kemudian menerima
update sistem ke P menggunakan versi /system sebagai preferensi daripada
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 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 app store (untuk update berikutnya).
Tapas adalah versi sistem build Android yang diperkecil yang menggunakan hierarki sumber yang dikurangi untuk menghasilkan versi aplikasi yang dapat didistribusikan. OEM yang sudah terbiasa dengan sistem build Android normal harus mengenali file build dari build platform Android normal.
Membuat manifes
Hierarki 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 dalam
Membuat aplikasi Data, OEM harus memiliki
setidaknya dua project Git khusus OEM yang dibuat 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 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 mereka (yang biasanya menyertakan project yang berisi sertifikat penandatanganan) ke manifes ini, dan dapat mengonfigurasi cabang yang berbeda.
<!-- 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.shtapasmake -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 prebuilt untuk disertakan dalam
image sistem dan/atau didistribusikan melalui app store untuk perangkat
yang kompatibel.