הפעלות מחדש עם יכולת שחזור (<= AOSP 14)

Android 11 תומך בהפעלות מחדש רכות, שהן הפעלות מחדש של תהליכים במרחב המשתמש במהלך זמן הריצה, שמשמשות להחלה של עדכונים שדורשים הפעלה מחדש (לדוגמה, עדכונים לחבילות APEX). נכון לעכשיו, הפעלה מחדש רכה מוגבלת לתהליכים שהתחילו אחרי userdata הועלה.

נדרשת הפעלה מחדש עם יכולת שחזור בדרכים הבאות:

• מ-PowerManager, על ידי קריאה ל-PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

• מהמעטפת, באמצעות adb shell svc power reboot userspace או adb reboot userspace

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

אם המכשיר תומך בהפעלה מחדש רכה, שיטת ה-API PowerManager.isRebootingUserspace() מחזירה את הערך true והערך של מאפיין המערכת init.userspace_reboot.is_supported שווה ל-1.

אם המכשיר לא תומך בהפעלות מחדש רכות, הקריאות למספרים PowerManager.reboot(PowerManager.REBOOT_USERSPACE),‏ adb reboot userspace ו-adb shell svc power reboot userspace נכשלות.

ביצוע הפעלה מחדש עם יכולת שחזור

אחרי שמבקשים הפעלה מחדש חלקית (דרך PowerManager או ממעטפת), init מבצע את השלבים הבאים:

1. מקבל את הערך sys.powerctl=reboot,userspace.

2. יוצר תהליך נפרד של UserspaceRebootWatchdogThread() כדי לעקוב אחרי ההפעלה מחדש הרכה.

3. הפעולה מפעילה פעולת userspace-reboot-requested, שמאפסת את כל מאפייני המערכת שעשויים להשפיע על ההפעלה מחדש הרכה. הנכסים המושפעים:

   • sys.usb.config
   • sys.usb.state
   • sys.boot_completed
   • dev.bootcomplete
   • sys.init.updatable_crashing
   • sys.init.updatable_crashing_process_name
   • apexd.status
   • sys.user.0.ce_available
   • sys.shutdown.requested
   • service.bootanim.exit

   צריך להגדיר מחדש את המאפיינים שלמעלה במהלך רצף האתחול. במקרה הצורך, אפשר לאפס מאפיינים נוספים. לדוגמה, תוכלו לעיין בפעולה on userspace-reboot-requested בקובץ rootdir/init.rc.

4. הפונקציה DoUserspaceReboot מפעילה את הפעולות הבאות:

   1. שולח SIGTERM לתהליכים שהתחילו אחרי הטעינה של userdata וממתין שיפסיקו אותם.
   2. אחרי שהזמן הקצוב לתפוגה פג, נשלחת הפקודה SIGKILL כדי להרוג את כל התהליכים שפועלים.
   3. שיחות /system/bin/vdc volume reset.
   4. ניתוק המכשיר התומך ב-zRAM.
   5. ביטול הרכבת חבילות APEX פעילות.
   6. מחזירה את השדה למרחב השמות של הטעינה הראשונית.
   7. הפעלת הפעולה userspace-reboot-resume.

אם ביקשת נקודת עצירה במערכת הקבצים לפני ההפעלה מחדש הרכה, userdata יותקן מחדש במצב נקודת עצירה במהלך הפעולה userspace-reboot-fs-remount (פרטים בקטע הבא). הפעלה מחדש עם יכולת שחזור תטופל אחרי שמגדירים את sys.boot_completed property לערך 1. בסיום ההפעלה מחדש הרכה, המסך נשאר כבוי ונדרשת אינטראקציה מפורשת של המשתמש כדי להפעיל אותו.

נקודות עצירה לצורך בדיקה במערכת קבצים

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

• יצירת נקודות ביקורת ברמת מערכת הקבצים (לדוגמה, f2fs), userdata מצורף מחדש באמצעות האפשרות checkpoint=disable.

• נקודת עצירה לבדיקה ברמת הבלוקים (לדוגמה, ext4), ואז /data פורק וכל המכשירים של מיפוי המכשירים ההורים שעליו הוא הותאם אישית נהרסים. בשלב הבא, userdata מוצמד באמצעות אותו נתיב קוד שמשמש בהפעלה רגילה עם נקודות עצירה.

