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

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

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

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

উপরন্তু, ডিএসইউ অ্যান্ড্রয়েড সিস্টেম ইমেজ যাচাই করতে ডিভাইস-ম্যাপার-ভেরিটি (ডিএম-ভেরিটি) কার্নেল বৈশিষ্ট্যের উপর নির্ভর করে। সুতরাং আপনাকে অবশ্যই নিম্নলিখিত কার্নেল কনফিগারগুলি সক্ষম করতে হবে:

• CONFIG_DM_VERITY=y
• CONFIG_DM_VERITY_FEC=y

পার্টিশনের প্রয়োজনীয়তা

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

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

• F2FS ব্যবহার করে:
  • 109s, 8G ব্যবহারকারী, 867M সিস্টেম, ফাইল সিস্টেমের ধরন: F2FS: এনক্রিপশন=aes-256-xts:aes-256-cts
  • 104s, 8G ব্যবহারকারী, 867M সিস্টেম, ফাইল সিস্টেমের ধরন: F2FS: এনক্রিপশন = বরফ
• ext4 ব্যবহার করে:
  • 135s, 8G ব্যবহারকারী, 867M সিস্টেম, ফাইল সিস্টেমের ধরন: ext4: encryption=aes-256-xts:aes-256-cts

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

metadata পার্টিশন (16 MB বা বড়) ইনস্টল করা ছবি সম্পর্কিত ডেটা সংরক্ষণের জন্য প্রয়োজন। এটি প্রথম পর্যায়ে মাউন্ট করার সময় মাউন্ট করা আবশ্যক।

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

ডিএসইউ তৈরি করা হয়েছিল এবং কার্নেল/কমন 4.9 দিয়ে পরীক্ষা করা হয়েছিল। এই বৈশিষ্ট্যটির জন্য কার্নেল 4.9 এবং উচ্চতর ব্যবহার করার পরামর্শ দেওয়া হচ্ছে।

বিক্রেতা HAL আচরণ

ওয়েভার HAL

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

দারোয়ান HAL

গেটকিপার HAL-কে বড় USER_ID মানগুলিকে সমর্থন করতে হবে, কারণ GSI HAL-কে +1000000 দ্বারা UID অফসেট করে৷

বুট যাচাই করুন

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

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

রোলব্যাক সুরক্ষা

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

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

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

আপনি যখন একটি DSU উদাহরণ চালু করেন, তখন দুটি অস্থায়ী ফাইল বরাদ্দ করা হয়:

• GSI.img (1~1.5 G) সংরক্ষণ করার জন্য একটি যৌক্তিক পার্টিশন
• GSI চালানোর জন্য স্যান্ডবক্স হিসেবে একটি 8 GB খালি /data পার্টিশন

আমরা একটি DSU দৃষ্টান্ত চালু করার আগে কমপক্ষে 10 GB মুক্ত স্থান সংরক্ষণ করার পরামর্শ দিই৷ DSU একটি SD কার্ড থেকে বরাদ্দ সমর্থন করে। যখন একটি SD কার্ড উপস্থিত থাকে, তখন এটি বরাদ্দের জন্য সর্বোচ্চ অগ্রাধিকার পায়৷ SD কার্ড সমর্থন নিম্ন-চালিত ডিভাইসগুলির জন্য গুরুত্বপূর্ণ যেগুলিতে পর্যাপ্ত অভ্যন্তরীণ স্টোরেজ নাও থাকতে পারে। যখন একটি SD কার্ড উপস্থিত থাকে, নিশ্চিত করুন যে এটি গ্রহণ করা হয়নি৷ DSU গৃহীত SD কার্ড সমর্থন করে না।

উপলব্ধ ফ্রন্টএন্ড

আপনি 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 চালু করুন

ডিএসইউতে প্রধান এন্ট্রি পয়েন্ট হল 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...);
   
   

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

$ 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 লোডার

অ্যান্ড্রয়েড 11 এক-ক্লিক ডিএসইউ লোডার প্রবর্তন করে, যা ডেভেলপার সেটিংসে একটি ফ্রন্টএন্ড।

চিত্র 1. DSU লোডার চালু করা হচ্ছে

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

চিত্র 2. DSU ইমেজ ইনস্টলেশনের অগ্রগতি

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

বৈশিষ্ট্য পতাকা

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

চিত্র 3. বৈশিষ্ট্য পতাকা সক্রিয় করা হচ্ছে

বৈশিষ্ট্য ফ্ল্যাগ UI একটি ব্যবহারকারী বিল্ড চলমান একটি ডিভাইসে অনুপলব্ধ হতে পারে. এই ক্ষেত্রে, পরিবর্তে adb কমান্ড ব্যবহার করুন:

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

