इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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, कोई खास रिकवरी नहीं

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

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

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

दूसरी इमेज. ऐसे डिवाइस जो Android 13 पर लॉन्च किए जा रहे हैं या जिनमें 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 पर लॉन्च होने वाले या अपग्रेड होने वाले डिवाइस, जिनमें खास तौर पर रिकवरी मोड नहीं है.

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

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

पांचवीं इमेज. ऐसे डिवाइस जो Android 12 पर लॉन्च किए जा रहे हैं या जिनमें 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
- सामान्य रैमडिस्क इमेज
जेनरिक 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 से जोड़ा गया है.
  - DTBO का अनुमान, vendor_boot हेडर से लगाया जा सकता है.
- recovery ramdisk इमेज
  - खाता वापस पाने के लिए संसाधन
  - गैर-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 का इस्तेमाल करता है. यह वैरिएबल साइप्रोप या 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:
  - सेट है, तो जीएसआई एवीबी कुंजियां $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* वैरिएबल सेट करने की ज़रूरत होती है.

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

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

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

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

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

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

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

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

System-as-root

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

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 के लिए सहायता जोड़ने के लिए, मॉड्यूल को $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 को उपलब्ध कराना

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

अगर डिवाइस पर वर्चुअल A/B काम करता है, लेकिन कंप्रेस करने की सुविधा नहीं है, तो virtual_ab_ota/launch_with_vendor_ramdisk.mk.
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. रिकवरी + vendor_boot + जेनरिक रैम डिस्क को / पर पुश करता है. (अगर OEM, रिकवरी रैम डिस्क में कर्नेल मॉड्यूल को BOARD_RECOVERY_KERNEL_MODULES में जोड़कर डुप्लीकेट करता है), तो vendor_boot का इस्तेमाल करना ज़रूरी नहीं है.
2. boot पार्टीशन से कर्नेल चलाता है.
कर्नेल, ramdisk को / पर माउंट करता है. इसके बाद, जेनरिक ramdisk से /init को चलाता है.
पहला चरण शुरू होने के बाद, ये काम किए जाते हैं:
1. IsRecoveryMode() == true और ForceNormalBoot() == false को सेट करता है.
2. /lib/modules से वेंडर के कर्नेल मॉड्यूल लोड करता है.
3. DoFirstStageMount() को कॉल करता है, लेकिन IsRecoveryMode() == true की वजह से माउंट नहीं करता. (डिवाइस रैम डिस्क को खाली नहीं करता, क्योंकि / अब भी वही है) लेकिन SetInitAvbVersionInRecovery() को कॉल करता है.)
4. recovery ramdisk से /system/bin/init से दूसरा स्टेज शुरू करता है.

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

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

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

प्रॉडक्ट मेकफ़ाइलें, $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 डिवाइस, जिनके रिकवरी पार्टिशन को अपडेट नहीं किया जा सकता. (यह असामान्य है.)

डिवाइस के हिसाब से 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 से चलाया गया)

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

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

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

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

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

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

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

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_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. रिकवरी रैमडिस्क को / पर पुश करता है.
2. recovery पार्टीशन से कर्नेल चलाता है.
कर्नेल, रैमडिस्क को / पर माउंट करता है. इसके बाद, /init को चलाता है, जो recovery रैमडिस्क से /system/bin/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 इमेज के टाइमस्टैंप की प्रॉपर्टी सेट करने के लिए, इस फ़ाइल को रीड कर सकता है.