हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

नया डिवाइस जोड़ना

अपने डिवाइस और प्रॉडक्ट के लिए मेकफ़ाइलें बनाने के लिए, इस पेज पर दी गई जानकारी का इस्तेमाल करें.

हर नए Android मॉड्यूल में एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए. इससे बिल्ड सिस्टम को मॉड्यूल के मेटाडेटा, कंपाइल-टाइम डिपेंडेंसी, और पैकेजिंग के निर्देशों के बारे में पता चलता है. Android, Soong बिल्ड सिस्टम का इस्तेमाल करता है. Android के बिल्ड सिस्टम के बारे में ज़्यादा जानने के लिए, Android बनाना लेख पढ़ें.

बिल्ड लेयर के बारे में जानकारी

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

लेयर	उदाहरण	ब्यौरा
प्रॉडक्ट	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	प्रॉडक्ट लेयर, शिपिंग प्रॉडक्ट की सुविधा से जुड़ी खास बातों के बारे में बताती है. जैसे, मॉड्यूल बनाने, काम करने वाली स्थानीय भाषाओं, और अलग-अलग स्थानीय भाषाओं के लिए कॉन्फ़िगरेशन के बारे में बताती है. दूसरे शब्दों में, यह पूरे प्रॉडक्ट का नाम है. प्रॉडक्ट के हिसाब से वैरिएबल, प्रॉडक्ट की परिभाषा वाली मेकफ़ाइल में तय किए जाते हैं. कोई प्रॉडक्ट, अन्य प्रॉडक्ट की परिभाषाओं से जानकारी ले सकता है. इससे रखरखाव आसान हो जाता है. आम तौर पर, एक ऐसा बेस प्रॉडक्ट बनाया जाता है जिसमें सभी प्रॉडक्ट पर लागू होने वाली सुविधाएं शामिल होती हैं. इसके बाद, उस बेस प्रॉडक्ट के आधार पर प्रॉडक्ट के वेरिएंट बनाए जाते हैं. उदाहरण के लिए, दो ऐसे प्रॉडक्ट जिनमें सिर्फ़ रेडियो (सीडीएमए बनाम जीएसएम) का अंतर है, वे एक ही बेस प्रॉडक्ट से इनहेरिट किए जा सकते हैं. इस बेस प्रॉडक्ट में रेडियो के बारे में जानकारी नहीं दी गई है.
बोर्ड/डिवाइस	मार्लिन, ब्लूललाइन, कोरल	बोर्ड/डिवाइस लेयर, डिवाइस पर मौजूद प्लास्टिक की फ़िज़िकल लेयर को दिखाती है. इसका मतलब है कि यह डिवाइस के इंडस्ट्रियल डिज़ाइन को दिखाती है. इस लेयर में, किसी प्रॉडक्ट के सामान्य डायग्राम भी दिखाए जाते हैं. इनमें बोर्ड पर मौजूद पेरिफ़ेरल और उनके कॉन्फ़िगरेशन शामिल हैं. इस्तेमाल किए गए नाम, अलग-अलग बोर्ड/डिवाइस कॉन्फ़िगरेशन के लिए सिर्फ़ कोड हैं.
आर्क	arm, x86, arm64, x86_64	आर्किटेक्चर लेयर में, प्रोसेसर कॉन्फ़िगरेशन और बोर्ड पर चल रहे ऐप्लिकेशन बाइनरी इंटरफ़ेस (एबीआई) के बारे में बताया जाता है.

बिल्ड वैरिएंट का इस्तेमाल करना

किसी प्रॉडक्ट के लिए ऐप्लिकेशन बनाते समय, फ़ाइनल रिलीज़ बिल्ड में कुछ बदलाव करना फ़ायदेमंद होता है. मॉड्यूल की परिभाषा में, मॉड्यूल LOCAL_MODULE_TAGS के साथ टैग तय कर सकता है. LOCAL_MODULE_TAGS की वैल्यू एक या उससे ज़्यादा हो सकती हैं. जैसे, optional (डिफ़ॉल्ट), debug, और eng.

