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

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

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

GKI จะเผยแพร่เป็นรายเดือนหลังจากการหยุดให้บริการ KMI

รุ่น GKI ของ Android 13, 14 และ 15

ตารางต่อไปนี้ใช้กับandroid13-5.10, android13-5.15 และ android14-5.15 เท่านั้น

บิลด์ที่ผ่านการรับรองรายเดือนของ GKI	วันที่ปิดรับการเช็คอิน	วันที่พร้อมโหลดล่วงหน้าของ GKI	ยืนยันแล้วใช่ไหม
พฤศจิกายน	11 พฤศจิกายน 2024	27 พฤศจิกายน 2024	ใช่
มกราคม	14 มกราคม 2025	31 มกราคม 2025	ใช่
มีนาคม	14 มีนาคม 2025	31 มีนาคม 2025	ใช่

ตารางต่อไปนี้ใช้กับ android14-6.1 และ android15-6.6 เท่านั้น

บิลด์ที่ผ่านการรับรองรายเดือนของ GKI	วันที่ปิดรับการเช็คอิน	วันที่พร้อมโหลดล่วงหน้าของ GKI	ยืนยันแล้วใช่ไหม
ตุลาคม	1 ตุลาคม 2024	14 ตุลาคม 2024	ใช่
พฤศจิกายน	1 พฤศจิกายน 2024	15 พฤศจิกายน 2024	ใช่
ธันวาคม	2 ธันวาคม 2024	16 ธันวาคม 2024	ใช่
มกราคม	6 มกราคม 2025	22 มกราคม 2025	ใช่

รุ่น GKI ของ Android 12

หลังจากเดือนพฤษภาคม 2024 android12-5.10 GKI จะเผยแพร่เป็นรายไตรมาสและเผยแพร่ในช่วงกลางเดือน ตารางต่อไปนี้ใช้กับ android12-5.10 เท่านั้น

บิลด์ที่ผ่านการรับรองรายเดือนของ GKI	วันที่ปิดรับการเช็คอิน	วันที่พร้อมโหลดล่วงหน้าของ GKI	ยืนยันแล้วใช่ไหม
พฤศจิกายน	1 พฤศจิกายน 2024	15 พฤศจิกายน 2024	ใช่
กุมภาพันธ์	3 กุมภาพันธ์ 2025	17 กุมภาพันธ์ 2025	ใช่

ความถูกต้องของรุ่น GKI สำหรับ OEM

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

เวอร์ชันสำหรับนักพัฒนาซอฟต์แวร์รายสัปดาห์

ระบบจะทดสอบรุ่นต่างๆ ด้วย Cuttlefish เพื่อตรวจสอบว่ารุ่นดังกล่าวผ่านเกณฑ์คุณภาพขั้นต่ำ

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

เวอร์ชันที่ผ่านการรับรองรายเดือน

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

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

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

กระบวนการส่งแอปอีกครั้งในกรณีฉุกเฉิน

การรีสปินหมายถึงกระบวนการรวมรวมอีกครั้ง การสร้างใหม่ การทดสอบอีกครั้ง และการรับรองไบนารีอีกครั้งหลังจากการเผยแพร่เคอร์เนล GKI สู่สาธารณะ คุณสามารถขอส่งไฟล์ไบนารีที่ผ่านการรับรองอีกครั้งในกรณีต่อไปนี้

• วิธีอัปเดตรายการสัญลักษณ์
• วิธีใช้การแก้ไขข้อบกพร่อง รวมถึงข้อบกพร่องที่พบระหว่างการอนุมัติจากห้องทดลองของผู้ให้บริการ
• วิธีเพิ่มฮุกของผู้ให้บริการ
• วิธีใช้แพตช์กับฟีเจอร์ที่มีอยู่
• วิธีใช้แพตช์ความปลอดภัย (หลังจากผ่านไป 6 เดือน)

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

หลักเกณฑ์เกี่ยวกับคำขอหมุนใหม่

โปรดอ่านหลักเกณฑ์ต่อไปนี้ก่อนขอรับการตรวจสอบอีกครั้ง

• การรีสปินใช้ได้เฉพาะในสาขารุ่นหลังจากเปิดตัวรุ่นแรกแบบสาธารณะของบิลด์รายเดือนแล้วเท่านั้น

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

