এই পৃষ্ঠাটি Cloud Translation API অনুবাদ করেছে।

পার্টিশন লেআউট

অ্যান্ড্রয়েড 10-এ, রুট ফাইল সিস্টেমটি আর ramdisk.img এ অন্তর্ভুক্ত করা হয় না এবং পরিবর্তে system.img এ মার্জ করা হয় (অর্থাৎ, system.img সবসময় এমনভাবে তৈরি করা হয় যেন BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করা হয়েছে)। অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলি:

একটি সিস্টেম-অ্যাজ-রুট পার্টিশন লেআউট ব্যবহার করুন (আচরণ পরিবর্তন করার কোনো বিকল্প ছাড়াই বিল্ড দ্বারা স্বয়ংক্রিয়ভাবে প্রয়োগ করা হয়)।
একটি রামডিস্ক ব্যবহার করতে হবে, যা dm-লিনিয়ারের জন্য প্রয়োজন।
BOARD_BUILD_SYSTEM_ROOT_IMAGE কে false সেট করতে হবে। এই সেটিংটি শুধুমাত্র রামডিস্ক ব্যবহার করে এমন ডিভাইস এবং রামডিস্ক ব্যবহার করে না এমন ডিভাইসগুলির মধ্যে পার্থক্য করতে ব্যবহৃত হয় (এবং সরাসরি system.img মাউন্ট করুন)।

সিস্টেম-এ-রুট কনফিগারেশনের অর্থ Android 9 এবং Android 10-এর মধ্যে আলাদা। একটি Android 9 সিস্টেম-অ্যাজ-রুট কনফিগারেশনে, BOARD_BUILD_SYSTEM_ROOT_IMAGE true সেট করা হয়, যা বিল্ডকে রুট ফাইল সিস্টেমকে system.img এ মার্জ করতে বাধ্য করে mount system.img রুট ফাইল সিস্টেম (rootfs) হিসাবে। এই কনফিগারেশনটি Android 9 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য বাধ্যতামূলক কিন্তু Android 9-এ আপগ্রেড করা ডিভাইসগুলির জন্য এবং Android এর নিম্ন সংস্করণে চলমান ডিভাইসগুলির জন্য ঐচ্ছিক ৷ একটি অ্যান্ড্রয়েড 10 সিস্টেম-অ্যাজ-রুট কনফিগারেশনে, বিল্ড সর্বদা $TARGET_SYSTEM_OUT এবং $TARGET_ROOT_OUT system.img এ একত্রিত করে; এই কনফিগারেশনটি Android 10 চালিত সমস্ত ডিভাইসের জন্য ডিফল্ট আচরণ।

অ্যান্ড্রয়েড 10 ডায়নামিক পার্টিশন সমর্থন করতে আরও পরিবর্তন করে, একটি ইউজারস্পেস পার্টিশনিং সিস্টেম যা ওভার-দ্য-এয়ার (OTA) আপডেটগুলি পার্টিশন তৈরি করতে, আকার পরিবর্তন করতে বা ধ্বংস করতে সক্ষম করে। এই পরিবর্তনের অংশ হিসাবে, Linux কার্নেল আর Android 10 চালিত ডিভাইসগুলিতে লজিক্যাল সিস্টেম পার্টিশন মাউন্ট করতে পারে না, তাই এই অপারেশনটি প্রথম পর্যায়ের init দ্বারা পরিচালিত হয়।

নিম্নলিখিত বিভাগগুলি সিস্টেম-অনলি OTA-র জন্য সিস্টেম-এ-রুট প্রয়োজনীয়তা বর্ণনা করে, সিস্টেম-এ-রুট ব্যবহার করার জন্য ডিভাইস আপডেট করার বিষয়ে নির্দেশিকা প্রদান করে (পার্টিশন বিন্যাস পরিবর্তন এবং dm-verity কার্নেলের প্রয়োজনীয়তা সহ)। র‌্যামডিস্কে পরিবর্তনের বিস্তারিত জানার জন্য, রামডিস্ক পার্টিশন দেখুন।

শুধুমাত্র সিস্টেম ওটিএ সম্পর্কে

