জেনেরিক বুট পার্টিশন

অ্যান্ড্রয়েড 12-এ, জেনেরিক boot ইমেজ, যাকে জেনেরিক কার্নেল ইমেজ (GKI) বলা হয়, এতে জেনেরিক রামডিস্ক এবং GKI কার্নেল রয়েছে।

অ্যান্ড্রয়েড 13 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য, boot ইমেজ থেকে জেনেরিক র‌্যামডিস্ক সরিয়ে একটি পৃথক init_boot ইমেজে রাখা হয়। এই পরিবর্তন শুধুমাত্র GKI কার্নেলের সাথে boot ইমেজ ছেড়ে যায়।

Android 12 বা পুরানো কার্নেল সংস্করণগুলি ব্যবহার করা চালিয়ে যাওয়া ডিভাইসগুলিকে আপগ্রেড করার জন্য, জেনেরিক র্যামডিস্কটি সেখানেই রয়ে গেছে যেখানে এটি একটি নতুন init_boot চিত্রের প্রয়োজন ছাড়াই ছিল।

একটি জেনেরিক রামডিস্ক তৈরি করতে, বিক্রেতা-নির্দিষ্ট সংস্থানগুলিকে র‌্যামডিস্কের বাইরে নিয়ে যান যাতে জেনেরিক র‌্যামডিস্কে শুধুমাত্র প্রথম পর্যায়ের init এবং একটি প্রপার্টি ফাইল থাকে যাতে টাইমস্ট্যাম্প তথ্য থাকে।

ডিভাইসগুলিতে যা:

• একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করবেন না, সমস্ত রিকভারি বিট জেনেরিক রামডিস্ক থেকে vendor_boot ramdisk-এ চলে যায়।

• একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করুন, recovery র‍্যামডিস্কে কোনো পরিবর্তনের প্রয়োজন নেই কারণ recovery র‍্যামডিস্ক স্বয়ংসম্পূর্ণ।

স্থাপত্য

নিম্নলিখিত চিত্রগুলি Android 12 এবং উচ্চতর সংস্করণে চলমান ডিভাইসগুলির আর্কিটেকচারকে চিত্রিত করে৷ অ্যান্ড্রয়েড 13 এর সাথে লঞ্চ করা ডিভাইসে জেনেরিক রামডিস্ক ধারণকারী একটি নতুন init_boot ইমেজ রয়েছে। অ্যান্ড্রয়েড 12 থেকে অ্যান্ড্রয়েড 13 তে আপগ্রেড করা ডিভাইসগুলি একই আর্কিটেকচার ব্যবহার করে যেমনটি তারা Android 12 এর সাথে করেছিল।

Android 13 দিয়ে লঞ্চ করুন, কোনো ডেডিকেটেড রিকভারি নেই

চিত্র 1. GKI সহ Android 13 চালু করা বা আপগ্রেড করা ডিভাইস, কোনো ডেডিকেটেড পুনরুদ্ধার নেই।

অ্যান্ড্রয়েড 13, ডেডিকেটেড এবং এ/বি রিকভারি (ডেডিকেটেড রামডিস্ক) দিয়ে লঞ্চ করুন

চিত্র 2. GKI, ডেডিকেটেড এবং A/B পুনরুদ্ধার সহ Android 13-এ চালু বা আপগ্রেড করা ডিভাইস।

ডিভাইসটিতে recovery_a এবং recovery_b পার্টিশন থাকলে এই চিত্রটি দেখুন।

অ্যান্ড্রয়েড 13 দিয়ে লঞ্চ করুন, ডেডিকেটেড এবং নন-এ/বি রিকভারি (ডেডিকেটেড রামডিস্ক)

চিত্র 3. GKI, ডেডিকেটেড এবং নন-A/B পুনরুদ্ধার সহ Android 13-এ চালু বা আপগ্রেড করা ডিভাইস।

ডিভাইসটিতে স্লট প্রত্যয় ছাড়া recovery নামে একটি পার্টিশন থাকলে এই চিত্রটি দেখুন।

Android 12 চালু করুন বা আপগ্রেড করুন, কোনো ডেডিকেটেড রিকভারি নেই

চিত্র 4. GKI সহ Android 12-এ চালু বা আপগ্রেড করা ডিভাইস, কোনো ডেডিকেটেড রিকভারি নেই।

Android 12, ডেডিকেটেড এবং A/B রিকভারিতে লঞ্চ বা আপগ্রেড করুন (ডেডিকেটেড রামডিস্ক)

চিত্র 5. ডিভাইসগুলি GKI, ডেডিকেটেড এবং A/B পুনরুদ্ধার সহ Android 12-এ চালু বা আপগ্রেড হচ্ছে।

