สร้างแพ็คเกจ OTA

คุณสามารถใช้เครื่องมือ 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 ผลลัพธ์จะอยู่ในไดเร็กทอรี out/

ota_update.zip พร้อมที่จะส่งไปยังอุปกรณ์ทดสอบแล้ว (ทุกอย่างลงนามด้วยรหัสทดสอบ) สำหรับอุปกรณ์ของผู้ใช้ ให้สร้างและใช้คีย์ส่วนตัวของคุณเองตามรายละเอียดใน Signing build for release

สร้างการอัพเดตแบบค่อยเป็นค่อยไป

การอัปเดต ส่วนเพิ่ม คือแพ็คเกจ OTA ที่มีแพตช์ไบนารีสำหรับข้อมูลที่มีอยู่แล้วบนอุปกรณ์ แพ็คเกจที่มีการอัพเดตส่วนเพิ่มมักจะมีขนาดเล็กลงเนื่องจากไม่จำเป็นต้องรวมไฟล์ที่ไม่เปลี่ยนแปลง นอกจากนี้ เนื่องจากไฟล์ที่เปลี่ยนแปลงมักจะคล้ายกับเวอร์ชันก่อนหน้ามาก แพ็คเกจจึงจำเป็นต้องรวมการเข้ารหัสความแตกต่างระหว่างสองไฟล์เท่านั้น

คุณสามารถติดตั้งแพ็คเกจการอัปเดตส่วนเพิ่มได้เฉพาะบนอุปกรณ์ที่มีบิลด์ต้นทางที่ใช้ในการสร้างแพ็คเกจเท่านั้น ในการสร้างการอัพเดตส่วนเพิ่ม คุณต้องมีไฟล์ 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 ที่รวมกัน และโดยทั่วไปจะเป็นชุดย่อยที่ไม่ได้ประกาศของพารามิเตอร์ 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 build

บนอุปกรณ์ที่ใช้ Android 11 ขึ้นไป คุณสามารถใช้แฟล็ก --boot_variable_file ในเครื่องมือ OTA เพื่อระบุเส้นทางไปยังไฟล์ที่มีค่าของตัวแปรรันไทม์ที่ใช้ในการสร้างลายนิ้วมือแบบไดนามิกของอุปกรณ์ จากนั้นข้อมูลจะถูกนำมาใช้เพื่ออัปเดตข้อมูลเมตา OTA เพื่อรวมชื่ออุปกรณ์และลายนิ้วมือในเงื่อนไข pre- และ post- (โดยใช้อักขระไปป์ | เป็นตัวคั่น) ธง --boot_variable_file มีไวยากรณ์และคำอธิบายดังต่อไปนี้

  • ไวยากรณ์: --boot_variable_file <path>
  • คำอธิบาย: ระบุเส้นทางไปยังไฟล์ที่มีค่าที่เป็นไปได้ของคุณสมบัติ ro.boot.* ใช้เพื่อคำนวณลายนิ้วมือรันไทม์ที่เป็นไปได้เมื่อคุณสมบัติ ro.product.* บางอย่างถูกแทนที่โดยคำสั่งนำเข้า ไฟล์ต้องการหนึ่งคุณสมบัติต่อบรรทัด โดยแต่ละบรรทัดมีรูปแบบต่อไปนี้: 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 สุดท้าย