ओटीए पैकेज बनाना

build/make/tools/releasetools में दिए गए ota_from_target_files टूल का इस्तेमाल करके, A/B सिस्टम अपडेट या A/B सिस्टम अपडेट के अलावा अन्य अपडेट का इस्तेमाल करने वाले डिवाइसों के लिए, पूरे और इंक्रीमेंटल ओटीए पैकेज बनाए जा सकते हैं. यह टूल, target-files.zip फ़ाइल, जो इनपुट के तौर पर Android बिल्ड सिस्टम से बनी है.

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

Android 8.0 के साथ काम न करने वाले, नॉन-A/B डिवाइसों के लिए काम करने वाले फ़ाइल आधारित ओटीए पैकेज, जिनमें यह ज़रूरी है इसके बजाय, ब्लॉक-आधारित ओटीए पैकेज का इस्तेमाल करें. ब्लॉक के आधार पर ओटीए पैकेज जनरेट करने या Android 7.x या उससे पहले के वर्शन वाले डिवाइसों के लिए, ota_from_target_files पैरामीटर में --block विकल्प पास करें.

पूरे अपडेट बनाना

पूरा अपडेट एक ओटीए पैकेज होता है, जिसमें डिवाइस (सिस्टम, बूट, और रिकवरी पार्टिशन). अगर डिवाइस में क्षमता है मिलने और लागू करने के बाद, पैकेज बिल्ड को इंस्टॉल कर सकता है चाहे डिवाइस की मौजूदा स्थिति कुछ भी हो. उदाहरण के लिए, निम्न कमांड, सभी अपडेट के लिए target-files.zip tardis डिवाइस.

. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output

make dist, $OUT में पूरा OTA पैकेज बनाता है. इससे बनी .zip फ़ाइल में, tardis डिवाइस के लिए OTA पैकेज बनाने के लिए ज़रूरी सभी चीज़ें होती हैं. आप ota_from_target_files को Python बाइनरी के रूप में भी बना सकते हैं और इसे या तो फ़ुल या इंंक्रीमेंटल पैकेज बनाना.

ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip

ota_from_target_files पाथ को $PATH में सेट अप किया गया है और इससे मिला Python बाइनरी, out/ डायरेक्ट्री में मौजूद है.

ota_update.zip अब टेस्ट डिवाइसों पर भेजने के लिए तैयार है. इसमें मौजूद हर चीज़ पर, टेस्ट पासकोड से हस्ताक्षर किया गया है. उपयोगकर्ताओं के डिवाइस के लिए, अपनी निजी कुंजियां जनरेट और इस्तेमाल करें ज़्यादा जानकारी के लिए, रिलीज़ के लिए बिल्ड बनाना में जाएं.

समय-समय पर अपडेट पाएं

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

इंक्रीमेंटल अपडेट पैकेज को सिर्फ़ उन डिवाइसों पर इंस्टॉल किया जा सकता है जिनमें पैकेज बनाने के लिए इस्तेमाल किया गया सोर्स बिल्ड मौजूद हो. समय के हिसाब से अपडेट करने के लिए, आपको पिछले बिल्ड की target_files.zip फ़ाइल चाहिए (वह फ़ाइल जो आपको चाहिए से अपडेट करने के लिए). साथ ही, नए बिल्ड की target_files.zip फ़ाइल को भी अपडेट करें. इसके लिए उदाहरण के लिए, नीचे दिए गए कमांड इंक्रीमेंटल अपडेट बनाने के लिए रिलीज़ टूल का इस्तेमाल करते हैं. tardis डिवाइस के लिए.

ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip

यह बिल्ड पिछले बिल्ड से काफ़ी मिलता-जुलता है. साथ ही, यह इंंक्रीमेंटल अपडेट से काफ़ी मिलता-जुलता है पैकेज (incremental_ota_update.zip), संबंधित पैकेज से बहुत कम है पूरा अपडेट (60 एमबी के बजाय करीब 1 एमबी).

