รูปแบบการกำหนดเวอร์ชัน GKI

หน้านี้อธิบายรูปแบบการกำหนดเวอร์ชันสำหรับ Generic Kernel Images (GKI) Generic Kernel Image (GKI) มีตัวระบุที่ไม่ซ้ำกันที่เรียกว่า Kernel Release Kernel Release ประกอบด้วยเวอร์ชัน Kernel Module Interface (KMI) และระดับย่อย Kernel Release จะเฉพาะเจาะจงกับอิมเมจที่เผยแพร่ ในขณะที่เวอร์ชัน KMI แสดงถึงอินเทอร์เฟซที่ใช้สร้างรุ่น เวอร์ชัน KMI สามารถรองรับ Kernel Release หลายรายการ Kernel Release จะเชื่อมโยงกับเวอร์ชัน KMI เพียงเวอร์ชันเดียว ในกรณีที่ไม่น่าจะเกิดขึ้นที่ต้องมีการเปลี่ยนแปลง Kernel Module Interface ระบบจะวนซ้ำ KMI Generation เพื่อแสดงการเปลี่ยนแปลงในเวอร์ชัน KMI

สรุปคำศัพท์

ตารางต่อไปนี้สรุปคำศัพท์สำคัญที่ใช้ในหน้านี้และสำหรับการอัปเดต GKI

ตารางต่อไปนี้แสดงคำศัพท์อื่นๆ ที่เกี่ยวข้องเพื่อใช้อ้างอิง

การออกแบบการกำหนดเวอร์ชัน

Kernel Release

คำจำกัดความ

สำหรับอุปกรณ์ที่มาพร้อมกับ GKI ระบบจะกำหนด Kernel Release ดังนี้

KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w      .x         .y       -zzz           -k            -something

ดูข้อมูลเพิ่มเติมได้ที่การระบุ Kernel Release จาก อุปกรณ์

ต่อไปนี้เป็นตัวอย่างของ Kernel Release

5.4.42-android12-0-00544-ged21d463f856

คำอธิบาย

Kernel Release คือรหัสที่ไม่ซ้ำกันของ GKI Release หากไบนารี GKI 2 รายการมี Kernel Release เดียวกัน ไบนารีทั้ง 2 รายการจะต้องเหมือนกันทุกไบต์

Kernel Release ประกอบด้วยเวอร์ชัน KMI, ระดับย่อย และคำต่อท้าย สำหรับเอกสารนี้ ระบบจะเพิกเฉยต่อคำต่อท้ายหลังจาก KMI Generation

เวอร์ชัน KMI

คำจำกัดความ

ระบบจะกำหนดเวอร์ชัน KMI ดังนี้

KmiVersion :=
Version.PatchLevel-AndroidRelease-KmiGeneration
w      .x         -zzz           -k

โปรดทราบว่าระดับย่อย y ไม่ได้เป็นส่วนหนึ่งของเวอร์ชัน KMI สำหรับตัวอย่าง ใน Kernel Release เวอร์ชัน KMI คือ

5.4-android12-0

คำอธิบาย

เวอร์ชัน KMI อธิบาย Kernel Module Interface (KMI) ระหว่าง GKI กับ Kernel Module (DLKM) ที่โหลดแบบไดนามิก

หาก Kernel Release 2 รายการมีเวอร์ชัน KMI เดียวกัน แสดงว่าทั้ง 2 รายการใช้ Kernel Module Interface เดียวกัน และ DLKM ที่เข้ากันได้กับรายการหนึ่งจะเข้ากันได้กับอีกรายการหนึ่งด้วย

การอัปเดต OTA จะต้องไม่ลดเวอร์ชัน KMI

ระดับย่อย

ระดับย่อย y อธิบายลำดับการเผยแพร่ของ Kernel Release ภายในเวอร์ชัน KMI เดียวกัน

สำหรับ Kernel Release 2 รายการที่มีเวอร์ชัน KMI เดียวกัน แต่มีระดับย่อย Y1 และ Y2 ตามลำดับ ให้ทำดังนี้

• หาก Y1 น้อยกว่าหรือเท่ากับ Y2 อุปกรณ์ที่ใช้ Y1 จะได้รับการอัปเดตเป็น Y2
• หาก Y1 มากกว่า Y2 อุปกรณ์ที่ใช้ Y1 จะอัปเดตเป็น Y2 ไม่ได้

นั่นคือ หากเวอร์ชัน KMI ไม่เปลี่ยนแปลง การอัปเดต OTA จะต้องไม่ลดระดับย่อย

ระบุ Kernel Release จากอุปกรณ์

