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

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

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

דרישות סף ומחזור חיים

  • תזמון: אפשר לבקש ספינים חוזרים רק בענפי הפצה אחרי השקה של גרסה רבעונית ראשונית לציבור. אפשר לשלוח בקשות לשינוי בקשות לגבי vendor-hooks או תכונות אחרות רק לגבי ענף של גרסה מסוימת, למשך שישה חודשים לכל היותר אחרי הפרסום הראשוני של הגרסה.
  • אבטחה ו-LTS: אחרי שישה חודשים, אפשר ליצור גרסה חדשה להסתעפויות רק כדי לתקן באגים קריטיים או כדי להחיל תיקוני אבטחה שמופיעים בעדכון האבטחה של Android‏ (ASB).
  • הוצאה משימוש: אם ההסתעפות לא עומדת בדרישות LTS, שמוגדרות בעדכון האבטחה של Android‏ (ASB), היא תוצא משימוש. לא נקבל בקשות ליצירת גרסאות (respin) להסתעפויות שהוצאו משימוש.
    • תאריך ההוצאה משימוש של ענף גרסה מסוים של GKI מופיע בהערות הגרסה הרבעוניות של GKI בקטע Releases (גרסאות). לדוגמה, המהדורה מספטמבר 2025 נתמכת לשינוי גרסה עד מרץ 2027. התאריך הזה משקף את משך החיים של גרסת הליבה LTS 2.0, שהוא 18 חודשים לגרסאות שיוצאות החל מספטמבר 2025 (לגרסאות שיצאו לפני ספטמבר 2025 היה משך חיים של 12 חודשים).
  • היקף: אפשר לבקש ספינים חוזרים רק לתיקון באגים דחופים, לעדכונים של רשימת הסמלים או להחלת תיקון לתיקון תכונה קיימת.

תקנים לשליחת תיקונים

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

מקור אמת ובחירה סלקטיבית

  • קודם ענף הפיתוח: כל תיקוני ה-patch שמועברים לענף של מהדורת הרבעון צריכים כבר להיות ממוזגים עם ענף הפיתוח הראשי של GKI. לדוגמה, אם נדרש תיקון ל-respin של android15-6.6-2025-08, הוא צריך כבר להיות ממורג ל-android15-6.6.
  • בחירת תיקונים נקייה: צריך לבחור תיקונים ישירות מענף הפיתוח. אל תבחרו באופן סלקטיבי מתוך ענפי גרסאות אחרים (לדוגמה, אל תבחרו מ-2025-08 ל-2025-09), כי זה עלול לגרום למידע על המחבר או על השמירה להיות לא עקבי עם הגרסה בענף הפיתוח. לא יתקבלו תיקונים עם מידע לא עקבי.
  • שמירת מטא-נתונים: שמירת המטא-נתונים המקוריים של הקומיט (לדוגמה, המחבר, חותמת הזמן המקורית). כדי לשמור את המטא-נתונים, משתמשים ב-git cherry-pick -x.

שרשרת שמירות (commit)

  • שרשרת רציפה: אם בקשת השינוי כוללת כמה תיקונים, צריך להעלות אותם כשרשרת רציפה אחת של קומיטים.
  • מיקום של ABI ו-KMI: אם גרסה חוזרת של תיקון מרובה כוללת עדכונים של ממשק מודול ליבת המערכת (KMI) וממשק בינארי של אפליקציה (ABI) (לדוגמה, שינויים ברשימת הסמלים או עדכונים בקובץ XML/STG), צריך למקם את הקומיטים האלה בסוף שרשרת הקומיטים.
  • שינוי בסיס: אם עורכים קומיט אב בשרשרת, צריך לשנות את הבסיס של כל תיקוני הצאצאים לגרסה האחרונה של תיקון האב כדי למנוע כשלים בבנייה.
  • פתרון קונפליקטים: מוודאים שאין סמני קונפליקטים בתיקון.
  • אימות בנייה: כל שרשרת הקומיטים חייבת להיבנות בהצלחה.

תגים נדרשים

ההתקדמות בבקשה ליצירת גרסה חדשה חסומה אם התגים הבאים לא מופיעים בהודעת השמירה:

  • ‫Change-Id: חייב להיות זהה לערך Change-Id של השינוי בענף הפיתוח.
  • ‫Bug (קיים): אסור להסיר תגי Bug: XYZ קיימים מהקומט של ענף הפיתוח המקורי.
  • ‫Bug (respin): צריך להוסיף תג Bug: XYZ חדש, כאשר XYZ מייצג את מזהה הבאג שמשויך לבקשת ה-respin הנוכחית.
  • אם צריך, מעדכנים את תג השמירה: כשמבצעים cherry-picking של CL מענף הפיתוח לענף ההפצה, וה-CL מתויג כ-UPSTREAM, כדאי לשקול את התרחישים הבאים:
      UPSTREAM
    • אם ה-CL חל בצורה חלקה על ענף הגרסה, לא צריך לבצע פעולות נוספות.
    • אם ה-CL לא חל בצורה חלקה, צריך לפתור את הקונפליקטים, לעדכן את התג ל-BACKPORT ולתעד את הפעולות שבוצעו כחלק מפתרון הקונפליקטים. אפשר לעיין בדרישות ל-backport מ-mainline Linux.

עדיפות ו-ESRT

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

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

בטבלה הבאה מפורטות העדיפויות של באגים והזמן לפתרון (ESRT):

בעדיפותESRT
P02 ימי עסקים
P15 ימי עסקים
P210 ימי עסקים
P315 ימי עסקים

מדיניות SLA

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

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

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

תהליך חידוש של מכונות וירטואליות במקרה חירום איור 1. תהליך ייצור מחדש (respin) דחוף.

כדי לשלוח בקשה ליצירת גרסה חדשה:

  1. ממלאים את טופס הבקשה ליצירת GKI חדש ופונים מיד לאיש הקשר שלכם ב-Google.

    • הטופס הזה יוצר באג של בקשת respin של GKI.

  2. הכנת הטלאים:

    • מוודאים שהתיקון מוזג ל-GKI development branch.
    • מחילים את התיקון על ענף ההפצה המתאים של GKI.
    • משנים את התיקון שנבחר כדי לכלול תג Bug: XYZ שמציין את מזהה בקשת הספין מחדש.

    דוגמה: כדי לבצע cherry-pick של CL מ-android16-6.12 ל-android16-6.12-2025-12:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. שולחים את הבאג. אחרי ששולחים את הבקשה, קורים הדברים הבאים:

    • תהליך הבדיקה אחרי שליחת בקשה:

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

    • גרסה: