תהליך הפצה גנרי של תמונת ליבה (GKI)

בדף הזה מתואר אופן ההשקה של GKI, כולל השקות שבועיות, חודשיות ומקרי חירום מחוץ למסגרת. מטרת המסמך הזה היא לספק ליצרני ציוד מקורי הנחיות לגבי המקומות שבהם אפשר לקבל את GKI, וגם את התהליך לקבלת תיקוני חירום מחוץ לתהליך התקינה הרגיל. יצרני ציוד מקורי יכולים גם להיעזר בפיתוח של GKI כדי לקבל מידע נוסף על האופן שבו הם יכולים לעבוד עם צוות הליבה של Android כדי לבצע אופטימיזציה של הליבה של GKI למוצרים שלהם.

קצב השקת הגרסאות של GKI

GKI משוחרר בתדירות חודשית אחרי הקפאת KMI.

גרסה של GKI ל-Android 13,‏ 14 ו-15

הטבלה הבאה רלוונטית רק ל-android13-5.10, ל-android13-5.15 ול-android14-5.15.

הטבלה הבאה רלוונטית רק ל-android14-6.1 ול-android15-6.6.

גרסה של GKI ל-Android 12

אחרי מאי 2024, הגרסאות של android12-5.10 GKI יפורסמו ברבעון ויפורסמו באמצע החודש. הטבלה הבאה רלוונטית רק ל-android12-5.10.

תקינות גרסאות build של GKI ליצרני ציוד מקורי

יצרני ציוד מקורי יכולים להשתמש ב-Android GKI שפורסם לאחרונה. יצרני ציוד מקורי יכולים להשיק גרסאות build שאושרו על ידי GKI כל עוד הן עומדות בדרישות LTS שמפורטות בעדכון האבטחה של Android‏ (ASB).

גרסאות פיתוח שבועיות

קובצי ה-binaries של GKI זמינים בשירות עצמי ב-Android CI, כשהשינויים מתמזגים. גרסאות build שבועיות לא יאושרו, אבל אפשר להשתמש בהן כבסיס לפיתוח ולבדיקה. אי אפשר להשתמש בגרסאות build שבועיות לגרסאות build של מכשירי ייצור למשתמשי קצה.

גרסאות מוסמכות חודשיות

הגרסאות החודשיות של GKI מכילות קובץ boot.img שנבדק, שכולל אישור שהוכנס על ידי Google כדי לאמת שהקובצי הבינאריים נוצרו מבסיס קוד מקור ידוע.

בכל חודש, נבחר גרסה מועמדת להפצה חודשית של GKI (לא מאושרת) אחרי תאריך הסגירה של ההוספה למאגר, שהוא בדרך כלל ה-build השבועי השני באותו חודש. אחרי שבוחרים את הגרסה החודשית המועמדת להפצה, לא נקבל שינויים חדשים לגרסה של אותו חודש. במהלך תקופת החלון הסגור אפשר לטפל רק בתיקונים של באגים שגורמים לכשל בבדיקה. גרסת המועמדת להפצה עוברת בדיקות איכות – כפי שמתואר בקטע ההסמכה של GKI – כדי לוודא שבדיקות התאימות עוברות ב-build של GSI+GKI במכשיר עזר וגם ב-cuttlefish.

איור 1. ציר הזמן להשקת GKI

תהליך סגירה מחדש במקרה חירום

respin מתייחס לתהליך של מיזוג מחדש, בנייה מחדש, בדיקה מחדש ואישור מחדש של קובץ בינארי אחרי השקה ציבורית של הליבה של GKI. אפשר לבקש גרסת respin של קובץ בינארי מאושר בכל אחד מהמקרים הבאים:

• כדי לעדכן רשימת סמלים.
• כדי לתקן באג, כולל באגים שזוהו במהלך האישור במעבדה של הספק.
• כדי להוסיף הוק של ספק.
• כדי להחיל תיקון על תכונה קיימת.
• כדי להחיל תיקון אבטחה (אחרי 6 חודשים).

תיקוני אבטחה מוזגו באופן אוטומטי להסתעפות של הגרסה במשך עד 6 חודשים אחרי השקת ההסתעפות. אחרי 6 חודשים, תצטרכו לבקש respin כדי להחיל תיקוני אבטחה על ההסתעפות.

הנחיות לשליחת בקשה להעלאת גרסת build מחדש

