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

অ্যান্ড্রয়েড ১২-এ, জেনেরিক boot ইমেজ, যা জেনেরিক কার্নেল ইমেজ (GKI) নামে পরিচিত, তাতে জেনেরিক র‍্যামডিস্ক এবং GKI কার্নেল থাকে।

যেসব ডিভাইস অ্যান্ড্রয়েড ১৩ সহ বাজারে আসছে, সেগুলোর boot ইমেজ থেকে জেনেরিক র‍্যামডিস্ক সরিয়ে একটি আলাদা init_boot ইমেজে রাখা হয়। এই পরিবর্তনের ফলে boot ইমেজে শুধুমাত্র GKI কার্নেলটিই থেকে যায়।

যেসব ডিভাইস এখনও অ্যান্ড্রয়েড ১২ বা তার পুরোনো কার্নেল সংস্করণ ব্যবহার করে, সেগুলোকে আপগ্রেড করার ক্ষেত্রে জেনেরিক র‍্যামডিস্ক আগের জায়গাতেই থাকে এবং নতুন কোনো init_boot ইমেজের প্রয়োজন হয় না।

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

যেসব ডিভাইসে:

  • ডেডিকেটেড recovery পার্টিশন ব্যবহার করবেন না, সমস্ত রিকভারি বিট জেনেরিক র‍্যামডিস্ক থেকে vendor_boot র‍্যামডিস্কে স্থানান্তরিত হবে।

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

স্থাপত্য

নিম্নলিখিত ডায়াগ্রামগুলো অ্যান্ড্রয়েড ১২ এবং তার পরবর্তী সংস্করণ চালিত ডিভাইসগুলোর আর্কিটেকচার তুলে ধরে। অ্যান্ড্রয়েড ১৩ দিয়ে চালু হওয়া ডিভাইসগুলোতে জেনেরিক র‍্যামডিস্ক সম্বলিত একটি নতুন init_boot ইমেজ থাকে। অ্যান্ড্রয়েড ১২ থেকে অ্যান্ড্রয়েড ১৩-তে আপগ্রেড করা ডিভাইসগুলো অ্যান্ড্রয়েড ১২-এর মতোই একই আর্কিটেকচার ব্যবহার করে।

অ্যান্ড্রয়েড ১৩ দিয়ে চালু হয়েছে, কোনো ডেডিকেটেড রিকভারি নেই

ডিভাইস চালু/আপগ্রেড করুন, GKI, কোনো ডেডিকেটেড রিকভারি নেই

চিত্র ১. GKI সহ, ডেডিকেটেড রিকভারি ছাড়া অ্যান্ড্রয়েড ১৩-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

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

ডিভাইস চালু/আপগ্রেড, GKI, ডেডিকেটেড এবং A/B রিকভারি

চিত্র ২. GKI, ডেডিকেটেড এবং A/B রিকভারি সহ অ্যান্ড্রয়েড ১৩-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

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

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

ডিভাইস চালু/আপগ্রেড, GKI, ডেডিকেটেড এবং নন-A/B রিকভারি

চিত্র ৩. GKI, ডেডিকেটেড এবং নন-A/B রিকভারি সহ অ্যান্ড্রয়েড ১৩-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

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

অ্যান্ড্রয়েড ১২ চালু বা আপগ্রেড করুন, কোনো ডেডিকেটেড রিকভারি নেই।

ডিভাইস চালু/আপগ্রেড করুন, GKI, কোনো ডেডিকেটেড রিকভারি নেই

চিত্র ৪। GKI সহ, ডেডিকেটেড রিকভারি ছাড়া অ্যান্ড্রয়েড ১২-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

অ্যান্ড্রয়েড ১২ চালু বা আপগ্রেড করুন, ডেডিকেটেড এবং এ/বি রিকভারি (ডেডিকেটেড র‍্যামডিস্ক)

ডিভাইস চালু/আপগ্রেড, GKI, ডেডিকেটেড এবং A/B রিকভারি

চিত্র ৫. GKI, ডেডিকেটেড এবং A/B রিকভারি ব্যবহার করে অ্যান্ড্রয়েড ১২-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

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

অ্যান্ড্রয়েড ১২ চালু করুন বা আপগ্রেড করুন, ডেডিকেটেড এবং নন-এ/বি রিকভারি (ডেডিকেটেড র‍্যামডিস্ক)

ডিভাইস চালু/আপগ্রেড, GKI, ডেডিকেটেড এবং নন-A/B রিকভারি

