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

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

ध्यान दें: यह जानकारी केवल एक नया डिवाइस प्रकार बनाने पर लागू होती है और विशेष रूप से कंपनी निर्माण और उत्पाद टीमों के लिए है।

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

निर्माण परतों को समझना

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

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

यूजरडिबग के लिए दिशानिर्देश

परीक्षण में यूजरडीबग बिल्ड चलाने से डिवाइस डेवलपर्स को इन-डेवलपमेंट रिलीज के प्रदर्शन और शक्ति को समझने में मदद मिलती है। उपयोगकर्ता और उपयोगकर्ताडीबग बिल्ड के बीच स्थिरता बनाए रखने के लिए, और डिबगिंग के लिए उपयोग किए जाने वाले बिल्ड में विश्वसनीय मेट्रिक्स प्राप्त करने के लिए, डिवाइस डेवलपर्स को इन दिशानिर्देशों का पालन करना चाहिए:

• यूजरडिबग को रूट एक्सेस सक्षम उपयोगकर्ता बिल्ड के रूप में परिभाषित किया गया है, सिवाय इसके:
  • यूजरडिबग-ओनली ऐप्स जो केवल उपयोगकर्ता द्वारा ऑन-डिमांड चलाए जाते हैं
  • संचालन जो केवल निष्क्रिय रखरखाव (चार्जर/पूरी तरह से चार्ज होने पर) के दौरान चलते हैं, जैसे पृष्ठभूमि संकलन के लिए 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 निर्देशिका देख सकते हैं।

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

निम्नलिखित चरण बताते हैं कि पिक्सेल उत्पाद लाइन के समान उत्पाद मेकफ़ाइल कैसे सेट करें:

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

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

4. एक 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
   

5. एक BoardConfig.mk मेकफ़ाइल बनाएं जिसमें बोर्ड-विशिष्ट कॉन्फ़िगरेशन शामिल हों। उदाहरण के लिए, 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	दो-अक्षर वाले भाषा कोड, दो-अक्षर वाले देश कोड जोड़े की एक स्थान-पृथक सूची जो उपयोगकर्ता के लिए कई सेटिंग्स का वर्णन करती है, जैसे यूआई भाषा और समय, दिनांक और मुद्रा स्वरूपण। PRODUCT_LOCALES में सूचीबद्ध पहला लोकेल उत्पाद के डिफ़ॉल्ट लोकेल के रूप में उपयोग किया जाता है।	en_GB , de_DE , es_ES , fr_CA
PRODUCT_MANUFACTURER	निर्माता का नाम.	acme
PRODUCT_MODEL	अंतिम उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम।
PRODUCT_NAME	समग्र उत्पाद के लिए अंतिम-उपयोगकर्ता-दृश्यमान नाम। सेटिंग्स > अबाउट स्क्रीन में दिखाई देता है।
PRODUCT_OTA_PUBLIC_KEYS	उत्पाद के लिए ओवर-द-एयर (OTA) सार्वजनिक कुंजियों की सूची।
PRODUCT_PACKAGES	इंस्टॉल करने के लिए एपीके और मॉड्यूल की सूची।	कैलेंडर संपर्क
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 पर्यावरण चर डिवाइस निर्माताओं को मैन्युअल प्राधिकरण के बिना एडीबी पर डिबग करने योग्य बिल्ड (-userdebug और -eng, लेकिन -user नहीं) तक पहुंचने में सक्षम बनाता है। आम तौर पर एडीबी प्रत्येक क्लाइंट कंप्यूटर के लिए एक अद्वितीय आरएसए प्रमाणीकरण कुंजी उत्पन्न करता है, जिसे वह किसी भी कनेक्टेड डिवाइस पर भेजेगा। यह एडीबी प्राधिकरण संवाद में दिखाई गई आरएसए कुंजी है। एक विकल्प के रूप में आप सिस्टम छवि में ज्ञात कुंजी बना सकते हैं और उन्हें एडीबी क्लाइंट के साथ साझा कर सकते हैं। यह ओएस विकास और विशेष रूप से परीक्षण के लिए उपयोगी है क्योंकि यह एडीबी प्राधिकरण संवाद के साथ मैन्युअल रूप से बातचीत करने की आवश्यकता से बचाता है।

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

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