نمای کلی A/B مجازی

Virtual A/B مکانیزم اصلی به‌روزرسانی اندروید است. A/B مجازی بر روی به‌روزرسانی‌های قدیمی A/B ساخته می‌شود ( به‌روزرسانی‌های سیستم A/B را ببینید) و غیر A/B که در ۱۵ منسوخ شده‌اند تا هزینه‌های اضافی به‌روزرسانی‌ها را کاهش دهد.

A/B مجازی در واقع یک اسلات اضافی برای پارتیشن‌های پویا ندارد، به پارتیشن‌های پویا مراجعه کنید. در عوض، دلتا در یک عکس فوری نوشته می‌شود و پس از تأیید راه‌اندازی موفق، در پارتیشن پایه ادغام می‌شود. Virtual A/B از یک قالب عکس فوری مخصوص اندروید استفاده می کند. برای عکس‌های فوری فشرده، فرمت COW را ببینید که امکان فشرده‌سازی عکس‌های فوری را فراهم می‌کند و استفاده از فضای دیسک را به حداقل می‌رساند. در یک OTA کامل، اندازه عکس فوری با فشرده سازی حدود 45٪ کاهش می یابد، و اندازه عکس فوری OTA افزایشی حدود 55٪ کاهش می یابد.

اندروید 12 گزینه فشرده سازی مجازی A/B را برای فشرده سازی پارتیشن های عکس فوری ارائه می دهد. Virtual A/B موارد زیر را ارائه می دهد

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

پیشینه و اصطلاحات

این بخش اصطلاحات را تعریف می کند و فناوری را که از A/B مجازی پشتیبانی می کند، توضیح می دهد. در حین نصب OTA، داده‌های سیستم عامل جدید یا در اسلات جدید آن برای پارتیشن‌های فیزیکی یا یک دستگاه COW خاص اندروید نوشته می‌شود. پس از راه‌اندازی مجدد دستگاه، داده‌های پارتیشن پویا با استفاده از dm-user و snapuserd daemon به دستگاه پایه آن ادغام می‌شوند. این فرآیند به طور کامل در فضای کاربر اتفاق می افتد.

نقشه‌بردار دستگاه

Device-mapper یک لایه بلوک مجازی لینوکس است که اغلب در اندروید استفاده می شود. با پارتیشن های پویا ، پارتیشن هایی مانند /system مجموعه ای از دستگاه های لایه ای هستند:

  • در پایین پشته، پارتیشن فیزیکی فوق‌العاده قرار دارد (برای مثال /dev/block/by-name/super ).
  • در وسط یک دستگاه dm-linear قرار دارد که مشخص می‌کند کدام بلوک‌ها در پارتیشن فوق‌العاده پارتیشن پویا را تشکیل می‌دهند. این به صورت /dev/block/mapper/system_[a|b] در دستگاه A/B یا /dev/block/mapper/system در دستگاه غیر A/B ظاهر می‌شود.
  • در بالا یک دستگاه dm-verity وجود دارد که برای پارتیشن های تایید شده ایجاد شده است. این دستگاه تأیید می کند که بلوک های دستگاه dm-linear به درستی امضا شده اند. به صورت /dev/block/mapper/system-verity ظاهر می‌شود و منبع نقطه نصب /system است.

شکل 1 نشان می دهد که پشته در زیر نقطه نصب /system چگونه به نظر می رسد.

Partition stacking underneath system

شکل 1. در زیر نقطه نصب سیستم / قرار دهید

عکس های فوری فشرده شده

در اندروید 12 و بالاتر، از آنجایی که فضای مورد نیاز در پارتیشن /data می‌تواند زیاد باشد، می‌توانید عکس‌های فوری فشرده‌شده را در ساخت خود فعال کنید تا فضای مورد نیاز پارتیشن /data را برطرف کند.

عکس‌های فوری فشرده A/B مجازی بر روی اجزای زیر ساخته شده‌اند که در اندروید ۱۲ و بالاتر در دسترس هستند:

  • dm-user ، یک ماژول هسته شبیه به FUSE که به فضای کاربران اجازه می دهد تا دستگاه های بلوک را پیاده سازی کنند.
  • snapuserd ، یک دیمون فضای کاربران برای پیاده سازی یک قالب عکس فوری جدید.

این اجزا باعث فشرده سازی می شوند. سایر تغییرات لازم برای اجرای قابلیت‌های snapshots فشرده در بخش‌های بعدی آورده شده است: فرمت COW برای عکس‌های فوری فشرده ، dm-user و snapuserd .

فرمت COW برای عکس های فوری فشرده

