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

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

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

गैर-A/B डिवाइसों के लिए, Android 8.0 के फ़ाइल आधारित ओटीए पैकेज काम नहीं करते. इनके लिए, ब्लॉक-आधारित ओटीए पैकेज का इस्तेमाल करना ज़रूरी है. 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 में पूरा ओटीए पैकेज बनाता है. .zip फ़ाइल में वे सभी चीज़ें मौजूद होती हैं जो tardis डिवाइस के लिए ओटीए पैकेज बनाने के लिए ज़रूरी हैं. 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 के साथ फ़्लैश किया जाएगा) में इमेज फ़्लैश करनी चाहिए. किसी दूसरे बिल्ड के नतीजों वाले डिवाइस पर इंंक्रीमेंटल पैकेज को इंस्टॉल करने की कोशिश करने पर, इंस्टॉल करने में गड़बड़ी हुई. इंस्टॉल विफल होने पर, डिवाइस उसी काम करने की स्थिति में रहता है (पुराने सिस्टम पर चल रहा); पैकेज उन सभी फ़ाइलों को स्पर्श करने से पहले अपडेट की जाने वाली सभी फ़ाइलों की पिछली स्थिति की पुष्टि करता है, ताकि डिवाइस आधी अपग्रेड स्थिति में न फंसे.

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

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

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