Aturan Zona Waktu

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

Pembaruan zona waktu (Android 10+)

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

Pembaruan menggunakan proses berikut:

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

Untuk 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 di kode sumber. Mitra harus bermigrasi sepenuhnya ke modul Time Zone Mainline.

Di Android 8.1 dan Android 9, OEM dapat menggunakan mekanisme berbasis APK untuk mengirimkan data aturan zona waktu yang diperbarui ke perangkat tanpa memerlukan pembaruan sistem. Mekanisme ini memungkinkan pengguna menerima pembaruan tepat waktu (sehingga memperpanjang masa pakai perangkat Android) dan memungkinkan mitra Android menguji pembaruan zona waktu secara independen dari pembaruan citra sistem.

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

Kode sumber dan data 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 pustaka berikut di pohon sumber Android:

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

Pustaka 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 diperbarui tanpa mengubah /system .

Komponen sistem Android yang memerlukan data aturan zona waktu, periksa 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 kembali 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 versi.

Format file distro bergantung pada rilis Android karena kontennya berubah seiring dengan versi ICU, persyaratan platform Android, dan perubahan rilis lainnya. Android menyediakan file distro untuk rilis Android yang didukung untuk setiap pembaruan IANA (selain memperbarui file sistem platform). Agar perangkat mereka tetap mutakhir, OEM dapat menggunakan file distro ini atau membuatnya sendiri menggunakan pohon sumber Android (yang berisi skrip dan file lain yang diperlukan untuk menghasilkan file distro).

Komponen pembaruan zona waktu

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

  • Fungsionalitas layanan platform ( timezone.RulesManagerService ), yang dinonaktifkan secara default. OEM harus mengaktifkan fungsionalitas tersebut melalui konfigurasi. RulesManagerService berjalan dalam proses server sistem dan melakukan tahapan operasi pembaruan 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 diperbarui (alias aplikasi Updater ). OEM harus menyertakan aplikasi ini dalam image sistem perangkat yang menggunakan fitur tersebut.
  • OEM TimeZoneData , aplikasi sistem yang dapat diperbarui (alias aplikasi Data ) yang membawa file distro ke perangkat dan membuatnya tersedia untuk aplikasi Updater. OEM harus menyertakan aplikasi ini dalam image sistem perangkat yang menggunakan fitur tersebut.
  • tzdatacheck , biner waktu boot yang diperlukan untuk pengoperasian pembaruan zona waktu yang benar dan aman.

Pohon sumber Android berisi kode sumber umum untuk komponen di atas, yang dapat dipilih oleh OEM untuk digunakan tanpa modifikasi. Kode pengujian diberikan agar OEM dapat secara otomatis memeriksa apakah mereka telah mengaktifkan fitur tersebut dengan benar.

Instalasi distro

Proses instalasi distro meliputi langkah-langkah berikut:

  1. Aplikasi data diperbarui melalui unduhan toko aplikasi atau sideload. Proses server sistem (melalui kelas timezone.RulesManagerServer/timezone.PackageTracker ) mengawasi perubahan pada nama paket aplikasi Data yang dikonfigurasi, khusus OEM.

    Pembaruan aplikasi data
    Gambar 1. Pembaruan aplikasi data
  2. Proses server sistem memicu pemeriksaan pembaruan dengan menyiarkan maksud yang ditargetkan dengan token unik sekali pakai ke Aplikasi Updater. Server sistem melacak token terbaru yang dihasilkan sehingga dapat menentukan kapan pemeriksaan terbaru yang dipicu telah selesai; token lainnya diabaikan.

    Pembaruan pemicu
    Gambar 2. Pemeriksaan pembaruan pemicu
  3. Selama pemeriksaan pembaruan , aplikasi Updater melakukan tugas berikut:
    • Mengkueri status perangkat saat ini dengan memanggil RulesManagerService.

      Hubungi RulesManagerService
      Gambar 3. Pembaruan aplikasi data, memanggil RulesManagerService
    • Mengkueri aplikasi Data dengan menanyakan URL ContentProvider yang terdefinisi dengan baik dan spesifikasi kolom untuk mendapatkan informasi tentang distro.

      Dapatkan informasi distro
      Gambar 4. Data update aplikasi, mendapatkan info tentang distro
  4. Aplikasi Updater mengambil tindakan yang sesuai berdasarkan informasi yang dimilikinya. Tindakan yang tersedia meliputi:
    • Minta instalasi. Data distro dibaca dari aplikasi Data dan diteruskan ke RulesManagerService di server sistem. RulesManagerService mengonfirmasi ulang bahwa versi format distro dan konten sesuai untuk perangkat dan melakukan tahapan instalasi.
    • Minta pencopotan pemasangan (ini jarang terjadi). Misalnya, jika APK yang diperbarui di /data dinonaktifkan atau dihapus instalasinya dan perangkat kembali ke versi yang ada di /system .
    • Tidak melakukan apapun. Terjadi ketika 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.

    Periksa selesai
    Gambar 5. Cek selesai
  5. Nyalakan ulang dan tzdatacheck. Saat perangkat melakukan booting berikutnya, biner tzdatacheck menjalankan operasi bertahap apa pun. Biner tzdatacheck dapat melakukan tugas-tugas berikut:
    • Jalankan operasi bertahap dengan menangani pembuatan, penggantian, dan/atau penghapusan file /data/misc/zoneinfo/current sebelum komponen sistem lain dibuka dan mulai menggunakan file tersebut.
    • Periksa apakah file di /data sudah benar untuk versi platform saat ini, 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 . Ini melindungi terhadap pembaruan sistem yang meninggalkan perangkat dengan data aturan zona waktu yang lebih lama daripada yang ada di gambar /system .

