نمای کلی «آزمایش A/B مجازی»

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

A/B مجازی درواقع اسلات اضافی برای پارتیشن‌های پویا ندارد، پارتیشن‌های پویا را ببینید. درعوض، دلتا در یک نمای فوری نوشته می‌شود و سپس پس‌از تأیید راه‌اندازی موفق، در پارتیشن پایه ادغام می‌شود. «A/B مجازی» از قالب عکس آنی مختص Android استفاده می‌کند. به قالب COW برای عکس‌های آنی فشرده مراجعه کنید که امکان فشرده‌سازی عکس‌های آنی را فراهم می‌کند و استفاده از فضای دیسک را به حداقل می‌رساند. در OTA کامل، اندازه عکس آنی با فشرده‌سازی حدود ۴۵٪ کاهش می‌یابد و اندازه عکس آنی OTA افزایشی حدود ۵۵٪ کاهش می‌یابد.

‫Android 12 گزینه فشرده‌سازی مجازی A/B را برای فشرده‌سازی پارتیشن‌های لحظه‌ای ارائه می‌دهد. آزمایش آ/ب مجازی موارد زیر را ارائه می‌دهد

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

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

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

Device-mapper

«دستگاه‌نگار» لایه بلوک مجازی Linux است که اغلب در Android استفاده می‌شود. با پارتیشن‌های پویا، پارتیشن‌هایی مثل /system پشته‌ای از دستگاه‌های لایه‌ای هستند:

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

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

شکل ۱. انباشت زیر نقطه نصب system/

عکس‌های آنی فشرده

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

عکس‌های آنی فشرده‌شده Virtual A/B براساس مؤلفه‌های زیر ساخته شده‌اند که در Android 12 و بالاتر دردسترس هستند:

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

این مؤلفه‌ها فشرده‌سازی را فعال می‌کنند. دیگر تغییرات لازم برای پیاده‌سازی قابلیت‌های تصاویر لحظه‌ای فشرده در بخش‌های بعدی ارائه شده است: قالب COW برای تصاویر لحظه‌ای فشرده، dm-user، و snapuserd.

قالب COW برای تصاویر لحظه‌ای فشرده

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

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

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

چیدمان کامل لحظه‌عکس روی دیسک به این شکل است:

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

dm-user

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

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

snapuserd

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

فشرده‌سازی XOR

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

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

ادغام عکس آنی

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

در زیر فرایند فشرده‌سازی Virtual A/B شرح داده شده است:

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

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

فرایند ادغام لحظه‌ای می‌تواند قطع شود. اگر دستگاه درطول فرایند ادغام بازراه‌اندازی شود، فرایند ادغام پس‌از بازراه‌اندازی ازسر گرفته می‌شود.

انتقال‌های اولیه

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

برای رسیدگی به این موضوع، snapuserd هم‌گام با init به‌شرح زیر انتقال می‌یابد:

1. init مرحله اول snapuserd را از ramdisk راه‌اندازی می‌کند و توصیف‌گر فایل باز را در متغیر محیطی در آن ذخیره می‌کند.
2. init مرحله اول سیستم فایل ریشه را به پارتیشن سیستم تغییر می‌دهد، سپس نسخه سیستم init را اجرا می‌کند.
3. نسخه سیستم init sepolicy ترکیبی را در یک رشته می‌خواند.
4. ‫Init mlock() را در همه صفحه‌های پشتیبانی‌شده با ext4 فرا می‌خواند. سپس همه جدول‌های نگاشت‌گر دستگاه را برای دستگاه‌های عکس آنی غیرفعال می‌کند و snapuserd را متوقف می‌کند. پس‌از این، خواندن از پارتیشن‌ها ممنوع است، زیرا این کار باعث بن‌بست می‌شود.
5. استفاده از توصیفگر باز برای کپی ramdisk از snapuserd، init شبح را با زمینه selinux صحیح مجدداً راه‌اندازی می‌کند. جدول‌های «نگاشت دستگاه» برای دستگاه‌های لحظه‌ای دوباره فعال می‌شوند.
6. ‫Init munlockall() را فرا می‌خواند - انجام دوباره ورودی/خروجی ایمن است.

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

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

تأثیر اندازه	غیر آ/ب	آزمایش آ/ب	آزمایش آ/ب مجازی	آزمایش آ/ب مجازی (فشرده)
تصویر کارخانه اصلی	‫۴٫۵ گیگابایت فوق‌العاده (۳٫۸ گیگابایت تصویر + ۷۰۰ مگابایت رزروشده)۱	‫۹ گیگابایت فوق‌العاده (۳٫۸ گیگابایت + ۷۰۰ مگابایت رزروشده، برای دو جایگاه)	‫۴٫۵ گیگابایت فوق‌العاده (۳٫۸ گیگابایت تصویر + ۷۰۰ مگابایت رزروشده)	‫۴٫۵ گیگابایت فوق‌العاده (۳٫۸ گیگابایت تصویر + ۷۰۰ مگابایت رزروشده)
دیگر «بخش‌های ثابت»	/cache	هیچ‌کدام	هیچ‌کدام	هیچ‌کدام
فضای ذخیره‌سازی اضافی درطول به‌روزرسانی ازطریق هوا (فضا پس‌از اعمال به‌روزرسانی ازطریق هوا برگردانده می‌شود)	‫۱٫۴ گیگابایت در /data	0	‫۳٫۸ گیگابایت۲ در /data	‫۲٫۱ گیگابایت۲ در data/
فضای ذخیره‌سازی کل موردنیاز برای اعمال OTA	‫۵٫۹ گیگابایت۳ (فوق‌العاده و داده)	‫۹ گیگابایت (فوق‌العاده)	‫۸٫۳ گیگابایت۳ (فوق‌العاده و داده)	‫۶٫۶ گیگابایت۳ (فوق‌العاده و داده)

^۱نشان‌دهنده چیدمان فرضی براساس نگاشت پیکسل است.

^۲فرض می‌کند تصویر سیستم جدید هم‌اندازه تصویر اصلی است.

^۳فضای موردنیاز تا راه‌اندازی مجدد گذرا است.

‫Android 11 Virtual A/B

‫Android 11 «آزمایش A/B مجازی» بااستفاده از قالب Kernel COW در پارتیشن پویا نوشت. این قالب درنهایت منسوخ شد زیرا قالب Kernel COW از فشرده‌سازی پشتیبانی نمی‌کند.

‫Android 12 Virtual A/B

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

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