אם משתמשים במאגר מפתחות ברמת מערכת הקבצים כדי לנהל מפתחות עם הצפנת פרטי כניסה (CE) ומפתחות עם הצפנת מכשיר (DE), המפתחות הולכים לאיבוד אחרי ביטול הקישור של userdata. כדי לאפשר שחזור של מפתחות, כשמתקינים מפתח במאגר המפתחות של מערכת הקבצים, vold מתקינה גם את אותו מפתח מסוג fscrypt-provisioning במאגר המפתחות ברמת הסשן. כשמתבצעת קריאה ל-init_user0, vold מתקין מחדש את המפתחות באוסף המפתחות של מערכת הקבצים.

חזרה לאתחול קשיח

כדי לוודא שהפעלה מחדש רכה לא תשאיר את המכשיר במצב לא שמיש, ב-Android 11 יש חזרה אוטומטית להפעלה מחדש קשה כשמתקיים אחד מהמצבים הבאים:

• מכשיר לא מצליח להפעיל הפעלה מחדש חלקית (כלומר sys.init.userspace_reboot.in_progress=1) תוך פרק זמן קצוב.
• תהליך לא מצליח להפסיק תוך פרק זמן קצוב.
• הפעולה /system/bin/vdc volume reset נכשלת.
• ניסיונות הניתוק של מכשיר ה-zRAM נכשלים.
• מתבצע ניתוק של חבילת APEX פעילה באופן שגוי.
• ניסיון לחבר מחדש את userdata למצב של נקודות עצירה נכשל.
• המכשיר לא מצליח לבצע אתחול (כלומר, sys.boot_completed=1) תוך פרק זמן קצוב.

הגדרה לכל מכשיר

אפשר לשנות את הערכים של המאפיינים הבאים כדי לשנות חלק מהמאפיינים של ההפעלה מחדש הרכה:

• init.userspace_reboot.is_supported קובע מתי המכשיר יכול לבצע הפעלה מחדש חלקית. אם הערך של המאפיין הזה הוא false,‏ 0 או לא צוין, הניסיונות להפעלה מחדש נדחים.
• init.userspace_reboot.sigkill.timeoutmillis קובע את זמן הקצאת הזמן לתפוגה באלפיות השנייה לתהליכים שקיבלו אות SIGKILL לעצירה. אם אחד מהתהליכים לא נעצר בזמן הזמן הקצוב הנתון, מופעלת חזרה למצב הראשוני של אתחול קשיח.
• init.userspace_reboot.sigterm.timeoutmillis קובע את זמן הקצאת הזמן לתפוגה באלפיות השנייה לתהליכים שקיבלו אות SIGTERM לסיום. כל התהליכים שהסתיים הזמן הקצוב לתפוגה מקבלים אות SIGKILL.
• השדה init.userspace_reboot.started.timeoutmillis קובע את זמן הקצאת הזמן (במילי-שניות) להפעלת ההפעלה מחדש (כלומר, sys.init.userspace_reboot.in_progress=1). אם המכשיר לא מצליח להפעיל את ההפעלה מחדש תוך זמן הקצאת הזמן שצוין, מתבצעת חזרה להפעלה מחדש באופן קשה.
• init.userspace_reboot.userdata_remount.timeoutmillis קובע את זמן הקצאת הזמן הקצוב, באלפיות שנייה, לניתוק של userdata. אם המכשיר לא מצליח לנתק את userdata במסגרת הזמן הקצוב, מתבצעת חזרה להפעלה מחדש קשה.
• init.userspace_reboot.watchdog.timeoutmillis קובע את הזמן הקצוב להפעלה מוצלחת של המכשיר (כלומר, sys.boot_completed=1). אם המכשיר לא מצליח להיכנס למצב הפעלה תוך פרק הזמן הזה, מתבצעת חזרה להפעלה מחדש באופן קשה.

התאמה אישית של האנימציה במהלך הפעלה מחדש עם יכולת שחזור

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

בסיום הפעולה userspace-reboot-fs-remount, init מפעיל את השירות bootanim. השירות הזה מחפש את קובצי האנימציה הבאים, בסדר הרשום, ומפעיל את הראשון שהוא מוצא:

• /product/media/userspace-reboot.zip
• /oem/media/userspace-reboot.zip
• /system/media/userspace-reboot.zip

הבא

אם לא צוינו קובצי אנימציה ספציפיים להפעלה מחדש חלקית, ב-bootanim תוצג אנימציית android שמוגדרת כברירת מחדל.

בדיקה

Android 11 כולל הטמעת עזר של הפעלה מחדש חלקית. בנוסף, אפשר לאמת הפעלה מחדש רכה באמצעות בדיקות CTS ב-UserspaceRebootHostTest.