به روز رسانی سیستم A/B (بدون درز).

به‌روزرسانی‌های سیستم A/B قدیمی، که به عنوان به‌روزرسانی‌های یکپارچه نیز شناخته می‌شوند، تضمین می‌کنند که یک سیستم راه‌اندازی قابل اجرا در طول به‌روزرسانی هوایی (OTA) روی دیسک باقی می‌ماند. این رویکرد احتمال یک دستگاه غیرفعال را پس از به‌روزرسانی کاهش می‌دهد، که به معنای تعویض دستگاه و reflash دستگاه کمتر در مراکز تعمیر و گارانتی است. سایر سیستم‌عامل‌های تجاری مانند ChromeOS نیز از به‌روزرسانی‌های A/B با موفقیت استفاده می‌کنند.

برای اطلاعات بیشتر در مورد به‌روزرسانی‌های سیستم A/B و نحوه عملکرد آنها، به انتخاب پارتیشن (اسلات‌ها) مراجعه کنید.

به روز رسانی سیستم A/B مزایای زیر را ارائه می دهد:

• به‌روزرسانی‌های OTA می‌توانند در حالی که سیستم در حال اجرا است، بدون ایجاد وقفه در کاربر رخ دهد. کاربران می توانند در طول OTA به استفاده از دستگاه های خود ادامه دهند—تنها زمان از کار افتادگی در طول به روز رسانی زمانی است که دستگاه در پارتیشن دیسک به روز شده راه اندازی مجدد می شود.
• پس از به روز رسانی، راه اندازی مجدد بیش از یک راه اندازی مجدد معمولی طول نمی کشد.
• اگر OTA اعمال نشود (مثلاً به دلیل فلاش بد)، کاربر تحت تأثیر قرار نخواهد گرفت. کاربر به اجرای سیستم‌عامل قدیمی ادامه می‌دهد و کلاینت آزاد است تا دوباره به‌روزرسانی را امتحان کند.
• اگر یک به‌روزرسانی OTA اعمال شود اما راه‌اندازی نشود، دستگاه دوباره به پارتیشن قدیمی راه‌اندازی می‌شود و قابل استفاده باقی می‌ماند. مشتری آزاد است تا مجدداً به‌روزرسانی را انجام دهد.
• هر گونه خطا (مانند خطاهای ورودی/خروجی) فقط بر مجموعه پارتیشن های استفاده نشده تأثیر می گذارد و می تواند دوباره امتحان شود. احتمال بروز چنین خطاهایی نیز کمتر می‌شود، زیرا بار ورودی/خروجی عمداً کم است تا از تضعیف تجربه کاربر جلوگیری شود.
• به روز رسانی ها را می توان در دستگاه های A/B پخش کرد و نیاز به دانلود بسته قبل از نصب را از بین می برد. پخش جریانی به این معنی است که لازم نیست کاربر فضای خالی کافی برای ذخیره بسته به‌روزرسانی در /data یا /cache داشته باشد.
• پارتیشن کش دیگر برای ذخیره بسته های به روز رسانی OTA استفاده نمی شود، بنابراین نیازی به اطمینان از اینکه پارتیشن کش برای به روز رسانی های بعدی به اندازه کافی بزرگ است وجود ندارد.
• dm-verity تضمین می‌کند که دستگاه یک تصویر خراب را بوت می‌کند. اگر دستگاهی به دلیل مشکل OTA یا dm-verity بد بوت نمی شود، دستگاه می تواند به یک تصویر قدیمی راه اندازی مجدد شود. (Android Verified Boot به آپدیت A/B نیاز ندارد.)

درباره به‌روزرسانی‌های سیستم A/B

به روز رسانی A/B نیاز به تغییراتی هم در کلاینت و هم در سیستم دارد. با این حال، سرور بسته OTA نباید به تغییرات نیاز داشته باشد: بسته‌های به‌روزرسانی همچنان از طریق HTTPS ارائه می‌شوند. برای دستگاه‌هایی که از زیرساخت OTA Google استفاده می‌کنند، تغییرات سیستم همه در AOSP است و کد مشتری توسط سرویس‌های Google Play ارائه می‌شود. OEM هایی که از زیرساخت OTA Google استفاده نمی کنند، می توانند از کد سیستم AOSP مجدد استفاده کنند، اما باید مشتری خود را تامین کنند.