ডিভাইসটিতে recovery_a এবং recovery_b পার্টিশন থাকলে এই চিত্রটি দেখুন।

Android 12-এ লঞ্চ বা আপগ্রেড করুন, ডেডিকেটেড এবং নন-A/B রিকভারি (ডেডিকেটেড রামডিস্ক)

চিত্র 6. GKI, ডেডিকেটেড এবং নন-A/B পুনরুদ্ধার সহ Android 12-এ চালু বা আপগ্রেড করা ডিভাইস।

ডিভাইসটিতে স্লট প্রত্যয় ছাড়া recovery নামে একটি পার্টিশন থাকলে এই চিত্রটি দেখুন।

Android 12-এ আপগ্রেড করুন, রিকভারি-এ-বুট (পুনরুদ্ধার-এ-রামডিস্ক)

চিত্র 7. Android 12-এ আপগ্রেড করা ডিভাইস, GKI নেই, রিকভারি-অ্যাজ-বুট।

Android 12-এ আপগ্রেড করুন, ডেডিকেটেড রিকভারি (ডেডিকেটেড রামডিস্ক)

চিত্র 8. ডিভাইসগুলি Android 12-এ আপগ্রেড হচ্ছে, GKI নেই, ডেডিকেটেড পুনরুদ্ধার।

বুট ইমেজ বিষয়বস্তু

অ্যান্ড্রয়েড বুট ইমেজ নিম্নলিখিত আছে.

• 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 রামডিস্ক ইমেজ
    • পুনরুদ্ধার সম্পদ
    • নন-A/B পুনরুদ্ধার পার্টিশনের জন্য, রামডিস্কের বিষয়বস্তু স্বতন্ত্র হতে হবে; রিকভারি ইমেজ দেখুন। যেমন:
    • lib/modules রিকভারি মোড বুট করার জন্য প্রয়োজনীয় সমস্ত কার্নেল মডিউল থাকা আবশ্যক
    • পুনরুদ্ধার রামডিস্কে অবশ্যই init থাকতে হবে।
    • A/B রিকভারি পার্টিশনের জন্য, রিকভারি র‍্যামডিস্ককে জেনেরিক এবং vendor_boot র‍্যামডিস্কের সাথে যুক্ত করা হয়, তাই এটিকে স্বতন্ত্র হওয়ার প্রয়োজন নেই। যেমন:
    • lib/modules vendor_boot ramdisk-এ কার্নেল মডিউল ছাড়াও রিকভারি মোড বুট করার জন্য প্রয়োজনীয় অতিরিক্ত কার্নেল মডিউল থাকতে পারে।
    • /init এ সিমলিংক বিদ্যমান থাকতে পারে, কিন্তু বুট ইমেজে প্রথম-পর্যায়ের /init বাইনারি দ্বারা এটিকে ছাপানো হয়েছে।

জেনেরিক রামডিস্ক ইমেজ বিষয়বস্তু

জেনেরিক রামডিস্কে নিম্নলিখিত উপাদান রয়েছে।

• init
• system/etc/ramdisk/build.prop
• ro. PRODUCT .bootimg.* build প্রপস
• মাউন্ট পয়েন্টের জন্য খালি ডিরেক্টরি: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/
• first_stage_ramdisk/
  • মাউন্ট পয়েন্টের জন্য নকল করা খালি ডিরেক্টরি: debug_ramdisk/ , mnt/ , dev/ , sys/ , proc/ , metadata/

বুট ইমেজ ইন্টিগ্রেশন

init_boot , boot , recovery , এবং vendor_boot ইমেজ কিভাবে তৈরি করা হয় তা বিল্ড পতাকা নিয়ন্ত্রণ করে। একটি বুলিয়ান বোর্ড ভেরিয়েবলের মান অবশ্যই স্ট্রিং true বা খালি হতে হবে (যা ডিফল্ট)।

• TARGET_NO_KERNEL এই ভেরিয়েবলটি নির্দেশ করে যে বিল্ডটি একটি প্রি-বিল্ট বুট ইমেজ ব্যবহার করে কিনা। যদি এই ভেরিয়েবলটি true সেট করা হয়, তাহলে BOARD_PREBUILT_BOOTIMAGE পূর্বনির্মাণ বুট চিত্রের অবস্থানে সেট করুন ( BOARD_PREBUILT_BOOTIMAGE:= device/${company}/${board}/boot.img )

• BOARD_USES_RECOVERY_AS_BOOT । এই ভেরিয়েবলটি নির্দেশ করে যে ডিভাইসটি boot ইমেজ হিসেবে recovery ইমেজ ব্যবহার করে কিনা। GKI ব্যবহার করার সময়, এই ভেরিয়েবলটি খালি থাকে এবং পুনরুদ্ধারের সংস্থান vendor_boot এ সরানো উচিত।

