คำถามที่พบบ่อย

Google เคยใช้ OTA แบบ A/B ในอุปกรณ์ใดบ้าง

ได้ ชื่อทางการตลาดสำหรับการอัปเดต A/B คือการอัปเดตที่ราบรื่น โทรศัพท์ Pixel และ Pixel XL ที่จัดส่งตั้งแต่เดือนตุลาคม 2016 มาพร้อมกับ A/B และ Chromebook ทุกเครื่องใช้ update_engine การติดตั้งใช้งาน A/B เดียวกัน การติดตั้งใช้งานโค้ดแพลตฟอร์มที่จำเป็นเป็นแบบสาธารณะใน Android 7.1 ขึ้นไป

เหตุใด OTA ที่ทำการทดสอบ A/B จึงดีกว่า

OTA แบบ A/B ช่วยให้ผู้ใช้ได้รับประสบการณ์การใช้งานที่ดียิ่งขึ้นเมื่อทำการอัปเดต  การวัดผลจากการอัปเดตความปลอดภัยรายเดือนแสดงให้เห็นว่าฟีเจอร์นี้ประสบความสำเร็จแล้ว โดยในเดือนพฤษภาคม 2017 เจ้าของ Pixel 95% ใช้การอัปเดตความปลอดภัยล่าสุดหลังจากผ่านไป 1 เดือน เทียบกับผู้ใช้ Nexus 87% และผู้ใช้ Pixel อัปเดตเร็วกว่าผู้ใช้ Nexus การอัปเดตบล็อกระหว่าง OTA ที่ล้มเหลวจะไม่ทำให้อุปกรณ์บูตไม่ได้อีกต่อไป จนกว่าอิมเมจระบบใหม่จะบูตสำเร็จ Android จะยังคงมีความสามารถในการย้อนกลับไปยังอิมเมจระบบที่ใช้งานได้ก่อนหน้า

system_other คืออะไร

แอปพลิเคชันจะจัดเก็บไว้ในไฟล์ .apk ซึ่งเป็นไฟล์ ZIP ไฟล์ .apk แต่ละไฟล์มีไฟล์ .dex อย่างน้อย 1 ไฟล์อยู่ภายใน ซึ่งมีไบต์โค้ด Dalvik แบบพกพา ไฟล์ .odex (optimized .dex) จะแยกจากไฟล์ .apk และอาจมีโค้ดเครื่องที่เฉพาะเจาะจงกับอุปกรณ์ หากมีไฟล์ .odex Android จะเรียกใช้แอปพลิเคชันด้วยความเร็วที่คอมไพล์ล่วงหน้าได้ โดยไม่ต้องรอให้คอมไพล์โค้ดทุกครั้งที่เปิดแอปพลิเคชัน ไฟล์ .odex ไม่ได้จำเป็นอย่างเคร่งครัด: Android สามารถเรียกใช้โค้ด .dex ได้โดยตรงผ่าน การตีความหรือการคอมไพล์แบบ Just-In-Time (JIT) แต่ไฟล์ .odex จะให้ การผสมผสานที่ดีที่สุดระหว่างความเร็วในการเปิดตัวและความเร็วขณะรันไทม์หากมีพื้นที่ว่าง

ตัวอย่าง: สำหรับไฟล์ installed-files.txt จาก Nexus 6P ที่ใช้ Android 7.1 ซึ่งมีขนาดอิมเมจระบบทั้งหมด 2628MiB (2755792836 ไบต์) รายละเอียดของผู้ที่มีส่วนทำให้ขนาดอิมเมจระบบโดยรวม มีขนาดใหญ่ที่สุดตามประเภทไฟล์มีดังนี้

.odex	1391770312 ไบต์	50.5%
.apk	846878259 ไบต์	30.7%
.so (โค้ด C/C++ แบบเนทีฟ)	202162479 ไบต์	7.3%
ไฟล์ .oat/รูปภาพ .art	163892188 ไบต์	5.9%
แบบอักษร	38952361 ไบต์	1.4%
ข้อมูลภาษา ICU	27468687 ไบต์	0.9%

