Proses rilis Generic Kernel Image (GKI)

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.

Tabel berikut hanya berlaku untuk android14-6.1 dan android15-6.6.

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.

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

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 cabang android12-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 ke android12-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-08 dan android12-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:

1. 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.
2. Tim GKI Google akan meninjau permintaan tersebut dan menyetujuinya atau menetapkannya kembali kepada Anda jika diperlukan informasi lebih lanjut.
3. 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.
4. 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

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/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_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.