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

ใช้ข้อมูลในหน้านี้เพื่อสร้าง 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 สำหรับ compiles พื้นหลัง
  • อย่ารวมคุณลักษณะที่เปิดใช้งาน/ปิดใช้งานโดยค่าเริ่มต้นตามประเภทบิลด์ นักพัฒนาซอฟต์แวร์ไม่แนะนำให้ใช้การบันทึกรูปแบบใดๆ ที่ส่งผลต่ออายุการใช้งานแบตเตอรี่ เช่น การบันทึกการแก้ไขข้อบกพร่องหรือการทิ้งฮีพ
  • คุณลักษณะการดีบักใดๆ ที่เปิดใช้งานโดยค่าเริ่มต้นใน userdebug ควรกำหนดไว้อย่างชัดเจนและแชร์กับนักพัฒนาทุกคนที่ทำงานในโปรเจ็กต์ คุณควรเปิดใช้งานคุณลักษณะการดีบักในช่วงเวลาจำกัดเท่านั้น จนกว่าปัญหาที่คุณกำลังพยายามแก้ไขจุดบกพร่องจะได้รับการแก้ไข

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

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

การตั้งค่าที่กำหนดเองกันมากที่สุดที่มีอยู่ในแฟ้ม กรอบ / ฐาน / core / ละเอียด / ความละเอียด / ค่า / 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

พิกเซลจะนำมาใช้กับการกำหนดค่าอุปกรณ์หลักที่มีชื่อ 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
    

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

  4. สร้าง AndroidProducts.mk ไฟล์ที่ชี้ไปยัง makefiles ของผลิตภัณฑ์ ในตัวอย่างนี้ จำเป็นต้องใช้ makefile ข้อกำหนดผลิตภัณฑ์เท่านั้น ตัวอย่างด้านล่างจาก 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 Makefile ที่มีการกำหนดค่าที่คณะกรรมการเฉพาะ ยกตัวอย่างให้ดู 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 : สำหรับการตั้งค่าตัวกรองสถานที่เกิดเหตุโดยใช้การแสดงออกปกตินำไปใช้กับชื่อสถานที่เกิดเหตุ ตัวอย่างเช่น:
    • ตัวกรองแบบ Inclusive: ^(de-AT|de-DE|en|uk).* - ช่วยให้เพียงเยอรมัน (ออสเตรียและเยอรมนีพันธุ์), อังกฤษทุกสายพันธุ์ของภาษาอังกฤษและยูเครน
    • กรอง Exclusive: ^(?!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 หากยังไม่ได้กำหนดไว้แล้ว