अगर कोई मॉड्यूल, टैग के बारे में जानकारी नहीं देता है (LOCAL_MODULE_TAGS के ज़रिए), तो उसका टैग डिफ़ॉल्ट रूप से optional पर सेट होता है. वैकल्पिक मॉड्यूल सिर्फ़ तब इंस्टॉल किया जाता है, जब PRODUCT_PACKAGES के साथ प्रॉडक्ट कॉन्फ़िगरेशन के लिए इसकी ज़रूरत हो.

ये फ़िलहाल तय किए गए बिल्ड वैरिएंट हैं.

वैरिएंट	ब्यौरा
`eng`	यह डिफ़ॉल्ट फ़्लेवर है. यह कुकी, `eng` या `debug` के तौर पर टैग किए गए मॉड्यूल इंस्टॉल करती है. यह टैग किए गए मॉड्यूल के साथ-साथ, प्रॉडक्ट डेफ़िनिशन फ़ाइलों के हिसाब से मॉड्यूल इंस्टॉल करता है. `ro.secure=0` `ro.debuggable=1` `ro.kernel.android.checkjni=1` `adb` डिफ़ॉल्ट रूप से चालू होती है.
`user`	यह वैरिएंट, फ़ाइनल रिलीज़ बिट के तौर पर इस्तेमाल किया जाता है. यह `user` टैग किए गए मॉड्यूल इंस्टॉल करता है. यह टैग किए गए मॉड्यूल के साथ-साथ, प्रॉडक्ट डेफ़िनिशन फ़ाइलों के हिसाब से मॉड्यूल इंस्टॉल करता है. `ro.secure=1` `ro.debuggable=0` `adb` डिफ़ॉल्ट रूप से बंद होती है.
`userdebug`	यह `user` के बराबर है. हालांकि, इसमें ये अपवाद शामिल हैं: यह `debug` के साथ टैग किए गए मॉड्यूल भी इंस्टॉल करता है. `ro.debuggable=1` `adb` डिफ़ॉल्ट रूप से चालू होती है.

userdebug के लिए दिशा-निर्देश

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

userdebug को ऐसे उपयोगकर्ता बिल्ड के तौर पर परिभाषित किया गया है जिसमें रूट ऐक्सेस चालू होता है. हालांकि, इसमें ये शामिल नहीं हैं:
- userdebug-only ऐप्लिकेशन, जिन्हें उपयोगकर्ता सिर्फ़ ज़रूरत पड़ने पर चलाता है
- ऐसे ऑपरेशन जो सिर्फ़ डिवाइस के रखरखाव के दौरान चलते हैं. जैसे, बैकग्राउंड में कंपाइल करने के लिए dex2oatd के बजाय dex2oat का इस्तेमाल करना. रखरखाव के दौरान डिवाइस, चार्जर से कनेक्ट होना चाहिए या पूरी तरह चार्ज होना चाहिए
ऐसी सुविधाएं शामिल न करें जो बिल्ड टाइप के आधार पर डिफ़ॉल्ट रूप से चालू/बंद होती हैं. डेवलपर को ऐसी किसी भी तरह की लॉगिंग का इस्तेमाल न करने की सलाह दी जाती है जिससे बैटरी लाइफ़ पर असर पड़ता हो. जैसे, डीबग लॉगिंग या हीप डंपिंग.
userdebug में डिफ़ॉल्ट रूप से चालू की गई किसी भी डीबग करने की सुविधा के बारे में साफ़ तौर पर बताया जाना चाहिए. साथ ही, इसे प्रोजेक्ट पर काम करने वाले सभी डेवलपर के साथ शेयर किया जाना चाहिए. आपको डीबग करने की सुविधाओं को सिर्फ़ सीमित समय के लिए चालू करना चाहिए. ऐसा तब तक करें, जब तक डीबग की जा रही समस्या हल न हो जाए.

संसाधन ओवरले की मदद से, बिल्ड को पसंद के मुताबिक बनाना

