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

Android 10-এ ডায়নামিক পার্টিশন কাজ করে, এটি একটি ব্যবহারকারী স্পেস পার্টিশনিং সিস্টেম যা ওভার-দ্য-এয়ার (OTA) আপডেট চলাকালীন পার্টিশন তৈরি, রিসাইজ ও মুছে দিতে পারে।

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

ব্যাকগ্রাউন্ড

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

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

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

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

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

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

  • ফিজিক্যাল ব্লক ডিভাইস system_a
    • মেটাডেটা ০
      • গ্রুপ foo_a
        • লজিক্যাল (ডায়নামিক) পার্টিশন system_a
        • লজিক্যাল (ডায়নামিক) পার্টিশন product_services_a
        • Foo-এর দ্বারা আপডেট করা অন্যান্য পার্টিশন
      • গ্রুপ bar_a
        • লজিক্যাল (ডায়নামিক) পার্টিশন vendor_a
        • লজিক্যাল (ডায়নামিক) পার্টিশন product_a
        • Bard-এর মাধ্যমে আপডেট করা অন্যান্য পার্টিশন
    • মেটাডেটা ১ (ব্যবহার করা হয়নি)
  • ফিজিক্যাল ব্লক ডিভাইস system_b
    • মেটাডেটা 0 (ব্যবহার করা হয়নি)
    • মেটাডেটা ১
      • গ্রুপ foo_b
        • লজিক্যাল (ডায়নামিক) পার্টিশন system_b
        • লজিক্যাল (ডায়নামিক) পার্টিশন product_services_b
        • Foo-এর মাধ্যমে আপডেট করা অন্যান্য পার্টিশন
      • Group bar_b
        • লজিক্যাল (ডায়নামিক) পার্টিশন vendor_b
        • লজিক্যাল (ডায়নামিক) পার্টিশন product_b
        • Bard-এর মাধ্যমে আপডেট করা অন্যান্য পার্টিশন

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

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

আপডেট রেট্রোফিট করা

Android 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 ক্লায়েন্টকে আপডেট করা হয় যাতে সেটি ডায়নামিক পার্টিশনের সাথে কাজ করতে পারে। সোর্স পার্টিশনের এক্সটেন্ড কখনই টার্গেট ফিজিক্যাল পার্টিশন জুড়ে থাকে না।

সাধারণ আপডেট প্যাকেজ ব্যবহার করে আপডেট ফ্লো

  1. super পার্টিশন মেটাডেটা ইনিশিয়ালাইজ করুন।
    1. মেটাডেটা S (সোর্স মেটাডেটা) থেকে নতুন মেটাডেটা M তৈরি করুন। যেমন, মেটাডেটা 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. ডিভাইস ম্যাপারে যোগ করা পার্টিশনকে রাইটেবল হিসেবে ম্যাপ করুন।
  2. ব্লক করা ডিভাইসে আপডেট প্রয়োগ করুন।
    1. প্রয়োজন হলে, ডিভাইস ম্যাপারে সোর্স পার্টিশনগুলি রিড-অনলি হিসেবে ম্যাপ করুন। সাইডলোডিংয়ের জন্য এটি প্রয়োজনীয় কারণ আপডেট করার আগে সোর্স পার্টিশন ম্যাপ করা হয় না।
    2. টার্গেট স্লটে সব ব্লক ডিভাইসে সম্পূর্ণ বা ডেল্টা আপডেট প্রয়োগ করুন।
    3. ইনস্টল করার পরে স্ক্রিপ্ট চালানোর জন্য পার্টিশন মাউন্ট করুন এবং তারপরে পার্টিশন আনমাউন্ট করুন।
  3. টার্গেট পার্টিশন আনম্যাপ করুন।

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

যে ডিভাইসে আগে থেকেই ডায়নামিক পার্টিশন চালু আছে, সেটিতে রেট্রোফিট আপডেট প্যাকেজ প্রয়োগ করা হলে, OTA ক্লায়েন্ট স্প্লিট super.img ফাইলটি সরাসরি ব্লক ডিভাইসে প্রয়োগ করে। আপডেট ফ্লো রেট্রোফিট আপডেটের মতোই। আরও বিবরণের জন্য আপডেট রেট্রোফিট করা দেখুন।

যেমন, ধরে নিন যে:

  • স্লট 'ক' হল অ্যাক্টিভ স্লট।
  • system_a-এ স্লট ০-তে অ্যাক্টিভ মেটাডেটা আছে।
  • system_a, vendor_a ও product_a ব্লক ডিভাইস হিসেবে ব্যবহার করা হয়।

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

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

ইনক্রিমেন্টাল OTA

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

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

সম্পূর্ণ OTA

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

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

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

শুধুমাত্র ডায়নামিক পার্টিশন চালু করা আছে এমন বিল্ডের ক্ষেত্রে নিয়মিত সম্পূর্ণ OTA প্যাকেজ প্রয়োগ করুন। OTA সার্ভার ভুলভাবে কনফিগার করা হলে এবং Android 9 বা এর আগের যেকোনও ভার্সনে চলমান ডিভাইসে এই প্যাকেজ পুশ করা হলে, ডিভাইস বুট করতে পারে না। Android 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 রান করে এবং আপডেট বাতিল করে দেয়।