Android 11 תומך בהפעלות מחדש רכות, שהן הפעלות מחדש של תהליכים בזמן ריצה במרחב המשתמש, שמשמשות להחלת עדכונים שדורשים הפעלה מחדש (לדוגמה, עדכונים לחבילות APEX). נכון לעכשיו, הפעלה מחדש רכה מוגבלת לתהליכים שהתחילו אחרי שהכונן userdata הותקן.
אפשר לבקש הפעלה רכה מחדש בדרכים הבאות:
מ-
PowerManager, באמצעות התקשרות אלPowerManager.reboot(PowerManager.REBOOT_USERSPACE)ממעטפת, באמצעות
adb shell svc power reboot userspaceאוadb reboot userspace
אחרי הפעלה מחדש רכה, אחסון פרטי הכניסה המוצפנים נשאר פתוח.
אם המכשיר תומך בהפעלה מחדש רכה, השיטה PowerManager.isRebootingUserspace() של ה-API מחזירה את הערך true, והערך של מאפיין המערכת init.userspace_reboot.is_supported שווה ל-1.
אם המכשיר לא תומך בהפעלה מחדש רכה, השיחות למספרים PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot
userspace ו-adb shell svc power reboot userspace ייכשלו.
הפעלה מחדש רכה
אחרי שמבקשים הפעלה מחדש רכה (דרך PowerManager או משורת פקודה), init מבצע את השלבים הבאים:
מקבל
sys.powerctl=reboot,userspace.מבצע פיצול (fork) של תהליך
UserspaceRebootWatchdogThread()נפרד כדי לעקוב אחרי ההפעלה מחדש הרכה.מפעיל פעולת
userspace-reboot-requested, שמאפסת את כל מאפייני המערכת שעשויים להשפיע על ההפעלה הרכה מחדש. נכסים מושפעים:sys.usb.configsys.usb.statesys.boot_completeddev.bootcompletesys.init.updatable_crashingsys.init.updatable_crashing_process_nameapexd.statussys.user.0.ce_availablesys.shutdown.requestedservice.bootanim.exit
צריך להגדיר מחדש את המאפיינים שלמעלה במהלך רצף האתחול. אם צריך, אפשר לאפס מאפיינים נוספים. לדוגמה, אפשר לעיין בפעולה
on userspace-reboot-requestedבrootdir/init.rc.מריץ את הפונקציה
DoUserspaceRebootשמבצעת את הפעולות הבאות:- שולח
SIGTERMלתהליכים שהתחילו אחרי ש-userdataהותקן ומחכה שהם יסתיימו. - אחרי שהזמן הקצוב לתפוגה מסתיים, נשלחת הפקודה
SIGKILLכדי להפסיק את כל התהליכים הפעילים. - שיחות
/system/bin/vdc volume reset. - מבטל את הטעינה של מכשיר הגיבוי של zRAM.
- מבטלת את הטעינה של חבילות APEX פעילות.
- חוזרים למרחב השמות של נקודת העיגון של bootstrap.
- מפעיל את הפעולה
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.Block level checkpointing (לדוגמה,
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שולט בערך הזמן הקצוב לתפוגה (timeout) במילישניות לתהליכים שקיבלו אותSIGKILLלהפסקה. אם אחד מהתהליכים לא מפסיק לפעול בפרק הזמן שמוגדר כטיימאוט, מופעלת חזרה לטעינה מחדש. -
init.userspace_reboot.sigterm.timeoutmillisשולט בערך הזמן הקצוב לתפוגה (timeout) באלפיות השנייה (מילישניות) לתהליכים שקיבלו אות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קובעת את הזמן הקצוב לתפוגה (timeout) להפעלה מוצלחת של מכשיר (כלומר,sys.boot_completed=1). אם מכשיר לא מופעל בזמן הקצוב לתפוגה שצוין, מופעלת חזרה לגיבוי של הפעלה מחדש.
התאמה אישית של האנימציה במהלך הפעלה מחדש רכה
ההטמעה לדוגמה של הפעלה מחדש רכה כוללת אפשרות להתאים אישית את האנימציה שמוצגת במהלך ההפעלה מחדש.
בסיום הפעולה userspace-reboot-fs-remount, שירות bootanim מתחיל.init השירות הזה מחפש את קובצי האנימציה הבאים, בסדר שמופיע ברשימה, ומפעיל את הראשון שהוא מוצא:
/product/media/userspace-reboot.zip/oem/media/userspace-reboot.zip/system/media/userspace-reboot.zip
אם לא מציינים קובצי אנימציה ספציפיים להפעלה רכה מחדש, מוצגת אנימציית ברירת המחדל android.bootanim
בדיקה
Android 11 כולל הטמעה לדוגמה של הפעלה מחדש רכה. בנוסף, אפשר לאמת הפעלה מחדש רכה באמצעות בדיקות CTS ב-UserspaceRebootHostTest.