सामान्य बूट पार्टीशन

Android 12 में, सामान्य boot इमेज को सामान्य कर्नेल इमेज (जीकेआई) कहा जाता है. इसमें सामान्य रैमडिस्क और जीकेआई कर्नेल शामिल होता है.

Android 13 के साथ लॉन्च होने वाले डिवाइसों के लिए, सामान्य ramdisk को boot इमेज से हटा दिया जाता है और इसे अलग init_boot इमेज में रख दिया जाता है. इस बदलाव के बाद, boot इमेज में सिर्फ़ GKI कर्नल रह जाएगा.

Android 12 या कर्नल के पुराने वर्शन का इस्तेमाल करने वाले डिवाइसों को अपग्रेड करने के लिए, सामान्य रैमडिस्क वहीं रहता है जहां वह था. इसके लिए, नई init_boot इमेज की ज़रूरत नहीं होती.

जेनेरिक रैमडिस्क बनाने के लिए, वेंडर के हिसाब से तय किए गए संसाधनों को रैमडिस्क से बाहर ले जाएं. ऐसा करने पर, जेनेरिक रैमडिस्क में सिर्फ़ पहले चरण का init और एक प्रॉपर्टी फ़ाइल होगी. इस फ़ाइल में टाइमस्टैंप की जानकारी होती है.

ऐसे डिवाइसों पर जो:

  • recovery पार्टीशन का इस्तेमाल न करें. रिकवरी के सभी बिट, सामान्य रैमडिस्क से vendor_boot रैमडिस्क में ट्रांसफ़र हो जाते हैं.

  • recovery पार्टीशन का इस्तेमाल करें. recovery ramdisk में कोई बदलाव करने की ज़रूरत नहीं है, क्योंकि recovery ramdisk में सब कुछ शामिल होता है.

भवन निर्माण

यहां दिए गए डायग्राम में, Android 12 और इसके बाद के वर्शन वाले डिवाइसों के आर्किटेक्चर के बारे में बताया गया है. Android 13 के साथ लॉन्च होने वाले डिवाइस में, नई init_boot इमेज होती है. इसमें सामान्य रैमडिस्क होता है. Android 12 से Android 13 पर अपग्रेड किए गए डिवाइस, Android 12 के आर्किटेक्चर का ही इस्तेमाल करते हैं.

Android 13 के साथ लॉन्च किया गया, रिकवरी के लिए कोई अलग से सिस्टम नहीं है

डिवाइस लॉन्च/अपग्रेड करना, GKI, कोई खास रिकवरी नहीं

पहली इमेज. ऐसे डिवाइस जो GKI के साथ Android 13 पर लॉन्च हो रहे हैं या अपग्रेड हो रहे हैं. इनमें रिकवरी के लिए कोई अलग से सुविधा नहीं है.

