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 के साथ लॉन्च करें, लेकिन रिकवरी के लिए कोई खास ऐप नहीं
पहला डायग्राम. Android 13 वाले डिवाइसों में, GKI (जीकेआई) की मदद से, इसे लॉन्च या अपग्रेड किया जा रहा हो. इनमें, रिकवरी टूल का इस्तेमाल नहीं किया जा सकता.
Android 13 के साथ लॉन्च किया गया, खास सुविधाओं और A/B रिकवरी (खास तौर पर तय की गई रैम डिस्क)
दूसरा डायग्राम. Android 13 के साथ लॉन्च या अपग्रेड किए जाने वाले डिवाइस. इनमें GKI, खास तौर पर बनाई गई, और A/B रिकवरी की सुविधा होती है.
अगर डिवाइस में recovery_a
और recovery_b
पार्टिशन हैं, तो यह डायग्राम देखें.
Android 13 के साथ लॉन्च किया गया, खास तौर पर काम करने वाले और नॉन-A/B रिकवरी (खास तौर पर सेट की गई रैम डिस्क)
तीसरी इमेज. Android 13 पर लॉन्च या अपग्रेड किए जाने वाले डिवाइस, जिनमें GKI (डिजिटल सर्टिफ़िकेट मैनेज करने के तरीके) और नॉन-A/B रिकवरी की सुविधा हो.
अगर डिवाइस में recovery
नाम का कोई सेगमेंट है, तो यह इमेज देखें.
स्लॉट सफ़िक्स.
Android 12 में लॉन्च या अपग्रेड करें. हालांकि, रिकवरी के लिए कोई खास ऐप नहीं है
चौथी इमेज. Android 12 वाले डिवाइसों पर, GKI (जीकेआई) की सुविधा वाले डिवाइस, जिन्हें किसी खास तरीके से वापस पाने के लिए सेट नहीं किया गया है.
Android 12, खास तौर पर काम करने वाले और A/B रिकवरी (खास तौर पर रामडिस्क) पर अपग्रेड या लॉन्च करें
पांचवी इमेज. 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 बूट इमेज में ये चीज़ें शामिल होती हैं.
Android 13 के साथ लॉन्च होने वाले डिवाइसों के लिए
init_boot
इमेज जोड़ी गई- हेडर वर्शन V4
- सामान्य ramdisk इमेज
जेनरिक
boot
इमेज- हेडर वर्शन V3 या
वर्शन 4
- GKIboo.img सर्टिफ़िकेशन के लिए
boot_signature
(सिर्फ़ v4 वर्शन). कॉन्टेंट बनाने प्रमाणित GKIboot.img
को वेरिफ़ाइड बूट के लिए साइन नहीं किया गया है. OEM को यह करना चाहिए पहले से बनेboot.img
को किसी खास डिवाइस से साइन करें एवीबी बटन दबाएं. - सामान्य
cmdline
(GENERIC_KERNEL_CMDLINE
) - GKI कर्नेल
- GKIboo.img सर्टिफ़िकेशन के लिए
- सामान्य ramdisk इमेज
- Android 12 की सिर्फ़
boot
इमेज में शामिल है और पहले
- Android 12 की सिर्फ़
- हेडर वर्शन V3 या
वर्शन 4
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
बाइनरी.
- हेडर वर्शन V2
सामान्य 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/Brecovery
पार्टीशन का इस्तेमाल करने से इसे सेट करना होगा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
को खाली पर सेट कर सकते हैं. अगर वे ऐसा करते हैं, तो नए कॉन्फ़िगरेशन. अगर ऐसा है, तो:किसी खास
recovery
पार्टीशन का इस्तेमाल न करें. आर्किटेक्चर ऐसा दिखता है पहली इमेज में दिखाया गया है और डिवाइस के सेटअप के लिए, Option का विकल्प चुना गया है 1.खास तौर पर बना
recovery
पार्टीशन इस्तेमाल करें. आर्किटेक्चर यहां दिखाया गया है इमेज 2a या इमेज 2b और डिवाइस का सेटअप यह विकल्प विकल्प 2a या विकल्प 2b है.
Android 12 के साथ लॉन्च होने वाले डिवाइसों को सेट अप करना ज़रूरी है खाली करने और नए कॉन्फ़िगरेशन का इस्तेमाल करने के लिए
BOARD_USES_RECOVERY_AS_BOOT
. अगर ऐसा है डिवाइस:
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
इमेज से लोड किया जाता है.
रिकवरी मोड को चालू करने की प्रोसेस नीचे दी गई है.
बूटलोडर शुरू होने के बाद ये काम किए जाते हैं:
- रिकवरी +
vendor_boot
+ जेनरिक रैम डिस्क को/
पर पुश करता है. (अगर OEM रिकवरी रैम डिस्क में कर्नेल मॉड्यूल को जोड़कर डुप्लीकेट बना देता हैBOARD_RECOVERY_KERNEL_MODULES
),vendor_boot
ज़रूरी नहीं है.) boot
पार्टीशन से कर्नेल को चलाता है.
- रिकवरी +
कर्नेल, ramdisk को
/
पर माउंट करता है. इसके बाद, जेनरिक रैम डिस्क से/init
को लागू करता है.पहले चरण की शुरुआत होती है और इसके बाद ये काम किए जाते हैं:
IsRecoveryMode() == true
औरForceNormalBoot() == false
को सेट करता है./lib/modules
से वेंडर कर्नेल मॉड्यूल लोड करता है.DoFirstStageMount()
को कॉल करता है, लेकिन माउंट करना छोड़ देता है, क्योंकिIsRecoveryMode() == true
. (डिवाइस रैम डिस्क को मुक्त नहीं करता (क्योंकि/
वही है) लेकिनSetInitAvbVersionInRecovery()
को कॉल करता है.)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
इमेज से लोड किया जाता है. कॉन्टेंट बनाने
रिकवरी मोड चालू करने की प्रोसेस नीचे दी गई है.
बूटलोडर शुरू होने के बाद ये काम किए जाते हैं:
- रिकवरी रैम डिस्क को
/
पर पुश करता है. recovery
पार्टीशन से कर्नेल को चलाता है.
- रिकवरी रैम डिस्क को
कर्नेल,
/
पर रैम डिस्क को माउंट करता है. इसके बाद,/init
को लागू करता है, जो इससे जुड़ी एक सिमलिंक हैrecovery
रैमडिस्क से/system/bin/init
.पहले चरण की शुरुआत होती है और इसके बाद ये काम किए जाते हैं:
IsRecoveryMode() == true
औरForceNormalBoot() == false
को सेट करता है./lib/modules
से वेंडर कर्नेल मॉड्यूल लोड करता है.DoFirstStageMount()
को कॉल करता है, लेकिन माउंट करना छोड़ देता है, क्योंकिIsRecoveryMode() == true
. (डिवाइस रैम डिस्क को मुक्त नहीं करता (क्योंकि/
वही है) लेकिनSetInitAvbVersionInRecovery()
को कॉल करता है.)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
इमेज टाइमस्टैंप प्रॉपर्टी सेट करें.