คุณสามารถใช้ota_from_target_files
เครื่องมือที่มีให้ใน build/make/tools/releasetools
เพื่อสร้างฟังก์ชันที่สมบูรณ์และเพิ่มเติม
แพ็กเกจ OTA สำหรับอุปกรณ์ที่ใช้การอัปเดตระบบ A/B หรือ
การอัปเดตระบบที่ไม่ใช่ A/B เครื่องมือจะใช้
ไฟล์ target-files.zip
ที่สร้างโดยระบบบิลด์ของ Android เป็นอินพุต
สำหรับอุปกรณ์ที่ใช้ Android 11 ขึ้นไป คุณสามารถสร้าง แพ็กเกจ OTA รายการเดียวสำหรับอุปกรณ์หลายเครื่องที่มี SKU แตกต่างกัน การดำเนินการนี้ต้องใช้ การกำหนดค่าอุปกรณ์เป้าหมายให้ใช้ลายนิ้วมือแบบไดนามิก และอัปเดตข้อมูลเมตาของ OTA เพื่อใส่อุปกรณ์ ชื่อและลายนิ้วมือในรายการ "ก่อนและหลัง"
แพ็กเกจ OTA ที่อิงตามไฟล์ของ Android 8.0 ที่เลิกใช้งานสำหรับอุปกรณ์ที่ไม่ใช่ A/B ซึ่งต้อง
ให้ใช้แพ็กเกจ OTA แบบบล็อกแทน ถึง
สร้างแพ็กเกจ OTA แบบบล็อกหรืออุปกรณ์ที่ใช้ Android 7.x หรือต่ำกว่า
ตัวเลือก --block
เป็นพารามิเตอร์ ota_from_target_files
สร้างการอัปเดตเต็มรูปแบบ
การอัปเดตที่สมบูรณ์คือแพ็กเกจ OTA ที่มีสถานะสุดท้ายทั้งหมดของ
อุปกรณ์ (พาร์ติชันระบบ การเปิดเครื่อง และการกู้คืน) ตราบใดที่อุปกรณ์สามารถ
ของการรับและใช้แพ็กเกจ แพ็กเกจก็จะติดตั้งบิลด์ได้
ไม่ว่าสถานะปัจจุบันของอุปกรณ์จะเป็นอย่างไรก็ตาม ตัวอย่างเช่น URL ต่อไปนี้
จะใช้เครื่องมือเผยแพร่เพื่อสร้างที่เก็บถาวร target-files.zip
สำหรับ
อุปกรณ์ tardis
เครื่อง
. build/envsetup.sh && lunch tardis-eng
mkdir dist_output
make dist DIST_DIR=dist_output
make dist
จะสร้างแพ็กเกจ OTA เต็มรูปแบบ (ใน $OUT
) ไฟล์ผลลัพธ์ .zip
มีทุกอย่างที่จำเป็นในการสร้างแพ็กเกจ OTA สำหรับอุปกรณ์ tardis
คุณสามารถสร้าง ota_from_target_files
เป็นไบนารี Python และเรียกเป็น
สร้างแพ็กเกจแบบเต็มหรือทีละส่วนก็ได้
ota_from_target_files dist_output/tardis-target_files.zip ota_update.zip
เส้นทาง ota_from_target_files
ได้รับการตั้งค่าใน $PATH
และ Python ผลลัพธ์
ไบนารีอยู่ในไดเรกทอรี out/
พร้อมส่ง ota_update.zip
ไปยังอุปกรณ์ทดสอบแล้ว (ทุกอย่างที่มีการรับรอง
ด้วยคีย์ทดสอบ) สำหรับอุปกรณ์ของผู้ใช้ ให้สร้างและใช้คีย์ส่วนตัวของคุณเองเป็น
ตามรายละเอียดในการเซ็นชื่อบิลด์สำหรับการเปิดตัว
สร้างอัปเดตเพิ่มเติม
การอัปเดตที่เพิ่มขึ้นคือแพ็กเกจ OTA ที่มีแพตช์ไบนารีของข้อมูล ในอุปกรณ์อยู่แล้ว แพ็กเกจที่มีการอัปเดตทีละน้อยมักมีขนาดเล็กกว่า เนื่องจากไม่จำเป็นต้องมีไฟล์ที่ไม่มีการเปลี่ยนแปลง นอกจากนี้ ไฟล์ที่มีการเปลี่ยนแปลง มักคล้ายกับเวอร์ชันก่อนหน้ามาก แพ็กเกจจะต้องมีเพียง การเข้ารหัสความแตกต่างระหว่างไฟล์ทั้งสองได้
คุณจะติดตั้งแพ็กเกจการอัปเดตเพิ่มเติมได้เฉพาะในอุปกรณ์ที่มี
บิลด์ต้นทางที่ใช้ในการสร้างแพ็กเกจ หากต้องการสร้างการอัปเดตเพิ่ม
คุณต้องมีไฟล์ target_files.zip
จากบิลด์ก่อนหน้า (รายการที่คุณต้องการ
เพื่ออัปเดต from) และไฟล์ target_files.zip
จากบิลด์ใหม่ สำหรับ
เช่น คำสั่งต่อไปนี้ใช้เครื่องมือสำหรับรุ่นเพื่อสร้างอัปเดตแบบเพิ่มขึ้นเรื่อยๆ
สำหรับอุปกรณ์ tardis
ota_from_target_files -i PREVIOUS-tardis-target_files.zip dist_output/tardis-target_files.zip incremental_ota_update.zip
บิลด์นี้คล้ายกับบิลด์ก่อนหน้าอย่างมาก และการอัปเดตที่เพิ่มขึ้น
แพ็กเกจ (incremental_ota_update.zip
) นั้นเล็กกว่า
อัปเดตแบบเต็ม (ประมาณ 1 MB จากเดิม 60 MB)
แจกจ่ายแพ็กเกจส่วนเพิ่มให้กับอุปกรณ์ที่ทำงานเหมือนกันทุกประการเท่านั้น
บิลด์ก่อนหน้าที่ใช้เป็นจุดเริ่มต้นของแพ็กเกจที่เพิ่มขึ้น คุณต้องแฟลช
รูปภาพใน PREVIOUS-tardis-target_files.zip
หรือ PREVIOUS-tardis-img.zip
(ทั้งคู่สร้างด้วย make dist
ที่จะกะพริบด้วย fastboot update
) แทนที่จะเป็น
รายการภายใต้ไดเรกทอรี PRODUCT_OUT
(สร้างด้วย make
ซึ่งจะ
กะพริบด้วย fastboot flashall
) กำลังพยายามติดตั้งแพ็กเกจที่เพิ่มขึ้น
ในอุปกรณ์ที่มีบิลด์อื่นๆ ส่งผลให้เกิดข้อผิดพลาดในการติดตั้ง เมื่อ
ติดตั้งไม่สำเร็จ อุปกรณ์จะยังคงอยู่ในสถานะทำงานเหมือนเดิม (กำลังใช้เวอร์ชันเก่า
ระบบ); แพ็กเกจจะยืนยันสถานะก่อนหน้าของไฟล์ทั้งหมดที่อัปเดต
ก่อนที่จะแตะเครื่อง เพื่อที่อุปกรณ์จะไม่ติดอยู่ในสถานะอัปเกรดครึ่งหนึ่ง
เสนอการอัปเดตแบบเต็มทุกๆ 3-4 รายการเพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีที่สุด อัปเดต ซึ่งจะช่วยให้ผู้ใช้ได้พบกับรุ่นล่าสุดและหลีกเลี่ยง ลำดับการติดตั้งอัปเดตส่วนเพิ่ม
สร้างแพ็กเกจ OTA สำหรับ SKU หลายรายการ
Android 11 ขึ้นไปรองรับการใช้ OTA เดียว สำหรับอุปกรณ์หลายเครื่องที่มี SKU ต่างกัน การดำเนินการนี้ต้องมีการกำหนดค่า อุปกรณ์เป้าหมายให้ใช้ลายนิ้วมือแบบไดนามิกและอัปเดตข้อมูลเมตาของ OTA (ใช้เครื่องมือ OTA) เพื่อใส่ชื่ออุปกรณ์และลายนิ้วมือในช่วงก่อนและหลังโพสต์ รายการเงื่อนไข
เกี่ยวกับ SKU
รูปแบบของ SKU เป็นรูปแบบหนึ่งของ build แบบรวม
และ
มักจะเป็นชุดย่อยที่ไม่ได้ประกาศของพารามิเตอร์ build_fingerprint
ปัจจุบัน
OEM ใช้พารามิเตอร์บิลด์ที่ CDD อนุมัติร่วมกับ SKU ได้ในขณะที่
โดยใช้รูปภาพเดียวสำหรับ SKU ดังกล่าว ตัวอย่างเช่น SKU ต่อไปนี้มี
หลายรูปแบบ:
SKU = <product><device><modifierA><modifierB><modifierC>
modifierA
คือระดับอุปกรณ์ (เช่น Pro, Premium หรือ Plus)modifierB
คือรูปแบบของฮาร์ดแวร์ (เช่น วิทยุ)modifierC
คือภูมิภาคซึ่งอาจเป็นพื้นที่ทั่วไป (เช่น NA, EMEA หรือ CHN ) หรือเฉพาะประเทศหรือภาษา (เช่น JPN, ENG หรือ CHN)
OEM จำนวนมากใช้รูปภาพเดียวสำหรับ SKU หลายรายการ แล้วสร้างผลิตภัณฑ์ขั้นสุดท้าย
ชื่อและลายนิ้วมือของอุปกรณ์ในระหว่างรันไทม์หลังจากอุปกรณ์เปิดเครื่อง กระบวนการนี้
ลดความซับซ้อนของกระบวนการพัฒนาแพลตฟอร์ม ซึ่งช่วยให้อุปกรณ์ที่มีผู้เยาว์
การกำหนดค่าเองแต่ใช้ชื่อผลิตภัณฑ์ต่างกันเพื่อแชร์รูปภาพทั่วไป (เช่น
tardis
และ tardispro
)
ใช้ลายนิ้วมือแบบไดนามิก
ลายนิ้วมือเป็นการเชื่อม build
พารามิเตอร์ เช่น
ro.product.brand
, ro.product.name
และ ro.product.device
ลายนิ้วมือ
ของอุปกรณ์ได้มาจากลายนิ้วมือพาร์ติชันระบบและใช้เป็น
ตัวระบุที่ไม่ซ้ำกันของรูปภาพ (และไบต์) ที่ทำงานอยู่ในอุปกรณ์ วิธีสร้าง
ลายนิ้วมือแบบไดนามิก ให้ใช้ตรรกะแบบไดนามิกในไฟล์ build.prop
ของอุปกรณ์เพื่อ
รับค่าของตัวแปร Bootloader ในเวลาเปิดเครื่องของอุปกรณ์ แล้วใช้ข้อมูลนั้นเพื่อ
สร้างลายนิ้วมือแบบไดนามิก
สำหรับอุปกรณ์นั้น
ตัวอย่างเช่น หากต้องการใช้ลายนิ้วมือแบบไดนามิกสำหรับอุปกรณ์ tardis
และ tardispro
ให้อัปเดตไฟล์ต่อไปนี้ตามที่แสดงด้านล่าง
อัปเดตไฟล์
odm/etc/build_std.prop
ให้มีบรรทัดต่อไปนี้ro.odm.product.device=tardis
อัปเดตไฟล์
odm/etc/build_pro.prop
ให้มีบรรทัดต่อไปนี้ro.odm.product.device=tardispro
อัปเดตไฟล์
odm/etc/build.prop
ให้มีบรรทัดต่อไปนี้ro.odm.product.device=tardis import /odm/etc/build_${ro.boot.product.hardware.sku}.prop
เส้นเหล่านี้จะตั้งชื่ออุปกรณ์ ลายนิ้วมือ และ
ro.build.fingerprint
ค่าตามค่าของฟิลด์
พร็อพเพอร์ตี้ ro.boot.product.hardware.sku
Bootloader (ซึ่งเป็นอ่านอย่างเดียว)
อัปเดตข้อมูลเมตาของแพ็กเกจ OTA
แพ็กเกจ OTA มีไฟล์ข้อมูลเมตา (META-INF/com/android/metadata
) ที่
อธิบายแพ็กเกจ รวมถึงเงื่อนไขล่วงหน้าและเงื่อนไขหลังการใช้งานของ OTA
ใหม่ ตัวอย่างเช่น โค้ดต่อไปนี้คือไฟล์ข้อมูลเมตาสำหรับแพ็กเกจ OTA
กำหนดเป้าหมายไปยังอุปกรณ์ tardis
post-build=google/tardis/tardis:11/RP1A.200521.001/6516341:userdebug/dev-keys
post-build-incremental=6516341
post-sdk-level=30
post-security-patch-level=2020-07-05
post-timestamp=1590026334
pre-build=google/tardis/tardis:11/RP1A.200519.002.A1/6515794:userdebug/dev-keys
pre-build-incremental=6515794
pre-device=tardis
ค่า pre-device
, pre-build-incremental
และ pre-build
กำหนดค่า
ที่อุปกรณ์ต้องมีก่อนที่จะติดตั้งแพ็กเกจ OTA ได้
ค่า post-build-incremental
และ post-build
กำหนดสถานะของอุปกรณ์
ที่มักมีหลังจากติดตั้งแพ็กเกจ OTA ค่าของ pre-
และ
ฟิลด์ post-
มาจากพร็อพเพอร์ตี้ของบิลด์ที่เกี่ยวข้องต่อไปนี้
- ค่า
pre-device
ได้มาจากพร็อพเพอร์ตี้ของบิลด์ro.product.device
- ดึงค่า
pre-build-incremental
และpost-build-incremental
แล้ว จากพร็อพเพอร์ตี้ของบิลด์ro.build.version.incremental
- ค่า
pre-build
และpost-build
ได้มาจาก พร็อพเพอร์ตี้ของบิลด์ro.build.fingerprint
ในอุปกรณ์ที่ใช้ Android 11 ขึ้นไป คุณสามารถใช้
แฟล็ก --boot_variable_file
ในเครื่องมือ OTA เพื่อระบุเส้นทางไปยังไฟล์ที่
มีค่าของตัวแปรรันไทม์ที่ใช้ในการสร้าง
ลายนิ้วมือแบบไดนามิก จากนั้นระบบจะใช้ข้อมูลเพื่ออัปเดตข้อมูลเมตาของ OTA เพื่อใส่
ชื่ออุปกรณ์และลายนิ้วมือในเงื่อนไข pre-
และ post-
(โดยใช้
อักขระไปป์ | เป็นตัวคั่น) แฟล็ก --boot_variable_file
มี
ไวยากรณ์และคำอธิบายต่อไปนี้
- ไวยากรณ์:
--boot_variable_file <path>
- คำอธิบาย: ระบุเส้นทางไปยังไฟล์ที่มีค่าที่เป็นไปได้
พร็อพเพอร์ตี้
ro.boot.*
รายการ ใช้ในการคำนวณลายนิ้วมือรันไทม์ที่เป็นไปได้ เมื่อพร็อพเพอร์ตี้ro.product.*
บางรายการถูกลบล้างโดยคำสั่งการนำเข้า ไฟล์ต้องการพร็อพเพอร์ตี้ 1 รายการต่อบรรทัด โดยแต่ละบรรทัดจะมีข้อมูลต่อไปนี้ รูปแบบ:prop_name=value1,value2
ตัวอย่างเช่น เมื่อพร็อพเพอร์ตี้คือ ro.boot.product.hardware.sku=std,pro
ค่า
ข้อมูลเมตา OTA สำหรับอุปกรณ์ tardis
และ tardispro
ดังที่แสดงด้านล่าง
post-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-build=google/tardis/tardis:11/<suffix>|google/tardis/tardispro:11/<suffix>
pre-device=tardis|tardispro
หากต้องการรองรับฟังก์ชันนี้ในอุปกรณ์ที่ใช้ Android 10 โปรดดูข้อมูลอ้างอิง
การใช้งาน
รายการการเปลี่ยนแปลงนี้จะแยกวิเคราะห์คำสั่ง import
แบบมีเงื่อนไขใน build.prop
ซึ่งทำให้ระบบรู้จักและลบล้างพร็อพเพอร์ตี้ใน
ข้อมูลเมตาสุดท้ายของ OTA