Android 10-এ, রুট ফাইল সিস্টেম আর
ramdisk.img-এ অন্তর্ভুক্ত করা হয় না এবং এর পরিবর্তে system.img-এ
মার্জ করা হয় (অর্থাৎ, system.img সবসময় এমনভাবে তৈরি করা হয়
যেন BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করা হয়েছে)। Android 10-এর সাথে
লঞ্চ হওয়া ডিভাইস:
- সিস্টেম-অ্যাজ-রুট পার্টিশন লেআউট ব্যবহার করুন (এটি অটোমেটিক প্রয়োগ করা হয় এবং এর আচরণ পরিবর্তন করার কোনও বিকল্প নেই)।
- অবশ্যই ramdisk ব্যবহার করতে হবে, যা dm-linear-এর জন্য প্রয়োজন।
BOARD_BUILD_SYSTEM_ROOT_IMAGE-এর মানfalseহিসেবে সেট করতে হবে। এই সেটিং শুধুমাত্র সেইসব ডিভাইসের মধ্যে পার্থক্য করতে ব্যবহার করা হয় যেগুলি র্যামডিস্ক ব্যবহার করে এবং যেগুলি র্যামডিস্ক ব্যবহার করে না (এবং পরিবর্তে সরাসরিsystem.imgমাউন্ট করে)।
Android 9 এবং
Android 10-এর মধ্যে সিস্টেম-অ্যাজ-রুট কনফিগারেশনের অর্থ আলাদা আলাদা হয়। Android 9 সিস্টেম-অ্যাজ-রুট
কনফিগারেশনে, BOARD_BUILD_SYSTEM_ROOT_IMAGE-কে true-এ সেট করা হয়, যা বিল্ডকে রুট ফাইল সিস্টেমকে system.img-এ মার্জ করতে বাধ্য করে
এবং তারপর system.img-কে রুট ফাইল সিস্টেম (rootfs) হিসেবে
মাউন্ট করে। Android 9 নিয়ে লঞ্চ করা ডিভাইসের জন্য এই কনফিগারেশন বাধ্যতামূলক হলেও
Android 9-এ আপগ্রেড করা ডিভাইস এবং Android-এর এর আগের যেকোনও ভার্সনে চলা ডিভাইসের জন্য এটি ঐচ্ছিক।
Android
10 সিস্টেম-অ্যাজ-রুট কনফিগারেশনে, বিল্ড সবসময়
$TARGET_SYSTEM_OUT ও $TARGET_ROOT_OUT-কে
system.img-এর সাথে মার্জ করে; Android 10
চালানো সব ডিভাইসের জন্য এই কনফিগারেশন হল ডিফল্ট আচরণ।
Android 10 আরও পরিবর্তন করে ডায়নামিক পার্টিশনকে সাপোর্ট করে। এটি একটি ইউজারস্পেস পার্টিশনিং সিস্টেম যা পার্টিশন তৈরি, রিসাইজ বা ধ্বংস করার জন্য ওভার-দ্য-এয়ার (OTA) আপডেটকে সক্ষম করে। এই পরিবর্তনের অংশ হিসেবে, Linux কার্নেল আর Android 10-এ চলা ডিভাইসে লজিক্যাল সিস্টেম পার্টিশন মাউন্ট করতে পারে না, তাই এই অপারেশনটি প্রথম স্টেজের init দ্বারা পরিচালিত হয়।
নিম্নলিখিত বিভাগে, শুধুমাত্র সিস্টেম-ওটিএ (OTA)-এর জন্য সিস্টেম-অ্যাজ-রুট সংক্রান্ত প্রয়োজনীয়তা বর্ণনা করা হয়েছে। এছাড়াও, সিস্টেম-অ্যাজ-রুট ব্যবহার করার জন্য ডিভাইস আপডেট করার বিষয়ে নির্দেশিকা দেওয়া হয়েছে (এর মধ্যে পার্টিশন লেআউট পরিবর্তন ও dm-verity কার্নেল সংক্রান্ত প্রয়োজনীয়তা অন্তর্ভুক্ত)। ramdisk-এ পরিবর্তন সম্পর্কে আরও জানতে, Ramdisk পার্টিশন দেখুন।
শুধুমাত্র সিস্টেমের জন্য OTA সম্পর্কে
সিস্টেম-অনলি OTA, যা অন্যান্য পার্টিশন পরিবর্তন না করেই Android রিলিজ আপডেট করতে
system.img এবং product.img দেয়, সেটির জন্য সিস্টেম-অ্যাজ-রুট পার্টিশন লেআউট প্রয়োজন।
Android 10
চালু থাকা সব ডিভাইসকে অবশ্যই সিস্টেম-অনলি OTA চালু করতে
সিস্টেম-অ্যাজ-রুট পার্টিশন লেআউট ব্যবহার করতে হবে।
- A/B ডিভাইস, যা rootfs হিসেবে
systemপার্টিশন মাউন্ট করে, আগে থেকেই system-as-root ব্যবহার করে এবং সিস্টেম OTA-কে সাপোর্ট করার জন্য কোনও পরিবর্তন করার প্রয়োজন হয় না। - A/B নয় এমন ডিভাইস, যেগুলি
systemপার্টিশনকে/system-এ মাউন্ট করে, সেগুলিকে সিস্টেম OTA-তে কাজ করার জন্য সিস্টেম-অ্যাজ-রুট পার্টিশন লেআউট ব্যবহার করার জন্য আপডেট করতে হবে।
A/B ও নন-A/B ডিভাইস সম্পর্কে আরও জানতে, এগুলি দেখুন: A/B (নির্বিঘ্নে) সিস্টেম আপডেট।
ভেন্ডর ওভারলে ব্যবহার করুন (<=AOSP 14)
ডিভাইস বুট করার সময় ভেন্ডর ওভারলে আপনাকে 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 প্রসঙ্গ থাকে। ভেন্ডর ওভারলে ফাইল এবং যে ফাইলগুলি তারা প্রতিস্থাপন করে তার মধ্যে
ফাইল কনটেক্সট অমিল থাকলে, ডিভাইস-নির্দিষ্ট sepolicy-তে
তা উল্লেখ করুন। ডিরেক্টরি লেভেলে ফাইল কনটেক্সট সেট করা হয়। ভেন্ডর ওভারলে ডিরেক্টরির
ফাইল কনটেক্সট টার্গেট ডিরেক্টরির সাথে না মিললে
এবং ডিভাইস-নির্দিষ্ট sepolicy-তে সঠিক ফাইল কনটেক্সট উল্লেখ করা না থাকলে,
সেই ভেন্ডর ওভারলে ডিরেক্টরি টার্গেট ডিরেক্টরির উপর ওভারলে করা হয় না।
ভেন্ডর ওভারলে ব্যবহার করতে, কার্নেলকে অবশ্যই CONFIG_OVERLAY_FS=y সেট করে OverlayFS চালু করতে হবে। এছাড়াও, কার্নেলকে অবশ্যই
সাধারণ কার্নেল ৪.৪ বা তার পরের ভার্সন থেকে মার্জ করতে হবে অথবা "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
-
product/vendor_overlay-এdevice/google/device/device.mk-এর মধ্যে প্রি-বিল্ট ভেন্ডর ফাইল ইনস্টল করুন: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)। নন-A/B ডিভাইসে /recovery
সরিয়ে দেওয়া হলে এবং A/B স্কিমের মতো করা হলে, /boot পার্টিশনে আপডেট করার সময় সমস্যা হলে রিকভারি মোড
কাজ নাও করতে পারে। এই
কারণে, A/B নয় এমন ডিভাইসের জন্য /recovery পার্টিশনকে /boot থেকে আলাদা পার্টিশন
হতে হবে, এর অর্থ হল
যে রিকভারি ইমেজকে ডিফার্ড পদ্ধতিতে আপডেট করা চালিয়ে যাওয়া হয় (অর্থাৎ, Android 8.1.0 বা এর আগের ভার্সনে চলা ডিভাইসের মতো)।
নিম্নলিখিত সারণীতে Android 9-এর আগে ও পরে নন-A/B ডিভাইসের জন্য ইমেজ পার্টিশনের পার্থক্য তালিকাভুক্ত করা হয়েছে।
| ছবি | Ramdisk (Android 9-এর আগের ভার্সন) | System-as-root (Android 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 সেট-আপ করা
সিস্টেম-অ্যাজ-রুটে, কার্নেলকে অবশ্যই system.img-কে
/ (মাউন্ট পয়েন্ট) এর অধীনে
dm-verity সহ মাউন্ট করতে হবে। AOSP system.img-এর জন্য নিম্নলিখিত dm-verity
ইমপ্লিমেন্টেশন কাজ করে।
vboot 1.0
vboot 1.0-এর জন্য, কার্নেলকে অবশ্যই
Android-নির্দিষ্ট
মেটাডেটা পার্স করতে হবে
/system, তারপর dm-verity সেট-আপ করার জন্য
dm-verity প্যারামিটার-এ কনভার্ট করতে হবে (এর জন্য
এইসব কার্নেল প্যাচ প্রয়োজন)।
নিম্নলিখিত উদাহরণে কার্নেল কমান্ড লাইনে system-as-root-এর জন্য 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-এর জন্য
hashtree descriptor পার্স করে, এটিকে
dm-verity params-এ কনভার্ট করে এবং অবশেষে কার্নেল কমান্ড লাইনের মাধ্যমে
কার্নেলে প্যারামিটার পাস করে। (/system-এর হ্যাশট্রি ডেসক্রিপ্টর /vbmeta-এ অথবা /system-এ থাকতে পারে।)
vboot 2.0-এর জন্য নিম্নলিখিত কার্নেল প্যাচ প্রয়োজন:
- https://android-review.googlesource.com/#/c/kernel/common/+/158491/
- kernel 4.4 প্যাচ, kernel 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
দিয়ে যোগ করা যেকোনও ডিভাইস-নির্দিষ্ট রুট ফোল্ডার
চলে যায় কারণ সম্পূর্ণ রুট ডিরেক্টরি কন্টেন্টকে সিস্টেম-অ্যাজ-রুট GSI
দিয়ে পাল্টে দেওয়া হয়েছে। এইসব ফোল্ডার সরিয়ে দিলে, ডিভাইস-নির্দিষ্ট রুট ফোল্ডারের উপর নির্ভরতা থাকলে
ডিভাইসটি আনবুটেবল হয়ে যেতে পারে
(যেমন, সেগুলি মাউন্ট পয়েন্ট হিসেবে ব্যবহার করা হয়)।
এই সমস্যা এড়াতে, ডিভাইস-নির্দিষ্ট রুট ফোল্ডার যোগ করতে BOARD_ROOT_EXTRA_FOLDERS ব্যবহার করবেন না।
আপনাকে ডিভাইস-নির্দিষ্ট মাউন্ট পয়েন্ট উল্লেখ করতে হলে, /mnt/vendor/<mount point> ব্যবহার করুন (এই চেঞ্জলিস্টে
যোগ করা হয়েছে)। এইসব ভেন্ডর-নির্দিষ্ট মাউন্ট পয়েন্ট সরাসরি
fstab ডিভাইস ট্রি (প্রথম-পর্যায়ের মাউন্টের জন্য)
এবং /vendor/etc/fstab.{ro.hardware} ফাইল, দুটিতেই অতিরিক্ত সেট-আপ ছাড়াই
নির্দিষ্ট করা যেতে পারে (যেহেতু fs_mgr এগুলি
/mnt/vendor/*-এর অধীনে অটোমেটিক তৈরি করে)।