• BOARD_USES_GENERIC_KERNEL_IMAGE এই পরিবর্তনশীলটি নির্দেশ করে যে বোর্ড GKI ব্যবহার করে। এই ভেরিয়েবলটি sysprops বা PRODUCT_PACKAGES প্রভাবিত করে না।

  এটি বোর্ড-স্তরের GKI সুইচ; নিম্নলিখিত সমস্ত ভেরিয়েবল এই ভেরিয়েবল দ্বারা সীমাবদ্ধ।

• BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT । ramdisk রিকভারি রিসোর্স 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 এ তৈরি করা হয়েছে।

    • সেট করা নেই, GSI AVB কী $ANDROID_PRODUCT_OUT/vendor-ramdisk/avb এ তৈরি করা হয়েছে।

  • খালি হলে, যদি BOARD_RECOVERY_AS_ROOT :

    • সেট করা হয়েছে, GSI AVB কী $ANDROID_PRODUCT_OUT/recovery/root/first_stage_ramdisk/avb এ তৈরি করা হয়েছে।

    • সেট করা নেই, GSI 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 এ জেনেরিক ramdisk যোগ করা হয় এবং চেইনড vbmeta-এর জন্য BOARD_AVB_INIT_BOOT* ভেরিয়েবল সেট করা প্রয়োজন।

অনুমোদিত সমন্বয়

একটি ডেডিকেটেড recovery পার্টিশন সহ ডিভাইসগুলি PRODUCT_BUILD_RECOVERY_IMAGE কে true বা খালিতে সেট করতে পারে৷ এই ডিভাইসগুলির জন্য, যদি BOARD_RECOVERYIMAGE_PARTITION_SIZE সেট করা থাকে, একটি recovery চিত্র তৈরি করা হয়৷

বুটের জন্য চেইনড vbmeta সক্ষম করুন

boot এবং init_boot ইমেজের জন্য চেইনড vbmeta অবশ্যই সক্রিয় করা আবশ্যক। নিম্নলিখিত উল্লেখ করুন:

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

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

একটি উদাহরণের জন্য, এই পরিবর্তন পড়ুন.

সিস্টেম-হিসেবে-রুট

GKI ব্যবহার করে এমন ডিভাইসগুলির জন্য সিস্টেম-এ-রুট সমর্থিত নয়। এই ধরনের ডিভাইসে, BOARD_BUILD_SYSTEM_ROOT_IMAGE খালি থাকতে হবে। সিস্টেম-অ্যাজ-রুট এমন ডিভাইসগুলির জন্যও সমর্থিত নয় যেগুলি গতিশীল পার্টিশন ব্যবহার করে।

পণ্য কনফিগারেশন

যে ডিভাইসগুলি জেনেরিক রামডিস্ক ব্যবহার করে তাদের অবশ্যই র্যামডিস্কে ইনস্টল করার অনুমতি দেওয়া ফাইলগুলির একটি তালিকা ইনস্টল করতে হবে। এটি করার জন্য, device.mk এ নিম্নলিখিতটি উল্লেখ করুন:

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

generic_ramdisk.mk ফাইলটি অন্যান্য মেকফাইলগুলিকে ভুলবশত রামডিস্কে অন্যান্য ফাইল ইনস্টল করা থেকেও বাধা দেয় (এর পরিবর্তে এই ধরনের ফাইলগুলিকে vendor_ramdisk এ সরান)।

ডিভাইস সেট আপ করুন

অ্যান্ড্রয়েড 13 এর সাথে লঞ্চ হওয়া, অ্যান্ড্রয়েড 12-তে আপগ্রেড করা এবং অ্যান্ড্রয়েড 12-এর সাথে লঞ্চ করা ডিভাইসগুলির মধ্যে সেটআপ নির্দেশাবলী আলাদা। অ্যান্ড্রয়েড 13, অ্যান্ড্রয়েড 12 এর সাথে যেমন ছিল সেরকমই সেটআপ।

• ডিভাইসগুলি Android 12 এ আপগ্রেড হচ্ছে:

  • BOARD_USES_RECOVERY_AS_BOOT এর মান সংরক্ষণ করতে পারে। যদি তারা তা করে তবে তারা লিগ্যাসি কনফিগারেশন ব্যবহার করছে এবং নতুন বিল্ড ভেরিয়েবল অবশ্যই খালি হতে হবে। যদি এই ধরনের ডিভাইস:

    • BOARD_USES_RECOVERY_AS_BOOT true সেট করুন, স্থাপত্যটি চিত্র 3 -এ দেখানো হয়েছে।

    • BOARD_USES_RECOVERY_AS_BOOT খালিতে সেট করুন, আর্কিটেকচারটি চিত্র 4 হিসাবে দেখানো হয়েছে।

  • BOARD_USES_RECOVERY_AS_BOOT খালি সেট করতে পারেন৷ যদি তারা তা করে তবে তারা নতুন কনফিগারেশন ব্যবহার করছে। যদি এই ধরনের ডিভাইস:

    • একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করবেন না, আর্কিটেকচারটি চিত্র 1- এ দেখানো হয়েছে এবং ডিভাইস সেটআপ বিকল্পটি হল বিকল্প 1 ।

    • একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করুন, আর্কিটেকচারটি চিত্র 2a বা চিত্র 2b তে দেখানো হয়েছে এবং ডিভাইস সেটআপ বিকল্পটি হল বিকল্প 2a বা বিকল্প 2b ।

