Proses rilis Generic Kernel Image (GKI)

Halaman ini menjelaskan cara GKI dirilis, termasuk rilis darurat mingguan, per kuartal, dan di luar jadwal. Tujuan dokumen ini adalah untuk memberikan panduan kepada OEM tentang tempat 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 dengan build bersertifikasi GKI selama build tersebut mematuhi persyaratan LTS dalam Android Security Bulletin (ASB).

Rilis pengembangan mingguan

Biner GKI tersedia untuk layanan mandiri dari Android CI saat perubahan digabungkan. Build mingguan tidak akan disertifikasi, tetapi dapat digunakan sebagai dasar untuk pengembangan dan pengujian. Build mingguan tidak dapat digunakan untuk build perangkat produksi bagi pengguna akhir.

Rilis bersertifikasi per kuartal

Rilis triwulanan GKI 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, yang biasanya merupakan build mingguan kedua pada bulan tersebut. 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. Kandidat rilis menjalani jaminan kualitas—seperti yang dijelaskan di bagian kualifikasi GKI—untuk memastikan bahwa pengujian kepatuhan lulus pada build GSI+GKI dengan perangkat referensi serta cuttlefish.

Gambar 1. Linimasa rilis GKI

Proses putar ulang darurat

Respin mengacu pada proses penggabungan ulang, pembangunan ulang, pengujian ulang, dan sertifikasi ulang biner setelah rilis publik kernel GKI. Anda dapat meminta putaran ulang 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 secara otomatis digabungkan ke dalam 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 putaran ulang, perhatikan panduan berikut:

• Respin hanya diizinkan di cabang rilis setelah rilis publik awal build kuartalan diluncurkan.

• Permintaan respin hanya diterima untuk cabang rilis tertentu selama maksimal enam bulan setelah rilis publik awal. Setelah enam bulan, cabang hanya memenuhi syarat untuk respin patch keamanan yang dikutip dalam Android Security Bulletin.

• Jika persyaratan LTS , yang ditentukan oleh Android Security Bulletin (ASB) menyebabkan cabang tidak patuh, cabang tersebut tidak digunakan lagi. Permintaan re-spin untuk cabang yang tidak digunakan lagi tidak diterima. Tanggal penghentian untuk cabang rilis GKI tertentu disertakan dalam catatan build rilis GKI per kuartal di bagian Rilis. Untuk perencanaan mendatang, persyaratan LTS diperbarui setiap tahun pada bulan Mei dan November. 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.

• Respin hanya berlaku untuk perbaikan bug mendesak, update daftar simbol, atau untuk menerapkan patch guna memperbaiki fitur yang ada.

• Semua patch yang masuk ke cabang rilis per kuartal harus sudah digabungkan ke cabang pengembangan GKI utama. Misalnya, jika patch diperlukan untuk pengiriman ulang 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 per kuartal.

• Dalam permintaan putar ulang, Anda harus menetapkan prioritas (urgensi) untuk permintaan tersebut. Prioritas ini membantu tim GKI memberikan bantuan yang lebih baik kepada partner secara tepat waktu. Untuk permintaan penting atau mendesak, tandai prioritas sebagai P0. Untuk permintaan P0 dan P1, Anda juga harus membenarkan urgensinya. Tabel berikut memberikan pemetaan prioritas bug dan waktu penyelesaian (ESRT):

  Prioritas	ESRT
  P0	2 hari kerja
  P1	5 hari kerja
  P2	10 hari kerja
  P3	15 hari kerja

• Anda harus mengirimkan permintaan putaran ulang terpisah per cabang rilis. Misalnya, jika putar ulang diperlukan untuk android12-5.10-2022-08 dan android12-5.10-2022-09, Anda harus membuat dua permintaan putar ulang.

• Setelah build disediakan dan permintaan putaran ulang ditandai sebagai telah diperbaiki, Anda tidak boleh membuka kembali permintaan putaran ulang untuk menambahkan CL tambahan. Anda harus mengirimkan permintaan putaran ulang baru jika ada patch tambahan yang perlu digabungkan.

• Untuk setiap CL yang dipertimbangkan, tambahkan tag berikut.

  • Bug: ID bug harus ditambahkan ke pesan commit untuk setiap CL.
  • Change-Id: harus sama dengan Change-Id perubahan cabang dasar.

• Jika permintaan putaran ulang memerlukan respons Anda, dan Anda tidak merespons dalam waktu tiga hari kerja, prioritas akan diturunkan satu tingkat (misalnya, P0 diturunkan menjadi P1). Jika Anda tidak merespons selama dua minggu, bug akan ditandai sebagai Tidak Akan Diperbaiki (Tidak Berlaku).

Mengirimkan permintaan putaran ulang

Diagram berikut menunjukkan proses respin. Proses 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 putaran ulang 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 dan log kernel, sehingga Google dapat membantu men-debug masalah tersebut.
2. Tim GKI Google akan meninjau permintaan dan menyetujuinya atau menetapkannya kembali kepada Anda jika diperlukan informasi lebih lanjut.
3. Setelah perbaikan disepakati, tim GKI Google akan meninjau kode (CR+2) perubahan tersebut. Peninjauan dimulai dalam jangka waktu ESRT. Tim GKI menggabungkan, membangun, menguji regresi, dan mengesahkan perubahan.
4. Biner dirilis ke ci.android.com. Jangka waktu ESRT berakhir dan tim GKI Google menandai permintaan sebagai telah diperbaiki dan merujuk pada 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 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 menggunakan rilis triwulanan dasar yang sesuai. Lihat contoh berikut tentang cara terjadinya skenario jenis ini.

• OEM1 dan OEM2 memutuskan untuk menggunakan rilis biner GKI dari 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 triwulanan 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 "per-OEM" tidak dapat diskalakan. Sebagai gantinya, tim GKI memeriksa setiap perubahan yang masuk ke build respin, dan menguji perubahan 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 memastikan bahwa kode yang ditambahkan oleh perubahan hanya dieksekusi di perangkat, model, atau SKU yang terpengaruh.

Manfaat utama dari putaran ulang terpadu adalah setiap perangkat yang menggunakan dasar rilis yang sama akan saling diuntungkan, 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 masalahnya dipahami dan semua detailnya 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.