Android बिल्ड सिस्टम, बिल्ड के समय किसी प्रॉडक्ट को पसंद के मुताबिक बनाने के लिए, रिसॉर्स ओवरले का इस्तेमाल करता है. संसाधन ओवरले, संसाधन फ़ाइलों के बारे में बताते हैं. ये फ़ाइलें, डिफ़ॉल्ट फ़ाइलों के ऊपर लागू होती हैं. संसाधन ओवरले का इस्तेमाल करने के लिए, प्रोजेक्ट की बिल्डफ़ाइल में बदलाव करें. इसके लिए, PRODUCT_PACKAGE_OVERLAYS को टॉप-लेवल डायरेक्ट्री के हिसाब से पाथ पर सेट करें. जब बिल्ड सिस्टम संसाधनों को खोजता है, तो यह पाथ, मौजूदा रूट के साथ खोजा गया शैडो रूट बन जाता है.

सबसे ज़्यादा बदली जाने वाली सेटिंग, frameworks/base/core/res/res/values/config.xml फ़ाइल में मौजूद होती हैं.

इस फ़ाइल पर रिसॉर्स ओवरले सेट अप करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करके, ओवरले डायरेक्ट्री को प्रोजेक्ट की बिल्डफ़ाइल में जोड़ें:

PRODUCT_PACKAGE_OVERLAYS := device/device-implementer/device-name/overlay

या

PRODUCT_PACKAGE_OVERLAYS := vendor/vendor-name/overlay

इसके बाद, डायरेक्ट्री में कोई ओवरले फ़ाइल जोड़ें. उदाहरण के लिए:

vendor/foobar/overlay/frameworks/base/core/res/res/values/config.xml

ओवरले config.xml फ़ाइल में मौजूद कोई भी स्ट्रिंग या स्ट्रिंग ऐरे, ओरिजनल फ़ाइल में मौजूद स्ट्रिंग या स्ट्रिंग ऐरे की जगह ले लेता है.

प्रॉडक्ट बनाना

अपने डिवाइस की सोर्स फ़ाइलों को कई तरह से व्यवस्थित किया जा सकता है. Pixel को लागू करने के तरीके के बारे में यहां खास जानकारी दी गई है.

Pixel को marlin नाम वाले मुख्य डिवाइस कॉन्फ़िगरेशन के साथ लागू किया गया है. इस डिवाइस कॉन्फ़िगरेशन से, एक प्रॉडक्ट बनाया जाता है. इसमें प्रॉडक्ट डेफ़िनिशन मेकफ़ाइल होती है. यह डिवाइस के बारे में प्रॉडक्ट से जुड़ी जानकारी देती है. जैसे, नाम और मॉडल. device/google/marlin डायरेक्ट्री में जाकर, यह देखा जा सकता है कि यह सब कैसे सेट अप किया गया है.

प्रॉडक्ट के मेकफ़ाइल लिखना

यहां दिए गए तरीके से, Pixel प्रॉडक्ट लाइन की तरह ही प्रॉडक्ट मेकफ़ाइल सेट अप की जा सकती हैं:

अपने प्रॉडक्ट के लिए device/<company-name>/<device-name> डायरेक्ट्री बनाएं. उदाहरण के लिए, device/google/marlin. इस डायरेक्ट्री में आपके डिवाइस के लिए सोर्स कोड होगा. साथ ही, उन्हें बनाने के लिए मेकफ़ाइलें भी होंगी.
एक device.mk मेकफ़ाइल बनाएं. इसमें डिवाइस के लिए ज़रूरी फ़ाइलों और मॉड्यूल के बारे में जानकारी दें. उदाहरण के लिए, device/google/marlin/device-marlin.mk देखें.
डिवाइस के आधार पर कोई खास प्रॉडक्ट बनाने के लिए, प्रॉडक्ट डेफ़िनिशन मेकफ़ाइल बनाएं. यहां दिए गए मेकफ़ाइल को device/google/marlin/aosp_marlin.mk से उदाहरण के तौर पर लिया गया है. ध्यान दें कि प्रॉडक्ट, मेकफ़ाइल के ज़रिए device/google/marlin/device-marlin.mk और vendor/google/marlin/device-vendor-marlin.mk फ़ाइलों से इनहेरिट करता है. साथ ही, प्रॉडक्ट के बारे में जानकारी भी देता है. जैसे, नाम, ब्रैंड, और मॉडल.
```
# Inherit from the common Open Source product configuration
$(call inherit-product, $(SRC_TARGET_DIR)/product/core_64_bit.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/aosp_base_telephony.mk)

PRODUCT_NAME := aosp_marlin
PRODUCT_DEVICE := marlin
PRODUCT_BRAND := Android
PRODUCT_MODEL := AOSP on msm8996
PRODUCT_MANUFACTURER := Google
PRODUCT_RESTRICT_VENDOR_FILES := true

PRODUCT_COPY_FILES += device/google/marlin/fstab.common:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.marlin

$(call inherit-product, device/google/marlin/device-marlin.mk)
$(call inherit-product-if-exists, vendor/google_devices/marlin/device-vendor-marlin.mk)

PRODUCT_PACKAGES += \
    Launcher3QuickStep \
    WallpaperPicker
```
प्रॉडक्ट के हिसाब से तय किए गए अन्य वैरिएबल के लिए, प्रॉडक्ट की परिभाषा वाले वैरिएबल सेट करना लेख पढ़ें. इन वैरिएबल को अपनी मेकफ़ाइल में जोड़ा जा सकता है.
एक AndroidProducts.mk फ़ाइल बनाएं, जो प्रॉडक्ट की मेकफ़ाइलों की ओर ले जाती हो. इस उदाहरण में, सिर्फ़ प्रॉडक्ट की परिभाषा वाली मेकफ़ाइल की ज़रूरत होती है. नीचे दिया गया उदाहरण, device/google/marlin/AndroidProducts.mk से लिया गया है. इसमें Marlin (Pixel) और Sailfish (Pixel XL) दोनों शामिल हैं. इन दोनों में ज़्यादातर कॉन्फ़िगरेशन एक जैसे हैं:
```
PRODUCT_MAKEFILES := \
	$(LOCAL_DIR)/aosp_marlin.mk \
	$(LOCAL_DIR)/aosp_sailfish.mk

COMMON_LUNCH_CHOICES := \
	aosp_marlin-userdebug \
	aosp_sailfish-userdebug
```
बोर्ड के हिसाब से कॉन्फ़िगरेशन वाली BoardConfig.mk makefile बनाएं. उदाहरण के लिए, device/google/marlin/BoardConfig.mk देखें.
Android 9 और इससे पहले के वर्शन के लिए सिर्फ़, अपने प्रॉडक्ट (जैसे, "लंच कॉम्बो") को बिल्ड में जोड़ने के लिए, vendorsetup.sh फ़ाइल बनाएं. साथ ही, डैश से अलग किया गया बिल्ड वैरिएंट जोड़ें. उदाहरण के लिए:
```
add_lunch_combo <product-name>-userdebug
```
इस चरण में, एक ही डिवाइस के आधार पर प्रॉडक्ट के और वैरिएंट बनाए जा सकते हैं.

प्रॉडक्ट की परिभाषा वाले वैरिएबल सेट करना

प्रॉडक्ट के हिसाब से वैरिएबल, प्रॉडक्ट की मेकफ़ाइल में तय किए जाते हैं. इस टेबल में, प्रॉडक्ट की परिभाषा वाली फ़ाइल में सेव किए गए कुछ वैरिएबल दिखाए गए हैं.

