ایست بازرسی داده های کاربر

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 را اجرا کنید.

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 را اجرا کنید.