การอัปเดตระบบแบบไดนามิกใน Android ถาม: Project Treble จะปรับปรุงเวอร์ชัน Android ในอนาคตอย่างไร

นอกเหนือจากการเปิดตัว Android 8.0 Oreo แล้ว Google ยังเปิดตัวอีกด้วย โครงการเสียงแหลม: การออกแบบสถาปัตยกรรมใหม่ที่สำคัญในลักษณะที่เฟรมเวิร์กระบบปฏิบัติการ Android และผู้จำหน่าย HAL และเคอร์เนล Linux สื่อสารกัน Treble เป็นความคิดริเริ่มที่สำคัญที่ออกแบบมาเพื่อลดเวอร์ชันแพลตฟอร์ม Android และ การกระจายตัวของแพตช์รักษาความปลอดภัยและอุปกรณ์แบรนด์ Android ทั้งหมดที่เปิดตัวด้วย Android Pie จะต้องรองรับ Project Treble OEM และผู้จำหน่ายทดสอบความเข้ากันได้ของ Treble โดยการบูต Generic System Image (GSI) ซึ่งเป็นโครงสร้าง Android ล้วนๆ จาก AOSP และส่งต่อ ชุดทดสอบผู้ขาย (VTS) และชุดทดสอบความเข้ากันได้บนอิมเมจระบบทั่วไป (CTS-on-GSI) GSI ได้รับการพิสูจน์แล้วว่ามีประโยชน์ไม่เพียงแต่ช่วยให้วิศวกรซอฟต์แวร์ที่ทำงานให้กับ OEM ทดสอบความเข้ากันได้ของ Treble เท่านั้น แต่ยังเปิดประตูสู่ ชุมชน ROM แบบกำหนดเองขนาดใหญ่ บน XDA สำหรับการเปิดตัว Android Q นั้น Google ต้องการทำให้ GSI มีประโยชน์สำหรับกลุ่มอื่น: นักพัฒนาแอป

นับตั้งแต่การเปิดตัวที่เสถียรครั้งแรกและการวางซอร์สโค้ดของแพลตฟอร์ม Android ใดๆ ก็ตามมักจะมา ในเดือนสิงหาคมนักพัฒนาที่ต้องการทดสอบ Android รุ่นถัดไปบนอุปกรณ์จริงมักจะต้องเข้าถึงสมาร์ทโฟน Google หากไม่ต้องการรอให้การอัปเดตไปถึงฮาร์ดแวร์ของตนเอง อย่างไรก็ตาม Google ทำงานร่วมกับ OEM เพื่อนำ Android P เบต้า ไปยังอุปกรณ์หลายเครื่องในปีที่แล้ว และพวกเขาได้ติดตามผลในปีนี้ด้วย Android Q เบต้า. นอกจาก Android Q เบต้าอย่างเป็นทางการแล้ว Google ในปีนี้ยังได้เปิดตัว Q เบต้า GSI อย่างเป็นทางการ ดังนั้นนักพัฒนาที่มีอุปกรณ์ที่เข้ากันได้กับ Project Treble จึงสามารถติดตั้ง Q release ล่าสุดได้โดยไม่ต้องรอเป็นเดือนกว่าที่ build จะเข้าถึงอุปกรณ์ของพวกเขา วิธีใหม่ในการทดสอบ Android รุ่นถัดไปนี้ทำให้นักพัฒนามีโอกาสมากขึ้นและมีเวลามากขึ้นในการทดสอบแอปของตน การเปลี่ยนแปลงครั้งสำคัญใน Android.

น่าเสียดายที่วิธีการปัจจุบันของ การติดตั้ง GSI อาจเป็นเรื่องยาก จำเป็นต้องปลดล็อค bootloader ซึ่งหมายถึงการล้างข้อมูลผู้ใช้ทั้งหมดและ/หรือทำให้การรับประกันเป็นโมฆะ และทำการแฟลชภาพผ่านโปรโตคอล fastboot ไม่ใช่กระบวนการที่ง่ายและรวดเร็วสำหรับนักพัฒนาแอปที่จะทำหากใช้อุปกรณ์ของตน ยังอนุญาตให้ปลดล็อค bootloader ได้. นั่นเป็นเหตุผลว่าทำไมสำหรับ หลายเดือนที่ผ่านมาGoogle ได้ดำเนินการหาวิธีใหม่ในการบูต GSI ป้อนคุณสมบัติใหม่ที่เรียกว่า Dynamic System Update หรือ DSU

