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

ডায়নামিক পার্টিশন ছাড়া A/B ডিভাইসের জন্য OTA

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

এই পৃষ্ঠাটি বর্ণনা করে যে কীভাবে OTA ক্লায়েন্টরা ডায়নামিক পার্টিশন সমর্থন ছাড়াই চালু হওয়া A/B ডিভাইসগুলির জন্য একটি আপডেটের সময় গতিশীল পার্টিশনের আকার পরিবর্তন করে এবং কীভাবে OTA ক্লায়েন্টরা Android 10 এ আপগ্রেড করে।

পটভূমি

গতিশীল পার্টিশন সমর্থন করার জন্য একটি A/B ডিভাইসের আপডেটের সময়, ডিভাইসে GUID পার্টিশন টেবিল (GPT) সংরক্ষিত থাকে, তাই ডিভাইসে super পার্টিশন নেই। মেটাডেটা system_a এবং system_b এ সংরক্ষণ করা হয়, কিন্তু এটি BOARD_SUPER_PARTITION_METADATA_DEVICE পরিবর্তন করে কাস্টমাইজ করা যেতে পারে।

প্রতিটি ব্লক ডিভাইসে, দুটি মেটাডেটা স্লট আছে। প্রতিটি ব্লক ডিভাইসে শুধুমাত্র একটি মেটাডেটা স্লট ব্যবহার করা হয়। উদাহরণস্বরূপ, system_a এ মেটাডেটা 0 এবং system_b এ মেটাডেটা 1 যথাক্রমে A এবং B স্লটে পার্টিশনের সাথে মিলে যায়। রানটাইমে, কোন স্লট আপডেট করা হচ্ছে তা বিবেচ্য নয়।

এই পৃষ্ঠায়, মেটাডেটা স্লটগুলিকে বলা হয় মেটাডেটা এস (উৎস) এবং মেটাডেটা টি (লক্ষ্য)। একইভাবে, পার্টিশনগুলিকে বলা হয় system_s , vendor_t , ইত্যাদি।

বিল্ড সিস্টেম কনফিগারেশন সম্পর্কে আরও তথ্যের জন্য, ডিভাইস আপগ্রেড করা দেখুন।

পার্টিশন কিভাবে আপডেট গোষ্ঠীর অন্তর্গত সে সম্পর্কে আরও তথ্যের জন্য, নতুন ডিভাইসের জন্য বোর্ড কনফিগারেশন পরিবর্তনগুলি দেখুন।

একটি ডিভাইসে মেটাডেটার একটি উদাহরণ হল:

শারীরিক ব্লক ডিভাইস system_a
- মেটাডেটা 0
  - গ্রুপ foo_a
    - লজিক্যাল (গতিশীল) পার্টিশন system_a
    - যৌক্তিক (গতিশীল) পার্টিশন product_services_a
    - Foo দ্বারা আপডেট করা অন্যান্য পার্টিশন
  - গ্রুপ bar_a
    - যৌক্তিক (গতিশীল) পার্টিশন vendor_a
    - যৌক্তিক (গতিশীল) পার্টিশন product_a
    - অন্যান্য পার্টিশন বার দ্বারা আপডেট করা হয়েছে
- মেটাডেটা 1 (ব্যবহার করা হয়নি)
শারীরিক ব্লক ডিভাইস system_b
- মেটাডেটা 0 (ব্যবহার করা হয়নি)
- মেটাডেটা 1
  - গ্রুপ foo_b
    - লজিক্যাল (ডাইনামিক) পার্টিশন system_b
    - যৌক্তিক (গতিশীল) পার্টিশন product_services_b
    - Foo দ্বারা আপডেট করা অন্যান্য পার্টিশন
  - গ্রুপ বার_খ
    - লজিক্যাল (গতিশীল) পার্টিশন vendor_b
    - যৌক্তিক (গতিশীল) পার্টিশন product_b
    - অন্যান্য পার্টিশন বার দ্বারা আপডেট করা হয়েছে