ตัวเลขเหล่านี้คล้ายกันสำหรับอุปกรณ์อื่นๆ ด้วย ดังนั้นในอุปกรณ์ Nexus/Pixel ไฟล์ .odex จะใช้พื้นที่ประมาณครึ่งหนึ่งของพาร์ติชันระบบ ซึ่งหมายความว่าเราจะใช้ ext4 ต่อไปได้ แต่จะเขียนไฟล์ .odex ไปยังพาร์ติชัน B ที่โรงงาน แล้วคัดลอกไปยัง /data ในการบูตครั้งแรก พื้นที่เก็บข้อมูลจริงที่ใช้กับ A/B ของ ext4 จะเหมือนกับ A/B ของ SquashFS เนื่องจากหากเราใช้ SquashFS เราจะจัดส่งไฟล์ .odex ที่มีการเพิ่มประสิทธิภาพล่วงหน้าใน system_a แทนที่จะเป็น system_b

การคัดลอกไฟล์ .odex ไปยัง /data ไม่ได้หมายความว่าพื้นที่ที่ประหยัดได้ใน /system จะหายไปใน /data ใช่ไหม

ก็ไม่เชิง ใน Pixel พื้นที่ส่วนใหญ่ที่ไฟล์ .odex ใช้จะเป็นของแอป ซึ่งโดยปกติจะ อยู่ใน /data แอปเหล่านี้จะได้รับการอัปเดตจาก Google Play ดังนั้นไฟล์ .apk และ .odex ในอิมเมจระบบจึงไม่ได้ใช้ตลอดอายุการใช้งานส่วนใหญ่ของอุปกรณ์ คุณสามารถยกเว้นไฟล์ดังกล่าว ทั้งหมดและแทนที่ด้วยไฟล์ .odex ขนาดเล็กที่อิงตามโปรไฟล์เมื่อผู้ใช้ใช้งานแต่ละแอปจริง (จึงไม่ต้องใช้พื้นที่สำหรับแอปที่ผู้ใช้ไม่ได้ใช้) โปรดดูรายละเอียดที่การพูดคุยในงาน Google I/O 2016 เรื่องวิวัฒนาการของศิลปะ

การเปรียบเทียบทำได้ยากเนื่องจากเหตุผลสำคัญ 2-3 ประการ ดังนี้

• แอปที่ Google Play อัปเดตจะมีไฟล์ .odex ใน /data เสมอ ทันทีที่ได้รับการอัปเดตครั้งแรก
• แอปที่ผู้ใช้ไม่ได้เรียกใช้ไม่จำเป็นต้องมีไฟล์ .odex
• การคอมไพล์ที่อิงตามโปรไฟล์จะสร้างไฟล์ .odex ที่มีขนาดเล็กกว่าการคอมไพล์ล่วงหน้า (เนื่องจากแบบแรกจะเพิ่มประสิทธิภาพเฉพาะโค้ดที่สำคัญต่อประสิทธิภาพเท่านั้น)

ดูรายละเอียดเกี่ยวกับตัวเลือกการปรับแต่งที่มีให้สำหรับ OEM ได้ที่ การกำหนดค่า ART

มีไฟล์ .odex 2 สำเนาใน /data ใช่ไหม

ซึ่งจะซับซ้อนขึ้นเล็กน้อย ... หลังจากเขียนอิมเมจระบบใหม่แล้ว ระบบจะเรียกใช้ dex2oat เวอร์ชันใหม่กับไฟล์ .dex ใหม่เพื่อสร้างไฟล์ .odex ใหม่ ซึ่งจะเกิดขึ้นขณะที่ระบบเดิมยังทำงานอยู่ ดังนั้นไฟล์ .odex ทั้งเก่าและใหม่จะอยู่ใน /data พร้อมกัน

โค้ดใน OtaDexoptService (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/OtaDexoptService.java) จะเรียกใช้ getAvailableSpace ก่อนที่จะเพิ่มประสิทธิภาพแต่ละแพ็กเกจเพื่อหลีกเลี่ยงการเพิ่มประสิทธิภาพมากเกินไป /data โปรดทราบว่าคำว่าพร้อมใช้งานในที่นี้ยังคงเป็นค่าประมาณแบบระมัดระวัง ซึ่งเป็นปริมาณพื้นที่ที่เหลือก่อนถึงเกณฑ์พื้นที่เหลือน้อยของระบบตามปกติ (วัดเป็นทั้งเปอร์เซ็นต์และจำนวนไบต์) ดังนั้นหาก /data เต็ม ระบบจะไม่ทำสำเนาไฟล์ .odex ทุกไฟล์ โค้ดเดียวกันนี้ยังมี BULK_DELETE_THRESHOLD ด้วย หากอุปกรณ์ใกล้จะใช้พื้นที่ว่างจนเต็ม (ตามที่อธิบายไว้) ระบบจะนำไฟล์ .odex ที่เป็นของแอปที่ไม่ได้ใช้งานออก นั่นเป็นอีกกรณีที่ไม่มีไฟล์ .odex 2 ชุด

