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

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

קצב ההפצה של GKI

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

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

הטבלה הבאה רלוונטית רק לגבי android13-5.10 android13-5.15, וגם android14-5.15. בהודעה הזו מפורטים תאריכי ההפצה בספטמבר 2024.

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

הטבלה הבאה רלוונטית רק לגבי android14-6.1 וגם android15-6.6 בהודעה הזו מפורטים תאריכי ההפצה בספטמבר 2024.

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

גרסת Android 12 GKI

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• אחרי שניתנה גרסת build ובקשת החזרה חוזרת סומנה כבעיה שתוקנה, שלא צריך לפתוח מחדש את הבקשה לסיבוב מחדש כדי להוסיף עוד CL. עליך לשלוח בקשה לסיבוב מחדש אם יש תיקונים נוספים שצריך למזג.

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

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

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

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

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

איור 2. תהליך הסיבוב החוזר

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

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

הסמכות GKI

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

איפה משיגים ארטיפקטים של build

אפשר לקבל פריטי מידע לכל פריטי התוכן ב- ci.android.com.

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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