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

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

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

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

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