برای OEM هایی که مشتری خود را تامین می کنند، مشتری باید:

• تصمیم بگیرید که چه زمانی به روز رسانی کنید. از آنجا که به‌روزرسانی‌های A/B در پس‌زمینه اتفاق می‌افتند، دیگر توسط کاربر شروع نمی‌شوند. برای جلوگیری از ایجاد اختلال در کاربران، توصیه می‌شود زمانی که دستگاه در حالت تعمیر و نگهداری بی‌حرکت است، مانند یک شبه و وای فای، به‌روزرسانی‌ها برنامه‌ریزی شود. با این حال، مشتری شما می تواند از هر اکتشافی که می خواهید استفاده کند.
• با سرورهای بسته OTA خود تماس بگیرید و تعیین کنید که آیا به روز رسانی در دسترس است یا خیر. این باید بیشتر با کد مشتری فعلی شما یکسان باشد، با این تفاوت که می خواهید سیگنال دهید که دستگاه از A/B پشتیبانی می کند. (کلینت Google همچنین دارای یک دکمه Check now برای کاربران برای بررسی آخرین به روز رسانی است.)
• با استفاده از URL HTTPS برای بسته به‌روزرسانی خود، با فرض در دسترس بودن، با update_engine تماس بگیرید. update_engine بلوک های خام را در پارتیشن استفاده نشده فعلی به روز می کند و بسته به روز رسانی را پخش می کند.
• بر اساس کد نتیجه update_engine ، موفقیت یا عدم موفقیت نصب را به سرورهای خود گزارش دهید. اگر آپدیت با موفقیت اعمال شود، update_engine به بوت لودر می گوید که در راه اندازی مجدد بعدی به سیستم عامل جدید بوت شود. در صورتی که سیستم عامل جدید راه اندازی نشود، بوت لودر به سیستم عامل قدیمی بازگشته است، بنابراین هیچ کاری از مشتری لازم نیست. اگر به‌روزرسانی ناموفق بود، مشتری باید تصمیم بگیرد که چه زمانی (و آیا) دوباره امتحان کند، بر اساس کد خطای دقیق. به عنوان مثال، یک مشتری خوب می تواند تشخیص دهد که یک بسته OTA جزئی ("تفاوت") با شکست مواجه می شود و به جای آن یک بسته کامل OTA را امتحان کند.

به صورت اختیاری، مشتری می تواند:

• نمایش یک اعلان از کاربر برای راه اندازی مجدد. اگر می‌خواهید خط‌مشی را پیاده‌سازی کنید که در آن کاربر تشویق می‌شود به طور معمول به‌روزرسانی شود، این اعلان می‌تواند به مشتری شما اضافه شود. اگر کلاینت از کاربران درخواستی نکند، در هر صورت، کاربران دفعه بعد که دوباره راه اندازی می شوند، به روز رسانی را دریافت خواهند کرد. (مشتری Google دارای تاخیر قابل تنظیم برای هر به‌روزرسانی است.)
• اعلانی را به کاربران نشان دهید که آیا آنها در نسخه جدید سیستم عامل بوت شده اند یا اینکه انتظار می رفت این کار را انجام دهند اما به نسخه قدیمی سیستم عامل بازگشته اند. (مشتری Google معمولاً هیچ کدام را انجام نمی دهد.)

در سمت سیستم، به‌روزرسانی‌های سیستم A/B بر موارد زیر تأثیر می‌گذارد:

• انتخاب پارتیشن (اسلات)، دیمون update_engine و تعاملات بوت لودر (در زیر توضیح داده شده است)
• فرآیند ساخت و تولید بسته به‌روزرسانی OTA (شرح شده در پیاده‌سازی به‌روزرسانی‌های A/B )

انتخاب پارتیشن (اسلات)

به روز رسانی سیستم A/B از دو مجموعه پارتیشن به نام اسلات (معمولاً اسلات A و شکاف B) استفاده می کند. سیستم از اسلات فعلی اجرا می‌شود در حالی که سیستم در حال اجرا در حین کار عادی به پارتیشن‌های موجود در شکاف استفاده نشده دسترسی ندارد. این رویکرد با نگه داشتن شکاف استفاده نشده به‌عنوان بازگشتی، به‌روزرسانی‌ها را مقاوم در برابر خطا می‌کند: اگر در حین یا بلافاصله پس از به‌روزرسانی خطایی رخ دهد، سیستم می‌تواند به اسلات قدیمی برگردد و همچنان یک سیستم کار کند. برای دستیابی به این هدف، هیچ پارتیشنی که توسط اسلات فعلی استفاده می شود نباید به عنوان بخشی از به روز رسانی OTA به روز شود (از جمله پارتیشن هایی که فقط یک نسخه برای آنها وجود دارد).

