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

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

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

ทำความเข้าใจกับเลเยอร์บิวด์

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

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

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

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

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

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

  4. สร้างไฟล์ AndroidProducts.mk ที่ชี้ไปยัง makefiles ของผลิตภัณฑ์ ในตัวอย่างนี้ จำเป็นต้องใช้เฉพาะ makefile คำจำกัดความของผลิตภัณฑ์เท่านั้น ตัวอย่างด้านล่างมาจาก device/google/marlin/AndroidProducts.mk (ซึ่งมีทั้ง marlin, 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 configurations เพื่อใช้เมื่อสร้างแพ็คเกจ
PRODUCT_BRAND แบรนด์ (เช่น ผู้ให้บริการ) ที่ได้รับการปรับแต่งซอฟต์แวร์ให้
PRODUCT_CHARACTERISTICS aapt คุณลักษณะเพื่อให้สามารถเพิ่มทรัพยากรเฉพาะตัวแปรลงในแพ็คเกจได้ tablet , nosdcard
PRODUCT_COPY_FILES รายการคำเช่น source_path:destination_path ไฟล์ที่เส้นทางต้นทางควรถูกคัดลอกไปยังเส้นทางปลายทางเมื่อสร้างผลิตภัณฑ์นี้ กฎสำหรับขั้นตอนการคัดลอกถูกกำหนดไว้ใน config/makefile
PRODUCT_DEVICE ชื่อของการออกแบบอุตสาหกรรม นี่คือชื่อบอร์ดด้วย และระบบบิลด์ใช้ชื่อนี้เพื่อค้นหา BoardConfig.mk tuna
PRODUCT_LOCALES รายการรหัสภาษา 2 ตัวอักษรที่คั่นด้วยช่องว่าง คู่รหัสประเทศ 2 ตัวอักษรที่อธิบายการตั้งค่าต่างๆ สำหรับผู้ใช้ เช่น ภาษา 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 หากยังไม่ได้ตั้งค่า