Android 10 User Data Checkpoint (UDC) را معرفی میکند، که به اندروید اجازه میدهد در صورت عدم موفقیت در بهروزرسانی خارج از هوا (OTA) اندروید به حالت قبلی خود بازگردد. با UDC، اگر یک بهروزرسانی OTA Android ناموفق باشد، دستگاه میتواند با خیال راحت به حالت قبلی خود برگردد. اگرچه بهروزرسانیهای A/B این مشکل را برای راهاندازی زودهنگام حل میکند، وقتی پارتیشن دادههای کاربر (نصب شده در /data
) اصلاح میشود، بازگشت مجدد پشتیبانی نمیشود.
UDC دستگاه را قادر می سازد تا پارتیشن داده های کاربر را حتی پس از تغییر بازگرداند. ویژگی UDC این کار را با قابلیتهای ایست بازرسی در سیستم فایل، پیادهسازی جایگزین زمانی که سیستم فایل از نقاط بازرسی پشتیبانی نمیکند، ادغام با مکانیزم بوتلودر A/B و همچنین پشتیبانی از بهروزرسانیهای غیر A/B، و پشتیبانی از اتصال نسخه کلیدی انجام میدهد. و جلوگیری از بازگشت کلید.
تاثیر کاربر
ویژگی UDC تجربه بهروزرسانی OTA را برای کاربران بهبود میبخشد زیرا کاربران کمتری دادههای خود را در صورت عدم موفقیت بهروزرسانی OTA از دست میدهند. این میتواند تعداد تماسهای پشتیبانی کاربرانی را که در طول فرآیند بهروزرسانی با مشکل مواجه میشوند، کاهش دهد. با این حال، هنگامی که بهروزرسانی OTA با شکست مواجه میشود، کاربران ممکن است چندین بار متوجه راهاندازی مجدد دستگاه شوند.
چگونه کار می کند
قابلیت چک پوینت در سیستم های فایل مختلف
برای سیستم فایل F2FS، UDC قابلیت چک پوینت را به هسته بالادست لینوکس 4.20 اضافه می کند و آن را به تمام هسته های رایج پشتیبانی شده توسط دستگاه های دارای اندروید 10 پشتیبانی می کند.
برای سیستم های فایل دیگر، UDC از یک دستگاه مجازی نگاشت دستگاه به نام dm_bow
برای عملکرد ایست بازرسی استفاده می کند. dm_bow
بین دستگاه و سیستم فایل قرار می گیرد. هنگامی که یک پارتیشن نصب می شود، یک trim صادر می شود که باعث می شود سیستم فایل دستورات trim را روی تمام بلوک های آزاد صادر کند. dm_bow
این برشها را قطع میکند و از آنها برای تنظیم یک لیست بلاک رایگان استفاده میکند. سپس خواندن و نوشتن بدون تغییر به دستگاه ارسال می شود، اما قبل از مجاز شدن نوشتن، از داده های مورد نیاز برای بازیابی در یک بلوک رایگان نسخه پشتیبان تهیه می شود.
فرآیند ایست بازرسی
هنگامی که پارتیشنی با پرچم checkpoint=fs/block
نصب میشود، Android با restoreCheckpoint
روی درایو تماس میگیرد تا به دستگاه اجازه دهد هر نقطه بازرسی فعلی را بازیابی کند. سپس init
تابع needsCheckpoint
را فراخوانی میکند تا مشخص کند آیا دستگاه در وضعیت بوتلودر A/B است یا تعداد تلاش مجدد بهروزرسانی را تنظیم کرده است. اگر هر کدام درست باشد، اندروید createCheckpoint
برای اضافه کردن پرچمهای نصب یا ساخت دستگاه dm_bow
فراخوانی میکند.
پس از نصب پارتیشن، کد چک پوینت برای صدور trims فراخوانی می شود. سپس فرآیند بوت به صورت عادی ادامه می یابد. در LOCKED_BOOT_COMPLETE
، Android با commitCheckpoint
تماس میگیرد تا نقطه بازرسی فعلی را انجام دهد و بهروزرسانی بهطور عادی ادامه مییابد.
کلیدهای keymaster را مدیریت کنید
کلیدهای Keymaster برای رمزگذاری دستگاه یا اهداف دیگر استفاده می شوند. برای مدیریت این کلیدها، Android تماسهای حذف کلید را تا زمانی که نقطه بازرسی متعهد شود به تأخیر میاندازد.
نظارت بر سلامت
یک شبح سلامت تأیید می کند که فضای دیسک کافی برای ایجاد یک نقطه بازرسی وجود دارد. شبح سلامت در cp_healthDaemon
در Checkpoint.cpp
قرار دارد.
شبح سلامت رفتارهای زیر را دارد که می توان آنها را پیکربندی کرد:
-
ro.sys.cp_msleeptime
: کنترل می کند که دستگاه چقدر استفاده از دیسک را بررسی می کند. -
ro.sys.cp_min_free_bytes
: حداقل مقداری را که شبح سلامت به دنبال آن است را کنترل می کند. -
ro.sys.cp_commit_on_full
: کنترل می کند که شبح سلامت دستگاه را راه اندازی مجدد کند یا نقطه بازرسی را انجام دهد و زمانی که دیسک پر است ادامه می دهد.
API های Checkpoint
Checkpoint API توسط ویژگی UDC استفاده می شود. برای سایر APIهای مورد استفاده توسط UDC، به IVold.aidl
مراجعه کنید.
نقطه شروع چک باطل (تکرار مجدد)
یک ایست بازرسی ایجاد می کند.
فریم ورک زمانی این روش را فراخوانی می کند که آماده شروع به روز رسانی باشد. نقطه بازرسی قبل از اینکه سیستم های فایل دارای نقطه بازرسی مانند داده های کاربر پس از راه اندازی مجدد R/W نصب شوند ایجاد می شود. اگر تعداد تلاشهای مجدد مثبت باشد، API تلاشهای مجدد ردیابی را انجام میدهد، و بهروزرسانیکننده needsRollback
را فراخوانی میکند تا بررسی کند که آیا بازگشت بهروزرسانی لازم است یا خیر. اگر تعداد تلاش مجدد -1
باشد، API به قضاوت بوت لودر A/B موکول می شود.
این روش هنگام انجام بهروزرسانی معمولی A/B فراخوانی نمیشود.
void commitChanges()
تغییرات را متعهد می شود.
فریم ورک این متد را پس از راهاندازی مجدد، زمانی که تغییرات آماده انجام شدن هستند، فراخوانی میکند. این قبل از نوشتن داده ها (مانند تصاویر، ویدئو، پیامک، دریافت دریافت سرور) روی داده های کاربر و قبل از BootComplete
فراخوانی می شود.
اگر هیچ بهروزرسانی فعالی وجود نداشته باشد، این روش تأثیری ندارد.
abortChanges()
راه اندازی مجدد را مجبور می کند و به ایست بازرسی باز می گردد. از اولین راهاندازی مجدد، تمام تغییرات دادههای کاربر را رها میکند.
فریم ورک این متد را بعد از راه اندازی مجدد اما قبل از commitChanges
فراخوانی می کند. retry_counter
با فراخوانی این متد کاهش می یابد. ورودی های گزارش تولید می شوند.
bool needRollback()
تعیین می کند که آیا بازگشت مجدد مورد نیاز است یا خیر.
در دستگاههای غیربازرسی، false
را برمیگرداند. در دستگاه های ایست بازرسی، در هنگام بوت غیربازرسی، true
را برمی گرداند.
UDC را اجرا کنید
پیاده سازی مرجع
برای مثالی از نحوه پیاده سازی UDC، به dm-bow.c مراجعه کنید. برای مستندات بیشتر در مورد این ویژگی، dm-bow.txt را ببینید.
راه اندازی
در on fs
در فایل init.hardware.rc
خود، مطمئن شوید که:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
در on late-fs
در فایل init.hardware.rc
خود، مطمئن شوید که:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
در فایل fstab.hardware
خود، مطمئن شوید که /data
به عنوان latemount
برچسب گذاری شده است.
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
اضافه کردن پارتیشن متادیتا
UDC به یک پارتیشن ابرداده برای ذخیره تعداد و کلیدهای امتحان مجدد nonbootloader نیاز دارد. یک پارتیشن ابرداده راه اندازی کنید و آن را زودتر در /metadata
نصب کنید.
در فایل fstab.hardware
خود، مطمئن شوید که /metadata
با عنوان earlymount
یا first_stage_mount
برچسب گذاری شده است.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
پارتیشن را به تمام صفرها مقداردهی اولیه کنید.
خطوط زیر را به BoardConfig.mk
اضافه کنید:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
به روز رسانی سیستم ها
سیستم های F2FS
برای سیستمهایی که از F2FS برای قالببندی دادهها استفاده میکنند، مطمئن شوید که نسخه F2FS شما از نقاط بازرسی پشتیبانی میکند. برای اطلاعات بیشتر، به عملکرد Checkpoint در سیستم های فایل مختلف مراجعه کنید.
پرچم checkpoint=fs
به بخش <fs_mgr_flags>
fstab برای دستگاه نصب شده در /data
اضافه کنید.
سیستم های غیر F2FS
برای سیستم های غیر F2FS، dm-bow
باید در پیکربندی هسته فعال باشد.
پرچم checkpoint=block
به بخش <fs_mgr_flags>
fstab برای دستگاه نصب شده در /data
اضافه کنید.
سیاهههای مربوط را بررسی کنید
هنگامی که Checkpoint API فراخوانی می شود، ورودی های گزارش ایجاد می شوند.
اعتبار سنجی
برای آزمایش پیاده سازی UDC خود، مجموعه تست های VTS VtsKernelCheckpointTest
را اجرا کنید.