A/B अपडेट लागू करें

ऐसे 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 सिस्टम अपडेट लागू करने के लिए:

1. इन कर्नेल पैच सीरीज़ को चेरी चुनें (अगर ज़रूरी हो):
   • अगर रैम डिस्क के बिना डिवाइस को चालू किया जा रहा है और "रिकवरी के तौर पर बूट करें" का इस्तेमाल किया जा रहा है, तो चेरीपिक 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.
2. पक्का करें कि कर्नेल कमांड लाइन आर्ग्युमेंट में ये अतिरिक्त आर्ग्युमेंट शामिल हों:

   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).
3. सिस्टम कीरिंग में सार्वजनिक कुंजी वाला .X509 प्रमाणपत्र जोड़ें:
   1. .der फ़ॉर्मैट में फ़ॉर्मैट किए गए .X509 सर्टिफ़िकेट को, यूआरएल के रूट में कॉपी करें kernel डायरेक्ट्री. अगर .X509 सर्टिफ़िकेट .pem फ़ाइल को कन्वर्ट करने के लिए, नीचे दिए गए openssl निर्देश का इस्तेमाल करें .pem से .der के फ़ॉर्मैट में:

      openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>

   2. सिस्टम कीरिंग के हिस्से के तौर पर, सर्टिफ़िकेट को शामिल करने के लिए zImage बनाएं. पुष्टि करने के लिए,procfs एंट्री की जांच करें (ज़रूरी है चालू करने के लिए KEYS_CONFIG_DEBUG_PROC_KEYS):

      angler:/# cat /proc/keys
      
      1c8a217e I------     1 perm 1f010000     0     0 asymmetri
      Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f []
      2d454e3e I------     1 perm 1f030000     0     0 keyring
      .system_keyring: 1/4

      .X509 प्रमाणपत्र को सफलतापूर्वक शामिल करने से सार्वजनिक कुंजी की मौजूदगी का पता चलता है (हाइलाइट, सार्वजनिक पासकोड के आईडी को दिखाता है).
   3. स्पेस को # से बदलें और इसे इस तरह पास करें: <public-key-id> कर्नेल कमांड लाइन में. उदाहरण के लिए, पास इसकी जगह Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f ली गई <public-key-id>.

बिल्ड वैरिएबल सेट करना

A/B-क्षमता वाले बूटलोडर को बिल्ड वैरिएबल से जुड़ी इन शर्तों को पूरा करना होगा:

पार्टिशन सेट करें (स्लॉट)

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>/vendor  /vendor  ext4  ro
wait,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 \
      dist_output/tardis-target_files.zip \
      ota_update.zip
  

• इंक्रीमेंटल ओटीए जनरेट करने के लिए:

  ./build/make/tools/releasetools/ota_from_target_files \
      -i PREVIOUS-tardis-target_files.zip \
      dist_output/tardis-target_files.zip \
      incremental_ota_update.zip
  

सेगमेंट कॉन्फ़िगर करें

update_engine एक ही डिस्क में तय किए गए A/B पार्टीशन के किसी भी जोड़े को अपडेट कर सकता है. विभाजनों के जोड़े में एक सामान्य उपसर्ग है (जैसे कि system या boot) और हर स्लॉट के हिसाब से सफ़िक्स (जैसे कि _a). उन हिस्सों की सूची जिनके लिए पेलोड जनरेटर से तय होता है कि अपडेट को AB_OTA_PARTITIONS मेक वैरिएबल की मदद से कॉन्फ़िगर किया गया है.

उदाहरण के लिए, अगर विभाजनों का जोड़ा bootloader_a और booloader_b शामिल हैं (_a और _b स्लॉट हैं प्रत्यय), तो आप उत्पाद या बोर्ड पर निम्न को निर्दिष्ट करके इन विभाजनों को अपडेट कर सकते हैं कॉन्फ़िगरेशन:

AB_OTA_PARTITIONS := \
  boot \
  system \
  bootloader

update_engine के ज़रिए अपडेट किए गए सभी सेगमेंट में, सिस्टम. इंक्रीमेंटल या delta अपडेट के दौरान, मौजूदा स्लॉट का बाइनरी डेटा का इस्तेमाल नए स्लॉट में डेटा जनरेट करने के लिए किया जाता है. किसी भी बदलाव की वजह से नया स्लॉट डेटा अपडेट प्रक्रिया के दौरान पुष्टि न हो पाने की वजह से अपडेट न हो पाना.

पोस्टइंस्टॉलेशन कॉन्फ़िगर करें

आप की-वैल्यू पेयर. /system/usr/bin/postinst पर मौजूद कार्यक्रम को इमेज के लिए, सिस्टम पार्टीशन में फ़ाइल सिस्टम के रूट के मुताबिक पाथ तय करें.

उदाहरण के लिए, usr/bin/postinst का मान system/usr/bin/postinst है (अगर नहीं है रैम डिस्क इस्तेमाल करके). इसके अलावा, फ़ाइल सिस्टम का वह टाइप तय करें जिसे mount(2) सिस्टम कॉल. प्रॉडक्ट या डिवाइस में यह जोड़ें .mk फ़ाइलें (अगर लागू हो):

AB_OTA_POSTINSTALL_CONFIG += \
  RUN_POSTINSTALL_system=true \
  POSTINSTALL_PATH_system=usr/bin/postinst \
  FILESYSTEM_TYPE_system=ext4

ऐप्लिकेशन कंपाइल करें

सिस्टम की नई इमेज का इस्तेमाल करके, फिर से चालू होने से पहले ऐप्लिकेशन को बैकग्राउंड में कंपाइल किया जा सकता है. कंपाइल करने के लिए बैकग्राउंड में मौजूद ऐप्लिकेशन का इस्तेमाल करने के लिए, उत्पाद के डिवाइस कॉन्फ़िगरेशन में नीचे दिया गया तरीका जोड़ें ( प्रॉडक्ट का device.mk):

1. बिल्ड में नेटिव कॉम्पोनेंट शामिल करें, ताकि यह पक्का किया जा सके कि कंपाइलेशन स्क्रिप्ट और बाइनरी कंपाइल करके सिस्टम इमेज में शामिल किया जाता है.

     # A/B OTA dexopt package
     PRODUCT_PACKAGES += otapreopt_script
   

2. कंपाइलेशन स्क्रिप्ट को update_engine से इस तरह कनेक्ट करें कि यह इंस्टॉल करने के बाद वाला चरण.

     # A/B OTA dexopt update_engine hookup
     AB_OTA_POSTINSTALL_CONFIG += \
       RUN_POSTINSTALL_system=true \
       POSTINSTALL_PATH_system=system/bin/otapreopt_script \
       FILESYSTEM_TYPE_system=ext4 \
       POSTINSTALL_OPTIONAL_system=true
   

इस्तेमाल नहीं किए गए दूसरे सिस्टम पार्टीशन में पहले से चुनी गई फ़ाइलों को इंस्टॉल करने में मदद के लिए, यह देखें DEX_PREOPT फ़ाइलों को पहली बार चालू करके इंस्टॉल किया गया.