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

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

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 12 में अपग्रेड होने वाले डिवाइस 13 उपयोगकर्ता उसी आर्किटेक्चर का इस्तेमाल करते हैं जिसे वे Android 12.

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

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

पहला डायग्राम. Android 13 वाले डिवाइसों में, GKI (जीकेआई) की मदद से, इसे लॉन्च या अपग्रेड किया जा रहा हो. इनमें, रिकवरी टूल का इस्तेमाल नहीं किया जा सकता.

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

डिवाइस, GKI, खास तौर पर काम करने वाले ऐप्लिकेशन, और A/B रिकवरी डिवाइस को लॉन्च या अपग्रेड करना

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

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

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

डिवाइस, GKI, खास तौर पर काम करने वाले और नॉन-A/B रिकवरी डिवाइस को लॉन्च या अपग्रेड करना

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

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

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

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

चौथी इमेज. Android 12 वाले डिवाइसों पर, GKI (जीकेआई) की सुविधा वाले डिवाइस, जिन्हें किसी खास तरीके से वापस पाने के लिए सेट नहीं किया गया है.

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

डिवाइस, GKI, खास तौर पर काम करने वाले ऐप्लिकेशन, और A/B रिकवरी डिवाइस को लॉन्च या अपग्रेड करना

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

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

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

डिवाइस, GKI, खास तौर पर काम करने वाले और नॉन-A/B रिकवरी डिवाइस को लॉन्च या अपग्रेड करना

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

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

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

GKI (जीकेआई) के बिना, चालू या अपग्रेड करने वाला डिवाइस

सातवीं इमेज. Android 12 पर अपग्रेड होने वाले डिवाइस, जिनमें GKI (जीकेआई) की सुविधा नहीं है. डिवाइस वापस पाने के लिए डिफ़ॉल्ट रूप से चालू होना ज़रूरी है.

Android 12 पर अपग्रेड करें. इसमें आपको रिकवरी के लिए खास तौर पर, दिया गया रैम डिस्क मिलेगा

डिवाइस लॉन्च या अपग्रेड करें, कोई GKI (जीकेआई) नहीं, रिकवरी के लिए खास तौर पर बनाया गया

आठवीं इमेज. Android 12 पर अपग्रेड होने वाले डिवाइस, जिनमें GKI (जीकेआई) की सुविधा मौजूद नहीं है. साथ ही, इसमें रिकवरी की सुविधा दी गई है.

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

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

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

    • हेडर वर्शन V4
    • सामान्य ramdisk इमेज

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

    • हेडर वर्शन V3 या वर्शन 4
      • GKIboo.img सर्टिफ़िकेशन के लिए boot_signature (सिर्फ़ v4 वर्शन). कॉन्टेंट बनाने प्रमाणित GKI boot.img को वेरिफ़ाइड बूट के लिए साइन नहीं किया गया है. OEM को यह करना चाहिए पहले से बने boot.img को किसी खास डिवाइस से साइन करें एवीबी बटन दबाएं.
      • सामान्य cmdline (GENERIC_KERNEL_CMDLINE)
      • GKI कर्नेल
    • सामान्य ramdisk इमेज
      • Android 12 की सिर्फ़ boot इमेज में शामिल है और पहले

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

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

  • recovery इमेज

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

सामान्य ramdisk इमेज कॉन्टेंट

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

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

  • BOARD_USES_GENERIC_KERNEL_IMAGE. इस वैरिएबल से पता चलता है कि बोर्ड जीकेआई. यह वैरिएबल साइप्रोप या PRODUCT_PACKAGES.

    यह बोर्ड-लेवल का जीकेआई स्विच है; निम्न सभी वैरिएबल इस वैरिएबल से प्रतिबंधित.

  • 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. यह वैरिएबल कंट्रोल करता है कि जीएसआई एवीबी कुंजियां, vendor_boot के लिए बनाई गई हैं.

    • जब true पर सेट किया जाता है, अगर BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT:

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

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

    • खाली होने पर, अगर BOARD_RECOVERY_AS_ROOT:

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

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

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

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

रूट के रूप में सिस्टम

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

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

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

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

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

पहला विकल्प: रिकवरी के लिए कोई खास हिस्सा नहीं

