Android 11 จะมาพร้อมกับ DSU Loader ภายในตัวเลือกสำหรับนักพัฒนาที่จะให้คุณดาวน์โหลดและติดตั้ง GSI ที่เข้ากันได้โดยอัตโนมัติ! อ่านเพิ่มเติม!
ระบบนิเวศของแอพที่ดีเป็นหนึ่งในเสาหลักที่สำคัญที่สุดของความสำเร็จของระบบปฏิบัติการ ทั้ง Google และ Apple ตระหนักถึงคุณค่าของการมีแอปพลิเคชันที่ดีบนแพลตฟอร์มของตน ดังนั้นทั้งสองบริษัทจึงพยายามสร้างสมดุลระหว่างความต้องการของผู้ใช้และนักพัฒนาแอปของตน ผู้ใช้ยังคงผลักดันให้เกิดการเปลี่ยนแปลงใน OS และในขณะที่คนส่วนใหญ่ชื่นชอบคุณสมบัติใหม่เหล่านี้ การเปลี่ยนแปลงไม่ใช่เรื่องสนุกเสมอไปสำหรับนักพัฒนาแอป เนื่องจากสามารถเปลี่ยนแปลงฟังก์ชันการทำงานหลักได้หลายอย่างและ พฤติกรรม. สำหรับนักพัฒนาที่ทำงานอย่างต่อเนื่องเพื่อให้แอปของตนมีความเกี่ยวข้อง การรับมือกับการเปลี่ยนแปลงเหล่านี้จะเพิ่มเข้าไปในรายการงานที่เพิ่มขึ้น แม้ว่าการเปลี่ยนแปลงเหล่านี้จะไม่ส่งผลกระทบโดยตรงต่อแอปพลิเคชันของตน แต่นักพัฒนายังคงต้องตรวจสอบให้แน่ใจว่าแอปของตนจะทำงานบนการอัปเดตระบบปฏิบัติการใหม่ Google ได้ทำการเปลี่ยนแปลงหลายอย่างในช่วงหลายปีที่ผ่านมาเพื่อทำให้ขั้นตอนนี้ง่ายขึ้นสำหรับนักพัฒนาแอป Android และตอนนี้คือการเปลี่ยนแปลงใหม่ ฟีเจอร์ใน Android 11 ที่เรียกว่า DSU Loader จะช่วยให้นักพัฒนาแอปทดสอบแอปบน Android ใหม่ได้ง่ายยิ่งขึ้น รุ่น
มันเริ่มต้นด้วย Project Treble
Project Treble ซึ่งเปิดตัวใน Android 8.0 ถือเป็นสิ่งสำคัญ ออกแบบสถาปัตยกรรมใหม่ของระบบปฏิบัติการ Android. เป้าหมายของ Project Treble คือการแบ่งระบบปฏิบัติการ Android ออกเป็นสองส่วนใหญ่ๆ ได้แก่ เฟรมเวิร์กและการใช้งานของผู้จำหน่าย ("ผู้ขาย" ในที่นี้หมายถึงผู้ผลิตส่วนประกอบฮาร์ดแวร์ที่เป็นกรรมสิทธิ์ซึ่งพบภายในอุปกรณ์ โดยปกติจะหมายถึง ซิลิคอน). เฟรมเวิร์กระบบปฏิบัติการ Android คือตัวระบบปฏิบัติการเอง รวมถึงแอพระบบทั้งหมด UI และส่วนประกอบ และ API ที่ใช้ร่วมกันในอุปกรณ์ Android การดำเนินการของผู้ขายประกอบด้วย HAL ของผู้ขาย (Hardware Abstraction Layers) และเคอร์เนล Linux และโมดูลเคอร์เนล Linux
เนื่องจาก OEM จัดส่งสมาร์ทโฟนที่มีส่วนประกอบฮาร์ดแวร์ต่างๆ มากมายจากผู้จำหน่ายหลายราย พวกเขาจึงต้องทำงานอย่างหนักเพื่อให้ฮาร์ดแวร์พร้อมใช้งานบนระบบปฏิบัติการ Android รุ่นเดียว จากนั้นในการอัปเดตระบบปฏิบัติการ Android ใหม่แต่ละครั้ง พวกเขาต้องทำงานมากขึ้นเพื่อให้แน่ใจว่าฮาร์ดแวร์ของพวกเขาใช้งานได้กับเวอร์ชันใหม่ แต่ด้วย Project Treble ที่สร้างมาตรฐาน ABI (Application Binary Interface) ระหว่างเฟรมเวิร์กระบบปฏิบัติการ Android และ HAL สำหรับเวอร์ชัน Android โดยเฉพาะ Android OEM สามารถเริ่มทดสอบการอัปเดตอุปกรณ์ของตนได้โดยไม่ต้องรอให้ผู้ผลิตซิลิกอนและผู้ผลิตส่วนประกอบอื่นๆ อัปเดตด้านของตน รหัส. การเปลี่ยนแปลงนี้เร็วขึ้นอย่างเห็นได้ชัด วิธีจัดการกับการอัปเดต Android.
นั่นคือส่วนสำคัญของสิ่งที่ Project Treble ทำเพื่อการอัปเดต Android แต่สิ่งที่สำคัญกว่าสำหรับแอป นักพัฒนาในที่นี้คือ Treble ได้เปิดใช้งานการใช้ Generic System Image (GSIs) เพื่อความเข้ากันได้ การทดสอบ
การเกิดขึ้นของ GSI
เพื่อให้ OEM ทดสอบว่าพวกเขาติดตั้ง Project Treble อย่างถูกต้องหรือไม่ Google กำหนดให้ OEM สามารถบูต Android เวอร์ชันใหม่ทั้งหมดจาก AOSP บนอุปกรณ์ได้ โครงสร้างใหม่ของ Android นี้เรียกว่า Generic System Image หรือ GSI หากบูท GSI และฮาร์ดแวร์พื้นฐานส่วนใหญ่ทำงานได้อย่างถูกต้อง OEM จะรู้ว่าอุปกรณ์ของตนตรงตามข้อกำหนดของ Project Treble ดังนั้น จุดประสงค์เริ่มต้นของ GSI จึงมีไว้สำหรับทดสอบความเข้ากันได้ของเสียงแหลม แต่จากที่เราได้เห็นกับชุมชนนักพัฒนาที่ XDA-Developers ที่นี่ พวกมันสามารถใช้เพื่อวัตถุประสงค์อื่นได้ เราเห็นว่า GSIs เป็นอย่างไร โดยพื้นฐานแล้วสามารถอนุญาตให้อุปกรณ์ที่มี Android UX ขนาดใหญ่สามารถเพลิดเพลินกับ Android เวอร์ชันล่าสุดพร้อมคุณสมบัติการทำงานได้ภายในไม่กี่วันหลังจากออกรุ่นใหม่ แต่ Google มองเห็นจุดประสงค์อื่นที่อยู่เบื้องหลัง GSI นั่นคือการให้นักพัฒนาแอปสามารถทดสอบแอปของตนบน Android เวอร์ชันใหม่บนอุปกรณ์จริงที่ตนมีอยู่แล้ว
ด้วย Android 10 Google ได้เปิดตัว GSI builds ของตนเองสำหรับนักพัฒนา Google ประสานแนวคิดที่ว่านักพัฒนาแอปควรใช้ GSI เพื่อบูต Android เวอร์ชันใหม่ทั้งหมดบนฮาร์ดแวร์ของตนเอง ทำให้ง่ายต่อการทดสอบพฤติกรรมของแอปพลิเคชันเทียบกับ Android สต็อก วิธีนี้จึงเพิ่มตัวเลือกที่มีอยู่สำหรับการทดสอบความเข้ากันได้ของแอพในสต็อก Android โดยไม่มีการเปลี่ยนแปลงพฤติกรรมของ OEM ซึ่งวิธีอื่นๆ โดยใช้สมาร์ทโฟน Pixel ใช้ Android Emulator อย่างเป็นทางการภายใน Android Studio หรือปรับใช้แอปบิลด์กับอินสแตนซ์ของอุปกรณ์บนคลาวด์
แม้จะมีความสะดวกทั้งหมดที่ GSI นำมาให้ การติดตั้งยังคงเป็นกระบวนการที่ยุ่งยาก นักพัฒนาแอปอาจไม่พอใจกับการแฟลชอิมเมจระบบด้วยตนเองบนอุปกรณ์ Android เนื่องจากเป็นสิ่งที่มักมีเฉพาะมือสมัครเล่นหรือนักพัฒนาระบบปฏิบัติการ Android เท่านั้นที่คุ้นเคย การติดตั้ง GSI จำเป็นต้องแฟลชอิมเมจระบบผ่าน fastboot ซึ่งต้องปิดใช้งาน Android Verified Boot และปลดล็อก bootloader ในทางกลับกัน การปลดล็อก Bootloader จำเป็นต้องล้างข้อมูลผู้ใช้ทั้งหมด และอย่างที่เราทราบกันดีว่าไม่มีกระบวนการหรือแนวทางเดียวในการปลดล็อก bootloader ของอุปกรณ์ Android ทุกเครื่องดังนั้นจึงไม่มีความสอดคล้องกัน ตัวอย่างเช่น อุปกรณ์ Samsung ไม่มี fastboot ในขณะที่อุปกรณ์ Xiaomi ให้คุณกระโดดข้ามห่วงเพื่อปลดล็อก bootloader เป็นระเบียบที่สะดวกสบายซึ่งมีศักยภาพในการคลายให้เป็นสิ่งที่ง่ายกว่า
นี่คือที่มาของการอัปเดตระบบแบบไดนามิก
การอัปเดตระบบแบบไดนามิกเพียงแค่ติดตั้ง GSI
Google ตระหนักว่าวิธีการติดตั้ง GSI ในปัจจุบันไม่ใช่โซลูชันที่สมบูรณ์แบบ ดังนั้นพวกเขาจึงเริ่มทำงานเพื่อหาโซลูชันที่ดีกว่า ใน Android 10, Google เริ่มทดสอบการอัปเดตระบบแบบไดนามิกหรือ สทศ. DSU เป็นวิธีใหม่ในการติดตั้ง GSI ชั่วคราวโดยไม่จำเป็นต้องใช้คำสั่ง fastboot เพื่อแฟลชอิมเมจระบบ เขียนทับการติดตั้งเดิม ด้วย DSU คุณสามารถบูตเข้าสู่ GSI ทดสอบแอปของคุณ แล้วรีบูตกลับเข้าสู่การติดตั้งดั้งเดิมของคุณได้อย่างสะดวกสบายซึ่งยังคงไม่ถูกแตะต้อง
เหตุผลที่ DSU สามารถติดตั้ง GSI ได้โดยไม่ต้องแตะต้องการติดตั้งดั้งเดิมก็คือ DSU จะสร้างอิมเมจพาร์ติชันระบบและข้อมูลใหม่ที่เก็บไว้ชั่วคราวใน /data/gsi. อิมเมจเหล่านี้จะถูกเมาต์ระหว่างการบู๊ตแทนที่จะเป็นระบบเดิมและพาร์ติชันข้อมูล เนื่องจากโทรศัพท์ต้องการพื้นที่จัดเก็บเพิ่มเติมสำหรับรูปภาพชั่วคราวใหม่เหล่านี้ โทรศัพท์ของคุณจึงต้องมี "โลจิคัลพาร์ติชัน" อยู่ในเครื่อง ซึ่งเป็นพาร์ติชันที่ปรับขนาดได้แบบไดนามิก โลจิคัลพาร์ติชันคือระบบแบ่งพาร์ติชันพื้นที่ผู้ใช้ใหม่สำหรับ Android ซึ่งจำเป็นสำหรับอุปกรณ์ที่เปิดตัวด้วย Android 10 หากอุปกรณ์ของคุณเปิดตัวด้วย Android 10 อุปกรณ์นั้นควรรองรับการติดตั้ง GSI ผ่าน DSU
ใน Android 10 สิ่งที่คุณต้องทำทั้งหมด ติดตั้ง GSI ผ่าน DSU คือการเปลี่ยนคุณสมบัติระบบแล้วเปิดใช้ DynamicSystemUpdatesInstallationService โดยส่งเจตจำนงพร้อมพาธไปยัง GSI เป็นเจตจำนงพิเศษ
แม้ว่าขั้นตอนนี้อาจดูไม่คุ้นเคย แต่ก็ง่ายกว่ามากและรบกวนน้อยกว่าเมื่อเปรียบเทียบกับการใช้ คำสั่ง fastboot และการจัดการกับความยุ่งยากในทุกสิ่ง รวมถึงการติดตั้งดั้งเดิม เช็ด คุณต้องมีความรู้เกี่ยวกับ ADB และความตั้งใจที่จะใช้ประโยชน์จาก DSU แต่สิ่งนี้ไม่ควรเป็นปัญหาสำหรับนักพัฒนาแอปส่วนใหญ่ ถึงกระนั้น ก็ไม่มีเหตุผลใดที่กระบวนการนี้จะไม่ง่ายไปกว่านี้อีกแล้ว นอกจากนี้ยังมีข้อเท็จจริงที่ว่าการติดตั้ง GSI ผ่าน DSU ยังต้องการให้คุณปลดล็อก bootloader โดยล้างข้อมูลผู้ใช้ทั้งหมดในกระบวนการ ด้วยเหตุนี้ Google จึงดำเนินการเปลี่ยนแปลงเพื่อปรับปรุงการติดตั้ง GSI ทั้งสองด้าน ใน Android 11 พวกเขาไม่จำเป็นต้องใช้บรรทัดคำสั่งเลยในการติดตั้ง GSI นอกจากนี้ยังทำให้สามารถติดตั้ง GSI ได้โดยไม่ต้องปลดล็อก bootloader
DSU Loader ใน Android 11
DSU Loader เป็นเครื่องมือใหม่ที่มีอยู่ในตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ของ Android 11 ที่ให้คุณทำได้ ดาวน์โหลด และ ติดตั้ง GSI ล่าสุดจาก Google โดยไม่จำเป็นต้องป้อนคำสั่ง fastboot หรือ ADB เพียงแตะตัวเลือก DSU Loader ภายในการตั้งค่า จากนั้นกล่องโต้ตอบจะปรากฏขึ้นพร้อมกับรายการ GSI ที่รองรับโดยตรงจาก Google GSI ที่รองรับเหล่านี้จะอิงตามระบบปฏิบัติการและสถาปัตยกรรมปัจจุบันของคุณ ดังนั้นคุณจึงสามารถติดตั้งได้เฉพาะ GSI ที่ใหม่กว่าเวอร์ชันระบบปฏิบัติการของคุณและตรงกับสถาปัตยกรรม SoC ของคุณ เพียงเลือก GSI ที่คุณต้องการติดตั้ง จากนั้นระบบจะดาวน์โหลดจากเซิร์ฟเวอร์ของ Google และติดตั้งในเบื้องหลังโดยอัตโนมัติ
ด้วย DSU Loader นักพัฒนาไม่จำเป็นต้องแตะบรรทัดคำสั่งเพื่อติดตั้ง GSI อย่างน้อยนั่นคือความฝัน เพราะยังมีอีกหนึ่งประเด็นที่ต้องแก้ไข
ทางข้างหน้า
ในปัจจุบัน ในการติดตั้ง GSI ผ่าน DSU Loader คุณต้องมี bootloader ที่ปลดล็อค แม้ว่าสิ่งนี้อาจทำลายจุดประสงค์ของการทดสอบทั้งหมด แต่ก็ไม่ควรจะเป็นเช่นนั้น และเราได้รับแจ้งว่ามันจะได้รับการแก้ไข Google ได้วางแผนให้ผู้ใช้สามารถบูต GSI ที่ลงนามโดย Google ผ่าน DSU โดยไม่จำเป็นต้องปลดล็อก bootloader ในความเป็นจริง Google มอบอำนาจให้ทำเช่นนั้น อุปกรณ์เปิดใช้ Android 10 ทั้งหมดมีคีย์สาธารณะของ Android Verified Boot ของ Android 10, Android 11 และ Android 12 GSI ที่ลงนามโดย Google การรวมคีย์สาธารณะ AVB ใน ramdisk ของอุปกรณ์จะช่วยให้แน่ใจว่า AVB จะไม่ปฏิเสธ GSI ที่คุณกำลังพยายามบูต นี่คือสาเหตุที่วิธีการปัจจุบันเกี่ยวข้องกับการปลดล็อก bootloader - โดยการแฟลชอิมเมจ vbmeta ที่ว่างเปล่าไปยังพาร์ติชัน vbmeta คุณจะปิดการใช้งาน AVB เพื่อไม่ให้ GSI ที่คุณกำลังจะแฟลช การปิดใช้งาน AVB เป็นความเสี่ยงด้านความปลอดภัยที่สำคัญ เนื่องจากหมายความว่ามีการแก้ไขใดๆ สามารถโหลดพาร์ติชัน system/boot/product/vendor ลงในอุปกรณ์ได้ ซึ่งเป็นเหตุผลที่ Google ต้องการทำ ออกไปตามข้อกำหนดนั้น
ดังนั้นเมื่อใดที่คุณจะบูต GSI ผ่าน DSU โดยไม่ต้องปลดล็อก bootloader หรือใช้เครื่องมือบรรทัดคำสั่งใด ๆ หวังว่าเร็ว ๆ นี้ตามที่ Google บอกกับเราว่าพวกเขามีข้อผิดพลาดเล็กน้อยในการเผยแพร่ตัวอย่างนักพัฒนาซอฟต์แวร์ Android 11 เริ่มต้นก่อนที่พวกเขาจะสามารถทำงานได้อย่างถูกต้อง จากนี้ไป เราสามารถติดตั้ง Developer Preview GSI ในอนาคตผ่าน DSU โดยไม่จำเป็นต้องปลดล็อก bootloader บางทีเมื่อ Android 12 Developer Previews พร้อมใช้งาน คุณจะสามารถบูตได้ทั้งหมดโดยใช้ DSU Loader ในตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ของ Android 11 สำหรับนักพัฒนาแอป หมายความว่าจะมีอีกวิธีหนึ่งสำหรับคุณในการทดสอบแอปพลิเคชันของคุณบนฮาร์ดแวร์จริงที่ใช้ Android เวอร์ชันใหม่