ภาพรวม A/B เสมือนจริง

A/B เสมือนเป็นกลไกการอัปเดตหลักของ Android A/B เสมือนจะอิงตามการอัปเดต A/B เดิม (ดูการอัปเดตระบบ A/B) และไม่ใช่ A/B ซึ่งเลิกใช้งานใน 15 เพื่อลดพื้นที่ในการอัปเดต

จริงๆ แล้ว A/B เสมือนไม่มีสล็อตเพิ่มเติมสําหรับพาร์ติชันแบบไดนามิก โปรดดูพาร์ติชันแบบไดนามิก แต่ระบบจะเขียนข้อมูล Delta ลงในสแนปชอต แล้วผสานเข้ากับพาร์ติชันฐานหลังจากยืนยันว่าการบูตสำเร็จ การทดสอบ A/B เสมือนใช้รูปแบบสแนปชอตเฉพาะของ Android ดูรูปแบบ COW สำหรับสแนปชอตที่บีบอัด ซึ่งช่วยให้บีบอัดสแนปชอตและลดการใช้พื้นที่ในดิสก์ได้ เมื่อใช้การบีบอัดใน OTA แบบเต็ม ขนาดสแนปชอตจะลดลงประมาณ 45% และขนาดสแนปชอต OTA แบบเพิ่มจะลดลงประมาณ 55%

Android 12 มีตัวเลือกการบีบอัด A/B เสมือนจริงเพื่อบีบอัดพาร์ติชันที่บันทึกภาพไว้ การทดสอบ A/B เสมือนมีข้อดีดังนี้

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

ความเป็นมาและคำศัพท์

ส่วนนี้จะอธิบายคําศัพท์และเทคโนโลยีที่รองรับการทดสอบ A/B เสมือนจริง ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในช่องใหม่สำหรับพาร์ติชันจริง หรืออุปกรณ์ COW สำหรับ Android โดยเฉพาะ หลังจากรีบูตอุปกรณ์แล้ว ระบบจะผสานข้อมูลพาร์ติชันแบบไดนามิกกลับไปยังอุปกรณ์พื้นฐานผ่านการใช้ dm-user และเดรัม snapuserd กระบวนการนี้จะดำเนินการทั้งหมดในพื้นที่ผู้ใช้

Device-mapper

Device-mapper เป็นเลเยอร์บล็อกเสมือนของ Linux ที่ใช้บ่อยใน Android เมื่อใช้พาร์ติชันแบบไดนามิก พาร์ติชันอย่าง /system จะเป็นกองอุปกรณ์ที่ซ้อนกัน ดังนี้

  • ที่ด้านล่างของกองคือพาร์ติชัน super จริง (เช่น /dev/block/by-name/super)
  • ตรงกลางคืออุปกรณ์ dm-linear ซึ่งระบุบล็อกในซุปเปอร์พาร์ติชันที่ประกอบกันเป็นพาร์ติชันแบบไดนามิกที่ระบุ ซึ่งจะปรากฏเป็น /dev/block/mapper/system_[a|b] ในอุปกรณ์ A/B หรือ /dev/block/mapper/system ในอุปกรณ์ที่ไม่ใช่ A/B
  • ที่ด้านบนจะมีอุปกรณ์ dm-verity ที่สร้างขึ้นสำหรับพาร์ติชันที่ยืนยันแล้ว อุปกรณ์นี้จะยืนยันว่าบล็อกในอุปกรณ์ dm-linear ได้รับการเซ็นชื่ออย่างถูกต้อง โดยจะปรากฏเป็น /dev/block/mapper/system-verity และเป็นที่มาของจุดมา운ต์ /system

รูปที่ 1 แสดงลักษณะของสแต็กใต้จุดมา운ต์ /system

การซ้อนพาร์ติชันใต้ระบบ

รูปที่ 1 สแต็กใต้จุดต่อเชื่อม /system

สแนปชอตที่บีบอัด

ใน Android 12 ขึ้นไป เนื่องจากข้อกำหนดด้านพื้นที่ในพาร์ติชัน /data อาจสูง คุณจึงเปิดใช้สแนปชอตแบบบีบอัดในบิลด์เพื่อตอบสนองข้อกำหนดด้านพื้นที่ที่สูงขึ้นของพาร์ติชัน /data ได้

