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

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

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

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

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

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

גרסאות build מוסמכות חודשיות של GKI	תאריך הסגירה של צ'ק-אין	תאריך השלמת ההטענה מראש של GKI	מוכן?
נובמבר	11 בנובמבר 2024	27 בנובמבר 2024	כן
ינואר	17 בינואר 2025	31 בינואר 2025	כן
מרץ	14 במרץ 2025	31 במרץ 2025	כן

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

גרסאות build מוסמכות חודשיות של GKI	תאריך הסגירה של צ'ק-אין	תאריך השלמת ההטענה מראש של GKI	מאושר?
אוקטובר	1 באוקטובר 2024	14 באוקטובר 2024	כן
נובמבר	1 בנובמבר 2024	15 בנובמבר 2024	כן
דצמבר	2 בדצמבר 2024	16 בדצמבר 2024	כן
ינואר	6 בינואר 2025	22 בינואר 2025	כן

גרסה של GKI ל-Android 12

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

גרסאות build מוסמכות חודשיות של GKI	תאריך הסגירה של צ'ק-אין	תאריך השלמת ההטענה מראש של GKI	מוכן?
נובמבר	1 בנובמבר 2024	15 בנובמבר 2024	כן
פברואר	3 בפברואר 2025	17 בפברואר 2025	כן

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

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

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

הגרסאות מתבצעות באמצעות Cuttlefish כדי לוודא שהן עומדות ברף האיכות המינימלי.

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

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

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

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

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

תהליך שליחת בקשה חוזרת (respin) במקרה חירום

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

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

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

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

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

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

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

• לכל CL שנכלל בבדיקה, יש להוסיף את התגים הבאים.

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

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

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

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

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

כדי להיכנס לתהליך הרוטציה:

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

הסמכות GKI

סוגי גרסאות build של GKI	אכיפת מדיניות האיכות	הערות
כל שבוע	בדיקת Cuttlefish אתחול קבוצת משנה של VTS קבוצת משנה של CTS	לא מאושר. רק לצורך בדיקה והצגה של מכשיר אחד ( ). לא ניתן להשתמש באפשרות הזו להפעלת מכשירים.
חודשי (מאושר)	בדיקת Cuttlefish מגף VTS CTS בדיקת חומרה למטרות עזר מגף VTS CTS
דחיות חוזרות (מאושרות)	בדיקת דיונון מגף VTS תת-קבוצה של CTS בדיקת מכשיר עזר אתחול VTS	מבוסס על build שאושר על ידי GKI. הגרסה המאוחדת מאושרת אחרי הבדיקה.

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

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

בלוח הבקרה שילוב רציף עם Android תוכלו למצוא מידע נוסף על ה-CI, כולל תוצאות הבדיקה.

שאלות נפוצות

ריכזנו כאן כמה שאלות נפוצות שקשורות לתהליך השחרור של 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 (כולל תיקון הספין במצב חירום) נבנה על בסיס הקוד העדכני ביותר?

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

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

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

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

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

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

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