Scoped Storage ใน Android Q บังคับให้นักพัฒนาใช้ SAF ซึ่งแย่มาก

การเปลี่ยนแปลง Scoped Storage ใน Android Q เป็นเรื่องที่น่าปวดหัวที่ต้องจัดการ เนื่องจาก Storage Access Framework มีข้อบกพร่องเล็กน้อยในขณะนี้

Android Q กำลังเปลี่ยนแปลงวิธีการจัดเก็บข้อมูลบนโทรศัพท์ของคุณโดยพื้นฐาน ในทุกเวอร์ชันจนถึง Pie พื้นที่เก็บข้อมูลของ Android ทำงานเหมือนกับคอมพิวเตอร์เดสก์ท็อป: คุณสามารถใช้แอปใดก็ได้ที่คุณต้องการอ่านหรือเขียนไฟล์ใดก็ได้ (หากคุณให้สิทธิ์แอปในการดำเนินการดังกล่าว) ด้วย Q Google กำลังแนะนำ (และต้องการ) "พื้นที่เก็บข้อมูลที่มีการกำหนดขอบเขต," ซึ่งทำให้ Android ทำงานเหมือนกับ iPhone มากขึ้น โดยที่พื้นที่เก็บข้อมูลจะแยกออกจากกันในแต่ละแอป แอปสามารถเข้าถึงเฉพาะไฟล์ของตัวเองเท่านั้น และหากถอนการติดตั้ง ไฟล์ทั้งหมดจะถูกลบ

โชคดีที่ Android Q ยังคงรักษาพฤติกรรมดั้งเดิมของระบบไฟล์ส่วนกลางของ Android ไว้ น่าเสียดายที่ขณะนี้ผู้ใช้ต้องตั้งค่าแอปให้เข้าถึงได้ยาก และทำให้ประสิทธิภาพและความสามารถลดลงอย่างมาก และนักพัฒนาจะต้องเขียนโค้ดใหม่ให้กับแอพจำนวนมากเพื่อรองรับ

แอพที่ต้องการการเข้าถึงระบบไฟล์ทั่วไป เช่น ตอนนี้ชุดโปรแกรมสำนักงาน โปรแกรมแก้ไขรูปภาพ หรือตัวจัดการไฟล์จะต้องใช้ Android API ที่เรียกว่า "

กรอบการเข้าถึงพื้นที่เก็บข้อมูล" (SAF) สำหรับการทำงานของไฟล์ทั้งหมด SAF มีให้บริการตั้งแต่ Android 5.0 Lollipop แต่นักพัฒนามักจะไม่ใช้งานเว้นแต่จำเป็น เนื่องจากมีความยากและไม่ดี API ที่บันทึกไว้ ประสบการณ์ผู้ใช้ที่ไม่ดี ประสิทธิภาพต่ำ และความน่าเชื่อถือต่ำ (ส่วนใหญ่อยู่ในรูปแบบของการใช้งานเฉพาะของผู้จำหน่ายอุปกรณ์ ปัญหา). เนื่องจากความยากลำบากในการเปลี่ยนไปใช้ SAF Google จึงตัดสินใจอนุญาตแอปที่ยังไม่ได้ระบุ การรองรับ Android Q จะทำงานเหมือนเดิม แต่จะเปลี่ยนไปเมื่อ Play Store ต้องการให้แอปทั้งหมดรองรับ Q ปีหน้า.

การเปลี่ยนแปลงที่ผู้ใช้เผชิญอย่างชัดเจนที่สุดกับ SAF คือประสบการณ์ในการอนุญาตให้แอปเข้าถึงพื้นที่เก็บข้อมูล เพื่อให้แอปเข้าถึงได้ แอปจะส่งคำขอไปยังระบบปฏิบัติการ ซึ่งจากนั้นจะแสดงหน้าจอตัวเลือกไดเร็กทอรี บนหน้าจอนี้ ผู้ใช้เลือกรากของลำดับชั้นโฟลเดอร์ที่แอปนั้นจะสามารถอ่านและเขียนไฟล์ได้ ผู้ใช้จะต้องทำตามขั้นตอนนี้สำหรับแต่ละแอปที่ต้องเข้าถึงไฟล์ในเครื่อง หรือสองครั้งต่อแอป หากจำเป็นต้องให้สิทธิ์การเข้าถึงการ์ด SD ภายนอกด้วย