ภาพรวมแบบ A/B ที่บีบอัดเสมือนสร้างขึ้นจากคอมโพเนนต์ต่อไปนี้ซึ่งพร้อมใช้งานใน Android 12 ขึ้นไป

  • dm-user ซึ่งเป็นโมดูลเคอร์เนลที่คล้ายกับ FUSE ซึ่งช่วยให้พื้นที่ผู้ใช้ใช้อุปกรณ์บล็อกได้
  • snapuserd ซึ่งเป็นเดรัมใน Userspace เพื่อใช้รูปแบบสแนปชอตใหม่

คอมโพเนนต์เหล่านี้ช่วยให้การบีบอัดทำงานได้ การเปลี่ยนแปลงอื่นๆ ที่จำเป็นซึ่งทำเพื่อใช้ความสามารถของสแนปชอตแบบบีบอัดมีอยู่ในหัวข้อต่อไปนี้ รูปแบบ COW สำหรับสแนปชอตแบบบีบอัด, dm-user และ snapuserd

รูปแบบ COW สำหรับสแนปชอตที่บีบอัด

ใน Android 12 ขึ้นไป สแนปชอตที่บีบอัดจะใช้รูปแบบ COW สำหรับ Android โดยเฉพาะ รูปแบบ COW มีข้อมูลเมตาเกี่ยวกับ OTA และบัฟเฟอร์ที่แตกต่างกันซึ่งมีการดำเนินการ COW และข้อมูลระบบปฏิบัติการใหม่ เมื่อเทียบกับรูปแบบสแนปชอตเคอร์เนลที่อนุญาตเฉพาะการดำเนินการแทนที่ (แทนที่บล็อก X ในอิมเมจฐานด้วยเนื้อหาของบล็อก Y ในสแนปชอต) รูปแบบ COW ของสแนปชอตที่บีบอัดของ Android นั้นมีความยืดหยุ่นมากกว่าและรองรับการดำเนินการต่อไปนี้

  • คัดลอก: ควรแทนที่บล็อก X ในอุปกรณ์ฐานด้วยบล็อก Y ในอุปกรณ์ฐาน
  • แทนที่: ควรแทนที่เนื้อหาของบล็อก X ในอุปกรณ์ฐานด้วยเนื้อหาของบล็อก Y ในสแนปชอต แต่ละบล็อกมีการบีบอัด gz
  • ศูนย์: ควรแทนที่บล็อก X ในอุปกรณ์ฐานด้วยศูนย์ทั้งหมด
  • XOR: อุปกรณ์ COW จะจัดเก็บไบต์ที่บีบอัดด้วย XOR ระหว่างบล็อก X กับบล็อก Y (ใช้ได้ใน Android 13 ขึ้นไป)

การอัปเดต OTA แบบสมบูรณ์ประกอบด้วยการดำเนินการแทนที่และศูนย์เท่านั้น การอัปเดต OTA แบบเพิ่มทีละน้อยอาจมีการดำเนินการคัดลอกเพิ่มเติม

เลย์เอาต์สแนปชอตแบบเต็มบนดิสก์จะมีลักษณะดังนี้

รูปแบบวัว

รูปที่ 2 รูปแบบ COW ของ Android ในดิสก์

dm-user

โมดูลเคอร์เนล dm-user ช่วยให้ userspace ใช้อุปกรณ์บล็อก Device Mapper ได้ รายการตาราง dm-user จะสร้างอุปกรณ์อื่นๆ ในส่วน /dev/dm-user/<control-name> กระบวนการ userspace สามารถโพลอุปกรณ์เพื่อรับคําขออ่านและเขียนจากเคอร์เนล คำขอแต่ละรายการจะมีบัฟเฟอร์ที่เชื่อมโยงกันสำหรับพื้นที่ผู้ใช้เพื่อสร้าง (สําหรับการอ่าน) หรือเผยแพร่ (สําหรับการเขียน)

โมดูลเคอร์เนล dm-user มีอินเทอร์เฟซใหม่ที่ผู้ใช้มองเห็นได้สำหรับเคอร์เนล ซึ่งไม่ได้เป็นส่วนหนึ่งของฐานโค้ด upstream ของ kernel.org ในระหว่างนี้ Google ขอสงวนสิทธิ์ในการเปลี่ยนแปลงอินเทอร์เฟซ dm-user ใน Android