לפני ששולחים בקשה לבדיקה חוזרת, חשוב לקרוא את ההנחיות הבאות:

• אפשר להשתמש בספינינג רק בהסתעפויות הפצה אחרי השקת הפצה ציבורית ראשונית של build חודשי.

• בקשות Respin מתקבלות רק עבור הסתעפות נתונה למשך שישה חודשים לכל היותר לאחר ההשקה הציבורית הראשונית. אחרי שישה חודשים, אפשר לבצע respin להסתעפויות רק עבור תיקוני אבטחה שצוינו בעדכון אבטחה של Android.

• אם ההסתעפות לא עומדת בדרישות LTS שמוגדרות בעדכון האבטחה של Android‏ (ASB), ההסתעפות הזו תוסר משימוש. לא נקבל בקשות להעלאת גרסה מחדש להסתעפויות שהוצאו משימוש. תאריך ההוצאה משימוש של גרסה מסוימת של GKI מופיע בהערות החודשיות לגבי גרסאות build של GKI בקטע Releases. כדי לתכנן את העתיד, הדרישות ל-LTS מתעדכנות מדי שנה במאי ובנובמבר. לדוגמה, ההסתעפות android12-5.10-2023-07 (5.10.177) לא נתמכת ב-respins אחרי 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 ימי עסקים

• צריך לשלוח בקשה נפרדת ל-respin לכל סניף של גרסה. לדוגמה, אם צריך לבצע שליחה חוזרת גם של android12-5.10-2022-08 וגם של android12-5.10-2022-09, צריך ליצור שתי בקשות שליחה חוזרת.

• אחרי ששולחים גרסה מתוכננת (build) ובקשת respin מסומנת כ'תוקנה', אסור לפתוח מחדש את בקשת ה-respin כדי להוסיף עוד CLs. אם יש תיקונים נוספים שצריך למזג, צריך לשלוח בקשה חדשה להוספת תיקון.

• לכל בקשת תמיכה שרוצים לבדוק, מוסיפים את התגים הבאים.

  • Bug: צריך להוסיף את מזהה הבאג להודעת השמירה של כל CL.
  • Change-Id: חייב להיות זהה ל-Change-Id של השינוי בהסתעפות הבסיסית.

• אם תתבקשו להשיב לבקשת שליחת בקשה חוזרת, ולא תשיגו זאת תוך שלושה ימי עסקים, רמת העדיפות תרד במקום אחד (לדוגמה, P0 תרד ל-P1). אם לא תגיבו במשך שבועיים, הבאג יסומן כ-Won't Fix (מיושן).

שליחת בקשה לשליחת גרסת build מחדש

בתרשים הבא מוצג תהליך ה-respin. התהליך מתחיל כששותף ה-OEM (אתם) שולח את הבקשה לסיבוב חוזר.

איור 2. תהליך ה-respin

כדי להתחיל בתהליך ה-respin:

1. ממלאים את טופס הבקשה ל-GKI Respin ופונים מיד למנהל החשבון הטכני שלכם ב-Google. הטופס הזה יוצר באג בבקשה להצמדה מחדש של GKI. באגים שנשלחים בבקשה ל-respin גלויים לכם (מגיש הבקשה), לצוות GKI ולאנשים ספציפיים שתוסיפו לרשימת הנמענים.
   • אם כבר יש לכם תיקון, הבקשה צריכה להפנות לתיקון שנשלח ל-AOSP כדי ש-Google תוכל לבדוק אותו. אם אי אפשר לשלוח את התיקון, צריך לצרף אותו לבקשה כקובץ טקסט.
   • אם אין תיקון, הבקשה צריכה להכיל כמה שיותר מידע, כולל מספר גרסת הליבה ויומנים כדי ש-Google תוכל לעזור לנפות את הבאגים שגרמו לבעיה.
2. צוות GKI של Google יבדוק את הבקשה ויאשר אותה, או יחזיר אותה אליכם אם יידרש מידע נוסף.
3. לאחר שהוסכם על תיקון, הקוד של צוות Google GKI יבדוק (CR+2) את השינוי. הבדיקה מתחילה במסגרת הזמן של ESRT. צוות GKI מבצע מיזוג, פיתוח, בדיקות לזיהוי רגרסיה ואישור של השינוי.
4. הקובץ הבינארי משוחרר ל-ci.android.com. מסגרת הזמן של ה-ESRT מסתיימת וצוות Google GKI מסמן את הבקשה כקבועה ומפנה את ה-build החלופי. גרסה מחודשת של ה-build תפורסם גם בדף של גרסאות build של Generic Kernel Image‏ (GKI).

