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

एक नया उपकरण जोड़ना

अपने डिवाइस और उत्पाद के लिए मेकफ़ाइल बनाने के लिए इस पृष्ठ की जानकारी का उपयोग करें।

प्रत्येक नए एंड्रॉइड मॉड्यूल में मॉड्यूल मेटाडेटा, संकलन-समय निर्भरता और पैकेजिंग निर्देशों के साथ बिल्ड सिस्टम को निर्देशित करने के लिए एक कॉन्फ़िगरेशन फ़ाइल होनी चाहिए। एंड्रॉइड सूंग बिल्ड सिस्टम का उपयोग करता है। Android बिल्ड सिस्टम के बारे में अधिक जानकारी के लिए Android का निर्माण देखें।

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

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

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

बिल्ड वेरिएंट का उपयोग करना

किसी विशेष उत्पाद के लिए निर्माण करते समय, अंतिम रिलीज़ बिल्ड पर मामूली बदलाव करना उपयोगी होता है। मॉड्यूल परिभाषा में, मॉड्यूल 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 को रूट एक्सेस सक्षम के साथ उपयोगकर्ता बिल्ड के रूप में परिभाषित किया गया है, सिवाय इसके:
- उपयोगकर्ताडिबग-केवल ऐप जो उपयोगकर्ता द्वारा केवल ऑन-डिमांड चलाए जाते हैं
- संचालन जो केवल निष्क्रिय रखरखाव (चार्जर/पूरी तरह चार्ज होने पर) के दौरान चलते हैं, जैसे पृष्ठभूमि संकलन के लिए dex2oatd बनाम dex2oat का उपयोग करना
उन सुविधाओं को शामिल न करें जो बिल्ड प्रकार के आधार पर डिफ़ॉल्ट रूप से सक्षम/अक्षम हैं। डिबग लॉगिंग या हीप डंपिंग जैसे बैटरी जीवन को प्रभावित करने वाले लॉगिंग के किसी भी रूप का उपयोग करने से डेवलपर्स को हतोत्साहित किया जाता है।
उपयोगकर्ता डिबग में डिफ़ॉल्ट रूप से सक्षम किसी भी डिबगिंग सुविधाओं को स्पष्ट रूप से परिभाषित किया जाना चाहिए और परियोजना पर काम कर रहे सभी डेवलपर्स के साथ साझा किया जाना चाहिए। जब तक आप जिस समस्या को डीबग करने का प्रयास कर रहे हैं, उसका समाधान नहीं हो जाता, तब तक आपको केवल सीमित समय के आधार पर डिबगिंग सुविधाओं को सक्षम करना चाहिए।

संसाधन ओवरले के साथ निर्माण को अनुकूलित करना

एंड्रॉइड बिल्ड सिस्टम किसी उत्पाद को निर्माण समय पर अनुकूलित करने के लिए संसाधन ओवरले का उपयोग करता है। संसाधन ओवरले उन संसाधन फ़ाइलों को निर्दिष्ट करते हैं जो डिफ़ॉल्ट के शीर्ष पर लागू होती हैं। संसाधन ओवरले का उपयोग करने के लिए, अपनी शीर्ष-स्तरीय निर्देशिका से संबंधित पथ पर 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 फ़ाइल में पाया गया कोई भी स्ट्रिंग या स्ट्रिंग सरणी मूल फ़ाइल में पाए गए लोगों को प्रतिस्थापित करता है।

उत्पाद का निर्माण

आप अपने डिवाइस के लिए स्रोत फ़ाइलों को कई अलग-अलग तरीकों से व्यवस्थित कर सकते हैं। यहां पिक्सेल कार्यान्वयन को व्यवस्थित करने के एक तरीके का संक्षिप्त विवरण दिया गया है।

पिक्सेल को marlin नामक एक मुख्य डिवाइस कॉन्फ़िगरेशन के साथ कार्यान्वित किया जाता है। इस डिवाइस कॉन्फ़िगरेशन से, उत्पाद परिभाषा मेकफ़ाइल के साथ एक उत्पाद बनाया जाता है जो डिवाइस के बारे में उत्पाद-विशिष्ट जानकारी जैसे नाम और मॉडल की घोषणा करता है। यह सब कैसे सेट किया जाता है यह देखने के लिए आप device/google/marlin निर्देशिका देख सकते हैं।

उत्पाद मेकफ़ाइल लिखना

निम्न चरण वर्णन करते हैं कि उत्पाद मेकफ़ाइल को पिक्सेल उत्पाद लाइन के समान कैसे सेट किया जाए:

अपने उत्पाद के लिए एक 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 से है (जिसमें मार्लिन, पिक्सेल और सेलफ़िश दोनों शामिल हैं, पिक्सेल 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`	दो-अक्षर वाले भाषा कोड, दो-अक्षर वाले देश कोड युग्मों की एक स्थान-पृथक सूची जो उपयोगकर्ता के लिए कई सेटिंग्स का वर्णन करती है, जैसे कि UI भाषा और समय, दिनांक और मुद्रा स्वरूपण। `PRODUCT_LOCALES` में सूचीबद्ध पहले स्थान का उपयोग उत्पाद के डिफ़ॉल्ट स्थान के रूप में किया जाता है।	`en_GB` , `de_DE` , `es_ES` , `fr_CA`
`PRODUCT_MANUFACTURER`	निर्माता का नाम।	`acme`
`PRODUCT_MODEL`	अंतिम उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम।
`PRODUCT_NAME`	संपूर्ण उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम। सेटिंग्स> स्क्रीन के बारे में दिखाई देता है।
`PRODUCT_OTA_PUBLIC_KEYS`	उत्पाद के लिए ओवर-द-एयर (OTA) सार्वजनिक कुंजियों की सूची।
`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 चर में जोड़कर OEM विभाजन से उठाया गया है जैसा कि नीचे दर्शाया गया है:

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

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

USB से कनेक्ट करने के लिए ADB_VENDOR_KEYS सेट करना

ADB_VENDOR_KEYS पर्यावरण चर डिवाइस निर्माताओं को मैन्युअल प्राधिकरण के बिना adb पर डिबग करने योग्य बिल्ड (-userdebug और -eng, लेकिन नहीं -user) तक पहुंचने में सक्षम बनाता है। आम तौर पर एडीबी प्रत्येक क्लाइंट कंप्यूटर के लिए एक अद्वितीय आरएसए प्रमाणीकरण कुंजी उत्पन्न करता है, जिसे वह किसी भी कनेक्टेड डिवाइस पर भेजेगा। यह एडीबी प्राधिकरण संवाद में दिखाई गई आरएसए कुंजी है। एक विकल्प के रूप में आप सिस्टम छवि में ज्ञात कुंजी बना सकते हैं और उन्हें एडीबी क्लाइंट के साथ साझा कर सकते हैं। यह ओएस विकास के लिए और विशेष रूप से परीक्षण के लिए उपयोगी है क्योंकि यह एडीबी प्राधिकरण संवाद के साथ मैन्युअल रूप से बातचीत करने की आवश्यकता से बचाता है।

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

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

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 सेट किया है, यदि यह पहले से सेट नहीं है।