वैरिएबल	ब्यौरा	उदाहरण
`PRODUCT_AAPT_CONFIG`	पैकेज बनाते समय इस्तेमाल करने के लिए `aapt` कॉन्फ़िगरेशन.
`PRODUCT_BRAND`	वह ब्रैंड (उदाहरण के लिए, मोबाइल और इंटरनेट सेवा देने वाली कंपनी) जिसके लिए सॉफ़्टवेयर को पसंद के मुताबिक बनाया गया है.
`PRODUCT_CHARACTERISTICS`	`aapt` एट्रिब्यूट का इस्तेमाल किया जाता है, ताकि पैकेज में वैरिएंट के हिसाब से संसाधन जोड़े जा सकें.	`tablet`, `nosdcard`
`PRODUCT_COPY_FILES`	`source_path:destination_path` जैसे शब्दों की सूची. इस प्रॉडक्ट को बनाते समय, सोर्स पाथ पर मौजूद फ़ाइल को डेस्टिनेशन पाथ पर कॉपी किया जाना चाहिए. कॉपी करने के चरणों के नियम `config/makefile` में बताए गए हैं.
`PRODUCT_DEVICE`	इंडस्ट्रियल डिज़ाइन का नाम. यह बोर्ड का नाम भी है. बिल्ड सिस्टम इसका इस्तेमाल, `BoardConfig.mk` का पता लगाने के लिए करता है.	`tuna`
`PRODUCT_LOCALES`	इसमें दो अक्षरों वाले भाषा कोड और दो अक्षरों वाले देश कोड के ऐसे जोड़े होते हैं जिनके बीच में खाली जगह होती है. ये जोड़े, उपयोगकर्ता के लिए कई सेटिंग के बारे में बताते हैं. जैसे, यूज़र इंटरफ़ेस (यूआई) की भाषा और समय, तारीख, और मुद्रा का फ़ॉर्मैट. `PRODUCT_LOCALES` में दी गई पहली स्थानीय भाषा को प्रॉडक्ट की डिफ़ॉल्ट स्थानीय भाषा के तौर पर इस्तेमाल किया जाता है.	`en_GB`, `de_DE`, `es_ES`, `fr_CA`
`PRODUCT_MANUFACTURER`	मैन्युफ़ैक्चरर का नाम.	`acme`
`PRODUCT_MODEL`	एंड प्रॉडक्ट के लिए, एंड-यूज़र को दिखने वाला नाम.
`PRODUCT_NAME`	यह पूरे प्रॉडक्ट के लिए, उपयोगकर्ता को दिखने वाला नाम होता है. यह सेटिंग > जानकारी स्क्रीन पर दिखता है.
`PRODUCT_OTA_PUBLIC_KEYS`	प्रॉडक्ट के लिए, ओवर-द-एयर (ओटीए) की सार्वजनिक कुंजियों की सूची.
`PRODUCT_PACKAGES`	इंस्टॉल किए जाने वाले APK और मॉड्यूल की सूची.	कैलेंडर में मौजूद संपर्क
`PRODUCT_PACKAGE_OVERLAYS`	इससे पता चलता है कि डिफ़ॉल्ट संसाधनों का इस्तेमाल करना है या प्रॉडक्ट के हिसाब से कोई ओवरले जोड़ना है.	`vendor/acme/overlay`
`PRODUCT_SYSTEM_PROPERTIES`	सिस्टम प्रॉपर्टी असाइनमेंट की सूची, `"key=value"` फ़ॉर्मैट में सिस्टम पार्टीशन के लिए. अन्य पार्टीशन के लिए सिस्टम प्रॉपर्टी, `PRODUCT_<PARTITION>_PROPERTIES` के ज़रिए सेट की जा सकती हैं. जैसे, वेंडर पार्टीशन के लिए `PRODUCT_VENDOR_PROPERTIES`. इस्तेमाल किए जा सकने वाले पार्टीशन के नाम: `SYSTEM`, `VENDOR`, `ODM`, `SYSTEM_EXT`, और `PRODUCT`.

सिस्टम की डिफ़ॉल्ट भाषा और स्थान-भाषा फ़िल्टर को कॉन्फ़िगर करना

इस जानकारी का इस्तेमाल करके, डिफ़ॉल्ट भाषा और सिस्टम के स्थान-भाषा फ़िल्टर को कॉन्फ़िगर करें. इसके बाद, नए डिवाइस टाइप के लिए स्थान-भाषा फ़िल्टर चालू करें.