• เมื่อข้อกําหนดของ LTS ที่กําหนดโดยกระดานข่าวสารด้านความปลอดภัยของ Android (ASB) ทําให้สาขาไม่เป็นไปตามข้อกําหนด ระบบจะเลิกใช้งานสาขานั้น ระบบไม่ยอมรับคำขอ Respin สำหรับสาขาที่เลิกใช้งานแล้ว วันที่เลิกใช้งานสำหรับ Branch ของรุ่น GKI หนึ่งๆ จะรวมอยู่ในบันทึกประจำเดือนของบิลด์รุ่น GKI ในส่วนรุ่น เราจะอัปเดตข้อกำหนด LTS เป็นรายปีในเดือนพฤษภาคมและพฤศจิกายนเพื่อวางแผนในอนาคต ตัวอย่างเช่น ระบบจะไม่รองรับการส่งใหม่ของสาขา android12-5.10-2023-07 (5.10.177) หลังจากวันที่ 1 พฤษภาคม 2024 เนื่องจากสาขา android12-5.10-2023-07 (5.10.177) ไม่เป็นไปตามข้อกําหนด LTS ของ ASB-2024-05

• การรีสปินใช้ได้กับการแก้ไขข้อบกพร่องเร่งด่วน การอัปเดตรายการสัญลักษณ์ หรือการใช้แพตช์เพื่อแก้ไขฟีเจอร์ที่มีอยู่เท่านั้น

• แพตช์ทั้งหมดที่จะรวมไว้ในสาขารุ่นรายเดือนต้องผสานรวมไว้ในสาขาการพัฒนา GKI หลักแล้ว ตัวอย่างเช่น หากต้องใช้แพตช์สำหรับการรีสปิน android12-5.10-2022-09 แพตช์ดังกล่าวต้องผสานรวมกับ android12-5.10 แล้ว

• คุณต้องเลือกแพตช์จากสาขาการพัฒนา GKI หลักและอัปโหลดแพตช์ไปยังสาขารุ่นรายเดือน

• ในคำขอส่งงานอีกครั้ง คุณต้องกำหนดลำดับความสำคัญ (ความเร่งด่วน) ให้กับคำขอ ลำดับความสำคัญนี้จะช่วยให้ทีม GKI ช่วยเหลือพาร์ทเนอร์ได้ดีขึ้นและทันท่วงที สำหรับคำขอที่สำคัญหรือมีเวลาจำกัด ให้ทำเครื่องหมายลำดับความสำคัญเป็น P0 สำหรับคำขอ P0 และ P1 คุณต้องระบุเหตุผลของความเร่งด่วนด้วย ตารางต่อไปนี้แสดงการเชื่อมโยงระหว่างลำดับความสำคัญของข้อบกพร่องและเวลาในการแก้ไข (ESRT)

  ความสำคัญ	ESRT
  P0	2 วันทำการ
  P1	5 วันทำการ
  P2	10 วันทำการ
  P3	15 วันทำการ

• คุณต้องส่งคำขอส่งอีกครั้งแยกกันสำหรับแต่ละสาขารุ่น เช่น หากต้องส่งคำขอเข้าร่วมอีกครั้งสำหรับทั้ง android12-5.10-2022-08 และ android12-5.10-2022-09 คุณต้องสร้างคำขอเข้าร่วมอีกครั้ง 2 รายการ

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

• เพิ่มแท็กต่อไปนี้สำหรับ CL แต่ละรายการที่อยู่ระหว่างการพิจารณา

  • Bug: ต้องเพิ่มรหัสข้อบกพร่องลงในข้อความคอมมิตสำหรับ CL แต่ละรายการ
  • Change-Id: ต้องเหมือนกับ Change-Id ของการเปลี่ยนแปลงในสาขาฐาน

• หากคำขอส่งคำตอบอีกครั้งกำหนดให้คุณต้องตอบกลับ แต่คุณไม่ตอบกลับภายใน 3 วันทำการ ระบบจะลดระดับความสำคัญลง 1 ระดับ (เช่น P0 จะลดระดับเป็น P1) หากคุณไม่ตอบกลับเป็นเวลา 2 สัปดาห์ ระบบจะทําเครื่องหมายข้อบกพร่องว่าจะไม่แก้ไข (ล้าสมัย)

ส่งคำขอให้ประเมินใหม่

