ডায়নামিক সিস্টেম আপডেট

ডায়নামিক সিস্টেম আপডেট (DSU) আপনাকে এমন একটি Android সিস্টেম ইমেজ তৈরি করতে দেয় যা ব্যবহারকারীরা ইন্টারনেট থেকে ডাউনলোড করতে এবং বর্তমান সিস্টেম ইমেজ খারাপ হয়ে যাওয়ার ঝুঁকি ছাড়াই ব্যবহার করে দেখতে পারেন। DSU কীভাবে কাজ করে তা এই ডকুমেন্টে বর্ণনা করা হয়েছে।

কার্নেল সংক্রান্ত প্রয়োজনীয়তা

কার্নেল সংক্রান্ত প্রয়োজনীয়তার জন্য ডায়নামিক পার্টিশন প্রয়োগ করা দেখুন।

এছাড়াও, Android সিস্টেম ইমেজ যাচাই করার জন্য DSU, device-mapper-verity (dm-verity) কার্নেল ফিচারের উপর নির্ভর করে। তাই আপনাকে অবশ্যই নিম্নলিখিত কার্নেল কনফিগারেশন চালু করতে হবে:

• CONFIG_DM_VERITY=y
• CONFIG_DM_VERITY_FEC=y

পার্টিশন সংক্রান্ত প্রয়োজনীয়তা

Android 11 থেকে শুরু করে, DSU-এর জন্য F2FS বা ext4 ফাইল সিস্টেম ব্যবহার করতে /data পার্টিশন প্রয়োজন। F2FS আরও ভালো পারফর্ম্যান্স দেয় এবং এটি সাজেস্ট করা হয়, তবে পার্থক্যটি খুব বেশি গুরুত্বপূর্ণ নয়।

Pixel ডিভাইসে ডায়নামিক সিস্টেম আপডেট কতক্ষণ সময় নেয় তার কিছু উদাহরণ এখানে দেওয়া হল:

• F2FS ব্যবহার করা হচ্ছে:
  • 109s, 8G ব্যবহারকারী, 867M সিস্টেম, ফাইল সিস্টেমের ধরন: F2FS: encryption=aes-256-xts:aes-256-cts
  • 104s, 8G user, 867M system, file system type: F2FS: encryption=ice
• ext4 ব্যবহার করে:
  • ১৩৫ সেকেন্ড, ৮জি ব্যবহারকারী, ৮৬৭এম সিস্টেম, ফাইল সিস্টেমের ধরন: ext4: encryption=aes-256-xts:aes-256-cts

আপনার প্ল্যাটফর্মে এটি করতে অনেক বেশি সময় লাগলে, মাউন্ট ফ্ল্যাগে এমন কোনও ফ্ল্যাগ আছে কিনা তা চেক করে দেখতে পারেন যা "সিঙ্ক" রাইট করে অথবা আরও ভাল পারফর্ম্যান্স পেতে আপনি নির্দিষ্টভাবে "অ্যাসিঙ্ক" ফ্ল্যাগ উল্লেখ করতে পারেন।

ইনস্টল করা ইমেজের সাথে সম্পর্কিত ডেটা স্টোর করার জন্য metadata পার্টিশন (১৬ এমবি বা তার বেশি) প্রয়োজন। প্রথম পর্যায়ের মাউন্ট করার সময় এটি মাউন্ট করতে হবে।

userdata পার্টিশনে অবশ্যই F2FS বা ext4 ফাইল সিস্টেম ব্যবহার করতে হবে। F2FS ব্যবহার করার সময়, Android কমন কার্নেলে উপলভ্য F2FS সম্পর্কিত সব প্যাচ অন্তর্ভুক্ত করুন।

DSU, কার্নেল/সাধারণ 4.9-এর সাথে ডেভেলপ ও পরীক্ষা করা হয়েছে। এই ফিচারের জন্য kernel 4.9 ও তার পরের যেকোনও ভার্সন ব্যবহার করার সাজেশন দেওয়া হয়।

ভেন্ডর HAL-এর আচরণ

Weaver HAL

