اندروید دو مکانیسم بهروزرسانی دارد: بهروزرسانیهای A/B (بدون درز) و بهروزرسانیهای غیر A/B. برای کاهش پیچیدگی کد و بهبود فرآیند بهروزرسانی، در اندروید 11 این دو مکانیسم از طریق A/B مجازی متحد شدهاند تا بهروزرسانیهای یکپارچه را برای همه دستگاهها با حداقل هزینه ذخیرهسازی ارائه کنند. اندروید 12 گزینه فشرده سازی مجازی A/B را برای فشرده سازی پارتیشن های عکس فوری ارائه می دهد. در اندروید 11 و اندروید 12 موارد زیر اعمال می شود:
- بهروزرسانیهای مجازی A/B مانند بهروزرسانیهای A/B یکپارچه هستند. بهروزرسانیهای مجازی A/B زمان آفلاین بودن و غیرقابل استفاده بودن دستگاه را به حداقل میرسانند.
- بهروزرسانیهای مجازی A/B را میتوان برگرداند . اگر سیستم عامل جدید راه اندازی نشود، دستگاه ها به طور خودکار به نسخه قبلی برمی گردند.
- بهروزرسانیهای مجازی A/B با کپی کردن تنها پارتیشنهایی که توسط بوتلودر استفاده میشوند ، از حداقل فضای اضافی استفاده میکنند. سایر پارتیشن های قابل به روز رسانی به صورت لحظه ای هستند.
پیشینه و اصطلاحات
این بخش اصطلاحات را تعریف می کند و فناوری را که از A/B مجازی پشتیبانی می کند، توضیح می دهد.
نقشهبردار دستگاه
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. در زیر نقطه نصب سیستم / قرار دهید
dm-snapshot
A/B مجازی به dm-snapshot
، یک ماژول نقشهبردار دستگاه برای گرفتن عکس فوری از وضعیت یک دستگاه ذخیرهسازی متکی است. هنگام استفاده از dm-snapshot
، چهار دستگاه در حال بازی هستند:
- دستگاه پایه دستگاهی است که عکس فوری گرفته می شود. در این صفحه، دستگاه پایه همیشه یک پارتیشن پویا است، مانند سیستم یا فروشنده.
- دستگاه کپی در نوشتن (COW)، برای ثبت تغییرات در دستگاه پایه. این می تواند هر اندازه ای باشد، اما باید به اندازه کافی بزرگ باشد تا تمام تغییرات دستگاه پایه را در خود جای دهد.
- دستگاه عکس فوری با استفاده از هدف
snapshot
ایجاد می شود. نوشته های روی دستگاه عکس فوری در دستگاه COW نوشته می شود. بسته به اینکه داده های مورد دسترسی توسط عکس فوری تغییر کرده باشند، از دستگاه عکس فوری خوانده می شود یا از دستگاه پایه یا دستگاه COW. - دستگاه مبدا با استفاده از
snapshot-origin
target ایجاد می شود. به دستگاه مبدأ می خواند که مستقیماً از دستگاه پایه خوانده می شود. در دستگاه مبدأ مستقیماً روی دستگاه پایه مینویسد، اما از دادههای اصلی با نوشتن در دستگاه COW پشتیبانگیری میشود.
شکل 2. نقشه برداری دستگاه برای dm-snapshot
عکس های فوری فشرده شده
در اندروید 12 و بالاتر، از آنجایی که فضای مورد نیاز در پارتیشن /data
میتواند زیاد باشد، میتوانید عکسهای فوری فشردهشده را در ساخت خود فعال کنید تا فضای مورد نیاز پارتیشن /data
را برطرف کند.
عکسهای فوری فشرده A/B مجازی بر روی اجزای زیر ساخته شدهاند که در اندروید ۱۲ و بالاتر در دسترس هستند:
-
dm-user
، یک ماژول هسته شبیه به FUSE که به فضای کاربران اجازه می دهد تا دستگاه های بلوک را پیاده سازی کنند. -
snapuserd
، یک دیمون فضای کاربران برای پیاده سازی یک قالب عکس فوری جدید.
این اجزا باعث فشرده سازی می شوند. سایر تغییرات لازم برای اجرای قابلیتهای snapshot فشرده در بخشهای بعدی آورده شده است: فرمت COW برای عکسهای فوری فشرده ، dm-user و Snapuserd .
فرمت COW برای عکس های فوری فشرده
در اندروید ۱۲ و بالاتر، عکسهای فوری فشرده از فرمت COW استفاده میکنند. مشابه فرمت داخلی هسته که برای عکسهای فوری غیرفشرده استفاده میشود، فرمت COW برای عکسهای فوری فشرده دارای بخشهای متناوب متادیتا و داده است. فراداده قالب اصلی فقط برای عملیات جایگزینی مجاز است: بلوک X را در تصویر پایه با محتوای بلوک Y در عکس فوری جایگزین کنید. فرمت عکس های فوری فشرده COW گویاتر است و از عملیات زیر پشتیبانی می کند:
- کپی : بلوک X در دستگاه پایه باید با بلوک Y در دستگاه پایه جایگزین شود.
- جایگزینی : بلوک X در دستگاه پایه باید با محتویات بلوک Y در عکس فوری جایگزین شود. هر یک از این بلوک ها به صورت gz فشرده شده است.
- صفر : بلوک X در دستگاه پایه باید با تمام صفرها جایگزین شود.
- XOR : دستگاه COW بایت های فشرده شده XOR را بین بلوک X و بلوک Y ذخیره می کند. (در اندروید 13 و بالاتر موجود است.)
به روز رسانی کامل OTA فقط شامل عملیات جایگزینی و صفر است. بهروزرسانیهای OTA افزایشی میتوانند عملیات کپی نیز داشته باشند.
dm-user در اندروید 12
ماژول هسته dm-user userspace
را قادر می سازد تا دستگاه های بلوک نقشه برداری دستگاه را پیاده سازی کنند. ورودی جدول dm-user یک دستگاه متفرقه در زیر /dev/dm-user/<control-name>
ایجاد می کند. یک فرآیند userspace
می تواند دستگاه را برای دریافت درخواست های خواندن و نوشتن از هسته نظرسنجی کند. هر درخواست دارای یک بافر مرتبط برای فضای کاربر است که یا برای پر کردن (برای خواندن) یا انتشار (برای نوشتن) است.
ماژول هسته dm-user
یک رابط کاربری قابل مشاهده جدید برای هسته ارائه می کند که بخشی از پایه کد kernel.org بالادستی نیست. تا زمانی که انجام نشده است، گوگل این حق را برای خود محفوظ می دارد که رابط dm-user
را در اندروید تغییر دهد.
snapuserd
مولفه snapuserd
userspace به dm-user
فشرده سازی مجازی A/B را پیاده سازی می کند.
در نسخه غیر فشرده Virtual A/B، (چه در اندروید 11 و پایین تر، چه در اندروید 12 بدون گزینه عکس فوری فشرده)، دستگاه COW یک فایل خام است. هنگامی که فشرده سازی فعال است، COW در عوض به عنوان یک دستگاه dm-user
عمل می کند که به نمونه ای از دیمون snapuserd
متصل است.
هسته از قالب جدید COW استفاده نمی کند. بنابراین مؤلفه snapuserd
درخواست ها را بین قالب Android COW و قالب داخلی هسته ترجمه می کند:
شکل 3. نمودار جریان snapuserd به عنوان مترجم بین قالب های Android و Kernel COW
این ترجمه و فشرده سازی هرگز روی دیسک اتفاق نمی افتد. مؤلفه snapuserd
خواندن و نوشتن COW را که در هسته اتفاق میافتد رهگیری میکند و با استفاده از قالب Android COW آنها را پیادهسازی میکند.
فشرده سازی XOR
برای دستگاههایی که با Android 13 و بالاتر راهاندازی میشوند، ویژگی فشردهسازی XOR، که بهطور پیشفرض فعال است، عکسهای فوری فضای کاربران را قادر میسازد تا بایتهای فشردهشده XOR را بین بلوکهای قدیمی و بلوکهای جدید ذخیره کنند. هنگامی که تنها چند بایت در یک بلوک در یک بهروزرسانی مجازی A/B تغییر میکند، طرح ذخیرهسازی فشرده XOR از فضای کمتری نسبت به طرح ذخیرهسازی پیشفرض استفاده میکند، زیرا عکسهای فوری بایتهای کامل 4K را ذخیره نمیکنند. این کاهش در اندازه عکس فوری امکان پذیر است زیرا داده های XOR حاوی صفرهای زیادی است و فشرده سازی آن آسان تر از داده های بلوک خام است. در دستگاههای پیکسل، فشردهسازی XOR اندازه عکس فوری را ۲۵٪ تا ۴۰٪ کاهش میدهد.
برای دستگاههایی که به Android 13 و بالاتر ارتقا مییابند، فشردهسازی XOR باید فعال باشد. برای جزئیات، فشرده سازی XOR را ببینید.
فرآیندهای فشرده سازی مجازی A/B
این بخش جزئیاتی در مورد فرآیند فشرده سازی مجازی A/B مورد استفاده در اندروید 13 و اندروید 12 ارائه می دهد.
خواندن متادیتا (اندروید 12)
ابرداده توسط یک دیمون snapuserd
ساخته شده است. ابرداده در درجه اول نقشه برداری از دو شناسه، هر کدام 8 بایت است که نشان دهنده بخش هایی است که باید ادغام شوند. در dm-snapshot
به آن disk_exception
می گویند.
struct disk_exception {
uint64_t old_chunk;
uint64_t new_chunk;
};
یک استثنای دیسک زمانی استفاده می شود که یک تکه داده قدیمی با یک قطعه جدید جایگزین شود.
یک شبح snapuserd
فایل COW داخلی را از طریق کتابخانه COW می خواند و ابرداده را برای هر یک از عملیات COW موجود در فایل COW می سازد.
خواندن فراداده از dm-snapshot
در هسته زمانی که دستگاه dm- snapshot
ایجاد می شود آغاز می شود.
شکل زیر یک نمودار توالی برای مسیر IO برای ساخت ابرداده ارائه می دهد.
شکل 4. جریان دنباله ای برای مسیر IO در ساخت ابرداده
ادغام (اندروید 12)
پس از تکمیل فرآیند بوت، موتور بهروزرسانی، اسلات را بهعنوان بوت موفق علامتگذاری میکند و با تغییر هدف dm-snapshot
به هدف dm-snapshot-merge
ادغام را آغاز میکند.
dm-snapshot
از میان ابرداده ها عبور می کند و یک IO ادغام را برای هر استثنای دیسک آغاز می کند. یک نمای کلی از مسیر ادغام IO در زیر نشان داده شده است.
شکل 5. نمای کلی مسیر IO را ادغام کنید
اگر دستگاه در طول فرآیند ادغام راه اندازی مجدد شود، ادغام در راه اندازی مجدد بعدی از سر گرفته می شود و ادغام کامل می شود.
لایه بندی دستگاه-نقشه نگار
برای دستگاههایی که با 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
را حذف می کند.
شکل 6. فرآیند فشرده سازی مجازی 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 گیگابایت در /data | 0 | 3.8 گیگابایت 2 در /داده | 2.1 گیگابایت 2 در /داده |
کل فضای ذخیرهسازی مورد نیاز برای اعمال OTA | 5.9 گیگابایت 3 (فوق العاده و دیتا) | 9 گیگابایت (فوق العاده) | 8.3 گیگابایت 3 (فوق العاده و دیتا) | 6.6 گیگابایت 3 (فوق العاده و دیتا) |
1 طرحبندی فرضی را بر اساس نقشهبرداری پیکسل نشان میدهد.
2 فرض می کند که تصویر سیستم جدید به اندازه اصلی است.
3 فضای مورد نیاز تا راه اندازی مجدد موقت است.
برای پیاده سازی Virtual A/B یا استفاده از قابلیت های فشرده شده عکس فوری، به پیاده سازی Virtual A/B مراجعه کنید.