চিত্র ৬. GKI, ডেডিকেটেড এবং নন-A/B রিকভারি সহ অ্যান্ড্রয়েড ১২-এ লঞ্চ বা আপগ্রেড হওয়া ডিভাইসসমূহ।

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

অ্যান্ড্রয়েড ১২-এ আপগ্রেড করুন, রিকভারি-অ্যাজ-বুট (রিকভারি-অ্যাজ-র‍্যামডিস্ক)

ডিভাইস চালু/আপগ্রেড করুন, GKI ছাড়া, রিকভারি-অ্যাজ-বুট

চিত্র ৭। অ্যান্ড্রয়েড ১২-এ আপগ্রেড হওয়া ডিভাইস, জিকেআই ছাড়া, রিকভারি-অ্যাজ-বুট।

অ্যান্ড্রয়েড ১২-এ আপগ্রেড করুন, ডেডিকেটেড রিকভারি (ডেডিকেটেড র‍্যামডিস্ক)

ডিভাইস চালু/আপগ্রেড করুন, GKI নয়, ডেডিকেটেড রিকভারি

চিত্র ৮. জিকেআই ছাড়া, ডেডিকেটেড রিকভারি ব্যবহার করে অ্যান্ড্রয়েড ১২-এ আপগ্রেড করা ডিভাইস।

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

অ্যান্ড্রয়েড বুট ইমেজগুলোতে নিম্নলিখিত বিষয়গুলো থাকে।

  • অ্যান্ড্রয়েড ১৩ সহ লঞ্চ হওয়া ডিভাইসগুলির জন্য init_boot ইমেজ যোগ করা হয়েছে।

    • হেডার সংস্করণ V4
    • জেনেরিক র‍্যামডিস্ক ইমেজ
  • জেনেরিক boot ইমেজ

    • হেডার সংস্করণ V3 বা V4
      • GKI boot.img সার্টিফিকেশনের জন্য একটি boot_signature (শুধুমাত্র v4-এর জন্য)। সার্টিফাইড GKI boot.img ভেরিফাইড বুটের জন্য স্বাক্ষরিত থাকে না। OEM-দের এখনও একটি ডিভাইস-নির্দিষ্ট AVB কী দিয়ে প্রি-বিল্ট boot.img টি স্বাক্ষর করতে হবে।
      • জেনেরিক cmdline ( GENERIC_KERNEL_CMDLINE )
      • জিকেআই কার্নেল
    • জেনেরিক র‍্যামডিস্ক ইমেজ
      • শুধুমাত্র অ্যান্ড্রয়েড ১২ এবং তার পূর্ববর্তী সংস্করণগুলোর boot ইমেজে অন্তর্ভুক্ত
  • vendor_boot ইমেজ (বিস্তারিত জানতে, ভেন্ডর বুট পার্টিশন দেখুন)

    • vendor_boot হেডার
      • ডিভাইস-নির্দিষ্ট cmdline ( BOARD_KERNEL_CMDLINE )
    • vendor_boot র‍্যামডিস্ক ইমেজ
      • lib/modules
      • পুনরুদ্ধার সংস্থান (যদি কোনো নির্দিষ্ট পুনরুদ্ধার ব্যবস্থা না থাকে)
    • dtb ছবি
  • recovery চিত্র

    • হেডার সংস্করণ V2
      • প্রয়োজনে পুনরুদ্ধারের জন্য ডিভাইস-নির্দিষ্ট cmdline
      • নন-এ/বি রিকভারি পার্টিশনের ক্ষেত্রে, হেডারের বিষয়বস্তু অবশ্যই স্বতন্ত্র হতে হবে; রিকভারি ইমেজ দেখুন। উদাহরণস্বরূপ:
      • boot এবং vendor_boot cmdline cmdline করা হয় না।
      • প্রয়োজন হলে, হেডারটি রিকভারি DTBO নির্দিষ্ট করে।
      • A/B রিকভারি পার্টিশনের ক্ষেত্রে, boot এবং vendor_boot থেকে বিষয়বস্তু একত্রিত করা বা অনুমান করা যেতে পারে। উদাহরণস্বরূপ:
      • cmdline boot এবং vendor_boot cmdline সাথে যুক্ত করা হয়।
      • vendor_boot হেডার থেকে DTBO সম্পর্কে ধারণা করা যায়।
    • recovery র‍্যামডিস্ক ইমেজ
      • পুনরুদ্ধার সংস্থান
      • নন-এ/বি রিকভারি পার্টিশনের ক্ষেত্রে, র‍্যামডিস্কের বিষয়বস্তু অবশ্যই স্বতন্ত্র হতে হবে; রিকভারি ইমেজ দেখুন। উদাহরণস্বরূপ:
      • রিকভারি মোডে বুট করার জন্য প্রয়োজনীয় সমস্ত কার্নেল মডিউল lib/modules অবশ্যই থাকতে হবে।
      • রিকভারি র‍্যামডিস্কে অবশ্যই init থাকতে হবে।
      • A/B রিকভারি পার্টিশনের ক্ষেত্রে, রিকভারি র‍্যামডিস্কটি জেনেরিক এবং vendor_boot র‍্যামডিস্কের শুরুতে যুক্ত করা হয়, তাই এটির স্বতন্ত্র হওয়ার প্রয়োজন নেই। উদাহরণস্বরূপ:
      • vendor_boot র‍্যামডিস্কে থাকা কার্নেল মডিউলগুলো ছাড়াও lib/modules শুধুমাত্র রিকভারি মোডে বুট করার জন্য প্রয়োজনীয় অতিরিক্ত কার্নেল মডিউলগুলো থাকতে পারে।
      • /init এ সিমলিঙ্কটি থাকতে পারে, কিন্তু বুট ইমেজের প্রথম-পর্যায়ের /init বাইনারিটির কারণে এটি আড়ালে পড়ে যায়।

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