Weaver HAL ব্যবহারকারীর কী সেভ করার জন্য নির্দিষ্ট সংখ্যক স্লট প্রদান করে। DSU দুটি অতিরিক্ত কী স্লট ব্যবহার করে। কোনও OEM-এর Weaver HAL থাকলে, সেটিতে জেনেরিক সিস্টেম ইমেজ (GSI) ও হোস্ট ইমেজের জন্য পর্যাপ্ত স্লট থাকতে হবে।

Gatekeeper HAL

Gatekeeper HAL-কে বড় USER_ID ভ্যালু সাপোর্ট করতে হবে, কারণ GSI, HAL-কে UID অফসেট করে +১০০০০০০।

বুট যাচাই করা

আপনি যদি যাচাই করা বুট বন্ধ না করে লক করা অবস্থায় ডেভেলপার GSI ইমেজ বুট করার সুবিধা দিতে চান, তাহলে device/<device_name>/device.mk ফাইলে নিম্নলিখিত লাইনটি যোগ করে ডেভেলপার GSI কী অন্তর্ভুক্ত করুন:

$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)

রোলব্যাক প্রোটেকশন

DSU ব্যবহার করার সময়, ডাউনলোড করা Android সিস্টেম ইমেজ ডিভাইসে থাকা বর্তমান সিস্টেম ইমেজের থেকে নতুন হতে হবে। এটি দুটি সিস্টেম ইমেজের Android যাচাই করা বুট (AVB) AVB প্রপার্টি ডেসক্রিপ্টর এর মধ্যে থাকা নিরাপত্তা প্যাচ লেভেল তুলনা করে করা হয়: Prop: com.android.build.system.security_patch -> '2019-04-05'.

AVB ব্যবহার করছে না এমন ডিভাইসের ক্ষেত্রে, বুটলোডারের সাথে কার্নেল cmdline বা bootconfig-এ বর্তমান সিস্টেম ইমেজের সিকিউরিটি প্যাচ লেভেল লিখুন: androidboot.system.security_patch=2019-04-05.

হার্ডওয়্যার সংক্রান্ত প্রয়োজনীয়তা

আপনি DSU ইনস্ট্যান্স লঞ্চ করলে, দুটি অস্থায়ী ফাইল অ্যাসাইন করা হয়:

• GSI.img (১~১.৫ জি) সেভ করার জন্য একটি লজিক্যাল পার্টিশন
• GSI চালানোর জন্য স্যান্ডবক্স হিসেবে ৮ GB খালি /data পার্টিশন

DSU ইনস্ট্যান্স লঞ্চ করার আগে অন্তত ১০ জিবি খালি জায়গা রাখার সাজেশন দেওয়া হয়। DSU, এসডি কার্ড থেকে অ্যাসাইনমেন্টকেও সমর্থন করে। এসডি কার্ড থাকলে, সেটিকেই বরাদ্দ করার জন্য সবচেয়ে বেশি অগ্রাধিকার দেওয়া হয়। কম পাওয়ারের ডিভাইসের জন্য এসডি কার্ডের সুবিধা খুবই গুরুত্বপূর্ণ, কারণ সেগুলিতে হয়ত পর্যাপ্ত ইন্টার্নাল স্টোরেজ থাকে না। এসডি কার্ড থাকলে, সেটি যেন অ্যাডপ্ট করা না হয়। DSU-তে অ্যাডপ্ট করা এসডি কার্ড কাজ করে না।

উপলভ্য ফ্রন্টএন্ড

আপনি adb, OEM অ্যাপ বা এক-ক্লিক DSU লোডার (Android 11 বা তার পরের যেকোনও ভার্সনে) ব্যবহার করে DSU চালু করতে পারবেন।

adb ব্যবহার করে DSU লঞ্চ করা

adb ব্যবহার করে DSU লঞ্চ করতে, এই কমান্ডগুলি লিখুন:

$ simg2img out/target/product/.../system.img system.raw
$ gzip -c system.raw > system.raw.gz
$ adb push system.raw.gz /storage/emulated/0/Download
$ adb shell am start-activity \
-n com.android.dynsystem/com.android.dynsystem.VerificationActivity  \
-a android.os.image.action.START_INSTALL    \
-d file:///storage/emulated/0/Download/system.raw.gz  \
--el KEY_SYSTEM_SIZE $(du -b system.raw|cut -f1)  \
--el KEY_USERDATA_SIZE 8589934592

