सामान्य बूट विभाजन

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

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

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

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

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

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

• recovery के लिए अलग से बनाए गए पार्टीशन का इस्तेमाल करें. recovery के लिए बनाए गए रैमडिस्क में कोई बदलाव करने की ज़रूरत नहीं है, क्योंकि recovery का रैमडिस्क अपने-आप काम करता है.

भवन निर्माण

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

Android 13 के साथ लॉन्च किया गया, कोई खास रिकवरी नहीं

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

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

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

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

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

तीसरी इमेज. ऐसे डिवाइस जो Android 13 पर लॉन्च किए जा रहे हैं या अपग्रेड किए जा रहे हैं. इनमें GKI, खास तौर पर बनाई गई रिकवरी, और A/B रिकवरी के अलावा अन्य रिकवरी शामिल है.

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

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

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

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

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

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

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

छठी इमेज. ऐसे डिवाइस जो Android 12 पर लॉन्च किए जा रहे हैं या अपग्रेड किए जा रहे हैं. इनमें GKI, खास, और A/B रिकवरी के अलावा अन्य रिकवरी मोड भी मौजूद हैं.

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

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

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

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

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

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

Android बूट इमेज में ये चीज़ें शामिल होती हैं.

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

  • हेडर का वर्शन 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 हेडर
    • डिवाइस के हिसाब से cmdline (BOARD_KERNEL_CMDLINE)
  • vendor_boot ramdisk इमेज
    • lib/modules
    • खाता वापस पाने के संसाधन (अगर खाता वापस पाने के लिए कोई खास संसाधन नहीं है)
  • dtb इमेज

• recovery इमेज

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

  • 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 के साथ लॉन्च होने वाले और A/B के अलावा किसी अन्य वर्शन का इस्तेमाल करने वाले डिवाइसों को, रिकवरी इमेज को अपने-आप काम करने के लिए, इस वैरिएबल को false पर सेट करना होगा.

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

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

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

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

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

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

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

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

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

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

Init बाइनरी और सिमलिंक

vendor_boot रैमडिस्क में /init से /system/bin/init का लिंक हो सकता है और /system/bin/init में init_second_stage.recovery हो सकता है. हालांकि, 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 पर इंस्टॉल हो जाएं. इसके बाद, vendor_ramdisk के तहत /system/bin पर इंस्टॉल हो जाएं.

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

PRODUCT_PACKAGES += adbd.recovery

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

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

पहले चरण के माउंट के दौरान मेटाडेटा के चेकसम का इस्तेमाल करने के लिए, GKI के साथ काम न करने वाले डिवाइसों पर, इन मॉड्यूल का रैमडिस्क वैरिएंट इंस्टॉल किया जाता है. 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 compression की सुविधा काम करती है.

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

दूसरा विकल्प: खास और A/B रिकवरी पार्टीशन

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

AB_OTA_PARTITIONS += recovery

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

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

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

recovery ramdisk में, रिकवरी के सभी संसाधन होते हैं. ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन 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

Init बाइनरी और सिमलिंक

recovery रैमडिस्क में /init -> /system/bin/init सिमलिंक और /system/bin/init पर init_second_stage.recovery हो सकता है. हालांकि, recovery ramdisk के बाद बूट ramdisk को जोड़ा जाता है, इसलिए /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 में मॉड्यूल इंस्टॉल करने के उदाहरणों के लिए, पहले चरण का कंसोल, मेटाडेटा के लिए चेकसम, और वर्चुअल A/B कंप्रेसन देखें.

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

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

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

पहले चरण के माउंट के दौरान मेटाडेटा के चेकसम का इस्तेमाल करने के लिए, GKI के साथ काम न करने वाले डिवाइसों पर, इन मॉड्यूल का रैमडिस्क वैरिएंट इंस्टॉल किया जाता है. 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 + सामान्य रैमडिस्क को / पर पुश करता है. (अगर OEM, BOARD_RECOVERY_KERNEL_MODULES में जोड़कर रिकवरी रामडिस्क में कर्नेल मॉड्यूल को डुप्लीकेट करता है, तो vendor_boot ज़रूरी नहीं है.)
   2. boot पार्टीशन से कर्नेल चलाता है.

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

3. पहला चरण शुरू होने के बाद, ये काम किए जाते हैं:

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

e2fsck को उपलब्ध कराना

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

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

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

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

दूसरा विकल्प 2b: खास और नॉन-A/B रिकवरी पार्टीशन

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

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

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

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

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

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

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

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

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

Init बाइनरी और सिमलिंक

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

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

• /init -> /system/bin/init (recovery ramdisk से)
• /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 पर इंस्टॉल हो जाएं. इसके बाद, vendor_ramdisk के तहत /system/bin पर इंस्टॉल हो जाएं.

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

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 के साथ काम न करने वाले डिवाइसों पर, इन मॉड्यूल का रैमडिस्क वैरिएंट इंस्टॉल किया जाता है. 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. पहला चरण शुरू होने के बाद, ये काम किए जाते हैं:

   1. IsRecoveryMode() == true और ForceNormalBoot() == false सेट करता है.
   2. /lib/modules से वेंडर के कर्नेल मॉड्यूल लोड करता है.
   3. DoFirstStageMount() को कॉल करता है, लेकिन IsRecoveryMode() == true की वजह से माउंट नहीं करता. (डिवाइस, रैमडिस्क को खाली नहीं करता, क्योंकि / अब भी पहले जैसा है. हालांकि, वह SetInitAvbVersionInRecovery() को कॉल करता है.)
   4. recovery रैमडिस्क से /system/bin/init से दूसरे चरण की 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 इमेज के टाइमस्टैंप की प्रॉपर्टी सेट करने के लिए, इस फ़ाइल को रीड कर सकता है.