इंक्रीमेंटल पैकेज को सिर्फ़ उन डिवाइसों पर डिस्ट्रिब्यूट करें जो बिलकुल एक जैसे काम करते हों पिछले बिल्ड का इस्तेमाल इंक्रीमेंटल पैकेज के शुरुआती पॉइंट के तौर पर किया जाता है. आपको फ़्लैश करना होगा PREVIOUS-tardis-target_files.zip या PREVIOUS-tardis-img.zip में मौजूद इमेज (दोनों make dist के साथ बनाए गए, fastboot update के साथ फ़्लैश किए जाएंगे), PRODUCT_OUT डायरेक्ट्री में आने वाले सवाल (जिसे make की मदद से बनाया गया है, जो fastboot flashall के साथ फ़्लैश किया गया). इंंक्रीमेंटल पैकेज को इंस्टॉल करने की कोशिश की जा रही है कुछ अन्य बिल्ड नतीजों वाले डिवाइस पर इंस्टॉलेशन में गड़बड़ी होती है. अगर इंस्टॉल नहीं हो पाता है, तो डिवाइस पहले जैसा ही काम करता रहेगा (पुराना सिस्टम चलता रहेगा). पैकेज, उन सभी फ़ाइलों की पिछली स्थिति की पुष्टि करता है जिन्हें अपडेट करने से पहले, वह उन पर काम करता है. इससे डिवाइस, आधा अपग्रेड होने की स्थिति में नहीं रहता.

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

एक से ज़्यादा SKU के लिए OTA पैकेज बनाना

Android 11 या उसके बाद के वर्शन के लिए, एक ओटीए का इस्तेमाल किया जा सकता है अलग-अलग एसकेयू वाले कई डिवाइसों के लिए एक पैकेज तैयार करता है. ऐसा करने के लिए, टारगेट किए गए डिवाइसों को डाइनैमिक फ़िंगरप्रिंट का इस्तेमाल करने के लिए कॉन्फ़िगर करना होगा. साथ ही, ओटीए टूल का इस्तेमाल करके ओटीए मेटाडेटा को अपडेट करना होगा, ताकि डिवाइस के नाम और फ़िंगरप्रिंट को पहले और बाद की स्थिति वाली एंट्री में शामिल किया जा सके.

SKU के बारे में जानकारी

SKU का फ़ॉर्मैट, बिल्ड पैरामीटर की वैल्यू के कॉम्बिनेशन का एक वैरिएशन होता है. आम तौर पर, यह मौजूदा build_fingerprint पैरामीटर का ऐसा सबसेट होता है जिसकी जानकारी नहीं दी जाती. OEM, किसी SKU के लिए सीडीडी से मंज़ूरी पा चुके बिल्ड पैरामीटर के किसी भी कॉम्बिनेशन का इस्तेमाल कर सकते हैं. साथ ही, उन SKU के लिए एक इमेज का भी इस्तेमाल किया जा सकता है. उदाहरण के लिए, इस SKU के कई वैरिएंट हैं:

SKU = <product><device><modifierA><modifierB><modifierC>
  • modifierA, डिवाइस का लेवल है. जैसे, Pro, Premium या Plus
  • modifierB हार्डवेयर वैरिएशन है (जैसे कि रेडियो)
  • modifierC, क्षेत्र है. यह सामान्य (जैसे, NA, EMEA या CHN) या देश या भाषा के हिसाब से हो सकता है (जैसे, JPN, ENG या CHN)

कई OEM, एक से ज़्यादा SKU के लिए एक ही इमेज का इस्तेमाल करते हैं और फिर तैयार प्रॉडक्ट तैयार करते हैं डिवाइस के बूट होने के बाद रनटाइम के समय उसका नाम और डिवाइस फ़िंगरप्रिंट. इस प्रोसेस से, प्लैटफ़ॉर्म डेवलप करने की प्रोसेस आसान हो जाती है. इससे, डिवाइसों पर छोटे बदलाव किए जा सकते हैं. साथ ही, अलग-अलग प्रॉडक्ट के नामों के बावजूद, एक जैसी इमेज (जैसे, tardis और tardispro) शेयर की जा सकती हैं.

डाइनैमिक फ़िंगरप्रिंट इस्तेमाल करना

फ़िंगरप्रिंट, बिल्ड का तय किया गया स्ट्रिंग जोड़ने का तरीका है पैरामीटर, जैसे कि ro.product.brand, ro.product.name, और ro.product.device. किसी डिवाइस का फ़िंगरप्रिंट, सिस्टम के partition फ़िंगरप्रिंट से मिलता है. इसका इस्तेमाल, डिवाइस पर चल रही इमेज (और बाइट) के यूनीक आइडेंटिफ़ायर के तौर पर किया जाता है. डाइनैमिक फ़िंगरप्रिंट बनाने के लिए, डिवाइस के build.prop फ़ाइल में डाइनैमिक लॉजिक का इस्तेमाल करें. इससे, डिवाइस के बूट होने के समय, बूटलोडर वैरिएबल की वैल्यू मिलती है. इसके बाद, उस डेटा का इस्तेमाल करके उस डिवाइस के लिए डाइनैमिक फ़िंगरप्रिंट बनाएं.