• Android 12 এর সাথে চালু হওয়া ডিভাইসগুলিকে অবশ্যই BOARD_USES_RECOVERY_AS_BOOT খালি করতে সেট করতে হবে এবং নতুন কনফিগারেশন ব্যবহার করতে হবে। যদি এই ধরনের ডিভাইস:

  • একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করবেন না, আর্কিটেকচারটি চিত্র 1- এ দেখানো হয়েছে এবং ডিভাইস সেটআপ বিকল্পটি হল বিকল্প 1 ।

  • একটি ডেডিকেটেড recovery পার্টিশন ব্যবহার করুন, আর্কিটেকচারটি চিত্র 2a বা চিত্র 2b তে দেখানো হয়েছে এবং ডিভাইস সেটআপ বিকল্পটি হল বিকল্প 2a বা বিকল্প 2b ।

কারণ aosp_arm64 শুধুমাত্র GKI তৈরি করে (এবং vendor_boot বা পুনরুদ্ধার নয়), এটি একটি সম্পূর্ণ লক্ষ্য নয়। aosp_arm64 বিল্ড কনফিগারেশনের জন্য, generic_arm64 পড়ুন।

বিকল্প 1: কোনো ডেডিকেটেড রিকভারি পার্টিশন নেই

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 ramdisk-এ /init থেকে /system/bin/init symlink, এবং /system/bin/init এ init_second_stage.recovery থাকতে পারে। যাইহোক, যেহেতু জেনেরিক রামডিস্ক vendor_boot ramdisk-এর পরে সংযুক্ত করা হয়, তাই /init সিমলিংকটি ওভাররাইট করা হয়। ডিভাইস পুনরুদ্ধারে বুট হলে, দ্বিতীয় পর্যায়ের init সমর্থন করার জন্য /system/bin/init বাইনারি প্রয়োজন। vendor_boot + জেনেরিক রামডিস্কের বিষয়বস্তু নিম্নরূপ:

• /init (জেনেরিক রামডিস্ক থেকে, init_first_stage থেকে নির্মিত)
• /system/bin/init ( vendor_ramdisk থেকে, init_second_stage.recovery থেকে নির্মিত)

fstab ফাইলগুলি সরান

জেনেরিক ramdisk-এ ইনস্টল করা fstab ফাইল vendor_ramdisk এ সরান। একটি উদাহরণের জন্য, এই পরিবর্তন পড়ুন.

মডিউল ইনস্টল করুন

আপনি vendor_ramdisk এ ডিভাইস-নির্দিষ্ট মডিউল ইনস্টল করতে পারেন (যদি আপনার ইনস্টল করার জন্য কোনো ডিভাইস-নির্দিষ্ট মডিউল না থাকে তবে এই ধাপটি এড়িয়ে যান)।

• মডিউলটি /first_stage_ramdisk এ ইনস্টল করার সময় মডিউলটির vendor_ramdisk ভেরিয়েন্ট ব্যবহার করুন। init রুটকে /first_stage_ramdisk এ বদল করার পরে এই মডিউলটি পাওয়া উচিত কিন্তু init রুটকে /system এ বদল করার আগে। উদাহরণের জন্য, মেটাডেটা চেকসাম এবং ভার্চুয়াল A/B কম্প্রেশন দেখুন।

• মডিউলটি / তে ইনস্টল করার সময় মডিউলটির recovery ভেরিয়েন্ট ব্যবহার করুন। init রুটকে /first_stage_ramdisk এ পরিবর্তন করার আগে এই মডিউলটি পাওয়া উচিত। / -এ মডিউল ইনস্টল করার বিস্তারিত জানার জন্য, প্রথম পর্যায়ের কনসোল দেখুন।

প্রথম পর্যায়ে কনসোল

