การเพิ่มอุปกรณ์ใหม่

ใช้ข้อมูลในหน้านี้เพื่อสร้าง makefiles สำหรับอุปกรณ์และผลิตภัณฑ์ของคุณ

หมายเหตุ: ข้อมูลนี้ใช้กับการสร้างอุปกรณ์ประเภทใหม่เท่านั้นและมีไว้สำหรับการสร้างบริษัทและทีมผลิตภัณฑ์โดยเฉพาะ

โมดูล Android ใหม่แต่ละโมดูลต้องมีไฟล์การกำหนดค่าเพื่อกำหนดทิศทางระบบบิลด์ด้วยข้อมูลเมตาของโมดูล การขึ้นต่อกันเวลาคอมไพล์ และคำแนะนำในการบรรจุภัณฑ์ Android ใช้ ระบบสร้าง Soong ดูการ สร้าง Android สำหรับข้อมูลเพิ่มเติมเกี่ยวกับระบบสร้าง Android

ทำความเข้าใจการสร้างเลเยอร์

ลำดับชั้นของบิลด์ประกอบด้วยเลเยอร์นามธรรมที่สอดคล้องกับลักษณะทางกายภาพของอุปกรณ์ เลเยอร์เหล่านี้อธิบายไว้ในตารางด้านล่าง แต่ละชั้นเกี่ยวข้องกับชั้นที่อยู่ด้านบนในความสัมพันธ์แบบหนึ่งต่อกลุ่ม ตัวอย่างเช่น สถาปัตยกรรมสามารถมีได้มากกว่าหนึ่งบอร์ด และแต่ละบอร์ดสามารถมีได้มากกว่าหนึ่งผลิตภัณฑ์ คุณอาจกำหนดองค์ประกอบในเลเยอร์ที่กำหนดเป็นความเชี่ยวชาญพิเศษขององค์ประกอบในเลเยอร์เดียวกัน ซึ่งจะช่วยลดการคัดลอกและทำให้การบำรุงรักษาง่ายขึ้น

