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

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

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

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

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

पूरा अपडेट, एक OTA पैकेज होता है. इसमें डिवाइस की फ़ाइनल स्थिति (सिस्टम, बूट, और रिकवरी पार्टीशन) की पूरी जानकारी होती है. जब तक डिवाइस पैकेज को पाने और लागू करने में सक्षम है, तब तक पैकेज, डिवाइस की मौजूदा स्थिति से कोई फ़र्क़ नहीं पड़ता. उदाहरण के लिए, यहां दी गई कमांड, target-files.zip डिवाइस के लिए 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 अब टेस्ट डिवाइसों पर भेजने के लिए तैयार है. इस पर टेस्ट कुंजी से हस्ताक्षर किया गया है. उपयोगकर्ता के डिवाइसों के लिए, अपनी निजी कुंजियां जनरेट करें और उनका इस्तेमाल करें. इसके बारे में ज़्यादा जानकारी के लिए, रिलीज़ के लिए बिल्ड पर साइन करना लेख पढ़ें.

इंक्रीमेंटल अपडेट बनाना

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

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

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

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

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

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

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

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

SKU = <product><device><modifierA><modifierB><modifierC>

• modifierA डिवाइस का लेवल है. जैसे, Pro, Premium या Plus
• modifierB हार्डवेयर का वैरिएंट है. जैसे, रेडियो
• modifierC वह क्षेत्र है जहां यह सुविधा उपलब्ध है. यह सामान्य हो सकता है, जैसे कि NA, EMEA या CHN. इसके अलावा, यह देश या भाषा के हिसाब से भी हो सकता है, जैसे कि JPN, ENG या CHN

कई ओईएम, एक से ज़्यादा एसकेयू के लिए एक ही इमेज का इस्तेमाल करते हैं. इसके बाद, डिवाइस बूट होने के बाद रनटाइम में प्रॉडक्ट का फ़ाइनल नाम और डिवाइस फ़िंगरप्रिंट निकालते हैं. इस प्रोसेस से, प्लैटफ़ॉर्म डेवलपमेंट की प्रोसेस आसान हो जाती है. इससे, मामूली बदलाव वाले डिवाइसों के साथ-साथ अलग-अलग प्रॉडक्ट के नाम वाले डिवाइसों को भी सामान्य इमेज (जैसे, 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.boot.product.hardware.sku बूटलोडर प्रॉपर्टी (जो सिर्फ़ पढ़ने के लिए होती है) की वैल्यू के आधार पर, डिवाइस का नाम, फ़िंगरप्रिंट, और ro.build.fingerprint वैल्यू को डाइनैमिक तरीके से सेट करती हैं.

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

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