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

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

Kernel से जुड़ी ज़रूरी शर्तें

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

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

• CONFIG_DM_VERITY=y
• CONFIG_DM_VERITY_FEC=y

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

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

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

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

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

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

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

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

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

Weaver HAL

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

Gatekeeper HAL

Gatekeeper HAL को बड़ी USER_ID वैल्यू के साथ काम करना चाहिए, क्योंकि GSI, HAL में UID को +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'.

जिन डिवाइसों में एवीबी का इस्तेमाल नहीं किया जा रहा है उनके लिए, मौजूदा सिस्टम इमेज के सुरक्षा पैच लेवल को कर्नेल cmdline या bootconfig में डालें. इसके लिए, बूटलोडर का इस्तेमाल करें: androidboot.system.security_patch=2019-04-05.

हार्डवेयर की आवश्यकताएं

DSU इंस्टेंस लॉन्च करने पर, दो अस्थायी फ़ाइलें असाइन की जाती हैं:

• GSI.img को स्टोर करने के लिए लॉजिकल पार्टीशन (1~1.5 G)
• GSI को चलाने के लिए, सैंडबॉक्स के तौर पर 8 जीबी का खाली /data पार्टीशन

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

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

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

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

किसी ऐप्लिकेशन का इस्तेमाल करके डीएसयू लॉन्च करना

डीएसयू का मुख्य एंट्री पॉइंट 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 पर पब्लिश नहीं किया जा सकता. इस ऐप्लिकेशन का मकसद है:

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

3. 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 लोडर लॉन्च करना

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

दूसरी इमेज. DSU की इमेज इंस्टॉल होने की स्थिति

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

फ़ीचर फ़्लैग

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

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

हो सकता है कि उपयोगकर्ता के बनाए गए बिल्ड वाले डिवाइस पर, फ़ीचर फ़्लैग का यूज़र इंटरफ़ेस (यूआई) उपलब्ध न हो. इस मामले में, इसके बजाय 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 पैकेज में ऐसा पार्टिशन हो सकता है जिसका डिवाइस पर उसके लिए कोई पार्टिशन नहीं है.

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

OEM के हस्ताक्षर वाला DSU

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

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

system.img और product.img, दोनों को ZIP फ़ाइल में डालने से पहले OEM पासकोड से हस्ताक्षर करना ज़रूरी है. आम तौर पर, एसिमेट्रिक एल्गोरिदम का इस्तेमाल किया जाता है, जैसे कि आरएसए. इसमें पैकेज पर हस्ताक्षर करने के लिए सीक्रेट पासकोड का इस्तेमाल किया जाता है. वहीं, उसकी पुष्टि करने के लिए सार्वजनिक पासकोड का इस्तेमाल किया जाता है. पहले स्टेज के रैमडिस्क में, पैरिंग सार्वजनिक कुंजी शामिल होनी चाहिए. उदाहरण के लिए, /avb/*.avbpubkey. अगर डिवाइस में पहले से ही AVB की सुविधा उपलब्ध है, तो हस्ताक्षर करने की मौजूदा प्रोसेस ही काफ़ी होगी. नीचे दिए गए सेक्शन में, हस्ताक्षर करने की प्रोसेस के बारे में बताया गया है. साथ ही, DSU पैकेज में मौजूद इमेज की पुष्टि करने के लिए इस्तेमाल किए जाने वाले AVB पब्लिक पासकोड की जगह को हाइलाइट किया गया है.

DSU JSON डिस्क्रिप्टर

DSU JSON डिस्क्रिप्टर, DSU पैकेज के बारे में बताता है. यह दो प्राइमिटिव के साथ काम करता है. सबसे पहले, include प्रिमिटिव में ज़्यादा JSON डिस्क्रिप्टर शामिल होते हैं या वे डीएसयू लोडर को किसी नई जगह पर रीडायरेक्ट करते हैं. उदाहरण के लिए:

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

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

• name और details एट्रिब्यूट ऐसी स्ट्रिंग होती हैं जो डायलॉग पर लोगों के चुनने के लिए दिखाई जाती हैं.

• cpu_api, vndk, और os_version एट्रिब्यूट का इस्तेमाल, डिवाइस के साथ काम करने की जांच करने के लिए किया जाता है. इस बारे में अगले सेक्शन में बताया गया है.

• pubkey एट्रिब्यूट, सार्वजनिक कुंजी के बारे में बताता है. यह कुंजी, उस गुप्त कुंजी के साथ जोड़ी जाती है जिसका इस्तेमाल डीएसयू पैकेज पर हस्ताक्षर करने के लिए किया जाता है. हालांकि, इस एट्रिब्यूट का इस्तेमाल करना ज़रूरी नहीं है. यह जानकारी देने पर, डीएसयू सेवा यह जांच कर सकती है कि डिवाइस में डीएसयू पैकेज की पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी है या नहीं. इससे ऐसा DSU पैकेज इंस्टॉल करने से बचा जा सकता है जिसकी पहचान नहीं की जा सकी. उदाहरण के लिए, OEM-B के बनाए डिवाइस पर OEM-A से हस्ताक्षर किया गया DSU इंस्टॉल करना.

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

  

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

रेफ़रंस के लिए, यहां जीएसआई के लिए डीएसयू का 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"
      }
   ]
}

कंपैटिबिलिटी मैनेजमेंट

डीएसयू पैकेज और स्थानीय डिवाइस के बीच काम करने की जानकारी देने के लिए, कई एट्रिब्यूट का इस्तेमाल किया जाता है:

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

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

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

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

डीएसयू से जुड़ी प्रोसेस

इस सेक्शन में, डीएसयू कॉन्फ़िगरेशन के कई तरीकों के बारे में बताया गया है.

नया कुंजी जोड़ा जनरेट करना

.pem फ़ॉर्मैट (उदाहरण के लिए, साइज़ 2048 बिट वाला) में आरएसए निजी/सार्वजनिक कुंजी का जोड़ा जनरेट करने के लिए, openssl निर्देश का इस्तेमाल करें:

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

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

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

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

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

ramdisk में, पेयरिंग पब्लिक पासकोड जोड़ना

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

स्थानीय तौर पर डीएसयू पैकेज की पुष्टि करना

हमारा सुझाव है कि आप इन निर्देशों का इस्तेमाल करके, सभी लोकल इमेज की पुष्टि, जोड़ी गई सार्वजनिक कुंजी के हिसाब से करें:

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 -

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

डिफ़ॉल्ट रूप से, डीएसयू लोडर, 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"
      },

}

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

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