نقطة تفتيش بيانات المستخدمين

يقدّم نظام التشغيل Android 10 ميزة "نقطة التحقّق من بيانات المستخدم" (UDC)، والتي تتيح لنظام التشغيل Android الرجوع إلى حالته السابقة عند تعذُّر إجراء تحديث عبر الأثير (OTA) لنظام التشغيل Android. باستخدام ميزة "تحديث الجهاز بدون اتصال بالإنترنت"، إذا تعذّر إجراء تحديث عبر الأثير على جهاز Android، يمكن للجهاز الرجوع بأمان إلى حالته السابقة. على الرغم من أنّ تحديثات الاختبارات الثنائية تحلّ هذه المشكلة في عملية التشغيل المبكر، لا تتوفّر إمكانية الرجوع إلى الإصدار السابق عند تعديل قسم بيانات المستخدم (الذي يتم تركيبه على /data).

تتيح ميزة "التحقّق من سلامة بيانات المستخدم" للجهاز إمكانية إعادة قسم بيانات المستخدم إلى حالته الأصلية حتى بعد تعديله. تحقّق ميزة "تحديثات بدون انقطاع" ذلك من خلال توفير إمكانات نقاط التحقّق لنظام الملفات، وتنفيذ بديل عندما لا يتيح نظام الملفات نقاط التحقّق، والتكامل مع آلية A/B الخاصة ببرنامج التحميل مع إتاحة التحديثات غير A/B، وإتاحة ربط إصدار المفتاح ومنع التراجع عن إصدار المفتاح.

التأثير في المستخدم

تعمل ميزة UDC على تحسين تجربة تحديثات OTA للمستخدمين، إذ يفقد عدد أقل من المستخدمين بياناتهم عند تعذُّر إجراء تحديث OTA. ويمكن أن يؤدي ذلك إلى تقليل عدد مكالمات الدعم التي يتلقّاها فريق الدعم من المستخدمين الذين يواجهون مشاكل أثناء عملية التحديث. ومع ذلك، عند تعذُّر تثبيت تحديث عبر الأثير، قد يلاحظ المستخدمون إعادة تشغيل الجهاز عدة مرات.

طريقة العمل

وظيفة نقاط التحقّق في أنظمة الملفات المختلفة

بالنسبة إلى نظام الملفات F2FS، تضيف ميزة UDC وظيفة نقطة التحقّق إلى إصدار 4.20 من نواة Linux المتوافقة مع الإصدارات الأحدث، وتعمل على نقلها إلى جميع النواة الشائعة المتوافقة مع الأجهزة التي تعمل بنظام التشغيل Android 10.

بالنسبة إلى أنظمة الملفات الأخرى، تستخدم أداة UDC جهازًا افتراضيًا لبرنامج Device Mapper يُسمى dm_bow لأداء وظيفة نقطة التحقّق. يقع dm_bow بين الجهاز ونظام الملفات. عند ربط قسم، يتم إصدار أمر TRIM ما يؤدي إلى إصدار نظام الملفات لأوامر TRIM على جميع الكتل الحرة. تعترض dm_bow عمليات الحذف هذه وتستخدمها لإعداد قائمة حظر مجانية. بعد ذلك، يتم إرسال عمليات القراءة والكتابة إلى الجهاز بدون تعديل، ولكن قبل السماح بعملية الكتابة، يتم الاحتفاظ بنسخة احتياطية من البيانات اللازمة للاستعادة في وحدة تخزين فارغة.

عملية نقطة التفتيش

عند تثبيت قسم يتضمّن العلامة checkpoint=fs/block، يستدعي نظام التشغيل Android الدالة restoreCheckpoint على محرك الأقراص للسماح للجهاز باستعادة أي نقطة حفظ حالية. تستدعي init الدالة needsCheckpoint لتحديد ما إذا كان الجهاز في حالة برنامج تحميل الإقلاع A/B أو تم ضبط عدد محاولات إعادة التحديث. إذا كان أي منهما صحيحًا، يستدعي Android createCheckpoint إما لإضافة علامات التحميل أو لإنشاء جهاز dm_bow.

بعد تحميل القسم، يتم استدعاء رمز نقطة التحقّق لإصدار عمليات تقليم. بعد ذلك، تستمر عملية التشغيل كالمعتاد. في LOCKED_BOOT_COMPLETE، يستدعي نظام التشغيل Android الدالة commitCheckpoint لتنفيذ نقطة التحقّق الحالية ويستمر التحديث كالمعتاد.

إدارة مفاتيح KeyMint (المعروفة سابقًا باسم Keymaster)

تُستخدم مفاتيح KeyMint لتشفير الأجهزة أو لأغراض أخرى. لإدارة هذه المفاتيح، يؤخّر نظام التشغيل Android طلبات حذف المفاتيح إلى أن يتم تنفيذ نقطة التحقّق.

