Android 10 पर काम करता है डाइनैमिक पार्टीशन, यूज़रस्पेस पार्टीशन यह एक ऐसे सिस्टम का इस्तेमाल करता है जो ओवर-द-एयर (ओटीए) अपडेट के दौरान पार्टिशन बना सकता है, उनका साइज़ बदल सकता है, और उन्हें नष्ट कर सकता है.
इस पेज पर बताया गया है कि A/B डिवाइसों को अपडेट करने के दौरान, ओटीए क्लाइंट, डाइनैमिक पार्टिशन का साइज़ कैसे बदलते हैं जो डाइनैमिक पार्टीशन के बिना लॉन्च हुई और ओटीए क्लाइंट को Android 10 पर कैसे अपग्रेड किया गया.
बैकग्राउंड
डाइनैमिक पार्टीशन की सुविधा के साथ काम करने के लिए, A/B डिवाइस को अपडेट करने के दौरान, डिवाइस पर मौजूद GUID पार्टीशन टेबल (GPT) को सुरक्षित रखा जाता है. इसलिए, डिवाइस पर कोई super
पार्टीशन नहीं होता. मेटाडेटा को system_a
और system_b
में सेव किया जाता है. हालांकि, BOARD_SUPER_PARTITION_METADATA_DEVICE
को बदलकर, इसे अपनी पसंद के मुताबिक बनाया जा सकता है.
ब्लॉक किए गए हर डिवाइस में, दो मेटाडेटा स्लॉट होते हैं. सिर्फ़ एक
हर ब्लॉक डिवाइस में मेटाडेटा स्लॉट का इस्तेमाल किया जाता है. उदाहरण के लिए, system_a
पर मौजूद मेटाडेटा 0 और system_b
पर मौजूद मेटाडेटा 1, क्रमशः A और B स्लॉट के पार्टीशन से जुड़े हैं. पर
रनटाइम, तो इससे कोई फ़र्क़ नहीं पड़ता कि कौनसा स्लॉट अपडेट किया जा रहा है.
इस पेज में, मेटाडेटा स्लॉट को मेटाडेटा S (सोर्स) और मेटाडेटा T (टारगेट) कहा जाता है. इसी तरह, सेगमेंट को
system_s
, vendor_t
वगैरह तक.
सिस्टम कॉन्फ़िगरेशन बिल्ड करें के बारे में ज़्यादा जानकारी के लिए, यहां देखें डिवाइस अपग्रेड किए जा रहे हैं.
नए डिवाइसों के लिए, बोर्ड के कॉन्फ़िगरेशन में हुए बदलाव देखें. इससे आपको यह जानकारी मिलेगी कि अपडेट ग्रुप में, पार्टीशन किस तरह शामिल होते हैं.
किसी डिवाइस पर मेटाडेटा का उदाहरण:
- फ़िज़िकल ब्लॉक डिवाइस
system_a
- मेटाडेटा 0
- ग्रुप
foo_a
- लॉजिकल (डाइनैमिक) पार्टीशन
system_a
- लॉजिकल (डाइनैमिक) पार्टीशन
product_services_a
- Foo ने अपडेट किए गए अन्य पार्टीशन
- लॉजिकल (डाइनैमिक) पार्टीशन
- ग्रुप
bar_a
- लॉजिकल (डाइनैमिक) पार्टीशन
vendor_a
- लॉजिकल (डाइनैमिक) पार्टीशन
product_a
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - अन्य पार्टिशन बार से अपडेट किए गए
- लॉजिकल (डाइनैमिक) पार्टीशन
- ग्रुप
- मेटाडेटा 1 (इस्तेमाल नहीं किया गया)
- मेटाडेटा 0
- फ़िज़िकल ब्लॉक डिवाइस
system_b
- मेटाडेटा 0 (इस्तेमाल नहीं किया गया)
- मेटाडेटा 1
- ग्रुप foo_b
- लॉजिकल (डाइनैमिक) पार्टीशन
system_b
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - लॉजिकल (डाइनैमिक) पार्टीशन
product_services_b
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - Foo ने अपडेट किए गए अन्य पार्टीशन
- लॉजिकल (डाइनैमिक) पार्टीशन
- समूह बार_b
- लॉजिकल (डाइनैमिक) पार्टीशन
vendor_b
- लॉजिकल (डाइनैमिक) पार्टीशन
product_b
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है - अन्य पार्टिशन बार से अपडेट किए गए
- लॉजिकल (डाइनैमिक) पार्टीशन
- ग्रुप foo_b
अपने डिवाइस पर मेटाडेटा को डंप करने के लिए,
system/extras/partition_tools
में मौजूद lpdump
टूल का इस्तेमाल किया जा सकता है. उदाहरण के लिए:
lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b
किसी अपडेट को फिर से फ़िट करना
Android 9 और उससे पहले के वर्शन वाले डिवाइसों पर, डिवाइस में मौजूद ओटीए क्लाइंट, अपडेट से पहले डाइनैमिक पार्टीशन को मैप नहीं कर सकता. अगर आप पैच का एक अतिरिक्त सेट बनाया जाता है, ताकि मैपिंग लागू की जा सके और उन्हें कॉपी किया जा सकता है.
ओटीए जनरेटर, super.img
फ़ाइल बनाता है. इसमें सभी डाइनैमिक पार्टिशन का कॉन्टेंट होता है. इसके बाद, इमेज को कई इमेज में बांट दिया जाता है. ये इमेज, सिस्टम, वेंडर वगैरह से जुड़े फ़िज़िकल ब्लॉक डिवाइसों के साइज़ से मेल खाती हैं. इन इमेज को नाम दिया गया है
super_system.img
, super_vendor.img
वगैरह.
ओटीए क्लाइंट, इन इमेज को असल हिस्सों पर लागू करता है,
सिर्फ़ लॉजिकल (डाइनैमिक) पार्टीशन के लिए इमेज लागू करने से ज़्यादा.
OTA क्लाइंट, डाइनैमिक पार्टीशन को मैप करने का तरीका नहीं जानता. इसलिए, अपडेट पैकेज जनरेट होने पर, इन पार्टीशन के लिए इंस्टॉल के बाद के सभी चरण अपने-आप बंद हो जाते हैं. यहां जाएं: इंस्टॉलेशन के बाद कॉन्फ़िगर करना देखें.
अपडेट करने का तरीका, Android 9 जैसा ही है.
अपडेट करने से पहले:
ro.boot.dynamic_partitions= ro.boot.dynamic_partitions_retrofit=
अपडेट करने के बाद:
ro.boot.dynamic_partitions=true ro.boot.dynamic_partitions_retrofit=true
रिफ़ोर्ट के बाद होने वाले अपडेट
रेट्रोफ़िट अपडेट के बाद, ओटीए क्लाइंट के साथ काम करने के लिए अपडेट हो जाता है डाइनैमिक पार्टिशन. सोर्स पार्टीशन की सीमाएं कभी भी खत्म नहीं होती हैं टारगेट किए गए फ़िज़िकल पार्टिशन के लिए.
सामान्य अपडेट पैकेज का इस्तेमाल करके अपडेट फ़्लो
super
पार्टीशन मेटाडेटा को शुरू करना.-
मेटाडेटा S (सोर्स मेटाडेटा) से नया मेटाडेटा M बनाएं.
उदाहरण के लिए, अगर मेटाडेटा S में [
system_s
,vendor_s
,product_s
] को ब्लॉक के तौर पर जोड़ा गया तो नए मेटाडेटा M में [system_t
,vendor_t
,product_t
] को ब्लॉक के तौर पर जोड़ा गया डिवाइस. M में सभी ग्रुप और पार्टीशन हटा दिए जाते हैं. -
इसके अनुसार लक्ष्य समूह और विभाजन जोड़ें
dynamic_partition_metadata
फ़ील्ड को अपडेट किया गया मेनिफ़ेस्ट. हर पार्टिशन का साइज़ यहां देखा जा सकता हैnew_partition_info
. - मेटाडेटा T में M लिखें.
- डिवाइस मैपर पर जोड़े गए पार्टीशन को, लिखने के लिए उपलब्ध के तौर पर मैप करें.
-
मेटाडेटा S (सोर्स मेटाडेटा) से नया मेटाडेटा M बनाएं.
उदाहरण के लिए, अगर मेटाडेटा S में [
- ब्लॉक किए गए डिवाइसों पर अपडेट लागू करें.
- अगर ज़रूरी हो, तो डिवाइस मैपर पर सोर्स पार्टिशन को सिर्फ़ पढ़ने के लिए मैप करें. साइडलोड करने के लिए, यह ज़रूरी है, क्योंकि अपडेट से पहले, सोर्स पार्टीशन मैप नहीं किए जाते.
- इस टैब में दिए गए सभी ब्लॉक डिवाइस पर पूरा या डेल्टा अपडेट लागू करें टारगेट स्लॉट.
- इंस्टॉल के बाद की स्क्रिप्ट चलाने के लिए, पार्टिशन को माउंट करें. इसके बाद, पार्टिशन को अनमाउंट करें.
- टारगेट किए गए पार्टीशन को अनमैप करें.
रिफ़ोर्ट अपडेट पैकेज का इस्तेमाल करके फ़्लो अपडेट करना
अगर रिफ़ोर्ट अपडेट पैकेज को ऐसे डिवाइस पर लागू किया जाता है जिस पर पहले से ही डाइनैमिक पार्टिशन की सुविधा चालू है, तो ओटीए क्लाइंट, ब्लॉक डिवाइसों पर सीधे तौर पर, फ़ाइल को अलग-अलग हिस्सों में बांटने वाली super.img
फ़ाइल लागू करता है. अपडेट
की प्रोसेस, किसी रेट्रोफ़िट अपडेट की तरह होती है. ज़्यादा जानकारी के लिए,
अपडेट को पहले से मौजूद सिस्टम में जोड़ना
लेख पढ़ें.
उदाहरण के लिए, मान लें कि:
- स्लॉट A, चालू स्लॉट है.
-
system_a
में स्लॉट 0 पर सक्रिय मेटाडेटा मौजूद है. -
system_a
,vendor_a
, औरproduct_a
का इस्तेमाल ब्लॉक डिवाइसों के तौर पर किया जाता है.
जब OTA क्लाइंट को रिफ़िट अपडेट पैकेज मिलता है, तो यह फ़िज़िकल system_b
पर super_system.img
, फ़िज़िकल vendor_b
पर super_vendor.img
, और फ़िज़िकल product_b
पर super_product.img
लागू होता है.
फ़िज़िकल ब्लॉक डिवाइस system_b
में सही
मेटाडेटा होता है, ताकि बूट के समय लॉजिकल system_b
,
vendor_b
, और product_b
को मैप किया जा सके.
अपडेट के पैकेज जनरेट करें
इंक्रीमेंटल ओटीए
रीफ़िट डिवाइसों के लिए इंक्रीमेंटल ओटीए जनरेट करते समय, अपडेट इस बात पर निर्भर करते हैं कि बेस बिल्ड में PRODUCT_USE_DYNAMIC_PARTITIONS
और PRODUCT_RETROFIT_DYNAMIC_PARTITIONS
की जानकारी दी गई है या नहीं.
-
अगर बेस बिल्ड वैरिएबल को तय नहीं करता, तो यह
रेट्रोफ़िटिंग अपडेट. अपडेट पैकेज में, अलग-अलग हिस्सों में बांटी गई
super.img
फ़ाइल शामिल होती है. साथ ही, इंस्टॉल के बाद की प्रोसेस को बंद कर दिया जाता है. - अगर बेस बिल्ड में वैरिएबल तय किए गए हैं, तो यह डाइनैमिक पार्टिशन वाले सामान्य अपडेट जैसा ही है. अपडेट पैकेज में, लॉजिकल (डाइनैमिक) पार्टीशन की इमेज होती हैं. इंस्टॉल के बाद की प्रोसेस को चालू किया जा सकता है.
फ़ुल ओटीए
रीट्रॉफ़िट डिवाइसों के लिए, दो फ़ुल ओटीए पैकेज जनरेट किए जाते हैं.
-
$(PRODUCT)-ota-retrofit-$(TAG).zip
में हमेशा स्प्लिटsuper.img
होता है. साथ ही, अपडेट को फिर से इंस्टॉल करने के लिए, इंस्टॉल के बाद का चरण बंद कर दिया जाता है.-
इसे दूसरे तर्क के साथ जनरेट किया गया है
--retrofit_dynamic_partitions
सेota_from_target_files
स्क्रिप्ट. - यह सुविधा सभी बिल्ड पर लागू की जा सकती है.
-
इसे दूसरे तर्क के साथ जनरेट किया गया है
-
$(PRODUCT)-ota-$(TAG).zip
में आने वाले अपडेट के लिए, तर्क के हिसाब से सही इमेज शामिल हैं.- इसे सिर्फ़ उन बिल्ड पर लागू करें जिनमें डाइनैमिक पार्टिशन चालू हों. इसे लागू करने के बारे में जानकारी यहां दी गई है.
पुराने बिल्ड पर नॉनट्रोफ़िट अपडेट को अस्वीकार करें
सामान्य पूरे ओटीए पैकेज को सिर्फ़ बिल्ड में लागू करें डाइनैमिक पार्टिशन चालू हैं. अगर ओटीए सर्वर को गलत तरीके से कॉन्फ़िगर किया गया है और इन पैकेज को Android 9 या उससे पहले के वर्शन पर चल रहे डिवाइसों पर पुश किया जाता है, तो डिवाइस बूट नहीं हो पाते. Android 9 और इससे पहले के वर्शन पर मौजूद OTA क्लाइंट, रिफ़ोट ओटीए पैकेज और सामान्य ओटीए पैकेज के बीच का अंतर नहीं बता सकता. इसलिए, क्लाइंट पूरे पैकेज को अस्वीकार नहीं करेगा.
डिवाइस को फ़ुल ओटीए पैकेज स्वीकार करने से रोकने के लिए, आपके पास ये विकल्प हैं मौजूदा डिवाइस की जांच करने के लिए पोस्ट-इंस्टॉल चरण पूरा करना ज़रूरी है कॉन्फ़िगरेशन. उदाहरण के लिए:
device/device_name/dynamic_partitions/check_dynamic_partitions
#!/system/bin/sh DP_PROPERTY_NAME="ro.boot.dynamic_partitions" DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit" DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME}) DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME}) if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then echo "Error: applied non-retrofit update on build without dynamic" \ "partitions." echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}" echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}" exit 1 fi
device/device_name/dynamic_partitions/Android.mk
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE:= check_dynamic_partitions LOCAL_MODULE_TAGS := optional LOCAL_MODULE_CLASS := EXECUTABLES LOCAL_SRC_FILES := check_dynamic_partitions LOCAL_PRODUCT_MODULE := true include $(BUILD_PREBUILT)
device/device_name/device.mk
PRODUCT_PACKAGES += check_dynamic_partitions # OPTIONAL=false so that the error in check_dynamic_partitions will be # propagated to OTA client. AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_product=true \ POSTINSTALL_PATH_product=bin/check_dynamic_partitions \ FILESYSTEM_TYPE_product=ext4 \ POSTINSTALL_OPTIONAL_product=false \
जब सामान्य ओटीए पैकेज को बिना डाइनैमिक के किसी डिवाइस पर लागू किया जाता है
पार्टिशन चालू हैं, ओटीए क्लाइंट काम करता है
check_dynamic_partitions
को इंस्टॉल करने के बाद
अपडेट को अस्वीकार कर देता है.