ชั้น	ตัวอย่าง	คำอธิบาย
ผลิตภัณฑ์	myProduct, myProduct_eu, myProduct_eu_fr, j2, sdk	เลเยอร์ผลิตภัณฑ์กำหนดข้อกำหนดคุณลักษณะของผลิตภัณฑ์ที่จัดส่ง เช่น โมดูลที่จะสร้าง สถานที่ที่รองรับ และการกำหนดค่าสำหรับสถานที่ต่างๆ กล่าวคือ นี่คือ ชื่อ ของผลิตภัณฑ์โดยรวม ตัวแปรเฉพาะผลิตภัณฑ์ถูกกำหนดไว้ใน makefile คำจำกัดความของผลิตภัณฑ์ ผลิตภัณฑ์สามารถสืบทอดมาจากคำจำกัดความของผลิตภัณฑ์อื่นๆ ซึ่งทำให้การบำรุงรักษาง่ายขึ้น วิธีการทั่วไปคือการสร้างผลิตภัณฑ์ฐานที่มีคุณลักษณะที่ใช้กับผลิตภัณฑ์ทั้งหมด จากนั้นจึงสร้างตัวเลือกสินค้าตามผลิตภัณฑ์หลักนั้น ตัวอย่างเช่น ผลิตภัณฑ์สองรายการที่แตกต่างกันโดยวิทยุเท่านั้น (CDMA กับ GSM) สามารถสืบทอดจากผลิตภัณฑ์พื้นฐานเดียวกันที่ไม่ได้กำหนดวิทยุ
บอร์ด/อุปกรณ์	มาร์ลิน บลูไลน์ ปะการัง	ชั้นบอร์ด/อุปกรณ์แสดงถึงชั้นทางกายภาพของพลาสติกบนอุปกรณ์ (นั่นคือ การออกแบบทางอุตสาหกรรมของอุปกรณ์) เลเยอร์นี้ยังแสดงถึงแผนผังเปล่าของผลิตภัณฑ์ ซึ่งรวมถึงอุปกรณ์ต่อพ่วงบนบอร์ดและการกำหนดค่า ชื่อที่ใช้เป็นเพียงรหัสสำหรับการกำหนดค่าบอร์ด/อุปกรณ์ที่แตกต่างกัน
โค้ง	อาร์ม, x86, อาร์ม64, x86_64	เลเยอร์สถาปัตยกรรมอธิบายการกำหนดค่าโปรเซสเซอร์และ Application Binary Interface (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

การรัน userdebug builds ในการทดสอบช่วยให้นักพัฒนาอุปกรณ์เข้าใจประสิทธิภาพและพลังของรุ่นที่กำลังพัฒนา เพื่อรักษาความสอดคล้องระหว่างบิลด์ผู้ใช้และผู้ใช้ดีบัก และเพื่อให้ได้ตัววัดที่เชื่อถือได้ในบิลด์ที่ใช้สำหรับการดีบัก ผู้พัฒนาอุปกรณ์ควรปฏิบัติตามหลักเกณฑ์เหล่านี้:

• userdebug ถูกกำหนดให้เป็นบิลด์ผู้ใช้ที่เปิดใช้งานการเข้าถึงรูท ยกเว้น:
  • แอพ userdebug เท่านั้นที่รันตามความต้องการโดยผู้ใช้เท่านั้น
  • การทำงานที่ทำงานเฉพาะระหว่างการบำรุงรักษาที่ไม่ได้ใช้งาน (ในเครื่องชาร์จ/ชาร์จเต็ม) เช่น การใช้ dex2oatd กับ dex2oat สำหรับการคอมไพล์พื้นหลัง
• อย่ารวมคุณลักษณะที่เปิดใช้งาน/ปิดใช้งานโดยค่าเริ่มต้นตามประเภทบิลด์ นักพัฒนาซอฟต์แวร์ไม่แนะนำให้ใช้การบันทึกรูปแบบใดๆ ที่ส่งผลต่ออายุการใช้งานแบตเตอรี่ เช่น การบันทึกการแก้ไขข้อบกพร่องหรือการทิ้งฮีพ
• คุณลักษณะการดีบักใดๆ ที่เปิดใช้งานโดยค่าเริ่มต้นใน userdebug ควรกำหนดไว้อย่างชัดเจนและแชร์กับนักพัฒนาทุกคนที่ทำงานในโปรเจ็กต์ คุณควรเปิดใช้งานคุณลักษณะการดีบักในช่วงเวลาจำกัดเท่านั้น จนกว่าปัญหาที่คุณพยายามแก้ไขจุดบกพร่องจะได้รับการแก้ไข

การปรับแต่งบิลด์ด้วยการซ้อนทับทรัพยากร

ระบบบิลด์ Android ใช้การซ้อนทับทรัพยากรเพื่อปรับแต่งผลิตภัณฑ์ ณ เวลาสร้าง โอเวอร์เลย์ทรัพยากรระบุไฟล์ทรัพยากรที่ใช้บนค่าเริ่มต้น ในการใช้การซ้อนทับทรัพยากร ให้แก้ไข buildfile ของโปรเจ็กต์เพื่อตั้งค่า PRODUCT_PACKAGE_OVERLAYS เป็นพาธที่สัมพันธ์กับไดเร็กทอรีระดับบนสุดของคุณ เส้นทางนั้นจะกลายเป็นเงารูทที่ค้นหาพร้อมกับรูทปัจจุบันเมื่อระบบบิลด์ค้นหาทรัพยากร

ค่าติดตั้งที่ปรับแต่งเองโดยทั่วไปมีอยู่ในไฟล์ frameworks/base/core/res/res/values/config.xml

หากต้องการตั้งค่าโอเวอร์เลย์ทรัพยากรในไฟล์นี้ ให้เพิ่มไดเร็กทอรีโอเวอร์เลย์ไปที่ไฟล์ build ของโปรเจ็กต์โดยใช้ตัวเลือกใดวิธีหนึ่งต่อไปนี้:

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 จากการกำหนดค่าอุปกรณ์นี้ ผลิตภัณฑ์จะถูกสร้างขึ้นด้วย makefile ข้อกำหนดผลิตภัณฑ์ที่ประกาศข้อมูลเฉพาะผลิตภัณฑ์เกี่ยวกับอุปกรณ์ เช่น ชื่อและรุ่น คุณสามารถดูไดเร็กทอรี device/google/marlin เพื่อดูว่าทั้งหมดนี้ได้รับการตั้งค่าอย่างไร

เขียน makefiles ของผลิตภัณฑ์

ขั้นตอนต่อไปนี้อธิบายวิธีตั้งค่า makefile ของผลิตภัณฑ์ในลักษณะที่คล้ายกับกลุ่มผลิตภัณฑ์ Pixel:

1. สร้างไดเร็กทอรี device/ <company-name> / <device-name> สำหรับผลิตภัณฑ์ของคุณ ตัวอย่างเช่น device/google/marlin ไดเร็กทอรีนี้จะมีซอร์สโค้ดสำหรับอุปกรณ์ของคุณพร้อมกับ makefiles เพื่อสร้างมันขึ้นมา
2. สร้าง device.mk makefile ที่ประกาศไฟล์และโมดูลที่จำเป็นสำหรับอุปกรณ์ ตัวอย่างเช่น โปรดดู device/google/marlin/device-marlin.mk
3. สร้าง makefile ข้อกำหนดผลิตภัณฑ์เพื่อสร้างผลิตภัณฑ์เฉพาะตามอุปกรณ์ makefile ต่อไปนี้นำมาจาก device/google/marlin/aosp_marlin.mk เป็นตัวอย่าง โปรดสังเกตว่าผลิตภัณฑ์สืบทอดจากไฟล์ 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
   

   ดู การตั้งค่าตัวแปรข้อกำหนดผลิตภัณฑ์ สำหรับตัวแปรเฉพาะผลิตภัณฑ์เพิ่มเติมที่คุณสามารถเพิ่มลงใน makefile ของคุณได้

4. สร้างไฟล์ AndroidProducts.mk ที่ชี้ไปที่ makefile ของผลิตภัณฑ์ ในตัวอย่างนี้ จำเป็นต้องใช้ 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
   

5. สร้าง Makefile BoardConfig.mk ที่มีการกำหนดค่าเฉพาะบอร์ด ตัวอย่างเช่น โปรดดู device/google/marlin/BoardConfig.mk
6. สำหรับ Android 9 และต่ำกว่า เท่านั้น ให้ สร้าง ไฟล์ vendorsetup.sh เพื่อเพิ่มผลิตภัณฑ์ของคุณ ("คอมโบอาหารกลางวัน") ลงในบิลด์พร้อมกับตัวเลือกบิวด์ที่คั่นด้วยเครื่องหมายขีด ตัวอย่างเช่น:

   add_lunch_combo <product-name>-userdebug
   

7. ณ จุดนี้ คุณสามารถสร้างตัวเลือกสินค้าเพิ่มเติมตามอุปกรณ์เดียวกันได้

การตั้งค่าตัวแปรคำจำกัดความผลิตภัณฑ์

ตัวแปรเฉพาะผลิตภัณฑ์ถูกกำหนดไว้ใน makefile ของผลิตภัณฑ์ ตารางแสดงตัวแปรบางตัวที่เก็บรักษาไว้ในไฟล์ข้อกำหนดของผลิตภัณฑ์

ตัวแปร	คำอธิบาย	ตัวอย่าง
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	รายการคีย์สาธารณะแบบ over-the-air (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 เพื่อสะท้อนความต้องการเป้าหมาย ด้วยวิธีนี้ ค่าเริ่มต้นจะยังคงอยู่ระหว่างการรีเซ็ตเป็นค่าจากโรงงาน ดังนั้นการตั้งค่าเริ่มต้นจะเหมือนกับการตั้งค่าครั้งแรกสำหรับผู้ใช้

การตั้งค่า ADB_VENDOR_KEYS ให้เชื่อมต่อผ่าน USB

ตัวแปรสภาพแวดล้อม ADB_VENDOR_KEYS ช่วยให้ผู้ผลิตอุปกรณ์สามารถเข้าถึงบิลด์ที่แก้ไขข้อบกพร่องได้ (-userdebug และ -eng แต่ไม่ใช่ -user) ผ่าน adb โดยไม่ต้องให้สิทธิ์ด้วยตนเอง โดยปกติ adb จะสร้างคีย์การรับรองความถูกต้อง RSA ที่ไม่ซ้ำกันสำหรับคอมพิวเตอร์ไคลเอนต์แต่ละเครื่อง ซึ่งจะส่งไปยังอุปกรณ์ที่เชื่อมต่อ นี่คือคีย์ RSA ที่แสดงในกล่องโต้ตอบการให้สิทธิ์ adb คุณสามารถสร้างคีย์ที่รู้จักลงในอิมเมจระบบและแชร์กับไคลเอ็นต์ adb ได้ สิ่งนี้มีประโยชน์สำหรับการพัฒนาระบบปฏิบัติการและโดยเฉพาะอย่างยิ่งสำหรับการทดสอบ เนื่องจากไม่จำเป็นต้องโต้ตอบกับกล่องโต้ตอบการให้สิทธิ์ adb ด้วยตนเอง

ในการสร้างคีย์ผู้จำหน่าย บุคคลหนึ่งคน (โดยปกติคือผู้จัดการรุ่น) ควร:

1. สร้างคู่คีย์โดยใช้ adb keygen สำหรับอุปกรณ์ Google Google จะสร้างคู่คีย์ใหม่สำหรับระบบปฏิบัติการใหม่แต่ละเวอร์ชัน
2. ตรวจสอบคู่คีย์ในที่ใดที่หนึ่งในทรีต้นทาง Google เก็บไว้ใน vendor/google/security/adb/ เป็นต้น
3. ตั้งค่าตัวแปรบิวด์ PRODUCT_ADB_KEYS ให้ชี้ไปที่ไดเร็กทอรีคีย์ของคุณ Google ทำได้โดยการเพิ่มไฟล์ Android.mk ในไดเร็กทอรีคีย์ที่ระบุว่า PRODUCT_ADB_KEYS := $(LOCAL_PATH)/$(PLATFORM_VERSION).adb_key.pub ซึ่งช่วยให้มั่นใจว่าเราอย่าลืมสร้างคู่คีย์ใหม่สำหรับแต่ละเวอร์ชันของระบบปฏิบัติการ

นี่คือ makefile ที่ 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 หากยังไม่ได้ตั้งค่า