هر شکاف دارای یک ویژگی قابل بوت است که بیان می کند که آیا اسلات دارای سیستم صحیحی است که دستگاه می تواند از طریق آن بوت شود. اسلات فعلی زمانی که سیستم در حال اجرا است قابل بوت است، اما اسلات دیگر ممکن است نسخه قدیمی (هنوز صحیح) سیستم، نسخه جدیدتر یا داده های نامعتبر داشته باشد. صرف نظر از این که اسلات فعلی چیست، یک اسلات وجود دارد که اسلات فعال (محلی که بوت لودر در بوت بعدی از آن بوت می شود) یا اسلات ترجیحی است.

هر اسلات همچنین دارای یک ویژگی موفقیت آمیز است که توسط فضای کاربر تنظیم شده است، که تنها در صورتی مرتبط است که اسلات نیز قابل بوت باشد. یک اسلات موفق باید بتواند خود را بوت، اجرا و به روز کند. یک اسلات قابل راه‌انداز که به‌عنوان موفق علامت‌گذاری نشده است (پس از چندین تلاش برای بوت شدن از آن) باید توسط بوت‌لودر به‌عنوان غیرقابل راه‌اندازی علامت‌گذاری شود، از جمله تغییر اسلات فعال به اسلات قابل راه‌اندازی دیگر (معمولاً به شکافی که بلافاصله قبل از تلاش برای راه‌اندازی اجرا می‌شود. به جدید و فعال). جزئیات خاص رابط در boot_control.h تعریف شده است.

دیمون موتور را به روز کنید

به روز رسانی سیستم A/B از یک دیمون پس زمینه به نام update_engine استفاده می کند تا سیستم را برای بوت شدن در یک نسخه جدید و به روز شده آماده کند. این دیمون می تواند اقدامات زیر را انجام دهد:

• از پارتیشن‌های اسلات فعلی A/B بخوانید و هر داده‌ای را طبق دستورالعمل بسته OTA در پارتیشن‌های شکاف استفاده نشده A/B بنویسید.
• رابط boot_control را در یک گردش کاری از پیش تعریف شده فراخوانی کنید.
• طبق دستورالعمل بسته OTA، پس از نوشتن تمام پارتیشن‌های اسلات استفاده نشده، یک برنامه پس از نصب را از پارتیشن جدید اجرا کنید. (برای جزئیات، پس از نصب را ببینید).

از آنجایی که دیمون update_engine در خود فرآیند بوت دخالت ندارد، در حین به‌روزرسانی توسط خط‌مشی‌ها و ویژگی‌های SELinux در اسلات فعلی محدود شده است (چنین سیاست‌ها و ویژگی‌ها را نمی‌توان تا زمانی که سیستم در یک بوت بوت شود به‌روزرسانی کرد. نسخه جدید). برای حفظ یک سیستم قوی، فرآیند به‌روزرسانی نباید جدول پارتیشن، محتویات پارتیشن‌های موجود در شکاف فعلی یا محتویات پارتیشن‌های غیر A/B را که با بازنشانی کارخانه‌ای پاک نمی‌شوند، تغییر دهد.

منبع موتور را به روز کنید

منبع update_engine در system/update_engine قرار دارد. فایل های A/B OTA dexopt بین installd و مدیر بسته تقسیم می شوند:

• frameworks/native/cmds/installd/ ota* شامل اسکریپت postinstall، باینری برای chroot، کلون نصب شده که dex2oat را فراخوانی می‌کند، اسکریپت post-OTA move-artifacts و فایل 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 در سیستم فایل، تغییرات زیر را در بیلد خود وصله کنید:

• 486618 را تغییر دهید
• 529080 را تغییر دهید
• 529081 را تغییر دهید
• 534660 را تغییر دهید
• 594637 را تغییر دهید