แผนภาพต่อไปนี้แสดงขั้นตอนการส่งอีกครั้ง กระบวนการจะเริ่มขึ้นเมื่อพาร์ทเนอร์ OEM (คุณ) ส่งคำขอส่งอีกครั้ง

รูปที่ 2 กระบวนการส่งอีกครั้ง

วิธีเข้าสู่กระบวนการส่งอีกครั้ง

1. กรอกแบบฟอร์มคำขอ Respin ของ GKI และติดต่อผู้จัดการลูกค้าด้านเทคนิคของ Google ทันที แบบฟอร์มนี้สร้างข้อบกพร่องของคำขอ GKI respin คุณจะ (ผู้ขอ) ทีม GKI และบุคคลที่คุณเพิ่มในรายชื่อสำเนาอีเมลของข้อบกพร่องเห็นข้อบกพร่องคำขอ Respin
   • หากมีวิธีแก้ไขแล้ว คำขอควรชี้ไปยังการส่งแพตช์ใน AOSP เพื่อให้ Google ตรวจสอบได้ หากส่งแพตช์ไม่ได้ คุณต้องแนบแพตช์เป็นไฟล์ข้อความมากับคำขอ
   • หากไม่มีวิธีแก้ไข คำขอต้องมีข้อมูลมากที่สุดเท่าที่จะเป็นไปได้ ซึ่งรวมถึงหมายเลขเวอร์ชันเคอร์เนลและบันทึก เพื่อให้ Google ช่วยแก้ไขข้อบกพร่องได้
2. ทีม GKI ของ Google จะตรวจสอบคำขอและอนุมัติคำขอดังกล่าว หรือส่งคำขอกลับให้คุณหากต้องการข้อมูลเพิ่มเติม
3. หลังจากตกลงกันว่าจะแก้ไขแล้ว ทีม GKI ของ Google จะตรวจสอบโค้ด (CR+2) การเปลี่ยนแปลง การตรวจสอบจะเริ่มกรอบเวลา ESRT ทีม GKI จะผสาน บิลด์ ทดสอบการเกิดปัญหาซ้ำ และรับรองการเปลี่ยนแปลง
4. เผยแพร่ไบนารีไปยัง ci.android.com กรอบเวลา ESRT สิ้นสุดลง และทีม GKI ของ Google ทำเครื่องหมายคำขอว่า "แก้ไขแล้ว" และอ้างอิงบิลด์ respin ระบบจะโพสต์บิลด์ Respin ไว้ในหน้าบิลด์รุ่นของ Generic Kernel Image (GKI) ด้วย

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

ประเภทของการสร้าง GKI	การบังคับใช้คุณภาพ	หมายเหตุ
รายสัปดาห์	การทดสอบ Cuttlefish บูต ข้อมูล VTS บางส่วน เซ็ตย่อยของ CTS	ไม่ได้รับการรับรอง สำหรับการทดสอบและการเปิดใช้งานอุปกรณ์ เท่านั้น ใช้เพื่อเปิดอุปกรณ์ไม่ได้
รายเดือน (ได้รับการรับรอง)	การทดสอบ Cuttlefish บูต VTS CTS การทดสอบฮาร์ดแวร์อ้างอิง บูต VTS CTS
การหมุนซ้ำ (ได้รับการรับรอง)	การทดสอบ Cuttlefish บูต VTS เซ็ตย่อยของ CTS การทดสอบอุปกรณ์อ้างอิง บูต VTS	สร้างขึ้นจากบิลด์ที่ผ่านการรับรอง GKI บิลด์จะได้รับการรับรองหลังจากผ่านคุณสมบัติ

แหล่งที่รับอาร์ติแฟกต์การสร้าง

คุณดูอาร์ติแฟกต์ของรุ่นทั้งหมดได้จาก ci.android.com

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

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

ต่อไปนี้คือคําถามที่พบบ่อยเกี่ยวกับกระบวนการเผยแพร่ GKI

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

ใช่ เรียกว่า "การเริ่มใหม่" ระบบรองรับกระบวนการส่งอีกครั้ง ตราบใดที่บิลด์ GKI ที่เผยแพร่ (ซึ่งมีการขอส่งอีกครั้ง) เป็นไปตามข้อกำหนด 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 (รวมถึงแพตช์การหมุนฉุกเฉิน) ในโค้ดเบสล่าสุดหรือไม่

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

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

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

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

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

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

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