ملاحظة: باستخدام UDC، يكتب Android البيانات في مكان مختلف على قسم userdata.

مراقبة الحالة الصحية

تتحقّق خدمة الخلفية الخاصة بالسلامة من توفّر مساحة كافية على القرص لإنشاء نقطة فحص. يقع برنامج الخدمة الصحية في cp_healthDaemon في Checkpoint.cpp.

تتضمّن خدمة الخلفية الخاصة بالسلامة السلوكيات التالية التي يمكن ضبطها:

• ro.sys.cp_msleeptime: تتحكّم في عدد المرات التي يتحقّق فيها الجهاز من استخدام القرص.
• ‫ro.sys.cp_min_free_bytes: تتحكّم في الحد الأدنى للقيمة التي يبحث عنها برنامج الصحة الخفي.
• ro.sys.cp_commit_on_full: تتحكّم هذه السمة في ما إذا كان برنامج التشغيل الصحي يعيد تشغيل الجهاز أو يثبّت نقطة التحقّق ويواصل العمل عندما يكون القرص ممتلئًا.

Checkpoint APIs

تستخدم ميزة "التحكّم الموحّد في الأجهزة" واجهات برمجة تطبيقات نقاط التحقّق. للاطّلاع على واجهات برمجة التطبيقات الأخرى التي تستخدمها "خدمة تحويل المستندات غير المتوافقة"، يُرجى الرجوع إلى IVold.aidl.

void startCheckpoint(int retry)

تنشئ هذه الطريقة نقطة تحقّق.

يستدعي إطار العمل هذه الطريقة عندما يكون جاهزًا لبدء عملية تحديث. يتم إنشاء نقطة التحقّق قبل تحميل أنظمة الملفات التي تم إنشاء نقاط تحقّق لها، مثل بيانات المستخدم، مع إذن القراءة والكتابة بعد إعادة التشغيل. إذا كان عدد محاولات إعادة التشغيل موجبًا، ستتعامل واجهة برمجة التطبيقات مع محاولات إعادة التشغيل الخاصة بالتتبُّع، وسيطلب برنامج التحديث تنفيذ needsRollback للتحقّق مما إذا كان يجب التراجع عن التحديث. إذا كان عدد محاولات إعادة التشغيل -1، ستعتمد واجهة برمجة التطبيقات على قرار برنامج التحميل الأولي A/B.

لا يتم استدعاء هذه الطريقة عند إجراء تعديل عادي على اختبار أ/ب.

void commitChanges()

يتم تنفيذ التغييرات.

يستدعي إطار العمل هذا الإجراء بعد إعادة التشغيل عندما تكون التغييرات جاهزة للتنفيذ. يتم تنفيذ هذا الإجراء قبل كتابة البيانات (مثل الصور والفيديوهات والرسائل القصيرة وإيصال الاستلام من الخادم) في بيانات المستخدم وقبل BootComplete.

إذا لم يكن هناك تحديث نشط تم حفظ حالته، لن يكون لهذه الطريقة أي تأثير.

abortChanges()

يفرض إعادة التشغيل والعودة إلى نقطة التحقّق. يتجاهل جميع تعديلات بيانات المستخدم منذ إعادة التشغيل الأولى.

يستدعي إطار العمل هذه الطريقة بعد إعادة التشغيل ولكن قبل commitChanges. يتم تقليل قيمة retry_counter عند استدعاء هذه الطريقة. يتم إنشاء إدخالات السجلّ.

bool needsRollback()

تحدِّد هذه السمة ما إذا كان يجب إجراء عملية استرجاع.

في الأجهزة التي لا تتضمّن نقطة تحقّق، يتم عرض 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

إضافة قسم البيانات الوصفية

تتطلّب ميزة "تحديثات بدون توقف" قسمًا للبيانات الوصفية لتخزين عدد محاولات إعادة التشغيل بدون برنامج الإقلاع والمفاتيح. إعداد قسم للبيانات الوصفية وتثبيته مبكرًا في /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=fs إلى القسم <fs_mgr_flags> من fstab للجهاز الذي تم تركيبه في /data.

أنظمة غير F2FS

بالنسبة إلى الأنظمة التي لا تستخدم نظام الملفات F2FS، يجب تفعيل dm-bow في إعدادات النواة.

أضِف العلامة checkpoint=block إلى القسم <fs_mgr_flags> من fstab للجهاز الذي تم تركيبه في /data.

مراجعة السجلات

يتم إنشاء إدخالات السجلّ عند طلب بيانات من واجهات برمجة تطبيقات Checkpoint.

التحقُّق

لاختبار تنفيذ UDC، شغِّل مجموعة اختبارات VTS VtsKernelCheckpointTest.