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

קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

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

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

כדי לקבוע למה המכשיר הופעל מחדש, מנהל האתחול משתמש במשאבי חומרה וזיכרון זמינים באופן ייחודי, ולאחר מכן הוא מוסר את הקביעה הזו על ידי הוספת androidboot.bootreason=<reason> לשורת הפקודה של ליבה של Android להפעלה. לאחר מכן, init מתרגם את שורת הפקודה הזו כדי להעביר אותה לנכס Android‏ bootloader_boot_reason_prop (ro.boot.bootreason). במכשירים שפועלים עם Android מגרסה 12 ואילך, שמשתמשים בליבה בגרסה 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) יכולה לשכתב את המאפיין הזה, אבל אפשר להעניק לכל האפליקציות הרשאות לקריאה של מדיניות האבטחה.
• להודיע למשתמשים על סיבה לאתחול ולבקש מהם להמתין עד שמתקינים את userdata לפני שהם נותנים אמון בתוכן במאפיין של סיבה לאתחול המערכת system_boot_reason_prop.

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

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

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

הלוגיקה של Bootstat תלויה ב-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"
• קבוצת blunt:
  • "cold". בדרך כלל מציין איפוס מלא של כל המכשירים, כולל הזיכרון.
  • "hard". בדרך כלל מציין שהמצב של החומרה אופס, ושהערך ramoops אמור לשמור תוכן קבוע.
  • "warm". בדרך כלל מציין שהזיכרון והמכשירים שומרים מצב כלשהו, ושאחסון ה-back-end של ramoops (ראו מנהל pstore בליבה) מכיל תוכן עקבי.
  • "shutdown"
  • "reboot". בדרך כלל המשמעות היא שהמצב של ramoops לא ידוע והמצב של החומרה לא ידוע. הערך הזה הוא ערך כללי, כי הערכים cold, ‏ hard ו-warm מספקים רמזים לגבי עומק האיפוס של המכשיר.

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

אף reason של span ראשון לא יכול להיות חלק מ-subreason או מ-detail. עם זאת, מאחר שאי אפשר ליצור סיבות להגדרה של הליבה במרחב המשתמש, אפשר לעשות שימוש חוזר ב-"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.

דיווח על סיבות לאתחול

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

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

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

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

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

אימות התאימות של הסיבה לאתחול

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

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