در Android 12 و بالاتر، عکس‌های فوری فشرده‌شده از فرمت COW مخصوص اندروید استفاده می‌کنند. فرمت COW حاوی ابرداده در مورد OTA است و دارای بافرهای متمایز حاوی عملیات COW و داده های سیستم عامل جدید است. در مقایسه با فرمت عکس فوری هسته که فقط برای عملیات جایگزینی مجاز است (بلوک X را در تصویر پایه با محتویات بلوک Y در عکس جایگزین کنید)، فرمت عکس های فوری فشرده Android COW گویاتر است و از عملیات زیر پشتیبانی می کند:

  • کپی : بلوک X در دستگاه پایه باید با بلوک Y در دستگاه پایه جایگزین شود.
  • جایگزینی : بلوک X در دستگاه پایه باید با محتویات بلوک Y در عکس فوری جایگزین شود. هر کدام از این بلوک ها به صورت gz فشرده شده است.
  • صفر : بلوک X در دستگاه پایه باید با تمام صفرها جایگزین شود.
  • XOR : دستگاه COW بایت های فشرده شده XOR را بین بلوک X و بلوک Y ذخیره می کند. (در اندروید 13 و بالاتر موجود است.)

به روز رسانی کامل OTA فقط شامل عملیات جایگزینی و صفر است. به‌روزرسانی‌های OTA افزایشی می‌توانند عملیات کپی نیز داشته باشند.

طرح کامل عکس فوری روی دیسک به این صورت است:

cow format

شکل 2. قالب Android COW روی دیسک

dm-user

ماژول هسته dm-user userspace قادر می سازد تا دستگاه های بلوک نقشه برداری دستگاه را پیاده سازی کنند. ورودی جدول dm-user یک دستگاه متفرقه در زیر /dev/dm-user/<control-name> ایجاد می کند. یک فرآیند userspace می تواند دستگاه را برای دریافت درخواست های خواندن و نوشتن از هسته نظرسنجی کند. هر درخواست دارای یک بافر مرتبط برای فضای کاربر است که یا برای پر کردن (برای خواندن) یا انتشار (برای نوشتن) است.

ماژول هسته dm-user یک رابط کاربری قابل مشاهده جدید برای هسته ارائه می کند که بخشی از پایه کد kernel.org بالادستی نیست. تا زمانی که انجام نشده است، گوگل این حق را برای خود محفوظ می دارد که رابط dm-user را در اندروید تغییر دهد.

snapuserd

مولفه snapuserd userspace به dm-user فشرده سازی مجازی A/B را پیاده سازی می کند. Snapuserd یک دیمون فضای کاربران است که وظیفه نوشتن و خواندن دستگاه های Android COW را بر عهده دارد. تمام ورودی/خروجی به عکس فوری باید از طریق این سرویس انجام شود. در حین نصب OTA، داده های سیستم عامل جدید توسط snapuserd (با فشرده سازی) روی عکس فوری نوشته می شود. تجزیه فراداده و باز کردن بسته بندی داده های بلوک جدید نیز در اینجا انجام می شود.

فشرده سازی XOR

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، ویژگی فشرده‌سازی XOR، که به‌طور پیش‌فرض فعال است، عکس‌های فوری فضای کاربران را قادر می‌سازد تا بایت‌های فشرده‌شده XOR را بین بلوک‌های قدیمی و بلوک‌های جدید ذخیره کنند. هنگامی که تنها چند بایت در یک بلوک در یک به‌روزرسانی مجازی A/B تغییر می‌کند، طرح ذخیره‌سازی فشرده XOR از فضای کمتری نسبت به طرح ذخیره‌سازی پیش‌فرض استفاده می‌کند، زیرا عکس‌های فوری بایت‌های کامل 4K را ذخیره نمی‌کنند. این کاهش در اندازه عکس فوری امکان پذیر است زیرا داده های XOR حاوی صفرهای زیادی است و فشرده سازی آن آسان تر از داده های بلوک خام است. در دستگاه‌های پیکسل، فشرده‌سازی XOR اندازه عکس فوری را ۲۵٪ تا ۴۰٪ کاهش می‌دهد.

برای دستگاه‌هایی که به Android 13 و بالاتر ارتقا می‌یابند، فشرده‌سازی XOR باید فعال باشد. برای جزئیات، فشرده سازی XOR را ببینید.

ادغام عکس فوری

برای دستگاه‌هایی که با Android 13 و بالاتر راه‌اندازی می‌شوند، فرآیندهای ادغام عکس فوری و عکس فوری در فشرده‌سازی مجازی A/B توسط مؤلفه فضای کاربران snapuserd انجام می‌شود. برای دستگاه هایی که به اندروید 13 و بالاتر ارتقا می یابند، این ویژگی باید فعال باشد. برای جزئیات، به ادغام فضای کاربری مراجعه کنید.