Keandalan

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

Untuk menangani hal ini, kode server sistem melacak apakah pemeriksaan pembaruan yang dipicu telah selesai dan kode versi Aplikasi Data yang terakhir diperiksa. Saat perangkat dalam keadaan idle dan mengisi daya, kode server sistem dapat memeriksa status saat ini. Jika ia menemukan pemeriksaan pembaruan yang tidak lengkap atau versi Aplikasi Data yang tidak diharapkan, maka secara spontan akan memicu pemeriksaan pembaruan.

Keamanan

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

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

Mengintegrasikan pembaruan zona waktu

Untuk mengaktifkan fitur pembaruan zona waktu, OEM biasanya:

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

Mempersiapkan

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

  • Buat kunci penandatanganan khusus aplikasi untuk aplikasi Data mereka.
  • Buat strategi rilis dan pembuatan versi untuk pembaruan zona waktu guna memahami perangkat mana yang akan diperbarui dan bagaimana mereka dapat memastikan bahwa pembaruan hanya diinstal pada perangkat yang membutuhkannya. Misalnya, OEM mungkin ingin memiliki satu aplikasi Data untuk semua perangkatnya atau mungkin memilih untuk memiliki aplikasi Data berbeda untuk perangkat berbeda. Keputusan tersebut berdampak pada pilihan nama paket, kemungkinan kode versi yang digunakan, dan strategi QA.
  • Pahami apakah mereka ingin menggunakan stok data zona waktu Android dari AOSP atau membuatnya sendiri.

Membuat aplikasi Data

AOSP mencakup semua kode sumber dan aturan build yang diperlukan untuk membuat aplikasi Data di packages/apps/TimeZoneData , dengan instruksi dan contoh templat untuk AndroidManifest.xml dan file lain yang terletak 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 Pengaturan > Aplikasi .

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

