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

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

קצב ההפצה של GKI

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

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

הטבלה הבאה רלוונטית רק לגבי android13-5.10 android13-5.15, וגם android14-6.1:

החל מינואר 2024, חזרנו את המהדורות החודשיות של android14-5.15 בהתאם לקצב החודשי שצוין טבלה. קצב ההפצה של android15-6.6 זהה לזה שבו החל מיולי 2024.

גרסת Android 12 GKI

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

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

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

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

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

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

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

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

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

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

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

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

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

הנחיות לבקשת הצמדה מחדש

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אפשר לקבל מידע נוסף על ה-CI, כולל הבדיקה תוצאות לגבי אינטגרציה רציפה (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

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

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

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

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

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

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

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

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

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