সিস্টেম-অনলি ওটিএ, যা অ্যান্ড্রয়েড রিলিজগুলিকে অন্য পার্টিশন পরিবর্তন না করে system.img এবং product.img আপডেট করতে সক্ষম করে, একটি সিস্টেম-এ-রুট পার্টিশন লেআউট প্রয়োজন। অ্যান্ড্রয়েড 10 চালিত সমস্ত ডিভাইসে শুধুমাত্র সিস্টেম-ওটিএ সক্ষম করতে একটি সিস্টেম-এ-রুট পার্টিশন লেআউট ব্যবহার করতে হবে।

A/B ডিভাইস, যা rootfs হিসাবে system পার্টিশন মাউন্ট করে, ইতিমধ্যেই সিস্টেম-এ-রুট ব্যবহার করে এবং সিস্টেম OTA-কে সমর্থন করার জন্য পরিবর্তনের প্রয়োজন হয় না।
নন-A/B ডিভাইসগুলি, যা /system এ system পার্টিশন মাউন্ট করে, সিস্টেমের OTA-কে সমর্থন করার জন্য একটি সিস্টেম-এ-রুট পার্টিশন লেআউট ব্যবহার করার জন্য আপডেট করা আবশ্যক।

A/B এবং নন-A/B ডিভাইসের বিশদ বিবরণের জন্য, A/B (সিমলেস) সিস্টেম আপডেটগুলি পড়ুন।

বিক্রেতা ওভারলে ব্যবহার করে

ভেন্ডর ওভারলে আপনাকে ডিভাইস বুট করার সময় vendor পার্টিশনে পরিবর্তন ওভারলে করতে দেয়। একটি ভেন্ডর ওভারলে হল product পার্টিশনে ভেন্ডর মডিউলগুলির একটি সেট যা ডিভাইস বুট করার সময়, বিদ্যমান মডিউলগুলি প্রতিস্থাপন এবং যোগ করার সময় vendor পার্টিশনে ওভারলেড হয়ে যায়।

ডিভাইস বুট হলে, init প্রক্রিয়া প্রথম পর্যায়ে মাউন্ট সম্পূর্ণ করে এবং ডিফল্ট বৈশিষ্ট্যগুলি পড়ে। তারপরে এটি /product/vendor_overlay/<target_vendor_version> অনুসন্ধান করে এবং প্রতিটি সাবডিরেক্টরি তার সংশ্লিষ্ট vendor পার্টিশন ডিরেক্টরিতে মাউন্ট করে, যদি নিম্নলিখিত শর্তগুলি পূরণ করা হয়:

/vendor/<overlay_dir> বিদ্যমান।
/product/vendor_overlay/<target_vendor_version>/<overlay_dir> /vendor/<overlay_dir> এর মতো একই ফাইল প্রসঙ্গ রয়েছে।
init /vendor/<overlay_dir> এর ফাইল প্রসঙ্গে মাউন্ট করার অনুমতি দেওয়া হয়েছে।

বিক্রেতা ওভারলে বাস্তবায়ন

/product/vendor_overlay/<target_vendor_version> এ ভেন্ডর ওভারলে ফাইল ইনস্টল করুন। ডিভাইস বুট করার সময় একই নামের ফাইল প্রতিস্থাপন করে এবং নতুন কোনো ফাইল যোগ করলে সেই ফাইলগুলি vendor পার্টিশনকে ওভারলে করে। বিক্রেতা ওভারলে vendor পার্টিশন থেকে ফাইল সরাতে পারে না।

বিক্রেতা ওভারলে ফাইলগুলির অবশ্যই একই ফাইল প্রসঙ্গ থাকতে হবে যেগুলি লক্ষ্য ফাইলগুলি তারা vendor পার্টিশনে প্রতিস্থাপন করে। ডিফল্টরূপে, /product/vendor_overlay/<target_vendor_version> ডিরেক্টরির ফাইলগুলিতে vendor_file প্রসঙ্গ থাকে। বিক্রেতা ওভারলে ফাইল এবং তারা যে ফাইলগুলি প্রতিস্থাপন করে তার মধ্যে যদি ফাইলের প্রসঙ্গ অমিল থাকে, তবে সেটি ডিভাইস-নির্দিষ্ট সিপলিসিতে উল্লেখ করুন। ফাইল প্রসঙ্গ ডিরেক্টরি স্তরে সেট করা হয়. যদি একটি বিক্রেতা ওভারলে ডিরেক্টরির ফাইলের প্রসঙ্গ টার্গেট ডিরেক্টরির সাথে মেলে না, এবং সঠিক ফাইলের প্রসঙ্গটি ডিভাইস-নির্দিষ্ট সিপলিসিতে নির্দিষ্ট করা না থাকে, তাহলে সেই ভেন্ডর ওভারলে ডিরেক্টরি টার্গেট ডিরেক্টরিতে ওভারলেড করা হয় না।

