Proses rilis Generic Kernel Image (GKI)

Halaman ini menjelaskan cara GKI dirilis, termasuk rilis darurat di luar band dan per kuartal. Tujuan halaman ini adalah memberikan panduan kepada OEM tentang tempat untuk mengambil GKI serta proses untuk perbaikan darurat di luar band. OEM juga dapat menggunakan pengembangan GKI untuk mempelajari lebih lanjut cara mereka dapat bekerja sama dengan tim Kernel Android untuk mengoptimalkan kernel GKI untuk produk mereka.

Ritme rilis GKI

GKI dirilis setiap tiga bulan setelah pembekuan KMI.

Validitas build GKI untuk OEM

OEM dapat menggunakan GKI Android yang baru dirilis. OEM dapat meluncurkan build bersertifikasi GKI selama build tersebut mematuhi persyaratan kernel yang Didukung Jangka Panjang (LTS) dalam Android Security Bulletin (ASB).

Rilis bersertifikasi per kuartal

Rilis GKI per kuartal berisi boot.img yang telah diuji dan mencakup sertifikat yang disisipkan Google untuk membuktikan bahwa biner dibuat dari dasar kode sumber yang diketahui.

Setiap kuartal, kandidat rilis kuartalan GKI (tidak disertifikasi) dipilih setelah tanggal batas check-in. Setelah kandidat rilis kuartalan 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. Release candidate menjalani jaminan kualitas—seperti yang dijelaskan di bagian kualifikasi GKI—untuk memverifikasi bahwa uji kepatuhan lulus pada build GSI+GKI dengan perangkat referensi serta Cuttlefish.

Gambar 1. Linimasa rilis GKI

Kualifikasi GKI

Tempat mendapatkan artefak build

OEM dapat memperoleh artefak untuk semua rilis dari ci.android.com.

Anda dapat menemukan informasi selengkapnya tentang CI, termasuk hasil pengujian di dasbor Android Continuous Integration.

FAQ

Berikut beberapa pertanyaan umum (FAQ) terkait proses rilis GKI.

Apakah mungkin membuat biner GKI baru berdasarkan GKI yang sudah dirilis?

Ya, ini dikenal sebagai putaran ulang. Proses respin didukung selama build GKI yang dirilis (yang respinnya diminta) mematuhi persyaratan LTS dalam Android Security Bulletin (ASB).

Apakah mungkin mereproduksi biner GKI?

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 dibangun di codebase terbaru?

Tidak. Respin hanya berisi patch yang berada di atas kernel bersertifikasi kuartalan yang telah dipilih. Respin ini berisi semua perbaikan bug yang memblokir peluncuran yang dilaporkan hingga waktu tertentu oleh OEM yang menggunakan rilis triwulanan dasar yang sesuai. Lihat contoh berikut tentang cara terjadinya jenis skenario ini.

• 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 sama.
• Respin di atas biner November 2021 memiliki perbaikan pemblokiran peluncuran yang dilaporkan oleh OEM1 dan OEM2 selama periode respin, tetapi tidak ada yang lain.
• Masalah yang disebutkan dalam poin kedua juga disertakan dalam rilis kuartalan GKI berikutnya.

Respin bulan Oktober memiliki semua patch yang dikirimkan OEM, tetapi patch OEM lainnya memengaruhi kami, karena belum diuji secara khusus dengan produk kami. Apakah hanya patch kami yang dapat disertakan?

Hal ini tidak mungkin. Jalur respin untuk masing-masing OEM tidak dapat diskalakan. Sebagai gantinya, tim GKI memeriksa setiap perubahan yang masuk ke build respin dan menguji perubahan tersebut dengan semua hardware yang tersedia sebelum membuat build baru. Jika tim GKI menemukan bahwa masalah tersebut khusus untuk OEM, perangkat, atau model tertentu, tim GKI dapat memverifikasi 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 mereka temukan 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 pada build respin hingga tim GKI memahami masalah dan mengumpulkan semua detailnya. Anda dapat melihatnya di log perubahan (pesan commit). Google tidak mengungkapkan perangkat spesifik yang terpengaruh, tetapi OEM selalu dapat menemukan deskripsi dan solusi masalah dalam log perubahan.