उपयोगकर्ता के डेटा का चेकपॉइंट

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

Android 10 में उपयोगकर्ता डेटा चेकपॉइंट (यूडीसी) की सुविधा जोड़ी गई है. इससे, Android ओवर-द-एयर (ओटीए) अपडेट पूरा न होने पर, Android को उसकी पिछली स्थिति पर वापस लाया जा सकता है. यूडीसी की मदद से, अगर Android ओटीए अपडेट पूरा नहीं हो पाता है, तो डिवाइस को सुरक्षित तरीके से उसकी पिछली स्थिति पर वापस लाया जा सकता है. हालांकि A/B अपडेट की मदद से, यह समस्या हल की जा सकती है. ऐसा करने से पहले बूट करने, रोलबैक करने, और इस्तेमाल करने में यह समस्या आ सकती है उपयोगकर्ता के डेटा के पार्टीशन (/data पर माउंट किया गया) में बदलाव होने पर, काम नहीं करता.

यूडीसी की मदद से डिवाइस, उपयोगकर्ता के डेटा के बंटवारे को वापस ला सकता है. भले ही, वह संशोधित. यूडीसी की सुविधा, फ़ाइल सिस्टम में चेकपॉइंट की सुविधाओं की मदद से ऐसा करती है. यह सुविधा, फ़ाइल सिस्टम में चेकपॉइंट की सुविधा न होने पर, एक वैकल्पिक तरीके से काम करती है. साथ ही, यह बूटलोडर के A/B सिस्टम के साथ इंटिग्रेट होती है. हालांकि, यह A/B के अलावा अन्य अपडेट के साथ भी काम करती है. साथ ही, यह पासकोड के वर्शन को बांधने और पासकोड को रोलबैक होने से रोकने की सुविधा के साथ भी काम करती है.

उपयोगकर्ता पर असर

यूडीसी की सुविधा से, उपयोगकर्ताओं को ओटीए अपडेट का बेहतर अनुभव मिलता है. ऐसा इसलिए, क्योंकि ओटीए अपडेट न होने पर, कम उपयोगकर्ताओं का डेटा मिटता है. इससे सहायता कॉल की संख्या कम हो सकती है जिन्हें अपडेट प्रोसेस के दौरान समस्याएं होती हैं. हालांकि, ओटीए अपडेट न होने पर, उपयोगकर्ताओं को डिवाइस कई बार रीबूट होते हुए दिख सकता है.

यह कैसे काम करता है

अलग-अलग फ़ाइल सिस्टम में चेकपॉइंट की सुविधा

F2FS फ़ाइल सिस्टम के लिए, यूडीसी अपस्ट्रीम में चेकपॉइंट फ़ंक्शन जोड़ता है 4.20 Linux कर्नेल और इसे डिवाइस पर काम करने वाले सभी सामान्य कर्नेल पर बैकपोर्ट करता है Android 10 वर्शन पर चल रहे हैं.

अन्य फ़ाइल सिस्टम के लिए, यूडीसी, चेकपॉइंट की सुविधा के लिए, dm_bow नाम के डिवाइस मैपर वर्चुअल डिवाइस का इस्तेमाल करता है. dm_bow, डिवाइस और फ़ाइल के बीच में है सिस्टम. जब कोई पार्टीशन माउंट किया जाता है, तो ट्रिम जारी किया जाता है. इससे फ़ाइल सिस्टम, सभी खाली ब्लॉक पर ट्रिम कमांड जारी करता है. dm_bow, इन ट्रिम और इस्तेमाल में रुकावट डालता है ताकि वे बिना किसी शुल्क के ब्लॉक सूची बना सकें. पढ़ने और लिखने के बाद, डिवाइस पर भेज दिया जाता है कोई बदलाव नहीं किया गया है, लेकिन डेटा में बदलाव करने की अनुमति नहीं है, लेकिन डेटा वापस लाने के लिए ज़रूरी डेटा का बैक अप ले लिया जाता है एक फ़्री ब्लॉक तक.

Checkpoint की प्रोसेस

checkpoint=fs/block फ़्लैग वाला सेगमेंट माउंट करने पर, Android कॉल डिवाइस को मौजूदा स्टोरेज को वापस लाने के लिए, ड्राइव पर restoreCheckpoint मौजूद है COVID-19 की जांच के लिए बनी है. इसके बाद init, needsCheckpoint फ़ंक्शन को कॉल करके यह पता लगाता है कि क्या डिवाइस या तो बूटलोडर A/B स्थिति में है या उसे अपडेट करने की फिर से कोशिश करने के लिए सेट किया गया है संख्या. अगर इनमें से कोई एक सही है, तो Android, माउंट फ़्लैग जोड़ने या dm_bow डिवाइस बनाने के लिए createCheckpoint को कॉल करता है.

पार्टीशन को माउंट करने के बाद, ट्रिम करने के लिए चेकपॉइंट कोड को कॉल किया जाता है. इसके बाद, बूट प्रोसेस सामान्य तरीके से जारी रहती है. LOCKED_BOOT_COMPLETE पर, Android, मौजूदा चेकपॉइंट को कमिट करने के लिए commitCheckpoint को कॉल करता है और अपडेट सामान्य तरीके से जारी रहता है.

कीमास्टर कुंजियां प्रबंधित करें

कीमास्टर कुंजियों का इस्तेमाल डिवाइस एन्क्रिप्शन या दूसरे कामों के लिए किया जाता है. इन्हें मैनेज करने के लिए पासकोड तय करने तक, Android, पासकोड मिटाने वाले कॉल में देरी करता है.