این تغییرات یک کپی از آخرین گزارش update_engine را در /data/misc/update_engine_log/update_engine. YEAR - TIME . علاوه بر گزارش فعلی، پنج گزارش اخیر در /data/misc/update_engine_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 برای دانلود بسته به‌روزرسانی ندارند. از آنجایی که نه OEM ها و نه کاربران نمی خواهند فضا را در یک پارتیشن /cache هدر دهند، برخی از کاربران بدون به روز رسانی کار می کنند زیرا دستگاه جایی برای ذخیره بسته به روز رسانی ندارد. برای رفع این مشکل، Android 8.0 پشتیبانی از جریان به‌روزرسانی‌های A/B را اضافه کرد که بلوک‌ها را مستقیماً در پارتیشن B می‌نویسند، بدون اینکه نیازی به ذخیره کردن بلوک‌ها در /data باشند. به‌روزرسانی‌های جریانی A/B تقریباً به فضای ذخیره‌سازی موقت نیاز ندارند و برای تقریباً 100 کیلوبایت ابرداده به فضای ذخیره‌سازی کافی نیاز دارند.

برای فعال کردن به‌روزرسانی‌های پخش جریانی در Android 7.1، وصله‌های زیر را انتخاب کنید:

• اجازه لغو درخواست حل و فصل پروکسی
• رفع خاتمه انتقال در حین حل و فصل پراکسی ها
• تست واحد را برای TerminateTransfer بین محدوده ها اضافه کنید
• پاکسازی RetryTimeoutCallback()

این وصله‌ها برای پشتیبانی از جریان به‌روزرسانی‌های A/B در Android نسخه ۷.۱ و جدیدتر، چه با استفاده از سرویس‌های تلفن همراه Google (GMS) یا هر سرویس گیرنده به‌روزرسانی دیگری، مورد نیاز هستند.

عمر یک به روز رسانی A/B

فرآیند به‌روزرسانی زمانی شروع می‌شود که یک بسته OTA (که در کد به عنوان بارگذاری نامیده می‌شود) برای دانلود در دسترس باشد. خط‌مشی‌های موجود در دستگاه ممکن است بارگیری و برنامه کاربردی را بر اساس سطح باتری، فعالیت کاربر، وضعیت شارژ یا سایر خط‌مشی‌ها به تعویق بیندازند. علاوه بر این، از آنجایی که به‌روزرسانی در پس‌زمینه اجرا می‌شود، ممکن است کاربران ندانند که به‌روزرسانی در حال انجام است. همه اینها به این معنی است که فرآیند به روز رسانی ممکن است در هر نقطه ای به دلیل خط مشی ها، راه اندازی مجدد غیرمنتظره یا اقدامات کاربر قطع شود.

اختیاری، ابرداده در بسته OTA خود نشان می دهد که به روز رسانی می تواند جریان داشته باشد. از همین بسته می توان برای نصب غیر استریم نیز استفاده کرد. سرور ممکن است از فراداده استفاده کند تا به کلاینت بگوید که در حال پخش جریانی است، بنابراین مشتری OTA را به update_engine به درستی تحویل دهد. سازندگان دستگاه با سرور و کلاینت خود می‌توانند با اطمینان از اینکه سرور تشخیص می‌دهد که به‌روزرسانی جریان دارد (یا فرض می‌کند همه به‌روزرسانی‌ها جریان دارند) به‌روزرسانی‌های جریانی را فعال می‌کنند و کلاینت برای پخش جریانی با update_engine تماس صحیح می‌گیرد. تولیدکنندگان می‌توانند از این واقعیت استفاده کنند که بسته از نوع استریم است تا پرچمی را برای مشتری ارسال کنند تا به سمت چارچوب به عنوان جریان ارسال شود.

پس از در دسترس قرار گرفتن یک بار، روند به روز رسانی به شرح زیر است:

پس از نصب

برای هر پارتیشنی که مرحله پس از نصب تعریف شده است، update_engine پارتیشن جدید را در یک مکان خاص نصب می کند و برنامه مشخص شده در OTA را نسبت به پارتیشن نصب شده اجرا می کند. به عنوان مثال، اگر برنامه post-install به صورت usr/bin/postinstall در پارتیشن سیستم تعریف شود، این پارتیشن از اسلات استفاده نشده در یک مکان ثابت (مانند /postinstall_mount ) و /postinstall_mount/usr/bin/postinstall نصب می شود. دستور /postinstall_mount/usr/bin/postinstall اجرا می شود.

