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

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

קצב ההפצה של GKI

גרסאות GKI מתפרסמות מדי רבעון אחרי הקפאת ה-KMI.

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

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

גרסאות GKI של 16KB

צוות ההפצה של GKI מטפל בגרסאות GKI של 16KB באותו קצב הפצה רבעוני, בדיקות התאמה ותהליך respin כמו בגרסאות GKI של 4KB:

• ענפים נתמכים:
  • ‫android15-6.6 (החל מינואר 2026)
  • android16-6.12 (החל ממרץ 2026)
  • ‫android17-6.18 (החל מיוני 2026)
• שמירה על שוויון ואישור: קובצי GKI בינאריים בגודל 16 KB משתמשים באותו תג מקור ובאותו מזהה build של ליבת המערכת כמו הגרסה התואמת של GKI בגודל 4 KB. עד 2027, הכרטיסייה גרסת build להפצה של 16KB בדפים של גרסאות ה-build להפצה של android15-6.6,‏ android16-6.12 ו-android17-6.18 מספקת קובצי GKI בינאריים להפצה של 16KB ללא אישור. לא חובה לעדכן את הליבות של 4KB ו-16KB ביחד, אבל מומלץ לעשות את זה.
• הפעלת respins לפי דרישה: אפשר לבקש הפעלת respins של GKI בגודל 16KB באמצעות אותו תהליך וטופס לבקשת respin כמו ב-builds בגודל 4KB.

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

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

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

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

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

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

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

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

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

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

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