उदाहरण के लिए, tardis और tardispro डिवाइसों के लिए डाइनैमिक फ़िंगरप्रिंट का इस्तेमाल करने के लिए, यहां दी गई फ़ाइलों को अपडेट करें.

  • odm/etc/build_std.prop फ़ाइल को अपडेट करें, ताकि उसमें यह लाइन शामिल की जा सके.

    ro.odm.product.device=tardis

  • odm/etc/build_pro.prop फ़ाइल को अपडेट करके, इसमें यह लाइन शामिल करें.

    ro.odm.product.device=tardispro

  • odm/etc/build.prop फ़ाइल को अपडेट करें, ताकि इन लाइनों को शामिल किया जा सके.

    ro.odm.product.device=tardis
import /odm/etc/build_${ro.boot.product.hardware.sku}.prop

ये लाइनें, डिवाइस का नाम, फ़िंगरप्रिंट, और ro.build.fingerprint वैल्यू को डाइनैमिक तौर पर सेट करती हैं. ऐसा, ro.boot.product.hardware.sku bootloader प्रॉपर्टी (जो रीड-ओनली होती है) की वैल्यू के आधार पर किया जाता है.

ओटीए पैकेज का मेटाडेटा अपडेट करना

एक ओटीए पैकेज में एक मेटाडेटा फ़ाइल (META-INF/com/android/metadata) होती है, जो पैकेज के बारे में बताता है. इसमें ओटीए के लिए पहले से तय की गई शर्त और बाद की स्थिति की जानकारी शामिल है पैकेज. उदाहरण के लिए, यह कोड एक ओटीए पैकेज की मेटाडेटा फ़ाइल है tardis डिवाइस को टारगेट कर रहा है.

post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis

pre-device, pre-build-incremental, और pre-build वैल्यू यह ज़रूरी है कि ओटीए पैकेज इंस्टॉल होने से पहले डिवाइस हो. कॉन्टेंट बनाने post-build-incremental और post-build वैल्यू, डिवाइस की स्थिति के बारे में बताती हैं OTA पैकेज के इंस्टॉल होने के बाद होने की उम्मीद की जाती है. pre- और post- फ़ील्ड की वैल्यू, नीचे दी गई मिलती-जुलती बिल्ड प्रॉपर्टी से ली जाती हैं.

  • pre-device की वैल्यू, ro.product.device की बिल्ड प्रॉपर्टी से ली जाती है.
  • pre-build-incremental और post-build-incremental की वैल्यू, ro.build.version.incremental बिल्ड प्रॉपर्टी से ली जाती हैं.
  • pre-build और post-build की वैल्यू, ro.build.fingerprint बिल्ड प्रॉपर्टी से ली जाती हैं.

Android 11 या उसके बाद के वर्शन वाले डिवाइसों पर, जो फ़ाइल का पाथ बताता है उसके लिए OTA टूल में --boot_variable_file फ़्लैग में डिवाइस के रनटाइम वैरिएबल की वैल्यू शामिल होती हैं डाइनैमिक फ़िंगरप्रिंट. इसके बाद, इस डेटा का इस्तेमाल ओटीए मेटाडेटा को अपडेट करने के लिए किया जाता है, ताकि pre- और post- शर्तों में डिवाइस का नाम और फ़िंगरप्रिंट शामिल किया जा सके. इसके लिए, डेलिमिटर के तौर पर पाइप वर्ण | का इस्तेमाल किया जाता है. --boot_variable_file फ़्लैग में सेटअप करें.

  • सिंटैक्स: --boot_variable_file <path>
  • ब्यौरा: उस फ़ाइल का पाथ बताता है जिसमें ro.boot.* प्रॉपर्टी. इंपोर्ट स्टेटमेंट की वजह से, कुछ ro.product.* प्रॉपर्टी बदल जाने पर, संभावित रनटाइम फ़िंगरप्रिंट का हिसाब लगाने के लिए इसका इस्तेमाल किया जाता है. फ़ाइल में हर लाइन में एक प्रॉपर्टी होनी चाहिए. साथ ही, हर लाइन का फ़ॉर्मैट यह होना चाहिए: prop_name=value1,value2.

उदाहरण के लिए, अगर प्रॉपर्टी ro.boot.product.hardware.sku=std,pro है, तो tardis और tardispro डिवाइसों के लिए ओटीए मेटाडेटा यहां दिखाया गया है.

post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro

Android 10 वाले डिवाइसों पर इस सुविधा का इस्तेमाल करने के लिए, इस्तेमाल करने का तरीका देखें. यह बदलाव सूची, build.prop फ़ाइल में मौजूद import स्टेटमेंट को शर्त के हिसाब से पार्स करती है. इससे, प्रॉपर्टी के बदलावों को पहचाना जा सकता है और उन्हें ओटीए के आखिरी मेटाडेटा में दिखाया जा सकता है.