סיבת האתחול הקנונית

מערכת Android 9 כוללת את השינויים הבאים במפרט הסיבה להפעלה של תוכנת האתחול.

הסיבות להפעלה

תוכנת אתחול משתמשת במשאבי חומרה וזיכרון שזמינים באופן ייחודי כדי להבין למה המכשיר הופעל מחדש, ואז מעביר את המידע הוספה של androidboot.bootreason=<reason> ל-Android בשורת הפקודה של הליבה להשקה. ואז init מתרגם את זה שורת הפקודה להעברה לנכס Android bootloader_boot_reason_prop (ro.boot.bootreason). במכשירים עם Android מגרסה 12 ואילך: עם גרסת ליבה (kernel) 5.10 ומעלה, androidboot.bootreason=<reason> נוספה ל-bootconfig במקום לשורת הפקודה של הליבה.

מפרטים של הסיבות להפעלה

בגרסאות הקודמות של Android צוין פורמט סיבת הפעלה שלא נעשה בו שימוש רווחים, באותיות קטנות, כולל כמה דרישות (כמו דיווח) kernel_panic, watchdog cold/warm/hard), ומה שגרם לכך שאין לך זכאות מסיבות ייחודיות אחרות. המפרט החופשי הזה הוביל של מאות הסברים מותאמים אישית (ולפעמים חסרי משמעות) מחרוזות, דבר שבתורו הוביל למצב שלא ניתן לניהול. נכון לתאריך הנוכחי גרסת Android, המומנטום האדיר של תוכן שכמעט לא ניתן לניתוח או חסר משמעות שנשלח על ידי תוכנת האתחול גרמה לבעיות תאימות עבור bootloader_boot_reason_prop

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

• אינטראקציה עם מפתחי תוכנת אתחול לעודד אותם:
  • לספק סיבות קנוניות, ניתנות לניתוח וניתנות לזיהוי כדי bootloader_boot_reason_prop
  • להשתתף ב-system/core/bootstat/bootstat.cpp רשימה של kBootReasonMap.
• להוסיף מקור מבוקר שניתן לכתיבה בזמן הריצה system_boot_reason_prop (sys.boot.reason). א' קבוצה מוגבלת של אפליקציות מערכת (כמו bootstat ו init) אפשר לשכתב את המאפיין הזה, אבל כל האפליקציות יכולות העניקו זכויות לשימוש ב-Sepolicy לקרוא אותו.
• הודעה למשתמשים לגבי סיבת ההפעלה שצריך להמתין עד לסיום הטעינה של נתוני המשתמשים לפני שסומכים על התוכן במאפיין סיבת ההפעלה של המערכת system_boot_reason_prop

למה כל כך מאוחר? למרות ש-bootloader_boot_reason_prop זמין מוקדם בזמן ההפעלה, הוא נחסם על ידי מדיניות האבטחה של Android לפי הצורך כי הוא מייצג מידע לא מדויק, לא ניתן לניתוח ולא קנוני. ברוב המקרים, רק מפתחים עם ידע מעמיק על מערכת ההפעלה נדרשת גישה למידע הזה. גרסה משופרת, ניתנת לניתוח וקנונית ה-API לסיבת ההפעלה עם system_boot_reason_prop יכול להיות מהימן והם נאספים באופן מדויק רק אחרי נתוני המשתמש. פרטים נוספים:

• לפני הטעינה של נתוני המשתמשים, system_boot_reason_prop יכיל את הערך מתוך bootloader_boot_reason_prop
• אחרי טעינת נתוני המשתמשים, ייתכן ש-system_boot_reason_prop עודכן כדי לעמוד בדרישות או כדי כדי לדווח על מידע מדויק יותר.

לכן, מערכת Android 9 מאריכה את התקופה של לפני שניתן להשיג את סיבת האתחול באופן רשמי, דיוק מיידי בהפעלה (עם bootloader_boot_reason_prop) כך שיהיו זמינים רק אחרי שנתוני המשתמש נטענים (עם system_boot_reason_prop).

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

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

הפורמט הקנוני של סיבת ההפעלה עבור bootloader_boot_reason_prop ב-Android 9 משתמשים בתחביר הבא:

<reason>,<subreason>,<detail>…

עיצוב כללים:

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

ערך ריק עבור bootloader_boot_reason_prop נחשב לא חוקי (כי כך סוכנים אחרים יוכלו להזריק סיבת אתחול לאחר מעשה).

דרישות לסיבות

הערך שניתן עבור reason (טווח ראשון, לפני הסיום או פסיק) חייב להיות הקבוצה הבאה מחולקת לליבה, חזקה וקהה סיבות:

• קבוצת הליבה:
  • watchdog"
  • "kernel_panic"
• קבוצה חזקה:
  • "recovery"
  • "bootloader"
