กระบวนการเผยแพร่อิมเมจ Kernel ทั่วไป (GKI)

หน้านี้อธิบายวิธีเผยแพร่ GKI ซึ่งรวมถึงการเผยแพร่รายสัปดาห์ รายไตรมาส และการเผยแพร่ฉุกเฉินนอกแบนด์ เป้าหมายของเอกสารนี้คือการให้คำแนะนำแก่ OEM เกี่ยวกับตำแหน่งที่จะรับ GKI รวมถึงกระบวนการแก้ไขฉุกเฉินนอกแบนด์ นอกจากนี้ OEM ยังใช้การพัฒนา GKI เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับวิธีทำงานร่วมกับทีม Android Kernel เพื่อเพิ่มประสิทธิภาพ เคอร์เนล GKI สำหรับผลิตภัณฑ์ของตนได้ด้วย

ความถี่ในการเผยแพร่ GKI

GKI จะเผยแพร่ทุกไตรมาสหลังจากที่ KMI หยุดการเปลี่ยนแปลง

ความถูกต้องของบิลด์ GKI สำหรับ OEM

OEM สามารถใช้ Android GKI ที่เพิ่งเปิดตัวได้ OEM สามารถเปิดตัวด้วยบิลด์ที่ได้รับการรับรอง GKI ได้ตราบใดที่เป็นไปตามข้อกำหนด LTS ในประกาศข่าวสารด้านความปลอดภัยของ Android (ASB)

การเปิดตัวที่ได้รับการรับรองรายไตรมาส

การเผยแพร่ GKI ทุกไตรมาสจะมี boot.img ที่ผ่านการทดสอบแล้ว ซึ่งมีใบรับรองที่ Google แทรกไว้เพื่อยืนยันว่าไบนารีสร้างขึ้นจากซอร์สโค้ด พื้นฐานที่ทราบ

ในแต่ละไตรมาส ระบบจะเลือก GKI Quarterly Release Candidate (ไม่ได้รับการรับรอง) หลังจากวันที่สิ้นสุดการเช็คอิน ซึ่งโดยปกติคือบิลด์รายสัปดาห์ที่ 2 ของ เดือนนั้น หลังจากเลือกเวอร์ชันที่คาดว่าจะเผยแพร่ในไตรมาสแล้ว ระบบจะไม่ยอมรับการเปลี่ยนแปลงใหม่ ในรุ่นของเดือนนั้น ในช่วงเวลาที่ปิด เราจะแก้ไขได้เฉพาะข้อบกพร่องที่ทำให้การทดสอบล้มเหลวเท่านั้น รุ่นที่พร้อมใช้งานจะได้รับการประกันคุณภาพตามที่อธิบายไว้ในส่วนการ รับรอง GKI เพื่อให้มั่นใจว่าการทดสอบการปฏิบัติตามข้อกำหนดจะผ่านใน บิลด์ GSI+GKI ที่มีอุปกรณ์อ้างอิงและ Cuttlefish

รูปที่ 1 ลำดับเวลาการเผยแพร่ GKI

คุณสมบัติของ GKI

แหล่งที่มาของอาร์ติแฟกต์บิลด์

คุณสามารถรับอาร์ติแฟกต์สำหรับการเผยแพร่ทั้งหมดได้จาก ci.android.com

ดูข้อมูลเพิ่มเติมเกี่ยวกับ CI รวมถึงผลการทดสอบได้ในแดชบอร์ดการผสานรวมอย่างต่อเนื่องของ Android

คำถามที่พบบ่อย

คำถามที่พบบ่อยเกี่ยวกับการเผยแพร่ GKI มีดังนี้

เป็นไปได้ไหมที่จะสร้างไบนารี GKI ใหม่โดยอิงตาม GKI ที่เผยแพร่แล้ว

ใช่ เราเรียกการดำเนินการนี้ว่าการหมุนซ้ำ กระบวนการ Respin จะได้รับการสนับสนุนตราบใดที่บิลด์ GKI ที่เผยแพร่ (ซึ่งมีการขอ Respin) เป็นไปตามข้อกำหนด LTS ในประกาศข่าวสารด้านความปลอดภัยของ Android (ASB)

สร้างไบนารี GKI ซ้ำได้ไหม