อย่างน้อย Google ก็ปรับปรุงกระบวนการนี้เพื่อ คิวเบต้า 3เนื่องจากรุ่นเบต้าก่อนหน้านี้ไม่อนุญาตให้แอปแนะนำตำแหน่งให้ผู้ใช้เลือกด้วยซ้ำ ต้องการให้ผู้ใช้ทำงานไม่น้อย เพื่อค้นหาพื้นที่เก็บข้อมูลหลักของอุปกรณ์จริงๆ

ประสิทธิภาพของไฟล์ I/O ได้รับผลกระทบบ้างภายใต้ SAF แต่ปัญหาที่โดดเด่นที่สุดอยู่ที่ไฟล์ การดำเนินการไดเร็กทอรีซึ่งช้ากว่าการเข้าถึงไฟล์ทั่วไปประมาณ 25 ถึง 50 เท่า พาย. ในกรณีของตัวจัดการไฟล์ นั่นหมายความว่าจะใช้เวลาในการค้นหาและคำนวณการใช้พื้นที่เก็บข้อมูลนานขึ้น รายงานข้อผิดพลาดพร้อมแอปสาธิตคือ มีอยู่ที่นี่

การทดสอบการทำงานของ SAFTest แสดงให้เห็นความแตกต่างด้านประสิทธิภาพระหว่าง File I/O API ทั่วไปกับ SAF

ปัญหาด้านประสิทธิภาพที่ยิ่งใหญ่กว่านั้นคือบางแอปจะต้องคัดลอกไฟล์ไปยังพื้นที่ "ที่เก็บข้อมูลที่กำหนดขอบเขต" ในเครื่องก่อนจึงจะสามารถทำงานร่วมกับแอปเหล่านั้นได้ นี่อาจเป็นปัญหาได้เมื่อไฟล์ดังกล่าวมีขนาดหลายกิกะไบต์ เช่น ในกรณีของไฟล์วิดีโอหรือไฟล์บีบอัด แอพ Android จำนวนมากใช้ประโยชน์จากไลบรารี Java โอเพ่นซอร์สจำนวนมหาศาลในชุมชนนักพัฒนา และโดยทั่วไปไลบรารีเหล่านี้ต้องการการเข้าถึงระบบไฟล์โดยตรงจึงจะทำงานได้ ไม่ใช่เฉพาะ Android และจำเป็นต้องเขียนใหม่จึงจะทำงานร่วมกับ SAF ได้ ที่แย่กว่านั้นคือไลบรารีภายในของ Android จำนวนมากใช้งานไม่ได้ เช่น ตัวจัดการแพ็คเกจหรือ zip API ในกรณีนี้ ตัวจัดการไฟล์จะไม่สามารถแสดงไอคอนสำหรับไฟล์ APK ได้ (โดยใช้ Android API มาตรฐาน) หากไม่ได้คัดลอก APK ทั้งหมดไปยังพื้นที่จัดเก็บข้อมูลที่กำหนดขอบเขตของตัวเองก่อน รายงานข้อผิดพลาด

สำหรับผู้ที่มีแนวโน้มทางเทคนิค ขณะนี้สามารถปิดการใช้งาน "Scoped Storage" ของ Android Q ในแต่ละแอปผ่าน ADB โดยใช้คำสั่ง appops ผู้ใช้รูทสามารถดำเนินการคำสั่งได้โดยตรงบนอุปกรณ์ของตนโดยไม่ต้องใช้คอมพิวเตอร์เดสก์ท็อป คำสั่งดังกล่าวอธิบายไว้ในเอกสารประกอบว่าเป็นคุณสมบัติของนักพัฒนา และอาจลบออกได้ตลอดเวลา

เปิดใช้งานการเข้าถึงที่เก็บข้อมูลทั่วไปสำหรับแอป:

adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-name

ปิดใช้งานการเข้าถึงที่เก็บข้อมูลทั่วไปสำหรับแอป:

adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-name

Google กล่าวถึงประโยชน์ด้านความปลอดภัยและความเป็นส่วนตัวของการเปลี่ยนแปลงนี้ แต่ในทางเทคนิคแล้ว ยังไม่มีการปรับปรุง แอพมีความสามารถในการจัดเก็บไฟล์แบบส่วนตัวตั้งแต่ Android 1.0 และแอพเกือบทั้งหมดใช้ประโยชน์จากความสามารถนี้ เมื่อคุณให้สิทธิ์แอปเข้าถึงไดเร็กทอรีรากของพื้นที่จัดเก็บข้อมูลของคุณผ่าน SAF แอปจะสามารถอ่าน เขียน และส่งไฟล์ใดๆ ได้ ต้องการให้นักพัฒนาที่ชั่วร้ายในลักษณะเดียวกับที่คุณอนุญาตให้แอปเข้าถึงพื้นที่เก็บข้อมูลใน Pie

