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

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

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

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

सभी अपडेट तैयार करें

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

. 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 एमबी) से काफ़ी छोटा है.

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

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

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

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

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 बूटलोडर प्रॉपर्टी की वैल्यू के आधार पर सेट की जाती हैं. यह प्रॉपर्टी रीड-ओनली होती है.

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

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