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

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

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

ได้ ชื่อทางการตลาดสำหรับการอัปเดต A/B คือการอัปเดตที่ราบรื่น โทรศัพท์ Pixel และ Pixel XL ตั้งแต่เดือนตุลาคม 2016 มาพร้อมกับ A/B และ Chromebook ทั้งหมดใช้การติดตั้งใช้งาน A/B เดียวกันupdate_engine การใช้โค้ดแพลตฟอร์มที่จําเป็นจะพร้อมใช้งานแบบสาธารณะใน 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 (.dex ที่เพิ่มประสิทธิภาพ) จะแยกจากไฟล์ .apk และอาจมีโค้ดเครื่องเฉพาะสำหรับอุปกรณ์ หากมีไฟล์ .odex อยู่ Android จะเรียกใช้แอปพลิเคชันด้วยความเร็วที่คอมไพล์ไว้ล่วงหน้าได้โดยไม่ต้องรอให้คอมไพล์โค้ดทุกครั้งที่เปิดแอปพลิเคชัน ไฟล์ .odex นั้นไม่จำเป็นอย่างเคร่งครัด เนื่องจาก Android สามารถเรียกใช้โค้ด .dex ได้โดยตรงผ่านการตีความหรือการคอมไพล์แบบทันท่วงที (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 เมื่อบูตเครื่องครั้งแรก พื้นที่เก็บข้อมูลจริงที่ใช้กับ ext4 A/B จะเหมือนกับ SquashFS A/B เนื่องจากหากเราใช้ 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 ใน /data มี 2 สำเนาใช่ไหม

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

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

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

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

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

ระบบจะเขียนข้อมูลแฟลชเพียงส่วนเล็กๆ เท่านั้น การอัปเดตระบบ Pixel แบบสมบูรณ์จะเขียนข้อมูลประมาณ 2.3 GB (ระบบจะคอมไพล์แอปอีกครั้งด้วย แต่การคอมไพล์ใหม่นี้จะเกิดขึ้นกับเวอร์ชันที่ไม่ใช่ 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/+/main/packages/SystemUI/AndroidManifest.xml#23) ซึ่งปัจจุบัน system_server ใช้อยู่เนื่องจากไม่อนุญาตให้ใช้ JIT ด้วยเหตุผลด้านความปลอดภัย

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

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

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

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

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

ไม่ การบูตที่ยืนยันแล้วของ Android จำเป็นต้องมีการอัปเดตแบบบล็อกเสมอ แต่ไม่จำเป็นต้องเป็นการอัปเดต A/B

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

ไม่

OTA แบบ A/B ละเมิดการป้องกันการย้อนกลับของ AVB2.0 ไหม

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

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

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

การอัปเดต 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 การอัปเดตไม่สำเร็จจะไม่ส่งผลต่อระบบที่ทำงานอยู่ในปัจจุบัน คุณลองอัปเดตอีกครั้งในภายหลังได้