"การปรับปรุงความปลอดภัย" เพียงอย่างเดียวเกิดขึ้นเนื่องจากขณะนี้เป็นกระบวนการที่ยากขึ้นสำหรับผู้ใช้ในการดำเนินการนี้ เว้นแต่ว่าแอปต้องการเพียงขโมยข้อมูลส่วนบุคคลส่วนใหญ่ของคุณ เช่น รูปภาพและวิดีโอที่คุณมี ดำเนินการ ซึ่ง Google ได้เพิ่มโซลูชันการเข้าถึงทางเลือกซึ่งใช้การรักษาความปลอดภัยแบบป๊อปอัปคลิกใช่แบบง่าย กล่องโต้ตอบ

ไม่มีใครรู้ว่า Google หวังว่าจะบรรลุประโยชน์อะไรจากการเปลี่ยนแปลงนี้ เหตุผลที่ระบุไว้อย่างเป็นทางการในเอกสารประกอบ Android Q เบต้าคือ “ให้ผู้ใช้ควบคุมไฟล์ได้มากขึ้นและเพื่อจำกัดไฟล์” ถ่วง." พื้นที่จัดเก็บที่กำหนดขอบเขตในรูปแบบปัจจุบันถือเป็นข้อจำกัดใหม่ของสิ่งที่ผู้ใช้ได้รับอนุญาตให้ทำ ไม่ใช่การขยายขอบเขต ควบคุม. การอ้างสิทธิ์ในการลดความยุ่งเหยิงอาจค่อนข้างถูกต้อง แต่เพียงเพราะการเปลี่ยนแปลงลดความสามารถในการใช้ไฟล์เลย และ “ความยุ่งเหยิง” จะเพิ่มขึ้นเมื่อคุณพิจารณาถึงปัญหาของบางแอปที่ต้องทำซ้ำไฟล์เพื่อทำงานกับแอปเหล่านั้น

หาก Google กังวลอย่างแท้จริงเกี่ยวกับการให้ผู้ใช้ควบคุมไฟล์และความยุ่งเหยิงได้มากขึ้น พวกเขาควรออกแบบ โซลูชันที่จัดการเรื่องนั้นโดยตรง แทนที่จะสร้างแบรนด์การออกแบบ Android Q ในปัจจุบันอย่างไม่ถูกต้องเช่นนี้ การปรับปรุง. คำตอบที่ง่ายที่สุดคือให้ผู้ใช้ตัดสินใจว่าต้องการให้แอปมีการเข้าถึงระบบไฟล์แบบกำหนดขอบเขตหรือแบบทั่วไปหรือไม่ โดยใช้กล่องโต้ตอบคำขอสิทธิ์พื้นที่เก็บข้อมูลที่มีอยู่ หากมีความกังวลเป็นพิเศษสำหรับผู้ใช้ที่ตัดสินใจไม่ดีที่นี่ ก็สามารถทำได้อย่างแน่นอน ทำให้กล่องโต้ตอบนั้นโดดเด่นยิ่งขึ้น และต้องมีการโต้ตอบจากผู้ใช้เพิ่มเติมเพื่ออนุมัติแอปอย่างเต็มรูปแบบ เข้าถึง.

คำตอบว่า Android จะให้ผู้ใช้ควบคุมไฟล์ได้มากขึ้นได้อย่างไรคือการให้ผู้ใช้ควบคุมได้มากขึ้นจริงๆ ไม่ใช่เอามันออกไป และจำกัดความสามารถของแพลตฟอร์ม Android โดยพื้นฐาน


หมายเหตุบรรณาธิการ: นี่เป็นบทความรับเชิญที่เขียนโดย XDA Senior Member ทลีเบ็คที่รู้จักกันดีจากผลงานของเขา FX File Explorer. เนื้อหาของบทความนี้สะท้อนถึงความคิดเห็นและการวิเคราะห์ของเขาเองเกี่ยวกับข้อจำกัดพื้นที่เก็บข้อมูลขอบเขตของ Android Q โดยมีการป้อนข้อมูลและการแก้ไขเพียงเล็กน้อยจาก Mishaal Rahman หัวหน้าบรรณาธิการของ XDA-Developers เราติดต่อ Google เพื่อสอบถามเกี่ยวกับข้อกังวลเหล่านี้ แต่ยังไม่ได้รับการตอบกลับจากบริษัทภายในเวลาที่เผยแพร่