(ฟีเจอร์นี้ได้รับการพัฒนาก่อนหน้านี้ภายใต้ชื่อ "Live Image" "Dynamic Android" และ "Android on Tap" ดังนั้นอย่าแปลกใจหาก Google เรียกมันว่าเป็นอย่างอื่นในอีกไม่กี่สัปดาห์หรือหลายเดือน)

การอัปเดตระบบไดนามิกใน Android Q

เป้าหมายของฟีเจอร์ DSU คือการอนุญาตให้นักพัฒนาบูตเข้าสู่ GSI โดยไม่รบกวนการติดตั้งปัจจุบัน นั่นหมายความว่าไม่จำเป็นต้องปลดล็อคโปรแกรมโหลดบูตและไม่จำเป็นต้องล้างข้อมูลผู้ใช้ กระบวนการติดตั้งยังง่ายขึ้นอย่างมาก เนื่องจาก Google ได้จัดเตรียมอินเทอร์เฟซบรรทัดคำสั่งผ่าน ADB และแอปที่สามารถควบคุมได้ผ่าน Intent ต่อไปนี้คือลักษณะที่ปรากฏในการบูต GSI โดยใช้ DSU:

ในวิดีโอนี้* Google Pixel 3 XL ที่ใช้ Android Q beta 3 จะรีบูตเข้าสู่ GSI ในสภาพแวดล้อมนี้ นักพัฒนาแอปสามารถติดตั้งและทดสอบแอปของตนเกี่ยวกับความเข้ากันได้ของ Q API เมื่อเสร็จสิ้นการทดสอบ พวกเขาสามารถรีบูตกลับเข้าสู่ซอฟต์แวร์ Q beta 3 ปกติบนอุปกรณ์ได้ โดยพื้นฐานแล้วคุณกำลังบูท GSI สองครั้งเพื่อให้คุณสามารถทดสอบแอปของคุณได้อย่างปลอดภัย!

*เราบันทึกวิดีโอนี้ที่ Google I/O 2019 เมื่อ DSU ยังไม่เผยแพร่ต่อสาธารณะ ดังนั้น Q beta 3 ที่สร้างจาก Pixel 3 XL ที่ถ่ายทำจึงได้รับการแก้ไขเล็กน้อยโดย Google เพื่อรวมการรองรับ DSU อุปกรณ์ที่ใช้ Q เบต้า 4 ขึ้นไปมีสิทธิ์รองรับ DSU หากมีคุณสมบัติตรงตามข้อกำหนดด้านล่าง

ข้อกำหนดสำหรับการอัปเดตระบบแบบไดนามิก

การได้รับสิ่งที่จำเป็นในการบูทและใช้งานคู่ไม่ใช่เรื่องง่ายสำหรับ Google ต้องทำการเปลี่ยนแปลงที่สำคัญกับวิธีจัดการพาร์ติชันบน Pixel 3 ซึ่งเป็นโปรแกรมทดสอบของ Google สำหรับ DSU ดังนั้นข้อกำหนดหลักประการแรกสำหรับการรองรับ DSU ก็คืออุปกรณ์นั้นรองรับ พาร์ติชันแบบไดนามิก. ไดนามิกพาร์ติชันเกี่ยวข้องกับพาร์ติชันพื้นที่เก็บข้อมูลจริงหนึ่งพาร์ติชัน ซึ่งแบ่งออกเป็นโลจิคัลพาร์ติชันที่ปรับขนาดได้ เช่น ระบบ ผู้จำหน่าย odm oem ผลิตภัณฑ์ ฯลฯ ในระหว่างการติดตั้ง GSI พื้นที่จะถูกสงวนไว้สำหรับระบบใหม่และพาร์ติชัน userdata โดยรับบล็อกที่ไม่ได้ใช้จากพาร์ติชัน userdata ที่มีอยู่ เนื่องจากพาร์ติชันใหม่เหล่านี้อาจมีขนาดได้หลายกิกะไบต์ การรองรับ DSU จึงเหมาะสมกับตรรกะเท่านั้น พาร์ติชัน มิฉะนั้นอุปกรณ์จะต้องสำรองพื้นที่เก็บข้อมูลหลายกิกะไบต์อย่างถาวรสำหรับ GSI การติดตั้ง