प्रॉपर्टी

सिस्टम की खास प्रॉपर्टी का इस्तेमाल करके, डिफ़ॉल्ट भाषा और सिस्टम की स्थान-भाषा के फ़िल्टर, दोनों को कॉन्फ़िगर करें:

ro.product.locale: इसका इस्तेमाल डिफ़ॉल्ट स्थान-भाषा सेट करने के लिए किया जाता है. शुरुआत में, इसे PRODUCT_LOCALES वैरिएबल में मौजूद पहले स्थान-भाषा के हिसाब से सेट किया जाता है. हालांकि, इस वैल्यू को बदला जा सकता है. (ज़्यादा जानकारी के लिए, प्रॉडक्ट की परिभाषा वाले वैरिएबल सेट करना टेबल देखें.)
ro.localization.locale_filter: इसका इस्तेमाल, स्थान-भाषा के हिसाब से फ़िल्टर सेट करने के लिए किया जाता है. इसके लिए, स्थान-भाषा के नामों पर लागू किया गया रेगुलर एक्सप्रेशन इस्तेमाल किया जाता है. उदाहरण के लिए:
- शामिल करने वाला फ़िल्टर: ^(de-AT|de-DE|en|uk).* - इससे सिर्फ़ जर्मन (ऑस्ट्रिया और जर्मनी के वैरिएंट), अंग्रेज़ी के सभी वैरिएंट, और यूक्रेनियन भाषा को शामिल किया जा सकता है
- एक्सक्लूसिव फ़िल्टर: ^(?!de-IT|es).* - इसमें जर्मन (इटली वैरिएंट) और स्पैनिश के सभी वैरिएंट शामिल नहीं हैं.

स्थानीय भाषा के फ़िल्टर को चालू करना

फ़िल्टर चालू करने के लिए, ro.localization.locale_filter सिस्टम प्रॉपर्टी की स्ट्रिंग वैल्यू सेट करें.

फ़ैक्ट्री कैलिब्रेशन के दौरान, oem/oem.prop के ज़रिए फ़िल्टर प्रॉपर्टी की वैल्यू और डिफ़ॉल्ट भाषा सेट करके, पाबंदियां कॉन्फ़िगर की जा सकती हैं. इसके लिए, फ़िल्टर को सिस्टम इमेज में शामिल करने की ज़रूरत नहीं होती. यह पक्का करें कि इन प्रॉपर्टी को ओईएम पार्टीशन से चुना गया हो. इसके लिए, उन्हें PRODUCT_OEM_PROPERTIES वैरिएबल में जोड़ें. ऐसा नीचे दिए गए तरीके से करें:

# Delegation for OEM customization
PRODUCT_OEM_PROPERTIES += \
    ro.product.locale \
    ro.localization.locale_filter

इसके बाद, प्रोडक्शन में टारगेट की ज़रूरी शर्तों को पूरा करने के लिए, oem/oem.prop में असल वैल्यू लिखी जाती हैं. इस तरीके से, फ़ैक्ट्री रीसेट के दौरान डिफ़ॉल्ट वैल्यू बनी रहती हैं. इसलिए, शुरुआती सेटिंग उपयोगकर्ता को पहली बार सेट अप करने जैसी दिखती हैं.

यूएसबी से कनेक्ट करने के लिए, ADB_VENDOR_KEYS सेट करें