অ্যাপ ব্যবহার করে DSU লঞ্চ করা

DSU-তে প্রবেশের মূল এন্ট্রি পয়েন্ট হল android.os.image.DynamicSystemClient.java API:

public class DynamicSystemClient {


...
...

     /**
     * Start installing DynamicSystem from URL with default userdata size.
     *
     * @param systemUrl A network URL or a file URL to system image.
     * @param systemSize size of system image.
     */
    public void start(String systemUrl, long systemSize) {
        start(systemUrl, systemSize, DEFAULT_USERDATA_SIZE);
    }

আপনাকে অবশ্যই ডিভাইসে এই অ্যাপটি বান্ডেল/প্রি-ইনস্টল করতে হবে। কারণ DynamicSystemClient হল একটি সিস্টেম API, আপনি সাধারণ SDK API দিয়ে অ্যাপ তৈরি করতে পারবেন না এবং Google Play-তে এটি প্রকাশ করতে পারবেন না। এই অ্যাপের উদ্দেশ্য হল:

1. কোনও ভেন্ডর-সংজ্ঞায়িত স্কিমের মাধ্যমে ছবির তালিকা ও সংশ্লিষ্ট URL সংগ্রহ করুন।
2. ডিভাইসের সাথে তালিকার ছবিগুলি ম্যাচ করুন এবং ব্যবহারকারীর বেছে নেওয়ার জন্য মানানসই ছবি দেখুন।

3. DynamicSystemClient.start-কে এইভাবে ইনভোক করুন:

