बिना डाइनैमिक पार्टीशन के A/B डिवाइसों के लिए OTA

Android 10 पर काम करता है डाइनैमिक पार्टीशन, यूज़रस्पेस पार्टीशन यह एक ऐसे सिस्टम का इस्तेमाल करता है जो ओवर-द-एयर (ओटीए) अपडेट के दौरान पार्टिशन बना सकता है, उनका साइज़ बदल सकता है, और उन्हें नष्ट कर सकता है.

इस पेज पर बताया गया है कि A/B डिवाइसों को अपडेट करने के दौरान, ओटीए क्लाइंट, डाइनैमिक पार्टिशन का साइज़ कैसे बदलते हैं जो डाइनैमिक पार्टीशन के बिना लॉन्च हुई और ओटीए क्लाइंट को Android 10 पर कैसे अपग्रेड किया गया.

बैकग्राउंड

डाइनैमिक पार्टिशन के साथ काम करने वाले किसी A/B डिवाइस को अपडेट करने के दौरान, डिवाइस पर जीयूआईडी की पार्टिशन टेबल (GPT) पहले से सेव है. इसलिए, इसमें कोई डिवाइस पर super पार्टीशन. मेटाडेटा यहां सेव किया जाता है system_a और system_b, लेकिन BOARD_SUPER_PARTITION_METADATA_DEVICE को बदलकर कस्टमाइज़ किया गया.

ब्लॉक किए गए हर डिवाइस में, दो मेटाडेटा स्लॉट होते हैं. सिर्फ़ एक हर ब्लॉक डिवाइस में मेटाडेटा स्लॉट का इस्तेमाल किया जाता है. उदाहरण के लिए, system_b पर मौजूद system_a और मेटाडेटा 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 (इस्तेमाल नहीं किया गया)
  • फ़िज़िकल ब्लॉक डिवाइस system_b
    • मेटाडेटा 0 (इस्तेमाल नहीं किया गया)
    • मेटाडेटा 1
      • समूह foo_b
        • लॉजिकल (डाइनैमिक) पार्टीशन system_b अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
        • लॉजिकल (डाइनैमिक) पार्टीशन product_services_b अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
        • अन्य पार्टीशन, Foo की मदद से अपडेट किए गए
      • समूह बार_b
        • लॉजिकल (डाइनैमिक) पार्टीशन vendor_b अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
        • लॉजिकल (डाइनैमिक) पार्टीशन product_b अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
        • अन्य पार्टिशन बार से अपडेट किए गए

lpdump टूल का इस्तेमाल मेटाडेटा डालने के लिए system/extras/partition_tools आपका डिवाइस. उदाहरण के लिए: 

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

ओटीए क्लाइंट को डाइनैमिक पार्टीशन को मैप करने का तरीका नहीं पता. इन विभाजनों के लिए सभी पोस्ट-इंस्टॉल चरण अपने आप अक्षम हो जाते हैं जब अपडेट पैकेज जनरेट होता है. यहां जाएं: इंस्टॉलेशन के बाद कॉन्फ़िगर करना देखें.

इसे अपडेट करने का तरीका, Android 9 की तरह ही है.

अपडेट से पहले:

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

अपडेट के बाद: 

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

रेट्रोफ़िट के बाद आने वाले समय के अपडेट

रेट्रोफ़िट अपडेट के बाद, ओटीए क्लाइंट के साथ काम करने के लिए अपडेट हो जाता है डाइनैमिक पार्टिशन. सोर्स पार्टीशन की सीमाएं कभी भी खत्म नहीं होती हैं टारगेट किए गए फ़िज़िकल पार्टिशन के लिए.

किसी नियमित अपडेट पैकेज का इस्तेमाल करके फ़्लो अपडेट करना

  1. super पार्टीशन मेटाडेटा को शुरू करना.
    1. मेटाडेटा S (सोर्स मेटाडेटा) से नया मेटाडेटा M बनाएं. उदाहरण के लिए, अगर मेटाडेटा S में [system_s, vendor_s, product_s] को ब्लॉक के तौर पर जोड़ा गया तो नए मेटाडेटा M में [system_t, vendor_t, product_t] को ब्लॉक के तौर पर जोड़ा गया डिवाइस. M में सभी ग्रुप और सेगमेंट खारिज कर दिए जाते हैं.
    2. इसके अनुसार लक्ष्य समूह और विभाजन जोड़ें dynamic_partition_metadata फ़ील्ड को अपडेट किया गया मेनिफ़ेस्ट. हर पार्टिशन का साइज़ यहां देखा जा सकता है new_partition_info.
    3. मेटाडेटा T पर M लिखें.
    4. डिवाइस मैपर पर जोड़े गए पार्टिशन को लिखने के लिए मैप करें.
  2. ब्लॉक किए गए डिवाइसों पर अपडेट लागू करें.
    1. अगर ज़रूरी हो, तो डिवाइस मैपर पर सोर्स पार्टिशन को मैप करें का इस्तेमाल, सिर्फ़ पढ़ने के लिए किया जाता है. अलग से लोड करने के लिए यह ज़रूरी है, क्योंकि अपडेट से पहले, सोर्स पार्टीशन को मैप नहीं किया जाता.
    2. इस टैब में दिए गए सभी ब्लॉक डिवाइस पर पूरा या डेल्टा अपडेट लागू करें टारगेट स्लॉट.
    3. पोस्ट-इंस्टॉल स्क्रिप्ट चलाने के लिए पार्टिशन माउंट करें और फिर सेगमेंट को अलग करें.
  3. टारगेट किए गए सेगमेंट को अनमैप करें.

रेट्रोफ़िट अपडेट पैकेज का इस्तेमाल करके फ़्लो अपडेट करें

अगर रेट्रोफ़िट अपडेट पैकेज को पहले से ही किसी ऐसे डिवाइस पर लागू किया गया है डाइनैमिक पार्टिशन चालू करता है, ओटीए क्लाइंट स्प्लिट लागू करता है super.img फ़ाइल सीधे ब्लॉक डिवाइसों पर सेव की जा सकती है. अपडेट की प्रोसेस, किसी रेट्रोफ़िट अपडेट की तरह होती है. यहां जाएं: अपडेट को फिर से फ़िट करना देखें.

उदाहरण के लिए, मान लें कि:

  • स्लॉट A चालू स्लॉट है.
  • system_a में स्लॉट 0 पर सक्रिय मेटाडेटा मौजूद है.
  • system_a, vendor_a, और product_a का इस्तेमाल ब्लॉक डिवाइसों के तौर पर किया जाता है.

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

पुराने बिल्ड पर नॉनट्रोफ़िट अपडेट को अस्वीकार करें

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

डिवाइस को फ़ुल ओटीए पैकेज स्वीकार करने से रोकने के लिए, आपके पास ये विकल्प हैं मौजूदा डिवाइस की जांच करने के लिए पोस्ट-इंस्टॉल चरण पूरा करना ज़रूरी है कॉन्फ़िगरेशन. उदाहरण के लिए:

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 को इंस्टॉल करने के बाद अपडेट को अस्वीकार कर देता है.