snapuserd

คอมโพเนนต์พื้นที่ผู้ใช้ snapuserd ไปยัง dm-user ใช้การบีบอัด A/B เสมือน Snapuserd เป็นเดรัมน์สเปซผู้ใช้ที่รับผิดชอบการเขียนและอ่านอุปกรณ์ COW ของ Android I/O ทั้งหมดไปยังสแนปชอตต้องผ่านบริการนี้ ในระหว่างการติดตั้ง OTA ระบบจะเขียนข้อมูลระบบปฏิบัติการใหม่ลงในสแนปชอตโดย snapuserd (มีการบีบอัด) นอกจากนี้ ระบบจะจัดการการแยกวิเคราะห์ข้อมูลเมตาและการแตกไฟล์ข้อมูลบล็อกใหม่ที่นี่ด้วย

การบีบอัด XOR

สำหรับอุปกรณ์ที่เปิดตัวด้วย Android 13 ขึ้นไป ฟีเจอร์การบีบอัด XOR ซึ่งเปิดใช้โดยค่าเริ่มต้นจะเปิดใช้สแนปชอตพื้นที่ผู้ใช้เพื่อจัดเก็บไบต์ที่บีบอัดด้วย XOR ระหว่างบล็อกเก่ากับบล็อกใหม่ เมื่อมีการอัปเดต A/B เสมือนและมีการเปลี่ยนแปลงเพียงไม่กี่ไบต์ในบล็อก รูปแบบพื้นที่เก็บข้อมูลการบีบอัด XOR จะใช้พื้นที่น้อยกว่ารูปแบบพื้นที่เก็บข้อมูลเริ่มต้น เนื่องจากสแนปชอตไม่ได้จัดเก็บข้อมูล 4K ไบต์เต็ม การลดขนาดภาพรวมนี้เป็นไปได้เนื่องจากข้อมูล XOR มีเลข 0 จำนวนมากและบีบอัดได้ง่ายกว่าข้อมูลบล็อกดิบ ในอุปกรณ์ Pixel การบีบอัด XOR จะลดขนาดภาพนิ่งลง 25-40%

สำหรับอุปกรณ์ที่อัปเกรดเป็น Android 13 ขึ้นไป คุณต้องเปิดใช้การบีบอัด XOR โปรดดูรายละเอียดที่หัวข้อการบีบอัด XOR

การผสานสแนปชอต

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

ต่อไปนี้อธิบายกระบวนการบีบอัด A/B เสมือน

  1. เฟรมเวิร์กจะต่อเชื่อมพาร์ติชัน /system จากอุปกรณ์ dm-verity ซึ่งวางซ้อนกันบนอุปกรณ์ dm-user ซึ่งหมายความว่าระบบจะกำหนดเส้นทาง I/O ทั้งหมดจากระบบไฟล์รูทไปยัง dm-user
  2. dm-user จะกำหนดเส้นทาง I/O ไปยัง D snapuserd ของพื้นที่ผู้ใช้ ซึ่งจะจัดการคำขอ I/O
  3. เมื่อการผสานเสร็จสมบูรณ์แล้ว เฟรมเวิร์กจะยุบ dm-verity ไว้ด้านบนของ dm-linear (system_base) และนํา dm-user ออก

กระบวนการบีบอัด A/B เสมือนจริง

รูปที่ 3 กระบวนการบีบอัด A/B เสมือน

กระบวนการผสานสแนปชอตอาจถูกขัดจังหวะ หากรีบูตอุปกรณ์ระหว่างกระบวนการผสาน ระบบจะผสานต่อหลังจากรีบูต

การเปลี่ยนผ่าน Init

เมื่อบูตด้วยสแนปชอตที่บีบอัด อินิจต์ระยะที่ 1 จะต้องเริ่มต้นขึ้นเพื่อมาунтพาร์ติชัน snapuserd การดำเนินการนี้ทำให้เกิดปัญหา เมื่อโหลดและบังคับใช้ sepolicy ระบบจะใส่ snapuserd ไว้ในบริบทที่ไม่ถูกต้อง และคำขออ่านของ sepolicy จะดำเนินการไม่สำเร็จเนื่องจากถูกปฏิเสธโดย SELinux

