লিনাক্স কার্নেলের dm-লিনিয়ার ডিভাইস-ম্যাপার মডিউল ব্যবহার করে ডায়নামিক পার্টিশন প্রয়োগ করা হয়। super পার্টিশনে super -এর মধ্যে প্রতিটি ডায়নামিক পার্টিশনের নাম এবং ব্লক রেঞ্জ তালিকাভুক্ত মেটাডেটা রয়েছে। প্রথম-পর্যায়ের init সময়, এই মেটাডেটা পার্স করা হয় এবং যাচাই করা হয়, এবং ভার্চুয়াল ব্লক ডিভাইসগুলি প্রতিটি গতিশীল পার্টিশনের প্রতিনিধিত্ব করার জন্য তৈরি করা হয়।
একটি OTA প্রয়োগ করার সময়, গতিশীল পার্টিশনগুলি স্বয়ংক্রিয়ভাবে তৈরি, পুনরায় আকার দেওয়া বা প্রয়োজন অনুসারে মুছে ফেলা হয়। A/B ডিভাইসের জন্য, মেটাডেটার দুটি কপি রয়েছে এবং পরিবর্তনগুলি শুধুমাত্র লক্ষ্য স্লটের প্রতিনিধিত্বকারী অনুলিপিতে প্রয়োগ করা হয়।
যেহেতু ডাইনামিক পার্টিশন ইউজারস্পেসে প্রয়োগ করা হয়, বুটলোডারের জন্য প্রয়োজনীয় পার্টিশনগুলিকে গতিশীল করা যায় না। উদাহরণস্বরূপ, boot , dtbo , এবং vbmeta বুটলোডার দ্বারা পড়া হয় এবং তাই অবশ্যই শারীরিক পার্টিশন হিসাবে থাকতে হবে।
প্রতিটি ডাইনামিক পার্টিশন একটি আপডেট গ্রুপের অন্তর্গত হতে পারে। এই গ্রুপগুলি সেই গ্রুপের পার্টিশনগুলি ব্যবহার করতে পারে এমন সর্বাধিক স্থান সীমাবদ্ধ করে। উদাহরণস্বরূপ, system এবং vendor এমন একটি গোষ্ঠীর অন্তর্গত হতে পারে যা system এবং vendor মোট আকারকে সীমাবদ্ধ করে।
নতুন ডিভাইসে গতিশীল পার্টিশন প্রয়োগ করুন
এই বিভাগে Android 10 এবং উচ্চতর সংস্করণের সাথে লঞ্চ হওয়া নতুন ডিভাইসগুলিতে কীভাবে গতিশীল পার্টিশন প্রয়োগ করা যায় তার বিশদ বিবরণ রয়েছে৷ বিদ্যমান ডিভাইসগুলি আপডেট করতে, অ্যান্ড্রয়েড ডিভাইসগুলি আপগ্রেড করা দেখুন।
পার্টিশন পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য, super নামে একটি পার্টিশন তৈরি করুন। super পার্টিশন অভ্যন্তরীণভাবে A/B স্লট পরিচালনা করে, তাই A/B ডিভাইসগুলির জন্য আলাদা super_a এবং super_b পার্টিশনের প্রয়োজন হয় না। বুটলোডার দ্বারা ব্যবহৃত নয় এমন সমস্ত পঠনযোগ্য AOSP পার্টিশন অবশ্যই গতিশীল হতে হবে এবং অবশ্যই GUID পার্টিশন টেবিল (GPT) থেকে মুছে ফেলতে হবে। বিক্রেতা-নির্দিষ্ট পার্টিশনগুলি গতিশীল হতে হবে না এবং GPT-এ স্থাপন করা যেতে পারে।
super আকার অনুমান করতে, GPT থেকে মুছে ফেলা পার্টিশনের আকার যোগ করুন। A/B ডিভাইসের জন্য, এতে উভয় স্লটের আকার অন্তর্ভুক্ত করা উচিত। চিত্র 1 ডায়নামিক পার্টিশনে রূপান্তর করার আগে এবং পরে একটি উদাহরণ পার্টিশন টেবিল দেখায়।
সমর্থিত গতিশীল পার্টিশন হল:
- সিস্টেম
- বিক্রেতা
- পণ্য
- সিস্টেম Ext
- ওডিএম
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য, কার্নেল কমান্ড লাইন বিকল্প androidboot.super_partition খালি থাকতে হবে যাতে sysprop ro.boot.super_partition কমান্ডটি খালি থাকে।
বিভাজন প্রান্তিককরণ
super পার্টিশন সঠিকভাবে সারিবদ্ধ না হলে ডিভাইস-ম্যাপার মডিউল কম দক্ষতার সাথে কাজ করতে পারে। super পার্টিশনটি ব্লক স্তর দ্বারা নির্ধারিত ন্যূনতম I/O অনুরোধের আকারের সাথে সারিবদ্ধ হওয়া আবশ্যক। ডিফল্টরূপে, বিল্ড সিস্টেম ( lpmake এর মাধ্যমে, যা super পার্টিশন ইমেজ তৈরি করে), অনুমান করে যে প্রতিটি গতিশীল পার্টিশনের জন্য একটি 1 MiB প্রান্তিককরণ যথেষ্ট। যাইহোক, বিক্রেতাদের নিশ্চিত করা উচিত যে super পার্টিশনটি সঠিকভাবে সারিবদ্ধ করা হয়েছে।
আপনি sysfs পরিদর্শন করে একটি ব্লক ডিভাইসের ন্যূনতম অনুরোধের আকার নির্ধারণ করতে পারেন। যেমন:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
আপনি একই পদ্ধতিতে super পার্টিশনের সারিবদ্ধকরণ যাচাই করতে পারেন:
# cat /sys/block/sda/sda17/alignment_offsetপ্রান্তিককরণ অফসেট 0 হতে হবে।
ডিভাইস কনফিগারেশন পরিবর্তন
গতিশীল পার্টিশন সক্রিয় করতে, device.mk এ নিম্নলিখিত পতাকা যোগ করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে super পার্টিশনের আকার সেট করতে হবে:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
A/B ডিভাইসে, গতিশীল পার্টিশন চিত্রের মোট আকার super পার্টিশন আকারের অর্ধেকের বেশি হলে বিল্ড সিস্টেম একটি ত্রুটি ছুড়ে দেয়।
আপনি নিম্নরূপ গতিশীল পার্টিশনের তালিকা কনফিগার করতে পারেন। আপডেট গোষ্ঠীগুলি ব্যবহার করে ডিভাইসগুলির জন্য, BOARD_SUPER_PARTITION_GROUPS ভেরিয়েবলে গোষ্ঠীগুলিকে তালিকাভুক্ত করুন৷ প্রতিটি গ্রুপের নামের সাথে একটি BOARD_ group _SIZE এবং BOARD_ group _PARTITION_LIST ভেরিয়েবল থাকে। A/B ডিভাইসের জন্য, একটি গ্রুপের সর্বাধিক আকার শুধুমাত্র একটি স্লট কভার করা উচিত, কারণ গ্রুপের নামগুলি অভ্যন্তরীণভাবে স্লট-প্রত্যয়যুক্ত।
এখানে একটি উদাহরণ ডিভাইস যা সমস্ত পার্টিশনকে example_dynamic_partitions নামে একটি গ্রুপে রাখে:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
এখানে একটি উদাহরণ ডিভাইস যা সিস্টেম এবং পণ্য পরিষেবাগুলিকে group_foo , এবং vendor , product এবং odm group_bar এ রাখে:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
- ভার্চুয়াল A/B লঞ্চ ডিভাইসগুলির জন্য, সমস্ত গোষ্ঠীর সর্বাধিক আকারের যোগফল সর্বাধিক হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড
ভার্চুয়াল A/B বাস্তবায়ন দেখুন। - A/B লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক মাপের সমষ্টি হতে হবে:
BOARD_SUPER_PARTITION_SIZE/ 2 - ওভারহেড - নন-A/B ডিভাইস এবং রেট্রোফিট A/B ডিভাইসগুলির জন্য, সমস্ত গ্রুপের সর্বাধিক মাপের সমষ্টি হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড - বিল্ড টাইমে, আপডেট গ্রুপে প্রতিটি পার্টিশনের ইমেজের মাপের সমষ্টি অবশ্যই গ্রুপের সর্বোচ্চ আকারের বেশি হবে না।
- মেটাডেটা, সারিবদ্ধকরণ ইত্যাদির জন্য হিসাব করার জন্য গণনায় ওভারহেড প্রয়োজন। একটি যুক্তিসঙ্গত ওভারহেড হল 4 MiB, তবে আপনি ডিভাইসের প্রয়োজন অনুসারে একটি বড় ওভারহেড বেছে নিতে পারেন।
সাইজ ডাইনামিক পার্টিশন
ডায়নামিক পার্টিশনের আগে, পার্টিশনের মাপ অতিরিক্ত বরাদ্দ করা হয়েছিল যাতে ভবিষ্যতে আপডেটের জন্য যথেষ্ট জায়গা থাকে। প্রকৃত আকার যেমন আছে তেমন নেওয়া হয়েছিল এবং বেশিরভাগ পঠনযোগ্য পার্টিশনের ফাইল সিস্টেমে কিছু পরিমাণ ফাঁকা জায়গা ছিল। গতিশীল পার্টিশনে, সেই ফাঁকা স্থানটি ব্যবহারযোগ্য নয় এবং একটি OTA চলাকালীন পার্টিশন বৃদ্ধি করতে ব্যবহার করা যেতে পারে। পার্টিশনগুলি যাতে স্থান নষ্ট না করে এবং ন্যূনতম সম্ভাব্য আকারে বরাদ্দ করা হয় তা নিশ্চিত করা গুরুত্বপূর্ণ।
শুধুমাত্র পঠনযোগ্য ext4 চিত্রের জন্য, বিল্ড সিস্টেম স্বয়ংক্রিয়ভাবে ন্যূনতম আকার বরাদ্দ করে যদি কোনো হার্ডকোডেড পার্টিশনের আকার নির্দিষ্ট করা না থাকে। বিল্ড সিস্টেমটি ইমেজের সাথে ফিট করে যাতে ফাইল সিস্টেমে যতটা সম্ভব কম অব্যবহৃত স্থান থাকে। এটি নিশ্চিত করে যে ডিভাইসটি ওটিএর জন্য ব্যবহার করা যেতে পারে এমন স্থান নষ্ট করে না।
অতিরিক্তভাবে, ব্লক-লেভেল ডিডপ্লিকেশন সক্ষম করে ext4 চিত্রগুলিকে আরও সংকুচিত করা যেতে পারে। এটি সক্ষম করতে, নিম্নলিখিত কনফিগারেশন ব্যবহার করুন:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
পার্টিশনের ন্যূনতম আকারের স্বয়ংক্রিয় বরাদ্দ অবাঞ্ছিত হলে, পার্টিশনের আকার নিয়ন্ত্রণ করার দুটি উপায় রয়েছে। আপনি BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE সাথে ন্যূনতম পরিমাণ খালি স্থান নির্দিষ্ট করতে পারেন, অথবা আপনি একটি নির্দিষ্ট আকারে গতিশীল পার্টিশন জোর করতে BOARD_ partition IMAGE_PARTITION_SIZE নির্দিষ্ট করতে পারেন। প্রয়োজন না হলে এইগুলির কোনটিই সুপারিশ করা হয় না।
যেমন:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
এটি product.img এ ফাইল সিস্টেমকে 50 MiB অব্যবহৃত স্থান রাখতে বাধ্য করে।
রুট হিসাবে সিস্টেম পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে লঞ্চ করা ডিভাইসগুলি অবশ্যই রুট হিসাবে সিস্টেম ব্যবহার করবে না।
ডায়নামিক পার্টিশন সহ ডিভাইসগুলি (সেটি ডাইনামিক পার্টিশনের সাথে চালু হোক বা রেট্রোফিট করা হোক না কেন) সিস্টেম-এ-রুট ব্যবহার করা উচিত নয়। লিনাক্স কার্নেল super পার্টিশনকে ব্যাখ্যা করতে পারে না এবং তাই system নিজেই মাউন্ট করতে পারে না। system এখন প্রথম পর্যায়ের init দ্বারা মাউন্ট করা হয়েছে, যা ramdisk-এ থাকে।
BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করবেন না। অ্যান্ড্রয়েড 10-এ, BOARD_BUILD_SYSTEM_ROOT_IMAGE পতাকাটি শুধুমাত্র কার্নেল দ্বারা বা ramdisk-এ প্রথম-পর্যায়ের init দ্বারা মাউন্ট করা হয়েছে কিনা তা পার্থক্য করতে ব্যবহৃত হয়।
BOARD_BUILD_SYSTEM_ROOT_IMAGE true সেট করা বিল্ড ত্রুটির কারণ হয় যখন PRODUCT_USE_DYNAMIC_PARTITIONS ও true হয়৷
যখন BOARD_USES_RECOVERY_AS_BOOT সত্যে সেট করা হয়, তখন পুনরুদ্ধারের চিত্রটি boot.img হিসাবে তৈরি করা হয়, যার মধ্যে পুনরুদ্ধারের রামডিস্ক থাকে। পূর্বে, বুটলোডার কোন মোডে বুট করতে হবে তা নির্ধারণ করতে skip_initramfs কার্নেল কমান্ড লাইন প্যারামিটার ব্যবহার করত। অ্যান্ড্রয়েড 10 ডিভাইসের জন্য, বুটলোডার অবশ্যই কার্নেল কমান্ড-লাইনে skip_initramfs পাস করবে না। পরিবর্তে, পুনরুদ্ধার এড়াতে এবং স্বাভাবিক অ্যান্ড্রয়েড বুট করতে বুটলোডারের androidboot.force_normal_boot=1 পাস করা উচিত। অ্যান্ড্রয়েড 12 বা তার পরে চালু হওয়া ডিভাইসগুলিকে অবশ্যই androidboot.force_normal_boot=1 পাস করতে bootconfig ব্যবহার করতে হবে।
AVB কনফিগারেশন পরিবর্তন
অ্যান্ড্রয়েড ভেরিফাইড বুট 2.0 ব্যবহার করার সময়, ডিভাইসটি যদি চেইনড পার্টিশন বর্ণনাকারী ব্যবহার না করে, তাহলে কোনো পরিবর্তনের প্রয়োজন নেই। যদি চেইনযুক্ত পার্টিশন ব্যবহার করা হয়, এবং যাচাইকৃত পার্টিশনগুলির মধ্যে একটি গতিশীল হয়, তাহলে পরিবর্তনগুলি আবশ্যক।
এখানে একটি ডিভাইসের জন্য একটি উদাহরণ কনফিগারেশন রয়েছে যা system এবং vendor পার্টিশনের জন্য vbmeta চেইন করে।
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
এই কনফিগারেশনের মাধ্যমে, বুটলোডার system এবং vendor পার্টিশনের শেষে একটি vbmeta ফুটার খুঁজে পাওয়ার আশা করে। যেহেতু এই পার্টিশনগুলি আর বুটলোডারের কাছে দৃশ্যমান নয় (এগুলি super তে থাকে), দুটি পরিবর্তন প্রয়োজন।
- ডিভাইসের পার্টিশন টেবিলে
vbmeta_systemএবংvbmeta_vendorপার্টিশন যোগ করুন। A/B ডিভাইসের জন্য,vbmeta_system_a,vbmeta_system_b,vbmeta_vendor_a, এবংvbmeta_vendor_bযোগ করুন। এই পার্টিশনগুলির মধ্যে এক বা একাধিক যোগ করা হলে, সেগুলিvbmetaপার্টিশনের সমান হওয়া উচিত। -
VBMETA_যোগ করে কনফিগারেশন ফ্ল্যাগগুলির পুনঃনামকরণ করুন এবং কোন পার্টিশনে চেইনিং প্রসারিত হবে তা নির্দিষ্ট করুন:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
একটি ডিভাইস একটি, উভয়, বা এই পার্টিশনগুলির একটিও ব্যবহার করতে পারে। লজিক্যাল পার্টিশনে চেইন করার সময়ই পরিবর্তন প্রয়োজন।
AVB বুটলোডার পরিবর্তন
যদি বুটলোডার libavb এম্বেড করে থাকে, তাহলে নিম্নলিখিত প্যাচগুলি অন্তর্ভুক্ত করুন:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: cmdline-এর প্রয়োজন হলেই পার্টিশন GUID-গুলিকে জিজ্ঞাসা করুন।"
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "সিস্টেম পার্টিশনকে অনুপস্থিত থাকার অনুমতি দিন"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Fix AvbSlotVerifyData->cmdline NULL হতে পারে"
শৃঙ্খলিত পার্টিশন ব্যবহার করলে, একটি অতিরিক্ত প্যাচ অন্তর্ভুক্ত করুন:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: পার্টিশনের শুরুতে vbmeta blobs সমর্থন করে।"
কার্নেল কমান্ড লাইন পরিবর্তন
কার্নেল কমান্ড লাইনে একটি নতুন প্যারামিটার, androidboot.boot_devices যোগ করতে হবে। এটি /dev/block/by-name symlinks সক্রিয় করতে init দ্বারা ব্যবহৃত হয়। এটি ueventd দ্বারা তৈরি অন্তর্নিহিত বাই-নেম সিমলিংকের ডিভাইস পাথ উপাদান হওয়া উচিত, অর্থাৎ, /dev/block/platform/ device-path /by-name/ partition-name Android 12 বা তার পরবর্তী সংস্করণের সাথে লঞ্চ করা ডিভাইসগুলিকে androidboot.boot_devices কে init করার জন্য bootconfig ব্যবহার করতে হবে।
উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিংক /dev/block/platform/ soc/100000.ufshc /by-name/super হয়, তাহলে আপনি BoardConfig.mk ফাইলে কমান্ড লাইন প্যারামিটারটি নিম্নরূপ যোগ করতে পারেন:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
fstab পরিবর্তন
ডিভাইস ট্রি এবং ডিভাইস ট্রি ওভারলেতে fstab এন্ট্রি থাকা উচিত নয়। একটি fstab ফাইল ব্যবহার করুন যা ramdisk এর অংশ হবে।
লজিক্যাল পার্টিশনের জন্য fstab ফাইলে পরিবর্তন করা আবশ্যক:
- fs_mgr পতাকা ক্ষেত্রের মধ্যে অবশ্যই
logicalপতাকা এবং Android 10-এ প্রবর্তিতfirst_stage_mountপতাকা অন্তর্ভুক্ত থাকতে হবে, যা নির্দেশ করে যে প্রথম পর্যায়ে একটি পার্টিশন মাউন্ট করা হবে। - একটি পার্টিশন
fs_mgrপতাকা হিসাবেavb= vbmeta partition nameউল্লেখ করতে পারে এবং তারপরে নির্দিষ্টvbmetaপার্টিশনটি কোনো ডিভাইস মাউন্ট করার চেষ্টা করার আগে প্রথম পর্যায়েinitদ্বারা আরম্ভ করা হয়। -
devক্ষেত্রটি অবশ্যই পার্টিশনের নাম হতে হবে।
নিম্নলিখিত fstab এন্ট্রিগুলি উপরোক্ত নিয়মগুলি অনুসরণ করে সিস্টেম, বিক্রেতা এবং পণ্যকে লজিক্যাল পার্টিশন হিসাবে সেট করে।
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
প্রথম পর্যায়ের রামডিস্কে fstab ফাইলটি অনুলিপি করুন।
SELinux পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইস অবশ্যই super_block_device লেবেল দিয়ে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিংক /dev/block/platform/ soc/100000.ufshc /by-name/super হয়, তাহলে file_contexts এ নিম্নলিখিত লাইন যোগ করুন:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
fastbootd
বুটলোডার (বা যেকোন নন-ইউজারস্পেস ফ্ল্যাশিং টুল) ডাইনামিক পার্টিশন বোঝে না, তাই এটি তাদের ফ্ল্যাশ করতে পারে না। এটি মোকাবেলা করার জন্য, ডিভাইসগুলিকে fastboot প্রোটোকলের একটি ব্যবহারকারী-স্পেস বাস্তবায়ন ব্যবহার করতে হবে, যাকে বলা হয় fastbootd।
কিভাবে fastbootd প্রয়োগ করতে হয় সে সম্পর্কে আরও তথ্যের জন্য, দেখুন ফাস্টবুটকে ইউজার স্পেসে সরানো ।
adb রিমাউন্ট
eng বা userdebug বিল্ড ব্যবহার করে ডেভেলপারদের জন্য, দ্রুত পুনরাবৃত্তির জন্য adb remount অত্যন্ত উপযোগী। ডায়নামিক পার্টিশনগুলি adb remount জন্য একটি সমস্যা তৈরি করে কারণ প্রতিটি ফাইল সিস্টেমের মধ্যে আর ফাঁকা জায়গা নেই। এটি মোকাবেলা করার জন্য, ডিভাইসগুলি ওভারলেফগুলি সক্ষম করতে পারে। যতক্ষণ পর্যন্ত সুপার পার্টিশনের মধ্যে ফাঁকা জায়গা থাকে, ততক্ষণ adb remount স্বয়ংক্রিয়ভাবে একটি অস্থায়ী গতিশীল পার্টিশন তৈরি করে এবং লেখার জন্য ওভারলেফ ব্যবহার করে। অস্থায়ী পার্টিশনটির নাম scratch , তাই অন্য পার্টিশনের জন্য এই নামটি ব্যবহার করবেন না।
কিভাবে overlayfs সক্ষম করতে হয় সে সম্পর্কে আরও তথ্যের জন্য, AOSP-এ overlayfs README দেখুন।
অ্যান্ড্রয়েড ডিভাইস আপগ্রেড করুন
আপনি যদি Android 10-এ একটি ডিভাইস আপগ্রেড করেন এবং OTA-তে গতিশীল পার্টিশন সমর্থন অন্তর্ভুক্ত করতে চান, তাহলে আপনাকে বিল্ট-ইন পার্টিশন টেবিল পরিবর্তন করতে হবে না। কিছু অতিরিক্ত কনফিগারেশন প্রয়োজন.
ডিভাইস কনফিগারেশন পরিবর্তন
গতিশীল পার্টিশনের পুনরুদ্ধার করতে, device.mk এ নিম্নলিখিত ফ্ল্যাগগুলি যুক্ত করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে নিম্নলিখিত বোর্ড ভেরিয়েবল সেট করতে হবে:
-
BOARD_SUPER_PARTITION_BLOCK_DEVICESব্লক ডিভাইসের তালিকায় সেট করুন যা ডায়নামিক পার্টিশনের পরিমাণ সঞ্চয় করতে ব্যবহৃত হয়। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের নামের তালিকা। - যথাক্রমে
BOARD_SUPER_PARTITION_BLOCK_DEVICESএ প্রতিটি ব্লক ডিভাইসের আকারেBOARD_SUPER_PARTITION_ partition _DEVICE_SIZEসেট করুন। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের আকারের তালিকা। বিদ্যমান বোর্ড কনফিগারেশনে এটি সাধারণতBOARD_ partition IMAGE_PARTITION_SIZE। -
BOARD_SUPER_PARTITION_BLOCK_DEVICESএ সমস্ত পার্টিশনের জন্য বিদ্যমানBOARD_ partition IMAGE_PARTITION_SIZEআনসেট করুন। -
BOARD_SUPER_PARTITION_SIZEBOARD_SUPER_PARTITION_ partition _DEVICE_SIZEএ সেট করুন। -
BOARD_SUPER_PARTITION_METADATA_DEVICEব্লক ডিভাইসে সেট করুন যেখানে ডায়নামিক পার্টিশন মেটাডেটা সংরক্ষণ করা হয়। এটি অবশ্যইBOARD_SUPER_PARTITION_BLOCK_DEVICESএর মধ্যে একটি হতে হবে। সাধারণত, এটিsystemসেট করা হয়। - যথাক্রমে
BOARD_SUPER_PARTITION_GROUPS,BOARD_ group _SIZEএবংBOARD_ group _PARTITION_LISTসেট করুন। বিস্তারিত জানার জন্য নতুন ডিভাইসে বোর্ড কনফিগারেশন পরিবর্তন দেখুন।
উদাহরণস্বরূপ, যদি ডিভাইসটিতে ইতিমধ্যে সিস্টেম এবং ভেন্ডর পার্টিশন থাকে এবং আপনি সেগুলিকে গতিশীল পার্টিশনে রূপান্তর করতে চান এবং আপডেটের সময় একটি নতুন পণ্য পার্টিশন যোগ করতে চান, এই বোর্ড কনফিগারেশন সেট করুন:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
SELinux পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইসগুলিকে super_block_device_type এট্রিবিউট দিয়ে চিহ্নিত করা আবশ্যক। উদাহরণস্বরূপ, যদি ডিভাইসে ইতিমধ্যেই system এবং vendor পার্টিশন থাকে, আপনি ডায়নামিক পার্টিশনের পরিমাণ সঞ্চয় করার জন্য সেগুলিকে ব্লক ডিভাইস হিসাবে ব্যবহার করতে চান এবং তাদের নামের সিমলিংকগুলিকে system_block_device হিসাবে চিহ্নিত করা হয়েছে :
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
তারপর, device.te এ নিম্নলিখিত লাইনটি যুক্ত করুন:
typeattribute system_block_device super_block_device_type;
অন্যান্য কনফিগারেশনের জন্য, নতুন ডিভাইসে গতিশীল পার্টিশন প্রয়োগ করা দেখুন।
রেট্রোফিট আপডেট সম্পর্কে আরও তথ্যের জন্য, ডায়নামিক পার্টিশন ছাড়া A/B ডিভাইসের জন্য OTA দেখুন।
কারখানার ছবি
ডায়নামিক পার্টিশন সাপোর্ট সহ লঞ্চ করা ডিভাইসের জন্য, ফ্যাক্টরি ইমেজ ফ্ল্যাশ করতে ইউজারস্পেস ফাস্টবুট ব্যবহার করা এড়িয়ে চলুন, কারণ ইউজারস্পেসে বুট করা অন্যান্য ফ্ল্যাশিং পদ্ধতির তুলনায় ধীর।
এর সমাধানের জন্য, make dist এখন একটি অতিরিক্ত super.img ইমেজ তৈরি করে যা সরাসরি সুপার পার্টিশনে ফ্ল্যাশ করা যায়। এটি স্বয়ংক্রিয়ভাবে লজিক্যাল পার্টিশনের বিষয়বস্তুগুলিকে বান্ডেল করে, যার অর্থ এতে super পার্টিশন মেটাডেটা ছাড়াও system.img , vendor.img , এবং আরও অনেক কিছু রয়েছে৷ এই ছবিটি কোনো অতিরিক্ত টুলিং বা fastbootd ব্যবহার না করে সরাসরি super পার্টিশনে ফ্ল্যাশ করা যেতে পারে। বিল্ড করার পরে, super.img ${ANDROID_PRODUCT_OUT} এ স্থাপন করা হয়।
A/B ডিভাইসগুলির জন্য যেগুলি গতিশীল পার্টিশনের সাথে চালু হয়, super.img এ A স্লটে ছবি থাকে। সুপার ইমেজ সরাসরি ফ্ল্যাশ করার পরে, ডিভাইসটি রিবুট করার আগে স্লট A বুটযোগ্য হিসাবে চিহ্নিত করুন।
রেট্রোফিট ডিভাইসের জন্য, make dist super_*.img ইমেজের একটি সেট তৈরি করে যা সরাসরি সংশ্লিষ্ট ফিজিক্যাল পার্টিশনে ফ্ল্যাশ করা যায়। উদাহরণস্বরূপ, যখন BOARD_SUPER_PARTITION_BLOCK_DEVICES সিস্টেম বিক্রেতা হয় তখন make dist builds super_system.img এবং super_vendor.img তৈরি করুন। এই ছবিগুলি target_files.zip এ OTA ফোল্ডারে রাখা হয়েছে।
ডিভাইস ম্যাপার স্টোরেজ-ডিভাইস টিউনিং
ডায়নামিক পার্টিশনিং অনেকগুলি ননডিটারমিনিস্টিক ডিভাইস-ম্যাপার অবজেক্টকে মিটমাট করে। এগুলি সবগুলি প্রত্যাশিত হিসাবে তাত্ক্ষণিক নাও হতে পারে, তাই আপনাকে অবশ্যই সমস্ত মাউন্ট ট্র্যাক করতে হবে এবং তাদের অন্তর্নিহিত স্টোরেজ ডিভাইসগুলির সাথে সমস্ত সংশ্লিষ্ট পার্টিশনের Android বৈশিষ্ট্যগুলি আপডেট করতে হবে৷
init ভিতরের একটি প্রক্রিয়া মাউন্টগুলিকে ট্র্যাক করে এবং অ্যাসিঙ্ক্রোনাসভাবে Android বৈশিষ্ট্যগুলিকে আপডেট করে। এটি যে পরিমাণ সময় নেয় তা একটি নির্দিষ্ট সময়ের মধ্যে হওয়ার গ্যারান্টি দেওয়া হয় না, তাই আপনাকে অবশ্যই on property ট্রিগারগুলিতে প্রতিক্রিয়া জানানোর জন্য পর্যাপ্ত সময় দিতে হবে। বৈশিষ্ট্যগুলি হল dev.mnt.blk. <partition> যেখানে <partition> হল root , system , data বা vendor , উদাহরণস্বরূপ। প্রতিটি সম্পত্তি বেস স্টোরেজ-ডিভাইস নামের সাথে যুক্ত, যেমন এই উদাহরণগুলিতে দেখানো হয়েছে:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
init.rc ভাষা নিয়মের অংশ হিসাবে অ্যান্ড্রয়েড বৈশিষ্ট্যগুলিকে প্রসারিত করার অনুমতি দেয় এবং স্টোরেজ ডিভাইসগুলিকে প্ল্যাটফর্মের দ্বারা এই ধরনের কমান্ডের সাথে প্রয়োজন অনুসারে টিউন করা যেতে পারে:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
দ্বিতীয় পর্যায়ের init এ কমান্ড প্রসেসিং শুরু হলে, epoll loop সক্রিয় হয়, এবং মানগুলি আপডেট হতে শুরু করে। যাইহোক, যেহেতু প্রপার্টি ট্রিগারগুলি দেরী- init পর্যন্ত সক্রিয় থাকে না, তাই root , system বা vendor পরিচালনা করতে প্রাথমিক বুট পর্যায়ে ব্যবহার করা যাবে না। init.rc স্ক্রিপ্ট early-fs (যখন বিভিন্ন ডেমন এবং সুবিধা শুরু হয়) ওভাররাইড না করা পর্যন্ত আপনি কার্নেল ডিফল্ট read_ahead_kb যথেষ্ট হবে বলে আশা করতে পারেন। তাই, Google সুপারিশ করে যে আপনি একটি init.rc -নিয়ন্ত্রিত প্রপার্টি যেমন sys.read_ahead_kb সাথে মিলিত on property বৈশিষ্ট্যটি ব্যবহার করুন, ক্রিয়াকলাপগুলির সময়কে মোকাবেলা করতে এবং জাতি পরিস্থিতি প্রতিরোধ করতে, এই উদাহরণগুলির মতো:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}
লিনাক্স কার্নেলের dm-লিনিয়ার ডিভাইস-ম্যাপার মডিউল ব্যবহার করে ডায়নামিক পার্টিশন প্রয়োগ করা হয়। super পার্টিশনে super -এর মধ্যে প্রতিটি ডায়নামিক পার্টিশনের নাম এবং ব্লক রেঞ্জ তালিকাভুক্ত মেটাডেটা রয়েছে। প্রথম-পর্যায়ের init সময়, এই মেটাডেটা পার্স করা হয় এবং যাচাই করা হয়, এবং ভার্চুয়াল ব্লক ডিভাইসগুলি প্রতিটি গতিশীল পার্টিশনের প্রতিনিধিত্ব করার জন্য তৈরি করা হয়।
একটি OTA প্রয়োগ করার সময়, গতিশীল পার্টিশনগুলি স্বয়ংক্রিয়ভাবে তৈরি, পুনরায় আকার দেওয়া বা প্রয়োজন অনুসারে মুছে ফেলা হয়। A/B ডিভাইসের জন্য, মেটাডেটার দুটি কপি রয়েছে এবং পরিবর্তনগুলি শুধুমাত্র লক্ষ্য স্লটের প্রতিনিধিত্বকারী অনুলিপিতে প্রয়োগ করা হয়।
যেহেতু ডাইনামিক পার্টিশন ইউজারস্পেসে প্রয়োগ করা হয়, বুটলোডারের জন্য প্রয়োজনীয় পার্টিশনগুলিকে গতিশীল করা যায় না। উদাহরণস্বরূপ, boot , dtbo , এবং vbmeta বুটলোডার দ্বারা পড়া হয় এবং তাই অবশ্যই শারীরিক পার্টিশন হিসাবে থাকতে হবে।
প্রতিটি ডাইনামিক পার্টিশন একটি আপডেট গ্রুপের অন্তর্গত হতে পারে। এই গ্রুপগুলি সেই গ্রুপের পার্টিশনগুলি ব্যবহার করতে পারে এমন সর্বাধিক স্থান সীমাবদ্ধ করে। উদাহরণস্বরূপ, system এবং vendor এমন একটি গোষ্ঠীর অন্তর্গত হতে পারে যা system এবং vendor মোট আকারকে সীমাবদ্ধ করে।
নতুন ডিভাইসে গতিশীল পার্টিশন প্রয়োগ করুন
এই বিভাগে Android 10 এবং উচ্চতর সংস্করণের সাথে লঞ্চ হওয়া নতুন ডিভাইসগুলিতে কীভাবে গতিশীল পার্টিশন প্রয়োগ করা যায় তার বিশদ বিবরণ রয়েছে৷ বিদ্যমান ডিভাইসগুলি আপডেট করতে, অ্যান্ড্রয়েড ডিভাইসগুলি আপগ্রেড করা দেখুন।
পার্টিশন পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য, super নামে একটি পার্টিশন তৈরি করুন। super পার্টিশন অভ্যন্তরীণভাবে A/B স্লট পরিচালনা করে, তাই A/B ডিভাইসগুলির জন্য আলাদা super_a এবং super_b পার্টিশনের প্রয়োজন হয় না। বুটলোডার দ্বারা ব্যবহৃত নয় এমন সমস্ত পঠনযোগ্য AOSP পার্টিশন অবশ্যই গতিশীল হতে হবে এবং অবশ্যই GUID পার্টিশন টেবিল (GPT) থেকে মুছে ফেলতে হবে। বিক্রেতা-নির্দিষ্ট পার্টিশনগুলি গতিশীল হতে হবে না এবং GPT-এ স্থাপন করা যেতে পারে।
super আকার অনুমান করতে, GPT থেকে মুছে ফেলা পার্টিশনের আকার যোগ করুন। A/B ডিভাইসের জন্য, এতে উভয় স্লটের আকার অন্তর্ভুক্ত করা উচিত। চিত্র 1 ডায়নামিক পার্টিশনে রূপান্তর করার আগে এবং পরে একটি উদাহরণ পার্টিশন টেবিল দেখায়।
সমর্থিত গতিশীল পার্টিশন হল:
- সিস্টেম
- বিক্রেতা
- পণ্য
- সিস্টেম Ext
- ওডিএম
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলির জন্য, কার্নেল কমান্ড লাইন বিকল্প androidboot.super_partition খালি থাকতে হবে যাতে sysprop ro.boot.super_partition কমান্ডটি খালি থাকে।
বিভাজন প্রান্তিককরণ
super পার্টিশন সঠিকভাবে সারিবদ্ধ না হলে ডিভাইস-ম্যাপার মডিউল কম দক্ষতার সাথে কাজ করতে পারে। super পার্টিশনটি ব্লক স্তর দ্বারা নির্ধারিত ন্যূনতম I/O অনুরোধের আকারের সাথে সারিবদ্ধ হওয়া আবশ্যক। ডিফল্টরূপে, বিল্ড সিস্টেম ( lpmake এর মাধ্যমে, যা super পার্টিশন ইমেজ তৈরি করে), অনুমান করে যে প্রতিটি গতিশীল পার্টিশনের জন্য একটি 1 MiB প্রান্তিককরণ যথেষ্ট। যাইহোক, বিক্রেতাদের নিশ্চিত করা উচিত যে super পার্টিশনটি সঠিকভাবে সারিবদ্ধ করা হয়েছে।
আপনি sysfs পরিদর্শন করে একটি ব্লক ডিভাইসের ন্যূনতম অনুরোধের আকার নির্ধারণ করতে পারেন। যেমন:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
আপনি একই পদ্ধতিতে super পার্টিশনের সারিবদ্ধকরণ যাচাই করতে পারেন:
# cat /sys/block/sda/sda17/alignment_offsetপ্রান্তিককরণ অফসেট 0 হতে হবে।
ডিভাইস কনফিগারেশন পরিবর্তন
গতিশীল পার্টিশন সক্রিয় করতে, device.mk এ নিম্নলিখিত পতাকা যোগ করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে super পার্টিশনের আকার সেট করতে হবে:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
A/B ডিভাইসে, গতিশীল পার্টিশন চিত্রের মোট আকার super পার্টিশন আকারের অর্ধেকের বেশি হলে বিল্ড সিস্টেম একটি ত্রুটি ছুড়ে দেয়।
আপনি নিম্নরূপ গতিশীল পার্টিশনের তালিকা কনফিগার করতে পারেন। আপডেট গোষ্ঠীগুলি ব্যবহার করে ডিভাইসগুলির জন্য, BOARD_SUPER_PARTITION_GROUPS ভেরিয়েবলে গোষ্ঠীগুলিকে তালিকাভুক্ত করুন৷ প্রতিটি গ্রুপের নামের সাথে একটি BOARD_ group _SIZE এবং BOARD_ group _PARTITION_LIST ভেরিয়েবল থাকে। A/B ডিভাইসের জন্য, একটি গ্রুপের সর্বাধিক আকার শুধুমাত্র একটি স্লট কভার করা উচিত, কারণ গ্রুপের নামগুলি অভ্যন্তরীণভাবে স্লট-প্রত্যয়যুক্ত।
এখানে একটি উদাহরণ ডিভাইস যা সমস্ত পার্টিশনকে example_dynamic_partitions নামে একটি গ্রুপে রাখে:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
এখানে একটি উদাহরণ ডিভাইস যা সিস্টেম এবং পণ্য পরিষেবাগুলিকে group_foo , এবং vendor , product এবং odm group_bar এ রাখে:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
- ভার্চুয়াল A/B লঞ্চ ডিভাইসগুলির জন্য, সমস্ত গোষ্ঠীর সর্বাধিক আকারের যোগফল সর্বাধিক হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড
ভার্চুয়াল A/B বাস্তবায়ন দেখুন। - A/B লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক মাপের সমষ্টি হতে হবে:
BOARD_SUPER_PARTITION_SIZE/ 2 - ওভারহেড - নন-A/B ডিভাইস এবং রেট্রোফিট A/B ডিভাইসগুলির জন্য, সমস্ত গ্রুপের সর্বাধিক মাপের সমষ্টি হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড - বিল্ড টাইমে, আপডেট গ্রুপে প্রতিটি পার্টিশনের ইমেজের মাপের সমষ্টি অবশ্যই গ্রুপের সর্বোচ্চ আকারের বেশি হবে না।
- মেটাডেটা, সারিবদ্ধকরণ ইত্যাদির জন্য হিসাব করার জন্য গণনায় ওভারহেড প্রয়োজন। একটি যুক্তিসঙ্গত ওভারহেড হল 4 MiB, তবে আপনি ডিভাইসের প্রয়োজন অনুসারে একটি বড় ওভারহেড বেছে নিতে পারেন।
সাইজ ডাইনামিক পার্টিশন
ডায়নামিক পার্টিশনের আগে, পার্টিশনের মাপ অতিরিক্ত বরাদ্দ করা হয়েছিল যাতে ভবিষ্যতে আপডেটের জন্য যথেষ্ট জায়গা থাকে। প্রকৃত আকার যেমন আছে তেমন নেওয়া হয়েছিল এবং বেশিরভাগ পঠনযোগ্য পার্টিশনের ফাইল সিস্টেমে কিছু পরিমাণ ফাঁকা জায়গা ছিল। গতিশীল পার্টিশনে, সেই ফাঁকা স্থানটি ব্যবহারযোগ্য নয় এবং একটি OTA চলাকালীন পার্টিশন বৃদ্ধি করতে ব্যবহার করা যেতে পারে। পার্টিশনগুলি যাতে স্থান নষ্ট না করে এবং ন্যূনতম সম্ভাব্য আকারে বরাদ্দ করা হয় তা নিশ্চিত করা গুরুত্বপূর্ণ।
শুধুমাত্র পঠনযোগ্য ext4 চিত্রের জন্য, বিল্ড সিস্টেম স্বয়ংক্রিয়ভাবে ন্যূনতম আকার বরাদ্দ করে যদি কোনো হার্ডকোডেড পার্টিশনের আকার নির্দিষ্ট করা না থাকে। বিল্ড সিস্টেমটি ইমেজের সাথে ফিট করে যাতে ফাইল সিস্টেমে যতটা সম্ভব কম অব্যবহৃত স্থান থাকে। এটি নিশ্চিত করে যে ডিভাইসটি ওটিএর জন্য ব্যবহার করা যেতে পারে এমন স্থান নষ্ট করে না।
অতিরিক্তভাবে, ব্লক-লেভেল ডিডপ্লিকেশন সক্ষম করে ext4 চিত্রগুলিকে আরও সংকুচিত করা যেতে পারে। এটি সক্ষম করতে, নিম্নলিখিত কনফিগারেশন ব্যবহার করুন:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
পার্টিশনের ন্যূনতম আকারের স্বয়ংক্রিয় বরাদ্দ অবাঞ্ছিত হলে, পার্টিশনের আকার নিয়ন্ত্রণ করার দুটি উপায় রয়েছে। আপনি BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE সাথে ন্যূনতম পরিমাণ খালি স্থান নির্দিষ্ট করতে পারেন, অথবা আপনি একটি নির্দিষ্ট আকারে গতিশীল পার্টিশন জোর করতে BOARD_ partition IMAGE_PARTITION_SIZE নির্দিষ্ট করতে পারেন। প্রয়োজন না হলে এইগুলির কোনটিই সুপারিশ করা হয় না।
যেমন:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
এটি product.img এ ফাইল সিস্টেমকে 50 MiB অব্যবহৃত স্থান রাখতে বাধ্য করে।
রুট হিসাবে সিস্টেম পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে লঞ্চ করা ডিভাইসগুলি অবশ্যই রুট হিসাবে সিস্টেম ব্যবহার করবে না।
ডাইনামিক পার্টিশন সহ ডিভাইসগুলি (তা ডায়নামিক পার্টিশনের সাথে চালু হোক বা রেট্রোফিট করা হোক না কেন) সিস্টেম-এ-রুট ব্যবহার করা উচিত নয়। লিনাক্স কার্নেল super পার্টিশনকে ব্যাখ্যা করতে পারে না এবং তাই system নিজেই মাউন্ট করতে পারে না। system এখন প্রথম পর্যায়ের init দ্বারা মাউন্ট করা হয়েছে, যা ramdisk-এ থাকে।
BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করবেন না। অ্যান্ড্রয়েড 10-এ, BOARD_BUILD_SYSTEM_ROOT_IMAGE পতাকাটি শুধুমাত্র কার্নেল দ্বারা বা ramdisk-এ প্রথম-পর্যায়ের init দ্বারা মাউন্ট করা হয়েছে কিনা তা পার্থক্য করতে ব্যবহৃত হয়।
BOARD_BUILD_SYSTEM_ROOT_IMAGE true সেট করা বিল্ড ত্রুটির কারণ হয় যখন PRODUCT_USE_DYNAMIC_PARTITIONS ও true হয়৷
যখন BOARD_USES_RECOVERY_AS_BOOT সত্যে সেট করা হয়, তখন পুনরুদ্ধারের চিত্রটি boot.img হিসাবে তৈরি করা হয়, যার মধ্যে পুনরুদ্ধারের রামডিস্ক থাকে। পূর্বে, বুটলোডার কোন মোডে বুট করতে হবে তা নির্ধারণ করতে skip_initramfs কার্নেল কমান্ড লাইন প্যারামিটার ব্যবহার করত। অ্যান্ড্রয়েড 10 ডিভাইসের জন্য, বুটলোডার অবশ্যই কার্নেল কমান্ড-লাইনে skip_initramfs পাস করবে না। পরিবর্তে, পুনরুদ্ধার এড়াতে এবং স্বাভাবিক অ্যান্ড্রয়েড বুট করতে বুটলোডারের androidboot.force_normal_boot=1 পাস করা উচিত। অ্যান্ড্রয়েড 12 বা তার পরে চালু হওয়া ডিভাইসগুলিকে অবশ্যই androidboot.force_normal_boot=1 পাস করতে bootconfig ব্যবহার করতে হবে।
AVB কনফিগারেশন পরিবর্তন
অ্যান্ড্রয়েড ভেরিফাইড বুট 2.0 ব্যবহার করার সময়, ডিভাইসটি যদি চেইনড পার্টিশন বর্ণনাকারী ব্যবহার না করে, তাহলে কোনো পরিবর্তনের প্রয়োজন নেই। যদি চেইনযুক্ত পার্টিশন ব্যবহার করা হয়, এবং যাচাইকৃত পার্টিশনগুলির মধ্যে একটি গতিশীল হয়, তাহলে পরিবর্তনগুলি আবশ্যক।
এখানে একটি ডিভাইসের জন্য একটি উদাহরণ কনফিগারেশন রয়েছে যা system এবং vendor পার্টিশনের জন্য vbmeta চেইন করে।
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
এই কনফিগারেশনের মাধ্যমে, বুটলোডার system এবং vendor পার্টিশনের শেষে একটি vbmeta ফুটার খুঁজে পাওয়ার আশা করে। যেহেতু এই পার্টিশনগুলি আর বুটলোডারের কাছে দৃশ্যমান নয় (এগুলি super তে থাকে), দুটি পরিবর্তন প্রয়োজন।
- ডিভাইসের পার্টিশন টেবিলে
vbmeta_systemএবংvbmeta_vendorপার্টিশন যোগ করুন। A/B ডিভাইসের জন্য,vbmeta_system_a,vbmeta_system_b,vbmeta_vendor_a, এবংvbmeta_vendor_bযোগ করুন। এই পার্টিশনগুলির মধ্যে এক বা একাধিক যোগ করা হলে, সেগুলিvbmetaপার্টিশনের সমান হওয়া উচিত। -
VBMETA_যোগ করে কনফিগারেশন ফ্ল্যাগগুলির পুনঃনামকরণ করুন এবং কোন পার্টিশনে চেইনিং প্রসারিত হবে তা নির্দিষ্ট করুন:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
একটি ডিভাইস একটি, উভয়, বা এই পার্টিশনগুলির একটিও ব্যবহার করতে পারে। লজিক্যাল পার্টিশনে চেইন করার সময়ই পরিবর্তন প্রয়োজন।
AVB বুটলোডার পরিবর্তন
যদি বুটলোডার libavb এম্বেড করে থাকে, তাহলে নিম্নলিখিত প্যাচগুলি অন্তর্ভুক্ত করুন:
- 818cf56740775446285466eda984acedd4baeac0 — "libavb: cmdline-এর প্রয়োজন হলেই পার্টিশন GUID-গুলিকে জিজ্ঞাসা করুন।"
- 5abd6bc2578968d24406d834471adfd995a0c2e9 — "সিস্টেম পার্টিশনকে অনুপস্থিত থাকার অনুমতি দিন"
- 9ba3b6613b4e5130fa01a11d984c6b5f0eb3af05 — "Fix AvbSlotVerifyData->cmdline NULL হতে পারে"
শৃঙ্খলিত পার্টিশন ব্যবহার করলে, একটি অতিরিক্ত প্যাচ অন্তর্ভুক্ত করুন:
- 49936b4c0109411fdd38bd4ba3a32a01c40439a9 — "libavb: পার্টিশনের শুরুতে vbmeta blobs সমর্থন করে।"
কার্নেল কমান্ড লাইন পরিবর্তন
কার্নেল কমান্ড লাইনে একটি নতুন প্যারামিটার, androidboot.boot_devices যোগ করতে হবে। এটি /dev/block/by-name symlinks সক্রিয় করতে init দ্বারা ব্যবহৃত হয়। এটি ueventd দ্বারা তৈরি অন্তর্নিহিত বাই-নেম সিমলিংকের ডিভাইস পাথ উপাদান হওয়া উচিত, অর্থাৎ, /dev/block/platform/ device-path /by-name/ partition-name Android 12 বা তার পরবর্তী সংস্করণের সাথে লঞ্চ করা ডিভাইসগুলিকে androidboot.boot_devices কে init করার জন্য bootconfig ব্যবহার করতে হবে।
উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিংক /dev/block/platform/ soc/100000.ufshc /by-name/super হয়, তাহলে আপনি BoardConfig.mk ফাইলে কমান্ড লাইন প্যারামিটারটি নিম্নরূপ যোগ করতে পারেন:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
fstab পরিবর্তন
ডিভাইস ট্রি এবং ডিভাইস ট্রি ওভারলেতে fstab এন্ট্রি থাকা উচিত নয়। একটি fstab ফাইল ব্যবহার করুন যা ramdisk এর অংশ হবে।
লজিক্যাল পার্টিশনের জন্য fstab ফাইলে পরিবর্তন করা আবশ্যক:
- fs_mgr পতাকা ক্ষেত্রের মধ্যে অবশ্যই
logicalপতাকা এবং Android 10-এ প্রবর্তিতfirst_stage_mountপতাকা অন্তর্ভুক্ত থাকতে হবে, যা নির্দেশ করে যে প্রথম পর্যায়ে একটি পার্টিশন মাউন্ট করা হবে। - একটি পার্টিশন
fs_mgrপতাকা হিসাবেavb= vbmeta partition nameউল্লেখ করতে পারে এবং তারপরে নির্দিষ্টvbmetaপার্টিশনটি কোনো ডিভাইস মাউন্ট করার চেষ্টা করার আগে প্রথম পর্যায়েinitদ্বারা আরম্ভ করা হয়। -
devক্ষেত্রটি অবশ্যই পার্টিশনের নাম হতে হবে।
নিম্নলিখিত fstab এন্ট্রিগুলি উপরোক্ত নিয়মগুলি অনুসরণ করে সিস্টেম, বিক্রেতা এবং পণ্যকে লজিক্যাল পার্টিশন হিসাবে সেট করে।
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
প্রথম পর্যায়ের রামডিস্কে fstab ফাইলটি অনুলিপি করুন।
SELinux পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইস অবশ্যই super_block_device লেবেল দিয়ে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিংক /dev/block/platform/ soc/100000.ufshc /by-name/super হয়, তাহলে file_contexts এ নিম্নলিখিত লাইন যোগ করুন:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
fastbootd
বুটলোডার (বা যেকোন নন-ইউজারস্পেস ফ্ল্যাশিং টুল) ডাইনামিক পার্টিশন বোঝে না, তাই এটি তাদের ফ্ল্যাশ করতে পারে না। এটি মোকাবেলা করার জন্য, ডিভাইসগুলিকে fastboot প্রোটোকলের একটি ব্যবহারকারী-স্পেস বাস্তবায়ন ব্যবহার করতে হবে, যাকে বলা হয় fastbootd।
কিভাবে fastbootd প্রয়োগ করতে হয় সে সম্পর্কে আরও তথ্যের জন্য, দেখুন ফাস্টবুটকে ইউজার স্পেসে সরানো ।
adb রিমাউন্ট
eng বা userdebug বিল্ড ব্যবহার করে ডেভেলপারদের জন্য, দ্রুত পুনরাবৃত্তির জন্য adb remount অত্যন্ত উপযোগী। ডায়নামিক পার্টিশনগুলি adb remount জন্য একটি সমস্যা তৈরি করে কারণ প্রতিটি ফাইল সিস্টেমের মধ্যে আর ফাঁকা জায়গা নেই। এটি মোকাবেলা করার জন্য, ডিভাইসগুলি ওভারলেফগুলি সক্ষম করতে পারে। যতক্ষণ পর্যন্ত সুপার পার্টিশনের মধ্যে ফাঁকা জায়গা থাকে, ততক্ষণ adb remount স্বয়ংক্রিয়ভাবে একটি অস্থায়ী গতিশীল পার্টিশন তৈরি করে এবং লেখার জন্য ওভারলেফ ব্যবহার করে। অস্থায়ী পার্টিশনটির নাম scratch , তাই অন্য পার্টিশনের জন্য এই নামটি ব্যবহার করবেন না।
কিভাবে overlayfs সক্ষম করতে হয় সে সম্পর্কে আরও তথ্যের জন্য, AOSP-এ overlayfs README দেখুন।
অ্যান্ড্রয়েড ডিভাইস আপগ্রেড করুন
আপনি যদি Android 10-এ একটি ডিভাইস আপগ্রেড করেন এবং OTA-তে গতিশীল পার্টিশন সমর্থন অন্তর্ভুক্ত করতে চান, তাহলে আপনাকে বিল্ট-ইন পার্টিশন টেবিল পরিবর্তন করতে হবে না। কিছু অতিরিক্ত কনফিগারেশন প্রয়োজন.
ডিভাইস কনফিগারেশন পরিবর্তন
গতিশীল পার্টিশনের পুনরুদ্ধার করতে, device.mk এ নিম্নলিখিত ফ্ল্যাগগুলি যুক্ত করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে নিম্নলিখিত বোর্ড ভেরিয়েবল সেট করতে হবে:
-
BOARD_SUPER_PARTITION_BLOCK_DEVICESব্লক ডিভাইসের তালিকায় সেট করুন যা ডায়নামিক পার্টিশনের পরিমাণ সঞ্চয় করতে ব্যবহৃত হয়। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের নামের তালিকা। - যথাক্রমে
BOARD_SUPER_PARTITION_BLOCK_DEVICESএ প্রতিটি ব্লক ডিভাইসের আকারেBOARD_SUPER_PARTITION_ partition _DEVICE_SIZEসেট করুন। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের আকারের তালিকা। বিদ্যমান বোর্ড কনফিগারেশনে এটি সাধারণতBOARD_ partition IMAGE_PARTITION_SIZE। -
BOARD_SUPER_PARTITION_BLOCK_DEVICESএ সমস্ত পার্টিশনের জন্য বিদ্যমানBOARD_ partition IMAGE_PARTITION_SIZEআনসেট করুন। -
BOARD_SUPER_PARTITION_SIZEBOARD_SUPER_PARTITION_ partition _DEVICE_SIZEএ সেট করুন। -
BOARD_SUPER_PARTITION_METADATA_DEVICEব্লক ডিভাইসে সেট করুন যেখানে ডায়নামিক পার্টিশন মেটাডেটা সংরক্ষণ করা হয়। এটি অবশ্যইBOARD_SUPER_PARTITION_BLOCK_DEVICESএর মধ্যে একটি হতে হবে। সাধারণত, এটিsystemসেট করা হয়। -
BOARD_SUPER_PARTITION_GROUPSসেট করুন,BOARD_ group _SIZEএবংBOARD_ group _PARTITION_LIST। বিশদের জন্য নতুন ডিভাইসে বোর্ড কনফিগারেশন পরিবর্তনগুলি দেখুন।
উদাহরণস্বরূপ, যদি ডিভাইসে ইতিমধ্যে সিস্টেম এবং বিক্রেতার পার্টিশন থাকে এবং আপনি এগুলিকে গতিশীল পার্টিশনে রূপান্তর করতে এবং আপডেটের সময় একটি নতুন পণ্য পার্টিশন যুক্ত করতে চান তবে এই বোর্ডের কনফিগারেশনটি সেট করুন:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
সেলিনাক্স পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইসগুলি অবশ্যই বৈশিষ্ট্যটি super_block_device_type টাইপের সাথে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, যদি ডিভাইসে ইতিমধ্যে system এবং vendor পার্টিশন থাকে তবে আপনি গতিশীল পার্টিশনের এক্সটেন্টগুলি সঞ্চয় করতে ব্লক ডিভাইস হিসাবে তাদের ব্যবহার করতে চান এবং তাদের উপ-নাম সিমলিঙ্কগুলি system_block_device হিসাবে চিহ্নিত করা হয়েছে:
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
তারপরে, device.te নিম্নলিখিত লাইনটি যুক্ত করুন:
typeattribute system_block_device super_block_device_type;
অন্যান্য কনফিগারেশনের জন্য, নতুন ডিভাইসে গতিশীল পার্টিশনগুলি প্রয়োগ করা দেখুন।
Retrofit আপডেট সম্পর্কে আরও তথ্যের জন্য, গতিশীল পার্টিশন ছাড়াই এ/বি ডিভাইসের জন্য ওটিএ দেখুন।
কারখানার ছবি
ডায়নামিক পার্টিশন সমর্থন সহ একটি ডিভাইসের জন্য, ব্যবহারকারী স্পেস ফাস্টবুট ব্যবহার করা এড়িয়ে চলুন কারখানার চিত্রগুলি ফ্ল্যাশ করতে ব্যবহার করুন, কারণ ব্যবহারকারীস্পেসে বুট করা অন্যান্য ফ্ল্যাশিং পদ্ধতির তুলনায় ধীর।
এটিকে সম্বোধন করার জন্য, এখন make dist একটি অতিরিক্ত super.img চিত্র তৈরি করে যা সুপার পার্টিশনে সরাসরি ফ্ল্যাশ করা যায়। এটি স্বয়ংক্রিয়ভাবে যৌক্তিক পার্টিশনের বিষয়বস্তুগুলি বান্ডিল করে, যার অর্থ এটিতে system.img , vendor.img এবং আরও অনেক কিছু রয়েছে, super পার্টিশন মেটাডেটা ছাড়াও। এই চিত্রটি কোনও অতিরিক্ত সরঞ্জামকরণ বা ফাস্টবুটডি ব্যবহার না করে সরাসরি super পার্টিশনে ফ্ল্যাশ করা যেতে পারে। বিল্ডের পরে, super.img ${ANDROID_PRODUCT_OUT}
গতিশীল পার্টিশনগুলির সাথে চালু হওয়া এ/বি ডিভাইসের জন্য, super.img -তে একটি স্লটে চিত্র রয়েছে। সুপার ইমেজটি সরাসরি ফ্ল্যাশ করার পরে, ডিভাইসটি পুনরায় বুট করার আগে বুটযোগ্য হিসাবে স্লট এ মার্ক করুন।
Retrofit ডিভাইসগুলির জন্য, make dist super_*.img চিত্রগুলি যা সরাসরি শারীরিক পার্টিশনে সরাসরি ফ্ল্যাশ করা যায়। উদাহরণস্বরূপ, make dist make make make super_system.img এবং super_vendor.img যখন BOARD_SUPER_PARTITION_BLOCK_DEVICES সিস্টেম বিক্রেতা হয়। এই চিত্রগুলি target_files.zip ওটিএ ফোল্ডারে স্থাপন করা হয়েছে।
ডিভাইস ম্যাপার স্টোরেজ-ডিভাইস টিউনিং
ডায়নামিক পার্টিশনিং বেশ কয়েকটি ননডিটারমিনিস্টিক ডিভাইস-ম্যাপার অবজেক্টগুলিকে সমন্বিত করে। এগুলি প্রত্যাশার মতো সমস্ত ইনস্ট্যান্ট করতে পারে না, সুতরাং আপনাকে অবশ্যই সমস্ত মাউন্টগুলি ট্র্যাক করতে হবে এবং তাদের অন্তর্নিহিত স্টোরেজ ডিভাইসগুলির সাথে সম্পর্কিত সমস্ত পার্টিশনের অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি আপডেট করতে হবে।
init অভ্যন্তরের একটি প্রক্রিয়া মাউন্টগুলি ট্র্যাক করে এবং অ্যাসিঙ্ক্রোনালিভাবে অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি আপডেট করে। এটি যে পরিমাণ সময় নেয় তা নির্দিষ্ট সময়ের মধ্যে হওয়ার গ্যারান্টিযুক্ত নয়, তাই আপনাকে অবশ্যই on property ট্রিগারগুলিতে প্রতিক্রিয়া জানাতে পর্যাপ্ত সময় সরবরাহ করতে হবে। বৈশিষ্ট্যগুলি হ'ল dev.mnt.blk. <partition> যেখানে <partition> উদাহরণস্বরূপ, root , system , data বা vendor । প্রতিটি সম্পত্তি বেস স্টোরেজ-ডিভাইস নামের সাথে সম্পর্কিত, যেমন এই উদাহরণগুলিতে দেখানো হয়েছে:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
init.rc ভাষা বিধিগুলির অংশ হিসাবে অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি প্রসারিত করার অনুমতি দেয় এবং স্টোরেজ ডিভাইসগুলি এই জাতীয় কমান্ডগুলির সাথে প্রয়োজনীয় হিসাবে প্ল্যাটফর্ম দ্বারা সুর করা যেতে পারে:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
একবার কমান্ড প্রসেসিং দ্বিতীয়-পর্যায়ে init শুরু করার পরে, epoll loop সক্রিয় হয়ে যায় এবং মানগুলি আপডেট হতে শুরু করে। তবে, সম্পত্তি ট্রিগারগুলি init হওয়া পর্যন্ত সক্রিয় না থাকায় এগুলি root , system বা vendor পরিচালনা করতে প্রাথমিক বুট পর্যায়ে ব্যবহার করা যায় না। আপনি আশা করতে পারেন যে কার্নেল ডিফল্ট read_ahead_kb পর্যাপ্ত হবে যতক্ষণ না init.rc স্ক্রিপ্টগুলি early-fs ওভাররাইড করতে পারে (যখন বিভিন্ন ডেমনস এবং সুবিধাগুলি শুরু হয়)। অতএব, গুগল সুপারিশ করে যে আপনি on property বৈশিষ্ট্যটি ব্যবহার করুন, sys.read_ahead_kb মতো একটি init.rc -controlled সম্পত্তি সহ, অপারেশনগুলির সময় নির্ধারণের জন্য এবং এই উদাহরণগুলির মতো রেসের শর্তগুলি রোধ করতে:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}
গতিশীল পার্টিশন লিনাক্স কার্নেলে ডিএম-লিনিয়ার ডিভাইস-ম্যাপার মডিউল ব্যবহার করে প্রয়োগ করা হয়। super পার্টিশনে super মধ্যে প্রতিটি গতিশীল পার্টিশনের নাম এবং ব্লক রেঞ্জগুলি তালিকাভুক্ত করে মেটাডেটা রয়েছে। প্রথম-পর্যায়ের init সময়, এই মেটাডেটাটি পার্সড এবং বৈধতাযুক্ত এবং প্রতিটি গতিশীল পার্টিশনের প্রতিনিধিত্ব করার জন্য ভার্চুয়াল ব্লক ডিভাইসগুলি তৈরি করা হয়।
একটি ওটিএ প্রয়োগ করার সময়, গতিশীল পার্টিশনগুলি স্বয়ংক্রিয়ভাবে তৈরি করা হয়, পুনরায় আকার দেওয়া বা প্রয়োজন হিসাবে মুছে ফেলা হয়। এ/বি ডিভাইসের জন্য, মেটাডেটার দুটি অনুলিপি রয়েছে এবং পরিবর্তনগুলি কেবল লক্ষ্য স্লটকে উপস্থাপন করে অনুলিপিতে প্রয়োগ করা হয়।
যেহেতু ডায়নামিক পার্টিশনগুলি ব্যবহারকারীস্পেসে প্রয়োগ করা হয়, বুটলোডার দ্বারা প্রয়োজনীয় পার্টিশনগুলি গতিশীল করা যায় না। উদাহরণস্বরূপ, boot , dtbo এবং vbmeta বুটলোডার দ্বারা পড়া হয় এবং তাই অবশ্যই শারীরিক পার্টিশন হিসাবে থাকতে হবে।
প্রতিটি গতিশীল পার্টিশন একটি আপডেট গ্রুপের অন্তর্গত হতে পারে। এই গোষ্ঠীগুলি সেই গোষ্ঠীর পার্টিশনগুলি গ্রাস করতে পারে এমন সর্বাধিক স্থানকে সীমাবদ্ধ করে। উদাহরণস্বরূপ, system এবং vendor এমন একটি গোষ্ঠীর অন্তর্ভুক্ত হতে পারে যা system এবং vendor মোট আকারকে সীমাবদ্ধ করে।
নতুন ডিভাইসে গতিশীল পার্টিশন প্রয়োগ করুন
এই বিভাগে অ্যান্ড্রয়েড 10 এবং উচ্চতর দিয়ে চালু হওয়া নতুন ডিভাইসে গতিশীল পার্টিশনগুলি কীভাবে প্রয়োগ করা যায় তা বিশদ। বিদ্যমান ডিভাইসগুলি আপডেট করতে, আপগ্রেডিং অ্যান্ড্রয়েড ডিভাইসগুলি দেখুন।
পার্টিশন পরিবর্তন
অ্যান্ড্রয়েড 10 দিয়ে চালু হওয়া ডিভাইসগুলির জন্য, super নামে একটি পার্টিশন তৈরি করুন। super পার্টিশনটি অভ্যন্তরীণভাবে একটি/বি স্লট পরিচালনা করে, সুতরাং এ/বি ডিভাইসের জন্য পৃথক super_a এবং super_b পার্টিশনের প্রয়োজন হয় না। বুটলোডার দ্বারা ব্যবহৃত হয় না এমন সমস্ত পঠন-কেবলমাত্র এওএসপি পার্টিশনগুলি অবশ্যই গতিশীল হতে হবে এবং অবশ্যই জিইউড পার্টিশন টেবিল (জিপিটি) থেকে সরানো উচিত। বিক্রেতা-নির্দিষ্ট পার্টিশনগুলি গতিশীল হতে হবে না এবং জিপিটিতে স্থাপন করা যেতে পারে।
super আকারটি অনুমান করার জন্য, জিপিটি থেকে মুছে ফেলা হচ্ছে এমন পার্টিশনগুলির আকারগুলি যুক্ত করুন। এ/বি ডিভাইসের জন্য, এতে উভয় স্লটের আকার অন্তর্ভুক্ত করা উচিত। চিত্র 1 গতিশীল পার্টিশনে রূপান্তর করার আগে এবং পরে একটি উদাহরণ পার্টিশন টেবিল দেখায়।
সমর্থিত গতিশীল পার্টিশনগুলি হ'ল:
- সিস্টেম
- বিক্রেতা
- পণ্য
- সিস্টেম এক্সট
- ওডিএম
অ্যান্ড্রয়েড 10 দিয়ে প্রবর্তনকারী ডিভাইসগুলির জন্য, কার্নেল কমান্ড লাইন বিকল্পটি androidboot.super_partition অবশ্যই খালি থাকতে হবে যাতে কমান্ড সিসপ্রপ ro.boot.super_partition খালি থাকে।
বিভাজন প্রান্তিককরণ
ডিভাইস-ম্যাপার মডিউলটি super পার্টিশনটি সঠিকভাবে সারিবদ্ধ না করা থাকলে কম দক্ষতার সাথে পরিচালনা করতে পারে। super পার্টিশনটি অবশ্যই ব্লক স্তর দ্বারা নির্ধারিত ন্যূনতম আই/ও অনুরোধের আকারে সারিবদ্ধ করতে হবে। ডিফল্টরূপে, বিল্ড সিস্টেম ( lpmake দিয়ে, যা super পার্টিশন চিত্র তৈরি করে), ধরে নেওয়া হয় যে প্রতিটি গতিশীল পার্টিশনের জন্য 1 এমআইবি প্রান্তিককরণ যথেষ্ট। তবে, বিক্রেতাদের নিশ্চিত করা উচিত যে super পার্টিশনটি সঠিকভাবে সারিবদ্ধ হয়েছে।
আপনি sysfs পরিদর্শন করে কোনও ব্লক ডিভাইসের সর্বনিম্ন অনুরোধের আকার নির্ধারণ করতে পারেন। যেমন:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
আপনি super পার্টিশনের প্রান্তিককরণটি একইভাবে যাচাই করতে পারেন:
# cat /sys/block/sda/sda17/alignment_offsetপ্রান্তিককরণ অফসেট 0 হতে হবে।
ডিভাইস কনফিগারেশন পরিবর্তন
ডায়নামিক পার্টিশন সক্ষম করতে, device.mk নিম্নলিখিত পতাকা যুক্ত করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে super পার্টিশনের আকার সেট করতে হবে:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
এ/বি ডিভাইসে, গতিশীল পার্টিশন চিত্রগুলির মোট আকার super পার্টিশন আকারের অর্ধেকেরও বেশি হলে বিল্ড সিস্টেমটি একটি ত্রুটি ছুঁড়ে দেয়।
আপনি নিম্নলিখিত হিসাবে গতিশীল পার্টিশনের তালিকাটি কনফিগার করতে পারেন। আপডেট গ্রুপগুলি ব্যবহার করে ডিভাইসগুলির জন্য, BOARD_SUPER_PARTITION_GROUPS ভেরিয়েবলে গোষ্ঠীগুলি তালিকাভুক্ত করুন। তারপরে প্রতিটি গ্রুপের নামটিতে একটি BOARD_ group _SIZE এবং BOARD_ group _PARTITION_LIST ভেরিয়েবল রয়েছে। এ/বি ডিভাইসের জন্য, গ্রুপের সর্বাধিক আকারের কেবলমাত্র একটি স্লটটি আবরণ করা উচিত, কারণ গ্রুপের নামগুলি অভ্যন্তরীণভাবে স্লট-সরবরাহ করা হয়।
এখানে একটি উদাহরণ ডিভাইস রয়েছে যা সমস্ত পার্টিশনগুলিকে example_dynamic_partitions নামে একটি গ্রুপে রাখে:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
এখানে একটি উদাহরণ ডিভাইস রয়েছে যা সিস্টেম এবং পণ্য পরিষেবাদিগুলিকে group_foo এবং vendor , product এবং odm group_bar রাখে:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
- ভার্চুয়াল এ/বি লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই সর্বাধিক হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড
ভার্চুয়াল এ/বি বাস্তবায়ন দেখুন। - এ/বি লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই হওয়া উচিত:
BOARD_SUPER_PARTITION_SIZE/ 2 - ওভারহেড - নন-এ/বি ডিভাইস এবং এ/বি ডিভাইসের পুনঃনির্মাণের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড - বিল্ড টাইমে, একটি আপডেট গ্রুপে প্রতিটি পার্টিশনের চিত্রগুলির আকারের যোগফল অবশ্যই গ্রুপের সর্বাধিক আকারের চেয়ে বেশি হওয়া উচিত নয়।
- মেটাডেটা, প্রান্তিককরণ ইত্যাদির জন্য অ্যাকাউন্টে ওভারহেডের প্রয়োজনীয়তা প্রয়োজন। একটি যুক্তিসঙ্গত ওভারহেড 4 এমআইবি, তবে আপনি ডিভাইসটির প্রয়োজন অনুসারে আরও বড় ওভারহেড চয়ন করতে পারেন।
আকার গতিশীল পার্টিশন
গতিশীল পার্টিশনের আগে, পার্টিশন আকারগুলি ভবিষ্যতের আপডেটের জন্য পর্যাপ্ত জায়গা রয়েছে তা নিশ্চিত করার জন্য অতিরিক্ত বরাদ্দ করা হয়েছিল। প্রকৃত আকারটি যেমন রয়েছে তেমন নেওয়া হয়েছিল এবং বেশিরভাগ পঠনযোগ্য পার্টিশনে তাদের ফাইল সিস্টেমে কিছু পরিমাণ মুক্ত স্থান ছিল। গতিশীল পার্টিশনে, সেই মুক্ত স্থানটি ব্যবহারযোগ্য এবং এটি একটি ওটিএ চলাকালীন পার্টিশন বাড়াতে ব্যবহৃত হতে পারে। পার্টিশনগুলি স্থান নষ্ট করছে না এবং ন্যূনতম সম্ভাব্য আকারে বরাদ্দ করা হয়েছে তা নিশ্চিত করা সমালোচনা।
কেবলমাত্র ext4 চিত্রের জন্য, বিল্ড সিস্টেমটি স্বয়ংক্রিয়ভাবে ন্যূনতম আকার বরাদ্দ করে যদি কোনও হার্ডকোডেড পার্টিশন আকার নির্দিষ্ট না করা হয়। বিল্ড সিস্টেমটি চিত্রটি ফিট করে যাতে ফাইল সিস্টেমে যতটা সম্ভব অব্যবহৃত স্থান থাকে। এটি নিশ্চিত করে যে ডিভাইসটি ওটিএগুলির জন্য ব্যবহার করা যেতে পারে এমন স্থান নষ্ট করে না।
অতিরিক্তভাবে, ext4 চিত্রগুলি ব্লক-লেভেল ডিপ্লিকেশন সক্ষম করে আরও সংকুচিত করা যেতে পারে। এটি সক্ষম করতে, নিম্নলিখিত কনফিগারেশনটি ব্যবহার করুন:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
যদি পার্টিশনের ন্যূনতম আকারের স্বয়ংক্রিয় বরাদ্দ অনাকাঙ্ক্ষিত হয় তবে পার্টিশন আকারটি নিয়ন্ত্রণ করার দুটি উপায় রয়েছে। আপনি BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE সাথে ন্যূনতম পরিমাণের মুক্ত স্থান নির্দিষ্ট করতে পারেন, বা আপনি নির্দিষ্ট আকারে গতিশীল পার্টিশনগুলিকে জোর করার জন্য BOARD_ partition IMAGE_PARTITION_SIZE নির্দিষ্ট করতে পারেন। প্রয়োজন না হলে এগুলির কোনওটিই সুপারিশ করা হয় না।
যেমন:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
এটি product.img -তে ফাইল সিস্টেমকে 50 টি এমআইবি অব্যবহৃত স্থান রাখতে বাধ্য করে।
সিস্টেম-হিসাবে-রুট পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলি অবশ্যই সিস্টেম-হিসাবে-রুট ব্যবহার করবে না।
ডায়নামিক পার্টিশন সহ ডিভাইসগুলি (এটি গতিশীল পার্টিশনগুলির সাথে চালু বা পুনঃনির্মাণ বা পুনঃনির্মাণ করে) অবশ্যই সিস্টেম-হিসাবে রুট ব্যবহার করা উচিত নয়। লিনাক্স কার্নেল super পার্টিশনটির ব্যাখ্যা করতে পারে না এবং তাই system নিজেই মাউন্ট করতে পারে না। system এখন ফার্স্ট-স্টেজ init দ্বারা মাউন্ট করা হয়েছে, যা রামডিস্কে থাকে।
BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করবেন না। অ্যান্ড্রয়েড 10-এ, BOARD_BUILD_SYSTEM_ROOT_IMAGE ফ্ল্যাগটি কেবল কার্নেল দ্বারা বা রামডিস্কের প্রথম-পর্যায়ের init দ্বারা সিস্টেমটি মাউন্ট করা হয়েছে কিনা তা পৃথক করতে ব্যবহৃত হয়।
BOARD_BUILD_SYSTEM_ROOT_IMAGE true সাথে সেট করা একটি বিল্ড ত্রুটির কারণ হয় যখন PRODUCT_USE_DYNAMIC_PARTITIONS true হয়।
যখন BOARD_USES_RECOVERY_AS_BOOT সত্যে সেট করা থাকে, পুনরুদ্ধারের চিত্রটি বুট.আইএমজি হিসাবে নির্মিত হয়, পুনরুদ্ধারের র্যামডিস্ক সহ। পূর্বে, বুটলোডার কোন মোডে বুট করতে হবে তা সিদ্ধান্ত নিতে skip_initramfs কার্নেল কমান্ড লাইন প্যারামিটার ব্যবহার করে। অ্যান্ড্রয়েড 10 ডিভাইসের জন্য, বুটলোডারটি অবশ্যই কার্নেল কমান্ড-লাইনে skip_initramfs পাস করবে না। পরিবর্তে, বুটলোডারটি পুনরুদ্ধার করতে এবং সাধারণ অ্যান্ড্রয়েড বুট করতে androidboot.force_normal_boot=1 পাস করা উচিত। অ্যান্ড্রয়েড 12 বা তার পরে চালু হওয়া ডিভাইসগুলি অবশ্যই androidboot.force_normal_boot=1 পাস করতে বুটকনফিগ ব্যবহার করতে হবে।
এভিবি কনফিগারেশন পরিবর্তন
অ্যান্ড্রয়েড যাচাই করা বুট ২.০ ব্যবহার করার সময়, যদি ডিভাইসটি শৃঙ্খলিত পার্টিশন বর্ণনাকারী ব্যবহার না করে, তবে কোনও পরিবর্তন প্রয়োজন হয় না। যদি শৃঙ্খলিত পার্টিশনগুলি ব্যবহার করে তবে এবং যাচাই করা পার্টিশনগুলির মধ্যে একটি গতিশীল, তবে পরিবর্তনগুলি প্রয়োজনীয়।
system এবং vendor পার্টিশনের জন্য vbmeta চেইন করে এমন একটি ডিভাইসের জন্য এখানে একটি উদাহরণ কনফিগারেশন রয়েছে।
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
এই কনফিগারেশনের সাথে, বুটলোডার system এবং vendor পার্টিশনগুলির শেষে একটি ভিবিএমইটিএ পাদলেখ খুঁজে পাওয়ার প্রত্যাশা করে। যেহেতু এই পার্টিশনগুলি বুটলোডারের কাছে আর দৃশ্যমান নয় (তারা super থাকে), দুটি পরিবর্তন প্রয়োজন।
- ডিভাইসের পার্টিশন টেবিলটিতে
vbmeta_systemএবংvbmeta_vendorপার্টিশন যুক্ত করুন। এ/বি ডিভাইসের জন্য,vbmeta_system_a,vbmeta_system_b,vbmeta_vendor_a, এবংvbmeta_vendor_bযুক্ত করুন। যদি এই পার্টিশনগুলির এক বা একাধিক যুক্ত করা হয় তবে সেগুলিvbmetaপার্টিশনের মতো একই আকার হওয়া উচিত। -
VBMETA_যোগ করে কনফিগারেশন পতাকাগুলির নাম পরিবর্তন করুন এবং শৃঙ্খলাটি কোন পার্টিশনগুলিতে প্রসারিত হয় তা নির্দিষ্ট করুন:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
একটি ডিভাইস উভয়ই বা এই পার্টিশনগুলির কোনওটিই ব্যবহার করতে পারে। লজিক্যাল পার্টিশনে শৃঙ্খলা করার সময় কেবল পরিবর্তনগুলি প্রয়োজন।
এভিবি বুটলোডার পরিবর্তন হয়
যদি বুটলোডারটি এম্বেড করা থাকে তবে নিম্নলিখিত প্যাচগুলি অন্তর্ভুক্ত করুন:
- 818CF567407754446285466EDA984ASDD4BAEAC0 - "লিবাভিবি: যখন সেমডলাইনের প্রয়োজন হয় তখন কেবল ক্যোয়ারী পার্টিশন জিইউডগুলি" "
- 5ABD6BC2578968D24406D834471ADFD995A0C2E9 - "সিস্টেম পার্টিশন অনুপস্থিত থাকার অনুমতি দিন"
- 9BA3B6613B4E5130FA01A11D984C6B5F0EB3AB3AF05- "ফিক্স অ্যাভিবিএসএলওটিভিফাইডিএটিএ-> সেমডলাইনটি নাল হতে পারে"
যদি শৃঙ্খলিত পার্টিশনগুলি ব্যবহার করে তবে একটি অতিরিক্ত প্যাচ অন্তর্ভুক্ত করুন:
- 49936B4C0109411FDD38BD4BA3A32A01C40439A9 - "LIBAVB: পার্টিশনের শুরুতে ভিবিএমইটিএ ব্লবকে সমর্থন করুন" "
কার্নেল কমান্ড লাইন পরিবর্তন
একটি নতুন প্যারামিটার, androidboot.boot_devices অবশ্যই কার্নেল কমান্ড লাইনে যুক্ত করতে হবে। এটি init দ্বারা /dev/block/by-name সিমলিঙ্কগুলি সক্ষম করতে ব্যবহৃত হয়। এটি ueventd দ্বারা নির্মিত অন্তর্নিহিত বাই-নাম সিমলিঙ্কের ডিভাইস পাথের উপাদান হওয়া উচিত, অর্থাৎ, /dev/block/platform/ device-path /by-name/ partition-name । অ্যান্ড্রয়েড 12 বা তার পরে চালু হওয়া ডিভাইসগুলি অবশ্যই androidboot.boot_devices পাস init জন্য বুটকনফিগ ব্যবহার করতে হবে।
উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিঙ্কটি /dev/block/platform/ soc/100000.ufshc /by-name/super হয় তবে আপনি নিম্নলিখিত হিসাবে বোর্ডকনফিগ.এমকে ফাইলটিতে কমান্ড লাইন প্যারামিটার যুক্ত করতে পারেন:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
Fstab পরিবর্তন
ডিভাইস ট্রি এবং ডিভাইস ট্রি ওভারলেগুলিতে এফএসটিএবি এন্ট্রি থাকতে হবে না। একটি এফএসটিএবি ফাইল ব্যবহার করুন যা রামডিস্কের অংশ হবে।
যৌক্তিক পার্টিশনের জন্য এফএসটিএবি ফাইলে পরিবর্তন করতে হবে:
- এফএস_এমজিআর ফ্ল্যাগস ফিল্ডে অবশ্যই
logicalফ্ল্যাগ এবংfirst_stage_mountপতাকা অন্তর্ভুক্ত করতে হবে, অ্যান্ড্রয়েড 10 এ প্রবর্তিত, যা ইঙ্গিত দেয় যে প্রথম পর্যায়ে একটি পার্টিশন মাউন্ট করা উচিত। - একটি পার্টিশন
avb= vbmeta partition namefs_mgrপতাকা হিসাবে নির্দিষ্ট করতে পারে এবং তারপরে নির্দিষ্টvbmetaপার্টিশনটি কোনও ডিভাইস মাউন্ট করার চেষ্টা করার আগে প্রথম পর্যায়েরinitদ্বারা শুরু করা হয়। -
devক্ষেত্রটি অবশ্যই পার্টিশনের নাম হতে হবে।
নিম্নলিখিত এফএসটিএবি এন্ট্রিগুলি উপরোক্ত নিয়মগুলি অনুসরণ করে লজিক্যাল পার্টিশন হিসাবে সিস্টেম, বিক্রেতা এবং পণ্য সেট করে।
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
প্রথম পর্যায়ে র্যামডিস্কে এফএসটিএবি ফাইলটি অনুলিপি করুন।
সেলিনাক্স পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইসটি অবশ্যই লেবেল super_block_device সাথে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, যদি সুপার পার্টিশন বাই-নাম সিমলিঙ্কটি /dev/block/platform/ soc/100000.ufshc /by-name/super হয় তবে file_contexts নিম্নলিখিত লাইনটি যুক্ত করুন:
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
ফাস্টবুটড
বুটলোডার (বা কোনও অ-ব্যবহারকারীর ফ্ল্যাশিং সরঞ্জাম) গতিশীল পার্টিশনগুলি বুঝতে পারে না, তাই এটি তাদের ফ্ল্যাশ করতে পারে না। এটি সমাধান করার জন্য, ডিভাইসগুলি অবশ্যই ফাস্টবুট প্রোটোকলের একটি ব্যবহারকারী-স্থান বাস্তবায়ন ব্যবহার করতে হবে, যা ফাস্টবুটডি নামে পরিচিত।
কীভাবে ফাস্টবুটড বাস্তবায়ন করবেন সে সম্পর্কে আরও তথ্যের জন্য, ফাস্টবুটটি ব্যবহারকারীর জায়গাতে সরানো দেখুন।
adb রিমাউন্ট
ইঞ্জি বা ইউজারডেবাগ বিল্ডগুলি ব্যবহার করে বিকাশকারীদের জন্য, adb remount দ্রুত পুনরাবৃত্তির জন্য অত্যন্ত দরকারী। গতিশীল পার্টিশনগুলি adb remount জন্য একটি সমস্যা তৈরি করে কারণ প্রতিটি ফাইল সিস্টেমের মধ্যে আর মুক্ত স্থান নেই। এটি সম্বোধন করতে, ডিভাইসগুলি ওভারলেফগুলি সক্ষম করতে পারে। যতক্ষণ না সুপার পার্টিশনের মধ্যে মুক্ত স্থান থাকে, adb remount স্বয়ংক্রিয়ভাবে একটি অস্থায়ী গতিশীল পার্টিশন তৈরি করে এবং লেখার জন্য ওভারলেফগুলি ব্যবহার করে। অস্থায়ী পার্টিশনের নামকরণ করা হয়েছে scratch , সুতরাং অন্যান্য পার্টিশনের জন্য এই নামটি ব্যবহার করবেন না।
ওভারলেফগুলি কীভাবে সক্ষম করবেন সে সম্পর্কে আরও তথ্যের জন্য, এওএসপি -তে ওভারলেফস রিডমে দেখুন।
অ্যান্ড্রয়েড ডিভাইসগুলি আপগ্রেড করুন
আপনি যদি অ্যান্ড্রয়েড 10 এ কোনও ডিভাইস আপগ্রেড করেন এবং ওটিএতে গতিশীল পার্টিশন সমর্থন অন্তর্ভুক্ত করতে চান তবে আপনাকে অন্তর্নির্মিত পার্টিশন টেবিলটি পরিবর্তন করতে হবে না। কিছু অতিরিক্ত কনফিগারেশন প্রয়োজন।
ডিভাইস কনফিগারেশন পরিবর্তন
ডায়নামিক পার্টিশনটি পুনঃনির্মাণ করতে, device.mk নিম্নলিখিত পতাকাগুলি যুক্ত করুন M এমকে:
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে নিম্নলিখিত বোর্ডের ভেরিয়েবলগুলি সেট করতে হবে:
- গতিশীল পার্টিশনের এক্সটেন্টগুলি সঞ্চয় করতে ব্যবহৃত ব্লক ডিভাইসের তালিকায়
BOARD_SUPER_PARTITION_BLOCK_DEVICESসেট করুন। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের নামগুলির তালিকা। -
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZEযথাক্রমেBOARD_SUPER_PARTITION_BLOCK_DEVICESপ্রতিটি ব্লক ডিভাইসের আকারে _ ডিভাইস_সাইজ করুন। এটি ডিভাইসে বিদ্যমান শারীরিক পার্টিশনের আকারের তালিকা। এটি সাধারণত বিদ্যমান বোর্ড কনফিগারেশনেBOARD_ partition IMAGE_PARTITION_SIZE। -
BOARD_SUPER_PARTITION_BLOCK_DEVICESসমস্ত পার্টিশনের জন্য বিদ্যমানBOARD_ partition IMAGE_PARTITION_SIZEআনসেট করুন। -
BOARD_SUPER_PARTITION_SIZEBOARD_SUPER_PARTITION_ partition _DEVICE_SIZEযোগফলের জন্য সেট করুন। - ব্লক ডিভাইসে যেখানে গতিশীল পার্টিশন মেটাডেটা সংরক্ষণ করা হয় সেখানে
BOARD_SUPER_PARTITION_METADATA_DEVICEসেট করুন। এটি অবশ্যইBOARD_SUPER_PARTITION_BLOCK_DEVICESমধ্যে একটি হতে হবে। সাধারণত, এটিsystemসেট করা হয়। -
BOARD_SUPER_PARTITION_GROUPSসেট করুন,BOARD_ group _SIZEএবংBOARD_ group _PARTITION_LIST। বিশদের জন্য নতুন ডিভাইসে বোর্ড কনফিগারেশন পরিবর্তনগুলি দেখুন।
উদাহরণস্বরূপ, যদি ডিভাইসে ইতিমধ্যে সিস্টেম এবং বিক্রেতার পার্টিশন থাকে এবং আপনি এগুলিকে গতিশীল পার্টিশনে রূপান্তর করতে এবং আপডেটের সময় একটি নতুন পণ্য পার্টিশন যুক্ত করতে চান তবে এই বোর্ডের কনফিগারেশনটি সেট করুন:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
সেলিনাক্স পরিবর্তন
সুপার পার্টিশন ব্লক ডিভাইসগুলি অবশ্যই বৈশিষ্ট্যটি super_block_device_type টাইপের সাথে চিহ্নিত করা উচিত। উদাহরণস্বরূপ, যদি ডিভাইসে ইতিমধ্যে system এবং vendor পার্টিশন থাকে তবে আপনি গতিশীল পার্টিশনের এক্সটেন্টগুলি সঞ্চয় করতে ব্লক ডিভাইস হিসাবে তাদের ব্যবহার করতে চান এবং তাদের উপ-নাম সিমলিঙ্কগুলি system_block_device হিসাবে চিহ্নিত করা হয়েছে:
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
তারপরে, device.te নিম্নলিখিত লাইনটি যুক্ত করুন:
typeattribute system_block_device super_block_device_type;
অন্যান্য কনফিগারেশনের জন্য, নতুন ডিভাইসে গতিশীল পার্টিশনগুলি প্রয়োগ করা দেখুন।
Retrofit আপডেট সম্পর্কে আরও তথ্যের জন্য, গতিশীল পার্টিশন ছাড়াই এ/বি ডিভাইসের জন্য ওটিএ দেখুন।
কারখানার ছবি
ডায়নামিক পার্টিশন সমর্থন সহ একটি ডিভাইসের জন্য, ব্যবহারকারী স্পেস ফাস্টবুট ব্যবহার করা এড়িয়ে চলুন কারখানার চিত্রগুলি ফ্ল্যাশ করতে ব্যবহার করুন, কারণ ব্যবহারকারীস্পেসে বুট করা অন্যান্য ফ্ল্যাশিং পদ্ধতির তুলনায় ধীর।
এটিকে সম্বোধন করার জন্য, এখন make dist একটি অতিরিক্ত super.img চিত্র তৈরি করে যা সুপার পার্টিশনে সরাসরি ফ্ল্যাশ করা যায়। এটি স্বয়ংক্রিয়ভাবে যৌক্তিক পার্টিশনের বিষয়বস্তুগুলি বান্ডিল করে, যার অর্থ এটিতে system.img , vendor.img এবং আরও অনেক কিছু রয়েছে, super পার্টিশন মেটাডেটা ছাড়াও। এই চিত্রটি কোনও অতিরিক্ত সরঞ্জামকরণ বা ফাস্টবুটডি ব্যবহার না করে সরাসরি super পার্টিশনে ফ্ল্যাশ করা যেতে পারে। বিল্ডের পরে, super.img ${ANDROID_PRODUCT_OUT}
গতিশীল পার্টিশনগুলির সাথে চালু হওয়া এ/বি ডিভাইসের জন্য, super.img -তে একটি স্লটে চিত্র রয়েছে। সুপার ইমেজটি সরাসরি ফ্ল্যাশ করার পরে, ডিভাইসটি পুনরায় বুট করার আগে বুটযোগ্য হিসাবে স্লট এ মার্ক করুন।
Retrofit ডিভাইসগুলির জন্য, make dist super_*.img চিত্রগুলি যা সরাসরি শারীরিক পার্টিশনে সরাসরি ফ্ল্যাশ করা যায়। উদাহরণস্বরূপ, make dist make make make super_system.img এবং super_vendor.img যখন BOARD_SUPER_PARTITION_BLOCK_DEVICES সিস্টেম বিক্রেতা হয়। এই চিত্রগুলি target_files.zip ওটিএ ফোল্ডারে স্থাপন করা হয়েছে।
ডিভাইস ম্যাপার স্টোরেজ-ডিভাইস টিউনিং
ডায়নামিক পার্টিশনিং বেশ কয়েকটি ননডিটারমিনিস্টিক ডিভাইস-ম্যাপার অবজেক্টগুলিকে সমন্বিত করে। এগুলি প্রত্যাশার মতো সমস্ত ইনস্ট্যান্ট করতে পারে না, সুতরাং আপনাকে অবশ্যই সমস্ত মাউন্টগুলি ট্র্যাক করতে হবে এবং তাদের অন্তর্নিহিত স্টোরেজ ডিভাইসগুলির সাথে সম্পর্কিত সমস্ত পার্টিশনের অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি আপডেট করতে হবে।
init অভ্যন্তরের একটি প্রক্রিয়া মাউন্টগুলি ট্র্যাক করে এবং অ্যাসিঙ্ক্রোনালিভাবে অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি আপডেট করে। এটি যে পরিমাণ সময় নেয় তা নির্দিষ্ট সময়ের মধ্যে হওয়ার গ্যারান্টিযুক্ত নয়, তাই আপনাকে অবশ্যই on property ট্রিগারগুলিতে প্রতিক্রিয়া জানাতে পর্যাপ্ত সময় সরবরাহ করতে হবে। বৈশিষ্ট্যগুলি হ'ল dev.mnt.blk. <partition> যেখানে <partition> উদাহরণস্বরূপ, root , system , data বা vendor । প্রতিটি সম্পত্তি বেস স্টোরেজ-ডিভাইস নামের সাথে সম্পর্কিত, যেমন এই উদাহরণগুলিতে দেখানো হয়েছে:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
init.rc ভাষা বিধিগুলির অংশ হিসাবে অ্যান্ড্রয়েড বৈশিষ্ট্যগুলি প্রসারিত করার অনুমতি দেয় এবং স্টোরেজ ডিভাইসগুলি এই জাতীয় কমান্ডগুলির সাথে প্রয়োজনীয় হিসাবে প্ল্যাটফর্ম দ্বারা সুর করা যেতে পারে:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
একবার কমান্ড প্রসেসিং দ্বিতীয়-পর্যায়ে init শুরু করার পরে, epoll loop সক্রিয় হয়ে যায় এবং মানগুলি আপডেট হতে শুরু করে। তবে, সম্পত্তি ট্রিগারগুলি init হওয়া পর্যন্ত সক্রিয় না থাকায় এগুলি root , system বা vendor পরিচালনা করতে প্রাথমিক বুট পর্যায়ে ব্যবহার করা যায় না। আপনি আশা করতে পারেন যে কার্নেল ডিফল্ট read_ahead_kb পর্যাপ্ত হবে যতক্ষণ না init.rc স্ক্রিপ্টগুলি early-fs ওভাররাইড করতে পারে (যখন বিভিন্ন ডেমনস এবং সুবিধাগুলি শুরু হয়)। অতএব, গুগল সুপারিশ করে যে আপনি on property বৈশিষ্ট্যটি ব্যবহার করুন, sys.read_ahead_kb মতো একটি init.rc -controlled সম্পত্তি সহ, অপারেশনগুলির সময় নির্ধারণের জন্য এবং এই উদাহরণগুলির মতো রেসের শর্তগুলি রোধ করতে:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}
গতিশীল পার্টিশন লিনাক্স কার্নেলে ডিএম-লিনিয়ার ডিভাইস-ম্যাপার মডিউল ব্যবহার করে প্রয়োগ করা হয়। super পার্টিশনে super মধ্যে প্রতিটি গতিশীল পার্টিশনের নাম এবং ব্লক রেঞ্জগুলি তালিকাভুক্ত করে মেটাডেটা রয়েছে। প্রথম-পর্যায়ের init সময়, এই মেটাডেটাটি পার্সড এবং বৈধতাযুক্ত এবং প্রতিটি গতিশীল পার্টিশনের প্রতিনিধিত্ব করার জন্য ভার্চুয়াল ব্লক ডিভাইসগুলি তৈরি করা হয়।
একটি ওটিএ প্রয়োগ করার সময়, গতিশীল পার্টিশনগুলি স্বয়ংক্রিয়ভাবে তৈরি করা হয়, পুনরায় আকার দেওয়া বা প্রয়োজন হিসাবে মুছে ফেলা হয়। এ/বি ডিভাইসের জন্য, মেটাডেটার দুটি অনুলিপি রয়েছে এবং পরিবর্তনগুলি কেবল লক্ষ্য স্লটকে উপস্থাপন করে অনুলিপিতে প্রয়োগ করা হয়।
যেহেতু ডায়নামিক পার্টিশনগুলি ব্যবহারকারীস্পেসে প্রয়োগ করা হয়, বুটলোডার দ্বারা প্রয়োজনীয় পার্টিশনগুলি গতিশীল করা যায় না। উদাহরণস্বরূপ, boot , dtbo এবং vbmeta বুটলোডার দ্বারা পড়া হয় এবং তাই অবশ্যই শারীরিক পার্টিশন হিসাবে থাকতে হবে।
প্রতিটি গতিশীল পার্টিশন একটি আপডেট গ্রুপের অন্তর্গত হতে পারে। এই গোষ্ঠীগুলি সেই গোষ্ঠীর পার্টিশনগুলি গ্রাস করতে পারে এমন সর্বাধিক স্থানকে সীমাবদ্ধ করে। উদাহরণস্বরূপ, system এবং vendor এমন একটি গোষ্ঠীর অন্তর্ভুক্ত হতে পারে যা system এবং vendor মোট আকারকে সীমাবদ্ধ করে।
নতুন ডিভাইসে গতিশীল পার্টিশন প্রয়োগ করুন
এই বিভাগে অ্যান্ড্রয়েড 10 এবং উচ্চতর দিয়ে চালু হওয়া নতুন ডিভাইসে গতিশীল পার্টিশনগুলি কীভাবে প্রয়োগ করা যায় তা বিশদ। বিদ্যমান ডিভাইসগুলি আপডেট করতে, আপগ্রেডিং অ্যান্ড্রয়েড ডিভাইসগুলি দেখুন।
পার্টিশন পরিবর্তন
অ্যান্ড্রয়েড 10 দিয়ে চালু হওয়া ডিভাইসগুলির জন্য, super নামে একটি পার্টিশন তৈরি করুন। super পার্টিশনটি অভ্যন্তরীণভাবে একটি/বি স্লট পরিচালনা করে, সুতরাং এ/বি ডিভাইসের জন্য পৃথক super_a এবং super_b পার্টিশনের প্রয়োজন হয় না। বুটলোডার দ্বারা ব্যবহৃত হয় না এমন সমস্ত পঠন-কেবলমাত্র এওএসপি পার্টিশনগুলি অবশ্যই গতিশীল হতে হবে এবং অবশ্যই জিইউড পার্টিশন টেবিল (জিপিটি) থেকে সরানো উচিত। বিক্রেতা-নির্দিষ্ট পার্টিশনগুলি গতিশীল হতে হবে না এবং জিপিটিতে স্থাপন করা যেতে পারে।
super আকারটি অনুমান করার জন্য, জিপিটি থেকে মুছে ফেলা হচ্ছে এমন পার্টিশনগুলির আকারগুলি যুক্ত করুন। এ/বি ডিভাইসের জন্য, এতে উভয় স্লটের আকার অন্তর্ভুক্ত করা উচিত। চিত্র 1 গতিশীল পার্টিশনে রূপান্তর করার আগে এবং পরে একটি উদাহরণ পার্টিশন টেবিল দেখায়।
সমর্থিত গতিশীল পার্টিশনগুলি হ'ল:
- সিস্টেম
- বিক্রেতা
- পণ্য
- সিস্টেম এক্সট
- ওডিএম
অ্যান্ড্রয়েড 10 দিয়ে প্রবর্তনকারী ডিভাইসগুলির জন্য, কার্নেল কমান্ড লাইন বিকল্পটি androidboot.super_partition অবশ্যই খালি থাকতে হবে যাতে কমান্ড সিসপ্রপ ro.boot.super_partition খালি থাকে।
বিভাজন প্রান্তিককরণ
ডিভাইস-ম্যাপার মডিউলটি super পার্টিশনটি সঠিকভাবে সারিবদ্ধ না করা থাকলে কম দক্ষতার সাথে পরিচালনা করতে পারে। super পার্টিশনটি অবশ্যই ব্লক স্তর দ্বারা নির্ধারিত ন্যূনতম আই/ও অনুরোধের আকারে সারিবদ্ধ করতে হবে। ডিফল্টরূপে, বিল্ড সিস্টেম ( lpmake দিয়ে, যা super পার্টিশন চিত্র তৈরি করে), ধরে নেওয়া হয় যে প্রতিটি গতিশীল পার্টিশনের জন্য 1 এমআইবি প্রান্তিককরণ যথেষ্ট। তবে, বিক্রেতাদের নিশ্চিত করা উচিত যে super পার্টিশনটি সঠিকভাবে সারিবদ্ধ হয়েছে।
আপনি sysfs পরিদর্শন করে কোনও ব্লক ডিভাইসের সর্বনিম্ন অনুরোধের আকার নির্ধারণ করতে পারেন। যেমন:
# ls -l /dev/block/by-name/super lrwxrwxrwx 1 root root 16 1970-04-05 01:41 /dev/block/by-name/super -> /dev/block/sda17 # cat /sys/block/sda/queue/minimum_io_size 786432
আপনি super পার্টিশনের প্রান্তিককরণটি একইভাবে যাচাই করতে পারেন:
# cat /sys/block/sda/sda17/alignment_offsetপ্রান্তিককরণ অফসেট 0 হতে হবে।
ডিভাইস কনফিগারেশন পরিবর্তন
ডায়নামিক পার্টিশন সক্ষম করতে, device.mk নিম্নলিখিত পতাকা যুক্ত করুন:
PRODUCT_USE_DYNAMIC_PARTITIONS := true
বোর্ড কনফিগারেশন পরিবর্তন
আপনাকে super পার্টিশনের আকার সেট করতে হবে:
BOARD_SUPER_PARTITION_SIZE := <size-in-bytes>
এ/বি ডিভাইসে, গতিশীল পার্টিশন চিত্রগুলির মোট আকার super পার্টিশন আকারের অর্ধেকেরও বেশি হলে বিল্ড সিস্টেমটি একটি ত্রুটি ছুঁড়ে দেয়।
আপনি নিম্নলিখিত হিসাবে গতিশীল পার্টিশনের তালিকাটি কনফিগার করতে পারেন। আপডেট গ্রুপগুলি ব্যবহার করে ডিভাইসগুলির জন্য, BOARD_SUPER_PARTITION_GROUPS ভেরিয়েবলে গোষ্ঠীগুলি তালিকাভুক্ত করুন। তারপরে প্রতিটি গ্রুপের নামটিতে একটি BOARD_ group _SIZE এবং BOARD_ group _PARTITION_LIST ভেরিয়েবল রয়েছে। এ/বি ডিভাইসের জন্য, গ্রুপের সর্বাধিক আকারের কেবলমাত্র একটি স্লটটি আবরণ করা উচিত, কারণ গ্রুপের নামগুলি অভ্যন্তরীণভাবে স্লট-সরবরাহ করা হয়।
এখানে একটি উদাহরণ ডিভাইস রয়েছে যা সমস্ত পার্টিশনগুলিকে example_dynamic_partitions নামে একটি গ্রুপে রাখে:
BOARD_SUPER_PARTITION_GROUPS := example_dynamic_partitions BOARD_EXAMPLE_DYNAMIC_PARTITIONS_SIZE := 6442450944 BOARD_EXAMPLE_DYNAMIC_PARTITIONS_PARTITION_LIST := system vendor product
এখানে একটি উদাহরণ ডিভাইস রয়েছে যা সিস্টেম এবং পণ্য পরিষেবাদিগুলিকে group_foo এবং vendor , product এবং odm group_bar রাখে:
BOARD_SUPER_PARTITION_GROUPS := group_foo group_bar BOARD_GROUP_FOO_SIZE := 4831838208 BOARD_GROUP_FOO_PARTITION_LIST := system product_services BOARD_GROUP_BAR_SIZE := 1610612736 BOARD_GROUP_BAR_PARTITION_LIST := vendor product odm
- ভার্চুয়াল এ/বি লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই সর্বাধিক হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড
ভার্চুয়াল এ/বি বাস্তবায়ন দেখুন। - এ/বি লঞ্চ ডিভাইসের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই হওয়া উচিত:
BOARD_SUPER_PARTITION_SIZE/ 2 - ওভারহেড - নন-এ/বি ডিভাইস এবং এ/বি ডিভাইসের পুনঃনির্মাণের জন্য, সমস্ত গ্রুপের সর্বাধিক আকারের যোগফল অবশ্যই হতে হবে:
BOARD_SUPER_PARTITION_SIZE- ওভারহেড - বিল্ড টাইমে, একটি আপডেট গ্রুপে প্রতিটি পার্টিশনের চিত্রগুলির আকারের যোগফল অবশ্যই গ্রুপের সর্বাধিক আকারের চেয়ে বেশি হওয়া উচিত নয়।
- মেটাডেটা, প্রান্তিককরণ ইত্যাদির জন্য অ্যাকাউন্টে ওভারহেডের প্রয়োজনীয়তা প্রয়োজন। একটি যুক্তিসঙ্গত ওভারহেড 4 এমআইবি, তবে আপনি ডিভাইসটির প্রয়োজন অনুসারে আরও বড় ওভারহেড চয়ন করতে পারেন।
আকার গতিশীল পার্টিশন
গতিশীল পার্টিশনের আগে, পার্টিশন আকারগুলি ভবিষ্যতের আপডেটের জন্য পর্যাপ্ত জায়গা রয়েছে তা নিশ্চিত করার জন্য অতিরিক্ত বরাদ্দ করা হয়েছিল। প্রকৃত আকারটি যেমন রয়েছে তেমন নেওয়া হয়েছিল এবং বেশিরভাগ পঠনযোগ্য পার্টিশনে তাদের ফাইল সিস্টেমে কিছু পরিমাণ মুক্ত স্থান ছিল। গতিশীল পার্টিশনে, সেই মুক্ত স্থানটি ব্যবহারযোগ্য এবং এটি একটি ওটিএ চলাকালীন পার্টিশন বাড়াতে ব্যবহৃত হতে পারে। পার্টিশনগুলি স্থান নষ্ট করছে না এবং ন্যূনতম সম্ভাব্য আকারে বরাদ্দ করা হয়েছে তা নিশ্চিত করা সমালোচনা।
কেবলমাত্র ext4 চিত্রের জন্য, বিল্ড সিস্টেমটি স্বয়ংক্রিয়ভাবে ন্যূনতম আকার বরাদ্দ করে যদি কোনও হার্ডকোডেড পার্টিশন আকার নির্দিষ্ট না করা হয়। বিল্ড সিস্টেমটি চিত্রটি ফিট করে যাতে ফাইল সিস্টেমে যতটা সম্ভব অব্যবহৃত স্থান থাকে। এটি নিশ্চিত করে যে ডিভাইসটি ওটিএগুলির জন্য ব্যবহার করা যেতে পারে এমন স্থান নষ্ট করে না।
অতিরিক্তভাবে, ext4 চিত্রগুলি ব্লক-লেভেল ডিপ্লিকেশন সক্ষম করে আরও সংকুচিত করা যেতে পারে। এটি সক্ষম করতে, নিম্নলিখিত কনফিগারেশনটি ব্যবহার করুন:
BOARD_EXT4_SHARE_DUP_BLOCKS := true
যদি পার্টিশনের ন্যূনতম আকারের স্বয়ংক্রিয় বরাদ্দ অনাকাঙ্ক্ষিত হয় তবে পার্টিশন আকারটি নিয়ন্ত্রণ করার দুটি উপায় রয়েছে। আপনি BOARD_ partition IMAGE_PARTITION_RESERVED_SIZE সাথে ন্যূনতম পরিমাণের মুক্ত স্থান নির্দিষ্ট করতে পারেন, বা আপনি নির্দিষ্ট আকারে গতিশীল পার্টিশনগুলিকে জোর করার জন্য BOARD_ partition IMAGE_PARTITION_SIZE নির্দিষ্ট করতে পারেন। প্রয়োজন না হলে এগুলির কোনওটিই সুপারিশ করা হয় না।
যেমন:
BOARD_PRODUCTIMAGE_PARTITION_RESERVED_SIZE := 52428800
এটি product.img -তে ফাইল সিস্টেমকে 50 টি এমআইবি অব্যবহৃত স্থান রাখতে বাধ্য করে।
সিস্টেম-হিসাবে-রুট পরিবর্তন
অ্যান্ড্রয়েড 10 এর সাথে চালু হওয়া ডিভাইসগুলি অবশ্যই সিস্টেম-হিসাবে-রুট ব্যবহার করবে না।
ডায়নামিক পার্টিশন সহ ডিভাইসগুলি (এটি গতিশীল পার্টিশনগুলির সাথে চালু বা পুনঃনির্মাণ বা পুনঃনির্মাণ করে) অবশ্যই সিস্টেম-হিসাবে রুট ব্যবহার করা উচিত নয়। লিনাক্স কার্নেল super পার্টিশনটির ব্যাখ্যা করতে পারে না এবং তাই system নিজেই মাউন্ট করতে পারে না। system এখন ফার্স্ট-স্টেজ init দ্বারা মাউন্ট করা হয়েছে, যা রামডিস্কে থাকে।
BOARD_BUILD_SYSTEM_ROOT_IMAGE সেট করবেন না। অ্যান্ড্রয়েড 10-এ, BOARD_BUILD_SYSTEM_ROOT_IMAGE ফ্ল্যাগটি কেবল কার্নেল দ্বারা বা রামডিস্কের প্রথম-পর্যায়ের init দ্বারা সিস্টেমটি মাউন্ট করা হয়েছে কিনা তা পৃথক করতে ব্যবহৃত হয়।
BOARD_BUILD_SYSTEM_ROOT_IMAGE true সাথে সেট করা একটি বিল্ড ত্রুটির কারণ হয় যখন PRODUCT_USE_DYNAMIC_PARTITIONS true হয়।
যখন BOARD_USES_RECOVERY_AS_BOOT সত্যে সেট করা থাকে, পুনরুদ্ধারের চিত্রটি বুট.আইএমজি হিসাবে নির্মিত হয়, পুনরুদ্ধারের র্যামডিস্ক ধারণ করে। পূর্বে, বুটলোডার কোন মোডে বুট করতে হবে তা সিদ্ধান্ত নিতে skip_initramfs কার্নেল কমান্ড লাইন প্যারামিটার ব্যবহার করে। অ্যান্ড্রয়েড 10 ডিভাইসের জন্য, বুটলোডারটি অবশ্যই কার্নেল কমান্ড-লাইনে skip_initramfs পাস করবে না। পরিবর্তে, বুটলোডারটি পুনরুদ্ধার করতে এবং সাধারণ অ্যান্ড্রয়েড বুট করতে androidboot.force_normal_boot=1 পাস করা উচিত। অ্যান্ড্রয়েড 12 বা তার পরে চালু হওয়া ডিভাইসগুলি অবশ্যই androidboot.force_normal_boot=1 পাস করতে বুটকনফিগ ব্যবহার করতে হবে।
এভিবি কনফিগারেশন পরিবর্তন
অ্যান্ড্রয়েড যাচাই করা বুট ২.০ ব্যবহার করার সময়, যদি ডিভাইসটি শৃঙ্খলিত পার্টিশন বর্ণনাকারী ব্যবহার না করে, তবে কোনও পরিবর্তন প্রয়োজন হয় না। যদি শৃঙ্খলিত পার্টিশনগুলি ব্যবহার করে তবে এবং যাচাই করা পার্টিশনগুলির মধ্যে একটি গতিশীল, তবে পরিবর্তনগুলি প্রয়োজনীয়।
system এবং vendor পার্টিশনের জন্য vbmeta চেইন করে এমন একটি ডিভাইসের জন্য এখানে একটি উদাহরণ কনফিগারেশন রয়েছে।
BOARD_AVB_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VENDOR_ROLLBACK_INDEX_LOCATION := 1
এই কনফিগারেশনের সাথে, বুটলোডার system এবং vendor পার্টিশনগুলির শেষে একটি ভিবিএমইটিএ পাদলেখ খুঁজে পাওয়ার প্রত্যাশা করে। যেহেতু এই পার্টিশনগুলি বুটলোডারের কাছে আর দৃশ্যমান নয় (তারা super থাকে), দুটি পরিবর্তন প্রয়োজন।
- ডিভাইসের পার্টিশন টেবিলটিতে
vbmeta_systemএবংvbmeta_vendorপার্টিশন যুক্ত করুন। এ/বি ডিভাইসের জন্য,vbmeta_system_a,vbmeta_system_b,vbmeta_vendor_a, এবংvbmeta_vendor_bযুক্ত করুন। যদি এই পার্টিশনগুলির এক বা একাধিক যুক্ত করা হয় তবে সেগুলিvbmetaপার্টিশনের মতো একই আকার হওয়া উচিত। -
VBMETA_যোগ করে কনফিগারেশন পতাকাগুলির নাম পরিবর্তন করুন এবং শৃঙ্খলাটি কোন পার্টিশনগুলিতে প্রসারিত হয় তা নির্দিষ্ট করুন:BOARD_AVB_VBMETA_SYSTEM := system BOARD_AVB_VBMETA_SYSTEM_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_SYSTEM_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_SYSTEM_ROLLBACK_INDEX_LOCATION := 1 BOARD_AVB_VBMETA_VENDOR := vendor BOARD_AVB_VBMETA_VENDOR_KEY_PATH := external/avb/test/data/testkey_rsa2048.pem BOARD_AVB_VBMETA_VENDOR_ALGORITHM := SHA256_RSA2048 BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX := $(PLATFORM_SECURITY_PATCH_TIMESTAMP) BOARD_AVB_VBMETA_VENDOR_ROLLBACK_INDEX_LOCATION := 1
একটি ডিভাইস উভয়ই বা এই পার্টিশনগুলির কোনওটিই ব্যবহার করতে পারে। লজিক্যাল পার্টিশনে শৃঙ্খলা করার সময় কেবল পরিবর্তনগুলি প্রয়োজন।
এভিবি বুটলোডার পরিবর্তন হয়
যদি বুটলোডারটি এম্বেড করা থাকে তবে নিম্নলিখিত প্যাচগুলি অন্তর্ভুক্ত করুন:
- 818CF567407754446285466EDA984ASDD4BAEAC0 - "লিবাভিবি: যখন সেমডলাইনের প্রয়োজন হয় তখন কেবল ক্যোয়ারী পার্টিশন জিইউডগুলি" "
- 5ABD6BC2578968D24406D834471ADFD995A0C2E9 - "সিস্টেম পার্টিশন অনুপস্থিত থাকার অনুমতি দিন"
- 9BA3B6613B4E5130FA01A11D984C6B5F0EB3AB3AF05- "ফিক্স অ্যাভিবিএসএলওটিভিফাইডিএটিএ-> সেমডলাইনটি নাল হতে পারে"
যদি শৃঙ্খলিত পার্টিশনগুলি ব্যবহার করে তবে একটি অতিরিক্ত প্যাচ অন্তর্ভুক্ত করুন:
- 49936B4C0109411FDD38BD4BA3A32A01C40439A9 - "LIBAVB: পার্টিশনের শুরুতে ভিবিএমইটিএ ব্লবকে সমর্থন করুন" "
কার্নেল কমান্ড লাইন পরিবর্তন
একটি নতুন প্যারামিটার, androidboot.boot_devices অবশ্যই কার্নেল কমান্ড লাইনে যুক্ত করতে হবে। এটি init দ্বারা /dev/block/by-name সিমলিঙ্কগুলি সক্ষম করতে ব্যবহৃত হয়। It should be the device path component to the underlying by-name symlink created by ueventd , that is, /dev/block/platform/ device-path /by-name/ partition-name . Devices launching with Android 12 or later must use bootconfig to pass androidboot.boot_devices to init .
For example, if the super partition by-name symlink is /dev/block/platform/ soc/100000.ufshc /by-name/super , you can add the command line parameter in the BoardConfig.mk file as follows:
BOARD_KERNEL_CMDLINE += androidboot.boot_devices=soc/100000.ufshc
BOARD_BOOTCONFIG += androidboot.boot_devices=soc/100000.ufshc
fstab changes
The device tree and device tree overlays must not contain fstab entries. Use an fstab file that will be part of the ramdisk.
Changes must be made to the fstab file for logical partitions:
- The fs_mgr flags field must include the
logicalflag and thefirst_stage_mountflag, introduced in Android 10, which indicates that a partition is to be mounted in the first stage. - A partition may specify
avb= vbmeta partition nameas anfs_mgrflag and then the specifiedvbmetapartition is initialized by first stageinitbefore attempting to mount any devices. - The
devfield must be the partition name.
The following fstab entries set system, vendor, and product as logical partitions following the above rules.
#<dev> <mnt_point> <type> <mnt_flags options> <fs_mgr_flags> system /system ext4 ro,barrier=1 wait,slotselect,avb=vbmeta,logical,first_stage_mount vendor /vendor ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount product /product ext4 ro,barrier=1 wait,slotselect,avb,logical,first_stage_mount
Copy the fstab file into the first stage ramdisk.
SELinux changes
The super partition block device must be marked with the label super_block_device . For example, if the super partition by-name symlink is /dev/block/platform/ soc/100000.ufshc /by-name/super , add the following line to file_contexts :
/dev/block/platform/soc/10000\.ufshc/by-name/super u:object_r:super_block_device:s0
fastbootd
The bootloader (or any non-userspace flashing tool) doesn't understand dynamic partitions, so it can't flash them. To address this, devices must use a user-space implementation of the fastboot protocol, called fastbootd.
For more information on how to implement fastbootd, see Moving Fastboot to User Space .
adb রিমাউন্ট
For developers using eng or userdebug builds, adb remount is extremely useful for fast iteration. Dynamic partitions pose a problem for adb remount because there is no longer free space within each file system. To address this, devices can enable overlayfs. As long as there is free space within the super partition, adb remount automatically creates a temporary dynamic partition and uses overlayfs for writes. The temporary partition is named scratch , so don't use this name for other partitions.
For more information on how to enable overlayfs, see the overlayfs README in AOSP.
Upgrade Android devices
If you upgrade a device to Android 10, and want to include dynamic partitions support in the OTA, you don't need to change the built-in partition table. Some extra configuration is required.
Device configuration changes
To retrofit dynamic partitioning, add the following flags in device.mk :
PRODUCT_USE_DYNAMIC_PARTITIONS := true PRODUCT_RETROFIT_DYNAMIC_PARTITIONS := true
Board configuration changes
You're required to set the following board variables:
- Set
BOARD_SUPER_PARTITION_BLOCK_DEVICESto the list of block devices used to store extents of dynamic partitions. This is the list of names of existing physical partitions on the device. - Set
BOARD_SUPER_PARTITION_ partition _DEVICE_SIZEto the sizes of each block device inBOARD_SUPER_PARTITION_BLOCK_DEVICES, respectively. This is the list of sizes of existing physical partitions on the device. This is usuallyBOARD_ partition IMAGE_PARTITION_SIZEin existing board configurations. - Unset existing
BOARD_ partition IMAGE_PARTITION_SIZEfor all partitions inBOARD_SUPER_PARTITION_BLOCK_DEVICES. - Set
BOARD_SUPER_PARTITION_SIZEto the sum ofBOARD_SUPER_PARTITION_ partition _DEVICE_SIZE. - Set
BOARD_SUPER_PARTITION_METADATA_DEVICEto the block device where dynamic partition metadata is stored. It must be one ofBOARD_SUPER_PARTITION_BLOCK_DEVICES. Usually, this is set tosystem. - Set
BOARD_SUPER_PARTITION_GROUPS,BOARD_ group _SIZE, andBOARD_ group _PARTITION_LIST, respectively. See Board configuration changes on new devices for details.
For example, if the device already has system and vendor partitions, and you want to convert them to dynamic partitions and add a new product partition during the update, set this board configuration:
BOARD_SUPER_PARTITION_BLOCK_DEVICES := system vendor BOARD_SUPER_PARTITION_METADATA_DEVICE := system # Rename BOARD_SYSTEMIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE. BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE := <size-in-bytes> # Rename BOARD_VENDORIMAGE_PARTITION_SIZE to BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE := <size-in-bytes> # This is BOARD_SUPER_PARTITION_SYSTEM_DEVICE_SIZE + BOARD_SUPER_PARTITION_VENDOR_DEVICE_SIZE BOARD_SUPER_PARTITION_SIZE := <size-in-bytes> # Configuration for dynamic partitions. For example: BOARD_SUPER_PARTITION_GROUPS := group_foo BOARD_GROUP_FOO_SIZE := <size-in-bytes> BOARD_GROUP_FOO_PARTITION_LIST := system vendor product
SELinux changes
The super partition block devices must be marked with the attribute super_block_device_type . For example, if the device already has system and vendor partitions, you want to use them as block devices to store extents of dynamic partitions, and their by-name symlinks are marked as system_block_device :
/dev/block/platform/soc/10000\.ufshc/by-name/system u:object_r:system_block_device:s0 /dev/block/platform/soc/10000\.ufshc/by-name/vendor u:object_r:system_block_device:s0
Then, add the following line to device.te :
typeattribute system_block_device super_block_device_type;
For other configurations, see Implementing dynamic partitions on new devices .
For more information about retrofit updates, see OTA for A/B Devices without Dynamic Partitions .
কারখানার ছবি
For a device launching with dynamic partitions support, avoid using userspace fastboot to flash factory images, as booting to userspace is slower than other flashing methods.
To address this, make dist now builds an additional super.img image that can be flashed directly to the super partition. It automatically bundles the contents of logical partitions, meaning it contains system.img , vendor.img , and so on, in addition to the super partition metadata. This image can be flashed directly to the super partition without any additional tooling or using fastbootd. After the build, super.img is placed in ${ANDROID_PRODUCT_OUT} .
For A/B devices that launch with dynamic partitions, super.img contains images in the A slot. After flashing the super image directly, mark slot A as bootable before rebooting the device.
For retrofit devices, make dist builds a set of super_*.img images that can be flashed directly to corresponding physical partitions. For example, make dist builds super_system.img and super_vendor.img when BOARD_SUPER_PARTITION_BLOCK_DEVICES is the system vendor. These images are placed in the OTA folder in target_files.zip .
Device mapper storage-device tuning
Dynamic partitioning accommodates a number of nondeterministic device-mapper objects. These may not all instantiate as expected, so you must track all mounts, and update the Android properties of all the associated partitions with their underlying storage devices.
A mechanism inside init tracks the mounts and asynchronously updates the Android properties. The amount of time this takes isn't guaranteed to be within a specific period, so you must provide enough time for all on property triggers to react. The properties are dev.mnt.blk. <partition> where <partition> is root , system , data , or vendor , for example. Each property is associated with the base storage-device name, as shown in these examples:
taimen:/ % getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [sda] [dev.mnt.blk.firmware]: [sde] [dev.mnt.blk.metadata]: [sde] [dev.mnt.blk.persist]: [sda] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.vendor]: [dm-1] blueline:/ $ getprop | grep dev.mnt.blk [dev.mnt.blk.data]: [dm-4] [dev.mnt.blk.metadata]: [sda] [dev.mnt.blk.mnt.scratch]: [sda] [dev.mnt.blk.mnt.vendor.persist]: [sdf] [dev.mnt.blk.product]: [dm-2] [dev.mnt.blk.root]: [dm-0] [dev.mnt.blk.system_ext]: [dm-3] [dev.mnt.blk.vendor]: [dm-1] [dev.mnt.blk.vendor.firmware_mnt]: [sda]
The init.rc language allows the Android properties to be expanded as part of the rules, and storage devices can be tuned by the platform as needed with commands like these:
write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb 128 write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb 128
Once command processing starts in second-stage init , the epoll loop becomes active, and the values start to update. However, because property triggers aren't active until late- init , they can't be used in the initial boot stages to handle root , system , or vendor . You may expect the kernel default read_ahead_kb to be sufficient until the init.rc scripts can override in early-fs (when various daemons and facilities start). Therefore, Google recommends that you use the on property feature, coupled with an init.rc -controlled property like sys.read_ahead_kb , to deal with timing the operations and to prevent race conditions, as in these examples:
on property:dev.mnt.blk.root=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.root}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.system=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.vendor=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.vendor}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.product=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.system_ext}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.oem=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.oem}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on property:dev.mnt.blk.data=* && property:sys.read_ahead_kb=* write /sys/block/${dev.mnt.blk.data}/queue/read_ahead_kb ${sys.read_ahead_kb:-2048} on early-fs: setprop sys.read_ahead_kb ${ro.read_ahead_kb.boot:-2048} on property:sys.boot_completed=1 setprop sys.read_ahead_kb ${ro.read_ahead_kb.bootcomplete:-128}