ได้ ตัวอย่างเช่น

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

หากต้องการสร้างตัวอย่างซ้ำ ให้ดาวน์โหลด manifest_$id.xml และเรียกใช้คำสั่งต่อไปนี้

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

คุณสามารถดึงสำเนาอาร์ติแฟกต์ GKI ได้จาก out/.../dist

ไบนารี GKI (รวมถึงแพตช์การหมุนฉุกเฉิน) สร้างขึ้นในโค้ดเบสล่าสุดใช่ไหม

ไม่ได้ Respin จะมีเฉพาะแพตช์ที่อยู่เหนือเคอร์เนลที่ได้รับการรับรองรายไตรมาสซึ่งเลือกไว้ การส่งต่อเหล่านี้มีการแก้ไขข้อบกพร่องที่บล็อกการเปิดตัวทั้งหมด ที่ OEM รายงานจนถึงเวลาใดก็ตามโดยใช้รุ่นไตรมาสพื้นฐานที่เกี่ยวข้อง ดูตัวอย่างต่อไปนี้เกี่ยวกับวิธีที่สถานการณ์ประเภทนี้เกิดขึ้น

• OEM1 และ OEM2 ตัดสินใจใช้ไบนารี GKI ที่เผยแพร่ตั้งแต่เดือนพฤศจิกายน 2021
• OEM1 และ OEM2 พบปัญหาที่ต้องใช้แพตช์เพื่อรองรับการสนับสนุน แพตช์เหล่านี้ อาจแตกต่างกันหรือเหมือนกันก็ได้
• การรีสปินที่อยู่เหนือไบนารีของเดือนพฤศจิกายน 2021 มีการแก้ไขการบล็อกการเปิดตัว ที่ทั้ง OEM1 และ OEM2 รายงานในช่วงเวลาการรีสปิน แต่ไม่มีการแก้ไขอื่นๆ
• ปัญหาที่กล่าวถึงในหัวข้อย่อยที่ 2 จะรวมอยู่ใน GKI รุ่นรายไตรมาสต่อๆ ไปด้วย

การรีสปินในเดือนตุลาคมมีแพตช์ทั้งหมดที่ OEM ส่งมา แต่แพตช์อื่นๆ ของ OEM ส่งผลกระทบต่อเราเนื่องจากยังไม่ได้ทดสอบกับผลิตภัณฑ์ของเราโดยเฉพาะ เราจะรวมเฉพาะแพตช์ของเราได้ไหม

ซึ่งทำไม่ได้ เส้นทางการหมุนซ้ำ "ต่อ OEM" ไม่สามารถปรับขนาดได้ แต่ทีม GKI จะตรวจสอบการเปลี่ยนแปลงทุกรายการที่รวมอยู่ในการสร้างใหม่และทดสอบการเปลี่ยนแปลงกับฮาร์ดแวร์ทั้งหมดที่มีก่อนที่จะสร้างบิลด์ใหม่ หากทีม GKI พบว่าปัญหาเกิดขึ้นกับ OEM, อุปกรณ์ หรือ รุ่นใดรุ่นหนึ่งโดยเฉพาะ ทีม GKI จะตรวจสอบว่าโค้ดที่เพิ่มโดยการเปลี่ยนแปลงจะทำงานในอุปกรณ์ รุ่น หรือ SKU ที่ได้รับผลกระทบเท่านั้น

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

มีกรณีที่ Google ให้ข้อมูลเฉพาะเกี่ยวกับแพตช์ของ OEM และสถานการณ์ปัญหาเพื่อให้ OEM ประเมินผลกระทบและความเสี่ยงของการใช้แพตช์กับผลิตภัณฑ์ของตนได้ไหม

Google จะไม่เพิ่มการเปลี่ยนแปลงลงในบิลด์ที่สร้างใหม่จนกว่าจะเข้าใจปัญหา และรวบรวมรายละเอียดทั้งหมดแล้ว ซึ่งจะเห็นได้ในบันทึกการเปลี่ยนแปลง (ข้อความคอมมิต) Google ไม่ได้ระบุว่าอุปกรณ์ใดที่ได้รับผลกระทบ แต่ OEM สามารถดูคำอธิบายปัญหาและวิธีแก้ปัญหาได้เสมอในบันทึกการเปลี่ยนแปลง