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
چگونه به نظر می رسد.
شکل 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 افزایشی میتوانند عملیات کپی نیز داشته باشند.
طرح کامل عکس فوری روی دیسک به این صورت است:
شکل 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 توضیح داده شده است:
- فریم ورک پارتیشن
/system
را از دستگاهdm-verity
که در بالای دستگاهdm-user
انباشته شده است نصب می کند. این بدان معناست که هر ورودی/خروجی از سیستم فایل ریشه بهdm-user
هدایت می شود. -
dm-user
I/O را به دیمونsnapuserd
فضای کاربر هدایت می کند که درخواست I/O را مدیریت می کند. - وقتی عملیات ادغام کامل شد، چارچوب
dm-verity
در بالایdm-linear
(system_base
) جمع می کند وdm-user
را حذف می کند.
شکل 3. فرآیند فشرده سازی مجازی A/B
فرآیند ادغام عکس فوری می تواند قطع شود. اگر دستگاه در حین فرآیند ادغام راه اندازی مجدد شود، فرآیند ادغام پس از راه اندازی مجدد از سر گرفته می شود.
انتقال ها را آغاز کنید
هنگام راهاندازی با عکسهای فوری فشرده، init مرحله اول باید snapuserd
برای نصب پارتیشنها شروع کند. این یک مشکل ایجاد میکند: وقتی sepolicy
بارگذاری و اجرا میشود، snapuserd
در زمینه اشتباه قرار میگیرد و درخواستهای خواندن آن با رد کردن سلینوکس شکست میخورد.
برای رفع این مشکل، snapuserd
انتقال در مرحله قفل با init
را به صورت زیر انجام دهید:
-
init
مرحله اولsnapuserd
از ramdisk راه اندازی می کند و یک توصیفگر فایل باز را در یک متغیر محیطی در آن ذخیره می کند. -
init
مرحله اول سیستم فایل ریشه را به پارتیشن سیستم سوئیچ می کند، سپس نسخه سیستمیinit
را اجرا می کند. - کپی سیستم
init
، sepolicy ترکیبی را در یک رشته می خواند. -
Init
mlock()
در تمام صفحات ext4 فراخوانی می کند. سپس تمام جداول دستگاه-نقشه نگار را برای دستگاه های عکس فوری غیرفعال می کند وsnapuserd
متوقف می کند. پس از این، خواندن از پارتیشن ها ممنوع است، زیرا انجام این کار باعث بن بست می شود. - با استفاده از توصیفگر باز برای کپی ramdisk
snapuserd
،init
دیمون را با زمینه سلینوکس درست راه اندازی می کند. جداول Device-mapper برای دستگاه های Snapshot دوباره فعال می شوند. - 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 مراجعه کنید.