আপনি আপনার ডিভাইসে মেটাডেটা ডাম্প করতে system/extras/partition_tools অধীনে lpdump টুল ব্যবহার করতে পারেন। যেমন:

lpdump --slot 0 /dev/block/by-name/system_a
lpdump --slot 1 /dev/block/by-name/system_b

একটি আপডেট retrofit

অ্যান্ড্রয়েড 9 এবং তার পরে চলমান ডিভাইসগুলিতে, ডিভাইসে OTA ক্লায়েন্ট আপডেটের আগে ম্যাপিং ডায়নামিক পার্টিশন সমর্থন করে না। প্যাচের একটি অতিরিক্ত সেট তৈরি করা হয়েছে যাতে ম্যাপিং সরাসরি বিদ্যমান ফিজিক্যাল পার্টিশনে প্রয়োগ করা যায়।

OTA জেনারেটর চূড়ান্ত super.img ফাইল তৈরি করে যাতে সমস্ত গতিশীল পার্টিশনের বিষয়বস্তু থাকে, তারপরে সিস্টেম, বিক্রেতা ইত্যাদির সাথে সম্পর্কিত শারীরিক ব্লক ডিভাইসের আকারের সাথে মিলে যাওয়া একাধিক ছবিতে বিভক্ত করে। এই ছবিগুলোর নাম super_system.img , super_vendor.img ইত্যাদি। OTA ক্লায়েন্ট লজিক্যাল (ডাইনামিক) পার্টিশনের জন্য ইমেজ প্রয়োগ করার পরিবর্তে এই ছবিগুলিকে ভৌত পার্টিশনে প্রয়োগ করে।

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

আপডেট প্রবাহ Android 9 এর মতোই।

আপডেটের আগে:

ro.boot.dynamic_partitions=
ro.boot.dynamic_partitions_retrofit=

আপডেটের পরে:

ro.boot.dynamic_partitions=true
ro.boot.dynamic_partitions_retrofit=true

রেট্রোফিটের পর ভবিষ্যতের আপডেট

রেট্রোফিট আপডেটের পরে, OTA ক্লায়েন্টকে গতিশীল পার্টিশনের সাথে কাজ করার জন্য আপডেট করা হয়। সোর্স পার্টিশনের পরিধি কখনই টার্গেট ফিজিক্যাল পার্টিশন জুড়ে বিস্তৃত হয় না।

নিয়মিত আপডেট প্যাকেজ ব্যবহার করে প্রবাহ আপডেট করুন

super পার্টিশন মেটাডেটা শুরু করুন।
1. মেটাডেটা এস (সোর্স মেটাডেটা) থেকে নতুন মেটাডেটা এম তৈরি করুন। উদাহরণস্বরূপ, যদি মেটাডেটা S ব্লক ডিভাইস হিসাবে [ system_s , vendor_s , product_s ] ব্যবহার করে, তাহলে নতুন মেটাডেটা M ব্লক ডিভাইস হিসাবে [ system_t , vendor_t , product_t ] ব্যবহার করে। সমস্ত গ্রুপ এবং পার্টিশন M এ বাতিল করা হয়।
2. আপডেট ম্যানিফেস্টে dynamic_partition_metadata ফিল্ড অনুযায়ী টার্গেট গ্রুপ এবং পার্টিশন যোগ করুন। প্রতিটি পার্টিশনের আকার new_partition_info এ পাওয়া যাবে।
3. মেটাডেটা T-এ M লিখুন।
4. ডিভাইস ম্যাপারে যোগ করা পার্টিশনগুলিকে লিখনযোগ্য হিসাবে ম্যাপ করুন।
ব্লক ডিভাইসে আপডেট প্রয়োগ করুন.
1. প্রয়োজনে, শুধুমাত্র পঠিত হিসাবে ডিভাইস ম্যাপারে উত্স পার্টিশনগুলি ম্যাপ করুন। এটি সাইডলোডিংয়ের জন্য প্রয়োজনীয় কারণ সোর্স পার্টিশনগুলি আপডেটের আগে ম্যাপ করা হয়নি।
2. লক্ষ্য স্লটে সমস্ত ব্লক ডিভাইসে একটি সম্পূর্ণ বা ডেল্টা আপডেট প্রয়োগ করুন।
3. পোস্ট-ইনস্টল স্ক্রিপ্ট চালানোর জন্য পার্টিশনগুলি মাউন্ট করুন, এবং তারপর পার্টিশনগুলি আনমাউন্ট করুন।
টার্গেট পার্টিশন আনম্যাপ করুন।

