हमारा सुझाव है कि 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	प्रॉडक्ट लेयर, शिपिंग प्रॉडक्ट की सुविधाओं की खास बातों के बारे में बताती है. जैसे, बनाने के लिए मॉड्यूल, काम करने वाली भाषाएं, और अलग-अलग भाषाओं के लिए कॉन्फ़िगरेशन. दूसरे शब्दों में, यह पूरे प्रॉडक्ट का नाम होता है. प्रॉडक्ट के हिसाब से वैरिएबल तय करने के लिए, प्रॉडक्ट की परिभाषा वाली मेकफ़ाइल का इस्तेमाल किया जाता है. किसी प्रॉडक्ट को अन्य प्रॉडक्ट की परिभाषाओं से इनहेरिट किया जा सकता है. इससे, प्रॉडक्ट को मैनेज करना आसान हो जाता है. आम तौर पर, ऐसा करने के लिए एक बुनियादी प्रॉडक्ट बनाया जाता है. इसमें सभी प्रॉडक्ट पर लागू होने वाली सुविधाएं होती हैं. इसके बाद, उस बुनियादी प्रॉडक्ट के आधार पर प्रॉडक्ट के वैरिएंट बनाए जाते हैं. उदाहरण के लिए, दो प्रॉडक्ट के रेडियो (CDMA बनाम GSM) में सिर्फ़ अंतर होने पर, वे उस बेस प्रॉडक्ट से इनहेरिट हो सकते हैं जिसमें रेडियो की जानकारी नहीं दी गई है.
बोर्ड/डिवाइस	मार्लिन, ब्लूलाइन, कोरल	बोर्ड/डिवाइस लेयर, डिवाइस पर मौजूद प्लास्टिक की फ़िज़िकल लेयर को दिखाती है. यह लेयर, किसी प्रॉडक्ट के स्कीमैटिक्स को भी दिखाती है. इनमें बोर्ड पर मौजूद पेरिफ़रल और उनके कॉन्फ़िगरेशन शामिल हैं. इस्तेमाल किए गए नाम, अलग-अलग बोर्ड/डिवाइस के कॉन्फ़िगरेशन के लिए सिर्फ़ कोड हैं.
आर्क	arm, x86, arm64, 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` डिफ़ॉल्ट रूप से चालू होता है.

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

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

userdebug को ऐसे उपयोगकर्ता के लिए बने बिल्ड के तौर पर परिभाषित किया गया है जिसके पास रूट ऐक्सेस चालू है. हालांकि, इसमें ये शामिल नहीं हैं:
- सिर्फ़ userdebug मोड में काम करने वाले ऐसे ऐप्लिकेशन जिन्हें उपयोगकर्ता सिर्फ़ मांग पर चलाता है
- ऐसे ऑपरेशन जो सिर्फ़ डिवाइस के चार्ज होने या चार्ज किए जाने के दौरान चलते हैं. जैसे, बैकग्राउंड में कॉम्पाइल करने के लिए 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 makefile बनाएं, जिसमें डिवाइस के लिए ज़रूरी फ़ाइलों और मॉड्यूल के बारे में जानकारी हो. उदाहरण के लिए, device/google/marlin/device-marlin.mk देखें.
डिवाइस के हिसाब से कोई खास प्रॉडक्ट बनाने के लिए, प्रॉडक्ट डेफ़िनिशन मेकफ़ाइल बनाएं. यहां दी गई makefile, उदाहरण के तौर पर device/google/marlin/aosp_marlin.mk से ली गई है. ध्यान दें कि प्रॉडक्ट, makefile की मदद से 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 मेकफ़ाइल बनाएं. उदाहरण के लिए, 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_VENDOR_PROPERTIES` की तरह ही `PRODUCT_<PARTITION>_PROPERTIES` के ज़रिए सेट की जा सकती हैं. इस्तेमाल किए जा सकने वाले partition के नाम: `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 में असल वैल्यू लिखी जाती हैं, ताकि टारगेट की ज़रूरी शर्तों को दिखाया जा सके. इस तरीके से, फ़ैक्ट्री रीसेट के दौरान डिफ़ॉल्ट वैल्यू बरकरार रहती हैं. इसलिए, उपयोगकर्ता को शुरुआती सेटिंग, पहली बार सेट अप करने जैसी ही दिखती हैं.

यूएसबी से कनेक्ट करने के लिए, 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 लिखा होता है. इससे यह पक्का करने में मदद मिलती है कि हम हर 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 सेट करने का सुझाव देगा. ऐसा तब होगा, जब ADB_VENDOR_KEYS पहले से सेट न हो.