জেনেরিক র‍্যামডিস্কে নিম্নলিখিত উপাদানগুলো থাকে।

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

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

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

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

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

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

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

  • BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT . এই ভেরিয়েবলটি নিয়ন্ত্রণ করে যে র‍্যামডিস্ক রিকভারি রিসোর্সগুলো vendor_boot এ বিল্ড করা হবে কিনা।

    • যখন এটি true তে সেট করা হয়, তখন রিকভারি রিসোর্সগুলি শুধুমাত্র vendor-ramdisk/ এ বিল্ড করা হয় এবং recovery/root/ এ বিল্ড করা হয় না।

    • খালি থাকলে, রিকভারি রিসোর্সগুলি শুধুমাত্র recovery/root/ এ তৈরি হয় এবং vendor-ramdisk/ এ তৈরি হয় না।

  • BOARD_MOVE_GSI_AVB_KEYS_TO_VENDOR_BOOT . এই ভেরিয়েবলটি নিয়ন্ত্রণ করে যে GSI AVB কীগুলি vendor_boot এ বিল্ড করা হবে কিনা।

    • যখন true তে সেট করা হয়, যদি BOARD_MOVE_RECOVERY_RESOURCES_TO_VENDOR_BOOT হয়:

      • সেট করা আছে, GSI AVB কীগুলি $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/avb এ বিল্ড করা হয়।

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

অনুমোদিত সংমিশ্রণ

উপাদান বা পরিবর্তনশীল রিকভারি পার্টিশন ছাড়া ডিভাইস আপগ্রেড করুন রিকভারি পার্টিশন দিয়ে ডিভাইস আপগ্রেড করুন রিকভারি পার্টিশন ছাড়া ডিভাইস চালু করুন A/B রিকভারি পার্টিশন দিয়ে ডিভাইসটি চালু করুন নন-এ/বি রিকভারি পার্টিশন দিয়ে ডিভাইসটি চালু করুন aosp_arm64
boot ধারণ করে হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ
init_boot অন্তর্ভুক্ত (অ্যান্ড্রয়েড ১৩) না না হ্যাঁ হ্যাঁ হ্যাঁ হ্যাঁ
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 খালি খালি খালি
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 ইমেজ তৈরি করা হয়।

বুটের জন্য চেইনড ভিবিমেটা সক্রিয় করুন

boot এবং init_boot ইমেজগুলির জন্য Chained 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 এ সরিয়ে দিন)।

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

যেসব ডিভাইস অ্যান্ড্রয়েড ১৩ দিয়ে লঞ্চ হয়, অ্যান্ড্রয়েড ১২-এ আপগ্রেড করে, এবং অ্যান্ড্রয়েড ১২ দিয়েই লঞ্চ হয়, সেগুলোর সেটআপ নির্দেশাবলী ভিন্ন হয়। অ্যান্ড্রয়েড ১৩-এর সেটআপ, অ্যান্ড্রয়েড ১২-এর মতোই হয়ে থাকে।

  • যেসব ডিভাইস অ্যান্ড্রয়েড ১২-এ আপগ্রেড হচ্ছে:

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

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

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

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

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

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

  • যেসব ডিভাইস অ্যান্ড্রয়েড ১২ সহ চালু হচ্ছে, সেগুলোকে অবশ্যই BOARD_USES_RECOVERY_AS_BOOT খালি রাখতে হবে এবং নতুন কনফিগারেশন ব্যবহার করতে হবে। যদি এই ধরনের ডিভাইসগুলিতে:

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

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