একটি রেট্রোফিট আপডেট প্যাকেজ ব্যবহার করে প্রবাহ আপডেট করুন

যদি রেট্রোফিট আপডেট প্যাকেজটি এমন একটি ডিভাইসে প্রয়োগ করা হয় যা ইতিমধ্যেই গতিশীল পার্টিশন সক্ষম করে, OTA ক্লায়েন্ট সরাসরি ব্লক ডিভাইসগুলিতে split super.img ফাইলটি প্রয়োগ করে। আপডেট ফ্লো একটি retrofit আপডেট অনুরূপ. বিস্তারিত জানার জন্য একটি আপডেট রিট্রোফিটিং দেখুন।

উদাহরণস্বরূপ, নিম্নলিখিত অনুমান করুন:

স্লট A হল সক্রিয় স্লট।
system_a স্লট 0 এ সক্রিয় মেটাডেটা ধারণ করে।
system_a , vendor_a , এবং product_a ব্লক ডিভাইস হিসাবে ব্যবহৃত হয়।

যখন OTA ক্লায়েন্ট একটি রেট্রোফিট আপডেট প্যাকেজ গ্রহণ করে, তখন এটি super_system.img ফিজিক্যাল system_b এ, super_vendor.img ফিজিক্যাল vendor_b এ এবং super_product.img ফিজিক্যাল product_b এ প্রযোজ্য হয়। লজিক্যাল system_b , vendor_b , এবং product_b বুট করার সময় ম্যাপ করার জন্য ফিজিক্যাল ব্লক ডিভাইস system_b সঠিক মেটাডেটা থাকে।

আপডেট প্যাকেজ তৈরি করুন

বর্ধিত ওটিএ

রেট্রোফিট ডিভাইসগুলির জন্য ক্রমবর্ধমান OTAs তৈরি করার সময়, বেস বিল্ড PRODUCT_USE_DYNAMIC_PARTITIONS এবং PRODUCT_RETROFIT_DYNAMIC_PARTITIONS সংজ্ঞায়িত করে কিনা তার উপর আপডেটগুলি নির্ভর করে।

যদি বেস বিল্ড ভেরিয়েবলগুলিকে সংজ্ঞায়িত না করে তবে এটি একটি রেট্রোফিটিং আপডেট। আপডেট প্যাকেজটিতে split super.img ফাইল রয়েছে এবং পোস্ট-ইনস্টল পদক্ষেপটি নিষ্ক্রিয় করে।
যদি বেস বিল্ড ভেরিয়েবলগুলিকে সংজ্ঞায়িত করে তবে এটি ডায়নামিক পার্টিশনের সাথে একটি সাধারণ আপডেটের মতোই। আপডেট প্যাকেজে লজিক্যাল (ডাইনামিক) পার্টিশনের জন্য ছবি রয়েছে। পোস্ট-ইনস্টল পদক্ষেপ সক্রিয় করা যেতে পারে।

সম্পূর্ণ OTA

রেট্রোফিট ডিভাইসের জন্য দুটি সম্পূর্ণ OTA প্যাকেজ তৈরি করা হয়।