   DynamicSystemClient aot = new DynamicSystemClient(...)
      aot.start(
           ...URL of the selected image...,
           ...uncompressed size of the selected image...);
   
   

URL-টি একটি gzip করা, নন-স্পার্স, সিস্টেম ইমেজ ফাইলের দিকে নির্দেশ করে, যা আপনি নিম্নলিখিত কমান্ডের সাহায্যে তৈরি করতে পারেন:

$ simg2img ${OUT}/system.img ${OUT}/system.raw
$ gzip ${OUT}/system.raw
$ ls ${OUT}/system.raw.gz

ফাইলের নাম এই ফর্ম্যাট মেনে চলতে হবে:

<android version>.<lunch name>.<user defined title>.raw.gz

উদাহরণ:

• o.aosp_taimen-userdebug.2018dev.raw.gz
• p.aosp_taimen-userdebug.2018dev.raw.gz

এক-ক্লিক DSU লোডার

Android 11-এ এক-ক্লিক DSU লোডার চালু করা হয়েছে, যা ডেভেলপার সেটিংসের ফ্রন্টএন্ড।

ছবি ১. DSU লোডার চালু করা হচ্ছে

ডেভেলপার DSU লোডার বোতামে ক্লিক করলে, এটি ওয়েব থেকে আগে থেকে কনফিগার করা DSU JSON ডেসক্রিপ্টর নিয়ে আসে এবং ফ্লোটিং মেনুতে সব প্রযোজ্য ছবি দেখায়। DSU ইনস্টলেশন শুরু করতে একটি ছবি বেছে নিন এবং বিজ্ঞপ্তি বারে প্রগ্রেস দেখানো হবে।

ছবি ২. DSU ইমেজ ইনস্টলেশন প্রগ্রেস

সাধারণত, DSU লোডার GSI ছবি থাকা JSON ডেসক্রিপ্টর লোড করে। নিম্নলিখিত বিভাগগুলি থেকে কীভাবে OEM-স্বাক্ষরিত DSU প্যাকেজ তৈরি করতে হয় এবং DSU লোডার থেকে সেগুলি লোড করতে হয় তা জানা যায়।

ফিচার ফ্ল্যাগ

DSU ফিচারটি settings_dynamic_android ফিচার ফ্ল্যাগের অধীনে থাকে। DSU ব্যবহার করার আগে, সংশ্লিষ্ট ফিচার ফ্ল্যাগ চালু আছে কিনা তা নিশ্চিত করুন।

ছবি ৩. ফিচার ফ্ল্যাগ চালু করা

ব্যবহারকারীর বিল্ড চলছে এমন ডিভাইসে ফিচার ফ্ল্যাগ UI উপলভ্য নাও থাকতে পারে। এই ক্ষেত্রে, এর পরিবর্তে adb কমান্ড ব্যবহার করুন:

$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1

GCE-তে ভেন্ডর হোস্ট সিস্টেম ইমেজ (ঐচ্ছিক)

সিস্টেম ইমেজের সম্ভাব্য স্টোরেজ লোকেশনের মধ্যে একটি হল Google Compute Engine (GCE) বাকেট। রিলিজ অ্যাডমিনিস্ট্রেটর রিলিজ করা সিস্টেম ইমেজ যোগ/মুছে/পরিবর্তন করতে GCP স্টোরেজ কনসোল ব্যবহার করেন।

ছবিগুলি অবশ্যই সর্বজনীন অ্যাক্সেস হতে হবে, যেমন এখানে দেখানো হয়েছে:

ছবি ৪. GCE-তে পাবলিক অ্যাক্সেস

কোনও আইটেম সর্বজনীন করার পদ্ধতি Google Cloud ডকুমেন্টেশনে উপলভ্য।

ZIP ফাইলে একাধিক পার্টিশন DSU

Android 11 থেকে শুরু করে, DSU-তে একাধিক পার্টিশন থাকতে পারে। যেমন, এতে system.img-এর পাশাপাশি product.img থাকতে পারে। ডিভাইস বুট করলে, প্রথম স্টেজ init ইনস্টল করা DSU পার্টিশন শনাক্ত করে এবং ইনস্টল করা DSU চালু থাকলে ডিভাইসে থাকা পার্টিশন সাময়িকভাবে পরিবর্তন করে। DSU প্যাকেজে এমন পার্টিশন থাকতে পারে যা ডিভাইসে অনুরূপ পার্টিশন নেই।

ছবি ৫. একাধিক পার্টিশন সহ DSU প্রসেস

OEM-এর স্বাক্ষর করা DSU

ডিভাইসে রান করা সব ছবি ডিভাইস নির্মাতার দ্বারা অনুমোদিত কিনা তা নিশ্চিত করতে, DSU প্যাকেজের মধ্যে থাকা সব ছবিকে সাইন করতে হবে। যেমন, ধরে নিন, একটি DSU প্যাকেজে নিচে উল্লেখ করা দুটি পার্টিশন ইমেজ আছে:

dsu.zip {
    - system.img
    - product.img
}

system.img এবং product.img দুটিই জিপ ফাইলে রাখার আগে OEM কী দ্বারা স্বাক্ষরিত হতে হবে। সাধারণত, অ্যাসিমেট্রিক অ্যালগরিদম ব্যবহার করা হয়, যেমন RSA। এখানে, প্যাকেজে স্বাক্ষর করার জন্য সিক্রেট কী এবং সেটি যাচাই করার জন্য পাবলিক কী ব্যবহার করা হয়। প্রথম স্টেজ র‍্যামডিস্কে অবশ্যই পেয়ারিং পাবলিক কী থাকতে হবে, যেমন, /avb/*.avbpubkey। ডিভাইসটি আগে থেকেই AVB গ্রহণ করে থাকলে, আগে থেকে থাকা সাইনিং প্রসেস যথেষ্ট হবে। নিচের বিভাগে স্বাক্ষর করার প্রসেস ব্যাখ্যা করা হয়েছে এবং AVB pubkey-এর প্লেসমেন্ট হাইলাইট করা হয়েছে যা DSU প্যাকেজে ইমেজ যাচাই করতে ব্যবহার করা হয়।

DSU JSON ডেসক্রিপ্টর

DSU JSON ডেসক্রিপ্টর DSU প্যাকেজ বর্ণনা করে। এটি দুটি প্রিমিটিভ সাপোর্ট করে। প্রথমে, include প্রিমিটিভের মধ্যে অতিরিক্ত JSON ডেসক্রিপ্টর বা রিডাইরেক্ট DSU লোডারকে নতুন লোকেশনে নিয়ে যায়। যেমন:

{
    "include": ["https://.../gsi-release/gsi-src.json"]
}

দ্বিতীয়ত, রিলিজ করা DSU প্যাকেজ বর্ণনা করতে image প্রিমিটিভ ব্যবহার করা হয়। ইমেজ প্রিমিটিভের মধ্যে বিভিন্ন অ্যাট্রিবিউট আছে:

• name এবং details অ্যাট্রিবিউট হল স্ট্রিং যা ব্যবহারকারীকে বেছে নেওয়ার জন্য ডায়ালগে দেখানো হয়।

• cpu_api, vndk ও os_version অ্যাট্রিবিউটগুলি মানানসই কিনা তা চেক করার জন্য ব্যবহার করা হয়, যা পরবর্তী বিভাগে বর্ণনা করা হয়েছে।

• ঐচ্ছিক pubkey অ্যাট্রিবিউটটি DSU প্যাকেজে সাইন করার জন্য ব্যবহৃত সিক্রেট কী-এর সাথে পেয়ার করা পাবলিক কী সম্পর্কে বর্ণনা করে। এটি নির্দিষ্ট করা থাকলে, DSU পরিষেবা চেক করতে পারে যে ডিভাইসে DSU প্যাকেজ যাচাই করার জন্য ব্যবহৃত কী আছে কিনা। এটি কোনও অজানা DSU প্যাকেজ ইনস্টল করা এড়ায়, যেমন OEM-B-এর তৈরি করা কোনও ডিভাইসে OEM-A-এর সাইন করা DSU ইনস্টল করা এড়ায়।

• ঐচ্ছিক tos অ্যাট্রিবিউট একটি টেক্সট ফাইলকে নির্দেশ করে যা সংশ্লিষ্ট DSU প্যাকেজের পরিষেবার শর্তাবলী বর্ণনা করে। কোনও ডেভেলপার পরিষেবার শর্তাবলী অ্যাট্রিবিউট নির্দিষ্ট করা DSU প্যাকেজ বেছে নিলে, ৬ নম্বর ছবিতে দেখানো ডায়ালগ বক্সটি খুলে যায় এবং DSU প্যাকেজ ইনস্টল করার আগে ডেভেলপারকে পরিষেবার শর্তাবলীতে সম্মতি জানাতে বলা হয়।

  

  ছবি ৬. পরিষেবার শর্তাবলী ডায়ালগ বক্স

রেফারেন্সের জন্য, এখানে GSI-এর জন্য DSU JSON ডেসক্রিপ্টর দেওয়া হল:

{
   "images":[
      {
         "name":"GSI+GMS x86",
         "os_version":"10",
         "cpu_abi": "x86",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_x86-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI+GMS ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "tos": "https://dl.google.com/developers/android/gsi/gsi-tos.txt",
         "uri":"https://.../gsi/gsi_gms_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI ARM64",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_arm64-exp-QP1A.190711.020.C4-5928301.zip"
      },
      {
         "name":"GSI x86_64",
         "os_version":"10",
         "cpu_abi": "x86_64",
         "details":"exp-QP1A.190711.020.C4-5928301",
         "vndk":[
            27,
            28,
            29
         ],
         "pubkey":"",
         "uri":"https://.../gsi/aosp_x86_64-exp-QP1A.190711.020.C4-5928301.zip"
      }
   ]
}

সামঞ্জস্য ম্যানেজমেন্ট

DSU প্যাকেজ ও স্থানীয় ডিভাইসের মধ্যে কম্প্যাটিবিলিটি নির্দিষ্ট করতে একাধিক অ্যাট্রিবিউট ব্যবহার করা হয়:

• cpu_api হল এমন একটি স্ট্রিং যা ডিভাইসের আর্কিটেকচার বর্ণনা করে। এই অ্যাট্রিবিউট বাধ্যতামূলক এবং এটি ro.product.cpu.abi সিস্টেম প্রপার্টির সাথে তুলনা করা হয়। সেগুলির মান হুবহু মিলতে হবে।

• os_version হল একটি ঐচ্ছিক পূর্ণসংখ্যা যা Android রিলিজ নির্দিষ্ট করে। যেমন, Android 10-এর জন্য, os_version হল 10 এবং Android 11-এর জন্য, os_version হল 11। এই অ্যাট্রিবিউট নির্দিষ্ট করা হলে, এটি অবশ্যই ro.system.build.version.release সিস্টেম প্রপার্টির সমান বা তার চেয়ে বেশি হতে হবে। বর্তমানে কাজ করে না এমন Android 11 ভেন্ডর ডিভাইসে Android 10 GSI ইমেজ বুট করা আটকাতে এই চেক ব্যবহার করা হয়। Android 10 ডিভাইসে Android 11 GSI ইমেজ বুট করার অনুমতি আছে।

• vndk হল একটি ঐচ্ছিক অ্যারে যা DSU প্যাকেজে অন্তর্ভুক্ত সব VNDK নির্দিষ্ট করে। এটি নির্দিষ্ট করা থাকলে, DSU লোডার চেক করে দেখে যে ro.vndk.version সিস্টেম প্রপার্টি থেকে এক্সট্র্যাক্ট করা নম্বরটি অন্তর্ভুক্ত করা হয়েছে কিনা।

নিরাপত্তার জন্য DSU কী প্রত্যাহার করা

DSU ছবি সাইন করার জন্য ব্যবহৃত RSA কী পেয়ার কম্প্রোমাইজড হয়ে গেলে, যত তাড়াতাড়ি সম্ভব র‍্যামডিস্ক আপডেট করে কম্প্রোমাইজড কী সরিয়ে দিতে হবে। বুট পার্টিশন আপডেট করা ছাড়াও, আপনি HTTPS URL থেকে DSU কী বাতিল করার তালিকা (কী ব্ল্যাকলিস্ট) ব্যবহার করে আপস করা কী ব্লক করতে পারবেন।

DSU কী প্রত্যাহার তালিকায় প্রত্যাহার করা AVB সর্বজনীন কী-এর তালিকা থাকে। DSU ইনস্টলেশনের সময়, DSU ইমেজের মধ্যে থাকা পাবলিক কী প্রত্যাহারের তালিকা দিয়ে যাচাই করা হয়। ছবিতে বাতিল করা পাবলিক কী থাকলে, DSU ইনস্টলেশন প্রসেস বন্ধ হয়ে যায়।

নিরাপত্তা নিশ্চিত করতে কী বাতিল করার তালিকার URL একটি HTTPS URL হতে হবে এবং এটি একটি রিসোর্স স্ট্রিংয়ে নির্দিষ্ট করা আছে:

frameworks/base/packages/DynamicSystemInstallationService/res/values/strings.xml@key_revocation_list_url

স্ট্রিংয়ের ভ্যালু হল https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json, যা Google-এর রিলিজ করা GSI কী-এর জন্য প্রত্যাহার তালিকা। এই রিসোর্স স্ট্রিং ওভারলে ও কাস্টমাইজ করা যেতে পারে, যাতে DSU ফিচার গ্রহণ করা OEM-রা তাদের নিজস্ব কী ব্ল্যাকলিস্ট প্রদান ও বজায় রাখতে পারে। এর ফলে OEM-এর কাছে ডিভাইসটির RAM ডিস্ক ইমেজ আপডেট না করেই নির্দিষ্ট পাবলিক কী ব্লক করার একটি উপায় থাকে।

প্রত্যাহার তালিকার ফর্ম্যাট হল:

{
   "entries":[
      {
         "public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      },
      {
         "public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
         "status":"REVOKED",
         "reason":"Key revocation test key"
      }
   ]
}

• public_key হল বাতিল করা কী-এর SHA-1 ডাইজেস্ট, যা AVB pubkey তৈরি করা বিভাগে বর্ণিত ফর্ম্যাটে আছে।
• status কী প্রত্যাহার করার স্ট্যাটাস নির্দেশ করে। বর্তমানে, শুধুমাত্র REVOKED ভ্যালু কাজ করে।
• reason হল একটি ঐচ্ছিক স্ট্রিং যা প্রত্যাহার করার কারণ বর্ণনা করে।

DSU প্রসিডিউর

এই বিভাগে DSU কনফিগারেশনের বিভিন্ন পদ্ধতি বর্ণনা করা হয়েছে।

নতুন কী পেয়ার তৈরি করা

openssl কমান্ড ব্যবহার করে .pem ফর্ম্যাটে (যেমন, ২০৪৮ বিট সাইজের) RSA প্রাইভেট/পাবলিক কী পেয়ার জেনারেট করুন:

$ openssl genrsa -out oem_cert_pri.pem 2048
$ openssl rsa -in oem_cert_pri.pem -pubout -out oem_cert_pub.pem

প্রাইভেট কী অ্যাক্সেস করা নাও যেতে পারে এবং এটি শুধুমাত্র হার্ডওয়্যার নিরাপত্তা মডিউলে (HSM) রাখা হয়। এই ক্ষেত্রে, key generation-এর পরে x509 পাবলিক কী সার্টিফিকেট উপলভ্য হতে পারে। x509 সার্টিফিকেট থেকে AVB পাবলিক কী তৈরি করার নির্দেশাবলীর জন্য র‍্যামডিস্কে পেয়ারিং পাবকী যোগ করা বিভাগটি দেখুন।

x509 সার্টিফিকেটকে PEM ফর্ম্যাটে কনভার্ট করতে:

$ openssl x509 -pubkey -noout -in oem_cert_pub.x509.pem > oem_cert_pub.pem

সার্টিফিকেটটি আগে থেকেই PEM ফাইল হলে এই ধাপটি এড়িয়ে যান।

রামডিস্কে পেয়ারিং pubkey যোগ করুন

স্বাক্ষরিত DSU প্যাকেজ যাচাই করতে oem_cert.avbpubkey-কে /avb/*.avbpubkey-এর অধীনে রাখতে হবে। প্রথমে, PEM ফর্ম্যাটে পাবলিক কী AVB public কী ফর্ম্যাটে কনভার্ট করুন:

$ avbtool extract_public_key --key oem_cert_pub.pem --output oem_cert.avbpubkey

তারপর, নিম্নলিখিত ধাপগুলি অনুসরণ করে প্রথম স্টেজের র‍্যামডিস্কে পাবলিক কী অন্তর্ভুক্ত করুন।

1. avbpubkey কপি করার জন্য আগে থেকে তৈরি মডিউল যোগ করুন। যেমন, এই ধরনের কন্টেন্ট সহ device/<company>/<board>/oem_cert.avbpubkey এবং device/<company>/<board>/avb/Android.mk যোগ করুন:

   include $(CLEAR_VARS)
   
   LOCAL_MODULE := oem_cert.avbpubkey
   LOCAL_MODULE_CLASS := ETC
   LOCAL_SRC_FILES := $(LOCAL_MODULE)
   ifeq ($(BOARD_USES_RECOVERY_AS_BOOT),true)
   LOCAL_MODULE_PATH := $(TARGET_RECOVERY_ROOT_OUT)/first_stage_ramdisk/avb
   else
   LOCAL_MODULE_PATH := $(TARGET_RAMDISK_OUT)/avb
   endif
   
   include $(BUILD_PREBUILT)
   

2. droidcore টার্গেটকে যোগ করা oem_cert.avbpubkey-এর উপর নির্ভর করতে দিন:

   droidcore: oem_cert.avbpubkey
   

JSON ডেসক্রিপ্টরে AVB pubkey অ্যাট্রিবিউট তৈরি করা

oem_cert.avbpubkey AVB পাবলিক কী বাইনারি ফর্ম্যাটে আছে। JSON ডেসক্রিপ্টরে যোগ করার আগে পঠনযোগ্য করতে SHA-1 ব্যবহার করুন:

$ sha1sum oem_cert.avbpubkey | cut -f1 -d ' '
3e62f2be9d9d813ef5........866ac72a51fd20

এটি JSON ডেসক্রিপ্টরের pubkey অ্যাট্রিবিউটের কন্টেন্ট হবে।

   "images":[
      {
         ...
         "pubkey":"3e62f2be9d9d813ef5........866ac72a51fd20",
         ...
      },

DSU প্যাকেজে স্বাক্ষর করা

DSU প্যাকেজে সাইন-ইন করতে এইসব পদ্ধতির মধ্যে একটি ব্যবহার করুন:

• পদ্ধতি ১: DSU প্যাকেজ তৈরি করতে আসল AVB সাইনিং প্রসেসের মাধ্যমে তৈরি করা আর্টিফ্যাক্ট আবার ব্যবহার করুন। অন্য একটি পদ্ধতি হল, রিলিজ প্যাকেজ থেকে আগে থেকে সাইন করা ছবি এক্সট্র্যাক্ট করা এবং এক্সট্র্যাক্ট করা ছবি ব্যবহার করে সরাসরি জিপ ফাইল তৈরি করা।

• পদ্ধতি ২: প্রাইভেট কী উপলভ্য থাকলে DSU পার্টিশনে সাইন করার জন্য নিম্নলিখিত কমান্ড ব্যবহার করুন। DSU প্যাকেজের (ZIP ফাইল) মধ্যে থাকা প্রতিটি img আলাদাভাবে সাইন করা থাকে:

  $ key_len=$(openssl rsa -in oem_cert_pri.pem -text | grep Private-Key | sed -e 's/.*(\(.*\) bit.*/\1/')
  $ for partition in system product; do
      avbtool add_hashtree_footer \
          --image ${OUT}/${partition}.img \
          --partition_name ${partition} \
          --algorithm SHA256_RSA${key_len} \
          --key oem_cert_pri.pem
  done
  

avbtool ব্যবহার করে add_hashtree_footer যোগ করা সম্পর্কে আরও তথ্য পেতে, avbtool ব্যবহার করা দেখুন।

লোকালভাবে DSU প্যাকেজ যাচাই করা

পেয়ার করা পাবলিক কী-এর সাথে সব লোকাল ছবি যাচাই করার জন্য এইসব কমান্ড ব্যবহার করার সাজেশন দেওয়া হয়:

for partition in system product; do
    avbtool verify_image --image ${OUT}/${partition}.img  --key oem_cert_pub.pem
done

প্রত্যাশিত আউটপুটটি দেখতে এইরকম:

Verifying image dsu/system.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/system.img
: Successfully verified sha1 hashtree of dsu/system.img for image of 898494464 bytes

Verifying image dsu/product.img using key at oem_cert_pub.pem
vbmeta: Successfully verified footer and SHA256_RSA2048 vbmeta struct in dsu/product.img
: Successfully verified sha1 hashtree of dsu/product.img for image of 905830400 bytes

DSU প্যাকেজ তৈরি করুন

নিচের উদাহরণে এমন DSU প্যাকেজ তৈরি করা হয়েছে যাতে system.img ও product.img আছে:

dsu.zip {
    - system.img
    - product.img
}

দুটি ছবিতেই স্বাক্ষর করা হয়ে গেলে, ZIP ফাইল তৈরি করতে নিম্নলিখিত কমান্ড ব্যবহার করুন:

$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -

এক-ক্লিক DSU কাস্টমাইজ করুন

ডিফল্ট হিসেবে, DSU লোডার GSI ছবির মেটাডেটা দেখায় যা হল https://...google.com/.../gsi-src.json।

OEM-রা persist.sys.fflag.override.settings_dynamic_system.list প্রপার্টিকে তাদের নিজস্ব JSON ডেসক্রিপ্টরের দিকে পয়েন্ট করে তালিকা ওভাররাইট করতে পারে। যেমন, কোনও OEM JSON মেটাডেটা প্রদান করতে পারে যাতে GSI এবং OEM-এর মালিকানাধীন ছবি অন্তর্ভুক্ত থাকে, যেমন:

{
    "include": ["https://dl.google.com/.../gsi-src.JSON"]
    "images":[
      {
         "name":"OEM image",
         "os_version":"10",
         "cpu_abi": "arm64-v8a",
         "details":"...",
         "vndk":[
            27,
            28,
            29
         ],
         "spl":"...",
         "pubkey":"",
         "uri":"https://.../....zip"
      },

}

OEM-এর পক্ষে প্রকাশিত DSU মেটাডেটা চেইন করা সম্ভব, যেমনটি ৭ নম্বর ছবিতে দেখানো হয়েছে।

ছবি ৭. প্রকাশিত DSU মেটাডেটা চেইন করা