যেহেতু aosp_arm64 শুধুমাত্র GKI বিল্ড করে ( vendor_boot বা recovery নয়), তাই এটি একটি সম্পূর্ণ টার্গেট নয়। 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 সিমলিঙ্ক এবং /system/bin/initinit_second_stage.recovery থাকতে পারে। তবে, যেহেতু 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 এ ইনস্টল করতে পারেন (যদি আপনার ইনস্টল করার মতো কোনো ডিভাইস-নির্দিষ্ট মডিউল না থাকে তবে এই ধাপটি এড়িয়ে যান)।

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

  • যখন মডিউলটি / এ ইনস্টল করা হয়, তখন মডিউলটির 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 \

উদাহরণস্বরূপ, এই পরিবর্তন তালিকাটি দেখুন।

ভার্চুয়াল এ/বি কম্প্রেশন

ভার্চুয়াল এ/বি কম্প্রেশন সমর্থন করার জন্য, 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 যদি ডিভাইসটি ভার্চুয়াল এ/বি সমর্থন করে কিন্তু কম্প্রেশন সমর্থন না করে।

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

প্রোডাক্ট মেকফাইলগুলো $ANDROID_PRODUCT_OUT/vendor-ramdisk/first_stage_ramdisk/system/bin/e2fsck ইনস্টল করে। রানটাইমে, প্রথম স্টেজের init রুটকে /first_stage_ramdisk এ সুইচ করে এবং তারপর /system/bin/e2fsck এক্সিকিউট করে।

বিকল্প ২ক: ডেডিকেটেড এবং এ/বি রিকভারি পার্টিশন

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

AB_OTA_PARTITIONS += recovery

vendor_boot র‍্যামডিস্কে র‍্যামডিস্ক এবং ভেন্ডর কার্নেল মডিউলের ভেন্ডর অংশগুলো থাকে, যার মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:

  • ডিভাইস-নির্দিষ্ট 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/initinit_second_stage.recovery থাকতে পারে। তবে, যেহেতু recovery র‍্যামডিস্কের পরে বুট র‍্যামডিস্ক যুক্ত করা হয়, তাই /init সিমলিঙ্কটি ওভাররাইট হয়ে যায়। যখন ডিভাইসটি রিকভারি মোডে বুট করে, তখন সেকেন্ড স্টেজ ইনিট সমর্থন করার জন্য /system/bin/init বাইনারিটির প্রয়োজন হয়।

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

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

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

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

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

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

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

ঐচ্ছিকভাবে, আপনি vendor_ramdisk এ ডিভাইস-নির্দিষ্ট মডিউল ইনস্টল করতে পারেন (যদি আপনার ইনস্টল করার মতো কোনো ডিভাইস-নির্দিষ্ট মডিউল না থাকে তবে এই ধাপটি এড়িয়ে যান)। Init রুট পরিবর্তন করে না। মডিউলগুলির vendor_ramdisk সংস্করণটি vendor_ramdisk এর রুটে ইনস্টল হয়। vendor_ramdisk এ মডিউল ইনস্টল করার উদাহরণের জন্য, First stage console , Metadata checksums , এবং Virtual A/B compression দেখুন।

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

মডিউলগুলোর 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 \

উদাহরণস্বরূপ, এই পরিবর্তন তালিকাটি দেখুন।

ভার্চুয়াল এ/বি কম্প্রেশন

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

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

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

রিকভারি মোডে বুট করার সময় বুট প্রক্রিয়া পরিবর্তিত হয়। রিকভারি + vendor_boot + জেনেরিক র‍্যামডিস্ক প্রক্রিয়াটি বিদ্যমান রিকভারি প্রক্রিয়ার মতোই, তবে এক্ষেত্রে কার্নেলটি recovery ইমেজের পরিবর্তে boot ইমেজ থেকে লোড করা হয়। রিকভারি মোডের বুট প্রক্রিয়াটি নিম্নরূপ।

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

    1. রিকভারি + vendor_boot + জেনেরিক র‍্যামডিস্ককে / এ পুশ করে। (যদি OEM কার্নেল মডিউলগুলোকে BOARD_RECOVERY_KERNEL_MODULES এ যোগ করে রিকভারি র‍্যামডিস্কে সেগুলোর প্রতিলিপি তৈরি করে), তাহলে vendor_boot ঐচ্ছিক।)
    2. boot পার্টিশন থেকে কার্নেলটি চালানো হয়।
  2. কার্নেল প্রথমে / এ র‍্যামডিস্ক মাউন্ট করে এবং তারপর জেনেরিক র‍্যামডিস্ক থেকে /init এক্সিকিউট করে।

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

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