OEM harus menginstal aplikasi Data yang sudah terpasang di image sistem perangkat di /system/priv-app . Untuk menyertakan APK bawaan (dihasilkan oleh proses pembuatan 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 di rangkaian pengujian.

Menyertakan aplikasi Updater dan Data di image sistem

OEM harus menempatkan APK Updater dan aplikasi Data di direktori /system/priv-app pada image sistem. Untuk melakukan hal ini, build image sistem harus secara eksplisit menyertakan target aplikasi Updater dan aplikasi Data yang sudah dibuat sebelumnya.

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

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 .

Properti Keterangan Diperlukan Penggantian?
config_enableUpdateableTimeZoneRules
Harus disetel ke true untuk mengaktifkan RulesManagerService. Ya
config_timeZoneRulesUpdateTrackingEnabled
Harus disetel ke true agar sistem mendengarkan perubahan pada aplikasi Data. Ya
config_timeZoneRulesDataPackage
Nama paket aplikasi Data khusus OEM. Ya
config_timeZoneRulesUpdaterPackage
Dikonfigurasi untuk aplikasi Updater default. Ubah hanya ketika menyediakan implementasi aplikasi Updater yang berbeda. TIDAK
config_timeZoneRulesCheckTimeMillisAllowed
Waktu yang diperbolehkan antara pemeriksaan pembaruan yang dipicu oleh RulesManagerService dan respons pemasangan, pencopotan pemasangan, atau tidak melakukan apa pun. Setelah titik ini, pemicu keandalan spontan dapat dihasilkan. TIDAK
config_timeZoneRulesCheckRetryCount
Jumlah pemeriksaan pembaruan berurutan yang gagal yang diizinkan sebelum RulesManagerService berhenti menghasilkan lebih banyak. TIDAK

Pengabaian konfigurasi harus ada dalam image sistem (bukan vendor atau lainnya) karena perangkat yang salah dikonfigurasi dapat menolak untuk melakukan booting. Jika penggantian konfigurasi ada pada image vendor, memperbarui ke image sistem tanpa aplikasi Data (atau dengan nama paket aplikasi Data/aplikasi Pembaruan yang berbeda) akan dianggap sebagai kesalahan konfigurasi.

pengujian xTS

xTS mengacu pada rangkaian pengujian khusus OEM yang mirip dengan rangkaian pengujian Android standar yang menggunakan Tradefed (seperti CTS dan VTS). OEM yang memiliki rangkaian pengujian tersebut dapat menambahkan pengujian pembaruan 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 mirip Tradefed. Seperti direktori templat 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 siap pakai yang diperlukan oleh pengujian.

Membuat pembaruan zona waktu

Saat IANA merilis serangkaian aturan zona waktu baru, tim pustaka inti Android membuat patch untuk memperbarui rilis di AOSP. OEM yang menggunakan sistem Android dan file distro bawaan dapat mengambil komitmen ini, menggunakannya untuk membuat versi baru aplikasi Data mereka, lalu merilis versi baru untuk memperbarui 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 memberikan update untuk perangkat Android 8.1, 9, dan 10, mereka harus menyelesaikan prosesnya sebanyak tiga kali.

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

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

Patch AOSP system/timezone berisi file yang diperbarui di system/timezone/input_data dan system/timezone/output_data . OEM yang perlu melakukan perbaikan lokal tambahan dapat memodifikasi file input kemudian menggunakan file di system/timezone/input_data dan external/icu untuk menghasilkan file di output_data .

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

Langkah 2: Memperbarui kode versi aplikasi Data

Pada langkah ini, OEM memperbarui kode versi aplikasi Data. Build secara otomatis mengambil distro.zip , namun versi baru aplikasi Data harus memiliki kode versi baru sehingga dikenali sebagai baru dan digunakan untuk menggantikan aplikasi Data yang dimuat sebelumnya atau aplikasi Data yang diinstal pada perangkat dengan pembaruan sebelumnya.

Saat membuat 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 dari versi citra sistem). Untuk 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: Membangun kembali, menandatangani, menguji, dan merilis

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

  • Untuk perangkat yang belum dirilis (atau saat mempersiapkan pembaruan sistem untuk perangkat yang dirilis), kirimkan APK baru di direktori aplikasi Data yang sudah dibuat sebelumnya untuk memastikan bahwa citra sistem dan pengujian xTS memiliki APK terbaru. OEM harus menguji apakah file baru berfungsi dengan benar (yaitu, lulus CTS dan pengujian otomatis dan manual khusus OEM).
  • Untuk perangkat yang dirilis dan tidak lagi menerima pembaruan sistem, APK yang ditandatangani mungkin hanya dirilis melalui app store.

OEM bertanggung jawab atas jaminan kualitas dan pengujian aplikasi Data yang diperbarui pada 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 pembaruan sistem diterima yang berisi APK yang lebih lama dari yang diunduh dari toko aplikasi, versi toko aplikasi harus dipertahankan.

