คุณสามารถใช้เครื่องมือ ota_from_target_files
ที่มีให้ใน build/make/tools/releasetools
เพื่อสร้างแพ็กเกจ OTA ที่สมบูรณ์และเพิ่มขึ้นสำหรับอุปกรณ์ที่ใช้การอัปเดตระบบ A/B หรือการอัปเดตระบบที่ไม่ใช่ A/B เครื่องมือจะใช้ไฟล์ target-files.zip
ที่สร้างโดยระบบบิลด์ของ Android เป็นอินพุต
สำหรับอุปกรณ์ที่ใช้ Android 11 ขึ้นไป คุณจะสร้างแพ็กเกจ OTA รายการเดียวสำหรับอุปกรณ์หลายเครื่องที่มี SKU แตกต่างกันได้ การดำเนินการนี้จำเป็นต้องกำหนดค่าอุปกรณ์เป้าหมายให้ใช้ลายนิ้วมือแบบไดนามิกและการอัปเดตข้อมูลเมตาของ OTA เพื่อรวมชื่ออุปกรณ์และลายนิ้วมือในรายการก่อนและหลังการใช้งาน
Android 8.0 เลิกใช้งานแพ็กเกจ OTA ตามไฟล์สำหรับอุปกรณ์ที่ไม่ใช่ A/B แล้ว ซึ่งต้องใช้แพ็กเกจ OTA ที่อิงตามการบล็อกแทน หากต้องการสร้างแพ็กเกจ OTA แบบบล็อกหรืออุปกรณ์ที่ใช้ Android 7.x หรือต่ำกว่า ให้ส่งตัวเลือก --block
ไปยังพารามิเตอร์ ota_from_target_files
สร้างการอัปเดตเต็มรูปแบบ
การอัปเดตที่สมบูรณ์คือแพ็กเกจ OTA ที่มีสถานะสุดท้ายทั้งหมดของอุปกรณ์ (พาร์ติชันของระบบ การเปิดเครื่อง และการกู้คืน) ตราบใดที่อุปกรณ์รับและใช้แพ็กเกจได้ แพ็กเกจก็จะติดตั้งบิลด์ได้ไม่ว่าปัจจุบันของอุปกรณ์จะเป็นอย่างไรก็ตาม เช่น คำสั่งต่อไปนี้ใช้เครื่องมือสำหรับการเผยแพร่เพื่อสร้างที่เก็บถาวรของ 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 Binary ที่ได้จะอยู่ในไดเรกทอรี out/
ตอนนี้ ota_update.zip
ก็พร้อมที่จะส่งไปยังอุปกรณ์ทดสอบแล้ว (ทุกอย่างจะรับรองด้วยคีย์ทดสอบ) สำหรับอุปกรณ์ของผู้ใช้ ให้สร้างและใช้คีย์ส่วนตัวของคุณเองตามรายละเอียดในการลงนามบิลด์สำหรับรุ่น
สร้างอัปเดตเพิ่มเติม
การอัปเดตที่เพิ่มขึ้นคือแพ็กเกจ OTA ที่มีแพตช์แบบไบนารีของข้อมูลในอุปกรณ์อยู่แล้ว แพ็กเกจที่มีการอัปเดตที่เพิ่มขึ้นมักจะมีขนาดเล็กกว่าเนื่องจากไม่จำเป็นต้องรวมไฟล์ที่ไม่มีการเปลี่ยนแปลง นอกจากนี้ เนื่องจากไฟล์ที่เปลี่ยนแปลงนั้นมักจะคล้ายกับไฟล์เวอร์ชันก่อนหน้าเป็นอย่างมาก แพ็กเกจจึงต้องรวมเฉพาะการเข้ารหัสของความแตกต่างระหว่าง 2 ไฟล์เท่านั้น
คุณติดตั้งแพ็กเกจการอัปเดตที่เพิ่มขึ้นได้เฉพาะในอุปกรณ์ที่ใช้บิลด์ต้นทางในการสร้างแพ็กเกจ หากต้องการสร้างการอัปเดตเพิ่มเติม คุณต้องมีไฟล์ target_files.zip
จากบิลด์ก่อนหน้า (รายการที่คุณต้องการอัปเดตจาก) และไฟล์ 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_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
)
ใช้ลายนิ้วมือแบบไดนามิก
ลายนิ้วมือคือการเชื่อมพารามิเตอร์บิลด์ เช่น 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