কারণ init রুটকে /first_stage_ramdisk এ পরিবর্তন করার আগে প্রথম পর্যায়ের কনসোল শুরু হয়, আপনাকে মডিউলের recovery বৈকল্পিক ইনস্টল করতে হবে। ডিফল্টরূপে, উভয় মডিউল ভেরিয়েন্ট build/make/target/product/base_vendor.mk এর জন্য ইনস্টল করা হয়, তাই যদি ডিভাইস মেকফাইলটি সেই ফাইল থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হয় তবে আপনাকে স্পষ্টভাবে recovery ভেরিয়েন্টটি ইনস্টল করতে হবে না।

পুনরুদ্ধার মডিউলগুলি স্পষ্টভাবে ইনস্টল করতে, নিম্নলিখিতটি ব্যবহার করুন।

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \

এটি নিশ্চিত করে যে linker , sh , এবং toybox $ANDROID_PRODUCT_OUT/recovery/root/system/bin এ ইনস্টল করা হয়েছে, যা তারপর vendor_ramdisk অধীনে /system/bin এ ইনস্টল করে।

প্রথম পর্যায়ের কনসোলের জন্য প্রয়োজনীয় মডিউল যোগ করতে (উদাহরণস্বরূপ, adbd), নিম্নলিখিতটি ব্যবহার করুন।

PRODUCT_PACKAGES += adbd.recovery

এটি নিশ্চিত করে যে নির্দিষ্ট মডিউলগুলি $ANDROID_PRODUCT_OUT/recovery/root/system/bin এ ইনস্টল করা হয়েছে, যা তারপর vendor_ramdisk অধীনে /system/bin এ ইনস্টল করে।

মেটাডেটা চেকসাম

প্রথম পর্যায়ে মাউন্ট করার সময় মেটাডেটা চেকসাম সমর্থন করতে, যে ডিভাইসগুলি GKI সমর্থন করে না সেগুলি নিম্নলিখিত মডিউলগুলির রামডিস্ক ভেরিয়েন্ট ইনস্টল করে। GKI-এর জন্য সমর্থন যোগ করতে, মডিউলগুলিকে $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin এ সরান:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    resize2fs.vendor_ramdisk \
    tune2fs.vendor_ramdisk \

একটি উদাহরণের জন্য, এই পরিবর্তন তালিকা পড়ুন।

ভার্চুয়াল A/B কম্প্রেশন

ভার্চুয়াল A/B কম্প্রেশন সমর্থন করতে, snapuserd অবশ্যই vendor_ramdisk এ ইনস্টল করতে হবে। ডিভাইসটি virtual_ab_ota/compression.mk থেকে ইনহেরিট করা উচিত, যা snapuserd এর vendor_ramdisk ভেরিয়েন্ট ইনস্টল করে।

বুট প্রক্রিয়া পরিবর্তন

পুনরুদ্ধার বা অ্যান্ড্রয়েডে বুট করার প্রক্রিয়া নিম্নলিখিত ব্যতিক্রমগুলি ছাড়া পরিবর্তিত হয় না:

• Ramdisk build.prop /second_stage_resources এ চলে যায় যাতে দ্বিতীয় পর্যায়ের init বুটের বিল্ড টাইমস্ট্যাম্প পড়তে পারে।

যেহেতু সম্পদগুলি জেনেরিক র‌্যামডিস্ক থেকে vendor_boot র‌্যামডিস্কে চলে যায়, জেনেরিক র‌্যামডিস্ককে vendor_boot র‌্যামডিস্কে সংযুক্ত করার ফলাফল পরিবর্তন হয় না।

e2fsck উপলব্ধ করুন

ডিভাইস মেকফাইলগুলি এর থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হতে পারে:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk যদি ডিভাইসটি ভার্চুয়াল A/B সমর্থন করে কিন্তু কম্প্রেশন না করে।

• virtual_ab_ota/compression.mk যদি ডিভাইসটি ভার্চুয়াল A/B কম্প্রেশন সমর্থন করে।

পণ্যের মেকফাইল $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck ইনস্টল করে। রানটাইমে, প্রথম পর্যায়ে init রুটকে /first_stage_ramdisk এ পরিবর্তন করে তারপর /system/bin/e2fsck চালায়।

বিকল্প 2a: ডেডিকেটেড এবং A/B রিকভারি পার্টিশন

A/B recovery পার্টিশন সহ ডিভাইসগুলির জন্য এই বিকল্পটি ব্যবহার করুন; অর্থাৎ, ডিভাইসটিতে একটি recovery_a এবং recovery_b partition রয়েছে। এই ধরনের ডিভাইসগুলির মধ্যে A/B এবং ভার্চুয়াল A/B ডিভাইস রয়েছে যেগুলির পুনরুদ্ধার পার্টিশন নিম্নলিখিত কনফিগারেশন সহ আপডেটযোগ্য:

AB_OTA_PARTITIONS += recovery

