תהליך הפצה גנרי של תמונת ליבה (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) במקרה חירום

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

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

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

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

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

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

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

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

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

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

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

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

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

הסמכות GKI

איפה אפשר לקבל ארטיפקטים של גרסאות build

אפשר לקבל את הארטיפקטים של כל הגרסאות המהדורות בכתובת 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

אפשר לאחזר את העותק של הארטיפקט של 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 יגלה שהבעיה ספציפית ליצרן ציוד מקורי, למכשיר או לדגם מסוימים, הוא יוכל לוודא שהקוד שנוסף בעקבות השינוי יפעל רק במכשיר, בדגם או במק"ט הרלוונטיים.

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

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

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