ข้อกำหนดอื่นๆ ได้แก่ ramdisk ซึ่งตัดสินใจว่าจะบูตเพื่อการกู้คืน ระบบ หรือโลจิคัลพาร์ติชัน และพาร์ติชันข้อมูลเมตาเพื่อจัดเก็บข้อมูลเมตาของ GSI โดยทั่วไป โครงสร้างสำหรับการรองรับ DSU คือข้อกำหนดในการเปิดตัว Android Qตามที่หัวหน้าโครงการ Treble Iliyan Malchev กล่าว เราไม่แน่ใจว่า ทุกอย่าง สิ่งที่จำเป็นในการรองรับ DSU คือข้อกำหนดในการเปิดตัว Android Q แต่เราสามารถสรุปได้ว่าอุปกรณ์ส่วนใหญ่หากไม่ใช่ทั้งหมดที่เปิดตัวด้วย Android Q สามารถ สนับสนุน DSU แม้ว่า Google จะไม่ได้กำหนดให้ทำก็ตาม จนถึงตอนนี้มีเพียง Pixel 3, Pixel 3 XL, Pixel 3a และ Pixel 3a XL เท่านั้นที่มีพาร์ติชันแบบไดนามิก และอุปกรณ์เหล่านี้มีเพียง Pixel 3 และ Pixel 3 XL เท่านั้นที่รองรับ DSU ใน Android Q beta 4 แม้ว่าไม่จำเป็นต้องมีการสนับสนุน DSU แต่ Google หวังว่า OEM จะเปิดใช้งานคุณลักษณะนี้ต่อไป เนื่องจากจะช่วยลดความยุ่งยากในการทดสอบความเข้ากันได้ของ Treble อย่างปลอดภัย ตัวอย่างเช่น วิศวกรซอฟต์แวร์ OEM สามารถใส่ GSI ได้ บนการ์ด SD เพื่อให้พวกเขาสามารถบูตบนอุปกรณ์หลายเครื่องได้อย่างรวดเร็วเพื่อทดสอบความเข้ากันได้ของ Treble

ความปลอดภัยสำหรับการอัปเดตระบบแบบไดนามิก

เนื่องจาก DSU แนะนำระบบปฏิบัติการตัวที่สองเป็นหลัก Google จึงต้องตรวจสอบให้แน่ใจว่าการติดตั้งใหม่นี้จะไม่ถูกแก้ไขเพื่อทำลายความสมบูรณ์ของอุปกรณ์ ดังนั้น มีการป้องกันความปลอดภัยขั้นพื้นฐานแบบเดียวกันสำหรับการติดตั้งดั้งเดิมสำหรับการติดตั้ง GSI: นโยบายการบูตที่ยืนยันแล้วของ Android และนโยบาย SELinux นอกจากนี้ เฉพาะแอปที่มีลายเซ็น INSTALL_DYNAMIC_SYSTEM|สิทธิ์พิเศษเท่านั้นที่สามารถเริ่มต้น GSI ได้ การติดตั้ง ในขณะที่แอปที่มีสิทธิ์ลายเซ็น MANAGE_DYNAMIC_SYSTEM สามารถเปิด/ปิดหรือล้าง GSI การติดตั้ง. ซึ่งหมายความว่าเฉพาะแอประดับระบบที่เชื่อถือได้เท่านั้นที่สามารถทำงานร่วมกับ DSU ได้

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

การติดตั้ง GSI

หากอุปกรณ์ของคุณรองรับ DSU เช่นซีรีส์ Pixel 3 การติดตั้ง GSI ก็เป็นเรื่องง่าย ก่อนอื่นคุณต้องตรวจสอบให้แน่ใจว่าได้เปิดใช้งานการตั้งค่าสถานะคุณลักษณะระบบไดนามิกผ่านวิธีใดวิธีหนึ่งจากสองวิธี:

1. หากคุณอยู่ในบิลด์ userdebug ให้เปิดใช้งานการตั้งค่าสถานะ settings_dynamic_android ในการตั้งค่า > ระบบ > ตัวเลือกนักพัฒนา > การตั้งค่าสถานะคุณลักษณะ
2. หากคุณอยู่ในบิลด์ผู้ใช้ ให้รันคำสั่ง adb shell ต่อไปนี้:

   setproppersist.sys.fflag.override.settings_dynamic_system 1

จากนั้นดาวน์โหลด Android Q beta GSI ล่าสุดจาก Google หรือ OEM ของอุปกรณ์ของคุณ (DSU อนุญาตให้ติดตั้ง GSI ที่ลงนามโดย Google หรือ OEM เท่านั้น) เมื่อดาวน์โหลดแล้ว ให้ใช้งาน simg2img เพื่อแปลงภาพที่กระจัดกระจายเป็นภาพดิบ ใช้ gzip เพื่อแพ็คอิมเมจ Raw จากนั้นคัดลอกไฟล์เก็บถาวรผลลัพธ์ไปยังตำแหน่งบนอุปกรณ์ของคุณ ที่จัดเก็บข้อมูลภายนอก (เช่น /data/media/0/Download) หรือสื่อจัดเก็บข้อมูลภายนอกจริง (เช่น SD จริง การ์ด). สุดท้าย ให้เปิดแอป DynamicSystemInstallationService ด้วยจุดประสงค์ที่ถูกต้องเพื่อเริ่มการติดตั้ง:

