डायनामिक सिस्टम अपडेट (डीएसयू) आपको एक एंड्रॉइड सिस्टम छवि बनाने की अनुमति देता है जिसे उपयोगकर्ता इंटरनेट से डाउनलोड कर सकते हैं और वर्तमान सिस्टम छवि को दूषित करने के जोखिम के बिना आज़मा सकते हैं। यह दस्तावेज़ बताता है कि डीएसयू का समर्थन कैसे करें।
कर्नेल आवश्यकताएँ
कर्नेल आवश्यकताओं के लिए गतिशील विभाजन लागू करना देखें।
इसके अलावा, डीएसयू एंड्रॉइड सिस्टम छवि को सत्यापित करने के लिए डिवाइस-मैपर-वेरिटी (डीएम-वेरिटी) कर्नेल सुविधा पर निर्भर करता है। इसलिए आपको निम्नलिखित कर्नेल कॉन्फ़िगरेशन को सक्षम करना होगा:
-
CONFIG_DM_VERITY=y
-
CONFIG_DM_VERITY_FEC=y
विभाजन की आवश्यकताएँ
एंड्रॉइड 11 से शुरू होकर, DSU को F2FS या ext4 फ़ाइल सिस्टम का उपयोग करने के लिए /data
विभाजन की आवश्यकता होती है। F2FS बेहतर प्रदर्शन देता है और अनुशंसित है, लेकिन अंतर नगण्य होना चाहिए।
यहां कुछ उदाहरण दिए गए हैं कि किसी पिक्सेल डिवाइस के साथ डायनामिक सिस्टम अपडेट में कितना समय लगता है:
- F2FS का उपयोग करना:
- 109s, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम प्रकार: F2FS: एन्क्रिप्शन=aes-256-xts:aes-256-cts
- 104s, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम प्रकार: F2FS: एन्क्रिप्शन=आइस
- Ext4 का उपयोग करना:
- 135s, 8G उपयोगकर्ता, 867M सिस्टम, फ़ाइल सिस्टम प्रकार: ext4: एन्क्रिप्शन=aes-256-xts:aes-256-cts
यदि आपके प्लेटफ़ॉर्म पर अधिक समय लगता है, तो आप यह जांचना चाहेंगे कि क्या माउंट फ़्लैग में कोई फ़्लैग है जो "सिंक" लिखता है, या आप बेहतर प्रदर्शन प्राप्त करने के लिए स्पष्ट रूप से "एसिंक" फ़्लैग निर्दिष्ट कर सकते हैं।
स्थापित छवियों से संबंधित डेटा संग्रहीत करने के लिए metadata
विभाजन (16 एमबी या बड़ा) आवश्यक है। इसे पहले चरण के माउंट के दौरान माउंट किया जाना चाहिए।
userdata
विभाजन को F2FS या ext4 फ़ाइल सिस्टम का उपयोग करना चाहिए। F2FS का उपयोग करते समय, Android सामान्य कर्नेल में उपलब्ध सभी F2FS संबंधित पैच शामिल करें।
डीएसयू को कर्नेल/कॉमन 4.9 के साथ विकसित और परीक्षण किया गया था। इस सुविधा के लिए कर्नेल 4.9 और उच्चतर का उपयोग करने की अनुशंसा की जाती है।
विक्रेता एचएएल व्यवहार
बुनकर एचएएल
बुनकर एचएएल उपयोगकर्ता कुंजियों को संग्रहीत करने के लिए निश्चित संख्या में स्लॉट प्रदान करता है। DSU दो अतिरिक्त कुंजी स्लॉट का उपभोग करता है। यदि किसी ओईएम के पास बुनकर एचएएल है, तो उसके पास जेनेरिक सिस्टम इमेज (जीएसआई) और होस्ट इमेज के लिए पर्याप्त स्लॉट होने चाहिए।
द्वारपाल एचएएल
गेटकीपर एचएएल को बड़े USER_ID
मानों का समर्थन करने की आवश्यकता है, क्योंकि जीएसआई यूआईडी को एचएएल से +1000000 तक ऑफसेट करता है।
बूट सत्यापित करें
यदि आप सत्यापित बूट को अक्षम किए बिना LOCKED स्थिति में डेवलपर GSI छवियों को बूट करने का समर्थन करना चाहते हैं, तो device/<device_name>/device.mk
फ़ाइल में निम्न पंक्ति जोड़कर डेवलपर GSI कुंजियाँ शामिल करें:
$(call inherit-product, $(SRC_TARGET_DIR)/product/developer_gsi_keys.mk)
रोलबैक सुरक्षा
डीएसयू का उपयोग करते समय, डाउनलोड की गई एंड्रॉइड सिस्टम छवि डिवाइस पर वर्तमान सिस्टम छवि से नई होनी चाहिए। यह दोनों सिस्टम छवियों के एंड्रॉइड सत्यापित बूट (एवीबी) एवीबी प्रॉपर्टी डिस्क्रिप्टर में सुरक्षा पैच स्तरों की तुलना करके किया जाता है: Prop: com.android.build.system.security_patch -> '2019-04-05'
।
एवीबी का उपयोग नहीं करने वाले उपकरणों के लिए, वर्तमान सिस्टम छवि के सुरक्षा पैच स्तर को बूटलोडर के साथ कर्नेल सीएमडीलाइन या बूटकॉन्फिग में डालें: androidboot.system.security_patch=2019-04-05
।
हार्डवेयर आवश्यकताएँ
जब आप DSU इंस्टेंस लॉन्च करते हैं, तो दो अस्थायी फ़ाइलें आवंटित की जाती हैं:
-
GSI.img
संग्रहीत करने के लिए एक तार्किक विभाजन (1~1.5 G) - जीएसआई चलाने के लिए सैंडबॉक्स के रूप में 8 जीबी खाली
/data
विभाजन
हम DSU इंस्टेंस लॉन्च करने से पहले कम से कम 10 जीबी खाली स्थान आरक्षित करने की सलाह देते हैं। डीएसयू एसडी कार्ड से आवंटन का भी समर्थन करता है। जब एक एसडी कार्ड मौजूद होता है, तो आवंटन के लिए इसकी सर्वोच्च प्राथमिकता होती है। एसडी कार्ड समर्थन कम शक्ति वाले उपकरणों के लिए महत्वपूर्ण है जिनमें पर्याप्त आंतरिक भंडारण नहीं हो सकता है। जब कोई एसडी कार्ड मौजूद हो, तो सुनिश्चित करें कि इसे अपनाया नहीं गया है। DSU अपनाए गए SD कार्ड का समर्थन नहीं करता.
उपलब्ध अग्रभाग
आप adb
, एक ओईएम ऐप, या एक-क्लिक डीएसयू लोडर (एंड्रॉइड 11 या उच्चतर में) का उपयोग करके डीएसयू लॉन्च कर सकते हैं।
एडीबी का उपयोग करके डीएसयू लॉन्च करें
एडीबी का उपयोग करके डीएसयू लॉन्च करने के लिए, ये आदेश दर्ज करें:
$ 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 पर प्रकाशित नहीं कर सकते हैं। इस ऐप का उद्देश्य है:
- विक्रेता-परिभाषित योजना के साथ एक छवि सूची और संबंधित यूआरएल प्राप्त करें।
- डिवाइस के विरुद्ध सूची में छवियों का मिलान करें और उपयोगकर्ता के चयन के लिए संगत छवियां दिखाएं।
DynamicSystemClient.start
इस प्रकार आमंत्रित करें:DynamicSystemClient aot = new DynamicSystemClient(...) aot.start( ...URL of the selected image..., ...uncompressed size of the selected image...);
URL एक gzipped, गैर-विरल, सिस्टम छवि फ़ाइल की ओर इंगित करता है, जिसे आप निम्नलिखित कमांड से बना सकते हैं:
$ 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
एक-क्लिक डीएसयू लोडर
एंड्रॉइड 11 वन-क्लिक डीएसयू लोडर पेश करता है, जो डेवलपर सेटिंग्स में फ्रंटएंड है।
चित्र 1. डीएसयू लोडर लॉन्च करना
जब डेवलपर DSU लोडर बटन पर क्लिक करता है, तो यह वेब से एक पूर्व-कॉन्फ़िगर DSU JSON डिस्क्रिप्टर लाता है और फ़्लोटिंग मेनू में सभी लागू छवियों को प्रदर्शित करता है। डीएसयू इंस्टॉलेशन शुरू करने के लिए एक छवि का चयन करें, और प्रगति अधिसूचना बार पर दिखाई देगी।
चित्र 2. डीएसयू छवि स्थापना प्रगति
डिफ़ॉल्ट रूप से, DSU लोडर एक JSON डिस्क्रिप्टर लोड करता है जिसमें GSI छवियां होती हैं। निम्नलिखित अनुभाग दर्शाते हैं कि OEM-हस्ताक्षरित DSU पैकेज कैसे बनाएं और उन्हें DSU लोडर से कैसे लोड करें।
फ़ीचर ध्वज
DSU सुविधा settings_dynamic_android
सुविधा ध्वज के अंतर्गत है। डीएसयू का उपयोग करने से पहले, सुनिश्चित करें कि संबंधित सुविधा ध्वज सक्षम है।
चित्र 3. फ़ीचर फ़्लैग को सक्षम करना
उपयोगकर्ता बिल्ड चलाने वाले डिवाइस पर फ़ीचर फ़्लैग यूआई अनुपलब्ध हो सकता है। इस स्थिति में, इसके बजाय adb
कमांड का उपयोग करें:
$ adb shell setprop persist.sys.fflag.override.settings_dynamic_system 1
जीसीई पर विक्रेता होस्ट सिस्टम छवियां (वैकल्पिक)
सिस्टम छवियों के लिए संभावित भंडारण स्थानों में से एक Google कंप्यूट इंजन (GCE) बकेट है। रिलीज़ व्यवस्थापक रिलीज़ सिस्टम छवि को जोड़ने/हटाने/बदलने के लिए GCP स्टोरेज कंसोल का उपयोग करता है।
छवियों की सार्वजनिक पहुंच होनी चाहिए, जैसा कि यहां दिखाया गया है:
चित्र 4. जीसीई में सार्वजनिक पहुंच
किसी आइटम को सार्वजनिक करने की प्रक्रिया Google क्लाउड दस्तावेज़ में उपलब्ध है।
ज़िप फ़ाइल में बहु-विभाजन DSU
Android 11 से प्रारंभ होकर, DSU में एक से अधिक विभाजन हो सकते हैं। उदाहरण के लिए, इसमें system.img
के अलावा product.img
भी हो सकता है। जब डिवाइस बूट होता है, तो पहला चरण init
स्थापित DSU विभाजन का पता लगाता है और स्थापित DSU सक्षम होने पर, ऑन-डिवाइस विभाजन को अस्थायी रूप से बदल देता है। DSU पैकेज में एक ऐसा विभाजन हो सकता है जिसका डिवाइस पर कोई संगत विभाजन नहीं है।
चित्र 5. अनेक विभाजनों के साथ डीएसयू प्रक्रिया
ओईएम-हस्ताक्षरित डीएसयू
यह सुनिश्चित करने के लिए कि डिवाइस पर चल रही सभी छवियां डिवाइस निर्माता द्वारा अधिकृत हैं, डीएसयू पैकेज के भीतर सभी छवियों पर हस्ताक्षर होना चाहिए। उदाहरण के लिए, मान लें कि एक DSU पैकेज है जिसमें नीचे दी गई दो विभाजन छवियां हैं:
dsu.zip {
- system.img
- product.img
}
ज़िप फ़ाइल में डालने से पहले system.img
और product.img
दोनों को OEM कुंजी द्वारा हस्ताक्षरित किया जाना चाहिए। सामान्य अभ्यास एक असममित एल्गोरिथ्म का उपयोग करना है, उदाहरण के लिए, आरएसए, जहां गुप्त कुंजी का उपयोग पैकेज पर हस्ताक्षर करने के लिए किया जाता है और सार्वजनिक कुंजी का उपयोग इसे सत्यापित करने के लिए किया जाता है। पहले चरण की रैमडिस्क में पारिंग सार्वजनिक कुंजी शामिल होनी चाहिए, उदाहरण के लिए, /avb/*.avbpubkey
। यदि डिवाइस ने पहले से ही AVB को अपनाया है, तो मौजूदा हस्ताक्षर प्रक्रिया पर्याप्त होगी। निम्नलिखित अनुभाग हस्ताक्षर प्रक्रिया का वर्णन करते हैं और एवीबी पबकी के स्थान पर प्रकाश डालते हैं जिसका उपयोग डीएसयू पैकेज में छवियों को सत्यापित करने के लिए किया जाता है।
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 द्वारा हस्ताक्षरित DSU को OEM-B द्वारा बनाए गए डिवाइस पर स्थापित करना।वैकल्पिक
tos
विशेषता एक टेक्स्ट फ़ाइल को इंगित करती है जो संबंधित DSU पैकेज के लिए सेवा की शर्तों का वर्णन करती है। जब कोई डेवलपर निर्दिष्ट सेवा विशेषता की शर्तों के साथ एक डीएसयू पैकेज का चयन करता है, तो चित्र 6 में दिखाया गया संवाद बॉक्स खुलता है, जो डेवलपर को डीएसयू पैकेज स्थापित करने से पहले सेवा की शर्तों को स्वीकार करने के लिए कहता है।चित्र 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 रिलीज़ निर्दिष्ट करता है। उदाहरण के लिए, एंड्रॉइड 10 के लिए,os_version
10
है और Android 11 के लिए,os_version
11
है। जब यह विशेषता निर्दिष्ट की जाती है, तो यहro.system.build.version.release
सिस्टम प्रॉपर्टी के बराबर या उससे अधिक होनी चाहिए। इस चेक का उपयोग एंड्रॉइड 11 विक्रेता डिवाइस पर एंड्रॉइड 10 जीएसआई छवि को बूट करने से रोकने के लिए किया जाता है, जो वर्तमान में समर्थित नहीं है। एंड्रॉइड 10 डिवाइस पर एंड्रॉइड 11 जीएसआई छवि को बूट करने की अनुमति है।vndk
एक वैकल्पिक सरणी है जो DSU पैकेज में शामिल सभी VNDK को निर्दिष्ट करती है। जब यह निर्दिष्ट किया जाता है, तो डीएसयू लोडर जांच करता है कि क्याro.vndk.version
सिस्टम प्रॉपर्टी से निकाला गया नंबर शामिल है।
सुरक्षा के लिए DSU कुंजियाँ निरस्त करें
अत्यंत दुर्लभ मामले में जब डीएसयू छवियों पर हस्ताक्षर करने के लिए उपयोग की जाने वाली आरएसए कुंजी जोड़ी से छेड़छाड़ की जाती है, तो छेड़छाड़ की गई कुंजी को हटाने के लिए रैमडिस्क को जल्द से जल्द अपडेट किया जाना चाहिए। बूट विभाजन को अद्यतन करने के अलावा, आप HTTPS URL से DSU कुंजी निरस्तीकरण सूची (कुंजी ब्लैकलिस्ट) का उपयोग करके समझौता की गई कुंजियों को ब्लॉक कर सकते हैं।
DSU कुंजी निरस्तीकरण सूची में निरस्त AVB सार्वजनिक कुंजियों की एक सूची शामिल है। डीएसयू स्थापना के दौरान, डीएसयू छवियों के अंदर सार्वजनिक कुंजी को निरस्तीकरण सूची के साथ मान्य किया जाता है। यदि छवियों में एक निरस्त सार्वजनिक कुंजी पाई जाती है, तो डीएसयू स्थापना प्रक्रिया रुक जाती है।
सुरक्षा मजबूती सुनिश्चित करने के लिए मुख्य निरस्तीकरण सूची यूआरएल एक HTTPS यूआरएल होना चाहिए, और संसाधन स्ट्रिंग में निर्दिष्ट है:
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 अपनी स्वयं की कुंजी ब्लैकलिस्ट प्रदान और बनाए रख सकें। यह ओईएम को डिवाइस की रैमडिस्क छवि को अपडेट किए बिना कुछ सार्वजनिक कुंजियों को ब्लॉक करने का एक तरीका प्रदान करता है।
निरसन सूची का प्रारूप है:
{
"entries":[
{
"public_key":"bf14e439d1acf231095c4109f94f00fc473148e6",
"status":"REVOKED",
"reason":"Key revocation test key"
},
{
"public_key":"d199b2f29f3dc224cca778a7544ea89470cbef46",
"status":"REVOKED",
"reason":"Key revocation test key"
}
]
}
-
public_key
, AVB पबकी अनुभाग को जनरेट करने में वर्णित प्रारूप में, निरस्त कुंजी का SHA-1 डाइजेस्ट है। -
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
निजी कुंजी पहुंच योग्य नहीं हो सकती है और इसे केवल हार्डवेयर सुरक्षा मॉड्यूल (एचएसएम) में रखा जाता है। इस मामले में, कुंजी निर्माण के बाद 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
फिर निम्न चरणों के साथ प्रथम चरण रैमडिस्क में सार्वजनिक कुंजी शामिल करें।
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)
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 पैकेज पर हस्ताक्षर करने के लिए इन विधियों में से किसी एक का उपयोग करें:
विधि 1: डीएसयू पैकेज बनाने के लिए मूल एवीबी हस्ताक्षर प्रक्रिया द्वारा बनाई गई कलाकृतियों का पुन: उपयोग करें। एक वैकल्पिक तरीका रिलीज़ पैकेज से पहले से हस्ताक्षरित छवियों को निकालना और सीधे ज़िप फ़ाइल बनाने के लिए निकाली गई छवियों का उपयोग करना है।
विधि 2: यदि निजी कुंजी उपलब्ध है तो डीएसयू विभाजन पर हस्ताक्षर करने के लिए निम्नलिखित आदेशों का उपयोग करें। DSU पैकेज (ज़िप फ़ाइल) के भीतर प्रत्येक
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
}
दोनों छवियों पर हस्ताक्षर होने के बाद, ज़िप फ़ाइल बनाने के लिए निम्नलिखित कमांड का उपयोग करें:
$ mkdir -p dsu
$ cp ${OUT}/system.img dsu
$ cp ${OUT}/product.img dsu
$ cd dsu && zip ../dsu.zip *.img && cd -
एक-क्लिक डीएसयू को अनुकूलित करें
डिफ़ॉल्ट रूप से, DSU लोडर GSI छवियों के मेटाडेटा को इंगित करता है जो https://...google.com/.../gsi-src.json
है।
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"
},
}
जैसा कि चित्र 7 में दिखाया गया है, OEM के लिए प्रकाशित DSU मेटाडेटा को श्रृंखलाबद्ध करना संभव है।
चित्र 7. प्रकाशित डीएसयू मेटाडेटा की शृंखला