ในกรณีที่/dataเต็มจนไม่สามารถใช้งานได้ การอัปเดตจะรอจนกว่า อุปกรณ์จะรีบูตเข้าสู่ระบบใหม่และไม่จำเป็นต้องใช้ไฟล์ .odex ของระบบเก่าอีกต่อไป PackageManager จะจัดการเรื่องนี้ (frameworks/base/+/android16-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215) หลังจากที่ระบบใหม่บูตเรียบร้อยแล้ว installd (frameworks/native/+/android16-release/cmds/installd/dexopt.cpp#2422) จะนำไฟล์ .odex ที่ระบบเก่าใช้ไปออกได้ ซึ่งจะทำให้อุปกรณ์กลับสู่ สถานะปกติที่มีสำเนาเพียงชุดเดียว

ดังนั้นแม้ว่า /data อาจมีไฟล์ .odex ทั้งหมด 2 ชุด (ก) แต่การดำเนินการนี้เป็นเพียงชั่วคราวและ (ข) จะเกิดขึ้นก็ต่อเมื่อคุณมีพื้นที่ว่างเพียงพอใน /data อยู่แล้ว โดยจะมีสำเนาเพียงฉบับเดียวเท่านั้น ยกเว้นในระหว่างการอัปเดต และในส่วนของฟีเจอร์ความเสถียรทั่วไปของ ART ระบบจะไม่เติม /data ด้วยไฟล์ .odex อยู่แล้ว (เนื่องจากจะเป็นปัญหาในระบบที่ไม่ใช่ A/B ด้วย)

การเขียน/คัดลอกทั้งหมดนี้จะทำให้แฟลชเสื่อมสภาพมากขึ้นไหม

โดยจะเขียนทับเฉพาะส่วนเล็กๆ ของหน่วยความจำแฟลชเท่านั้น ซึ่งการอัปเดตระบบ Pixel แบบเต็มจะเขียนทับประมาณ 2.3 GiB (ระบบจะคอมไพล์แอปอีกครั้งด้วย แต่การดำเนินการนี้จะเกิดขึ้นกับอุปกรณ์ที่ไม่ใช่ A/B ด้วย) โดยปกติแล้ว OTA แบบเต็มที่อิงตามบล็อกจะเขียนข้อมูลในปริมาณที่คล้ายกัน ดังนั้นอัตราการสึกหรอของหน่วยความจำแฟลชจึงควรคล้ายกัน

การแฟลชพาร์ติชันระบบ 2 รายการจะเพิ่มเวลาในการแฟลชจากโรงงานไหม

ไม่ Pixel ไม่ได้เพิ่มขนาดอิมเมจของระบบ (เพียงแค่แบ่งพื้นที่ออกเป็น 2 พาร์ติชัน เท่านั้น)

การเก็บไฟล์ .odex ไว้ใน B จะทำให้การรีบูตหลังจากรีเซ็ตข้อมูลเป็นค่าเริ่มต้นช้าลงใช่ไหม

ได้ หากคุณใช้อุปกรณ์จริง รับ OTA และรีเซ็ตข้อมูลเป็นค่าเริ่มต้น การรีบูตครั้งแรกจะช้ากว่าปกติ (1 นาที 40 วินาที เทียบกับ 40 วินาทีใน Pixel XL) เนื่องจากไฟล์ .odex จะหายไปจาก B หลังจาก OTA ครั้งแรก จึงคัดลอกไปยัง /data ไม่ได้ นั่นคือข้อแลกเปลี่ยน

การรีเซ็ตข้อมูลเป็นค่าเริ่มต้นจากโรงงานควรเป็นการดำเนินการที่เกิดขึ้นไม่บ่อยนักเมื่อเทียบกับการบูตปกติ ดังนั้นเวลาที่ใช้จึงมีความสำคัญน้อยกว่า (การดำเนินการนี้ไม่ส่งผลต่อผู้ใช้หรือผู้ตรวจสอบที่ได้รับอุปกรณ์จากโรงงาน เนื่องจากในกรณีดังกล่าว พาร์ติชัน B จะพร้อมใช้งาน) การใช้คอมไพเลอร์ JIT หมายความว่าเรา ไม่จำเป็นต้องคอมไพล์ทุกอย่างใหม่ จึงไม่ได้แย่อย่างที่คุณคิด นอกจากนี้ คุณยัง ทำเครื่องหมายแอปว่าต้องมีการคอมไพล์ล่วงหน้าได้โดยใช้ coreApp="true" ในไฟล์ Manifest (frameworks/base/+/android16-release/packages/SystemUI/AndroidManifest.xml#23) ปัจจุบัน system_server ใช้การคอมไพล์ล่วงหน้านี้เนื่องจากไม่อนุญาตให้ใช้ JIT ด้วยเหตุผลด้านความปลอดภัย

การเก็บไฟล์ .odex ไว้ใน /data แทนที่จะเก็บไว้ใน /system จะทำให้การรีบูตหลังจาก OTA ช้าลงใช่ไหม

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

เราควรจัดส่งอุปกรณ์ A/B ขนาด 32 GiB ไหม 16 GiB 8 GiB

32 GiB ทำงานได้ดีเนื่องจากได้รับการพิสูจน์แล้วใน Pixel และ 320 MiB จาก 16 GiB หมายถึงการลดลง 2% ในทำนองเดียวกัน 320 MiB จาก 8 GiB ก็ลดลง 4% แน่นอนว่า A/B ไม่ใช่ตัวเลือกที่แนะนำ ในอุปกรณ์ที่มี 4 GiB เนื่องจากค่าใช้จ่ายเพิ่มเติม 320 MiB คิดเป็นเกือบ 10% ของพื้นที่ทั้งหมดที่ใช้ได้

AVB2.0 ต้องใช้ OTA แบบ A/B ไหม

ไม่ Verified Boot ของ Android กำหนดให้ใช้การอัปเดตแบบบล็อกมาโดยตลอด แต่ไม่จำเป็นต้องเป็นการอัปเดต A/B

OTA แบบ A/B ต้องใช้ AVB2.0 ไหม

ไม่

OTA แบบ A/B จะทำให้การป้องกันการย้อนกลับของ AVB2.0 หยุดทำงานไหม

ไม่ ระบบ A/B จะไม่เปลี่ยนกลับไปใช้พาร์ติชันที่ใช้งานอยู่ก่อนหน้าโดยอัตโนมัติหากบูตเข้าสู่รูปภาพระบบใหม่ไม่สำเร็จ (หลังจากลองใหม่ตามจำนวนครั้งที่กำหนดโดยโปรแกรมโหลดบูต) แต่จะเปลี่ยนกลับไปใช้รูปภาพระบบ "ก่อนหน้า" โดยอัตโนมัติ แต่ประเด็นสำคัญในที่นี้คือ "ก่อนหน้า" ในความหมายของ A/B ยังคงเป็นอิมเมจระบบ "ปัจจุบัน" ทันทีที่อุปกรณ์บูตอิมเมจใหม่ได้สำเร็จ การป้องกันการย้อนกลับจะเริ่มทำงานและรับประกันว่าคุณจะย้อนกลับไม่ได้ แต่จนกว่าคุณจะ บูตอิมเมจใหม่ได้สำเร็จจริงๆ การป้องกันการย้อนกลับจะไม่ถือว่าอิมเมจนั้นเป็น อิมเมจระบบปัจจุบัน

หากติดตั้งการอัปเดตขณะที่ระบบทำงานอยู่ จะไม่ช้าไปหน่อยหรือ

การอัปเดตแบบไม่ใช่ A/B มีเป้าหมายคือการติดตั้งการอัปเดตให้เร็วที่สุดเท่าที่จะเป็นไปได้ เนื่องจากผู้ใช้ กำลังรอและใช้อุปกรณ์ไม่ได้ในขณะที่ระบบใช้การอัปเดต แต่การอัปเดต A/B จะตรงกันข้าม เนื่องจากผู้ใช้ยังคงใช้อุปกรณ์อยู่ เป้าหมายคือการลดผลกระทบให้เหลือน้อยที่สุด ดังนั้นการอัปเดตจึงจะช้าโดยเจตนา ผ่านตรรกะในไคลเอ็นต์การอัปเดตระบบ Java (ซึ่งสำหรับ Google คือ GmsCore ซึ่งเป็นแพ็กเกจหลักที่ GMS จัดหาให้) Android ยังพยายาม เลือกเวลาที่ผู้ใช้ไม่ได้ใช้อุปกรณ์เลยด้วย แพลตฟอร์มรองรับ การหยุด/กลับมาอัปเดตต่อ และไคลเอ็นต์สามารถใช้ฟีเจอร์นี้เพื่อหยุดการอัปเดตชั่วคราวหากผู้ใช้ เริ่มใช้อุปกรณ์ และกลับมาอัปเดตต่อเมื่ออุปกรณ์ไม่ได้ใช้งานอีกครั้ง

การทำ OTA มี 2 เฟส ซึ่งแสดงอย่างชัดเจนใน UI เป็นขั้นตอนที่ 1 จาก 2 และ ขั้นตอนที่ 2 จาก 2 ใต้แถบความคืบหน้า ขั้นตอนที่ 1 สอดคล้องกับการเขียนบล็อกข้อมูล ส่วนขั้นตอนที่ 2 คือการคอมไพล์ไฟล์ .dex ล่วงหน้า ทั้ง 2 เฟสนี้มีความแตกต่างกันอย่างมากในแง่ของ ผลกระทบต่อประสิทธิภาพ ระยะแรกคือ I/O อย่างง่าย การดำเนินการนี้ใช้ทรัพยากร (RAM, CPU, I/O) น้อยมากเนื่องจากเป็นการคัดลอกบล็อกอย่างช้าๆ

เฟสที่ 2 จะเรียกใช้ dex2oat เพื่อคอมไพล์ล่วงหน้าสำหรับอิมเมจระบบใหม่ ซึ่งแน่นอนว่าข้อกำหนดของฟีเจอร์นี้มีความชัดเจนน้อยกว่า เนื่องจากคอมไพล์แอปจริง และแน่นอนว่าการคอมไพล์แอปขนาดใหญ่และซับซ้อนต้องใช้เวลามากกว่าการคอมไพล์แอปขนาดเล็กและเรียบง่ายมาก ในขณะที่ระยะที่ 1 จะไม่มีบล็อกดิสก์ที่ใหญ่หรือซับซ้อนกว่าบล็อกอื่นๆ

กระบวนการนี้คล้ายกับตอนที่ Google Play ติดตั้งการอัปเดตแอปในเบื้องหลังก่อน แสดงการแจ้งเตือนอัปเดตแอป 5 รายการแล้ว ซึ่งดำเนินการมาหลายปีแล้ว

จะเกิดอะไรขึ้นหากผู้ใช้รอการอัปเดตอยู่

การใช้งานปัจจุบันใน GmsCore ไม่ได้แยกความแตกต่างระหว่างการอัปเดตในเบื้องหลังกับการอัปเดตที่ผู้ใช้เริ่ม แต่ในอนาคตอาจมีการแยกความแตกต่าง ในกรณีที่ผู้ใช้ขอให้ติดตั้งการอัปเดตอย่างชัดเจน หรือกำลังดูหน้าจอความคืบหน้าของการอัปเดต เราจะ จัดลําดับความสําคัญของการอัปเดตโดยสมมติว่าผู้ใช้กําลังรอให้การอัปเดตเสร็จสมบูรณ์

จะเกิดอะไรขึ้นหากอัปเดตไม่สำเร็จ

ในการอัปเดตแบบไม่ใช่ A/B หากการอัปเดตใช้ไม่ได้ ผู้ใช้มักจะเหลือเพียงอุปกรณ์ที่ใช้ไม่ได้ ข้อยกเว้นเพียงอย่างเดียวคือหากเกิดข้อผิดพลาดก่อนที่แอปพลิเคชันจะเริ่มทำงาน (เนื่องจากแพ็กเกจยืนยันไม่สำเร็จ เป็นต้น) การอัปเดต A/B ทำให้การอัปเดตไม่สำเร็จ ไม่ส่งผลต่อระบบที่กำลังทำงานอยู่ คุณลองอัปเดตอีกครั้งในภายหลังได้