adb shell am start-activity \ -n com.android.dynsystem/com.android.dynsystem.VerificationActivity \ -a android.os.image.action.START_INSTALL \ -d file:///storage/emulated/0/Download/system_raw.gz \ --el KEY_SYSTEM_SIZE $(du -b system_raw.img|cut -f1) \ --el KEY_USERDATA_SIZE 8589934592

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

คุณสามารถดูคำแนะนำในการติดตั้ง GSI ฉบับเต็มสำหรับ DSU ได้ ที่นี่. สามารถแจ้งข้อบกพร่องได้ที่ เครื่องมือติดตามปัญหาของ Googleเรดดิต, หรือ กองล้น.

เหตุผลเบื้องหลังการอัปเดตระบบไดนามิก

เมื่อฉันพูดคุยกับ Iliyan Malchev ที่ Google I/O เขาได้ย้ำสิ่งที่ Hung-ying Tyan จากทีม Treble พูดเกี่ยวกับการเข้าถึง GSI ในระยะเริ่มต้นที่ การประชุมสุดยอด Android Dev ประจำเดือนพฤศจิกายน. Google ตั้ง DSU เป็น ขอคำติชมจากผู้ชมในวงกว้างมากที่สุด. เป้าหมายคือการปรับปรุงคุณภาพของ GSI ซึ่งในทางกลับกัน ปรับปรุงคุณภาพของการเปิดตัว Android ในอนาคต เนื่องจาก GSI เป็นรูปแบบ Android ที่บริสุทธิ์ที่สุด ปัจจุบัน Google เป็นบริษัทเดียวที่ทดสอบความเข้ากันได้ของ GSI เวอร์ชันถัดไป (เช่น อิมเมจระบบ Android Q ทำงานบน Android P ได้ดีเพียงใด การใช้งานของผู้ขาย) แต่เมื่อมีคนแฟลช GSI และให้ข้อเสนอแนะมากขึ้น OEM ก็สามารถแก้ไขการละเมิดความเข้ากันได้ของ Treble ได้ ดังนั้น GSI จะทำงานได้ดียิ่งขึ้นใน อนาคต. Iliyan กล่าวว่ามีความสนใจอย่างมากจาก OEM และผู้จำหน่ายเช่น Qualcomm ในการนำอิมเมจของผู้จำหน่ายจาก Android รุ่นก่อนหน้ากลับมาใช้ใหม่พร้อมกับอิมเมจระบบเวอร์ชันถัดไป โครงการริเริ่มเช่น DSU ช่วยให้ Google และ OEM อุดช่องว่างความครอบคลุมจากการทดสอบอัตโนมัติ เช่น VTS และ CTS-on-GSI ดังนั้น Google จึงได้รับผู้ทดสอบเบต้ามากขึ้นเพื่อให้ข้อเสนอแนะเกี่ยวกับ Android รุ่นถัดไป ในขณะเดียวกันก็ได้ยินเกี่ยวกับการละเมิดความเข้ากันได้ของ Treble เพื่อให้ OEM สามารถปรับปรุงงานของพวกเขาได้

ยินดีต้อนรับการเพิ่ม Dynamic System Updates ใน Android Q แต่จะไม่ใช่โซลูชันดูอัลบูตที่บางท่านคาดหวัง ตามที่กล่าวไว้ก่อนหน้านี้ สามารถติดตั้งได้เฉพาะอิมเมจระบบที่ลงนามโดย Google หรือ OEM เท่านั้น เมื่อฉันถาม Iliyan เกี่ยวกับความเป็นไปได้ในการขยาย DSU เพื่อรองรับระบบนิเวศของ Android ทางเลือก เขากล่าวว่าในทางเทคนิคแล้ว DSU เป็นเพียงช่องทางในการส่งมอบระบบเท่านั้น ภาพ OEM ใดๆ ก็สามารถใช้งานได้ตามที่ต้องการ ตราบใดที่ผลลัพธ์สุดท้ายเป็นไปตามมาตรฐาน Android. Google ไม่ได้สร้างทางเลือกอื่นแทนระบบ OTA ที่นี่ และ DSU ไม่ได้ตั้งใจเพื่อใช้สำหรับการบูทคู่อย่างแท้จริง ไม่ว่างานที่ Google ทำบน Treble กำลังทำให้ Android เป็นโมดูลาร์มากขึ้น ดังนั้นฉันจะไม่แปลกใจเลยหากการบูทคู่แบบเนทีฟจะกลายเป็นความจริงในเร็วๆ นี้