• מוגדר קהה:
  • "cold" בדרך כלל מציין איפוס מלא של כל המכשירים, כולל זיכרון.
  • "hard" לרוב מציין שהחומרה נמצאת במצב שלה איפוס ו-ramoops צריך לשמור תוכן קבוע.
  • "warm" מציין באופן כללי את הזיכרון והמכשירים לשמור מדינה מסוימת, וגם את ramoops (מידע נוסף זמין בקטע pstore מנהל התקן בליבה (kernel)) מכיל תוכן עקבי.
  • "shutdown"
  • "reboot" בדרך כלל המדינה ramoops היא לא ידוע ומצב החומרה לא ידוע. הערך הזה הוא כללי כמו הערכים cold, hard ו-warm מספקים רמזים לגבי עומק האיפוס של המכשיר.

תוכנת אתחול צריכה לספק ליבה (kernel) או קבוצה קהה reason, וגם מומלץ מאוד לספק subreason אם ניתן נקבע. לדוגמה, לחיצה ארוכה על מקש הפעלה מונעת הסיבה להפעלת הגיבוי היא ramoops "reboot,longkey".

לא ניתן לכלול reason בטווח הראשון של subreason או detail. אבל, מכיוון שסיבות להגדרת הליבה (kernel) לא יכולות להיות מופקות על ידי מרחב המשתמש, ניתן לעשות שימוש חוזר ב-"watchdog" לאחר סיבה קהה, וגם פרטים על המקור (למשל, "reboot,watchdog,service_manager_unresponsive", או "reboot,software,watchdog").

סיבות ההפעלה לא צריכות לדרוש ידע פנימי של מומחה כדי לפענח ו/או חייב להיות קריא לאנשים עם דוח אינטואיטיבי. למשל: "shutdown,vbxd" (לא טוב), "shutdown,uv" (טוב יותר), "shutdown,undervoltage" (המועדף).

שילובים של סיבה משנית

Android שומר קבוצה של reason-subreason שאין לגרום לעומס יתר בשימוש רגיל, אבל ניתן להשתמש בהם כל מקרה לגופו, אם השילוב משקף במדויק את תנאי. דוגמאות לשילובים שמורים:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (החל מ-thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (מ- BatteryStatsService)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

לפרטים נוספים, אפשר לעיין בkBootReasonMap ב system/core/bootstat/bootstat.cpp וה-Git המשויך בהיסטוריה של יומן השינויים במאגר המקור של Android.

דיווח על סיבות הפעלה

כל הסיבות להפעלה, מתוכנת האתחול או נרשמות בהפעלה הקנונית חייבת להיות רשומה בקטע kBootReasonMap של system/core/bootstat/bootstat.cpp. הרשימה kBootReasonMap היא שילוב של כלים תואמים וקודמים מסיבות שלא עומדות בדרישות המדיניות. מפתחי תוכנת אתחול צריכים לרשום רק עדכונים חדשים סיבות תואמות למדיניות (ולא צריך לרשום סיבות שלא תואמות למדיניות, אלא אם המוצר כבר נשלח ואי אפשר לשנות אותו).

מומלץ מאוד להשתמש בערכים קיימים שעומדים בדרישות של system/core/bootstat/bootstat.cpp וההגבלה על פעילות שלך לפני כן באמצעות מחרוזת לא תואמת. ההנחיות הן:

• אישור כדי לדווח על "kernel_panic" תוכנת אתחול, כי ל-bootstat יש אפשרות לבדוק ramoops עבור kernel_panic signatures כדי לשפר את מסיבות משנה לsystem_boot_reason_prop הקנונית.
• לא בסדר לדווח על מחרוזת שלא תואמת למדיניות בתוך kBootReasonMap (למשל "panic") מ- תוכנת אתחול, מכיוון שהפעולה הזאת תפריע בסופו של דבר את היכולת לשפר reason

לדוגמה, אם kBootReasonMap מכיל "wdog_bark", מפתח של תוכנת אתחול צריך:

• שינוי למודל "watchdog,bark" והוספה לרשימה ב- kBootReasonMap.
• מה המשמעות של "bark" לאנשים שלא מכירים את טכנולוגיים ולקבוע אם subreason משמעותי יותר זמינים.

בדיקת התאימות של סיבת ההפעלה

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

לכן, כדי לעמוד בדרישות של תוכנת האתחול, מפתחי תוכנת האתחול צריכים לציית מרצון לרוח הכללים וההנחיות שתוארו למעלה. אנחנו ממליצים למפתחים כאלה לתרום ל-AOSP (במיוחד כדי system/core/bootstat/bootstat.cpp) ולהשתמש בהזדמנות הזו בתור לדיונים על בעיות הקשורות לאתחול.