vendor_boot ramdisk-এ ramdisk এবং ভেন্ডর কার্নেল মডিউলগুলির ভেন্ডর বিট রয়েছে, যার মধ্যে নিম্নলিখিতগুলি রয়েছে:

• ডিভাইস-নির্দিষ্ট fstab ফাইল

• lib/modules (বিক্রেতা কার্নেল মডিউল অন্তর্ভুক্ত)

recovery রামডিস্কে সমস্ত পুনরুদ্ধারের সংস্থান রয়েছে। এই ধরনের ডিভাইসে, পণ্য কনফিগারেশন generic_ramdisk.mk থেকে উত্তরাধিকারসূত্রে পাওয়া যায় ।

BOARD মান সেট করুন

A/B recovery পার্টিশন সহ ডিভাইসগুলির জন্য নিম্নলিখিত মানগুলি সেট করুন:

BOARD_USES_RECOVERY_AS_BOOT :=
BOARD_USES_GENERIC_KERNEL_IMAGE := true
BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT :=
BOARD_EXCLUDE_KERNEL_FROM_RECOVERY_IMAGE := true
BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT := true

Init বাইনারি এবং সিমলিংক

recovery ramdisk-এ একটি /init -> /system/bin/init symlink এবং /system/bin/init এ init_second_stage.recovery থাকতে পারে। যাইহোক, যেহেতু বুট রামডিস্ক recovery রামডিস্কের পরে সংযুক্ত করা হয়েছে, তাই /init সিমলিংকটি ওভাররাইট করা হয়েছে। ডিভাইস রিকভারি মোডে বুট হলে, দ্বিতীয় পর্যায়ের init সমর্থন করার জন্য /system/bin/init বাইনারি প্রয়োজন।

যখন ডিভাইসটি recovery বুট হয়, তখন recovery + vendor_boot + জেনেরিক রামডিস্কের বিষয়বস্তু নিম্নরূপ:

• /init (রামডিস্ক থেকে, init_first_stage থেকে নির্মিত)
• /system/bin/init ( recovery ramdisk থেকে, init_second_stage.recovery থেকে নির্মিত, এবং /init থেকে কার্যকর করা হয়েছে)

যখন ডিভাইসটি অ্যান্ড্রয়েডে বুট হয়, vendor_boot + জেনেরিক রামডিস্কের বিষয়বস্তু নিম্নরূপ:

• /init (জেনেরিক রামডিস্ক থেকে, init_first_stage থেকে নির্মিত)

fstab ফাইলগুলি সরান

জেনেরিক ramdisk-এ ইনস্টল করা 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 ramdisk রিকভারি মোডে লোড না হয়, তাহলে ডিভাইসটি ঐচ্ছিকভাবে 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 ভেরিয়েন্ট ইনস্টল করে।

বুট প্রক্রিয়া পরিবর্তন

অ্যান্ড্রয়েডে বুট করার সময়, বুট প্রক্রিয়া পরিবর্তন হয় না। vendor_boot + জেনেরিক ramdisk বিদ্যমান বুট প্রক্রিয়ার অনুরূপ, fstab vendor_boot থেকে লোড হওয়া ছাড়া। যেহেতু system/bin/recovery বিদ্যমান নেই, first_stage_init এটি একটি সাধারণ বুট হিসাবে পরিচালনা করে।

পুনরুদ্ধার মোডে বুট করার সময়, বুট প্রক্রিয়া পরিবর্তন হয়। recovery + vendor_boot + generic ramdisk বিদ্যমান পুনরুদ্ধার প্রক্রিয়ার অনুরূপ, কিন্তু কার্নেলটি recovery চিত্রের পরিবর্তে boot ইমেজ থেকে লোড করা হয়। পুনরুদ্ধার মোডের বুট প্রক্রিয়াটি নিম্নরূপ।

1. বুটলোডার শুরু হয়, তারপর নিম্নলিখিতগুলি করে:

   1. পুনরুদ্ধার + vendor_boot + জেনেরিক রামডিস্ককে / এ ঠেলে দেয়। (যদি OEM BOARD_RECOVERY_KERNEL_MODULES এ যোগ করে পুনরুদ্ধার র‌্যামডিস্কে কার্নেল মডিউলের নকল করে), vendor_boot ঐচ্ছিক।)
   2. boot পার্টিশন থেকে কার্নেল চালায়।

2. কার্নেল ramdisk-এ মাউন্ট করে / তারপর জেনেরিক ramdisk থেকে /init চালায়।

