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

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

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

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

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

เลเยอร์	ตัวอย่าง	คำอธิบาย
ผลิตภัณฑ์	myProduct, myProduct_eu, myProduct_eu_fr, j2, SDK	เลเยอร์ผลิตภัณฑ์จะระบุข้อกำหนดเฉพาะของการจัดส่ง เช่น โมดูลสำหรับสร้าง ภาษาที่รองรับ การกำหนดค่าสำหรับภาษาต่างๆ กล่าวคือ นี่คือชื่อ ของผลิตภัณฑ์โดยรวม ตัวแปรเฉพาะผลิตภัณฑ์จะกำหนดไว้ใน คำจำกัดความของผลิตภัณฑ์ ผลิตภัณฑ์สามารถรับค่าจาก คำจำกัดความผลิตภัณฑ์ ซึ่งทำให้การบำรุงรักษาง่ายขึ้น วิธีการที่ใช้กันทั่วไป คือการสร้างผลิตภัณฑ์พื้นฐานที่มีคุณลักษณะที่ใช้กับ ผลิตภัณฑ์ทั้งหมด แล้วสร้างผลิตภัณฑ์ย่อยโดยอิงตามฐานนั้น ผลิตภัณฑ์ ตัวอย่างเช่น ผลิตภัณฑ์ 2 รายการที่แตกต่างกันเฉพาะ วิทยุของพวกเขา (CDMA กับ GSM) สามารถรับค่าจากผลิตภัณฑ์พื้นฐานเดียวกับที่ ไม่ได้เป็นคำจำกัดความของวิทยุ
กระดาน/อุปกรณ์	มาร์ลิน, บลูไลน์, ปะการัง	ชั้นบอร์ด/อุปกรณ์แสดงถึงชั้นพลาสติกจริงบน อุปกรณ์ (ซึ่งเป็นการออกแบบเชิงอุตสาหกรรมของอุปกรณ์) เลเยอร์นี้ยังแสดงถึง สคีมาของผลิตภัณฑ์ ซึ่งรวมถึงอุปกรณ์ต่อพ่วงบนกระดานและ การกำหนดค่า ชื่อที่ใช้เป็นเพียงรหัสของกระดาน/อุปกรณ์อื่นเท่านั้น การกำหนดค่าเอง
โค้ง	แขน, x86, arm64, x86_64	เลเยอร์สถาปัตยกรรมจะอธิบายการกำหนดค่าโปรเซสเซอร์และ อินเทอร์เฟซแบบไบนารีของแอปพลิเคชัน (ABI) ที่ทำงานอยู่บนกระดาน

ใช้ตัวแปรของบิลด์

เมื่อสร้างผลิตภัณฑ์อย่างใดอย่างหนึ่ง การมีผู้เยาว์ รูปแบบต่างๆ ในการสร้างรุ่นสุดท้าย ในโมดูล โมดูลนี้จะระบุแท็กด้วย LOCAL_MODULE_TAGS ได้ โดยสามารถมีค่าตั้งแต่ optional ได้ตั้งแต่ 1 ค่าขึ้นไป (ค่าเริ่มต้น) 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 เปิดใช้อยู่โดยค่าเริ่มต้น

หลักเกณฑ์สำหรับการแก้ไขข้อบกพร่องของผู้ใช้

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

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

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

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

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

ในการตั้งค่าการวางซ้อนทรัพยากรในไฟล์นี้ ให้เพิ่มไดเรกทอรีการวางซ้อนลงใน Project Buildfile โดยใช้ค่าใดค่าหนึ่งต่อไปนี้

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

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

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

4. สร้างไฟล์ AndroidProducts.mk ที่ชี้ไปยังไฟล์เครื่องสำอางของผลิตภัณฑ์ ใน ในตัวอย่างนี้ จำเป็นต้องใช้ไฟล์สร้างคำจำกัดความของผลิตภัณฑ์เท่านั้น ตัวอย่างด้านล่างมาจาก device/google/marlin/AndroidProducts.mk (ซึ่งมีทั้งมาร์ลิน พิกเซล และปลากระโทงร่มหรือ Pixel 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 ที่มีการกำหนดค่าเฉพาะบอร์ด ดูตัวอย่างได้ที่ 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	รายการรหัสภาษา 2 ตัวอักษรที่คั่นด้วยช่องว่าง ซึ่งเป็นคู่รหัสประเทศ 2 ตัวอักษรที่ อธิบายการตั้งค่าต่างๆ ให้กับผู้ใช้ เช่น ภาษาและเวลาของ UI, วันที่ การจัดรูปแบบสกุลเงิน ภาษาแรกที่แสดงใน PRODUCT_LOCALES จะใช้เป็น ภาษาเริ่มต้นของผลิตภัณฑ์	en_GB, de_DE, es_ES, fr_CA
PRODUCT_MANUFACTURER	ชื่อผู้ผลิต	acme
PRODUCT_MODEL	ชื่อที่ผู้ใช้ปลายทางเห็นสำหรับผลิตภัณฑ์ปลายทาง
PRODUCT_NAME	ชื่อที่ผู้ใช้ปลายทางเห็นสำหรับผลิตภัณฑ์โดยรวม ปรากฏในการตั้งค่า > หน้าจอเกี่ยวกับ
PRODUCT_OTA_PUBLIC_KEYS	รายการคีย์สาธารณะผ่านอากาศ (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 คน (โดยปกติจะเป็นผู้จัดการการเผยแพร่) ควรทำดังนี้

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 ลองใช้คีย์ Canonical เหล่านี้ก่อน ก่อนกลับไปใช้คีย์ที่สร้างขึ้น คีย์โฮสต์ที่ต้องมีการให้สิทธิ์ด้วยตนเอง เมื่อ adb เชื่อมต่อกับอุปกรณ์ที่ไม่ได้รับอนุญาตไม่ได้ อุปกรณ์ ข้อความแสดงข้อผิดพลาดจะแนะนำให้คุณตั้งค่า ADB_VENDOR_KEYS หากไม่ใช่ ตั้งค่าแล้ว