रिलीज़ के लिए बिल्ड पर हस्ताक्षर करना

Android OS की इमेज में, दो जगहों पर क्रिप्टोग्राफ़िक सिग्नेचर का इस्तेमाल किया जाता है:

1. इमेज में मौजूद हर .apk फ़ाइल पर साइन किया जाना चाहिए. Android का Package Manager, .apk सिग्नेचर का इस्तेमाल दो तरीकों से करता है:
   • किसी ऐप्लिकेशन को बदलने पर, उस पर उसी कुंजी से साइन किया जाना चाहिए जिससे पुराने ऐप्लिकेशन पर साइन किया गया था. ऐसा करने पर ही, नए ऐप्लिकेशन को पुराने ऐप्लिकेशन का डेटा ऐक्सेस करने की अनुमति मिलेगी. यह नियम, उपयोगकर्ता के ऐप्लिकेशन को .apk फ़ाइल को ओवरराइट करके अपडेट करने और /data में इंस्टॉल किए गए नए वर्शन से, सिस्टम ऐप्लिकेशन को ओवरराइड करने, दोनों पर लागू होता है.
   • अगर दो या उससे ज़्यादा ऐप्लिकेशन, उपयोगकर्ता की आईडी शेयर करना चाहते हैं, तो उन पर एक ही कुंजी से साइन किया जाना चाहिए. ऐसा करने पर ही, वे डेटा शेयर कर पाएंगे.
2. OTA अपडेट पैकेज पर, सिस्टम की ओर से इस्तेमाल की जाने वाली किसी एक कुंजी से साइन किया जाना चाहिए. ऐसा न करने पर, इंस्टॉलेशन प्रोसेस उन्हें अस्वीकार कर देगी.

रिलीज़ कुंजियां

Android ट्री में, build/target/product/security के तहत test-keys शामिल हैं. make का इस्तेमाल करके, Android OS की इमेज बनाने पर, सभी .apk फ़ाइलों पर test-keys का इस्तेमाल करके साइन किया जाएगा. test-keys सार्वजनिक तौर पर उपलब्ध हैं. इसलिए, कोई भी व्यक्ति .apk फ़ाइलों पर इन्हीं कुंजियों का इस्तेमाल करके साइन कर सकता है. इससे, वे आपके OS की इमेज में शामिल सिस्टम ऐप्लिकेशन को बदल सकते हैं या उन्हें हैक कर सकते हैं. इसलिए, सार्वजनिक तौर पर रिलीज़ या डिप्लॉय की गई Android OS की किसी भी इमेज पर, release-keys के खास सेट का इस्तेमाल करके साइन करना ज़रूरी है. इन कुंजियों को सिर्फ़ आपके पास ऐक्सेस करने की अनुमति होनी चाहिए.

रिलीज़-कुंजियों का अपना यूनीक सेट जनरेट करने के लिए, अपने Android ट्री के रूट से ये निर्देश चलाएं:

subject='/C=US/ST=California/L=Mountain View/O=Android/OU=Android/CN=Android/emailAddress=android@android.com'
mkdir ~/.android-certs
for x in releasekey platform shared media networkstack; do \
    ./development/tools/make_key ~/.android-certs/$x "$subject"; \
  done

$subject को बदलकर, अपनी कंपनी की जानकारी डालें. किसी भी डायरेक्ट्री का इस्तेमाल किया जा सकता है. हालांकि, ऐसी जगह चुनें जिसका बैकअप लिया जाता हो और जो सुरक्षित हो. कुछ वेंडर, अपनी निजी कुंजी को मज़बूत पासफ़्रेज़ से एन्क्रिप्ट (सुरक्षित) करते हैं और एन्क्रिप्ट की गई कुंजी को सोर्स कंट्रोल में सेव करते हैं. वहीं, कुछ वेंडर अपनी रिलीज़ कुंजियों को किसी दूसरी जगह सेव करते हैं. जैसे, एयर-गैप्ड कंप्यूटर पर.

रिलीज़ इमेज जनरेट करने के लिए, इसका इस्तेमाल करें:

