OEM এবং SoC বিক্রেতারা যারা A/B সিস্টেম আপডেট বাস্তবায়ন করতে চায় তাদের অবশ্যই নিশ্চিত করতে হবে যে তাদের বুটলোডার boot_control HAL প্রয়োগ করছে এবং কার্নেলে সঠিক পরামিতি পাস করেছে।
বুট কন্ট্রোল HAL প্রয়োগ করুন
A/B- সক্ষম বুটলোডারদের hardware/libhardware/include/hardware/boot_control.h
এ boot_control
HAL প্রয়োগ করতে হবে। আপনি system/extras/bootctl
ইউটিলিটি এবং system/extras/tests/bootloader/
ব্যবহার করে বাস্তবায়ন পরীক্ষা করতে পারেন।
আপনাকে অবশ্যই নীচে দেখানো স্টেট মেশিনটি বাস্তবায়ন করতে হবে:
কার্নেল সেট আপ করুন
A/B সিস্টেম আপডেট বাস্তবায়ন করতে:
- নিম্নলিখিত কার্নেল প্যাচ সিরিজ চেরিপিক করুন (যদি প্রয়োজন হয়):
- যদি রামডিস্ক ছাড়া বুট করা হয় এবং "বুট অ্যাজ রিকভারি" ব্যবহার করা হয়, তাহলে চেরিপিক android-review.googlesource.com/#/c/158491/ ।
- ramdisk ছাড়া dm-verity সেট আপ করতে, cherrypick android-review.googlesource.com/#/q/status:merged+project:kernel/common+branch:android-3.18+topic:A_B_Changes_3.18 ।
- নিশ্চিত করুন যে কার্নেল কমান্ড লাইন আর্গুমেন্টে নিম্নলিখিত অতিরিক্ত আর্গুমেন্ট রয়েছে:
... যেখানেskip_initramfs rootwait ro init=/init root="/dev/dm-0 dm=system none ro,0 1 android-verity <public-key-id> <path-to-system-partition>"
<public-key-id>
মান হল পাবলিক কী-এর আইডি যা ভেরিটি টেবিল স্বাক্ষর যাচাই করতে ব্যবহৃত হয় (বিস্তারিত জানতে, dm-verity দেখুন)। - সিস্টেম কীরিং-এ সর্বজনীন কী ধারণকারী .X509 শংসাপত্র যোগ করুন:
-
kernel
ডিরেক্টরির রুটে.der
ফরম্যাটে ফরম্যাট করা .X509 সার্টিফিকেট কপি করুন। যদি .X509 সার্টিফিকেট একটি.pem
ফাইল হিসাবে ফর্ম্যাট করা হয়, তাহলে.pem
থেকে.der
ফর্ম্যাটে রূপান্তর করতে নিম্নলিখিতopenssl
কমান্ডটি ব্যবহার করুন:openssl x509 -in <x509-pem-certificate> -outform der -out <x509-der-certificate>
- সিস্টেম কীরিংয়ের অংশ হিসাবে শংসাপত্রটি অন্তর্ভুক্ত করতে
zImage
তৈরি করুন। যাচাই করতে,procfs
এন্ট্রি পরীক্ষা করুন (সক্ষম হতেKEYS_CONFIG_DEBUG_PROC_KEYS
প্রয়োজন): .X509 শংসাপত্রের সফল অন্তর্ভুক্তি সিস্টেম কীরিং-এ সর্বজনীন কী-এর উপস্থিতি নির্দেশ করে (হাইলাইট সর্বজনীন কী আইডি নির্দেশ করে)।angler:/# cat /proc/keys 1c8a217e I------ 1 perm 1f010000 0 0 asymmetri Android: 7e4333f9bba00adfe0ede979e28ed1920492b40f: X509.RSA 0492b40f [] 2d454e3e I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1/4
- স্থানটি
#
দিয়ে প্রতিস্থাপন করুন এবং কার্নেল কমান্ড লাইনে<public-key-id>
হিসাবে পাস করুন। উদাহরণস্বরূপ,<public-key-id>
এর জায়গায়Android:#7e4333f9bba00adfe0ede979e28ed1920492b40f
পাস করুন।
-
বিল্ড ভেরিয়েবল সেট করুন
A/B- সক্ষম বুটলোডারদের অবশ্যই নিম্নলিখিত বিল্ড পরিবর্তনশীল মানদণ্ড পূরণ করতে হবে:
A/B টার্গেটের জন্য অবশ্যই সংজ্ঞায়িত করতে হবে |
/device/google/marlin/+/android-7.1.0_r1/device-common.mk দেখুন। আপনি ঐচ্ছিকভাবে কম্পাইলিং -এ বর্ণিত পোস্ট-ইনস্টল (কিন্তু প্রি-রিবুট) dex2oat পদক্ষেপটি পরিচালনা করতে পারেন। |
---|---|
A/B টার্গেটের জন্য দৃঢ়ভাবে সুপারিশ করা হয় |
|
A/B লক্ষ্যের জন্য সংজ্ঞায়িত করা যাবে না |
|
ডিবাগ বিল্ডের জন্য ঐচ্ছিক | PRODUCT_PACKAGES_DEBUG += update_engine_client |
পার্টিশন সেট করুন (স্লট)
A/B ডিভাইসগুলির একটি পুনরুদ্ধার পার্টিশন বা ক্যাশে পার্টিশনের প্রয়োজন নেই কারণ Android আর এই পার্টিশনগুলি ব্যবহার করে না৷ ডাটা পার্টিশনটি এখন ডাউনলোড করা OTA প্যাকেজের জন্য ব্যবহার করা হয় এবং রিকভারি ইমেজ কোডটি বুট পার্টিশনে রয়েছে। A/B-ed সমস্ত পার্টিশনের নামকরণ করা উচিত নিম্নরূপ (স্লটগুলি সর্বদা a
, b
, ইত্যাদি নাম দেওয়া হয়): boot_a
, boot_b
, system_a
, system_b
, vendor_a
, vendor_b
।
ক্যাশে
নন-A/B আপডেটের জন্য, ডাউনলোড করা OTA প্যাকেজগুলি সংরক্ষণ করতে এবং আপডেটগুলি প্রয়োগ করার সময় অস্থায়ীভাবে ব্লকগুলিকে লুকিয়ে রাখতে ক্যাশে পার্টিশন ব্যবহার করা হয়েছিল। ক্যাশে পার্টিশনের মাপ করার একটি ভাল উপায় ছিল না: আপনি কোন আপডেটগুলি প্রয়োগ করতে চান তার উপর নির্ভর করে এটি কত বড় হবে। সবচেয়ে খারাপ ক্ষেত্রে সিস্টেম ইমেজ হিসাবে বড় একটি ক্যাশে পার্টিশন হবে. A/B আপডেটের সাথে ব্লকগুলি লুকিয়ে রাখার দরকার নেই (কারণ আপনি সর্বদা এমন একটি পার্টিশনে লিখছেন যা বর্তমানে ব্যবহার করা হয় না) এবং A/B স্ট্রিমিং এর সাথে এটি প্রয়োগ করার আগে পুরো OTA প্যাকেজটি ডাউনলোড করার দরকার নেই।
পুনরুদ্ধার
রিকভারি RAM ডিস্ক এখন boot.img
ফাইলে রয়েছে। পুনরুদ্ধারের সময়, বুটলোডার কার্নেল কমান্ড লাইনে skip_initramfs
বিকল্পটি রাখতে পারে না ।
নন-A/B আপডেটের জন্য, পুনরুদ্ধার পার্টিশনে আপডেটগুলি প্রয়োগ করতে ব্যবহৃত কোড থাকে। A/B আপডেটগুলি নিয়মিত বুট করা সিস্টেম ইমেজে চলমান update_engine
দ্বারা প্রয়োগ করা হয়। ফ্যাক্টরি ডেটা রিসেট এবং আপডেট প্যাকেজগুলির সাইডলোডিং (যেখান থেকে "পুনরুদ্ধার" নামটি এসেছে) বাস্তবায়নের জন্য এখনও একটি পুনরুদ্ধার মোড ব্যবহার করা হয়েছে। পুনরুদ্ধার মোডের জন্য কোড এবং ডেটা একটি রামডিস্কের নিয়মিত বুট পার্টিশনে সংরক্ষণ করা হয়; সিস্টেম ইমেজে বুট করার জন্য, বুটলোডার কার্নেলকে র্যামডিস্ক এড়িয়ে যেতে বলে (অন্যথায় ডিভাইসটি রিকভারি মোডে বুট হয়। রিকভারি মোড ছোট (এবং এর বেশিরভাগই বুট পার্টিশনে ছিল), তাই বুট পার্টিশন বাড়ে না। আকারে
Fstab
A/B-ed পার্টিশনের জন্য slotselect
আর্গুমেন্ট অবশ্যই লাইনে থাকতে হবে। যেমন:
<path-to-block-device>/vendor /vendor ext4 ro wait,verify=<path-to-block-device>/metadata,slotselect
vendor
নাম দেওয়া উচিত নয়। পরিবর্তে, পার্টিশন vendor_a
বা vendor_b
নির্বাচন করা হবে এবং /vendor
মাউন্ট পয়েন্টে মাউন্ট করা হবে।
কার্নেল স্লট আর্গুমেন্ট
বর্তমান স্লট প্রত্যয়টি একটি নির্দিষ্ট ডিভাইস ট্রি (DT) নোড ( /firmware/android/slot_suffix
) বা androidboot.slot_suffix
কার্নেল কমান্ড লাইন বা বুট কনফিগ আর্গুমেন্টের মাধ্যমে পাস করা উচিত।
ডিফল্টরূপে, ফাস্টবুট একটি A/B ডিভাইসে বর্তমান স্লট ফ্ল্যাশ করে। যদি আপডেট প্যাকেজে অন্যান্য, নন-কারেন্ট স্লটের জন্যও ছবি থাকে, ফাস্টবুট সেই ছবিগুলিকেও ফ্ল্যাশ করে। উপলব্ধ বিকল্প অন্তর্ভুক্ত:
-
--slot SLOT
। ডিফল্ট আচরণ ওভাররাইড করুন এবং একটি আর্গুমেন্ট হিসাবে পাস করা স্লট ফ্ল্যাশ করতে দ্রুত বুট প্রম্পট করুন। -
--set-active [ SLOT ]
। স্লটটিকে সক্রিয় হিসাবে সেট করুন। যদি কোন ঐচ্ছিক যুক্তি নির্দিষ্ট করা না থাকে, তাহলে বর্তমান স্লট সক্রিয় হিসাবে সেট করা হয়। -
fastboot --help
। কমান্ড বিস্তারিত পান.
যদি বুটলোডার ফাস্টবুট প্রয়োগ করে, তাহলে এটি set_active <slot>
কমান্ড সমর্থন করবে যা প্রদত্ত স্লটে বর্তমান সক্রিয় স্লট সেট করে (এটি অবশ্যই সেই স্লটের জন্য আনবুটযোগ্য পতাকাটিও পরিষ্কার করতে হবে এবং পুনরায় চেষ্টা গণনাকে ডিফল্ট মানগুলিতে পুনরায় সেট করতে হবে)। বুটলোডার নিম্নলিখিত ভেরিয়েবলগুলিকে সমর্থন করবে:
-
has-slot:<partition-base-name-without-suffix>
। প্রদত্ত পার্টিশন যদি স্লট সমর্থন করে তবে "হ্যাঁ" দেয়, অন্যথায় "না"। -
current-slot
স্লট প্রত্যয়টি ফেরত দেয় যা পরবর্তী থেকে বুট করা হবে। -
slot-count
উপলব্ধ স্লটের সংখ্যা উপস্থাপন করে একটি পূর্ণসংখ্যা প্রদান করে। বর্তমানে, দুটি স্লট সমর্থিত তাই এই মান হল2
। -
slot-successful:<slot-suffix>
. প্রদত্ত স্লট সফলভাবে বুটিং হিসাবে চিহ্নিত করা হলে "হ্যাঁ" ফেরত দেয়, অন্যথায় "না"। -
slot-unbootable:<slot-suffix>
। প্রদত্ত স্লটটি আনবুটযোগ্য হিসাবে চিহ্নিত হলে "হ্যাঁ" ফেরত দেয়, অন্যথায় "না"। -
slot-retry-count:<slot-suffix>
। প্রদত্ত স্লট বুট করার চেষ্টা করার জন্য বাকি পুনঃপ্রচারের সংখ্যা।
সমস্ত ভেরিয়েবল দেখতে, fastboot getvar all
চালান।
OTA প্যাকেজ তৈরি করুন
OTA প্যাকেজ টুলগুলি নন-A/B ডিভাইসগুলির জন্য কমান্ডের মতো একই কমান্ড অনুসরণ করে। target_files.zip
ফাইলটি অবশ্যই A/B টার্গেটের জন্য বিল্ড ভেরিয়েবল নির্ধারণ করে তৈরি করতে হবে। OTA প্যাকেজ টুলগুলি স্বয়ংক্রিয়ভাবে A/B আপডেটারের বিন্যাসে প্যাকেজগুলি সনাক্ত করে এবং তৈরি করে।
উদাহরণ:
- একটি সম্পূর্ণ OTA তৈরি করতে:
./build/make/tools/releasetools/ota_from_target_files \ dist_output/tardis-target_files.zip \ ota_update.zip
- একটি বর্ধিত ওটিএ তৈরি করতে:
./build/make/tools/releasetools/ota_from_target_files \ -i PREVIOUS-tardis-target_files.zip \ dist_output/tardis-target_files.zip \ incremental_ota_update.zip
পার্টিশন কনফিগার করুন
update_engine
একই ডিস্কে সংজ্ঞায়িত A/B পার্টিশনের যেকোনো জোড়া আপডেট করতে পারে। একজোড়া পার্টিশনের একটি সাধারণ উপসর্গ থাকে (যেমন system
বা boot
) এবং প্রতি-স্লট প্রত্যয় (যেমন _a
)। পার্টিশনের তালিকা যার জন্য পেলোড জেনারেটর একটি আপডেট নির্ধারণ করে তা AB_OTA_PARTITIONS
মেক ভেরিয়েবল দ্বারা কনফিগার করা হয়।
উদাহরণস্বরূপ, যদি একটি জোড়া পার্টিশন bootloader_a
এবং booloader_b
অন্তর্ভুক্ত করা হয় ( _a
এবং _b
হল স্লট প্রত্যয়), আপনি পণ্য বা বোর্ড কনফিগারেশনে নিম্নলিখিতগুলি উল্লেখ করে এই পার্টিশনগুলি আপডেট করতে পারেন:
AB_OTA_PARTITIONS := \ boot \ system \ bootloader
update_engine
দ্বারা আপডেট করা সমস্ত পার্টিশন বাকি সিস্টেম দ্বারা পরিবর্তন করা উচিত নয়। ইনক্রিমেন্টাল বা ডেল্টা আপডেটের সময়, বর্তমান স্লট থেকে বাইনারি ডেটা ব্যবহার করা হয় নতুন স্লটে ডেটা তৈরি করতে। যেকোন পরিবর্তনের ফলে নতুন স্লট ডেটা আপডেট প্রক্রিয়া চলাকালীন যাচাইকরণ ব্যর্থ হতে পারে এবং সেইজন্য আপডেট ব্যর্থ হতে পারে।
পোস্ট ইন্সটলেশন কনফিগার করুন
আপনি কী-মান জোড়ার একটি সেট ব্যবহার করে প্রতিটি আপডেট করা পার্টিশনের জন্য পোস্ট-ইনস্টল ধাপটি ভিন্নভাবে কনফিগার করতে পারেন। একটি নতুন ইমেজে /system/usr/bin/postinst
এ অবস্থিত একটি প্রোগ্রাম চালানোর জন্য, সিস্টেম পার্টিশনে ফাইল সিস্টেমের রুটের সাথে সম্পর্কিত পাথ নির্দিষ্ট করুন।
উদাহরণস্বরূপ, usr/bin/postinst
হল system/usr/bin/postinst
(যদি RAM ডিস্ক ব্যবহার না করা হয়)। অতিরিক্তভাবে, mount(2)
সিস্টেম কলে পাস করার জন্য ফাইল-সিস্টেম প্রকার উল্লেখ করুন। পণ্য বা ডিভাইস .mk
ফাইলে নিম্নলিখিত যোগ করুন (যদি প্রযোজ্য হয়):
AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=usr/bin/postinst \ FILESYSTEM_TYPE_system=ext4
অ্যাপস কম্পাইল করুন
নতুন সিস্টেম ইমেজ দিয়ে রিবুট করার আগে অ্যাপগুলি ব্যাকগ্রাউন্ডে কম্পাইল করা যাবে। ব্যাকগ্রাউন্ডে অ্যাপ কম্পাইল করতে, পণ্যের ডিভাইস কনফিগারেশনে নিম্নলিখিত যোগ করুন (পণ্যের device.mk-এ):
- কম্পাইলেশন স্ক্রিপ্ট এবং বাইনারিগুলি কম্পাইল করা হয়েছে এবং সিস্টেম ইমেজে অন্তর্ভুক্ত করা হয়েছে তা নিশ্চিত করতে বিল্ডে নেটিভ উপাদানগুলি অন্তর্ভুক্ত করুন।
# A/B OTA dexopt package PRODUCT_PACKAGES += otapreopt_script
- সংকলন স্ক্রিপ্টটিকে
update_engine
এ সংযুক্ত করুন যেটি একটি পোস্ট-ইনস্টল পদক্ষেপ হিসাবে চলে।# A/B OTA dexopt update_engine hookup AB_OTA_POSTINSTALL_CONFIG += \ RUN_POSTINSTALL_system=true \ POSTINSTALL_PATH_system=system/bin/otapreopt_script \ FILESYSTEM_TYPE_system=ext4 \ POSTINSTALL_OPTIONAL_system=true
অব্যবহৃত দ্বিতীয় সিস্টেম পার্টিশনে প্রি-অপটেড ফাইল ইনস্টল করার জন্য সাহায্যের জন্য, DEX_PREOPT ফাইলের প্রথম বুট ইনস্টলেশন পড়ুন।