सेहत की निगरानी करना

हेल्थ डेमन यह पुष्टि करता है कि चेकपॉइंट बनाने के लिए, डिस्क में ज़रूरत के मुताबिक जगह है या नहीं. हेल्थ डेमन, Checkpoint.cpp में cp_healthDaemon में मौजूद होता है.

हेल्थ डीमन के ये व्यवहार कॉन्फ़िगर किए जा सकते हैं:

• ro.sys.cp_msleeptime: यह नीति कंट्रोल करती है कि डिवाइस कितनी बार डिस्क के इस्तेमाल की जांच करता है.
• ro.sys.cp_min_free_bytes: इससे यह तय होता है कि हेल्थ डेमन कम से कम कौनसी वैल्यू देखेगा.
• ro.sys.cp_commit_on_full: यह कंट्रोल करता है कि हेल्थ डेमन, डिवाइस को फिर से चालू करता है या डिस्क भर जाने पर, चेकपॉइंट को लागू करता है और प्रोसेस जारी रखता है.

Checkpoint एपीआई

चेकपॉइंट एपीआई का इस्तेमाल, यूडीसी सुविधा करती है. यूडीसी की ओर से इस्तेमाल किए जाने वाले दूसरे एपीआई के लिए, यहां देखें IVold.aidl.

अमान्य startCheckpoint(फिर से कोशिश करें)

एक चेकपॉइंट बनाता है.

अपडेट शुरू करने के लिए, फ़्रेमवर्क इस तरीके को कॉल करता है. कॉन्टेंट बनाने चेकपॉइंट बनाया जाता है, तो चेकपॉइंट वाले फ़ाइल सिस्टम, जैसे कि userdata डिवाइस को फिर से चालू करने के बाद, R/W माउंट किया गया. अगर फिर से कोशिश करने की संख्या पॉज़िटिव होती है, तो एपीआई फिर से कोशिश करता है और अपडेटर, needsRollback को कॉल करके पता लगाता है कि रोल बैक हुआ है या नहीं अपडेट करना ज़रूरी है. अगर फिर से कोशिश करने की संख्या -1 है, तो एपीआई A/B bootloader के फ़ैसले पर निर्भर करता है.

सामान्य A/B अपडेट करते समय, यह तरीका कॉल नहीं किया जाता.

void commitChanges()

बदलाव लागू करता है.

फ़्रेमवर्क, रीबूट के बाद इस तरीके को कॉल करता है, जब बदलाव लागू करने के लिए तैयार हों. यह डेटा (जैसे चित्र, वीडियो, एसएमएस, सर्वर) से पहले कॉल किया जाता है रसीद की रसीद), उपयोगकर्ता के डेटा में BootComplete से पहले लिखी जाती है.

अगर कोई ऐक्टिव चेकपॉइंट अपडेट मौजूद नहीं है, तो इस तरीके से कोई असर नहीं पड़ता.

abortChanges()

डिवाइस को रीबूट करता है और उसे चेकपॉइंट पर वापस ले जाता है. पहले रीबूट के बाद से, उपयोगकर्ता डेटा में किए गए सभी बदलावों को हटा देता है.

फ़्रेमवर्क, रीबूट के बाद, लेकिन commitChanges से पहले इस तरीके को कॉल करता है. इस तरीके को कॉल करने पर, retry_counter कम हो जाता है. लॉग एंट्री हैं जनरेट किया गया.

बूल नीड्सरोलबैक()

इससे यह तय होता है कि रोल बैक करने की ज़रूरत है या नहीं.

बिना चेकपॉइंट वाले डिवाइसों पर, false दिखाता है. चेकपॉइंट डिवाइसों पर, नॉन-चेकपॉइंट बूट के दौरान true दिखाता है.

यूडीसी को लागू करना

रेफ़रंस के तौर पर लागू करना

यूडीसी को कैसे लागू किया जा सकता है, इसका उदाहरण नीचे दिया गया है. dm-bow.c पर सेट किया जा सकता है. इस सुविधा के बारे में अतिरिक्त दस्तावेज़ पाने के लिए, यहां जाएं dm-bow.txt इस्तेमाल करें.

सेटअप

अपनी init.hardware.rc फ़ाइल में मौजूद on fs की फ़ाइल में, पक्का करें कि:

mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early

अपनी init.hardware.rc फ़ाइल में on late-fs में, पक्का करें कि आपके पास ये चीज़ें हों:

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 वर्शन चेकपॉइंट का इस्तेमाल करता है. ज़्यादा जानकारी के लिए, अलग-अलग फ़ाइल सिस्टम का इस्तेमाल करते हैं.

इसके लिए fstab के <fs_mgr_flags> सेक्शन में checkpoint=fs फ़्लैग जोड़ें डिवाइस /data पर माउंट किया गया.

नॉन-F2FS सिस्टम

गैर-F2FS सिस्टम के लिए, dm-bow कर्नेल कॉन्फ़िगरेशन में चालू होना चाहिए.

/data पर माउंट किए गए डिवाइस के लिए, fstab के <fs_mgr_flags> सेक्शन में checkpoint=block फ़्लैग जोड़ें.

लॉग देखें

Checkpoint API को कॉल करने पर, लॉग एंट्री जनरेट होती हैं.

पुष्टि करें

यूडीसी लागू करने की जांच करने के लिए, VtsKernelCheckpointTest वीटीएस जांच का सेट चलाएं.