डीबग रैमडिस्क के साथ वीटीएस टेस्टिंग

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) में अपडेट कर सकते हैं.

इसके लिए, यह तरीका अपनाएं:

  1. otatools.zip को https://ci.android.com से डाउनलोड करें. हमारा सुझाव है कि आप aosp-main पर aosp_arm64-userdebug के बिल्ड आर्टफ़ैक्ट से डाउनलोड करें.

  2. repack_bootimg के लिए, प्रोसेस करने का एनवायरमेंट सेट अप करें:

    unzip otatools.zip -d otatools
    export PATH="${PWD}/otatools/bin:${PATH}"
    repack_bootimg --help
  3. इस्तेमाल किए जा रहे 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 से डाउनलोड करें.

  4. डिवाइस 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

अगर --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