e2fsck উপলব্ধ করুন

ডিভাইস মেকফাইলগুলো নিম্নলিখিতগুলো থেকে ইনহেরিট করতে পারে:

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

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

প্রোডাক্ট মেকফাইলগুলো $ANDROID_PRODUCT_OUT/vendor-ramdisk/system/bin/e2fsck ইনস্টল করে। রানটাইমে, প্রথম ধাপের init /system/bin/e2fsck এক্সিকিউট করে।

বিকল্প ২খ: ডেডিকেটেড এবং নন-এ/বি রিকভারি পার্টিশন

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

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

vendor_boot র‍্যামডিস্কে র‍্যামডিস্ক এবং ভেন্ডর কার্নেল মডিউলের ভেন্ডর অংশগুলো থাকে, যার মধ্যে নিম্নলিখিতগুলো অন্তর্ভুক্ত:

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

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

  • কার্নেল ইমেজ
  • ডিটিবিও চিত্র
  • lib/modules এ কার্নেল মডিউল
  • প্রথম পর্যায়ের init একটি symlink /init -> /system/bin/init হিসাবে
  • দ্বিতীয় পর্যায়ের ইনিট বাইনারি /system/bin/init
  • ডিভাইস-নির্দিষ্ট fstab ফাইল
  • recovery বাইনারি সহ অন্যান্য সমস্ত রিকভারি রিসোর্স

এই ধরনের ডিভাইসগুলিতে, পণ্যের কনফিগারেশন generic_ramdisk.mk থেকে উত্তরাধিকারসূত্রে প্রাপ্ত হয়

বোর্ডের মান নির্ধারণ করুন

নন-এ/বি ডিভাইসগুলির জন্য নিম্নলিখিত মানগুলি সেট করুন:

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

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

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

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

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

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

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

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

আপনি ডিভাইস-নির্দিষ্ট মডিউলগুলো vendor_ramdisk এবং recovery ramdisk-এ ইনস্টল করতে পারেন (যদি আপনার ইনস্টল করার মতো কোনো ডিভাইস-নির্দিষ্ট মডিউল না থাকে তবে এই ধাপটি এড়িয়ে যান)। init রুট পরিবর্তন করে না। মডিউলগুলোর vendor_ramdisk সংস্করণটি vendor_ramdisk এর রুটে ইনস্টল হয়। মডিউলগুলোর recovery সংস্করণটি recovery ramdisk-এর রুটে ইনস্টল হয়। vendor_ramdisk এবং recovery ramdisk-এ মডিউল ইনস্টল করার উদাহরণের জন্য, First stage console এবং Metadata checksums দেখুন।

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

মডিউলগুলোর vendor_ramdisk ভ্যারিয়েন্ট ইনস্টল করতে নিম্নলিখিতটি ব্যবহার করুন:

PRODUCT_PACKAGES += \
    linker.vendor_ramdisk \
    shell_and_utilities_vendor_ramdisk \

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

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

PRODUCT_PACKAGES += adbd.vendor_ramdisk

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

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

PRODUCT_PACKAGES += \
    linker.recovery \
    shell_and_utilities_recovery \
    adbd.recovery \

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

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

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

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

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

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

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

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

    1. রিকভারি র‍্যামডিস্ককে / এ স্থানান্তর করে।
    2. recovery পার্টিশন থেকে কার্নেলটি চালানো হয়।
  2. কার্নেল প্রথমে র‍্যামডিস্ককে ' / এ মাউন্ট করে এবং তারপর /init এক্সিকিউট করে, যা recovery র‍্যামডিস্ক থেকে /system/bin/init এর একটি সিমলিঙ্ক।

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

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

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

নিম্নলিখিত কোডটি একটি উদাহরণ 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 ইমেজের টাইমস্ট্যাম্প বৈশিষ্ট্যগুলো নির্ধারণ করতে পারে।