Halaman ini menjelaskan skema pembuatan versi untuk Gambar Kernel Generik (GKI). Gambar Kernel Generik (GKI) memiliki pengidentifikasi unik yang disebut rilis kernel. Rilis kernel terdiri dari versi antarmuka modul kernel (KMI) dan sub-level. Rilis kernel khusus untuk image yang dirilis, sedangkan versi KMI mewakili antarmuka tempat rilis dibuat. Versi KMI dapat mendukung beberapa rilis kernel. Rilis kernel hanya terikat pada satu versi KMI. Jika antarmuka modul kernel harus diubah, pembuatan KMI akan diiterasi untuk mencerminkan perubahan dalam versi KMI.
Ringkasan istilah
Tabel berikut merangkum istilah-istilah penting yang digunakan di halaman ini dan untuk pembaruan GKI.
| Nama | Simbol | Contoh | Keterangan |
|---|---|---|---|
| Rilis kernel | akhiran wxy-zzz-k | 5.4.42-android12-0-foo | Pengenal unik untuk rilis GKI. Ini adalah nilai yang dikembalikan oleh uname . |
| versi KMI | wx-zzz-k | 5.4-android12-0 | Menjelaskan antarmuka modul kernel (KMI) antara GKI dan modul kernel yang dapat dimuat secara dinamis (DLKM). |
| Sub-tingkat | kamu | 42 | Menjelaskan urutan rilis rilis kernel dalam versi KMI yang sama. |
Tabel berikut mencantumkan istilah terkait lainnya sebagai referensi.
| Nama | Simbol | Contoh | Keterangan |
|---|---|---|---|
| wxy | wxy | 5.4.42 | Untuk detailnya, lihat Makefiles Kernel Linux (cari "KERNELRELEASE"). wxy digunakan langsung di seluruh dokumen ini. Ini juga biasa disebut sebagai nomor versi tiga bagian . Istilah yang digunakan dalam VINTF, versi kernel , mungkin menimbulkan kebingungan dengan istilah lain, terutama w . Variabel ini disebut sebagai kernel_version_tuple di libkver . Tupel ini tidak boleh dikurangi oleh pembaruan apa pun, termasuk OTA atau jalur utama. |
| Cabang kernel | zzz-wx | android12-5.4 | Istilah ini digunakan pada tipe cabang kernel umum . |
| Versi: kapan | w | 5 | Istilah ini tidak digunakan dalam dokumen ini. Variabel ini disebut sebagai versi di libkver . |
| tingkat tambalan | X | 4 | Istilah ini tidak digunakan dalam dokumen ini. Variabel ini disebut sebagai patch_level di libkver . |
| rilis Android | zzz | android12 | Ini adalah nomor rilis Android (makanan penutup) yang dikaitkan dengan kernel. Saat membandingkan kolom Nomor rilis Android tidak boleh dikurangi oleh pembaruan apa pun, termasuk OTA atau jalur utama. |
| generasi KMI | k | 0 | Ini adalah jumlah tambahan yang ditambahkan untuk menghadapi kejadian yang tidak terduga. Jika perbaikan bug keamanan memerlukan perubahan pada KMI dalam rilis Android yang sama, generasi KMI akan ditingkatkan. Nomor generasi KMI dimulai dengan 0. |
Desain versi
Rilis kernel
Definisi
Untuk perangkat yang dikirimkan bersama GKI, rilis kernel ditentukan sebagai berikut:
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
Untuk informasi lebih lanjut, lihat Menentukan rilis kernel dari suatu perangkat .
Berikut ini adalah contoh rilis kernel.
5.4.42-android12-0-00544-ged21d463f856
Keterangan
Rilis kernel adalah ID unik dari rilis GKI. Jika dua biner GKI memiliki rilis kernel yang sama, keduanya harus identik dalam hal byte.
Rilis kernel terdiri dari versi KMI, sub-level, dan akhiran. Untuk keperluan dokumen ini, akhiran setelah pembuatan KMI diabaikan.
versi KMI
Definisi
Versi KMI didefinisikan sebagai berikut:
KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w .x -zzz -k
Perhatikan bahwa sub-level, y bukan bagian dari versi KMI. Misalnya pada Kernel release , versi KMI adalah:
5.4-android12-0
Keterangan
Versi KMI menjelaskan antarmuka modul kernel (KMI) antara GKI dan modul kernel yang dapat dimuat secara dinamis (DLKM).
Jika dua rilis kernel memiliki versi KMI yang sama, keduanya mengimplementasikan antarmuka modul kernel yang sama. DLKM yang kompatibel dengan satu juga kompatibel dengan yang lain.
Versi KMI tidak boleh dikurangi oleh pembaruan OTA apa pun.
Sub-tingkat
Sub-level, y , menjelaskan urutan rilis rilis kernel dalam versi KMI yang sama.
Untuk dua rilis kernel yang memiliki versi KMI yang sama namun masing-masing memiliki sub-level Y1 dan Y2:
- Jika Y1 lebih kecil atau sama dengan Y2, perangkat yang menjalankan Y1 dapat menerima pembaruan ke Y2.
- Jika Y1 lebih besar dari Y2, perangkat yang menjalankan Y1 tidak dapat diperbarui ke Y2.
Artinya, jika versi KMI tidak berubah, sublevelnya tidak boleh diturunkan oleh pembaruan OTA apa pun.
Menentukan rilis kernel dari suatu perangkat
Rilis kernel lengkap dapat ditemukan dengan mengeksekusi uname -r , atau uname(2) dengan cuplikan kode berikut:
std::string get_kernel_release() {
struct utsname buf;
return uname(&buf) == 0 ? buf.release : "";
}
Contoh keluarannya adalah:
5.4.42-android12-0-00544-ged21d463f856
Untuk tujuan dokumen ini, apa pun setelah pembuatan KMI diabaikan saat mengekstraksi informasi kernel. Lebih formalnya, keluaran uname -r diurai dengan regex berikut (dengan asumsi zzz selalu dimulai dengan "android"):
^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$
Informasi yang diabaikan dapat mencakup informasi seperti nomor build ci.android.com , jumlah patch di atas kernel dasar, dan hash SHA dari git commit.
libkver
Pustakanya, libkver, menyediakan antarmuka C++ untuk mengurai rilis kernel atau string versi KMI. Untuk daftar API yang diekspos libkver, lihat packages/modules/Gki/libkver/include/kver .
pemeriksaan VINTF
Untuk Android 11 atau lebih rendah, bagian rilis Android dari versi KMI ditentukan secara manual di manifes perangkat oleh produsen perangkat. Untuk detailnya, lihat Aturan kecocokan kernel VINTF .
Dari Android S, bagian rilis Android versi KMI dapat diekstraksi dari kernel dan dimasukkan ke manifes perangkat pada waktu build.
Karena persyaratan konfigurasi kernel secara umum tidak berubah, tidak perlu mengkodekan k dalam matriks kompatibilitas. Namun, jika persyaratan konfigurasi kernel perlu diubah, pastikan hal berikut:
- Persyaratan yang sesuai dari matriks kompatibilitas dihapus.
- Tes VTS tambahan ditambahkan untuk memeriksa persyaratan baru yang bergantung pada pembuatan KMI.
Versi gambar boot dalam metadata OTA
Meskipun image booting diperbarui melalui pembaruan OTA, itu harus dibungkus dalam format payload OTA, payload.bin . Payload OTA mengkodekan kolom version untuk setiap partisi. Saat update_engine menangani payload OTA, ia membandingkan kolom ini untuk memastikan partisi tidak diturunkan versinya.
Untuk menghindari kebingungan, kolom version untuk partisi boot di metadata OTA disebut boot image version .
Karena ramdisk selalu dibuat dari awal, penggunaan stempel waktu ramdisk sudah cukup untuk mendeskripsikan keseluruhan image boot. Tidak perlu mengkodekan rilis kernel dalam versi image boot, kecuali Anda menjahit image boot lama ke biner kernel baru di masa mendatang.
Sebelum pembaruan OTA, klien OTA memeriksa versi image booting dengan cara yang sama seperti partisi lainnya.