3. প্রথম পর্যায়ে init শুরু হয়, তারপর নিম্নলিখিতগুলি করে:

   1. IsRecoveryMode() == true এবং ForceNormalBoot() == false সেট করে।
   2. /lib/modules থেকে ভেন্ডর কার্নেল মডিউল লোড করে।
   3. DoFirstStageMount() কল করে কিন্তু মাউন্ট করা এড়িয়ে যায় কারণ IsRecoveryMode() == true । (ডিভাইসটি র‍্যামডিস্ককে মুক্ত করে না (কারণ / এখনও একই) কিন্তু SetInitAvbVersionInRecovery() কল করে।)
   4. recovery রামডিস্ক থেকে /system/bin/init থেকে দ্বিতীয় পর্যায়ের init শুরু করে।

e2fsck উপলব্ধ করুন

ডিভাইস মেকফাইলগুলি এর থেকে উত্তরাধিকার সূত্রে প্রাপ্ত হতে পারে:

• virtual_ab_ota/launch_with_vendor_ramdisk.mk যদি ডিভাইসটি ভার্চুয়াল A/B সমর্থন করে কিন্তু কম্প্রেশন না করে।

• virtual_ab_ota/compression.mk যদি ডিভাইসটি ভার্চুয়াল A/B কম্প্রেশন সমর্থন করে।

পণ্যের মেকফাইল $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck ইনস্টল করে। রানটাইমে, প্রথম পর্যায়ের init /system/bin/e2fsck চালায়।

বিকল্প 2b: ডেডিকেটেড এবং নন-A/B রিকভারি পার্টিশন

একটি নন-A/B recovery পার্টিশন সহ ডিভাইসগুলির জন্য এই বিকল্পটি ব্যবহার করুন; অর্থাৎ, ডিভাইসটিতে একটি স্লট প্রত্যয় ছাড়াই recovery নামে একটি পার্টিশন রয়েছে। এই ধরনের ডিভাইস অন্তর্ভুক্ত:

• নন-এ/বি ডিভাইস;
• A/B এবং ভার্চুয়াল A/B ডিভাইস, যার মধ্যে রিকভারি পার্টিশন আপডেট করা যায় না। (এটি অস্বাভাবিক।)

vendor_boot ramdisk-এ ramdisk এবং ভেন্ডর কার্নেল মডিউলগুলির ভেন্ডর বিট রয়েছে, যার মধ্যে নিম্নলিখিতগুলি রয়েছে:

• ডিভাইস-নির্দিষ্ট fstab ফাইল
• lib/modules (বিক্রেতা কার্নেল মডিউল অন্তর্ভুক্ত)

recovery চিত্রটি অবশ্যই স্বয়ংসম্পূর্ণ হতে হবে। পুনরুদ্ধার মোড বুট করার জন্য এটিতে অবশ্যই সমস্ত প্রয়োজনীয় সংস্থান থাকতে হবে, সহ:

• কার্নেল ইমেজ
• DTBO চিত্র
• lib/modules কার্নেল মডিউল
• প্রথম পর্যায়ের init একটি symlink /init -> /system/bin/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 symlink এবং /system/bin/init এ init_second_stage.recovery থাকতে হবে। ডিভাইস পুনরুদ্ধার মোডে বুট হলে, প্রথম পর্যায় এবং দ্বিতীয় পর্যায়ের init উভয় সমর্থন করার জন্য /system/bin/init বাইনারি প্রয়োজন।

যখন ডিভাইসটি recovery বুট হয়, তখন recovery র‍্যামডিস্কের বিষয়বস্তু নিম্নরূপ:

• /init -> /system/bin/init ( recovery রামডিস্ক থেকে)
• /system/bin/init ( recovery ramdisk থেকে, init_second_stage.recovery থেকে নির্মিত, এবং /init থেকে কার্যকর করা হয়েছে)

যখন ডিভাইসটি অ্যান্ড্রয়েডে বুট হয়, vendor_boot + জেনেরিক রামডিস্কের বিষয়বস্তু নিম্নরূপ:

• /init (রামডিস্ক থেকে, init_first_stage থেকে নির্মিত)

fstab ফাইলগুলি সরান

জেনেরিক ramdisk-এ ইনস্টল করা fstab ফাইল vendor_ramdisk এবং recovery ramdisk-এ সরান। একটি উদাহরণের জন্য, এই পরিবর্তন পড়ুন.

মডিউল ইনস্টল করুন

আপনি 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 \

এটি নিশ্চিত করে যে linker , sh , এবং toybox $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin এ ইনস্টল করা হয়েছে, যা তারপর vendor_ramdisk অধীনে /system/bin এ ইনস্টল করে।

প্রথম পর্যায়ের কনসোলের জন্য প্রয়োজনীয় মডিউল যোগ করতে (উদাহরণস্বরূপ, adbd), AOSP-তে প্রাসঙ্গিক প্যাচ আপলোড করে এই মডিউলগুলির vendor_ramdisk বৈকল্পিক সক্ষম করুন, তারপর নিম্নলিখিতগুলি ব্যবহার করুন,

