Android 10 के बाद, CTS-on-GSI/VTS के मुताबिक टेस्ट करने के लिए इस्तेमाल किया जाने वाला Generic System Image (GSI), रिलीज़ साइन करने के लिए, userdebug से user build टाइप में बदल गया है. यह वीटीएस की जांच के लिए एक समस्या है, क्योंकि वीटीएस को चलाने के लिए adb root
की ज़रूरत होती है. हालांकि, adb root
उपयोगकर्ता के बनाए गए डिवाइस पर उपलब्ध नहीं होता.
डीबग रैमडिस्क (या डीबग बूट इमेज) को उपयोगकर्ता के बनाए गए ऐसे डिवाइस पर adb root
को चालू करने के लिए लॉन्च किया गया जिसके बूटलोडर को अनलॉक किया गया है. यह CTS-on-GSI और VTS-on-GSI के लिए, एक ही उपयोगकर्ता बिल्ड जीएसआई system.img
का इस्तेमाल करके, टेस्टिंग के फ़्लो को आसान बनाता है. एसटीएस सेटअप के लिए, किसी अन्य यूज़र डीबग OEM system.img
का इस्तेमाल करना अब भी
ज़रूरी है.
नीचे दी गई टेबल में, Android 10 में नीतियों का पालन करने से जुड़ी जांच के लिए, इमेज और बिल्ड टाइप में हुए बदलावों के बारे में बताया गया है.
टेस्ट सुइट | इनसे जांच करें | बनाएं | डीबग करने के लिए ramdisk | adb root? | Android 9 से 10 पर बिल्ड वैरिएंट में बदलाव |
---|---|---|---|---|---|
सीटीएस | OEM का सिस्टम | उपयोगकर्ता | नहीं | नहीं | कोई बदलाव नहीं |
जीएसआई पर सीटीएस | जीएसआई | उपयोगकर्ता | नहीं | नहीं | उपयोगकर्ता डीबग -> उपयोगकर्ता जीएसआई रिलीज़ पर हस्ताक्षर किया गया |
STS | OEM का सिस्टम | userdebug | नहीं | Y | Q में नया |
वीटीएस | जीएसआई | उपयोगकर्ता | Y | Y | userdebug -> user GSI रिलीज़ पर हस्ताक्षर किया गया |
खास जानकारी
ये अतिरिक्त इमेज फ़ाइलें, बिल्ड फ़ोल्डर (${ANDROID_PRODUCT_OUT}
) में जनरेट होती हैं:
boot-debug.img
vendor_boot-debug.img
जब boot-debug.img
को डिवाइस के boot
पार्टीशन पर फ़्लैश किया जाता है, तो सिस्टम की sepolicy फ़ाइल का userdebug वर्शन और एक और प्रॉपर्टी फ़ाइल, adb_debug.prop
लोड हो जाती है. इससे उपयोगकर्ता बिल्ड के साथ adb root
की अनुमति मिलती है system.img
(जीएसआई या OEM का).
vendor_boot
सेगमेंट वाले डिवाइसों पर Generic Kernel Image (GKI) का इस्तेमाल करने के लिए, boot-debug.img
को फ़्लैश नहीं किया जाना चाहिए. ऐसा इसलिए, क्योंकि boot
सेगमेंट को सर्टिफ़ाइड GKI इमेज से फ़्लैश किया जाना चाहिए.
इसके बजाय, vendor_boot-debug.img
को vendor_boot
partition पर फ़्लैश किया जाना चाहिए, ताकि ramdisk को डीबग किया जा सके.
डीबग करने के लिए, रैम डिस्क का इस्तेमाल करने से जुड़ी ज़रूरी शर्तें
डीबग रैमडिस्क, OEM उपलब्ध कराता है जो अनुपालन की जांच कर रहा है. यह रिलीज़ साइन नहीं होना चाहिए. साथ ही, इसका इस्तेमाल सिर्फ़ तब किया जा सकता है, जब डिवाइस अनलॉक हो.
डिबग रैमडिस्क को जनरेट नहीं किया जाएगा या इन डिवाइसों को अपग्रेड करने के लिए इस्तेमाल नहीं किया जाएगा:
BOARD_BUILD_SYSTEM_ROOT_IMAGE
सहीskip_initramfs
को कर्नेल कमांड लाइन में
Android 12 GSI
Android 12 जीएसआई के साथ डीबग रैमडिस्क का इस्तेमाल करने के लिए, किसी अन्य निर्देश की ज़रूरत नहीं है.
डीबग रैम डिस्क को 29/09/2021 से, repack_bootimg
टूल की मदद से अपडेट करने की ज़रूरत नहीं होगी. SGR1.210929.001 (7777720)
के बाद का Android 12 GSI बिल्ड, अपने system.img
में अप-टू-डेट userdebug_plat_sepolicy.cil
फ़ाइल को शामिल करता है और डीबग रैमडिस्क से userdebug_plat_sepolicy.cil
को अनदेखा करता है. ज़्यादा जानकारी के लिए, CLs देखें.
Android 11 GSI
boot-debug.img
या vendor_boot-debug.img
का इस्तेमाल करने पर, boot-debug.img
या vendor_boot-debug.img
के डीबग
रैमडिस्क में मौजूद userdebug_plat_sepolicy.cil
फ़ाइल से, सिस्टम की सेक्योरिटी नीति लोड हो जाती है. GSI इमेज को बूट करने के लिए, कृपया android11-gsi
शाखा से, sepolicy में किए गए अप-टू-डेट बदलावों को हमेशा शामिल करें. इससे, boot-debug.img
या vendor_boot-debug.img
को फिर से बनाया जा सकेगा.
इसके अलावा, repack_bootimg
टूल का इस्तेमाल करके, अपडेट की गई जीएसआई सेपॉलिसी के साथ boot-debug.img
या vendor_boot-debug.img
को फिर से बनाया जा सकता है.
डीबग रैम डिस्क को रीपैक करें
boot-debug.img
को फिर से बनाने के लिए, sepolicy में बदलाव करने के बजाय, पार्टनर repack_bootimg
का इस्तेमाल करके, GSI sepolicy फ़ाइल को boot-debug.img
(या अगर डिवाइस GKI का इस्तेमाल करता है, तो vendor_boot-debug.img
) में अपडेट कर सकते हैं.
इसके लिए, यह तरीका अपनाएं:
otatools.zip
को https://ci.android.com से डाउनलोड करें. हमारा सुझाव है कि आपaosp-main
परaosp_arm64-userdebug
के बिल्ड आर्टफ़ैक्ट से डाउनलोड करें.repack_bootimg
के लिए, प्रोसेस करने का एनवायरमेंट सेट अप करें:unzip otatools.zip -d otatools
export PATH="${PWD}/otatools/bin:${PATH}"
repack_bootimg --help
इस्तेमाल किए जा रहे GSI बिल्ड से
userdebug_plat_sepolicy.cil
याboot-with-debug-ramdisk-${KERNEL_VERSION}.img
डाउनलोड करें. उदाहरण के लिए, अगरRJR1.211020.001 (7840830)
से arm64 GSI का इस्तेमाल किया जा रहा है, तो https://ci.android.com/builds/submitted/7840830/aosp_arm64-user/latest से डाउनलोड करें.डिवाइस
boot-debug.img
याvendor_boot-debug.img
कोuserdebug_plat_sepolicy.cil
पर अपडेट करें:repack_bootimg --local --dst_bootimg boot-debug.img \ --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --local --dst_bootimg vendor_boot-debug.img \ --ramdisk_add userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
boot-with-debug-ramdisk-${KERNEL_VERSION}.img
के साथ:repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \ --dst_bootimg boot-debug.img \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
# If using GKI
repack_bootimg --src_bootimg boot-with-debug-ramdisk-5.4.img \ --dst_bootimg vendor_boot-debug.img \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil \ --ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
डिवाइस के कॉन्फ़िगरेशन के हिसाब से,
--ramdisk_add
के आर्ग्युमेंट में बदलाव किया जा सकता है. ज़्यादा जानकारी के लिए, अगला सेक्शन देखें.
userdebug sepolicy का पाथ
ऊपर दिया गया repack_bootimg
, userdebug_plat_sepolicy.cil
फ़ाइल को --src_bootimg
के रैमडिस्क से --dst_bootimg
के रैमडिस्क में कॉपी करता है. हालांकि, डीबग रैम डिस्क का पाथ, अलग-अलग Android वर्शन में अलग-अलग हो सकता है. Android 10 और 11 में, उन डिवाइसों का पाथ first_stage_ramdisk/userdebug_plat_sepolicy.cil
है जिनमें कर्नेल कमांड लाइन में androidboot.force_normal_boot=1
मौजूद है. इसके अलावा, पाथ userdebug_plat_sepolicy.cil
होता है.
यह देखने के लिए कि कर्नेल कमांड लाइन में androidboot.force_normal_boot
है या नहीं, यह कमांड चलाएं:
adb root
adb shell cat /proc/cmdline | grep force_normal_boot
Android 12 से, डीबग रैमडिस्क में मौजूद पाथ हमेशा userdebug_plat_sepolicy.cil
होता है. भले ही, कर्नेल कमांड लाइन में androidboot.force_normal_boot=1
मौजूद हो या नहीं. नीचे दी गई टेबल में, अलग-अलग Android वर्शन के डीबग रैम डिस्क के पाथ दिखाए गए हैं.
डीबग इमेज | Android 10 | Android 11 | Android 12 |
---|---|---|---|
GKI boot-with-debug-ramdisk-${KERNEL_VERSION}.img | लागू नहीं | first_stage_ramdisk/userdebug_plat_sepolicy.cil |
userdebug_plat_sepolicy.cil |
डिवाइस के हिसाब से boot-debug.img | यह force_normal_boot पर निर्भर करता है | यह force_normal_boot पर निर्भर करता है | userdebug_plat_sepolicy.cil |
डिवाइस के हिसाब से vendor_boot-debug.img | लागू नहीं | यह force_normal_boot पर निर्भर करता है | userdebug_plat_sepolicy.cil |
src_path:dst_path
जोड़े की सूची की मदद से, अलग-अलग पाथ से फ़ाइलों को कॉपी करने और उन्हें अलग-अलग पाथ में चिपकाने के लिए, --ramdisk_add
का इस्तेमाल किया जा सकता है. उदाहरण के लिए, यह कमांड, Android 11 boot-with-debug-ramdisk-5.4.img
से फ़ाइल first_stage_ramdisk/userdebug_plat_sepolicy.cil
को कॉपी करके, Android 11 vendor_boot-debug.img
में first_stage_ramdisk/userdebug_plat_sepolicy.cil
में चिपकाता है.
repack_bootimg \
--src_bootimg boot-with-debug-ramdisk-5.4.img \
--dst_bootimg vendor_boot-debug.img \
--ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:first_stage_ramdisk/userdebug_plat_sepolicy.cil
अगर कर्नेल कमांड लाइन में कोई androidboot.force_normal_boot=1
नहीं है, तो डेस्टिनेशन पाथ को userdebug_plat_sepolicy.cil
में बदलने के लिए, कमांड में नीचे दिए गए तरीके से बदलाव किया जाना चाहिए.
repack_bootimg \
--src_bootimg boot-with-debug-ramdisk-5.4.img \
--dst_bootimg vendor_boot-debug.img \
--ramdisk_add first_stage_ramdisk/userdebug_plat_sepolicy.cil:userdebug_plat_sepolicy.cil
AVB फ़ुटर जोड़ना
अगर --dst_bootimg
को पास की गई इमेज को AVB-चेन वाले सेगमेंट के तौर पर कॉन्फ़िगर किया गया है, तो repack_bootimg
कमांड चलाने के बाद AVB फ़ुटर जोड़ना होगा.
उदाहरण के लिए, repack_bootimg
को चलाने से पहले, यह पता करने के लिए यह कमांड चलाएं कि vendor_boot-debug.img
में चेन किया गया AVB फ़ुटर है या नहीं.
avbtool info_image --image vendor_boot-debug.img
अगर इसमें मूल रूप से एक चेन वाला AVB फ़ुटर है, तो repack_bootimg
कमांड का इस्तेमाल करने के बाद एक एवीबी फ़ुटर जोड़ना होगा. vendor_boot-debug.img
पर हस्ताक्षर करने के लिए, किसी भी टेस्ट पासकोड का इस्तेमाल किया जा सकता है. ऐसा इसलिए है, क्योंकि डिबग रैमडिस्क का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब डिवाइस अनलॉक हो. इससे boot
या vendor_boot
पार्टीशन पर, रिलीज़ पासकोड से हस्ताक्षर की गई इमेज का इस्तेमाल किया जा सकता है.
avbtool add_hash_footer --partition_name vendor_boot \
--partition_size 100663296 \
--algorithm SHA256_RSA4096 \
--key otatools/external/avb/test/data/testkey_rsa4096.pem \
--image vendor_boot-debug.img