Android 13 के साथ लॉन्च किया गया, डेडिकेटेड और A/B रिकवरी (डेडिकेटेड रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI, डेडिकेटेड और A/B रिकवरी

दूसरी इमेज. ऐसे डिवाइस जो Android 13 पर लॉन्च किए जा रहे हैं या अपग्रेड किए जा रहे हैं. इनमें जीकेआई, डेडिकेटेड, और ए/बी रिकवरी की सुविधा उपलब्ध है.

अगर डिवाइस में recovery_a और recovery_b पार्टिशन हैं, तो इस इमेज को देखें.

Android 13 के साथ लॉन्च किया गया, डेडिकेटेड और नॉन-ए/बी रिकवरी (डेडिकेटेड रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI, डेडिकेटेड और नॉन-ए/बी रिकवरी

तीसरी इमेज. ऐसे डिवाइस जो Android 13 पर अपग्रेड हो रहे हैं या लॉन्च हो रहे हैं और जिनमें GKI, डेडिकेटेड, और नॉन-A/B रिकवरी की सुविधा है.

अगर डिवाइस में recovery नाम का कोई ऐसा पार्टिशन है जिसमें स्लॉट सफ़िक्स नहीं है, तो इस इमेज को देखें.

Android 12 के साथ लॉन्च किया गया या Android 12 में अपग्रेड किया गया, रिकवरी के लिए कोई अलग से सुविधा नहीं है

डिवाइस लॉन्च/अपग्रेड करना, GKI, कोई खास रिकवरी नहीं

चौथी इमेज. GKI के साथ Android 12 पर लॉन्च या अपग्रेड किए जा रहे डिवाइसों के लिए, कोई खास रिकवरी मोड नहीं है.

Android 12 पर लॉन्च या अपग्रेड करें, डेडिकेटेड और A/B रिकवरी (डेडिकेटेड रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI, डेडिकेटेड और A/B रिकवरी

पांचवीं इमेज. GKI, डेडिकेटेड, और A/B रिकवरी के साथ Android 12 पर लॉन्च या अपग्रेड किए जा रहे डिवाइस.

अगर डिवाइस में recovery_a और recovery_b पार्टिशन हैं, तो इस इमेज को देखें.

Android 12 को लॉन्च या अपग्रेड करें, डेडिकेटेड और नॉन-ए/बी रिकवरी (डेडिकेटेड रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI, डेडिकेटेड और नॉन-ए/बी रिकवरी

छठी इमेज. Android 12 पर अपग्रेड किए जा रहे या लॉन्च किए जा रहे ऐसे डिवाइस जिनमें GKI, डेडिकेटेड, और नॉन-A/B रिकवरी की सुविधा है.

अगर डिवाइस में recovery नाम का कोई ऐसा पार्टिशन है जिसमें स्लॉट सफ़िक्स नहीं है, तो इस इमेज को देखें.

Android 12 पर अपग्रेड करें, रिकवरी-ऐज़-बूट (रिकवरी-ऐज़-रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI नहीं है, रिकवरी-ऐज़-बूट

सातवीं इमेज. Android 12 पर अपग्रेड किए गए डिवाइसों के लिए, जीकेआई नहीं है और रिकवरी-ऐज़-बूट की सुविधा है.

Android 12 पर अपग्रेड करें, डेडिकेटेड रिकवरी (डेडिकेटेड रैमडिस्क)

डिवाइस लॉन्च/अपग्रेड करना, GKI नहीं, रिकवरी के लिए अलग से पार्टीशन

आठवीं इमेज. Android 12 पर अपग्रेड किए जा रहे डिवाइसों के लिए, जीकेआई नहीं है और रिकवरी के लिए अलग से पार्टीशन है.

बूट इमेज का कॉन्टेंट

Android बूट इमेज में यह कॉन्टेंट शामिल होता है.

  • Android 13 के साथ लॉन्च होने वाले डिवाइसों के लिए init_boot इमेज जोड़ी गई

    • हेडर वर्शन V4
    • जेनरिक रैमडिस्क इमेज

  • जेनरिक boot इमेज

    • हेडर वर्शन V3 या V4
      • GKI boot.img सर्टिफ़िकेशन के लिए boot_signature (सिर्फ़ v4). सर्टिफ़ाइड GKI boot.img पर, वेरिफ़ाइड बूट के लिए हस्ताक्षर नहीं किया गया है. OEM को अब भी, डिवाइस के हिसाब से AVB कुंजी का इस्तेमाल करके, पहले से बनाए गए boot.img पर हस्ताक्षर करने होंगे.
      • सामान्य cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI कर्नेल
    • सामान्य रैमडिस्क इमेज
      • सिर्फ़ Android 12 और इससे पहले के वर्शन पर boot इमेज में शामिल है

  • vendor_boot इमेज (ज़्यादा जानकारी के लिए, वेंडर बूट पार्टीशन देखें)

    • vendor_boot header
      • डिवाइस के हिसाब से cmdline (BOARD_KERNEL_CMDLINE)
    • vendor_boot ramdisk image
      • lib/modules
      • खाता वापस पाने के संसाधन (अगर खाता वापस पाने के लिए कोई खास सुविधा उपलब्ध नहीं है)
    • dtb इमेज

  • recovery इमेज

    • हेडर वर्शन V2
      • अगर ज़रूरी हो, तो डिवाइस के हिसाब से cmdline को वापस पाने की सुविधा
      • नॉन-A/B रिकवरी पार्टिशन के लिए, हेडर का कॉन्टेंट स्टैंडअलोन होना चाहिए. रिकवरी इमेज देखें. उदाहरण के लिए:
      • cmdline को boot और vendor_boot cmdline के साथ नहीं जोड़ा गया है.
      • अगर ज़रूरी हो, तो हेडर में रिकवरी डीटीबीओ की जानकारी दी जाती है.
      • A/B रिकवरी पार्टिशन के लिए, कॉन्टेंट को boot और vendor_boot से जोड़ा या अनुमान लगाया जा सकता है. उदाहरण के लिए:
      • cmdline को boot और vendor_boot cmdline के साथ जोड़ा गया है.
      • DTBO का पता vendor_boot हेडर से लगाया जा सकता है.
    • recovery ramdisk image
      • खाता वापस पाने से जुड़े संसाधन
      • नॉन-A/B रिकवरी पार्टिशन के लिए, रैमडिस्क का कॉन्टेंट स्टैंडअलोन होना चाहिए. रिकवरी इमेज देखें. उदाहरण के लिए:
      • lib/modules में, रिकवरी मोड को बूट करने के लिए ज़रूरी सभी कर्नल मॉड्यूल होने चाहिए
      • रिकवरी रैमडिस्क में init होना चाहिए.
      • A/B रिकवरी पार्टिशन के लिए, रिकवरी रैमडिस्क को सामान्य और vendor_boot रैमडिस्क से पहले जोड़ा जाता है. इसलिए, इसे स्टैंडअलोन होने की ज़रूरत नहीं होती. उदाहरण के लिए:
      • lib/modules में, vendor_boot रैमडिस्क में मौजूद कर्नेल मॉड्यूल के अलावा, सिर्फ़ वे अतिरिक्त कर्नेल मॉड्यूल शामिल हो सकते हैं जो रिकवरी मोड को बूट करने के लिए ज़रूरी हैं.
      • ऐसा हो सकता है कि /init पर सिंबल लिंक मौजूद हो, लेकिन बूट इमेज में मौजूद पहले चरण के /init बाइनरी की वजह से यह लिंक काम न कर रहा हो.

जेनरिक रैमडिस्क इमेज का कॉन्टेंट

सामान्य रैमडिस्क में ये कॉम्पोनेंट शामिल होते हैं.

  • init
  • system/etc/ramdisk/build.prop
  • ro.PRODUCT.bootimg.* build प्रॉप
  • माउंट पॉइंट के लिए खाली डायरेक्ट्री: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/
  • first_stage_ramdisk/
    • माउंट पॉइंट के लिए डुप्लीकेट की गई खाली डायरेक्ट्री: debug_ramdisk/, mnt/, dev/, sys/, proc/, metadata/

बूट इमेज इंटिग्रेशन

बिल्ड फ़्लैग से यह कंट्रोल किया जाता है कि init_boot, boot, recovery, और vendor_boot इमेज कैसे बनाई जाती हैं. बूलियन बोर्ड वैरिएबल की वैल्यू, स्ट्रिंग true होनी चाहिए या खाली होनी चाहिए (यह डिफ़ॉल्ट वैल्यू है).

  • TARGET_NO_KERNEL. यह वैरिएबल बताता है कि बिल्ड, पहले से बनी बूट इमेज का इस्तेमाल करता है या नहीं. अगर इस वैरिएबल को true पर सेट किया गया है, तो BOARD_PREBUILT_BOOTIMAGE को पहले से बनी बूट इमेज (BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img) की जगह पर सेट करें

  • BOARD_USES_RECOVERY_AS_BOOT. इस वैरिएबल से पता चलता है कि डिवाइस, boot इमेज के तौर पर recovery इमेज का इस्तेमाल करता है या नहीं. GKI का इस्तेमाल करते समय, यह वैरिएबल खाली होता है. साथ ही, रिकवरी संसाधनों को vendor_boot में ले जाना चाहिए.

  • BOARD_USES_GENERIC_KERNEL_IMAGE. यह वैरिएबल दिखाता है कि बोर्ड, GKI का इस्तेमाल करता है. इस वैरिएबल से sysprops या PRODUCT_PACKAGES पर कोई असर नहीं पड़ता.

    यह बोर्ड-लेवल का GKI स्विच है. यहां दिए गए सभी वैरिएबल, इस वैरिएबल के हिसाब से काम करते हैं.

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT. यह वैरिएबल कंट्रोल करता है कि क्या ramdisk रिकवरी के संसाधनों को vendor_boot के लिए बनाया गया है.

    • true पर सेट होने पर, रिकवरी के संसाधन सिर्फ़ vendor-ramdisk/ के लिए बनाए जाते हैं. इन्हें recovery/root/ के लिए नहीं बनाया जाता.

    • अगर यह फ़ील्ड खाली है, तो रिकवरी के संसाधन सिर्फ़ recovery/root/ के लिए बनाए जाते हैं, vendor-ramdisk/ के लिए नहीं.

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT. यह वैरिएबल कंट्रोल करता है कि GSI AVB कुंजियां, vendor_boot के लिए बनाई गई हैं या नहीं.

    • true पर सेट होने पर, अगर BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

      • सेट है, तो GSI AVB कुंजियां $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb के लिए बनाई जाती हैं.

      • Is unset, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb.

    • अगर BOARD_RECOVERY_AS_ROOT की वैल्यू खाली है, तो:

      • सेट है, तो GSI AVB कुंजियां $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb के लिए बनाई जाती हैं.

      • Is unset, GSI AVB keys are built to $ANDROID_PRODUCT_OUT/ramdisk/avb.

  • BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE. यह वैरिएबल कंट्रोल करता है कि recovery इमेज में कर्नल है या नहीं. Android 12 के साथ लॉन्च होने वाले और A/B recovery पार्टीशन का इस्तेमाल करने वाले डिवाइसों को इस वैरिएबल को true पर सेट करना होगा. Android 12 के साथ लॉन्च होने वाले और नॉन-ए/बी का इस्तेमाल करने वाले डिवाइसों को इस वैरिएबल को false पर सेट करना होगा, ताकि रिकवरी इमेज को अलग से न रखा जाए.

  • BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES. इस वैरिएबल से यह कंट्रोल किया जाता है कि टारगेट फ़ाइलों में IMAGES/ के नीचे $OUT/boot*.img को कॉपी किया जाए या नहीं.

    • aosp_arm64 को इस वैरिएबल को true पर सेट करना होगा.

    • अन्य डिवाइसों को इस वैरिएबल को खाली छोड़ना होगा.

  • BOARD_INIT_BOOT_IMAGE_PARTITION_SIZE. यह वैरिएबल कंट्रोल करता है कि init_boot.img जनरेट किया गया है या नहीं. साथ ही, यह वैरिएबल साइज़ सेट करता है. इस विकल्प को सेट करने पर, सामान्य रैमडिस्क को boot.img के बजाय init_boot.img में जोड़ा जाता है. साथ ही, चेन किए गए vbmeta के लिए, BOARD_AVB_INIT_BOOT* वैरिएबल सेट करने पड़ते हैं.

अनुमति वाले कॉम्बिनेशन

कॉम्पोनेंट या वैरिएबल रिकवरी पार्टिशन के बिना डिवाइस को अपग्रेड करना रिकवरी पार्टीशन की मदद से डिवाइस को अपग्रेड करना रिकवरी पार्टिशन के बिना डिवाइस लॉन्च करना A/B रिकवरी पार्टिशन वाले डिवाइस को लॉन्च करना बिना ए/बी रिकवरी पार्टिशन वाले डिवाइस को लॉन्च करना aosp_arm64
boot शामिल है हां हाँ हाँ हाँ हाँ हां
इसमें init_boot (Android 13) शामिल है no no हां हाँ हाँ हां
vendor_boot शामिल है वैकल्पिक वैकल्पिक हां हाँ हां no
recovery शामिल है no हां no हां हां no
BOARD_USES_RECOVERY_AS_BOOT true खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_USES_GENERIC_KERNEL_IMAGE खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है true true true true
PRODUCT_BUILD_RECOVERY_IMAGE खिलाड़ी के लिए कोई मार्कर नहीं है true या खाली खिलाड़ी के लिए कोई मार्कर नहीं है true या खाली true या खाली खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_RECOVERYIMAGE_PARTITION_SIZE खिलाड़ी के लिए कोई मार्कर नहीं है > 0 खिलाड़ी के लिए कोई मार्कर नहीं है > 0 > 0 खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है true खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है true true true खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है true खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है
BOARD_COPY_BOOT_IMAGE_TO_TARGET_FILES खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है खिलाड़ी के लिए कोई मार्कर नहीं है true

जिन डिवाइसों में recovery का अलग पार्टीशन होता है वे PRODUCT_BUILD_RECOVERY_IMAGE को true या खाली पर सेट कर सकते हैं. इन डिवाइसों के लिए, अगर BOARD_RECOVERYIMAGE_PARTITION_SIZE सेट है, तो recovery इमेज बनाई जाती है.

बूट के लिए चेन किए गए vbmeta को चालू करें

boot और init_boot इमेज के लिए, चेन किए गए vbmeta को चालू करना ज़रूरी है. इनके बारे में बताएं:

BOARD_AVB_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa4096.pem
BOARD_AVB_BOOT_ALGORITHM := SHA256_RSA4096
BOARD_AVB_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_BOOT_ROLLBACK_INDEX_LOCATION := 2

BOARD_AVB_INIT_BOOT_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem
BOARD_AVB_INIT_BOOT_ALGORITHM := SHA256_RSA2048
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP)
BOARD_AVB_INIT_BOOT_ROLLBACK_INDEX_LOCATION := 3

उदाहरण के लिए, यह बदलाव देखें.

System-as-root

GKI का इस्तेमाल करने वाले डिवाइसों के लिए, सिस्टम-ऐज़-रूट की सुविधा काम नहीं करती. ऐसे डिवाइसों पर, BOARD_BUILD_SYSTEM_ROOT_IMAGE खाली होना चाहिए. सिस्टम-ऐज़-रूट, डाइनैमिक पार्टीशन का इस्तेमाल करने वाले डिवाइसों के लिए भी काम नहीं करता.

प्रॉडक्ट कॉन्फ़िगरेशन

जेनेरिक रैमडिस्क का इस्तेमाल करने वाले डिवाइसों को, उन फ़ाइलों की सूची इंस्टॉल करनी होगी जिन्हें रैमडिस्क में इंस्टॉल करने की अनुमति है. इसके लिए, device.mk में यह जानकारी दें:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)

generic_ramdisk.mk फ़ाइल, अन्य मेकफ़ाइलों को गलती से रैमडिस्क में अन्य फ़ाइलें इंस्टॉल करने से भी रोकती है. ऐसी फ़ाइलों को generic_ramdisk.mk में ले जाएं.vendor_ramdisk

डिवाइसों को सेट अप करना

Android 13 के साथ लॉन्च होने वाले डिवाइसों, Android 12 पर अपग्रेड करने वाले डिवाइसों, और Android 12 के साथ लॉन्च होने वाले डिवाइसों के लिए, सेटअप करने के निर्देश अलग-अलग होते हैं. Android 13 पर, Android 12 की तरह ही सेट अप किए जाते हैं

  • Android 12 पर अपग्रेड किए गए डिवाइसों के लिए:

    • BOARD_USES_RECOVERY_AS_BOOT की वैल्यू को बनाए रख सकता है. ऐसा करने पर, वे लेगसी कॉन्फ़िगरेशन का इस्तेमाल कर रहे होते हैं और नए बिल्ड वैरिएबल खाली होने चाहिए. अगर ऐसे डिवाइस:

      • BOARD_USES_RECOVERY_AS_BOOT को true पर सेट करें. आर्किटेक्चर तीसरी इमेज में दिखाया गया है.

      • BOARD_USES_RECOVERY_AS_BOOT को खाली पर सेट करें. आर्किटेक्चर को चौथी इमेज में दिखाया गया है.

    • BOARD_USES_RECOVERY_AS_BOOT को खाली पर सेट किया जा सकता है. ऐसा करने पर, वे नए कॉन्फ़िगरेशन का इस्तेमाल कर रहे होते हैं. अगर ऐसे डिवाइस:

  • Android 12 के साथ लॉन्च होने वाले डिवाइसों को BOARD_USES_RECOVERY_AS_BOOT को खाली पर सेट करना होगा और नए कॉन्फ़िगरेशन का इस्तेमाल करना होगा. अगर ऐसे डिवाइस:

    • किसी खास recovery पार्टीशन का इस्तेमाल न करें. आर्किटेक्चर, पहली इमेज में दिखाए गए तरीके से होना चाहिए. साथ ही, डिवाइस सेटअप करने का विकल्प पहला विकल्प होना चाहिए.

    • recovery पार्टीशन का इस्तेमाल करें. आर्किटेक्चर इमेज 2a या इमेज 2b में दिखाया गया है. साथ ही, डिवाइस सेटअप करने का विकल्प विकल्प 2a या विकल्प 2b है.

aosp_arm64 सिर्फ़ GKI बनाता है, न कि vendor_boot या रिकवरी. इसलिए, यह पूरा टारगेट नहीं है. aosp_arm64बिल्ड कॉन्फ़िगरेशन के लिए, generic_arm64 देखें.

पहला विकल्प: रिकवरी के लिए कोई अलग पार्टीशन नहीं है

जिन डिवाइसों में recovery पार्टिशन नहीं होता उनमें boot पार्टिशन में, जेनरिक boot इमेज होती है. vendor_boot ramdisk में रिकवरी के सभी संसाधन होते हैं. इनमें lib/modules (वेंडर कर्नल मॉड्यूल के साथ) भी शामिल है. ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन generic_ramdisk.mk से इनहेरिट होता है.

बोर्ड की वैल्यू सेट करना

ये वैल्यू सेट करें:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT := true
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

vendor_boot ramdisk में /init से /system/bin/init सिमलंक हो सकता है. साथ ही, init_second_stage.recovery /system/bin/init पर हो सकता है. हालांकि, vendor_boot ramdisk के बाद सामान्य ramdisk को जोड़ा जाता है. इसलिए, /init सिंबल लिंक को बदल दिया जाता है. जब डिवाइस रिकवरी मोड में बूट होता है, तब दूसरे चरण के init को सपोर्ट करने के लिए /system/bin/init बाइनरी की ज़रूरत होती है. vendor_boot + सामान्य रैमडिस्क में यह कॉन्टेंट होता है:

  • /init (सामान्य रैमडिस्क से, जिसे init_first_stage से बनाया गया है)
  • /system/bin/init (vendor_ramdisk से, init_second_stage.recovery से बनाया गया)

fstab फ़ाइलों को दूसरी जगह ले जाना

जेनेरिक रैमडिस्क में इंस्टॉल की गई fstab फ़ाइलों को vendor_ramdisk में ले जाएं. उदाहरण के लिए, यह बदलाव देखें.

मॉड्यूल इंस्टॉल करना

डिवाइस के हिसाब से मॉड्यूल इंस्टॉल किए जा सकते हैं. vendor_ramdisk (अगर आपको डिवाइस के हिसाब से कोई मॉड्यूल इंस्टॉल नहीं करना है, तो इस चरण को छोड़ दें).

  • जब मॉड्यूल /first_stage_ramdisk में इंस्टॉल होता है, तब मॉड्यूल के vendor_ramdisk वैरिएंट का इस्तेमाल करें. यह मॉड्यूल, init के रूट को /first_stage_ramdisk में स्विच करने के बाद और init के रूट को /system में स्विच करने से पहले उपलब्ध होना चाहिए. उदाहरण के लिए, मेटाडेटा के चेकसम और वर्चुअल A/B कंप्रेशन देखें.

  • जब मॉड्यूल / में इंस्टॉल हो, तब मॉड्यूल के recovery वैरिएंट का इस्तेमाल करें. यह मॉड्यूल, init के रूट को /first_stage_ramdisk में स्विच करने से पहले उपलब्ध होना चाहिए. / के लिए मॉड्यूल इंस्टॉल करने के बारे में जानकारी पाने के लिए, पहली स्टेज का कंसोल देखें.

पहले चरण का कंसोल

पहली स्टेज का कंसोल, init के रूट को /first_stage_ramdisk में स्विच करने से पहले शुरू होता है. इसलिए, आपको मॉड्यूल का recovery वर्शन इंस्टॉल करना होगा. डिफ़ॉल्ट रूप से, दोनों मॉड्यूल वैरिएंट build/make/target/product/base_vendor.mk में इंस्टॉल होते हैं. इसलिए, अगर डिवाइस की मेकफ़ाइल उस फ़ाइल से इनहेरिट होती है, तो आपको recovery वैरिएंट को अलग से इंस्टॉल करने की ज़रूरत नहीं है.

रिकवरी मॉड्यूल को साफ़ तौर पर इंस्टॉल करने के लिए, इसका इस्तेमाल करें.

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

इससे यह पक्का होता है कि linker, sh, और toybox, $ANDROID_PRODUCT_OUT/recovery/root/system/bin पर इंस्टॉल हो जाएं. इसके बाद, $ANDROID_PRODUCT_OUT/recovery/root/system/bin, vendor_ramdisk के तहत /system/bin पर इंस्टॉल हो जाता है.

पहले चरण के कंसोल के लिए ज़रूरी मॉड्यूल (उदाहरण के लिए, adbd) जोड़ने के लिए, यहां दिया गया तरीका अपनाएं.

PRODUCT_PACKAGES += adbd.recovery

इससे यह पक्का होता है कि बताए गए मॉड्यूल $ANDROID_PRODUCT_OUT/recovery/root/system/bin में इंस्टॉल हो जाएं. इसके बाद, $ANDROID_PRODUCT_OUT/recovery/root/system/bin, vendor_ramdisk में इंस्टॉल हो जाता है./system/bin

मेटाडेटा चेकसम

पहले चरण में माउंट करने के दौरान, मेटाडेटा चेकस को सपोर्ट करने के लिए, जिन डिवाइसों पर GKI इंस्टॉल नहीं किया जा सकता वे यहां दिए गए मॉड्यूल के ramdisk वैरिएंट इंस्टॉल करते हैं. GKI के लिए सहायता जोड़ने के लिए, मॉड्यूल को $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin पर ले जाएं:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

उदाहरण के लिए, बदलावों की यह सूची देखें.

वर्चुअल A/B कंप्रेशन

वर्चुअल A/B कंप्रेशन के लिए, snapuserd को vendor_ramdisk पर इंस्टॉल करना ज़रूरी है. डिवाइस को virtual_ab_ota/compression.mk से इनहेरिट करना चाहिए. virtual_ab_ota/compression.mk, snapuserd का vendor_ramdisk वैरिएंट इंस्टॉल करता है.

बूट प्रोसेस में हुए बदलाव

रिकवरी मोड या Android में बूट करने की प्रोसेस में कोई बदलाव नहीं होता. हालांकि, इसमें यह अपवाद शामिल है:

  • Ramdisk build.prop, /second_stage_resources में चला जाता है, ताकि दूसरे चरण init में बूट के बिल्ड टाइमस्टैंप को पढ़ा जा सके.

संसाधन, सामान्य रैमडिस्क से vendor_boot रैमडिस्क में ट्रांसफ़र होते हैं. इसलिए, सामान्य रैमडिस्क को vendor_boot रैमडिस्क से जोड़ने पर कोई बदलाव नहीं होता.

e2fsck को उपलब्ध कराएं

डिवाइस के मेकफ़ाइल, यहां से इनहेरिट किए जा सकते हैं:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk अगर डिवाइस पर वर्चुअल A/B की सुविधा काम करती है, लेकिन कंप्रेशन की सुविधा काम नहीं करती.

  • virtual_ab_ota/compression.mk अगर डिवाइस पर वर्चुअल A/B कंप्रेशन की सुविधा काम करती है.

प्रॉडक्ट की मेकफ़ाइलें, $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck इंस्टॉल करती हैं. रनटाइम के दौरान, पहला चरण init रूट को /first_stage_ramdisk में बदलता है. इसके बाद, /system/bin/e2fsck को लागू करता है.

विकल्प 2a: रिकवरी के लिए अलग से और A/B टेस्टिंग के लिए पार्टीशन

इस विकल्प का इस्तेमाल उन डिवाइसों के लिए करें जिनमें A/B recovery पार्टीशन हैं. इसका मतलब है कि डिवाइस में recovery_a और recovery_b partition है. ऐसे डिवाइसों में A/B और वर्चुअल A/B डिवाइस शामिल हैं. इनके रिकवरी पार्टीशन को अपडेट किया जा सकता है. इनका कॉन्फ़िगरेशन इस तरह से होता है:

AB_OTA_PARTITIONS += recovery

vendor_boot ramdisk में, ramdisk और वेंडर कर्नेल मॉड्यूल के वेंडर बिट शामिल होते हैं. इनमें ये शामिल हैं:

  • डिवाइस के हिसाब से fstab फ़ाइलें

  • lib/modules (इसमें वेंडर कर्नेल मॉड्यूल शामिल हैं)

recovery ramdisk में, रिकवरी के सभी संसाधन होते हैं. ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन generic_ramdisk.mk से इनहेरिट होता है.

बोर्ड की वैल्यू सेट करना

A/B recovery पार्टीशन वाले डिवाइसों के लिए, ये वैल्यू सेट करें:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery ramdisk में /init -> /system/bin/init सिमलंक और /system/bin/init पर init_second_stage.recovery शामिल हो सकता है. हालांकि, बूट रैमडिस्क को recovery रैमडिस्क के बाद जोड़ा जाता है. इसलिए, /init सिंबल लिंक को बदल दिया जाता है. जब डिवाइस रिकवरी मोड में बूट होता है, तब दूसरे चरण के init को सपोर्ट करने के लिए /system/bin/init बाइनरी की ज़रूरत होती है.

डिवाइस के recovery में बूट होने पर, recovery + vendor_boot + सामान्य रैमडिस्क का कॉन्टेंट इस तरह होता है:

  • /init (रैमडिस्क से, init_first_stage से बनाया गया)
  • /system/bin/init (recovery रैमडिस्क से, init_second_stage.recovery से बनाया गया, और /init से एक्ज़ीक्यूट किया गया)

जब डिवाइस Android में बूट होता है, तब vendor_boot + सामान्य रैमडिस्क का कॉन्टेंट इस तरह होता है:

  • /init (सामान्य रैमडिस्क से, जिसे init_first_stage से बनाया गया है)

fstab फ़ाइलों को दूसरी जगह ले जाना

जेनेरिक रैमडिस्क में इंस्टॉल की गई सभी fstab फ़ाइलों को vendor_ramdisk में ले जाएं. उदाहरण के लिए, यह बदलाव देखें.

मॉड्यूल इंस्टॉल करना

इसके अलावा, डिवाइस के हिसाब से मॉड्यूल इंस्टॉल किए जा सकते हैं. vendor_ramdisk (अगर आपको डिवाइस के हिसाब से कोई मॉड्यूल इंस्टॉल नहीं करना है, तो यह चरण छोड़ें). Init रूट को स्विच नहीं करता है. मॉड्यूल का vendor_ramdisk वैरिएंट, vendor_ramdisk के रूट में इंस्टॉल होता है. vendor_ramdisk में मॉड्यूल इंस्टॉल करने के उदाहरणों के लिए, पहले चरण का कंसोल, मेटाडेटा के चेकसम, और वर्चुअल ए/बी कंप्रेसर देखें.

पहले चरण का कंसोल

मॉड्यूल के vendor_ramdisk वर्शन को इंस्टॉल करने के लिए, इसका इस्तेमाल करें:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

इससे यह पक्का होता है कि linker, sh, और toybox, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर इंस्टॉल हो जाएं. इसके बाद, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, vendor_ramdisk के तहत /system/bin पर इंस्टॉल हो जाता है.

पहले चरण के कंसोल के लिए ज़रूरी मॉड्यूल (उदाहरण के लिए, adbd) जोड़ने के लिए, इन मॉड्यूल के vendor_ramdisk वैरिएंट को चालू करें. इसके लिए, AOSP में ज़रूरी पैच अपलोड करें. इसके बाद, यहां दिया गया तरीका अपनाएं,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

इससे यह पक्का होता है कि बताए गए मॉड्यूल, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर इंस्टॉल हो जाएं. अगर रिकवरी मोड में vendor_boot ramdisk लोड किया जाता है, तो मॉड्यूल recovery में भी उपलब्ध होता है. अगर रिकवरी मोड में vendor_boot ramdisk लोड नहीं होता है, तो डिवाइस में adbd.recovery को भी इंस्टॉल किया जा सकता है.

मेटाडेटा चेकसम

पहले चरण में माउंट करने के दौरान, मेटाडेटा चेकस को सपोर्ट करने के लिए, जिन डिवाइसों पर GKI इंस्टॉल नहीं किया जा सकता वे यहां दिए गए मॉड्यूल के ramdisk वैरिएंट इंस्टॉल करते हैं. GKI के लिए सहायता जोड़ने के लिए, मॉड्यूल को $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर ले जाएं:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

उदाहरण के लिए, बदलावों की यह सूची देखें.

वर्चुअल A/B कंप्रेशन

वर्चुअल A/B कंप्रेशन के लिए, snapuserd को vendor_ramdisk पर इंस्टॉल किया जाना चाहिए. डिवाइस को virtual_ab_ota/compression.mk से इनहेरिट करना चाहिए. virtual_ab_ota/compression.mk, snapuserd का vendor_ramdisk वैरिएंट इंस्टॉल करता है.

बूट प्रोसेस में हुए बदलाव

Android में बूट करने पर, बूट करने की प्रोसेस में कोई बदलाव नहीं होता. vendor_boot + जेनेरिक रैमडिस्क, बूट करने की मौजूदा प्रोसेस की तरह ही होता है. हालांकि, इसमें fstab, vendor_boot से लोड होता है. system/bin/recovery मौजूद न होने की वजह से, first_stage_init इसे सामान्य बूट के तौर पर हैंडल करता है.

रिकवरी मोड में बूट करने पर, बूट करने की प्रोसेस बदल जाती है. रिकवरी + vendor_boot + सामान्य रैमडिस्क, मौजूदा रिकवरी प्रोसेस की तरह ही होती है. हालांकि, इसमें कर्नल को recovery इमेज के बजाय boot इमेज से लोड किया जाता है. रिकवरी मोड में बूट करने की प्रोसेस यहां दी गई है.

  1. बूटलोडर शुरू होता है. इसके बाद, यह ये काम करता है:

    1. यह vendor_boot में रिकवरी + vendor_boot + जेनरिक रैमडिस्क को पुश करता है./ (अगर ओईएम, रिकवरी रैमडिस्क में कर्नेल मॉड्यूल को डुप्लीकेट करता है, तो BOARD_RECOVERY_KERNEL_MODULES को जोड़ना ज़रूरी नहीं है.)vendor_boot
    2. यह boot पार्टीशन से कर्नल को चलाता है.

  2. कर्नेल, रैमडिस्क को / पर माउंट करता है. इसके बाद, जेनेरिक रैमडिस्क से /init को एक्ज़ीक्यूट करता है.

  3. पहले चरण की init प्रोसेस शुरू होती है. इसके बाद, यह प्रोसेस ये काम करती है:

    1. IsRecoveryMode() == true और ForceNormalBoot() == false सेट करता है.
    2. यह /lib/modules से वेंडर कर्नेल मॉड्यूल लोड करता है.
    3. कॉल DoFirstStageMount() करता है, लेकिन माउंट करने की प्रोसेस को छोड़ देता है, क्योंकि IsRecoveryMode() == true. (डिवाइस, रैमडिस्क को खाली नहीं करता है, क्योंकि / अब भी वही है. हालांकि, यह SetInitAvbVersionInRecovery() को कॉल करता है.)
    4. यह recovery ramdisk से /system/bin/init से दूसरे चरण की शुरुआत करता है.

e2fsck को उपलब्ध कराएं

डिवाइस के मेकफ़ाइल, यहां से इनहेरिट किए जा सकते हैं:

  • virtual_ab_ota/launch_with_vendor_ramdisk.mk अगर डिवाइस पर वर्चुअल A/B की सुविधा काम करती है, लेकिन कंप्रेशन की सुविधा काम नहीं करती.

  • virtual_ab_ota/compression.mk अगर डिवाइस पर वर्चुअल A/B कंप्रेशन की सुविधा काम करती है.

प्रॉडक्ट की मेकफ़ाइलें, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck इंस्टॉल करती हैं. रनटाइम के दौरान, पहली स्टेज init को /system/bin/e2fsck किया जाता है.

दूसरा विकल्प: रिकवरी के लिए अलग से बनाया गया और A/B टेस्ट के लिए इस्तेमाल न किया जाने वाला पार्टीशन

इस विकल्प का इस्तेमाल उन डिवाइसों के लिए करें जिनमें नॉन-ए/बी recovery पार्टिशन होता है. इसका मतलब है कि डिवाइस में recovery नाम का एक पार्टिशन होता है, जिसमें स्लॉट सफ़िक्स नहीं होता. इस तरह के डिवाइसों में ये शामिल हैं:

  • नॉन-A/B डिवाइसों के लिए;
  • A/B और वर्चुअल A/B डिवाइस, जिनमें रिकवरी पार्टीशन को अपडेट नहीं किया जा सकता. (यह असामान्य है.)

vendor_boot ramdisk में, ramdisk और वेंडर कर्नेल मॉड्यूल के वेंडर बिट शामिल होते हैं. इनमें ये शामिल हैं:

  • डिवाइस के हिसाब से fstab फ़ाइलें
  • lib/modules (इसमें वेंडर कर्नेल मॉड्यूल शामिल हैं)

recovery इमेज में सभी ज़रूरी जानकारी होनी चाहिए. इसमें रिकवरी मोड को बूट करने के लिए, सभी ज़रूरी संसाधन शामिल होने चाहिए. जैसे:

  • कर्नेल इमेज
  • डीटीबीओ इमेज
  • lib/modules में कर्नेल मॉड्यूल
  • सिमलिंक के तौर पर पहले चरण का इनिट /init -> /system/bin/init
  • सेकंड-स्टेज इनिट बाइनरी /system/bin/init
  • डिवाइस के हिसाब से fstab फ़ाइलें
  • डेटा वापस पाने के लिए अन्य सभी संसाधन, जिनमें recovery बाइनरी भी शामिल है

ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन generic_ramdisk.mk से इनहेरिट होता है.

बोर्ड की वैल्यू सेट करना

A/B टेस्टिंग की सुविधा वाले डिवाइसों के लिए, ये वैल्यू सेट करें:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE :=
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

recovery रैमडिस्क में /init -> /system/bin/init सिमलंक और /system/bin/init पर init_second_stage.recovery होना चाहिए. जब डिवाइस रिकवरी मोड में बूट होता है, तब पहले और दूसरे चरण की शुरुआत, दोनों के लिए /system/bin/init बाइनरी की ज़रूरत होती है.

जब डिवाइस recovery में बूट होता है, तब recovery रैमडिस्क का कॉन्टेंट इस तरह होता है:

  • /init -> /system/bin/init (recovery रैमडिस्क से)
  • /system/bin/init (recovery रैमडिस्क से, init_second_stage.recovery से बनाया गया, और /init से एक्ज़ीक्यूट किया गया)

जब डिवाइस Android में बूट होता है, तब vendor_boot + सामान्य रैमडिस्क का कॉन्टेंट इस तरह होता है:

  • /init (रैमडिस्क से, init_first_stage से बनाया गया)

fstab फ़ाइलों को दूसरी जगह ले जाना

जेनेरिक रैमडिस्क में इंस्टॉल की गई सभी fstab फ़ाइलों को vendor_ramdisk और recovery रैमडिस्क में ले जाएं. उदाहरण के लिए, यह बदलाव देखें.

मॉड्यूल इंस्टॉल करना

vendor_ramdisk और recovery रैमडिस्क में डिवाइस के हिसाब से मॉड्यूल इंस्टॉल किए जा सकते हैं. अगर आपको डिवाइस के हिसाब से कोई मॉड्यूल इंस्टॉल नहीं करना है, तो यह चरण छोड़ दें. init रूट को स्विच नहीं करता है. मॉड्यूल का vendor_ramdisk वैरिएंट, vendor_ramdisk के रूट में इंस्टॉल होता है. मॉड्यूल का recovery वैरिएंट, recovery रैमडिस्क के रूट में इंस्टॉल होता है. vendor_ramdisk और recovery रैमडिस्क में मॉड्यूल इंस्टॉल करने के उदाहरणों के लिए, पहले चरण का कंसोल और मेटाडेटा के चेकसम देखें.

पहले चरण का कंसोल

मॉड्यूल के vendor_ramdisk वर्शन को इंस्टॉल करने के लिए, इसका इस्तेमाल करें:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

इससे यह पक्का होता है कि linker, sh, और toybox, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर इंस्टॉल हो जाएं. इसके बाद, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin, vendor_ramdisk के तहत /system/bin पर इंस्टॉल हो जाता है.

पहले चरण के कंसोल के लिए ज़रूरी मॉड्यूल (उदाहरण के लिए, adbd) जोड़ने के लिए, इन मॉड्यूल के vendor_ramdisk वैरिएंट को चालू करें. इसके लिए, AOSP में ज़रूरी पैच अपलोड करें. इसके बाद, यहां दिया गया तरीका अपनाएं,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

इससे यह पक्का होता है कि बताए गए मॉड्यूल, $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर इंस्टॉल हो जाएं.

मॉड्यूल के recovery वैरिएंट को इंस्टॉल करने के लिए, vendor_ramdisk को recovery से बदलें:

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

मेटाडेटा चेकसम

पहले चरण में माउंट करने के दौरान, मेटाडेटा चेकस को सपोर्ट करने के लिए, जिन डिवाइसों पर GKI इंस्टॉल नहीं किया जा सकता वे यहां दिए गए मॉड्यूल के ramdisk वैरिएंट इंस्टॉल करते हैं. GKI के लिए सहायता जोड़ने के लिए, मॉड्यूल को $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin पर ले जाएं:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

पहले चरण में रिकवरी के दौरान मेटाडेटा के चेकसम की सुविधा इस्तेमाल करने के लिए, इन मॉड्यूल के रिकवरी वैरिएंट चालू करें और उन्हें इंस्टॉल करें.

बूट प्रोसेस में हुए बदलाव

Android में बूट करने पर, बूट करने की प्रोसेस में कोई बदलाव नहीं होता. vendor_boot + जेनेरिक रैमडिस्क, बूट करने की मौजूदा प्रोसेस की तरह ही होता है. हालांकि, इसमें fstab, vendor_boot से लोड होता है. system/bin/recovery मौजूद न होने की वजह से, first_stage_init इसे सामान्य बूट के तौर पर हैंडल करता है.

रिकवरी मोड में बूट करने पर, बूट करने की प्रोसेस में कोई बदलाव नहीं होता. रिकवरी रैमडिस्क को उसी तरह से लोड किया जाता है जिस तरह से मौजूदा रिकवरी प्रोसेस में किया जाता है. कर्नेल को recovery इमेज से लोड किया जाता है. रिकवरी मोड में बूट करने की प्रोसेस यहां दी गई है.

  1. बूटलोडर शुरू होता है. इसके बाद, यह ये काम करता है:

    1. यह कुकी, रिकवरी रैमडिस्क को / पर पुश करती है.
    2. यह recovery पार्टीशन से कर्नल को चलाता है.

  2. कर्नेल, रैमडिस्क को / पर माउंट करता है. इसके बाद, /init को एक्ज़ीक्यूट करता है. यह recovery रैमडिस्क से /system/bin/init का सिमलंक होता है.

  3. पहले चरण की init प्रोसेस शुरू होती है. इसके बाद, यह प्रोसेस ये काम करती है:

    1. IsRecoveryMode() == true और ForceNormalBoot() == false सेट करता है.
    2. यह /lib/modules से वेंडर कर्नेल मॉड्यूल लोड करता है.
    3. कॉल DoFirstStageMount() करता है, लेकिन माउंट करने की प्रोसेस को छोड़ देता है, क्योंकि IsRecoveryMode() == true. (डिवाइस, रैमडिस्क को खाली नहीं करता है, क्योंकि / अब भी वही है. हालांकि, यह SetInitAvbVersionInRecovery() को कॉल करता है.)
    4. यह recovery ramdisk से /system/bin/init से दूसरे चरण की शुरुआत करता है.

बूट इमेज के टाइमस्टैंप

यहां boot इमेज के टाइमस्टैंप वाली फ़ाइल का उदाहरण दिया गया है:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

  • बिल्ड टाइम पर, system/etc/ramdisk/build.prop फ़ाइल को सामान्य रैमडिस्क में जोड़ दिया जाता है. इस फ़ाइल में, बिल्ड के टाइमस्टैंप की जानकारी होती है.

  • रनटाइम के दौरान, पहले चरण में init, रैमडिस्क से फ़ाइलों को tmpfs में कॉपी करता है. इसके बाद, रैमडिस्क को खाली कर देता है, ताकि दूसरे चरण में init इस फ़ाइल को पढ़कर boot इमेज के टाइमस्टैंप की प्रॉपर्टी सेट कर सके.