برای موفقیت پس از نصب، هسته قدیمی باید بتواند:

• قالب سیستم فایل جدید را سوار کنید . نوع سیستم فایل نمی تواند تغییر کند مگر اینکه در هسته قدیمی پشتیبانی از آن وجود داشته باشد، از جمله جزئیاتی مانند الگوریتم فشرده سازی مورد استفاده در صورت استفاده از یک سیستم فایل فشرده (مانند SquashFS).
• فرمت برنامه پس از نصب پارتیشن جدید را درک کنید . اگر از یک باینری با فرمت اجرایی و پیوند پذیر (ELF) استفاده می‌کنید، باید با هسته قدیمی سازگار باشد (مثلاً یک برنامه جدید ۶۴ بیتی که روی هسته ۳۲ بیتی قدیمی اجرا می‌شود اگر معماری از ساخت‌های ۳۲ به ۶۴ بیت تغییر کند). مگر اینکه به لودر ( ld ) دستور داده شود که از مسیرهای دیگر استفاده کند یا یک باینری ثابت بسازد، کتابخانه ها از تصویر سیستم قدیمی و نه از تصویر جدید بارگذاری می شوند.

به عنوان مثال، می توانید از یک اسکریپت پوسته به عنوان یک برنامه پس از نصب استفاده کنید که توسط باینری پوسته سیستم قدیمی با یک #! نشانگر در بالا)، سپس مسیرهای کتابخانه را از محیط جدید برای اجرای یک برنامه پیچیده تر باینری پس از نصب تنظیم کنید. از طرف دیگر، می‌توانید مرحله پس از نصب را از یک پارتیشن کوچک‌تر اختصاصی اجرا کنید تا فرمت سیستم فایل را در پارتیشن اصلی سیستم بدون ایجاد مشکلات سازگاری با عقب یا به‌روزرسانی‌های اولیه به‌روزرسانی کنید. این به کاربران امکان می‌دهد مستقیماً از یک تصویر کارخانه به آخرین نسخه به‌روزرسانی شوند.

برنامه جدید پس از نصب توسط خط مشی های SELinux تعریف شده در سیستم قدیمی محدود شده است. به این ترتیب، مرحله پس از نصب برای انجام وظایف مورد نیاز طراحی در یک دستگاه خاص یا سایر کارهای با بهترین تلاش مناسب است. مرحله پس از نصب برای رفع اشکال یکباره قبل از راه اندازی مجدد که به مجوزهای پیش بینی نشده نیاز دارد، مناسب نیست .

برنامه پس از نصب انتخاب شده در زمینه SELinux postinstall اجرا می شود. تمام فایل‌های موجود در پارتیشن نصب‌شده جدید با postinstall_file برچسب‌گذاری می‌شوند، بدون توجه به ویژگی‌های آنها پس از راه‌اندازی مجدد در آن سیستم جدید. تغییرات در ویژگی های SELinux در سیستم جدید بر مرحله پس از نصب تأثیری نخواهد داشت. اگر برنامه پس از نصب نیاز به مجوزهای اضافی دارد، این مجوزها باید به زمینه پس از نصب اضافه شوند.

پس از راه اندازی مجدد

پس از راه اندازی مجدد، update_verifier بررسی یکپارچگی را با استفاده از dm-verity آغاز می کند. این بررسی قبل از zygote شروع می‌شود تا سرویس‌های جاوا هر گونه تغییرات برگشت‌ناپذیری را ایجاد نکنند که از بازگشت ایمن جلوگیری کند. در طول این فرآیند، اگر بوت تایید شده یا dm-verity هر گونه خرابی را شناسایی کند، بوت لودر و هسته نیز ممکن است راه اندازی مجدد راه اندازی کنند. پس از اتمام بررسی، update_verifier بوت را با موفقیت نشان می دهد.

update_verifier فقط بلوک‌های فهرست شده در /data/ota_package/care_map.txt را می‌خواند، که در یک بسته A/B OTA هنگام استفاده از کد AOSP موجود است. سرویس گیرنده به‌روزرسانی سیستم جاوا، مانند GmsCore، care_map.txt را استخراج می‌کند، اجازه دسترسی را قبل از راه‌اندازی مجدد دستگاه تنظیم می‌کند، و فایل استخراج‌شده را پس از راه‌اندازی موفقیت‌آمیز سیستم در نسخه جدید حذف می‌کند.