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

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

קצב ההפצה של GKI

ה-GKI מופץ אחת לרבעון אחרי הקפאת ה-KMI.

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

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

גרסאות מוסמכות רבעוניות

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

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

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

דרישות הסף לשימוש ב-GKI

איפה אפשר להשיג פריטי מידע על בנייה

אפשר להשיג ארטיפקטים של כל הגרסאות בכתובת ci.android.com.

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

שאלות נפוצות

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

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

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

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

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

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

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

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

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

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