הפעלה מחדש רכה (<= AOSP 14)

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 מבצע את השלבים הבאים:

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 קובע את זמן הקצאת הזמן הקצוב לתפוגה (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 קובע את זמן הקצאת הזמן לביצוע אתחול מוצלח של המכשיר (כלומר, 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.