การสร้างแพ็คเกจ 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 และไบนารีของไพธอนที่เป็นผลลัพธ์จะอยู่ในไดเร็กทอรี out/

ota_update.zip พร้อมที่จะส่งไปยังอุปกรณ์ทดสอบแล้ว (ทุกอย่างลงนามด้วยรหัสทดสอบ) สำหรับอุปกรณ์ของผู้ใช้ ให้สร้างและใช้คีย์ส่วนตัวของคุณเองตามรายละเอียดใน Signing builds 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 ปัจจุบัน 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 แบบไดนามิกตามค่าของคุณสมบัติ bootloader ro.boot.product.hardware.sku (ซึ่งเป็นแบบอ่านอย่างเดียว)

กำลังอัปเดตข้อมูลเมตาของแพ็คเกจ 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 build
  • ค่า pre-build บิลด์และหลังบิลด์ได้มาจากคุณสมบัติ ro.build.fingerprint post-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 สุดท้าย