در زیر فرآیند فشرده سازی مجازی A/B توضیح داده شده است:

  1. فریم ورک پارتیشن /system را از دستگاه dm-verity که در بالای دستگاه dm-user انباشته شده است نصب می کند. این بدان معناست که هر ورودی/خروجی از سیستم فایل ریشه به dm-user هدایت می شود.
  2. dm-user I/O را به دیمون snapuserd فضای کاربر هدایت می کند که درخواست I/O را مدیریت می کند.
  3. وقتی عملیات ادغام کامل شد، چارچوب dm-verity در بالای dm-linear ( system_base ) جمع می کند و dm-user حذف می کند.

فرآیند فشرده سازی مجازی A/B

شکل 3. فرآیند فشرده سازی مجازی A/B

فرآیند ادغام عکس فوری می تواند قطع شود. اگر دستگاه در حین فرآیند ادغام راه اندازی مجدد شود، فرآیند ادغام پس از راه اندازی مجدد از سر گرفته می شود.

انتقال ها را آغاز کنید

هنگام راه‌اندازی با عکس‌های فوری فشرده، init مرحله اول باید snapuserd را برای نصب پارتیشن‌ها شروع کند. این یک مشکل ایجاد می‌کند: وقتی sepolicy بارگذاری و اجرا می‌شود، snapuserd در زمینه اشتباه قرار می‌گیرد و درخواست‌های خواندن آن با رد کردن سلینوکس شکست می‌خورد.

برای رفع این مشکل، snapuserd انتقال در مرحله قفل با init را به صورت زیر انجام دهید:

  1. init مرحله اول snapuserd از ramdisk راه اندازی می کند و یک توصیفگر فایل باز را در یک متغیر محیطی در آن ذخیره می کند.
  2. init مرحله اول سیستم فایل ریشه را به پارتیشن سیستم سوئیچ می کند، سپس نسخه سیستمی init را اجرا می کند.
  3. کپی سیستم init sepolicy ترکیبی را در یک رشته می خواند.
  4. Init mlock() در تمام صفحات ext4 فراخوانی می کند. سپس تمام جداول دستگاه-نقشه نگار را برای دستگاه های عکس فوری غیرفعال می کند و snapuserd متوقف می کند. پس از این، خواندن از پارتیشن ها ممنوع است، زیرا انجام این کار باعث بن بست می شود.
  5. با استفاده از توصیفگر باز برای کپی ramdisk snapuserd ، init دیمون را با زمینه سلینوکس درست راه اندازی می کند. جداول Device-mapper برای دستگاه های Snapshot دوباره فعال می شوند.
  6. Init munlockall() فراخوانی می کند - اجرای مجدد IO بی خطر است.

استفاده از فضا

جدول زیر مقایسه ای از استفاده از فضا برای مکانیسم های OTA مختلف با استفاده از اندازه های سیستم عامل Pixel و OTA ارائه می دهد.

تاثیر اندازه غیر A/B A/B A/B مجازی A/B مجازی (فشرده شده)
تصویر اصلی کارخانه 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 1 9 گیگابایت فوق العاده (3.8G + 700M رزرو شده، برای دو اسلات) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده) 4.5 گیگابایت فوق العاده (3.8G تصویر + 700M رزرو شده)
سایر پارتیشن های ثابت /cache هیچ کدام هیچ کدام هیچ کدام
فضای ذخیره سازی اضافی در طول OTA (فضا پس از اعمال OTA برگردانده شد) 1.4 گیگابایت در /داده 0 3.8 گیگابایت 2 در /داده 2.1 گیگابایت 2 در /داده
کل فضای ذخیره‌سازی مورد نیاز برای اعمال OTA 5.9 گیگابایت 3 (فوق العاده و دیتا) 9 گیگابایت (فوق العاده) 8.3 گیگابایت 3 (فوق العاده و دیتا) 6.6 گیگابایت 3 (فوق العاده و دیتا)

1 طرح‌بندی فرضی را بر اساس نقشه‌برداری پیکسل نشان می‌دهد.

2 فرض می کند که تصویر سیستم جدید به اندازه اصلی است.

3 فضای مورد نیاز تا راه اندازی مجدد موقت است.

اندروید 11 مجازی A/B

اندروید 11 Virtual A/B با استفاده از قالب Kernel COW روی پارتیشن پویا نوشت. این در نهایت منسوخ شد زیرا قالب Kernel COW از فشرده سازی پشتیبانی نمی کند.

اندروید 12 مجازی A/B

در اندروید 12، فشرده سازی در قالب یک فرمت COW خاص اندروید پشتیبانی می شود. این نسخه از Virtual A/B به ترجمه COW خاص اندروید به قالب Kernel COW نیاز داشت. در نهایت این در اندروید 13 جایگزین شد که اتکا به فرمت Kernel COW و همچنین dm-snapshot حذف کرد.

برای پیاده سازی Virtual A/B یا استفاده از قابلیت های فشرده شده عکس فوری، به پیاده سازی Virtual A/B مراجعه کنید.