हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

डाइनैमिक सिस्टम अपडेट

डाइनैमिक सिस्टम अपडेट (डीएसयू) की मदद से, Android सिस्टम इमेज बनाई जा सकती है. इसे लोग इंटरनेट से डाउनलोड करके आज़मा सकते हैं. इससे मौजूदा सिस्टम इमेज के खराब होने का खतरा नहीं होता. इस दस्तावेज़ में, डीएसयू को सपोर्ट करने का तरीका बताया गया है.

कर्नेल से जुड़ी ज़रूरी शर्तें

कर्नेल की ज़रूरी शर्तों के लिए, डाइनैमिक पार्टीशन लागू करना देखें.

इसके अलावा, DSU, Android सिस्टम इमेज की पुष्टि करने के लिए, डिवाइस-मैपर-वेरिटी (डीएम-वेरिटी) कर्नल सुविधा पर निर्भर करता है. इसलिए, आपको यहां दिए गए कर्नल कॉन्फ़िगरेशन चालू करने होंगे:

CONFIG_DM_VERITY=y
CONFIG_DM_VERITY_FEC=y

पार्टिशन से जुड़ी ज़रूरी शर्तें

Android 11 से, DSU को /data पार्टिशन के लिए, F2FS या ext4 फ़ाइल सिस्टम का इस्तेमाल करना होगा. F2FS से बेहतर परफ़ॉर्मेंस मिलती है और इसका इस्तेमाल करने का सुझाव दिया जाता है. हालांकि, दोनों के बीच का अंतर काफ़ी कम होना चाहिए.

यहां कुछ उदाहरण दिए गए हैं, जिनसे पता चलता है कि Pixel डिवाइस पर डाइनैमिक सिस्टम अपडेट होने में कितना समय लगता है:

F2FS का इस्तेमाल करके:
- 109s, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम का टाइप: F2FS: encryption=aes-256-xts:aes-256-cts
- 104s, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम का टाइप: F2FS: encryption=ice
ext4 का इस्तेमाल करना:
- 135 सेकंड, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम टाइप: ext4: encryption=aes-256-xts:aes-256-cts

अगर आपके प्लैटफ़ॉर्म पर इसमें ज़्यादा समय लगता है, तो हो सकता है कि माउंट फ़्लैग में कोई ऐसा फ़्लैग शामिल हो जिसकी वजह से “सिंक” राइट हो रहा हो. इसके अलावा, बेहतर परफ़ॉर्मेंस पाने के लिए, “एसिंक” फ़्लैग को साफ़ तौर पर सेट किया जा सकता है.

इंस्टॉल की गई इमेज से जुड़ा डेटा सेव करने के लिए, metadata पार्टीशन (16 एमबी या इससे ज़्यादा) ज़रूरी है. इसे पहले चरण के माउंटिंग के दौरान माउंट किया जाना चाहिए.

userdata पार्टिशन के लिए, F2FS या ext4 फ़ाइल सिस्टम का इस्तेमाल करना ज़रूरी है. F2FS का इस्तेमाल करते समय, Android के कॉमन कर्नल में उपलब्ध F2FS से जुड़े सभी पैच शामिल करें.

DSU को कर्नल/कॉमन 4.9 के साथ डेवलप और टेस्ट किया गया था. हमारा सुझाव है कि इस सुविधा के लिए, कर्नल 4.9 और उसके बाद के वर्शन का इस्तेमाल करें.

वेंडर एचएएल का व्यवहार

Weaver एचएएल

वीवर एचएएल, उपयोगकर्ता की कुंजियों को सेव करने के लिए तय संख्या में स्लॉट उपलब्ध कराता है. DSU, दो अतिरिक्त कुंजी स्लॉट का इस्तेमाल करता है. अगर किसी ओईएम के पास वीवर एचएएल है, तो उसके पास सामान्य सिस्टम इमेज (जीएसआई) और होस्ट इमेज के लिए, ज़रूरत के मुताबिक स्लॉट होने चाहिए.

Gatekeeper HAL

Gatekeeper HAL को बड़ी USER_ID वैल्यू के साथ काम करना होगा, क्योंकि GSI, HAL को यूआईडी ऑफ़सेट +1000000 से भेजता है.