ADB_VENDOR_KEYS एनवायरमेंट वैरिएबल की मदद से, डिवाइस बनाने वाली कंपनियां, adb पर डीबग किए जा सकने वाले बिल्ड (-userdebug और -eng, लेकिन -user नहीं) को ऐक्सेस कर सकती हैं. इसके लिए, उन्हें मैन्युअल तरीके से अनुमति लेने की ज़रूरत नहीं होती. आम तौर पर, adb हर क्लाइंट कंप्यूटर के लिए एक यूनीक आरएसए पुष्टि करने वाली कुंजी जनरेट करता है. यह कुंजी, कनेक्ट किए गए किसी भी डिवाइस को भेजी जाएगी. यह आरएसए कुंजी है, जो adb ऑथराइज़ेशन डायलॉग में दिखती है. इसके अलावा, सिस्टम इमेज में जाने-पहचाने पासकोड बनाए जा सकते हैं और उन्हें adb क्लाइंट के साथ शेयर किया जा सकता है. यह ओएस डेवलपमेंट और खास तौर पर टेस्टिंग के लिए फ़ायदेमंद है. ऐसा इसलिए, क्योंकि इससे adb ऑथराइज़ेशन डायलॉग के साथ मैन्युअल तरीके से इंटरैक्ट करने की ज़रूरत नहीं पड़ती.

वेंडर की कुंजियां बनाने के लिए, किसी एक व्यक्ति (आम तौर पर रिलीज़ मैनेजर) को यह काम करना चाहिए:

adb keygen का इस्तेमाल करके, कुंजी का जोड़ा जनरेट करें. Google डिवाइसों के लिए, Google हर नए ओएस वर्शन के लिए नया कुंजी जोड़ा जनरेट करता है.
सोर्स ट्री में कहीं भी मौजूद कुंजी जोड़े की जांच करें. Google इन्हें vendor/google/security/adb/ में सेव करता है. उदाहरण के लिए.
बिल्ड वैरिएबल PRODUCT_ADB_KEYS को अपनी कुंजी वाली डायरेक्ट्री पर सेट करें. Google, मुख्य डायरेक्ट्री में Android.mk फ़ाइल जोड़कर ऐसा करता है. इस फ़ाइल में PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub लिखा होता है. इससे यह पक्का करने में मदद मिलती है कि हम हर ओएस वर्शन के लिए, नया पासकोड पेयर जनरेट करना न भूलें.

यहां उस डायरेक्ट्री में Google इस्तेमाल की जाने वाली मेकफ़ाइल दी गई है जहां हम हर रिलीज़ के लिए, चेक-इन किए गए कुंजी जोड़े सेव करते हैं:

PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub

ifeq ($(wildcard $(PRODUCT_ADB_KEYS)),)
  $(warning ========================)
  $(warning The adb key for this release)
  $(warning )
  $(warning   $(PRODUCT_ADB_KEYS))
  $(warning )
  $(warning does not exist. Most likely PLATFORM_VERSION in build/core/version_defaults.mk)
  $(warning has changed and a new adb key needs to be generated.)
  $(warning )
  $(warning Please run the following commands to create a new key:)
  $(warning )
  $(warning   make -j8 adb)
  $(warning   LOGNAME=android-eng HOSTNAME=google.com adb keygen $(patsubst %.pub,%,$(PRODUCT_ADB_KEYS)))
  $(warning )
  $(warning and upload/review/submit the changes)
  $(warning ========================)
  $(error done)
endif

इन वेंडर कुंजियों का इस्तेमाल करने के लिए, इंजीनियर को सिर्फ़ ADB_VENDOR_KEYS एनवायरमेंट वैरिएबल सेट करना होता है. इससे उस डायरेक्ट्री का पता चलता है जिसमें कुंजी जोड़े सेव किए जाते हैं. इससे adb को यह पता चलता है कि जनरेट की गई होस्ट कुंजी का इस्तेमाल करने से पहले, इन कैननिकल कुंजियों का इस्तेमाल किया जाना चाहिए. जनरेट की गई होस्ट कुंजी के लिए, मैन्युअल तरीके से अनुमति देना ज़रूरी होता है. जब adb किसी ऐसे डिवाइस से कनेक्ट नहीं हो पाता है जिसे अनुमति नहीं मिली है, तो गड़बड़ी के मैसेज में आपको ADB_VENDOR_KEYS सेट करने का सुझाव दिया जाएगा. ऐसा तब होगा, जब ADB_VENDOR_KEYS पहले से सेट न हो.