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

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

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

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

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

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

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

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 किसी भी माउंट को जोड़ने के लिए createCheckpoint को कॉल करता है फ़्लैग करने या dm_bow डिवाइस बनाने का तरीका.

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

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

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

सेहत पर नज़र रखें

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

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

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

Checkpoint एपीआई

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

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

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

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

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

कुकी में किए गए बदलाव अमान्य हैं

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

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

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

abortबदलाव()

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

फ़्रेमवर्क इस तरीके को डिवाइस को फिर से चालू करने के बाद, लेकिन 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 कर्नेल कॉन्फ़िगरेशन में चालू होना चाहिए.

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

लॉग देखें

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

पुष्टि करें

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