PRODUCT_PACKAGES += adbd.vendor_ramdisk

এটি নিশ্চিত করে যে নির্দিষ্ট মডিউলগুলি $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin এ ইনস্টল হবে।

মডিউলগুলির recovery ভেরিয়েন্ট ইনস্টল করতে, recovery দিয়ে vendor_ramdisk প্রতিস্থাপন করুন:

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 \

পুনরুদ্ধারের প্রথম পর্যায়ে মাউন্ট করার সময় মেটাডেটা চেকসাম সমর্থন করতে, এই মডিউলগুলির পুনরুদ্ধার বৈকল্পিক সক্রিয় করুন এবং সেগুলিও ইনস্টল করুন।

বুট প্রক্রিয়া পরিবর্তন

অ্যান্ড্রয়েডে বুট করার সময়, বুট প্রক্রিয়া পরিবর্তন হয় না। vendor_boot + জেনেরিক ramdisk বিদ্যমান বুট প্রক্রিয়ার অনুরূপ, fstab vendor_boot থেকে লোড করা ছাড়া। যেহেতু system/bin/recovery বিদ্যমান নেই, first_stage_init এটি একটি সাধারণ বুট হিসাবে পরিচালনা করে।

পুনরুদ্ধার মোডে বুট করার সময়, বুট প্রক্রিয়া পরিবর্তন হয় না। পুনরুদ্ধার রামডিস্ক বিদ্যমান পুনরুদ্ধার প্রক্রিয়ার মতো একইভাবে লোড করা হয়। recovery চিত্র থেকে কার্নেল লোড করা হয়। পুনরুদ্ধার মোডের বুট প্রক্রিয়াটি নিম্নরূপ।

1. বুটলোডার শুরু হয়, তারপর নিম্নলিখিতগুলি করে:

   1. পুনরুদ্ধার রামডিস্ককে / এ ঠেলে দেয়।
   2. recovery পার্টিশন থেকে কার্নেল চালায়।

2. কার্নেল ramdisk-এ মাউন্ট করে / তারপর /init চালায়, যা recovery ramdisk থেকে /system/bin/init এর একটি সিমলিঙ্ক।

3. প্রথম পর্যায়ে init শুরু হয়, তারপর নিম্নলিখিতগুলি করে:

   1. IsRecoveryMode() == true এবং ForceNormalBoot() == false সেট করে।
   2. /lib/modules থেকে ভেন্ডর কার্নেল মডিউল লোড করে।
   3. DoFirstStageMount() কল করে কিন্তু মাউন্ট করা এড়িয়ে যায় কারণ IsRecoveryMode() == true । (ডিভাইসটি র‍্যামডিস্ককে মুক্ত করে না (কারণ / এখনও একই) কিন্তু SetInitAvbVersionInRecovery() কল করে।)
   4. recovery রামডিস্ক থেকে /system/bin/init থেকে দ্বিতীয় পর্যায়ের init শুরু করে।

বুট ইমেজ টাইমস্ট্যাম্প

নিম্নলিখিত কোড হল একটি উদাহরণ boot ইমেজ টাইমস্ট্যাম্প ফাইল:

####################################
# from generate-common-build-props
# These properties identify this partition image.
####################################
ro.product.bootimage.brand=Android
ro.product.bootimage.device=generic_arm64
ro.product.bootimage.manufacturer=unknown
ro.product.bootimage.model=AOSP on ARM64
ro.product.bootimage.name=aosp_arm64
ro.bootimage.build.date=Mon Nov 16 22:46:27 UTC 2020
ro.bootimage.build.date.utc=1605566787
ro.bootimage.build.fingerprint=Android/aosp_arm64/generic_arm64:S/MASTER/6976199:userdebug/test-keys
ro.bootimage.build.id=MASTER
ro.bootimage.build.tags=test-keys
ro.bootimage.build.type=userdebug
ro.bootimage.build.version.incremental=6976199
ro.bootimage.build.version.release=11
ro.bootimage.build.version.release_or_codename=S
ro.bootimage.build.version.sdk=30
# Auto-added by post_process_props.py
persist.sys.usb.config=none
# end of file

• নির্মাণের সময়, একটি system/etc/ramdisk/build.prop ফাইল জেনেরিক রামডিস্কে যোগ করা হয়। এই ফাইলটিতে বিল্ডের টাইমস্ট্যাম্প তথ্য রয়েছে।

• রানটাইমে, ramdisk মুক্ত করার আগে প্রথম পর্যায়ে init ফাইলগুলিকে ramdisk থেকে tmpfs এ কপি করে যাতে দ্বিতীয় পর্যায়ের init boot ইমেজ টাইমস্ট্যাম্প বৈশিষ্ট্য সেট করতে এই ফাইলটি পড়তে পারে।