वेरीफ़ाइड बूट

अगर आपको पुष्टि किए गए बूट को बंद किए बिना, लॉक किए गए मोड में डेवलपर जीएसआई इमेज को बूट करने की सुविधा देनी है, तो डेवलपर जीएसआई कुंजियां शामिल करें. इसके लिए, फ़ाइल device/<device_name>/device.mk में यह लाइन जोड़ें:

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

रोलबैक सुरक्षा

DSU का इस्तेमाल करते समय, डाउनलोड की गई Android सिस्टम इमेज, डिवाइस पर मौजूद मौजूदा सिस्टम इमेज से नई होनी चाहिए. इसके लिए, दोनों सिस्टम इमेज के Android Verified Boot (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 को सेव करने के लिए लॉजिकल पार्टिशन (1 से 1.5 GB)
GSI चलाने के लिए, 8 जीबी का खाली /data पार्टीशन, सैंडबॉक्स के तौर पर

हमारा सुझाव है कि डीएसयू इंस्टेंस लॉन्च करने से पहले, कम से कम 10 जीबी खाली जगह रिज़र्व करें. DSU, एसडी कार्ड से भी जगह असाइन करने की सुविधा देता है. एसडी कार्ड मौजूद होने पर, उसे सबसे ज़्यादा प्राथमिकता दी जाती है. कम पावर वाले डिवाइसों के लिए एसडी कार्ड का इस्तेमाल करना ज़रूरी है. ऐसा इसलिए, क्योंकि इन डिवाइसों में स्टोरेज की जगह कम होती है. अगर एसडी कार्ड मौजूद है, तो पक्का करें कि उसे अडॉप्ट न किया गया हो. DSU, एडॉप्ट किए गए एसडी कार्ड के साथ काम नहीं करता.

उपलब्ध फ़्रंटएंड

adb, OEM ऐप्लिकेशन या एक क्लिक वाले डीएसयू लोडर का इस्तेमाल करके डीएसयू लॉन्च किया जा सकता है. यह सुविधा Android 11 या इसके बाद के वर्शन में उपलब्ध है.

adb का इस्तेमाल करके डीएसयू लॉन्च करना

adb का इस्तेमाल करके डीएसयू लॉन्च करने के लिए, ये कमांड डालें:

$ 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एपीआई है:

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 एक सिस्टम एपीआई है. इसलिए, ऐप्लिकेशन को सामान्य एसडीके एपीआई के साथ नहीं बनाया जा सकता. साथ ही, इसे Google Play पर पब्लिश नहीं किया जा सकता. इस ऐप्लिकेशन का मकसद यह है:

वेंडर की तय की गई स्कीम के हिसाब से, इमेज की सूची और उससे जुड़ा यूआरएल फ़ेच करता है.
सूची में मौजूद इमेज को डिवाइस से मैच करें और उपयोगकर्ता को चुनने के लिए, काम करने वाली इमेज दिखाएं.

DynamicSystemClient.start को इस तरह से शुरू करें:

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

यूआरएल, 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

एक क्लिक में डीएसयू लोडर

Android 11 में, एक क्लिक में डीएसयू लोडर लॉन्च करने की सुविधा दी गई है. यह डेवलपर सेटिंग में फ़्रंटएंड है.

पहली इमेज. DSU लोडर लॉन्च किया जा रहा है

जब डेवलपर DSU Loader बटन पर क्लिक करता है, तो यह वेब से पहले से कॉन्फ़िगर किया गया DSU JSON डिस्क्रिप्टर फ़ेच करता है. साथ ही, फ़्लोटिंग मेन्यू में लागू होने वाली सभी इमेज दिखाता है. DSU इंस्टॉल करने के लिए कोई इमेज चुनें. इसके बाद, सूचना बार पर इसकी प्रोग्रेस दिखेगी.

DSU इमेज इंस्टॉल करने की प्रोसेस

दूसरी इमेज. DSU इमेज इंस्टॉल करने की प्रोसेस

DSU लोडर, डिफ़ॉल्ट रूप से एक JSON डिस्क्रिप्टर लोड करता है. इसमें जीएसआई इमेज होती हैं. नीचे दिए गए सेक्शन में, ओईएम के हस्ताक्षर वाले डीएसयू पैकेज बनाने और उन्हें डीएसयू लोडर से लोड करने का तरीका बताया गया है.

फ़ीचर फ़्लैग

DSU सुविधा, settings_dynamic_android फ़ीचर फ़्लैग के तहत आती है. DSU का इस्तेमाल करने से पहले, पक्का करें कि इससे जुड़ा फ़ीचर फ़्लैग चालू हो.

फ़ीचर फ़्लैग चालू करना.

तीसरी इमेज. फ़ीचर फ़्लैग चालू करना

ऐसा हो सकता है कि उपयोगकर्ता के बिल्ड पर चल रहे डिवाइस पर, फ़ीचर फ़्लैग यूज़र इंटरफ़ेस (यूआई) उपलब्ध न हो. इस मामले में, adb कमांड का इस्तेमाल करें:

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

GCE पर वेंडर की होस्ट सिस्टम इमेज (ज़रूरी नहीं)

सिस्टम इमेज को सेव करने के लिए, Google Compute Engine (GCE) बकेट का इस्तेमाल किया जा सकता है. रिलीज़ एडमिन, रिलीज़ की गई सिस्टम इमेज को जोड़ने/मिटाने/बदलने के लिए, GCP स्टोरेज कंसोल का इस्तेमाल करता है.

इमेज को सार्वजनिक तौर पर ऐक्सेस किया जा सकता हो. जैसा कि यहां दिखाया गया है:

GCE में सार्वजनिक ऐक्सेस

चौथी इमेज. GCE में सार्वजनिक ऐक्सेस

किसी आइटम को सार्वजनिक करने की प्रोसेस, Google Cloud के दस्तावेज़ में दी गई है.

ZIP फ़ाइल में मौजूद एक से ज़्यादा पार्टीशन वाला डीएसयू

Android 11 से, DSU में एक से ज़्यादा पार्टीशन हो सकते हैं. उदाहरण के लिए, इसमें system.img के अलावा product.img भी शामिल हो सकता है. डिवाइस बूट होने पर, पहले चरण का बूटलोडर init इंस्टॉल किए गए डीएसयू पार्टिशन का पता लगाता है. साथ ही, इंस्टॉल किए गए डीएसयू के चालू होने पर, डिवाइस पर मौजूद पार्टिशन को कुछ समय के लिए बदल देता है. DSU पैकेज में ऐसा पार्टिशन हो सकता है जिसका डिवाइस पर कोई मेल खाने वाला पार्टिशन मौजूद न हो.

एक से ज़्यादा पार्टीशन के साथ डीएसयू प्रोसेस

पांचवीं इमेज. एक से ज़्यादा पार्टीशन के साथ डीएसयू प्रोसेस

OEM के हस्ताक्षर वाला डीएसयू

यह पक्का करने के लिए कि डिवाइस पर चल रही सभी इमेज को डिवाइस बनाने वाली कंपनी ने अनुमति दी है, DSU पैकेज में मौजूद सभी इमेज पर हस्ताक्षर होना चाहिए. उदाहरण के लिए, मान लें कि एक डीएसयू पैकेज है, जिसमें नीचे दी गई दो पार्टीशन इमेज शामिल हैं:

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

system.img और product.img, दोनों पर OEM के हस्ताक्षर होने चाहिए. इसके बाद ही, इन्हें ZIP फ़ाइल में रखा जा सकता है. आम तौर पर, असिमेट्रिक एल्गोरिदम का इस्तेमाल किया जाता है. उदाहरण के लिए, आरएसए. इसमें सीक्रेट कुंजी का इस्तेमाल पैकेज पर हस्ताक्षर करने के लिए किया जाता है और सार्वजनिक कुंजी का इस्तेमाल इसकी पुष्टि करने के लिए किया जाता है. पहले चरण के रैमडिस्क में पेयरिंग की सार्वजनिक कुंजी शामिल होनी चाहिए. उदाहरण के लिए, /avb/*.avbpubkey. अगर डिवाइस पहले से ही AVB का इस्तेमाल कर रहा है, तो मौजूदा हस्ताक्षर करने की प्रक्रिया काफ़ी होगी. यहां दिए गए सेक्शन में, हस्ताक्षर करने की प्रोसेस के बारे में बताया गया है. साथ ही, AVB pubkey को कहां रखा जाता है, इस बारे में हाइलाइट किया गया है. इस pubkey का इस्तेमाल, 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 पैकेज पर हस्ताक्षर करने के लिए इस्तेमाल की गई सीक्रेट कुंजी के साथ जोड़ी जाती है. इस विकल्प को चुनने पर, डीएसयू सेवा यह जांच कर सकती है कि डिवाइस में डीएसयू पैकेज की पुष्टि करने के लिए इस्तेमाल की गई कुंजी मौजूद है या नहीं. इससे, किसी ऐसे डीएसयू पैकेज को इंस्टॉल करने से बचा जा सकता है जिसकी पुष्टि नहीं हुई है. उदाहरण के लिए, OEM-A के बनाए गए डीएसयू को OEM-B के बनाए गए डिवाइस पर इंस्टॉल करना.
tos एट्रिब्यूट (ज़रूरी नहीं) एक टेक्स्ट फ़ाइल की ओर ले जाता है. इस फ़ाइल में, DSU पैकेज के लिए सेवा की शर्तों के बारे में बताया गया होता है. जब कोई डेवलपर, सेवा की शर्तों के एट्रिब्यूट के साथ कोई डीएसयू पैकेज चुनता है, तो इमेज 6 में दिखाया गया डायलॉग बॉक्स खुलता है. इसमें डेवलपर से डीएसयू पैकेज इंस्टॉल करने से पहले, सेवा की शर्तों को स्वीकार करने के लिए कहा जाता है.

छठी इमेज. सेवा की शर्तों वाला डायलॉग बॉक्स

रेफ़रंस के लिए, यहां GSI के लिए डीएसयू 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 की जीएसआई इमेज बूट की जा सकती है.
vndk एक वैकल्पिक कैटगरी है. इसमें वे सभी वीएनडीके शामिल होते हैं जो डीएसयू पैकेज में शामिल हैं. इसकी वैल्यू तय करने पर, डीएसयू लोडर यह देखता है कि ro.vndk.version सिस्टम प्रॉपर्टी से निकाला गया नंबर शामिल है या नहीं.

सुरक्षा के लिए डीएसयू कुंजियां रद्द करना

अगर DSU इमेज पर हस्ताक्षर करने के लिए इस्तेमाल किए गए RSA कुंजी जोड़े से जुड़ी सुरक्षा में कोई समस्या आती है, तो ramdisk को जल्द से जल्द अपडेट किया जाना चाहिए, ताकि सुरक्षा में समस्या पैदा करने वाली कुंजी को हटाया जा सके. हालांकि, ऐसा बहुत कम होता है. बूट पार्टीशन को अपडेट करने के अलावा, एचटीटीपीएस यूआरएल से डीएसयू की कुंजी रद्द करने की सूची (कुंजी की ब्लैकलिस्ट) का इस्तेमाल करके, हैक की गई कुंजियों को ब्लॉक किया जा सकता है.

DSU की कुंजी रद्द करने की सूची में, रद्द की गई AVB की सार्वजनिक कुंजियों की सूची होती है. DSU इंस्टॉल करने के दौरान, DSU इमेज में मौजूद सार्वजनिक कुंजियों की पुष्टि, रद्द किए गए प्रमाणपत्रों की सूची से की जाती है. अगर इमेज में रद्द की गई सार्वजनिक कुंजी मिलती है, तो DSU इंस्टॉल करने की प्रोसेस रुक जाती है.

सुरक्षा को बेहतर बनाने के लिए, कुंजी रद्द करने की सूची का यूआरएल, एचटीटीपीएस यूआरएल होना चाहिए. इसे संसाधन स्ट्रिंग में बताया गया है:

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

स्ट्रिंग की वैल्यू https://dl.google.com/developers/android/gsi/gsi-keyblacklist.json है. यह Google की ओर से रिलीज़ की गई जीएसआई कुंजियों के लिए, रद्द करने की सूची है. इस रिसॉर्स स्ट्रिंग को ओवरले और पसंद के मुताबिक बनाया जा सकता है, ताकि डीएसयू सुविधा का इस्तेमाल करने वाले ओईएम, अपनी कुंजी की ब्लैकलिस्ट बना सकें और उसे मैनेज कर सकें. इससे ओईएम को, डिवाइस की रैमडिस्क इमेज को अपडेट किए बिना कुछ सार्वजनिक पासकोड ब्लॉक करने का तरीका मिलता है.

निलंबन की सूची का फ़ॉर्मैट यह है:

{
   "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 कमांड का इस्तेमाल करें. उदाहरण के लिए, 2048 बिट के साइज़ के साथ:

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

निजी कोड को ऐक्सेस नहीं किया जा सकता. इसे सिर्फ़ हार्डवेयर सुरक्षा मॉड्यूल (एचएसएम) में रखा जाता है. इस मामले में, कुंजी जनरेट होने के बाद x509 सार्वजनिक पासकोड सर्टिफ़िकेट उपलब्ध हो सकता है. x509 सर्टिफ़िकेट से AVB की सार्वजनिक कुंजी जनरेट करने के निर्देशों के लिए, रामडिस्क में पेयरिंग की सार्वजनिक कुंजी जोड़ना सेक्शन देखें.

x509 सर्टिफ़िकेट को PEM फ़ॉर्मैट में बदलने के लिए:

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

अगर सर्टिफ़िकेट पहले से ही पीईएम फ़ाइल है, तो इस चरण को छोड़ दें.

पेयरिंग की सार्वजनिक कुंजी को रैमडिस्क में जोड़ें

हस्ताक्षर किए गए डीएसयू पैकेज की पुष्टि करने के लिए, oem_cert.avbpubkey को /avb/*.avbpubkey में रखना होगा. सबसे पहले, पीईएम फ़ॉर्मैट में मौजूद सार्वजनिक पासकोड को AVB सार्वजनिक पासकोड फ़ॉर्मैट में बदलें:

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

इसके बाद, सार्वजनिक कुंजी को पहले चरण के रैमडिस्क में शामिल करें. इसके लिए, यह तरीका अपनाएं.

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)
```
जोड़े गए oem_cert.avbpubkey के आधार पर, droidcore टारगेट को निर्भर बनाएं:
```
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 पैकेज पर हस्ताक्षर करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करें:

पहला तरीका: डीएसयू पैकेज बनाने के लिए, एवीबी पर साइन करने की मूल प्रोसेस से बनाए गए आर्टफ़ैक्ट का फिर से इस्तेमाल करें. इसके अलावा, रिलीज़ पैकेज से पहले से साइन की गई इमेज निकालकर, सीधे तौर पर ZIP फ़ाइल बनाने के लिए उनका इस्तेमाल किया जा सकता है.
दूसरा तरीका: अगर निजी कुंजी उपलब्ध है, तो 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 पैकेज बनाना

यहां दिए गए उदाहरण में, एक ऐसा डीएसयू पैकेज बनाया गया है जिसमें 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 -

एक क्लिक में डीएसयू की सुविधा को पसंद के मुताबिक बनाना

डिफ़ॉल्ट रूप से, डीएसयू लोडर, जीएसआई इमेज के मेटाडेटा की ओर इशारा करता है. यह मेटाडेटा https://...google.com/.../gsi-src.json है.

ओईएम, सूची में बदलाव कर सकते हैं. इसके लिए, उन्हें persist.sys.fflag.override.settings_dynamic_system.list प्रॉपर्टी तय करनी होगी, जो उनके खुद के JSON डिस्क्रिप्टर की ओर ले जाती हो. उदाहरण के लिए, कोई ओईएम इस तरह का JSON मेटाडेटा दे सकता है, जिसमें जीएसआई के साथ-साथ ओईएम की मालिकाना हक वाली इमेज भी शामिल हों:

{
    "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"
      },

}

ओईएम के पास, पब्लिश किए गए डीएसयू मेटाडेटा को चेन करने का विकल्प होता है. जैसा कि सातवीं इमेज में दिखाया गया है.

DSU के पब्लिश किए गए मेटाडेटा को चेन करना

सातवीं इमेज. DSU के पब्लिश किए गए मेटाडेटा को चेन करना