জিসিই-তে বিক্রেতা হোস্ট সিস্টেমের ছবি (ঐচ্ছিক)

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

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

চিত্র 4. GCE-তে পাবলিক অ্যাক্সেস

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

জিপ ফাইলে একাধিক পার্টিশন ডিএসইউ

Android 11 থেকে শুরু করে, DSU একাধিক পার্টিশন থাকতে পারে। উদাহরণস্বরূপ, এতে system.img ছাড়াও একটি product.img থাকতে পারে। যখন ডিভাইস বুট হয়, প্রথম পর্যায়ে init ইনস্টল করা DSU পার্টিশন সনাক্ত করে এবং ইনস্টল করা DSU সক্রিয় করা হলে অস্থায়ীভাবে ডিভাইসে পার্টিশন প্রতিস্থাপন করে। ডিএসইউ প্যাকেজে এমন একটি পার্টিশন থাকতে পারে যার ডিভাইসে সংশ্লিষ্ট পার্টিশন নেই।

চিত্র 5. একাধিক পার্টিশন সহ DSU প্রক্রিয়া

OEM স্বাক্ষরিত DSU

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

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

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

DSU JSON বর্ণনাকারী

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

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

দ্বিতীয়ত, আদিম image প্রকাশিত ডিএসইউ প্যাকেজগুলি বর্ণনা করতে ব্যবহৃত হয়। আদিম চিত্রের ভিতরে বেশ কয়েকটি বৈশিষ্ট্য রয়েছে:

• name এবং details বৈশিষ্ট্যগুলি হল স্ট্রিং যা ব্যবহারকারীর নির্বাচন করার জন্য ডায়ালগে দেখানো হয়।

• cpu_api , vndk , এবং os_version বৈশিষ্ট্যগুলি সামঞ্জস্য পরীক্ষা করার জন্য ব্যবহৃত হয়, যা পরবর্তী বিভাগে বর্ণিত হয়েছে।

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

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

  

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

রেফারেন্সের জন্য, এখানে 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 কীগুলির জন্য একটি প্রত্যাহার তালিকা৷ এই রিসোর্স স্ট্রিংটি ওভারলেড এবং কাস্টমাইজ করা যেতে পারে, যাতে OEM যারা DSU বৈশিষ্ট্য গ্রহণ করে তাদের নিজস্ব কী কালো তালিকা প্রদান এবং বজায় রাখতে পারে। এটি ডিভাইসের রামডিস্ক ইমেজ আপডেট না করেই নির্দিষ্ট পাবলিক কী ব্লক করার জন্য OEM-এর একটি উপায় প্রদান করে।

প্রত্যাহার তালিকার বিন্যাস হল:

{
   "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 পাবকি তৈরি করা বিভাগে বর্ণিত হয়েছে৷
• status কীটির প্রত্যাহার স্থিতি নির্দেশ করে। বর্তমানে, একমাত্র সমর্থিত মানটি REVOKED ।
• reason হল একটি ঐচ্ছিক স্ট্রিং যা প্রত্যাহার করার কারণ বর্ণনা করে।

ডিএসইউ পদ্ধতি

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

একটি নতুন কী জোড়া তৈরি করুন

.pem ফরম্যাটে একটি RSA প্রাইভেট/পাবলিক কী পেয়ার তৈরি করতে openssl কমান্ডটি ব্যবহার করুন (উদাহরণস্বরূপ, আকার 2048 বিট সহ):

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

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

একটি x509 শংসাপত্রকে PEM ফর্ম্যাটে রূপান্তর করতে:

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

শংসাপত্রটি ইতিমধ্যে একটি PEM ফাইল হলে এই পদক্ষেপটি এড়িয়ে যান৷

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

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

$ 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 পাবকি অ্যাট্রিবিউট তৈরি করুন

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

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

এটি JSON বর্ণনাকারীর pubkey বৈশিষ্ট্যের বিষয়বস্তু হবে।

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

একটি DSU প্যাকেজ সাইন ইন করুন

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

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

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

  $ 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গুলি তাদের নিজস্ব JSON বর্ণনাকারীর দিকে নির্দেশ করে persist.sys.fflag.override.settings_dynamic_system.list বৈশিষ্ট্য সংজ্ঞায়িত করে তালিকাটি ওভাররাইট করতে পারে৷ উদাহরণস্বরূপ, একটি 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"
      },

}

চিত্র 7-এ দেখানো একটি OEM-এর জন্য প্রকাশিত DSU মেটাডেটা চেইন করা সম্ভব।

চিত্র 7. চেইনিং প্রকাশিত DSU মেটাডেটা