คุณดู Kernel Release แบบเต็มได้โดยเรียกใช้ uname -r หรือ uname(2) ด้วยข้อมูลโค้ดต่อไปนี้

std::string get_kernel_release() {
  struct utsname buf;
  return uname(&buf) == 0 ? buf.release : "";
}

ตัวอย่างเอาต์พุต

5.4.42-android12-0-00544-ged21d463f856

สำหรับเอกสารนี้ ระบบจะเพิกเฉยต่อข้อมูลใดๆ หลังจาก KMI Generation เมื่อแยกข้อมูลเคอร์เนล หรือพูดอย่างเป็นทางการมากขึ้นได้ว่า ระบบจะแยกวิเคราะห์เอาต์พุตของ uname -r ด้วย Regex ต่อไปนี้ (สมมติว่า zzz เริ่มต้นด้วย "android" เสมอ)

^(?P<w>\d+)[.](?P<x>\d+)[.](?P<y>\d+)-(?P<z>android\d+)-(?P<k>\d+).*$

ข้อมูลที่ระบบเพิกเฉยอาจรวมถึงข้อมูลต่างๆ เช่น หมายเลขบิลด์ ci.android.com, จำนวน แพตช์ที่อยู่เหนือเคอร์เนลพื้นฐาน และแฮช SHA ของ Git Commit

libkver

ไลบรารี libkver มีอินเทอร์เฟซ C++ สำหรับแยกวิเคราะห์สตริง Kernel Release หรือเวอร์ชัน KMI ดูรายการ API ที่ libkver แสดงได้ที่ packages/modules/Gki/libkver/include/kver

การตรวจสอบ VINTF

สำหรับ Android 11 หรือต่ำกว่า ผู้ผลิตอุปกรณ์จะระบุส่วน Android Release ของเวอร์ชัน KMI ในไฟล์ Manifest ของอุปกรณ์ด้วยตนเอง ดูรายละเอียดได้ที่ ดู กฎการจับคู่เคอร์เนล VINTF

ตั้งแต่ Android S เป็นต้นไป ระบบจะแยกส่วน Android Release ของเวอร์ชัน KMI ออกจากเคอร์เนลและแทรกลงในไฟล์ Manifest ของอุปกรณ์ในเวลาบิลด์

เนื่องจากข้อกำหนดการกำหนดค่าเคอร์เนลโดยทั่วไปจะไม่เปลี่ยนแปลง คุณจึงไม่จำเป็นต้องเข้ารหัส k ภายในเมทริกซ์ความเข้ากันได้ อย่างไรก็ตาม ในกรณีที่ไม่น่าจะเกิดขึ้นที่ต้องมีการเปลี่ยนแปลงข้อกำหนดการกำหนดค่าเคอร์เนล ให้ตรวจสอบสิ่งต่อไปนี้

• นำข้อกำหนดที่เกี่ยวข้องออกจากเมทริกซ์ความเข้ากันได้
• เพิ่มการทดสอบ VTS เพิ่มเติมเพื่อตรวจสอบข้อกำหนดใหม่ตามเงื่อนไข KMI Generation

เวอร์ชันอิมเมจบูตในข้อมูลเมตาของ OTA

แม้ว่าอิมเมจบูตจะได้รับการอัปเดตผ่าน OTA แต่ก็ต้องห่อหุ้มในรูปแบบเพย์โหลด OTA, payload.bin เพย์โหลด OTA จะเข้ารหัสฟิลด์ version สำหรับแต่ละพาร์ติชัน เมื่อ update_engine จัดการเพย์โหลด OTA ระบบจะเปรียบเทียบฟิลด์นี้เพื่อให้แน่ใจว่าพาร์ติชันจะไม่ถูกดาวน์เกรด

เพื่อหลีกเลี่ยงความสับสน เราจึงเรียกฟิลด์ version สำหรับพาร์ติชันบูตในข้อมูลเมตาของ OTA ว่า boot image version

เนื่องจากระบบจะสร้าง Ramdisk ใหม่ทั้งหมด การใช้การประทับเวลา Ramdisk จึงเพียงพอที่จะอธิบายอิมเมจบูตทั้งหมด คุณไม่จำเป็นต้องเข้ารหัส Kernel Release ในเวอร์ชันอิมเมจบูต เว้นแต่ว่าคุณจะรวมอิมเมจบูตเก่าเข้ากับไบนารีเคอร์เนลใหม่ในอนาคต

ก่อนการอัปเดต OTA ไคลเอ็นต์ OTA จะตรวจสอบเวอร์ชันอิมเมจบูตในลักษณะเดียวกับพาร์ติชันอื่นๆ