make dist
sign_target_files_apks \
-o \    # explained in the next section
--default_key_mappings ~/.android-certs out/dist/*-target_files-*.zip \
signed-target_files.zip

sign_target_files_apks स्क्रिप्ट, टारगेट-फ़ाइलों वाले .zip को इनपुट के तौर पर लेती है और टारगेट-फ़ाइलों वाला नया .zip बनाती है. इसमें, सभी .apk फ़ाइलों पर नई कुंजियों का इस्तेमाल करके साइन किया जाता है. नई कुंजियों से साइन की गई इमेज, signed-target_files.zip में IMAGES/ के तहत मिल सकती हैं.

OTA पैकेज पर साइन करना

ota_from_target_files \
-k  (--package_key) 
signed-target_files.zip \
signed-ota_update.zip

सिग्नेचर और साइडलोडिंग

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

मुख्य सिस्टम से मिले अपडेट पैकेज की आम तौर पर दो बार पुष्टि की जाती है. पहली बार, मुख्य सिस्टम से android API में RecoverySystem.verifyPackage() तरीके का इस्तेमाल करके और दूसरी बार, रिकवरी से. RecoverySystem API, /system/etc/security/otacerts.zip फ़ाइल में (डिफ़ॉल्ट रूप से) मुख्य सिस्टम में सेव की गई सार्वजनिक कुंजियों के हिसाब से सिग्नेचर की जांच करता है. रिकवरी, /res/keys फ़ाइल में रिकवरी पार्टीशन रैम डिस्क में सेव की गई सार्वजनिक कुंजियों के हिसाब से सिग्नेचर की जांच करती है.

डिफ़ॉल्ट रूप से, बिल्ड से जनरेट की गई टारगेट-फ़ाइलों वाले .zip में, OTA सर्टिफ़िकेट को टेस्ट कुंजी से मैच करने के लिए सेट किया जाता है. रिलीज़ की गई इमेज पर, किसी दूसरे सर्टिफ़िकेट का इस्तेमाल किया जाना चाहिए, ताकि डिवाइस अपडेट पैकेज की पुष्टि कर सकें. पिछले सेक्शन में दिखाए गए तरीके के मुताबिक, sign_target_files_apks को -o फ़्लैग पास करने पर, टेस्ट कुंजी वाले सर्टिफ़िकेट को आपके certs डायरेक्ट्री से रिलीज़ कुंजी वाले सर्टिफ़िकेट से बदल दिया जाता है.

आम तौर पर, सिस्टम इमेज और रिकवरी इमेज में, OTA की सार्वजनिक कुंजियों का एक ही सेट सेव होता है. कुंजी को सिर्फ़ रिकवरी की कुंजियों के सेट में जोड़कर, ऐसे पैकेज पर साइन किया जा सकता है जिन्हें सिर्फ़ साइडलोडिंग के ज़रिए इंस्टॉल किया जा सकता है. हालांकि, इसके लिए यह ज़रूरी है कि मुख्य सिस्टम का अपडेट डाउनलोड करने का मैकेनिज़्म, otacerts.zip के हिसाब से सही तरीके से पुष्टि कर रहा हो. अपने प्रॉडक्ट की परिभाषा में PRODUCT_EXTRA_RECOVERY_KEYS वैरिएबल सेट करके, सिर्फ़ रिकवरी में शामिल की जाने वाली अतिरिक्त कुंजियां तय की जा सकती हैं:

vendor/yoyodyne/tardis/products/tardis.mk

 [...]

PRODUCT_EXTRA_RECOVERY_KEYS := vendor/yoyodyne/security/tardis/sideload

इससे, सार्वजनिक कुंजी vendor/yoyodyne/security/tardis/sideload.x509.pem को रिकवरी की कुंजियों वाली फ़ाइल में शामिल किया जाता है, ताकि इस कुंजी से साइन किए गए पैकेज इंस्टॉल किए जा सकें. हालांकि, अतिरिक्त कुंजी को otacerts.zip में शामिल नहीं किया जाता. इसलिए, डाउनलोड किए गए पैकेज की सही तरीके से पुष्टि करने वाले सिस्टम, इस कुंजी से साइन किए गए पैकेज के लिए रिकवरी को शुरू नहीं करते.

सर्टिफ़िकेट और निजी कुंजियां

हर कुंजी दो फ़ाइलों में मिलती है: सर्टिफ़िकेट, जिसका एक्सटेंशन .x509.pem होता है और निजी कुंजी, जिसका एक्सटेंशन .pk8 होता है. निजी कुंजी को गोपनीय रखा जाना चाहिए. साथ ही, किसी पैकेज पर साइन करने के लिए इसकी ज़रूरत होती है. कुंजी को पासवर्ड से सुरक्षित किया जा सकता है. इसके उलट, सर्टिफ़िकेट में कुंजी का सिर्फ़ सार्वजनिक हिस्सा होता है. इसलिए, इसे बड़े पैमाने पर डिस्ट्रिब्यूट किया जा सकता है. इसका इस्तेमाल, यह पुष्टि करने के लिए किया जाता है कि किसी पैकेज पर, उससे जुड़ी निजी कुंजी से साइन किया गया है.

स्टैंडर्ड Android बिल्ड में पांच कुंजियों का इस्तेमाल किया जाता है. ये सभी कुंजियां build/target/product/security में मौजूद होती हैं:

testkey

ऐसे पैकेज के लिए सामान्य डिफ़ॉल्ट कुंजी जो किसी कुंजी के बारे में जानकारी नहीं देते.

platform

ऐसे पैकेज के लिए टेस्ट कुंजी जो मुख्य प्लैटफ़ॉर्म का हिस्सा हैं.

shared

ऐसी चीज़ों के लिए टेस्ट कुंजी जिन्हें होम/संपर्क प्रोसेस में शेयर किया जाता है.

media

ऐसे पैकेज के लिए टेस्ट कुंजी जो मीडिया/डाउनलोड सिस्टम का हिस्सा हैं.

हर पैकेज, अपनी Android.mk फ़ाइल में LOCAL_CERTIFICATE सेट करके, इनमें से किसी एक कुंजी के बारे में जानकारी देता है. (अगर यह वैरिएबल सेट नहीं है, तो testkey का इस्तेमाल किया जाता है.) पाथनेम के हिसाब से, कोई दूसरी कुंजी भी तय की जा सकती है. उदाहरण के लिए:

device/yoyodyne/apps/SpecialApp/Android.mk

 [...]

LOCAL_CERTIFICATE := device/yoyodyne/security/special

अब बिल्ड, SpecialApp.apk पर साइन करने के लिए, device/yoyodyne/security/special.{x509.pem,pk8} कुंजी का इस्तेमाल करता है. बिल्ड में सिर्फ़ उन निजी कुंजियों का इस्तेमाल किया जा सकता है जो पासवर्ड से सुरक्षित नहीं हैं.

साइन करने के लिए, बेहतर विकल्प

APK साइनिंग कुंजी बदलना

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

कुंजी के नामों के आधार पर, कुंजी बदलने की जानकारी देने के लिए, --key_mapping और --default_key_mappings फ़्लैग का इस्तेमाल करें:

• --key_mapping src_key=dest_key फ़्लैग एक बार में एक कुंजी को बदलने की जानकारी देता है.
• --default_key_mappings dir फ़्लैग, build/target/product/security में मौजूद सभी कुंजियों को बदलने के लिए, पांच कुंजियों वाली डायरेक्ट्री की जानकारी देता है. यह मैपिंग की जानकारी देने के लिए, --key_mapping का पांच बार इस्तेमाल करने के बराबर है.

build/target/product/security/testkey      = dir/releasekey
build/target/product/security/platform     = dir/platform
build/target/product/security/shared       = dir/shared
build/target/product/security/media        = dir/media
build/target/product/security/networkstack = dir/networkstack

APK के नामों के आधार पर, साइनिंग कुंजी बदलने की जानकारी देने के लिए, --extra_apks apk_name1,apk_name2,...=key फ़्लैग का इस्तेमाल करें. अगर key को खाली छोड़ दिया जाता है, तो स्क्रिप्ट, तय किए गए APK को पहले से साइन किया गया मानती है.

मान लें कि tardis प्रॉडक्ट के लिए, आपको पासवर्ड से सुरक्षित छह कुंजियों की ज़रूरत है. इनमें से पांच कुंजियों का इस्तेमाल, build/target/product/security में मौजूद पांच कुंजियों को बदलने के लिए किया जाएगा. वहीं, एक कुंजी का इस्तेमाल, ऊपर दिए गए उदाहरण में SpecialApp के लिए ज़रूरी अतिरिक्त कुंजी device/yoyodyne/security/special को बदलने के लिए किया जाएगा. अगर कुंजियां इन फ़ाइलों में मौजूद हैं:

vendor/yoyodyne/security/tardis/releasekey.x509.pem
vendor/yoyodyne/security/tardis/releasekey.pk8
vendor/yoyodyne/security/tardis/platform.x509.pem
vendor/yoyodyne/security/tardis/platform.pk8
vendor/yoyodyne/security/tardis/shared.x509.pem
vendor/yoyodyne/security/tardis/shared.pk8
vendor/yoyodyne/security/tardis/media.x509.pem
vendor/yoyodyne/security/tardis/media.pk8
vendor/yoyodyne/security/tardis/networkstack.x509.pem
vendor/yoyodyne/security/tardis/networkstack.pk8
vendor/yoyodyne/security/special.x509.pem
vendor/yoyodyne/security/special.pk8           # NOT password protected
vendor/yoyodyne/security/special-release.x509.pem
vendor/yoyodyne/security/special-release.pk8   # password protected

इसके बाद, सभी ऐप्लिकेशन पर इस तरह साइन किया जाएगा:

./build/make/tools/releasetools/sign_target_files_apks \
    --default_key_mappings vendor/yoyodyne/security/tardis \
    --key_mapping vendor/yoyodyne/security/special=vendor/yoyodyne/security/special-release \
    --extra_apks PresignedApp= \
    -o tardis-target_files.zip \
    signed-tardis-target_files.zip

इससे यह जानकारी दिखती है:

Enter password for vendor/yoyodyne/security/special-release key>
Enter password for vendor/yoyodyne/security/tardis/networkstack key>
Enter password for vendor/yoyodyne/security/tardis/media key>
Enter password for vendor/yoyodyne/security/tardis/platform key>
Enter password for vendor/yoyodyne/security/tardis/releasekey key>
Enter password for vendor/yoyodyne/security/tardis/shared key>
    signing: Phone.apk (vendor/yoyodyne/security/tardis/platform)
    signing: Camera.apk (vendor/yoyodyne/security/tardis/media)
    signing: NetworkStack.apk (vendor/yoyodyne/security/tardis/networkstack)
    signing: Special.apk (vendor/yoyodyne/security/special-release)
    signing: Email.apk (vendor/yoyodyne/security/tardis/releasekey)
        [...]
    signing: ContactsProvider.apk (vendor/yoyodyne/security/tardis/shared)
    signing: Launcher.apk (vendor/yoyodyne/security/tardis/shared)
NOT signing: PresignedApp.apk
        (skipped due to special cert string)
rewriting SYSTEM/build.prop:
  replace:  ro.build.description=tardis-user Eclair ERC91 15449 test-keys
     with:  ro.build.description=tardis-user Eclair ERC91 15449 release-keys
  replace: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/test-keys
     with: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/release-keys
    signing: framework-res.apk (vendor/yoyodyne/security/tardis/platform)
rewriting RECOVERY/RAMDISK/default.prop:
  replace:  ro.build.description=tardis-user Eclair ERC91 15449 test-keys
     with:  ro.build.description=tardis-user Eclair ERC91 15449 release-keys
  replace: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/test-keys
     with: ro.build.fingerprint=generic/tardis/tardis/tardis:Eclair/ERC91/15449:user/release-keys
using:
    vendor/yoyodyne/security/tardis/releasekey.x509.pem
for OTA package verification
done.

पासवर्ड से सुरक्षित सभी कुंजियों के लिए, उपयोगकर्ता से पासवर्ड का अनुरोध करने के बाद, स्क्रिप्ट, इनपुट टारगेट .zip में मौजूद सभी APK फ़ाइलों पर रिलीज़ कुंजियों का इस्तेमाल करके दोबारा साइन करती है. कमांड चलाने से पहले, ANDROID_PW_FILE एनवायरमेंट वैरिएबल को किसी अस्थायी फ़ाइल नाम पर भी सेट किया जा सकता है. इसके बाद, स्क्रिप्ट आपका एडिटर शुरू करती है, ताकि सभी कुंजियों के लिए पासवर्ड डाला जा सके. पासवर्ड डालने का यह तरीका ज़्यादा आसान हो सकता है.

APEX साइनिंग कुंजी बदलना

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

रिलीज़ के लिए साइन करते समय, APEX फ़ाइल के लिए इस्तेमाल की जाने वाली दोनों साइनिंग कुंजियों को रिलीज़ कुंजियों से बदल दिया जाता है. फ़ाइल सिस्टम पेलोड कुंजी की जानकारी देने के लिए, --extra_apex_payload फ़्लैग का इस्तेमाल किया जाता है. वहीं, पूरे APEX फ़ाइल की साइनिंग कुंजी की जानकारी देने के लिए, --extra_apks फ़्लैग का इस्तेमाल किया जाता है.

मान लें कि tardis प्रॉडक्ट के लिए, com.android.conscrypt.apex, com.android.media.apex, और com.android.runtime.release.apex APEX फ़ाइलों के लिए, आपके पास कुंजी का यह कॉन्फ़िगरेशन है.

name="com.android.conscrypt.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
name="com.android.media.apex" public_key="PRESIGNED" private_key="PRESIGNED" container_certificate="PRESIGNED" container_private_key="PRESIGNED"
name="com.android.runtime.release.apex" public_key="vendor/yoyodyne/security/testkeys/com.android.runtime.avbpubkey" private_key="vendor/yoyodyne/security/testkeys/com.android.runtime.pem" container_certificate="vendor/yoyodyne/security/testkeys/com.google.android.runtime.release_container.x509.pem" container_private_key="vendor/yoyodyne/security/testkeys/com.google.android.runtime.release_container.pk8"

साथ ही, आपके पास रिलीज़ कुंजियां वाली ये फ़ाइलें हैं:

vendor/yoyodyne/security/runtime_apex_container.x509.pem
vendor/yoyodyne/security/runtime_apex_container.pk8
vendor/yoyodyne/security/runtime_apex_payload.pem

रिलीज़ के लिए साइन करते समय, इस कमांड से com.android.runtime.release.apex और com.android.tzdata.apex के लिए इस्तेमाल की जाने वाली साइनिंग कुंजियां बदल जाती हैं. खास तौर पर, com.android.runtime.release.apex पर, तय की गई रिलीज़ कुंजियों (runtime_apex_container का इस्तेमाल APEX फ़ाइल के लिए और runtime_apex_payload का इस्तेमाल फ़ाइल इमेज पेलोड के लिए) का इस्तेमाल करके साइन किया जाता है. com.android.tzdata.apex को पहले से साइन किया गया माना जाता है. अन्य सभी APEX फ़ाइलों को, टारगेट फ़ाइलों में बताए गए डिफ़ॉल्ट कॉन्फ़िगरेशन के हिसाब से हैंडल किया जाता है.

./build/make/tools/releasetools/sign_target_files_apks \
    --default_key_mappings   vendor/yoyodyne/security/tardis \
    --extra_apks             com.android.runtime.release.apex=vendor/yoyodyne/security/runtime_apex_container \
    --extra_apex_payload_key com.android.runtime.release.apex=vendor/yoyodyne/security/runtime_apex_payload.pem \
    --extra_apks             com.android.media.apex= \
    --extra_apex_payload_key com.android.media.apex= \
    -o tardis-target_files.zip \
    signed-tardis-target_files.zip

ऊपर दी गई कमांड चलाने पर, ये लॉग मिलते हैं:

        [...]
    signing: com.android.runtime.release.apex                  container (vendor/yoyodyne/security/runtime_apex_container)
           : com.android.runtime.release.apex                  payload   (vendor/yoyodyne/security/runtime_apex_payload.pem)
NOT signing: com.android.conscrypt.apex
        (skipped due to special cert string)
NOT signing: com.android.media.apex
        (skipped due to special cert string)
        [...]

दूसरे विकल्प

sign_target_files_apks स्क्रिप्ट, बिल्ड प्रॉपर्टी फ़ाइलों में बिल्ड की जानकारी और फ़िंगरप्रिंट को फिर से लिखती है, ताकि यह पता चल सके कि बिल्ड पर साइन किया गया है. --tag_changes फ़्लैग से यह कंट्रोल किया जाता है कि फ़िंगरप्रिंट में कौनसे बदलाव किए जाएं. सभी फ़्लैग के बारे में दस्तावेज़ देखने के लिए, स्क्रिप्ट को -h के साथ चलाएं.

कुंजियां मैन्युअल तरीके से जनरेट करना

Android, 2048-बिट आरएसए कुंजियों का इस्तेमाल करता है. इनमें सार्वजनिक एक्सपोनेन्ट 3 होता है. openssl.org से openssl टूल का इस्तेमाल करके, सर्टिफ़िकेट/निजी कुंजी के जोड़े जनरेट किए जा सकते हैं:

# generate RSA key
openssl genrsa -3 -out temp.pem 2048
Generating RSA private key, 2048 bit long modulus
....+++
.....................+++
e is 3 (0x3)

# create a certificate with the public part of the key
openssl req -new -x509 -key temp.pem -out releasekey.x509.pem -days 10000 -subj '/C=US/ST=California/L=San Narciso/O=Yoyodyne, Inc./OU=Yoyodyne Mobility/CN=Yoyodyne/emailAddress=yoyodyne@example.com'

# create a PKCS#8-formatted version of the private key
openssl pkcs8 -in temp.pem -topk8 -outform DER -out releasekey.pk8 -nocrypt

# securely delete the temp.pem file
shred --remove temp.pem

ऊपर दी गई openssl pkcs8 कमांड से, .pk8 फ़ाइल बनती है. इसमें कोई पासवर्ड नहीं होता. इसका इस्तेमाल, बिल्ड सिस्टम के साथ किया जा सकता है. पासवर्ड से सुरक्षित .pk8 फ़ाइल बनाने के लिए (रिलीज़ की सभी असली कुंजियों के लिए ऐसा किया जाना चाहिए), -nocrypt आर्ग्युमेंट को -passout stdin से बदलें. इसके बाद, openssl, निजी कुंजी को स्टैंडर्ड इनपुट से पढ़े गए पासवर्ड से एन्क्रिप्ट (सुरक्षित) करेगा. कोई प्रॉम्प्ट नहीं दिखता. इसलिए, अगर stdin टर्मिनल है, तो प्रोग्राम तब तक हैंग दिखेगा, जब तक आप पासवर्ड नहीं डालते. पासवर्ड को दूसरी जगहों से पढ़ने के लिए, -passout आर्ग्युमेंट के लिए अन्य वैल्यू का इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, openssl का दस्तावेज़ देखें.

temp.pem इंटरमीडिएट फ़ाइल में, निजी कुंजी बिना किसी पासवर्ड सुरक्षा के मौजूद होती है. इसलिए, रिलीज़ कुंजियां जनरेट करते समय, इसे सोच-समझकर डिस्पोज़ करें. खास तौर पर, GNUshred यूटिलिटी, नेटवर्क या जर्नल किए गए फ़ाइल सिस्टम पर काम नहीं कर सकती. कुंजियां जनरेट करते समय, रैम डिस्क में मौजूद वर्किंग डायरेक्ट्री (जैसे, tmpfs पार्टीशन) का इस्तेमाल किया जा सकता है, ताकि इंटरमीडिएट फ़ाइलें गलती से भी सार्वजनिक न हो जाएं.

इमेज फ़ाइलें बनाना

signed-target_files.zip मिलने के बाद, आपको इमेज बनानी होगी, ताकि इसे किसी डिवाइस पर डाला जा सके. टारगेट फ़ाइलों से साइन की गई इमेज बनाने के लिए, Android ट्री के रूट से यह कमांड चलाएं:

img_from_target_files signed-target_files.zip signed-img.zip

fastboot update signed-img.zip