बिना recovery पार्टिशन वाले डिवाइसों में जेनरिक boot इमेज होती है boot विभाजन. vendor_boot के रैम डिस्क में, डेटा वापस पाने के लिए सभी संसाधन मौजूद हैं, इसमें 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 रैम डिस्क में /init से /system/bin/init तक का सिमलिंक हो सकता है, और init_second_stage.recovery को /system/bin/init बजे. हालांकि, क्योंकि सामान्य रैमडिस्क को vendor_boot रैमडिस्क, /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 में, डिवाइस के हिसाब से खास मॉड्यूल इंस्टॉल किए जा सकते हैं (अभी नहीं अगर आपके पास इंस्टॉल करने के लिए डिवाइस के हिसाब से खास मॉड्यूल नहीं है, तो इस चरण को पूरा करके देखें).

  • मॉड्यूल के इंस्टॉल होने पर, मॉड्यूल के vendor_ramdisk वैरिएंट का इस्तेमाल करें /first_stage_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 (जीकेआई) के साथ काम नहीं करते हैं, रैमडिस्क इंस्टॉल करते हैं दिए गए मॉड्यूल का एक वैरिएंट है. जीकेआई के साथ काम करने के लिए, मॉड्यूल को $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 में चालू होने की प्रोसेस में कोई बदलाव नहीं होता, क्योंकि अपवाद:

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

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

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

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

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

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

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

दूसरा विकल्प (a): खास आपके लिए और A/B खाते का डेटा वापस पाने के लिए सेगमेंट

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

AB_OTA_PARTITIONS += recovery

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

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

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

recovery के रैम डिस्क में, डेटा वापस पाने के लिए सभी संसाधन मौजूद हैं. ऐसे डिवाइसों पर, प्रॉडक्ट कॉन्फ़िगरेशन इनहेरिट करता है 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 रैम डिस्क में /init -> /system/bin/init सिमलिंक हो सकता है, और /system/bin/init बजे init_second_stage.recovery. हालांकि, बूट रैम डिस्क को recovery रैम डिस्क के बाद जोड़ा गया है. /init सिमलिंक यह है ओवरराइट किया गया. डिवाइस के रिकवरी मोड में चालू होने पर, /system/bin/init दूसरे चरण के शुरुआत करने के लिए बाइनरी की ज़रूरत है.

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

  • /init (रैम डिस्क से, init_first_stage से बनाया गया)
  • /system/bin/init (recovery ramdisk से, इसे बनाया गया 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) के लिए ज़रूरी मॉड्यूल जोड़ने के लिए, चालू करें इन मॉड्यूल के vendor_ramdisk वैरिएंट को, काम के पैच अपलोड करके, एओएसपी चुनने के बाद, इनका इस्तेमाल करें,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

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

मेटाडेटा के काम करने का तरीका चेकसम पहले स्टेज को माउंट करने के दौरान, ऐसे डिवाइस जो 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. कर्नेल, ramdisk को / पर माउंट करता है. इसके बाद, जेनरिक रैम डिस्क से /init को लागू करता है.

  3. पहले चरण की शुरुआत होती है और इसके बाद ये काम किए जाते हैं:

    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, लेकिन कंप्रेस की गई वैल्यू नहीं है.

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

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

दूसरा विकल्प (b): रिकवरी के लिए खास और नॉन-A/B हिस्से का बीच

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

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

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

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

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

  • कर्नेल इमेज
  • DTBO इमेज
  • 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 ramdisk से, इसे बनाया गया 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 ramdisk का रूट मॉड्यूल इंस्टॉल करने के उदाहरण: vendor_ramdisk और recovery ramdisk, से पहले स्टेज का कंसोल और मेटाडेटा चेकसम के पास होता है.

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

मॉड्यूल का 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) के लिए ज़रूरी मॉड्यूल जोड़ने के लिए, चालू करें इन मॉड्यूल के 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 (जीकेआई) के साथ काम नहीं करते हैं, रैमडिस्क इंस्टॉल करते हैं दिए गए मॉड्यूल का एक वैरिएंट है. जीकेआई के साथ काम करने के लिए, मॉड्यूल को $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 इसे सामान्य बूट की तरह हैंडल करता है.

रिकवरी मोड में चालू करने पर, बूट करने की प्रोसेस में कोई बदलाव नहीं होता. रिकवरी ramdisk को मौजूदा रिकवरी प्रोसेस की तरह ही लोड किया जाता है. कर्नेल को 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 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 इमेज टाइमस्टैंप प्रॉपर्टी सेट करें.