$(PRODUCT)-ota-retrofit-$(TAG).zip সর্বদা স্প্লিট super.img থাকে এবং রিট্রোফিটিং আপডেটের জন্য পোস্ট-ইনস্টল স্টেপ অক্ষম করে।
- এটি ota_from_target_files স্ক্রিপ্টে একটি অতিরিক্ত যুক্তি --retrofit_dynamic_partitions দিয়ে তৈরি করা হয়েছে।
- এটি সমস্ত বিল্ডে প্রয়োগ করা যেতে পারে।
$(PRODUCT)-ota-$(TAG).zip ভবিষ্যত আপডেটের জন্য যৌক্তিক ছবি রয়েছে।
- এটি শুধুমাত্র গতিশীল পার্টিশন সক্রিয় সহ বিল্ডগুলিতে প্রয়োগ করুন। এটি কার্যকর করার জন্য নীচের বিবরণ দেখুন।

পুরানো বিল্ডগুলিতে ননরেট্রোফিট আপডেট প্রত্যাখ্যান করুন

নিয়মিত সম্পূর্ণ OTA প্যাকেজ প্রয়োগ করুন শুধুমাত্র ডায়নামিক পার্টিশন সক্রিয় সহ বিল্ড করার জন্য। যদি OTA সার্ভারটি ভুলভাবে কনফিগার করা থাকে এবং এই প্যাকেজগুলিকে Android 9 বা তার নিচের সংস্করণে চলমান ডিভাইসগুলিতে ঠেলে দেয়, ডিভাইসগুলি বুট করতে ব্যর্থ হয়। অ্যান্ড্রয়েড 9 এবং তার নিচের OTA ক্লায়েন্ট একটি রেট্রোফিট OTA প্যাকেজ এবং একটি নিয়মিত সম্পূর্ণ OTA প্যাকেজের মধ্যে পার্থক্য বলতে পারে না, তাই ক্লায়েন্ট সম্পূর্ণ প্যাকেজ প্রত্যাখ্যান করবে না।

ডিভাইসটিকে সম্পূর্ণ OTA প্যাকেজ গ্রহণ করা থেকে আটকাতে, বিদ্যমান ডিভাইস কনফিগারেশন পরীক্ষা করার জন্য আপনাকে একটি পোস্ট-ইনস্টল পদক্ষেপের প্রয়োজন হতে পারে। যেমন:

device/ device_name /dynamic_partitions/check_dynamic_partitions

#!/system/bin/sh
DP_PROPERTY_NAME="ro.boot.dynamic_partitions"
DP_RETROFIT_PROPERTY_NAME="ro.boot.dynamic_partitions_retrofit"

DP_PROPERTY=$(getprop ${DP_PROPERTY_NAME})
DP_RETROFIT_PROPERTY=$(getprop ${DP_RETROFIT_PROPERTY_NAME})

if [ "${DP_PROPERTY}" != "true" ] || [ "${DP_RETROFIT_PROPERTY}" != "true" ] ; then
    echo "Error: applied non-retrofit update on build without dynamic" \
         "partitions."
    echo "${DP_PROPERTY_NAME}=${DP_PROPERTY}"
    echo "${DP_RETROFIT_PROPERTY_NAME}=${DP_RETROFIT_PROPERTY}"
    exit 1
fi

device/ device_name /dynamic_partitions/Android.mk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE:= check_dynamic_partitions
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES
LOCAL_SRC_FILES := check_dynamic_partitions
LOCAL_PRODUCT_MODULE := true
include $(BUILD_PREBUILT)

device/ device_name /device.mk

PRODUCT_PACKAGES += check_dynamic_partitions

# OPTIONAL=false so that the error in check_dynamic_partitions will be
# propagated to OTA client.
AB_OTA_POSTINSTALL_CONFIG += \
    RUN_POSTINSTALL_product=true \
    POSTINSTALL_PATH_product=bin/check_dynamic_partitions \
    FILESYSTEM_TYPE_product=ext4 \
    POSTINSTALL_OPTIONAL_product=false \

যখন নিয়মিত OTA প্যাকেজটি একটি ডিভাইসে গতিশীল পার্টিশন সক্রিয় না করে প্রয়োগ করা হয়, তখন OTA ক্লায়েন্ট একটি পোস্ট-ইনস্টল পদক্ষেপ হিসাবে check_dynamic_partitions চালায় এবং আপডেটটি প্রত্যাখ্যান করে।