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

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

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

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

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

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

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

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

सबसे अधिक कस्टमाइज़ की गई सेटिंग फ़ाइल में निहित हैं चौखटे / आधार / कोर / 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 निर्देशिका देखना चाहते हैं कि इस सब की स्थापना की है।

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

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

  1. एक बनाएं device/ <company-name> / <device-name> अपने उत्पाद के लिए निर्देशिका। उदाहरण के लिए, device/google/marlin । इस निर्देशिका में आपके डिवाइस के लिए मेकफ़ाइल के साथ उन्हें बनाने के लिए स्रोत कोड होगा।
  2. एक बनाएं device.mk makefile कि फ़ाइलें और मॉड्यूल डिवाइस के लिए आवश्यक की घोषणा की। एक उदाहरण के लिए, देखें device/google/marlin/device-marlin.mk
  3. डिवाइस के आधार पर एक विशिष्ट उत्पाद बनाने के लिए उत्पाद परिभाषा मेकफ़ाइल बनाएं। निम्नलिखित makefile से लिया जाता है device/google/marlin/aosp_marlin.mk एक उदाहरण के रूप। सूचना है कि से उत्पाद inherits device/google/marlin/device-marlin.mk और vendor/google/marlin/device-vendor-marlin.mk makefile करते हुए भी जैसे कि नाम, ब्रांड के रूप में उत्पाद-विशिष्ट जानकारी की घोषणा के माध्यम से फ़ाइलें, और मॉडल।
    # 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
    

    देखें उत्पाद परिभाषा चर सेट करना है कि आप अपने makefiles को जोड़ सकते हैं अतिरिक्त उत्पाद-विशिष्ट चर के लिए।

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

उत्पाद परिभाषा चर सेट करना

उत्पाद-विशिष्ट चर उत्पाद के मेकफ़ाइल में परिभाषित किए गए हैं। तालिका उत्पाद परिभाषा फ़ाइल में बनाए गए कुछ चर दिखाती है।

चर विवरण उदाहरण
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 कारखाने कैलिब्रेशन के दौरान आप सिस्टम छवि में फिल्टर पाक के बिना प्रतिबंध कॉन्फ़िगर कर सकते हैं। आप यह सुनिश्चित करें कि इन गुणों OEM विभाजन से उठाया जाता है शामिल करके उन्हें PRODUCT_OEM_PROPERTIES चर के रूप में नीचे दिया गया:

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

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

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

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

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

  1. का उपयोग कर एक कुंजी युग्म उत्पन्न adb keygen । Google उपकरणों के लिए, Google प्रत्येक नए OS संस्करण के लिए एक नई कुंजी जोड़ी बनाता है।
  2. स्रोत ट्री में कहीं न कहीं प्रमुख युग्मों की जाँच करें। में गूगल भंडार उन्हें vendor/google/security/adb/ , उदाहरण के लिए।
  3. निर्माण चर सेट PRODUCT_ADB_KEYS अपने प्रमुख निर्देशिका के लिए बात करने के लिए। गूगल एक जोड़कर इस करता 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 यदि वह पहले से स्थापित नहीं किया गया।