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

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

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

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

बिल्ड लेयर को समझना

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

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

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

किसी प्रॉडक्ट को बनाते समय, उस सामान का छोटी होना ज़रूरी है जिनमें फ़ाइनल रिलीज़ बिल्ड के अलग-अलग वर्शन शामिल हैं. मॉड्यूल में परिभाषा, मॉड्यूल 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`, डिफ़ॉल्ट रूप से चालू होती है.

उपयोगकर्ता डीबग के लिए दिशा-निर्देश

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

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

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

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 देखें.
डिवाइस के हिसाब से किसी खास प्रॉडक्ट को बनाने के लिए, प्रॉडक्ट डेफ़िनिशन फ़ाइल बनाएं. कॉन्टेंट बनाने नीचे दी गई Makefile को 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 फ़ाइल बनाएं. तय सीमा में इस उदाहरण में, सिर्फ़ प्रॉडक्ट की परिभाषा Makefile की ज़रूरत है. नीचे दिया गया उदाहरण device/google/marlin/AndroidProducts.mk (जिसमें मार्लिन और Pixel, दोनों शामिल हैं, और सेलफ़िश, 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 फ़ाइल बनाएं जिसमें बोर्ड से जुड़े कॉन्फ़िगरेशन हों. उदाहरण के लिए, 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 और मॉड्यूल की सूची.	Calendar के संपर्क
`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 में लिखा जाता है ज़रूरतें. इस तरीके से, फ़ैक्ट्री रीसेट के दौरान डिफ़ॉल्ट वैल्यू बनी रहती हैं, इसलिए शुरुआती सेटिंग, उपयोगकर्ता को पहले सेटअप जैसी ही दिखती हैं.

USB पर कनेक्ट करने के लिए ADB_ शेयर करने के लिए ADB_ शेयर की जाने वाली_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 को सेट करने का सुझाव दिया जाएगा. अगर ऐसा नहीं है, तो पहले से सेट है.