ভেন্ডর ওভারলে ব্যবহার করতে, কার্নেলকে অবশ্যই CONFIG_OVERLAY_FS=y সেট করে OverlayFS সক্রিয় করতে হবে। এছাড়াও, কার্নেলকে অবশ্যই সাধারণ কার্নেল 4.4 বা তার পরবর্তী থেকে মার্জ করতে হবে, অথবা "overlayfs: override_creds=off option bypass creator_cred" দিয়ে প্যাচ করতে হবে।

বিক্রেতা ওভারলে বাস্তবায়ন উদাহরণ

এই পদ্ধতিটি একটি ভেন্ডর ওভারলে প্রয়োগ করে দেখায় যা /vendor/lib/* , /vendor/etc/* , এবং /vendor/app/* ডিরেক্টরিগুলিকে ওভারলে করে।

device/<vendor>/<target>/vendor_overlay/<target_vendor_version>/ :

device/google/device/vendor_overlay/28/lib/libfoo.so
device/google/device/vendor_overlay/28/lib/libbar.so
device/google/device/vendor_overlay/28/etc/baz.xml
device/google/device/vendor_overlay/28/app/qux.apk

device/google/device/device.mk এ product/vendor_overlay প্রি-বিল্ট ভেন্ডর ফাইল ইনস্টল করুন:
```
PRODUCT_COPY_FILES += \
    $(call find-copy-subdir-files,*,device/google/device/vendor_overlay,$(TARGET_COPY_OUT_PRODUCT)/vendor_overlay)
```
টার্গেট vendor পার্টিশন ফাইলে vendor_file ছাড়া অন্য প্রসঙ্গ থাকলে ফাইলের প্রসঙ্গ সংজ্ঞায়িত করুন। যেহেতু /vendor/lib/* vendor_file প্রসঙ্গ ব্যবহার করে, এই উদাহরণে সেই ডিরেক্টরি অন্তর্ভুক্ত করা হয় না।
device/google/device-sepolicy/private/file_contexts এ নিম্নলিখিত যোগ করুন:
```
/(product|system/product)/vendor_overlay/[0-9]+/etc(/.*)?   u:object_r:vendor_configs_file:s0
/(product|system/product)/vendor_overlay/[0-9]+/app(/.*)?   u:object_r:vendor_app_file:s0
```
init প্রক্রিয়াটিকে vendor_file ছাড়া অন্য ফাইল প্রসঙ্গে ভেন্ডর ওভারলে মাউন্ট করার অনুমতি দিন। কারণ init প্রক্রিয়ার ইতিমধ্যেই vendor_file প্রসঙ্গে মাউন্ট করার অনুমতি রয়েছে, এই উদাহরণটি vendor_file এর জন্য নীতি নির্ধারণ করে না।
device/google/device-sepolicy/public/init.te এ নিম্নলিখিত যোগ করুন:
```
allow init vendor_configs_file:dir mounton;
allow init vendor_app_file:dir mounton;
```

ভেন্ডর ওভারলে যাচাই করা হচ্ছে

ভেন্ডর ওভারলে কনফিগারেশন যাচাই করতে, /product/vendor_overlay/<target_vendor_version>/<overlay_dir> এ ফাইল যোগ করুন এবং ফাইলগুলি /vendor/<overlay_dir> এর ফাইলগুলিতে ওভারলে করা হয়েছে কিনা তা পরীক্ষা করুন।

userdebug বিল্ডগুলির জন্য, Atest এর জন্য একটি পরীক্ষা মডিউল রয়েছে:

$ atest -v fs_mgr_vendor_overlay_test

সিস্টেম-এ-রুট-এ আপডেট করা হচ্ছে

সিস্টেম-অ্যাজ-রুট ব্যবহার করার জন্য নন-A/B ডিভাইসগুলিকে আপডেট করতে, আপনাকে অবশ্যই boot.img এবং system.img এর পার্টিশনিং স্কিম আপডেট করতে হবে, dm-verity সেট আপ করতে হবে এবং ডিভাইস-নির্দিষ্ট রুট ফোল্ডারে বুট নির্ভরতা মুছে ফেলতে হবে।

পার্টিশন আপডেট করা হচ্ছে

A/B ডিভাইসের বিপরীতে যেগুলি /boot পুনরুদ্ধার পার্টিশন হিসাবে পুনরায় ব্যবহার করে, নন-A/B ডিভাইসগুলিকে অবশ্যই /recovery পার্টিশনটিকে আলাদা রাখতে হবে কারণ তাদের ফলব্যাক স্লট পার্টিশন নেই (উদাহরণস্বরূপ, boot_a থেকে boot_b )। যদি /recovery নন-A/B ডিভাইসে মুছে ফেলা হয় এবং A/B স্কিমের অনুরূপ করা হয়, তাহলে /boot পার্টিশনের ব্যর্থ আপডেটের সময় পুনরুদ্ধার মোড ভেঙে যেতে পারে। এই কারণে, /recovery পার্টিশনটি নন-A/B ডিভাইসগুলির জন্য /boot থেকে একটি পৃথক পার্টিশন হতে হবে , যা বোঝায় যে পুনরুদ্ধার চিত্রটি বিলম্বিত পদ্ধতিতে আপডেট হতে থাকবে (অর্থাৎ, Android চালিত ডিভাইসগুলির মতোই। 8.1.0 বা কম)।

নিম্নলিখিত সারণীটি Android 9 এর আগে এবং পরে নন-A/B ডিভাইসগুলির জন্য চিত্র পার্টিশন পার্থক্যগুলি তালিকাভুক্ত করে৷

ছবি	রামডিস্ক (৯ এর আগে)	সিস্টেম-এ-রুট (9 এর পরে)
`boot.img`	একটি কার্নেল এবং একটি `ramdisk.img` রয়েছে : ramdisk.img -/ - init.rc - init - etc -> /system/etc - system/ (mount point) - vendor/ (mount point) - odm/ (mount point) ...	শুধুমাত্র একটি সাধারণ বুট কার্নেল ধারণ করে।
`recovery.img`	একটি রিকভারি কার্নেল এবং একটি রিকভারি `ramdisk.img` রয়েছে।
`system.img`	নিম্নলিখিতগুলি রয়েছে: system.img -/ - bin/ - etc - vendor -> /vendor - ...	মূল `system.img` এবং `ramdisk.img` এর একত্রিত বিষয়বস্তু রয়েছে : system.img -/ - init.rc - init - etc -> /system/etc - system/ - bin/ - etc/ - vendor -> /vendor - ... - vendor/ (mount point) - odm/ (mount point) ...

পার্টিশন নিজেই পরিবর্তন হয় না; ramdisk এবং system-as-root উভয়ই নিম্নলিখিত পার্টিশন স্কিম ব্যবহার করে:

/boot
/system
/system
/recovery
/vendor , ইত্যাদি

dm-verity সেট আপ করা হচ্ছে

সিস্টেম-এ-রুট-এ, কার্নেলকে অবশ্যই dm-verity- এর সাথে system.img এর অধীনে / (মাউন্ট পয়েন্ট) মাউন্ট করতে হবে। AOSP system.img এর জন্য নিম্নলিখিত dm-verity বাস্তবায়ন সমর্থন করে।

vboot 1.0

vboot 1.0- এর জন্য, কার্নেলকে অবশ্যই /system এ অ্যান্ড্রয়েড-নির্দিষ্ট মেটাডেটা পার্স করতে হবে, তারপর dm -verity সেট আপ করতে dm-verity params- এ রূপান্তর করতে হবে ( এই কার্নেল প্যাচগুলির প্রয়োজন)। নিম্নলিখিত উদাহরণটি কার্নেল কমান্ড লাইনে সিস্টেম-এজ-রুটের জন্য dm-verity সম্পর্কিত সেটিংস দেখায়:

ro root=/dev/dm-0 rootwait skip_initramfs init=/init
dm="system none ro,0 1 android-verity /dev/sda34"
veritykeyid=id:7e4333f9bba00adfe0ede979e28ed1920492b40f

vboot 2.0

vboot 2.0 ( AVB ) এর জন্য, বুটলোডারকে অবশ্যই external/avb/libavb সংহত করতে হবে, যা পরে /system এর জন্য হ্যাশট্রি বর্ণনাকারীকে পার্স করে, এটিকে dm-verity params- এ রূপান্তর করে, এবং অবশেষে কার্নেল কমান্ড লাইনের মাধ্যমে প্যারামগুলিকে কার্নেলে প্রেরণ করে। ( /system এর Hashtree বর্ণনাকারী /vbmeta বা /system নিজেই হতে পারে।)

vboot 2.0-এর জন্য নিম্নলিখিত কার্নেল প্যাচগুলির প্রয়োজন:

https://android-review.googlesource.com/#/c/kernel/common/+/158491/
কার্নেল 4.4 প্যাচ , কার্নেল 4.9 প্যাচ , ইত্যাদি।

নিম্নলিখিত উদাহরণটি কার্নেল কমান্ড লাইনে সিস্টেম-এজ-রুটের জন্য dm-verity সম্পর্কিত সেটিংস দেখায়:

ro root=/dev/dm-0 rootwait  skip_initramfs init=/init

dm="1 vroot none ro 1,0 5159992 verity 1
PARTUUID=00000016-0000-0000-0000-000000000000
PARTUUID=00000016-0000-0000-0000-000000000000 4096 4096 644999 644999
sha1 d80b4a8be3b58a8ab86fad1b498640892d4843a2
8d08feed2f55c418fb63447fec0d32b1b107e42c 10 restart_on_corruption
ignore_zero_blocks use_fec_from_device
PARTUUID=00000016-0000-0000-0000-000000000000 fec_roots 2 fec_blocks
650080 fec_start 650080"

ডিভাইস-নির্দিষ্ট রুট ফোল্ডার ব্যবহার করে

সিস্টেম-অ্যাজ-রুট দিয়ে, ডিভাইসে জেনেরিক সিস্টেম ইমেজ (GSI) ফ্ল্যাশ করার পরে (এবং ভেন্ডর টেস্ট স্যুট পরীক্ষা চালানোর আগে), BOARD_ROOT_EXTRA_FOLDERS এর সাথে যোগ করা যেকোন ডিভাইস-নির্দিষ্ট রুট ফোল্ডার চলে গেছে কারণ সমগ্র রুট ডিরেক্টরির বিষয়বস্তু প্রতিস্থাপিত হয়েছে। সিস্টেম-এ-রুট জিএসআই দ্বারা। ডিভাইস-নির্দিষ্ট রুট ফোল্ডারগুলির উপর নির্ভরশীলতা বিদ্যমান থাকলে এই ফোল্ডারগুলি অপসারণের ফলে ডিভাইসটি আনবুটযোগ্য হয়ে উঠতে পারে (উদাহরণস্বরূপ, এগুলি মাউন্ট পয়েন্ট হিসাবে ব্যবহার করা হয়)।

এই সমস্যা এড়াতে, ডিভাইস-নির্দিষ্ট রুট ফোল্ডার যোগ করতে BOARD_ROOT_EXTRA_FOLDERS ব্যবহার করবেন না। আপনি যদি ডিভাইস-নির্দিষ্ট মাউন্ট পয়েন্ট নির্দিষ্ট করতে চান, তাহলে /mnt/vendor/<mount point> ব্যবহার করুন (এই পরিবর্তন তালিকাগুলিতে যোগ করা হয়েছে)। এই বিক্রেতা-নির্দিষ্ট মাউন্ট পয়েন্টগুলি সরাসরি fstab ডিভাইস ট্রি (প্রথম-পর্যায়ের মাউন্টের জন্য) এবং /vendor/etc/fstab.{ro.hardware} ফাইলে অতিরিক্ত সেটআপ ছাড়াই নির্দিষ্ট করা যেতে পারে (যেমন fs_mgr এগুলিকে /mnt/vendor/* এর অধীনে তৈরি করে। /mnt/vendor/* স্বয়ংক্রিয়ভাবে)।