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

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 पर लॉन्च किए जा रहे हैं या अपग्रेड किए जा रहे हैं. इनमें GKI, डेडिकेटेड, और A/B रिकवरी की सुविधा उपलब्ध है.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. इस वैरिएबल से पता चलता है कि डिवाइस, recovery इमेज को boot इमेज के तौर पर इस्तेमाल करता है या नहीं. GKI का इस्तेमाल करते समय, यह वैरिएबल खाली होता है. साथ ही, रिकवरी संसाधनों को vendor_boot में ले जाना चाहिए.

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

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

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

    • 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 के लिए बनाई जाती हैं.

      • अगर इस नीति को सेट नहीं किया जाता है, तो जीएसआई एवीबी कुंजियां $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb पर बनाई जाती हैं.

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

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

      • अगर इस नीति को सेट नहीं किया जाता है, तो जीएसआई एवीबी कुंजियां $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 जनरेट किया गया है या नहीं. साथ ही, यह वैरिएबल init_boot.img का साइज़ सेट करता है. इस विकल्प को सेट करने पर, सामान्य रैमडिस्क को boot.img के बजाय init_boot.img में जोड़ा जाता है. साथ ही, चेन किए गए vbmeta के लिए, BOARD_AVB_INIT_BOOT* वैरिएबल सेट करने पड़ते हैं.

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

कॉम्पोनेंट या वैरिएबल रिकवरी पार्टीशन के बिना डिवाइस को अपग्रेड करना रिकवरी पार्टीशन की मदद से डिवाइस को अपग्रेड करना रिकवरी पार्टिशन के बिना डिवाइस लॉन्च करना A/B रिकवरी पार्टिशन वाले डिवाइस को लॉन्च करना बिना ए/बी रिकवरी पार्टिशन वाले डिवाइस को लॉन्च करना aosp_arm64
boot शामिल है हां हां हां हां हां हां
इसमें init_boot (Android 13) शामिल है नहीं नहीं हां हां हां हां
vendor_boot शामिल है ज़रूरी नहीं ज़रूरी नहीं हां हां हां नहीं
recovery शामिल है नहीं हां नहीं हां हां नहीं
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 को खाली पर सेट किया जा सकता है. ऐसा करने पर, वे नए कॉन्फ़िगरेशन का इस्तेमाल कर रहे होते हैं. अगर ऐसे डिवाइस:

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

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

  • 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 वैल्यू सेट करना

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

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 symlink को बदल दिया जाता है. जब डिवाइस रिकवरी मोड में बूट होता है, तब दूसरे चरण के 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 में इंस्टॉल हो जाएं. इसके बाद, ये 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 से इनहेरिट करना चाहिए. इससे 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 रैमडिस्क में, रिकवरी के सभी संसाधन होते हैं. ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन generic_ramdisk.mk से इनहेरिट होता है.

BOARD वैल्यू सेट करना

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 रैमडिस्क में /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 से इनहेरिट करना चाहिए. इससे snapuserd का vendor_ramdisk वैरिएंट इंस्टॉल होता है.

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

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

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

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

    1. यह रिकवरी + vendor_boot + जेनरिक रैमडिस्क को / पर पुश करता है. (अगर ओईएम, रिकवरी रैमडिस्क में कर्नेल मॉड्यूल को डुप्लीकेट करता है, तो उन्हें BOARD_RECOVERY_KERNEL_MODULES में जोड़कर डुप्लीकेट किया जाता है. इसलिए, 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 होती है.

दूसरा विकल्प: रिकवरी के लिए अलग से और नॉन-ए/बी पार्टीशन

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

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

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

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

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

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

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

BOARD वैल्यू सेट करना

नॉन-ए/बी डिवाइसों के लिए, ये वैल्यू सेट करें:

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 ramdisk के लिए, डिवाइस के हिसाब से मॉड्यूल इंस्टॉल किए जा सकते हैं. अगर आपको डिवाइस के हिसाब से कोई मॉड्यूल इंस्टॉल नहीं करना है, तो यह चरण छोड़ दें. 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. कर्नल, ramdisk को / पर माउंट करता है. इसके बाद, /init को एक्ज़ीक्यूट करता है. यह recovery ramdisk से /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 इमेज के टाइमस्टैंप की प्रॉपर्टी सेट कर सके.