به‌روزرسانی‌های سیستم A/B قدیمی، که به‌عنوان به‌روزرسانی‌های یکپارچه نیز شناخته می‌شوند، تضمین می‌کنند که سیستم راه‌اندازی قابل‌استفاده‌ای درطول به‌روزرسانی ازطریق هوا (OTA) در دیسک باقی بماند. این رویکرد احتمال غیرفعال شدن دستگاه پس‌از به‌روزرسانی را کاهش می‌دهد، که به معنی تعویض کمتر دستگاه و بازنصب نرم‌افزار دستگاه در مراکز تعمیر و ضمانت‌نامه است. سیستم‌عامل‌های تجاری دیگر مانند ChromeOS نیز با موفقیت از به‌روزرسانی‌های A/B استفاده می‌کنند.
برای کسب اطلاعات بیشتر درباره به‌روزرسانی‌های سیستم A/B و نحوه عملکرد آن‌ها، انتخاب پارتیشن (اسلات‌ها) را ببینید.
به‌روزرسانی‌های سیستم A/B مزایای زیر را ارائه می‌دهد:
- به‌روزرسانی‌های OTA می‌توانند درحین اجرای سیستم و بدون ایجاد وقفه برای کاربر انجام شوند. کاربران می‌توانند درطول OTA به استفاده از دستگاه‌هایشان ادامه دهند—تنها زمان ازکارافتادگی درطول به‌روزرسانی زمانی است که دستگاه در بخش دیسک به‌روزشده بازراه‌اندازی می‌شود.
- پس‌از به‌روزرسانی، بازراه‌اندازی بیشتر از بازراه‌اندازی معمولی طول نمی‌کشد.
- اگر «به‌روزرسانی ازطریق شبکه» اعمال نشود (برای مثال، به‌دلیل فلش بد)، کاربر تحت تأثیر قرار نخواهد گرفت. کاربر همچنان سیستم‌عامل قدیمی را اجرا خواهد کرد و کارخواه می‌تواند به‌روزرسانی را دوباره امتحان کند.
- اگر به‌روزرسانی OTA اعمال شود اما دستگاه نتواند راه‌اندازی شود، دستگاه به پارتیشن قدیمی بازراه‌اندازی می‌شود و همچنان قابل‌استفاده خواهد بود. کاربر می‌تواند به‌روزرسانی را دوباره امتحان کند.
- هرگونه خطا (مثل خطاهای ورودی/خروجی) فقط بر مجموعه پارتیشن استفاده‌نشده تأثیر می‌گذارد و می‌توان دوباره امتحان کرد. چنین خطاهایی نیز کمتر احتمال وقوع دارند زیرا بار ورودی/خروجی عمداً پایین است تا از تنزل تجربه کاربر جلوگیری شود.
-
به‌روزرسانی‌ها را می‌توان در دستگاه‌های A/B جاری‌سازی کرد و نیاز به بارگیری بسته قبل‌از نصب آن را ازبین برد. جاری‌سازی یعنی لازم نیست کاربر فضای آزاد کافی برای ذخیره کردن بسته به‌روزرسانی در
/dataیا/cacheداشته باشد. - از افراز حافظه نهان دیگر برای ذخیره کردن بسته‌های به‌روزرسانی OTA استفاده نمی‌شود، بنابراین نیازی نیست مطمئن شوید که افراز حافظه نهان برای به‌روزرسانی‌های آینده به‌اندازه کافی بزرگ است.
- dm-verity تضمین می‌کند که دستگاه تصویر خراب‌نشده‌ای را راه‌اندازی خواهد کرد. اگر دستگاهی به‌دلیل OTA بد یا مشکل dm-verity راه‌اندازی نشود، دستگاه می‌تواند با تصویر قدیمی بازراه‌اندازی شود. (Android راه‌اندازی درستی‌سنجی‌شده به به‌روزرسانی‌های A/B نیاز ندارد.)
درباره به‌روزرسانی‌های سیستم A/B
به‌روزرسانی‌های A/B هم در مشتری و هم در سیستم نیاز به تغییر دارند. بااین‌حال، سرور بسته OTA نباید نیاز به تغییر داشته باشد: بسته‌های به‌روزرسانی همچنان ازطریق HTTPS ارائه می‌شوند. برای دستگاه‌هایی که از زیرساخت OTA Google استفاده می‌کنند، همه تغییرات سیستم در AOSP است و کد مشتری توسط «خدمات Google Play» ارائه می‌شود. «تولیدکنندگان تجهیزات اصلی» که از زیرساخت OTA Google استفاده نمی‌کنند می‌توانند از کد سیستم AOSP دوباره استفاده کنند اما باید مشتری خودشان را تأمین کنند.
برای تولیدکنندگان اصلی سخت‌افزار که کارخواه خودشان را ارائه می‌دهند، کارخواه باید:
- تصمیم بگیرید چه زمانی به‌روزرسانی را انجام دهید. ازآنجایی‌که به‌روزرسانی‌های A/B در پس‌زمینه انجام می‌شوند، دیگر کاربر آن‌ها را آغاز نمی‌کند. برای جلوگیری از ایجاد اختلال در کار کاربران، توصیه می‌شود به‌روزرسانی‌ها زمانی برنامه‌ریزی شوند که دستگاه در حالت نگهداری در وضعیت آماده‌به‌کار باشد، مثلاً درطول شب و در حالت Wi-Fi. بااین‌حال، کارخواه شما می‌تواند از هر اکتشافی که می‌خواهید استفاده کند.
- با سرورهای بسته OTA خود بررسی کنید و تعیین کنید که آیا به‌روزرسانی دردسترس است یا خیر. این باید عمدتاً با کد کارخواه موجود شما یکسان باشد، با این تفاوت که باید سیگنال دهید که دستگاه از A/B پشتیبانی می‌کند. (کارخواه Google همچنین شامل دکمه بررسی اکنون برای کاربران است تا جدیدترین به‌روزرسانی را بررسی کنند.)
-
با نشانی وب HTTPS برای بسته به‌روزرسانی‌تان با
update_engineتماس بگیرید، درصورتی‌که دردسترس باشد.update_engineبلوک‌های خام را در پارتیشن بلااستفاده فعلی به‌روزرسانی می‌کند، زیرا بسته به‌روزرسانی را جاری‌سازی می‌کند. -
براساس کد نتیجه
update_engine، موفقیت‌ها یا شکست‌های نصب را به سرورهایتان گزارش کنید. اگر به‌روزرسانی باموفقیت اعمال شود،update_engineبه bootloader می‌گوید که در راه‌اندازی مجدد بعدی، سیستم‌عامل جدید را راه‌اندازی کند. اگر سیستم‌عامل جدید راه‌اندازی نشود، bootloader به سیستم‌عامل قدیمی برمی‌گردد، بنابراین مشتری نیازی به انجام کاری ندارد. اگر به‌روزرسانی ناموفق باشد، کارخواه باید براساس کد خطای دقیق تصمیم بگیرد که چه زمانی (و آیا) دوباره امتحان کند. برای مثال، یک مشتری خوب می‌تواند تشخیص دهد که بسته OTA جزئی («تفاوت») ناموفق است و به‌جای آن بسته OTA کامل را امتحان کند.
به‌صورت اختیاری، کارخواه می‌تواند:
- اعلان بازراه‌اندازی دستگاه را به کاربر نشان دهید. اگر می‌خواهید خط‌مشی‌ای را پیاده‌سازی کنید که در آن کاربر تشویق می‌شود به‌طور معمول به‌روزرسانی کند، می‌توانید این اعلان را به مشتری‌تان اضافه کنید. اگر کارخواه از کاربران درخواست نکند، کاربران به‌هرحال دفعه بعدی که بازراه‌اندازی می‌کنند به‌روزرسانی را دریافت خواهند کرد. (کارخواه Google تأخیری پیکربندی‌شدنی برای هر به‌روزرسانی دارد.)
- اعلان نشان می‌دهد که آیا کاربران با نسخه جدید سیستم‌عامل راه‌اندازی کرده‌اند یا اینکه قرار بوده این کار را انجام دهند اما به نسخه قدیمی سیستم‌عامل برگشته‌اند. (مشتری Google معمولاً هیچ‌کدام از این کارها را انجام نمی‌دهد.)
در سمت سیستم، به‌روزرسانی‌های سیستم A/B بر موارد زیر تأثیر می‌گذارد:
-
انتخاب پارتیشن (شکاف‌ها)،
daemon
update_engine، و تعاملات bootloader (در زیر توضیح داده شده است) - فرایند ساخت و تولید بسته به‌روزرسانی ازطریق هوا (توضیح داده‌شده در پیاده‌سازی به‌روزرسانی‌های A/B)
انتخاب پارتیشن (جایگاه‌ها)
به‌روزرسانی‌های سیستم A/B از دو مجموعه پارتیشن استفاده می‌کنند که به آن‌ها جایگاه (معمولاً جایگاه A و جایگاه B) گفته می‌شود. سیستم از شکاف فعلی اجرا می‌شود درحالی‌که سیستم درحال اجرا درطول عملکرد عادی به پارتیشن‌های موجود در شکاف استفاده‌نشده دسترسی ندارد. این رویکرد با نگه داشتن شکاف استفاده‌نشده به‌عنوان جایگزین، به‌روزرسانی‌ها را دربرابر خطا مقاوم می‌کند: اگر خطایی درطول یا بلافاصله پس‌از به‌روزرسانی رخ دهد، سیستم می‌تواند به شکاف قدیمی برگردد و همچنان سیستم فعال داشته باشد. برای دستیابی به این هدف، هیچ‌یک از پارتیشن‌های استفاده‌شده توسط جایگاه فعلی نباید به‌عنوان بخشی از به‌روزرسانی OTA به‌روزرسانی شوند (ازجمله پارتیشن‌هایی که فقط یک نسخه دارند).
هر شکاف دارای یک ویژگی راه‌اندازی‌پذیر است که مشخص می‌کند آیا شکاف حاوی سیستم صحیحی است که دستگاه می‌تواند از آن راه‌اندازی شود یا نه. وقتی سیستم درحال اجرا است، شکاف کنونی قابل‌راه‌اندازی است، اما شکاف دیگر ممکن است نسخه قدیمی (هنوز درست) سیستم، نسخه جدیدتر، یا داده‌های نامعتبر داشته باشد. صرف‌نظر از اینکه شکاف فعلی چیست، یک شکاف وجود دارد که شکاف فعال است (شکافی که bootloader در راه‌اندازی بعدی از آن راه‌اندازی می‌شود) یا شکاف ترجیحی است.
هر شکاف همچنین دارای یک ویژگی موفق است که توسط فضای کاربر تنظیم شده است، که فقط درصورتی مرتبط است که شکاف نیز قابل‌راه‌اندازی باشد. شکاف موفق باید بتواند خودش را راه‌اندازی، اجرا، و به‌روزرسانی کند. شکاف راه‌اندازی‌پذیری که به‌عنوان موفق علامت‌گذاری نشده است (پس‌از چند تلاش برای
راه‌اندازی از آن)، باید توسط راه‌انداز سیستم به‌عنوان راه‌اندازی‌ناپذیر علامت‌گذاری شود، ازجمله تغییر شکاف فعال
به شکاف راه‌اندازی‌پذیر دیگر (معمولاً به شکافی که بلافاصله قبل‌از تلاش برای
راه‌اندازی در شکاف فعال جدید اجرا می‌شده است). جزئیات خاص میانای کاربری در
boot_control.h تعریف شده است.
به‌روزرسانی کردن دیو موتور
به‌روزرسانی‌های سیستم A/B از یک دیو پس‌زمینه‌ای به‌نام
update_engine برای آماده کردن سیستم برای راه‌اندازی در نسخه جدید و به‌روزشده استفاده می‌کنند. این
دیمن می‌تواند کنش‌های زیر را انجام دهد:
- طبق دستور بسته OTA، از پارتیشن‌های A/B جایگاه فعلی بخوانید و داده‌ها را در پارتیشن‌های A/B جایگاه استفاده‌نشده بنویسید.
- رابط
boot_controlرا در گردش کار ازپیش‌تعریف‌شده‌ای فراخوانی کنید. - پس‌از نوشتن همه پارتیشن‌های جایگاه استفاده‌نشده، طبق دستور بسته OTA، برنامه پس‌از نصب را از پارتیشن جدید اجرا کنید. (برای جزئیات، پس‌از نصب را ببینید).
ازآنجایی‌که دیمون update_engine در فرایند راه‌اندازی دخیل نیست، کارهایی که می‌تواند درطول به‌روزرسانی انجام دهد توسط خط‌مشی‌ها و ویژگی‌های SELinux در شکاف فعلی محدود می‌شود (این خط‌مشی‌ها و ویژگی‌ها تا زمانی که سیستم به نسخه جدید راه‌اندازی نشود، قابل به‌روزرسانی نیستند). برای حفظ سیستم قوی، فرایند به‌روزرسانی
نباید جدول پارتیشن، محتوای پارتیشن‌ها در
جایگاه فعلی، یا محتوای پارتیشن‌های غیر A/B را که نمی‌توان با بازنشانی کارخانه‌ای پاک کرد تغییر دهد.
به‌روزرسانی منبع موتور
منبع update_engine در
system/update_engine قرار دارد. فایل‌های dexopt به‌روزرسانی بی‌سیم A/B بین installd و مدیر بسته تقسیم می‌شوند:
-
frameworks/native/cmds/installd/ota* شامل متن پس‌از نصب، باینری برای chroot، شبیه‌سازی نصب که dex2oat را فرا می‌خواند، متن انتقال آرتیفکت پس‌از OTA، و فایل rc برای متن انتقال است. -
frameworks/base/services/core/java/com/android/server/pm/OtaDexoptService.java(به‌علاوهOtaDexoptShellCommand) مدیر بسته‌ای است که فرمان‌های dex2oat را برای برنامه‌ها آماده می‌کند.
برای نمونه‌ای از نحوه عملکرد، به
/device/google/marlin/device-common.mk مراجعه کنید.
به‌روزرسانی گزارش‌های موتور
برای نسخه‌های Android 8.x و قدیمی‌تر، گزارش‌های update_engine را می‌توانید در
logcat و در گزارش اشکال پیدا کنید. برای دردسترس قرار دادن گزارش‌های update_engine در سیستم فایل، تغییرات زیر را در ساختار خود وصله کنید:
این تغییرات نسخه‌ای از جدیدترین گزارش update_engine را در
/data/misc/update_engine_log/update_engine.YEAR-TIME ذخیره می‌کند. علاوه‌بر گزارش فعلی، پنج گزارش اخیر در
/data/misc/update_engine_log/ ذخیره می‌شود. کاربران دارای شناسه گروه log می‌توانند
به گزارش‌های سیستم فایل دسترسی داشته باشند.
تعامل‌های راه‌انداز سیستم
boot_control HAL توسط update_engine (و احتمالاً
دیگر برنامه‌های پس‌زمینه‌ای) استفاده می‌شود تا به راه‌انداز سیستم دستور دهد از کجا راه‌اندازی کند. سناریوهای نمونه رایج و وضعیت‌های مرتبط با آن‌ها شامل موارد زیر است:
- حالت عادی: سیستم از شکاف فعلی خود، یعنی شکاف A یا B، درحال اجرا است. تاکنون هیچ به‌روزرسانی‌ای اعمال نشده است. شیار فعلی سیستم قابل‌راه‌اندازی، موفق، و شیار فعال است.
- به‌روزرسانی درحال انجام است: سیستم از جایگاه B اجرا می‌شود، بنابراین جایگاه B جایگاه راه‌اندازی‌پذیر، موفق، و فعال است. شکاف A به‌عنوان غیرقابل‌راه‌اندازی علامت‌گذاری شد زیرا محتوای شکاف A درحال به‌روزرسانی است اما هنوز تکمیل نشده است. بازراه‌اندازی در این حالت باید راه‌اندازی از شکاف B را ادامه دهد.
- به‌روزرسانی اعمال شد، بازراه‌اندازی درانتظار است: سیستم از شکاف B اجرا می‌شود، شکاف B قابل‌راه‌اندازی و موفق است، اما شکاف A به‌عنوان فعال علامت‌گذاری شده است (و بنابراین به‌عنوان قابل‌راه‌اندازی علامت‌گذاری شده است). جایگاه A هنوز به‌عنوان موفق علامت‌گذاری نشده است و بارکننده باید چند بار تلاش کند از جایگاه A راه‌اندازی کند.
-
سیستم در به‌روزرسانی جدید بازراه‌اندازی شد: سیستم برای اولین‌بار از جایگاه A اجرا می‌شود، جایگاه B همچنان قابل‌راه‌اندازی و موفق است، درحالی‌که جایگاه A فقط قابل‌راه‌اندازی است و همچنان فعال است اما موفق نیست. شبح فضای کاربر،
update_verifier، باید جایگاه A را پس‌از انجام برخی‌از بررسی‌ها به‌عنوان موفق علامت‌گذاری کند.
پشتیبانی از به‌روزرسانی جاری‌سازی
دستگاه‌های کاربر همیشه فضای کافی در /data برای بارگیری بسته به‌روزرسانی ندارند. ازآنجایی‌که نه «تولیدکنندگان تجهیزات اصلی» و نه کاربران نمی‌خواهند فضای پارتیشن /cache را هدر دهند،
برخی‌از کاربران به‌روزرسانی دریافت نمی‌کنند زیرا دستگاه جایی برای ذخیره بسته به‌روزرسانی ندارد. برای
پرداختن به این مشکل، Android 8.0 از به‌روزرسانی‌های جاری‌سازی A/B پشتیبانی می‌کند که بلوک‌ها را
مستقیماً در پارتیشن B می‌نویسد، بدون اینکه نیاز باشد بلوک‌ها در
/data ذخیره شوند. به‌روزرسانی‌های جاری‌سازی A/B تقریباً به فضای ذخیره‌سازی موقت نیاز ندارند و فقط به فضای ذخیره‌سازی کافی برای حدود ۱۰۰ کیلوبایت فراداده نیاز دارند.
برای فعال کردن به‌روزرسانی‌های جاری‌سازی در Android 7.1، وصله‌های زیر را انتخاب کنید:
- اجازه لغو درخواست وضوح کارگزار
- رفع مشکل خاتمه دادن به انتقال درحین حل‌وفصل پراکسی‌ها
- افزودن آزمون واحد برای TerminateTransfer بین محدوده‌ها
- پاک‌سازی RetryTimeoutCallback()
این وصله‌ها برای پشتیبانی از جاری‌سازی به‌روزرسانی‌های A/B در Android 7.1 و نسخه‌های بالاتر، چه از خدمات تلفن همراه Google (GMS) استفاده کنید یا از هر مشتری به‌روزرسانی دیگری، الزامی است.
چرخه عمر به‌روزرسانی A/B
فرایند به‌روزرسانی زمانی شروع می‌شود که بسته OTA (که در کد به آن بار مفید گفته می‌شود) برای بارگیری دردسترس باشد. خط‌مشی‌های دستگاه ممکن است براساس سطح باتری، فعالیت کاربر، وضعیت شارژ، یا خط‌مشی‌های دیگر، بارگیری و اعمال محموله را به‌تعویق بیندازند. علاوه‌براین، چون به‌روزرسانی در پس‌زمینه اجرا می‌شود، کاربران ممکن است متوجه نشوند که به‌روزرسانی درحال انجام است. همه این‌ها یعنی فرایند به‌روزرسانی ممکن است در هر نقطه‌ای به‌دلیل خط‌مشی‌ها، بازراه‌اندازی‌های غیرمنتظره، یا کنش‌های کاربر قطع شود.
به‌صورت اختیاری، فراداده در بسته OTA خود نشان می‌دهد که به‌روزرسانی می‌تواند جاری‌سازی شود؛ از همان بسته
می‌توان برای نصب غیرجاری‌سازی نیز استفاده کرد. سرور می‌تواند از فراداده برای
اعلام جاری‌سازی به کارخواه استفاده کند تا کارخواه OTA را به‌درستی به
update_engine واگذار کند. سازندگان دستگاه که سرور و کارخواه خودشان را دارند
می‌توانند با اطمینان از اینکه سرور تشخیص می‌دهد به‌روزرسانی درحال جاری‌سازی است (یا
فرض می‌کند همه به‌روزرسانی‌ها درحال جاری‌سازی هستند) و کارخواه تماس صحیح را با
update_engine برای جاری‌سازی برقرار می‌کند، جاری‌سازی به‌روزرسانی‌ها را فعال کنند. تولیدکنندگان می‌توانند از این واقعیت که بسته متعلق به
نسخه جاری‌سازی است برای ارسال پرچم به مشتری استفاده کنند تا انتقال به سمت چارچوب
را به‌عنوان جاری‌سازی راه‌اندازی کنند.
پس‌از دردسترس قرار گرفتن بار، فرایند به‌روزرسانی به این صورت است:
| مرحله | فعالیت‌ها |
|---|---|
| 1 |
جایگاه کنونی (یا «جایگاه منبع») با
markBootSuccessful() به‌عنوان موفق علامت‌گذاری می‌شود (اگر قبلاً علامت‌گذاری نشده باشد).
|
| 2 |
جایگاه استفاده‌نشده (یا «جایگاه هدف») با فراخوانی تابع
setSlotAsUnbootable() به‌عنوان غیرقابل‌راه‌اندازی علامت‌گذاری می‌شود. جایگاه فعلی همیشه در ابتدای به‌روزرسانی به‌عنوان موفق علامت‌گذاری می‌شود تا از بازگشت راه‌انداز سیستم به جایگاه استفاده‌نشده که به‌زودی داده‌های نامعتبر خواهد داشت جلوگیری شود. اگر سیستم به نقطه‌ای رسیده باشد که بتواند
به‌روزرسانی را اعمال کند، جایگاه فعلی به‌عنوان موفقیت‌آمیز علامت‌گذاری می‌شود، حتی اگر سایر
عناصر اصلی خراب باشند (مثل واسط کاربر در حلقه خرابی)، زیرا می‌توان نرم‌افزار جدیدی برای
رفع این مشکلات ارسال کرد. بار به‌روزرسانی یک لکه مات با دستورالعمل‌های به‌روزرسانی به نسخه جدید است. بار مفید به‌روزرسانی شامل موارد زیر است:
|
| 3 | فراداده محموله بارگیری شد. |
| 4 | برای هر عملیات تعریف‌شده در فراداده، به‌ترتیب، داده‌های مرتبط (درصورت وجود) در حافظه بارگیری می‌شود، عملیات اعمال می‌شود، و حافظه مرتبط دور انداخته می‌شود. |
| 5 | کل پارتیشن‌ها دوباره خوانده می‌شود و با درهم‌سازی موردانتظار تأیید می‌شود. |
| 6 | مرحله پس‌از نصب (درصورت وجود) اجرا می‌شود. درصورت بروز خطا درطول اجرای هر مرحله، به‌روزرسانی ناموفق خواهد بود و با احتمالاً یک داده‌برداری متفاوت دوباره امتحان می‌شود. اگر همه مراحل تاکنون موفقیت‌آمیز بوده باشد، به‌روزرسانی موفقیت‌آمیز است و آخرین مرحله اجرا می‌شود. |
| 7 |
جایگاه استفاده‌نشده با فراخوانی setActiveBootSlot() به‌عنوان فعال علامت‌گذاری می‌شود.
علامت‌گذاری جایگاه استفاده‌نشده به‌عنوان فعال به این معنی نیست که راه‌اندازی آن تکمیل خواهد شد. اگر bootloader (یا خود سیستم) وضعیت موفقیت‌آمیزی را نخواند، می‌تواند جایگاه فعال را برگرداند.
|
| 8 |
پس‌از نصب (که در زیر شرح داده شده است) شامل اجرای برنامه‌ای از نسخه «به‌روزرسانی جدید»
درحالی‌که هنوز در نسخه قدیمی اجرا می‌شود. اگر در بسته OTA تعریف شده باشد، این مرحله
الزامی است و برنامه باید با کد خروج 0 برگردد؛
درغیراین‌صورت، به‌روزرسانی ناموفق خواهد بود.
|
| 9 |
پس‌از اینکه سیستم با موفقیت در جایگاه جدید راه‌اندازی شد و بررسی‌های پس‌از بازراه‌اندازی را تکمیل کرد، جایگاه فعلی (که قبلاً «جایگاه هدف» بود) با فراخوانی markBootSuccessful() به‌عنوان موفق علامت‌گذاری می‌شود.
|
پس‌از نصب
برای هر پارتیشنی که مرحله پس‌از نصب در آن تعریف شده است،
update_engine پارتیشن جدید را در مکان خاصی نصب می‌کند و
برنامه مشخص‌شده در OTA را نسبت‌به پارتیشن نصب‌شده اجرا می‌کند. برای مثال، اگر برنامه پس‌از نصب به‌عنوان usr/bin/postinstall در بخش سیستم تعریف شده باشد، این بخش از شکاف استفاده‌نشده در مکان ثابتی (مانند /postinstall_mount) سوار می‌شود و فرمان /postinstall_mount/usr/bin/postinstall اجرا می‌شود.
برای اینکه پس‌از نصب موفقیت‌آمیز باشد، هسته قدیمی باید بتواند:
- قالب جدید سیستم فایل را نصب کنید. نوع سیستم فایل نمی‌تواند تغییر کند مگر اینکه در هسته قدیمی از آن پشتیبانی شود، ازجمله جزئیاتی مثل الگوریتم فشرده‌سازی مورد استفاده درصورت استفاده از سیستم فایل فشرده (یعنی SquashFS).
-
با قالب برنامه پس‌از نصب پارتیشن جدید آشنا شوید. اگر از باینری
«قالب اجرایی و پیوندپذیر» (ELF) استفاده می‌کنید، باید با هسته قدیمی سازگار باشد
(برای نمونه، برنامه جدید ۶۴ بیتی که روی هسته ۳۲ بیتی قدیمی اجرا می‌شود، درصورتی‌که معماری از
ساخت‌های ۳۲ بیتی به ۶۴ بیتی تغییر کرده باشد). مگر اینکه به بارکننده (
ld) دستور داده شود از مسیرهای دیگر استفاده کند یا باینری ایستا بسازد، کتابخانه‌ها از تصویر سیستم قدیمی بار می‌شوند و نه از تصویر جدید.
برای مثال، می‌توانید از یک دستور پوسته به‌عنوان برنامه پس‌از نصب استفاده کنید که با باینری پوسته سیستم قدیمی تفسیر می‌شود (با نشانگر #! در بالا)، سپس مسیرهای کتابخانه را از محیط جدید برای اجرای برنامه پس‌از نصب باینری پیچیده‌تر تنظیم کنید. یا می‌توانید مرحله پس‌از نصب را از پارتیشن کوچک‌تر اختصاصی اجرا کنید تا قالب سیستم فایل در پارتیشن سیستم اصلی فعال شود و بدون بروز مشکلات سازگاری با نسخه‌های قبلی یا به‌روزرسانی‌های گام‌به‌گام به‌روزرسانی شود؛ این کار به کاربران امکان می‌دهد مستقیماً از تصویر کارخانه‌ای به جدیدترین نسخه به‌روزرسانی کنند.
برنامه جدید پس‌از نصب با خط‌مشی‌های SELinux تعریف‌شده در سیستم قدیمی محدود می‌شود. بنابراین، مرحله پس‌از نصب برای انجام وظایف موردنیاز طراحی در یک دستگاه معین یا سایر وظایف با بهترین تلاش مناسب است. مرحله پس‌از نصب برای رفع اشکالات یک‌باره قبل‌از بازراه‌اندازی که به اجازه‌های پیش‌بینی‌نشده نیاز دارند مناسب نیست.
برنامه پس‌از نصب انتخاب‌شده در بافت
postinstall SELinux اجرا می‌شود. همه فایل‌های موجود در پارتیشن سوارشده جدید با postinstall_file برچسب‌گذاری خواهند شد،
صرف‌نظر از اینکه ویژگی‌های آن‌ها پس‌از بازراه‌اندازی در آن سیستم جدید چه باشد. تغییرات در مشخصه‌های SELinux در سیستم جدید بر مرحله پس‌از نصب تأثیر نخواهد گذاشت. اگر برنامه پس‌از نصب به اجازه‌های اضافی نیاز دارد، باید
این اجازه‌ها به زمینه پس‌از نصب اضافه شود.
پس‌از بازراه‌اندازی
پس‌از بازراه‌اندازی، update_verifier بررسی تمامیت را بااستفاده از dm-verity راه‌اندازی می‌کند.
این بررسی قبل‌از زیگوت شروع می‌شود تا از ایجاد هرگونه تغییر غیرقابل‌برگشت توسط سرویس‌های جاوا که
از بازگرداندن ایمن جلوگیری می‌کند جلوگیری شود. درطول این فرایند، اگر راه‌اندازی درستی‌سنجی‌شده یا dm-verity هرگونه خرابی را شناسایی کند، راه‌انداز سیستم و هسته نیز ممکن است راه‌اندازی مجدد را فعال کنند. پس‌از تکمیل بررسی،
update_verifier
راه‌اندازی را موفقیت‌آمیز علامت‌گذاری می‌کند.
update_verifier فقط بلوک‌های فهرست‌شده در
/data/ota_package/care_map.txt را می‌خواند که هنگام استفاده از کد AOSP در بسته A/B OTA گنجانده شده است. کارخواه به‌روزرسانی سیستم Java، مثل GmsCore،
care_map.txt را استخراج می‌کند، اجازه دسترسی را قبل‌از بازراه‌اندازی دستگاه تنظیم می‌کند، و
فایل استخراج‌شده را پس‌از اینکه سیستم باموفقیت با نسخه جدید راه‌اندازی شد حذف می‌کند.