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

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

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

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

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