Kode versi APK harus menyertakan informasi berikut:

  • Versi format distro (mayor + 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 yang 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 versi 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 mereka tangani.

Pemeriksaan versi
Gambar 6. Contoh strategi kode versi
Contoh Nilai Tujuan
Y Disimpan Memungkinkan skema alternatif/APK pengujian di masa mendatang. Awalnya (secara implisit) 0. Karena tipe dasarnya adalah tipe int 32-bit yang ditandatangani, skema ini mendukung hingga dua revisi skema penomoran di masa depan.
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. Kecil kemungkinannya untuk mencapai 100 mengingat perkiraan kenaikan besar per level API. Versi utama 1 setara dengan API level 27.
1 Versi format kecil Melacak versi format minor 3 digit desimal. Format distro mendukung 3 digit desimal tetapi hanya 1 digit yang digunakan di sini. Kecil kemungkinannya untuk mencapai 10.
X Disimpan Bernilai 0 untuk rilis produksi (dan mungkin berbeda untuk APK pengujian).
ZZZZZ Nomor versi buram Nomor desimal dialokasikan sesuai permintaan. Termasuk celah untuk memungkinkan pembaruan interstisial dilakukan jika diperlukan.

Skema ini dapat dikemas lebih baik jika biner digunakan daripada desimal, namun skema ini memiliki keuntungan karena dapat dibaca manusia. Jika rentang nomor lengkap 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 ditunjukkan pada tabel berikut.

# Kode versi minSdkVersion {Versi format mayor},{Versi format minor},{Versi aturan IANA},{Revisi}
1 11000010 O-MR1 mayor=001,minor=001,iana=2017a,revisi=1
2 21000010 P mayor=002,minor=001,iana=2017a,revisi=1
3 11000020 O-MR1 mayor=001,minor=001,iana=2017a,revisi=2
4 11000030 O-MR1 mayor=001,minor=001,iana=2017b,revisi=1
5 21000020 P mayor=002,minor=001,iana=2017b,revisi=1
6 11000040 O-MR1 mayor=001,minor=001,iana=2018a,revisi=1
7 21000030 P mayor=002,minor=001,iana=2018a,revisi=1
8 1123456789 - -
9 11000021 O-MR1 mayor=001,minor=001,iana=2017a,revisi=2,respin=2
  • Contoh 1 dan 2 menunjukkan dua versi APK untuk rilis IANA 2017a yang sama dengan versi format utama 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 jumlahnya lebih tinggi, rilis tersebut menggantikan rilis IANA sebelumnya/revisi Android dari masing-masing pendahulunya.
  • Contoh 6 dan 7 menunjukkan rilis 2018a untuk O-MR1 dan P.
  • Contoh 8 mendemonstrasikan penggunaan Y untuk sepenuhnya menggantikan skema Y=0.
  • Contoh 9 mendemonstrasikan penggunaan celah tersisa antara 3 dan 4 untuk memutar ulang apk.

Karena setiap perangkat dikirimkan dengan APK default dengan versi yang sesuai pada image sistem, tidak ada risiko versi O-MR1 diinstal pada perangkat P karena nomor versinya lebih rendah daripada versi image sistem P. Perangkat dengan versi O-MR1 terinstal di /data yang kemudian menerima pembaruan sistem ke P menggunakan versi /system dibandingkan 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 citra sistem dengan benar. Aplikasi Data dimaksudkan untuk dibuat dengan build tapas yang menghasilkan APK yang sesuai untuk ditambahkan ke image sistem (untuk rilis awal) dan ditandatangani serta didistribusikan melalui app store (untuk pembaruan berikutnya).

Tapas adalah versi lebih ramping dari sistem build Android yang menggunakan pohon sumber yang diperkecil untuk menghasilkan versi aplikasi yang dapat didistribusikan. OEM yang akrab dengan sistem build Android normal harus mengenali file build dari build platform Android normal.

Membuat manifes

Pohon sumber yang diperkecil biasanya dicapai dengan file manifes khusus yang hanya merujuk pada proyek Git yang diperlukan oleh sistem pembangunan dan untuk membangun aplikasi. Setelah mengikuti instruksi dalam Membuat aplikasi Data , OEM harus memiliki setidaknya dua proyek Git khusus OEM yang dibuat dengan menggunakan file templat di bawah packages/apps/TimeZoneData/oem_template :

  • Satu proyek 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 proyek Git berisi APK bertanda tangan yang dihasilkan oleh build aplikasi untuk disertakan dalam build image sistem dan pengujian xTS.

Pembuatan aplikasi memanfaatkan beberapa proyek Git lain yang dibagikan dengan pembuatan platform atau berisi pustaka kode independen OEM.

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

   <!-- 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 pembangunan tapas

Setelah pohon sumber dibuat, aktifkan 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 menghasilkan file di direktori out/dist untuk pengujian. File-file ini dapat ditempatkan ke dalam direktori bawaan untuk disertakan dalam image sistem dan/atau didistribusikan melalui toko aplikasi untuk perangkat yang kompatibel.