ऐसे OEM और SoC वेंडर जो A/B सिस्टम अपडेट लागू करना चाहते हैं, उन्हें अपने बूटलोडर को पक्का करना होगा बूट_कंट्रोल HAL लागू करता है और सही पैरामीटर को कर्नेल.
बूट कंट्रोल एचएएल लागू करें
A/B-क्षमता वाले बूटलोडर को boot_control
एचएएल को
hardware/libhardware/include/hardware/boot_control.h
. लागू करने की प्रोसेस की जांच करने के लिए,
system/extras/bootctl
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
उपयोगिता और
system/extras/tests/bootloader/
.
आपको नीचे दिखाई गई स्टेट मशीन भी लागू करनी होगी:
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया हैकर्नेल को सेट अप करें
A/B सिस्टम अपडेट लागू करने के लिए:
-
इन कर्नेल पैच सीरीज़ को चेरी चुनें (अगर ज़रूरी हो):
- अगर रैम डिस्क के बिना डिवाइस को चालू किया जा रहा है और "रिकवरी के तौर पर बूट करें" का इस्तेमाल किया जा रहा है, तो चेरीपिक android-review.googlesource.com/#/c/158491/ पर टैप करें.
- रैम डिस्क के बिना डीएम-वेरिटी सेट अप करने के लिए, चेरीपिक android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Change_3.18.
-
पक्का करें कि कर्नेल कमांड लाइन आर्ग्युमेंट में ये अतिरिक्त आर्ग्युमेंट शामिल हों:
skip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
<public-key-id>
वैल्यू, सार्वजनिक पासकोड का आईडी है वेरिटी टेबल सिग्नेचर की पुष्टि करें (जानकारी के लिए, dm-verity). -
सिस्टम कीरिंग में सार्वजनिक कुंजी वाला .X509 प्रमाणपत्र जोड़ें:
-
.der
फ़ॉर्मैट में फ़ॉर्मैट किए गए .X509 सर्टिफ़िकेट को, यूआरएल के रूट में कॉपी करेंkernel
डायरेक्ट्री. अगर .X509 सर्टिफ़िकेट.pem
फ़ाइल को कन्वर्ट करने के लिए, नीचे दिए गएopenssl
निर्देश का इस्तेमाल करें.pem
से.der
के फ़ॉर्मैट में:खोलने के लिए x509 -इन <x509-pem-certificate> -आउटफ़ॉर्म डेर -आउट <x509-der-certificate>
-
सिस्टम कीरिंग के हिस्से के तौर पर, सर्टिफ़िकेट को शामिल करने के लिए
zImage
बनाएं. पुष्टि करने के लिए,procfs
एंट्री की जांच करें (ज़रूरी है चालू करने के लिएKEYS_CONFIG_DEBUG_PROC_KEYS
):एंगलर:/# बिल्ली /proc/keys 1c8a217e I------ 1 पर्म 1f010000 0 0 एसिमेट्री Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] 2d454e3e I------ 1 अनुमति 1f030000 0 0 कीरिंग .system_keyring: 1/4
.X509 प्रमाणपत्र को सफलतापूर्वक शामिल करने से सार्वजनिक कुंजी की मौजूदगी का पता चलता है (हाइलाइट, सार्वजनिक पासकोड के आईडी को दिखाता है). -
स्पेस को
#
से बदलें और इसे इस तरह पास करें:<public-key-id>
कर्नेल कमांड लाइन में. उदाहरण के लिए, पास इसकी जगहAndroid:#7e4333f9bba00adfe0ede979e28ed1920492b40f
ली गई<public-key-id>
.
-
बिल्ड वैरिएबल सेट करना
A/B-क्षमता वाले बूटलोडर को बिल्ड वैरिएबल से जुड़ी इन शर्तों को पूरा करना होगा:
A/B टारगेट के लिए तय होना चाहिए |
/device/google/marlin/+/android-7.1.0_r1/device-common.mk . इसके अलावा, आपके पास पोस्ट-इंस्टॉल (फिर से चालू करने से पहले) डेक्स2oट का तरीका भी इस्तेमाल करने का विकल्प है. इस चरण के बारे में इसमें बताया गया है
कंपाइल करना.
|
---|---|
A/B टारगेट के लिए खास तौर पर सुझाया गया |
|
A/B टारगेट के लिए तय नहीं किया जा सकता |
|
डीबग बिल्ड के लिए ज़रूरी नहीं है | PRODUCT_PACKAGES_DEBUG += update_engine_client |
पार्टिशन सेट करें (स्लॉट)
A/B डिवाइसों को रिकवरी पार्टिशन या कैश पार्टीशन की ज़रूरत नहीं है, क्योंकि Android अब
नहीं कर सकते. डेटा के बंटवारे का इस्तेमाल, अब डाउनलोड किए गए ओटीए पैकेज के लिए किया जाता है और
रिकवरी इमेज कोड, बूट पार्टीशन पर है. A/B-ed वाले सभी विभाजनों को नाम दिया जाना चाहिए
नीचे दिया गया है (स्लॉट के नाम हमेशा a
, b
वगैरह होते हैं): boot_a
,
boot_b
, system_a
, system_b
, vendor_a
,
vendor_b
.
कैश
नॉन-A/B अपडेट के लिए, कैश मेमोरी के हिस्से का इस्तेमाल, डाउनलोड किए गए OTA पैकेज को स्टोर करने और अपडेट लागू करते समय अस्थायी रूप से स्टैश ब्लॉक. कैश मेमोरी को साइज़ देने का कोई अच्छा तरीका नहीं था विभाजन: आपको किस तरह के अपडेट लागू करने हैं, यह इस बात पर निर्भर करता है कि इसका कितना बड़ा होना ज़रूरी है. सबसे खराब केस एक कैश मेमोरी वाला हिस्सा होगा, जो सिस्टम की इमेज जितना बड़ा होगा. A/B अपडेट का इस्तेमाल करने की ज़रूरत नहीं है ब्लॉक को छिपाने के लिए (क्योंकि आप हमेशा ऐसे विभाजन में लिखते हैं जिसका वर्तमान में उपयोग नहीं किया जा रहा है) और A/B स्ट्रीम करने पर, पूरे ओटीए पैकेज को लागू करने से पहले डाउनलोड करने की ज़रूरत नहीं है.
रिकवरी
रिकवरी रैम डिस्क अब boot.img
फ़ाइल में है. इस पेज पर जाकर,
खाता वापस पाने के लिए, बूटलोडर skip_initramfs
विकल्प को चालू नहीं कर सकता
कर्नेल कमांड लाइन.
गैर-A/B अपडेट के लिए, रिकवरी पार्टिशन में अपडेट लागू करने के लिए इस्तेमाल किया गया कोड शामिल होता है. ए/बी
ये अपडेट, सामान्य रूप से चालू की गई सिस्टम इमेज में चल रहे update_engine
के ज़रिए लागू किए जाते हैं.
फ़ैक्ट्री डेटा रीसेट करने और अपडेट को अलग से लोड करने के लिए, अब भी रिकवरी मोड का इस्तेमाल किया जा रहा है
पैकेज (जहां से "रिकवरी" नाम आया है). रिकवरी मोड का कोड और डेटा
सामान्य बूट पार्टिशन में रैम डिस्क में सेव किया जाता है; सिस्टम इमेज में बूट करने के लिए,
बूटलोडर, कर्नेल को रैम डिस्क छोड़ने का निर्देश देता है (वरना डिवाइस रिकवरी के लिए चालू हो जाएगा)
मोड. रिकवरी मोड छोटा है (और इसका ज़्यादातर हिस्सा पहले से ही बूट पार्टीशन पर था), इसलिए बूट
विभाजन से आकार नहीं बढ़ता.
एफ़एसटैब
slotselect
आर्ग्युमेंट, A/B-ed की लाइन पर होना चाहिए
विभाजन. उदाहरण के लिए:
<path-to-block-device>/वेंडर /वेंडर ext4 ro इंतज़ार करें,verify=<path-to-block-device>/metadata,slotselect
किसी भी सेगमेंट का नाम vendor
नहीं होना चाहिए. इसके बजाय, vendor_a
या
vendor_b
को चुना जाएगा और /vendor
माउंट पॉइंट पर माउंट किया जाएगा.
कर्नेल स्लॉट के आर्ग्युमेंट
मौजूदा स्लॉट सफ़िक्स को किसी खास डिवाइस ट्री (DT) नोड से पास किया जाना चाहिए
(/firmware/android/slot_suffix
) या
androidboot.slot_suffix
कर्नेल कमांड लाइन या बूट कॉन्फ़िगरेशन आर्ग्युमेंट.
डिफ़ॉल्ट रूप से, A/B डिवाइस पर फ़ास्टबूट मौजूदा स्लॉट को फ़्लैश करता है. अगर अपडेट पैकेज भी इसमें अन्य, नॉन-मौजूदा स्लॉट के लिए इमेज शामिल होती हैं, फ़ास्टबूट उन इमेज को भी फ़्लैश करता है. ये विकल्प उपलब्ध हैं:
-
--slot SLOT
. डिफ़ॉल्ट ऐक्शन को बदलें और इस तरह से पास किए जाने वाले स्लॉट को फ़्लैश करने के लिए फ़ास्टबूट का निर्देश दें एक तर्क दिया गया है. -
--set-active [SLOT]
. स्लॉट को 'चालू है' के तौर पर सेट करें. अगर कोई वैकल्पिक आर्ग्युमेंट नहीं है तय करने का मतलब है कि मौजूदा स्लॉट को 'चालू है' के तौर पर सेट कर दिया जाता है. fastboot --help
. निर्देशों के बारे में ज़्यादा जानकारी पाएं.
अगर बूटलोडर, फ़ास्टबूट को लागू करता है, तो इसे
set_active <slot>
, जो मौजूदा चालू स्लॉट को दिए गए स्लॉट में सेट करता है (यह
उस स्लॉट के लिए बूट नहीं किए जा सकने वाले फ़्लैग को भी हटाना होगा और फिर से कोशिश करने की संख्या को डिफ़ॉल्ट पर रीसेट करना होगा
वैल्यू). बूटलोडर में नीचे दिए गए वैरिएबल भी काम करने चाहिए:
-
has-slot:<partition-base-name-without-suffix>
. अगर दिया गया विकल्प चुना गया है, तो “हां” दिखता है विभाजन, स्लॉट का समर्थन करता है, अन्यथा “नहीं”. current-slot
. उस स्लॉट प्रत्यय को लौटाता है जिसे अगली बार से बूट किया जाएगा.-
slot-count
. उपलब्ध स्लॉट की संख्या दिखाने वाला पूर्णांक लौटाता है. फ़िलहाल, दो स्लॉट का इस्तेमाल किया जा सकता है. इसलिए, यह वैल्यू2
है. -
slot-successful:<slot-suffix>
. नतीजे के तौर पर "हां" दिखता है अगर दिया गया स्लॉट सफलतापूर्वक बूट होने वाला के रूप में मार्क किया गया, "नहीं" नहीं तो. -
slot-unbootable:<slot-suffix>
. अगर दिए गए स्लॉट को मार्क किया गया है, तो “हां” लौटाता है "नहीं" नहीं तो. -
slot-retry-count:<slot-suffix>
. इतनी बार और कोशिश की जा सकती है दिए गए स्लॉट को चालू करें.
सभी वैरिएबल देखने के लिए, चलाएं
fastboot getvar all
.
ओटीए पैकेज जनरेट करें
OTA पैकेज टूल वे ही निर्देश अपनाते हैं जो
ग़ैर-A/B डिवाइसों के लिए निर्देश. target_files.zip
फ़ाइल इनके ज़रिए जनरेट होनी चाहिए
A/B टारगेट के लिए बिल्ड वैरिएबल तय करें. OTA पैकेज टूल अपने-आप,
और A/B अपडेटर के फ़ॉर्मैट में पैकेज जनरेट करें.
उदाहरण:
-
पूरा ओटीए जनरेट करने के लिए:
./build/make/tools/releasetools/ota_from_target_files \ det_Output/tardis-target_files.zip \ ota_update.zip
-
इंक्रीमेंटल ओटीए जनरेट करने के लिए:
./build/make/tools/releasetools/ota_from_target_files \ -i PREVIOUS-tardis-target_files.zip \ det_Output/tardis-target_files.zip \ वृद्धिशील_ota_update.zip
सेगमेंट कॉन्फ़िगर करें
update_engine
एक ही डिस्क में तय किए गए A/B पार्टीशन के किसी भी जोड़े को अपडेट कर सकता है.
विभाजनों के जोड़े में एक सामान्य उपसर्ग है (जैसे कि system
या boot
)
और हर स्लॉट के हिसाब से सफ़िक्स (जैसे कि _a
). उन हिस्सों की सूची जिनके लिए पेलोड
जनरेटर से तय होता है कि अपडेट को AB_OTA_PARTITIONS
मेक वैरिएबल की मदद से कॉन्फ़िगर किया गया है.
उदाहरण के लिए, अगर विभाजनों का जोड़ा bootloader_a
और
booloader_b
शामिल हैं (_a
और _b
स्लॉट हैं
प्रत्यय), तो आप उत्पाद या बोर्ड पर निम्न को निर्दिष्ट करके इन विभाजनों को अपडेट कर सकते हैं
कॉन्फ़िगरेशन:
AB_OTA_PARTITIONS := \ चालू करें \ सिस्टम \ बूटलोडर
update_engine
के ज़रिए अपडेट किए गए सभी सेगमेंट में,
सिस्टम. इंक्रीमेंटल या delta अपडेट के दौरान, मौजूदा स्लॉट का बाइनरी डेटा
का इस्तेमाल नए स्लॉट में डेटा जनरेट करने के लिए किया जाता है. किसी भी बदलाव की वजह से नया स्लॉट डेटा
अपडेट प्रक्रिया के दौरान पुष्टि न हो पाने की वजह से अपडेट न हो पाना.
पोस्टइंस्टॉलेशन कॉन्फ़िगर करें
आप
की-वैल्यू पेयर. /system/usr/bin/postinst
पर मौजूद कार्यक्रम को
इमेज के लिए, सिस्टम पार्टीशन में फ़ाइल सिस्टम के रूट के मुताबिक पाथ तय करें.
उदाहरण के लिए, usr/bin/postinst
का मान system/usr/bin/postinst
है (अगर नहीं है
रैम डिस्क इस्तेमाल करके). इसके अलावा, फ़ाइल सिस्टम का वह टाइप तय करें जिसे
mount(2)
सिस्टम कॉल. प्रॉडक्ट या डिवाइस में यह जोड़ें
.mk
फ़ाइलें (अगर लागू हो):
AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=सही \ POSTINSTALL_PATH_system=usr/bin/postinst \ FILEसिस्टम_TYPE_system=ext4
ऐप्लिकेशन कंपाइल करें
सिस्टम की नई इमेज का इस्तेमाल करके, फिर से चालू होने से पहले ऐप्लिकेशन को बैकग्राउंड में कंपाइल किया जा सकता है. कंपाइल करने के लिए बैकग्राउंड में मौजूद ऐप्लिकेशन का इस्तेमाल करने के लिए, उत्पाद के डिवाइस कॉन्फ़िगरेशन में नीचे दिया गया तरीका जोड़ें ( प्रॉडक्ट का device.mk):
-
बिल्ड में नेटिव कॉम्पोनेंट शामिल करें, ताकि यह पक्का किया जा सके कि कंपाइलेशन स्क्रिप्ट और बाइनरी
कंपाइल करके सिस्टम इमेज में शामिल किया जाता है.
# A/B OTA डेक्सऑप्ट पैकेज PRODUCT_PACKAGES += otapreopt_script
-
कंपाइलेशन स्क्रिप्ट को
update_engine
से इस तरह कनेक्ट करें कि यह इंस्टॉल करने के बाद वाला चरण.# A/B OTA dexopt updated_engine हुकअप AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=सही \ POSTINSTALL_PATH_system=system/bin/otapreopt_script \ FILEसिस्टम_TYPE_system=ext4 \ POSTINSTALL_OPTIONAL_system=सही
इस्तेमाल नहीं किए गए दूसरे सिस्टम पार्टीशन में पहले से चुनी गई फ़ाइलों को इंस्टॉल करने में मदद के लिए, यह देखें DEX_PREOPT फ़ाइलों को पहली बार चालू करके इंस्टॉल किया गया.