snapuserd จึงเปลี่ยนไปพร้อมกับ init ดังนี้

  1. init ระยะที่ 1 จะเปิด snapuserd จากแรมดิสก์ และบันทึกตัวบ่งชี้ไฟล์ที่เปิดอยู่ไปยังตัวแปรสภาพแวดล้อม
  2. init ระยะที่ 1 จะเปลี่ยนระบบไฟล์รูทเป็นพาร์ติชันระบบ แล้วเรียกใช้สำเนาระบบของ init
  3. ระบบจะอ่าน init ที่คัดลอกไว้เป็นสตริง
  4. Init เรียกใช้ mlock() ในหน้าทั้งหมดที่ใช้ ext4 จากนั้นจะปิดใช้งานตารางเครื่องแมปอุปกรณ์ทั้งหมดสำหรับอุปกรณ์สแนปชอต และหยุด snapuserd หลังจากนี้ ระบบจะไม่อนุญาตให้อ่านจากพาร์ติชัน เนื่องจากจะทำให้เกิดปัญหาการล็อกตาย
  5. init ใช้ตัวระบุแบบเปิดไปยังสำเนาแรมดิสก์ของ snapuserd เพื่อเปิดใช้โปรแกรมเดรัมอีกครั้งด้วยบริบท selinux ที่ถูกต้อง ตาราง Device-mapper สำหรับอุปกรณ์สแนปชอตจะเปิดใช้งานอีกครั้ง
  6. Init เรียกใช้ munlockall() - คุณสามารถดำเนินการ IO อีกครั้งได้

การใช้พื้นที่ทำงาน

ตารางต่อไปนี้แสดงการเปรียบเทียบการใช้พื้นที่สำหรับกลไก OTA แบบต่างๆ โดยใช้ขนาดระบบปฏิบัติการและ OTA ของ Pixel

ผลกระทบด้านขนาด ไม่ใช่ A/B A/B การทดสอบ A/B เสมือน A/B เสมือน (บีบอัด)
รูปภาพต้นฉบับจากโรงงาน 4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่สงวนไว้)1 9 GB Super (3.8 GB + 700 MB สำรองไว้สำหรับ 2 ช่อง) 4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่จองไว้) 4.5 GB Super (ภาพ 3.8 GB + 700 MB ที่จองไว้)
พาร์ติชันแบบคงที่อื่นๆ /cache ไม่มี ไม่มี ไม่มี
พื้นที่เก็บข้อมูลเพิ่มเติมระหว่าง OTA (พื้นที่ว่างที่คืนหลังจากใช้ OTA) 1.4 GB ใน /data 0 3.8 GB2 ใน /data 2.1 GB2 ใน /data
พื้นที่เก็บข้อมูลทั้งหมดที่จําเป็นในการใช้ OTA 5.9 GB3 (Super และ Data) 9 GB (Super) 8.3 GB3 (Super และ Data) 6.6 GB3 (Super และข้อมูล)

1 ระบุเลย์เอาต์ที่คาดการณ์ตามการแมปพิกเซล

2 ถือว่าภาพระบบใหม่มีขนาดเท่ากับภาพต้นฉบับ

3 พื้นที่ทำงานที่ต้องการจะหายไปชั่วคราวจนกว่าจะรีบูต

การทดสอบ A/B เสมือนของ Android 11

Android 11 ของ Virtual A/B เขียนลงในพาร์ติชันแบบไดนามิกโดยใช้รูปแบบ COW ของเคอร์เนล ในที่สุดเราก็เลิกใช้งานรูปแบบนี้เนื่องจากรูปแบบ COW ของเคอร์เนลไม่รองรับการบีบอัด

การทดสอบ A/B เสมือนของ Android 12

ใน Android 12 ระบบจะรองรับการบีบอัดในรูปแบบ COW สำหรับ Android โดยเฉพาะ A/B เสมือนจริงเวอร์ชันนี้จำเป็นต้องมีการแปล COW สำหรับ Android โดยเฉพาะเป็นรูปแบบ COW ของเคอร์เนล ในที่สุดก็มีการแทนที่รูปแบบนี้ใน Android 13 ซึ่งนำการพึ่งพารูปแบบ COW ของเคอร์เนลและ dm-snapshot ออก

หากต้องการใช้ Virtual A/B หรือใช้ความสามารถของสแนปชอตแบบบีบอัด โปรดดูหัวข้อการใช้ Virtual A/B