ใช้ข้อมูลในเพจนี้เพื่อสร้างไฟล์ 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 | นี่คือรสชาติเริ่มต้น
|
user | ตัวแปรตั้งใจให้เป็นบิตการเผยแพร่ขั้นสุดท้าย
|
userdebug | เช่นเดียวกับ user โดยมีข้อยกเว้นเหล่านี้:
|
แนวทางปฏิบัติสำหรับ 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:
- สร้างไดเรกทอรี
device/ <company-name> / <device-name>
สำหรับผลิตภัณฑ์ของคุณ ตัวอย่างเช่นdevice/google/marlin
ไดเรกทอรีนี้จะมีซอร์สโค้ดสำหรับอุปกรณ์ของคุณพร้อมกับ makefiles ที่จะสร้าง - สร้าง makefile
device.mk
ที่ประกาศไฟล์และโมดูลที่จำเป็นสำหรับอุปกรณ์ ตัวอย่างเช่น โปรดดูที่device/google/marlin/device-marlin.mk
- สร้าง 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 ของคุณ
- สร้างไฟล์
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
- สร้างไฟล์ makefile
BoardConfig.mk
ที่มีการกำหนดค่าเฉพาะบอร์ด ตัวอย่างเช่น โปรดดูที่device/google/marlin/BoardConfig.mk
- สำหรับ Android 9 และต่ำกว่า เท่านั้น ให้สร้างไฟล์
vendorsetup.sh
เพื่อเพิ่มผลิตภัณฑ์ของคุณ ("คำสั่งผสมอาหารกลางวัน") ลงในบิลด์พร้อมกับ ตัวแปรบิลด์ ที่คั่นด้วยเครื่องหมายขีดกลาง ตัวอย่างเช่น:add_lunch_combo <product-name>-userdebug
- ณ จุดนี้ คุณสามารถสร้างผลิตภัณฑ์ย่อยเพิ่มเติมโดยใช้อุปกรณ์เดียวกันได้
การตั้งค่าตัวแปรคำจำกัดความของผลิตภัณฑ์
ตัวแปรเฉพาะผลิตภัณฑ์ถูกกำหนดไว้ใน 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 ด้วยตนเอง
หากต้องการสร้างคีย์ผู้จำหน่าย บุคคลหนึ่งคน (โดยปกติจะเป็นผู้จัดการการเผยแพร่) ควร:
- สร้างคู่คีย์โดยใช้
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
ซึ่งช่วยให้มั่นใจว่าเราจะจำไว้ว่าต้องสร้างคู่คีย์ใหม่สำหรับระบบปฏิบัติการแต่ละเวอร์ชัน
นี่คือ 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
หากยังไม่ได้ตั้งค่า