הסמכות GKI

איפה אפשר לקבל את ארטיפקטי ה-build

אפשר למצוא את פריטי המידע שנוצרו בתהליך הפיתוח (Artifact) של כל הגרסאות בכתובת ci.android.com.

מידע נוסף על CI, כולל תוצאות הבדיקה, זמין בלוח הבקרה של Android Continuous Integration.

שאלות נפוצות

ריכזנו כאן כמה שאלות נפוצות שקשורות לתהליך השחרור של GKI.

האם אפשר ליצור קובץ GKI בינארי חדש על סמך GKI שכבר שוחרר?

כן, הפעולה הזו נקראת 'שליחת בקשה חוזרת'. תהליך ה-respin נתמך כל עוד גרסה ה-build של 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

אפשר לאחזר את עותק של פריט המידע שנוצר בתהליך הפיתוח (Artifact) של GKI מ-out/.../dist.

האם הקובץ הבינארי של GKI (כולל תיקון ה-spin למקרה חירום) נוצר על קוד הבסיס העדכני ביותר?

לא. גרסת Respins מכילה רק תיקונים שמתווספים לליבות המאושרות החודשיות שנבחרו. הגרסאות האלה מכילות את כל תיקוני הבאגים שמונעים את ההשקה, שדווחו על ידי יצרני ציוד מקורי (OEM) עד לאותו זמן באמצעות הגרסה הבסיסית החודשית המתאימה. בדוגמה הבאה מוסבר איך מתרחש תרחיש כזה.

• יצרני הציוד המקורי (OEM1 ו-OEM2) מחליטים להשתמש במהדורה הבינארית של GKI מנובמבר 2021.
• OEM1 ו-OEM2 מוצאים בעיות שדורשות תיקונים כדי לקבל תמיכה. התיקונים האלה עשויים להיות שונים או להיות זהים.
• בגרסאות ה-respin של הקובץ הבינארי מחודש נובמבר 2021 יש תיקונים לחסימה של ההשקה שדווחו על ידי OEM1 ו-OEM2 במהלך חלון ה-respin, אבל לא יותר מזה.
• הבעיות שצוינו בפסקה השנייה נכללות גם במהדורות החודשיות הבאות של GKI.

ב-respin של אוקטובר כל התיקונים שנשלחו על ידי יצרני ציוד מקורי (OEM), אבל תיקונים אחרים של יצרני ציוד מקורי משפיעים עלינו כי הם לא נבדקו באופן ספציפי עם המוצרים שלנו. האם אפשר לכלול רק את התיקון שלנו?

אי אפשר לעשות זאת. לא ניתן להתאים נתיב respin 'לכל יצרן ציוד מקורי'. במקום זאת, צוות GKI בודק היטב כל שינוי שמשולב בגרסאות build מחודשות, ובודק את השינויים בכל החומרה הזמינה לפני יצירת גרסה build חדשה. אם צוות GKI יגלה שהבעיה ספציפית ליצרן ציוד מקורי, למכשיר או לדגם מסוימים, הוא יוכל לוודא שהקוד שנוסף בעקבות השינוי יפעל רק במכשיר, בדגם או ב-SKU הרלוונטיים.

היתרון העיקרי של הוספות מאוחדות הוא שכל מכשיר שנעשה בו שימוש באותו בסיס הפצה מועיל זה לזה, במיוחד אם הבאגים שהם מגלים הם כלליים וחלים לכל המשתמשים. באגים ב-kernel של הליבה שנמצאו בבדיקות של ספקי הסלולר הם דוגמה ספציפית לכך.

האם יש מצבים שבהם Google מספקת מידע ספציפי על תיקוני OEM ותרחישי בעיות, כדי ש-OEM יוכלו להעריך את ההשפעה והסיכון של הטמעת התיקונים במוצרים שלהם?

Google לא תוסיף אף פעם שינוי לגרסה מחודשת של build עד שהבעיה תובהר וכל הפרטים ייאספו. הוא מופיע בהיסטוריית השינויים (הודעת ההתחייבות). Google לא חושפת איזה מכשיר ספציפי מושפע מהבעיה, אבל יצרני ציוד מקורי תמיד יכולים למצוא את תיאור הבעיה והפתרון ביומן השינויים.