Halaman ini menjelaskan cara GKI dirilis, termasuk rilis mingguan, bulanan, dan rilis darurat di luar band. Tujuan dokumen ini adalah untuk memberi OEM panduan tentang tempat mengambil GKI serta proses perbaikan darurat di luar band. OEM juga dapat menggunakan pengembangan GKI untuk mempelajari lebih lanjut cara mereka dapat bekerja sama dengan tim Android Kernel untuk mengoptimalkan kernel GKI untuk produk mereka.
Ritme rilis GKI
GKI dirilis dengan ritme bulanan setelah pembekuan KMI.
Rilis GKI Android 13, 14, dan 15
Tabel berikut hanya berlaku untuk
android13-5.10,
android13-5.15,
dan
android14-5.15.
| Build bulanan bersertifikasi GKI | Batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| November | 11 November 2024 | 27 November 2024 | Ya |
| Januari | 14 Januari 2025 | 31 Januari 2025 | Ya |
| Maret | 14 Maret 2025 | 31 Maret 2025 | Ya |
Tabel berikut hanya berlaku untuk
android14-6.1
dan
android15-6.6.
| Build bulanan bersertifikasi GKI | Batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| Oktober | 1 Oktober 2024 | 14 Oktober 2024 | Ya |
| November | 1 November 2024 | 15 November 2024 | Ya |
| Desember | 2 Desember 2024 | 16 Desember 2024 | Ya |
| Januari | 6 Januari 2025 | 22 Januari 2025 | Ya |
Rilis GKI Android 12
Setelah Mei 2024, rilis GKI android12-5.10 akan memiliki ritme kuartalan dan
dipublikasikan pada pertengahan bulan.
Tabel berikut hanya berlaku untuk
android12-5.10.
| Build bulanan bersertifikasi GKI | Batas waktu check-in | Tanggal siap pramuat GKI | Dikonfirmasi? |
|---|---|---|---|
| November | 1 November 2024 | 15 November 2024 | Ya |
| Februari | 3 Februari 2025 | 17 Februari 2025 | Ya |
Validitas build GKI untuk OEM
OEM dapat menggunakan GKI Android yang baru dirilis. OEM dapat meluncurkan dengan build bersertifikasi GKI selama mematuhi persyaratan LTS di Android Security Bulletin (ASB).
Rilis pengembangan mingguan
Rilis diuji dengan Cuttlefish untuk memastikannya lulus standar kualitas minimum.Biner GKI tersedia untuk layanan mandiri dari Android CI saat perubahan digabungkan. Build mingguan tidak akan disertifikasi, meskipun dapat digunakan sebagai dasar pengukuran untuk pengembangan dan pengujian. Build mingguan tidak dapat digunakan untuk build perangkat produksi bagi pengguna akhir.
Rilis bersertifikasi bulanan
Rilis bulanan GKI berisi boot.img yang telah diuji dan menyertakan sertifikat yang dimasukkan Google
untuk membuktikan bahwa biner dibuat dari dasar pengukuran kode
sumber yang diketahui.
Setiap bulan, kandidat rilis bulanan GKI (tidak disertifikasi) dipilih setelah tanggal batas check-in, yang biasanya merupakan build mingguan kedua bulan tersebut. Setelah kandidat rilis bulanan dipilih, perubahan baru tidak akan diterima dalam rilis bulan tersebut. Selama periode jendela tertutup, hanya perbaikan untuk bug yang menyebabkan kegagalan pengujian yang dapat ditangani. Calon rilis menjalani jaminan kualitas—seperti yang dijelaskan di bagian kualifikasi GKI—untuk memastikan pengujian kepatuhan lulus build GSI+GKI dengan perangkat referensi serta cuttlefish.
Gambar 1. Linimasa rilis GKI
Proses respin darurat
Respin mengacu pada proses penggabungan ulang, pembuatan ulang, pengujian ulang, dan sertifikasi ulang biner setelah rilis publik kernel GKI. Anda dapat meminta respin biner bersertifikasi untuk salah satu keadaan berikut:
- Untuk memperbarui daftar simbol.
- Untuk menerapkan perbaikan pada bug, termasuk bug yang ditemukan selama persetujuan lab operator.
- Untuk menambahkan hook vendor.
- Untuk menerapkan patch ke fitur yang ada.
- Untuk menerapkan patch keamanan (setelah 6 bulan).
Patch keamanan otomatis digabungkan ke cabang rilis hingga 6 bulan setelah rilis cabang. Setelah batas waktu 6 bulan, Anda harus meminta respin untuk menerapkan patch keamanan ke cabang.
Panduan permintaan putaran ulang
Sebelum meminta respin, perhatikan panduan berikut:
Respins hanya diizinkan di cabang rilis setelah rilis publik awal build bulanan telah diluncurkan.
Permintaan re-spin hanya diterima untuk cabang rilis tertentu selama maksimal enam bulan setelah rilis publik awal. Setelah enam bulan, cabang hanya memenuhi syarat untuk respin untuk patch keamanan yang dikutip dalam Buletin Keamanan Android.
Jika persyaratan LTS, yang ditentukan oleh Android Security Bulletin (ASB) menyebabkan cabang tidak mematuhi persyaratan, cabang tersebut tidak digunakan lagi. Permintaan respin untuk cabang yang tidak digunakan lagi tidak diterima. Tanggal penghentian untuk cabang rilis GKI tertentu disertakan dalam catatan build rilis GKI bulanan di bagian Rilis. Untuk perencanaan mendatang, persyaratan LTS diperbarui pada bulan Mei dan November setiap tahun. Misalnya, cabang
android12-5.10-2023-07(5.10.177) tidak didukung untuk respin setelah 1 Mei 2024, karena cabangandroid12-5.10-2023-07(5.10.177) tidak mematuhi persyaratan LTS ASB-2024-05.Respins hanya berlaku untuk perbaikan bug mendesak, pembaruan daftar simbol, atau untuk menerapkan patch guna memperbaiki fitur yang ada.
Semua patch yang masuk ke cabang rilis bulanan harus sudah digabungkan ke cabang pengembangan GKI utama. Misalnya, jika patch diperlukan untuk respin
android12-5.10-2022-09, patch tersebut harus sudah digabungkan keandroid12-5.10.Anda harus memilih patch dari cabang pengembangan GKI utama dan mengupload patch ke cabang rilis bulanan.
Dalam permintaan respin, Anda harus menetapkan prioritas (urgensi) ke permintaan. Prioritas ini membantu tim GKI untuk membantu partner dengan lebih baik dan tepat waktu. Untuk permintaan yang penting atau mendesak, tandai prioritas sebagai P0. Untuk permintaan P0 dan P1, Anda juga harus membenarkan urgensi. Tabel berikut memberikan pemetaan prioritas bug dan waktu hingga penyelesaian (ESRT):
Prioritas ESRT P0 2 hari kerja P1 5 hari kerja P2 10 hari kerja P3 15 hari kerja
Anda harus mengirimkan permintaan respin terpisah per cabang rilis. Misalnya, jika respin diperlukan untuk
android12-5.10-2022-08danandroid12-5.10-2022-09, Anda harus membuat dua permintaan respin.Setelah build disediakan dan permintaan respin ditandai sebagai diperbaiki, Anda tidak boleh membuka kembali permintaan respin untuk menambahkan CL tambahan. Anda harus mengirimkan permintaan respin baru jika ada patch tambahan yang perlu digabungkan.
Untuk setiap CL yang sedang dipertimbangkan, tambahkan tag berikut.
Bug: ID bug harus ditambahkan ke pesan commit untuk setiap CL.Change-Id: harus sama dengan ID Perubahan perubahan cabang dasar.
Jika permintaan pengiriman ulang memerlukan respons Anda, dan Anda tidak merespons dalam tiga hari kerja, prioritasnya akan diturunkan satu tingkat (misalnya, P0 diturunkan menjadi P1). Jika Anda tidak merespons selama dua minggu, bug tersebut akan ditandai sebagai Tidak Akan Diperbaiki (Tidak Digunakan Lagi).
Mengirim permintaan respin
Diagram berikut menunjukkan proses respin. Proses ini dimulai saat Partner OEM (Anda) mengirimkan permintaan respin.
Gambar 2. Proses respin
Untuk memulai proses respin:
- Isi formulir permintaan Respin GKI.
dan segera hubungi Manajer Akun Teknis Google Anda. Formulir ini
membuat bug permintaan respin GKI. Bug permintaan Respin dapat dilihat oleh Anda
(peminta), tim GKI, dan individu tertentu yang Anda tambahkan ke
daftar CC bug.
- Jika Anda sudah memiliki perbaikan, permintaan harus mengarah ke pengiriman patch di AOSP agar Google dapat meninjaunya. Jika pengiriman patch tidak memungkinkan, patch harus dilampirkan sebagai file teks ke permintaan.
- Jika Anda tidak memiliki perbaikan, permintaan harus berisi sebanyak mungkin informasi, termasuk nomor versi kernel dan log, sehingga Google dapat membantu men-debug masalah.
- Tim GKI Google akan meninjau permintaan tersebut dan menyetujuinya atau menetapkannya kembali kepada Anda jika diperlukan informasi lebih lanjut.
- Setelah perbaikan disepakati, tim kode GKI Google akan meninjau (CR+2) perubahan tersebut. Peninjauan akan memulai jangka waktu ESRT. Tim GKI menggabungkan, mem-build, menguji untuk regresi, dan memberikan sertifikasi pada perubahan.
- Biner dirilis ke ci.android.com. Jangka waktu ESRT berakhir dan tim GKI Google menandai permintaan sebagai diperbaiki dan mereferensikan build respin. Build respin juga akan diposting di halaman build rilis Generic Kernel Image (GKI).
Kualifikasi GKI
| Jenis build GKI | Penerapan kualitas | Catatan |
|---|---|---|
| Mingguan | Pengujian sotong
|
|
| Bulanan (tersertifikasi) | Pengujian sotong
|
|
| Putar ulang (bersertifikasi) | Pengujian sotong
|
|
Tempat mendapatkan artefak build
Artefak untuk semua rilis dapat diperoleh dari ci.android.com.
Anda dapat menemukan informasi selengkapnya tentang CI, termasuk hasil pengujian di dasbor Continuous Integration Android.
FAQ
Berikut beberapa pertanyaan umum (FAQ) terkait proses rilis GKI.
Apakah mungkin untuk mem-build biner GKI baru berdasarkan GKI yang telah dirilis?
Ya, hal ini dikenal sebagai respin. Proses respin didukung selama build GKI yang dirilis (tempat respin diminta) mematuhi persyaratan LTS di Android Security Bulletin (ASB).
Apakah biner GKI dapat direproduksi?
Ya, berikut contohnya:
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Untuk mereproduksi contoh, download manifest_$id.xml dan jalankan perintah
berikut:
repo init -u https://android.googlesource.com/kernel/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
Anda dapat mengambil salinan artefak GKI dari out/.../dist.
Apakah biner GKI (termasuk patch spin darurat) telah dibuat di codebase terbaru?
Tidak. Respins hanya berisi patch yang berada di atas kernel tersertifikasi bulanan yang telah dipilih. Respin ini berisi semua perbaikan bug pemblokiran peluncuran yang dilaporkan hingga waktu tertentu oleh OEM menggunakan rilis bulanan dasar yang sesuai. Lihat contoh berikut tentang bagaimana jenis skenario ini terjadi.
- OEM1 dan OEM2 memutuskan untuk menggunakan rilis biner GKI mulai November 2021.
- OEM1 dan OEM2 menemukan masalah yang memerlukan patch untuk dukungan. Patch ini mungkin berbeda atau mungkin sama.
- Respin di atas biner November 2021 memiliki perbaikan pemblokiran peluncuran yang dilaporkan oleh OEM1 dan OEM2 selama periode respin, tetapi tidak ada lagi.
- Masalah yang disebutkan dalam butir kedua juga disertakan dalam rilis bulanan GKI berikutnya.
Respon ulang Oktober memiliki semua patch yang dikirimkan OEM, tetapi patch OEM lainnya memengaruhi kami, karena belum diuji secara khusus dengan produk kami. Apakah mungkin untuk hanya menyertakan patch kami?
Hal ini tidak mungkin. Jalur respin "per-OEM" tidak skalabel. Sebagai gantinya, tim GKI akan memeriksa setiap perubahan yang masuk ke build respin, dan menguji perubahan dengan semua hardware yang tersedia sebelum membuat build baru. Jika tim GKI mendapati bahwa masalah tersebut khusus untuk OEM, perangkat, atau model, tim GKI dapat memastikan bahwa kode yang ditambahkan oleh perubahan hanya dieksekusi di perangkat, model, atau SKU yang terpengaruh.
Manfaat utama dari respin terpadu adalah setiap perangkat yang menggunakan basis rilis yang sama akan saling mendapatkan manfaat, terutama jika bug yang ditemukan bersifat umum dan berlaku untuk semua pengguna. Bug kernel inti yang ditemukan dalam pengujian operator adalah contoh spesifik dari konsep ini.
Apakah ada situasi saat Google memberikan informasi spesifik tentang patch OEM dan skenario masalah, sehingga OEM dapat mengevaluasi dampak dan risiko penerapan patch dengan produk mereka?
Google tidak akan pernah menambahkan perubahan ke build respin hingga masalah dipahami dan semua detail telah dikumpulkan. Hal ini terlihat di log perubahan (pesan commit). Google tidak mengungkapkan perangkat spesifik yang terpengaruh, tetapi OEM selalu dapat menemukan deskripsi dan solusi masalah dalam log perubahan.