Android Q में स्कोप्ड स्टोरेज डेवलपर्स को SAF का उपयोग करने के लिए मजबूर करता है, जो बेकार है

click fraud protection

Android Q में स्कोप्ड स्टोरेज परिवर्तन से निपटना एक सिरदर्द है, क्योंकि स्टोरेज एक्सेस फ्रेमवर्क में अभी कुछ खामियां हैं।

Android Q आपके फ़ोन पर स्टोरेज के काम करने के तरीके को मौलिक रूप से बदल रहा है। पाई तक के हर संस्करण में, एंड्रॉइड का स्टोरेज एक डेस्कटॉप कंप्यूटर की तरह काम करता था: आप किसी भी फ़ाइल को पढ़ने या लिखने के लिए किसी भी ऐप का उपयोग कर सकते हैं (यदि आप ऐप को ऐसा करने की अनुमति देते हैं)। Q के साथ, Google "प्रस्तुत कर रहा है (और इसकी आवश्यकता है)"स्कोप्ड स्टोरेज," जो एंड्रॉइड को एक आईफोन की तरह काम करता है, जहां प्रत्येक ऐप के लिए स्टोरेज अलग-अलग होता है। कोई ऐप केवल अपनी फ़ाइलों तक पहुंच सकता है, और यदि इसे अनइंस्टॉल किया जाता है, तो इसकी सभी फ़ाइलें हटा दी जाती हैं।

शुक्र है कि Android Q अभी भी केंद्रीय फ़ाइल सिस्टम के Android के कुछ मूल व्यवहार को बरकरार रखता है। दुर्भाग्य से, अब उपयोगकर्ता के लिए इसे एक्सेस करने के लिए ऐप्स सेट करना बोझिल हो गया है और इससे प्रदर्शन और क्षमता काफी कम हो गई है। और डेवलपर्स को इसका समर्थन करने के लिए ऐप्स को काफी हद तक रीकोड करना होगा।

ऐसे ऐप्स जिन्हें सामान्य फ़ाइल सिस्टम एक्सेस की आवश्यकता होती है, उदा. एक ऑफिस सुइट, छवि संपादक, या फ़ाइल प्रबंधक को अब एंड्रॉइड एपीआई का उपयोग करने की आवश्यकता होगी जिसे "

स्टोरेज एक्सेस फ्रेमवर्क" (एसएएफ), सभी फ़ाइल परिचालनों के लिए। एसएएफ एंड्रॉइड 5.0 लॉलीपॉप के बाद से उपलब्ध है, लेकिन डेवलपर्स इसका उपयोग तब तक नहीं करते जब तक कि इसकी आवश्यकता न हो, क्योंकि इसकी कठिन और खराब क्षमता है। प्रलेखित एपीआई, खराब उपयोगकर्ता अनुभव, खराब प्रदर्शन और खराब विश्वसनीयता (बड़े पैमाने पर डिवाइस विक्रेता-विशिष्ट कार्यान्वयन के रूप में)। समस्याएँ)। SAF में परिवर्तन में कठिनाई के परिणामस्वरूप, Google ने उन ऐप्स को अनुमति देने का निर्णय लिया है जो अभी तक संकेत नहीं देते हैं Android Q समर्थन पहले की तरह काम करेगा, लेकिन यह तब बदल जाएगा जब Play Store को सभी ऐप्स को Q का समर्थन करने की आवश्यकता होगी अगले वर्ष।

एसएएफ के साथ सबसे स्पष्ट उपयोगकर्ता-सामना वाला परिवर्तन किसी ऐप को स्टोरेज तक पहुंच प्रदान करने का अनुभव है। किसी ऐप को एक्सेस प्राप्त करने के लिए, यह ओएस से अनुरोध करता है, जो तब एक निर्देशिका चयनकर्ता स्क्रीन प्रदर्शित करता है। इस स्क्रीन पर उपयोगकर्ता एक फ़ोल्डर पदानुक्रम के रूट का चयन करता है जिसमें वह ऐप फ़ाइलों को पढ़ने और लिखने में सक्षम होगा। उपयोगकर्ता को प्रत्येक ऐप के लिए इस प्रक्रिया से गुजरना होगा जिसके लिए स्थानीय फ़ाइलों तक पहुंच की आवश्यकता होती है, या यदि उन्हें बाहरी एसडी कार्ड तक पहुंच प्रदान करने की आवश्यकता होती है तो प्रति ऐप दो बार जाना होगा।

Google ने कम से कम इस प्रक्रिया में सुधार तो किया क्यू बीटा 3, क्योंकि पहले बीटा ने किसी ऐप को उपयोगकर्ता के चयन के लिए कोई स्थान सुझाने की भी अनुमति नहीं दी थी, जो उपयोगकर्ता को काफी काम करने की आवश्यकता होती है वास्तव में उनके डिवाइस का प्राथमिक भंडारण ढूंढने के लिए।

SAF के तहत फ़ाइल I/O प्रदर्शन में कुछ हद तक कमी आती है, लेकिन सबसे बड़ी समस्या फ़ाइल में है निर्देशिका संचालन, जहां यह पारंपरिक फ़ाइल पहुंच की तुलना में ~25 से 50 गुना धीमा है पाई. फ़ाइल प्रबंधकों के मामले में, इसका मतलब है कि खोज और भंडारण उपयोग गणना करने में काफी अधिक समय लगेगा। एक प्रदर्शन ऐप के साथ एक बग रिपोर्ट है यहां उपलब्ध है।

SAFTest का नमूना परीक्षण SAF के साथ पारंपरिक फ़ाइल I/O API के बीच प्रदर्शन अंतर दिखाता है।

इससे भी बड़ा प्रदर्शन मुद्दा यह है कि कुछ ऐप्स को फ़ाइलों के साथ काम करने से पहले उन्हें अपने स्थानीय "स्कोप्ड स्टोरेज" क्षेत्र में कॉपी करना होगा। यह तब समस्याग्रस्त हो सकता है जब ऐसी फ़ाइलें कई गीगाबाइट आकार की हों, उदाहरण के लिए वीडियो फ़ाइलों या संपीड़ित अभिलेखागार के मामले में। कई एंड्रॉइड ऐप डेवलपर समुदाय में ओपन-सोर्स जावा लाइब्रेरी की अद्भुत संख्या का लाभ उठाते हैं, और इन लाइब्रेरी को काम करने के लिए आमतौर पर सीधे फाइल सिस्टम एक्सेस की आवश्यकता होती है। वे एंड्रॉइड-विशिष्ट नहीं हैं और एसएएफ के साथ काम करने के लिए उन्हें पुनः लिखने की आवश्यकता होगी। इससे भी बुरी बात यह है कि एंड्रॉइड की कई आंतरिक लाइब्रेरी इसके साथ काम नहीं करेंगी, जैसे पैकेज मैनेजर या ज़िप एपीआई। उदाहरण के तौर पर, एक फ़ाइल प्रबंधक संपूर्ण एपीके को अपने दायरे वाले भंडारण क्षेत्र में कॉपी किए बिना एपीके फ़ाइल (मानक एंड्रॉइड एपीआई का उपयोग करके) के लिए आइकन प्रदर्शित करने में भी सक्षम नहीं होगा। बग रिपोर्ट।

तकनीकी रूप से इच्छुक लोगों के लिए, वर्तमान में एपॉप्स कमांड का उपयोग करके एडीबी के माध्यम से प्रति-ऐप आधार पर एंड्रॉइड क्यू के "स्कोप्ड स्टोरेज" को अक्षम करना संभव है। रूट उपयोगकर्ता डेस्कटॉप कंप्यूटर के बिना सीधे अपने डिवाइस पर कमांड निष्पादित कर सकते हैं। ऐसे आदेशों को दस्तावेज़ीकरण में डेवलपर सुविधाओं के रूप में वर्णित किया गया है और इस प्रकार इन्हें किसी भी समय हटाया जा सकता है।

किसी ऐप के लिए सामान्य संग्रहण एक्सेस सक्षम करें:

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 इस परिवर्तन के सुरक्षा और गोपनीयता लाभों का दावा करता है, लेकिन तकनीकी रूप से कहें तो कोई सुधार नहीं हुआ है। एंड्रॉइड 1.0 के बाद से ऐप्स में फ़ाइलों को निजी तौर पर संग्रहीत करने की क्षमता है, और लगभग सभी ऐप्स इस क्षमता का उपयोग करते हैं। जब आप किसी ऐप को SAF के माध्यम से अपने स्टोरेज की रूट डायरेक्टरी तक पहुंच प्रदान करते हैं, तो यह किसी भी फाइल को पढ़, लिख और भेज सकता है अपने नापाक डेवलपर को ठीक उसी अंदाज में चाहता है, जब आपने किसी ऐप को पाई में स्टोरेज तक पहुंच प्रदान की थी।

एकमात्र "सुरक्षा सुधार" इसलिए होता है क्योंकि अब उपयोगकर्ता के लिए ऐसा करना अधिक कठिन प्रक्रिया है। बेशक, जब तक कोई ऐप केवल आपकी सबसे निजी जानकारी, जैसे कि आपके फ़ोटो और वीडियो, चुराना न चाहे लिया गया, जिसके लिए Google ने एक वैकल्पिक एक्सेस समाधान जोड़ा है जो एक साधारण पॉप-अप क्लिक-यस सुरक्षा का उपयोग करता है संवाद.

यह ज्ञात नहीं है कि Google इस परिवर्तन से क्या लाभ प्राप्त करना चाहता है। Android Q बीटा दस्तावेज़ में आधिकारिक तौर पर बताया गया कारण "उपयोगकर्ताओं को उनकी फ़ाइलों पर अधिक नियंत्रण देना और फ़ाइल को सीमित करना है अव्यवस्था।" स्कोप्ड स्टोरेज, अपने वर्तमान स्वरूप में, उपयोगकर्ता को जो करने की अनुमति है उसकी एक नई सीमा है, न कि उनके नियंत्रण। अव्यवस्था कम करने का दावा कुछ हद तक वैध हो सकता है, लेकिन केवल इसलिए क्योंकि परिवर्तन से फ़ाइलों का उपयोग करने की क्षमता बिल्कुल कम हो जाती है। और "अव्यवस्था" तब और बढ़ जाती है जब आप कुछ ऐप्स की समस्या पर विचार करते हैं जिनके साथ काम करने के लिए उन्हें डुप्लिकेट फ़ाइलों की आवश्यकता होती है।

यदि Google वास्तव में उपयोगकर्ताओं को फ़ाइलों और अव्यवस्थाओं पर अधिक नियंत्रण देने के बारे में चिंतित है, तो उन्हें इसकी योजना बनानी चाहिए ऐसा समाधान जो वर्तमान Android Q डिज़ाइन को गलत तरीके से ब्रांड करने के बजाय सीधे उसका समाधान करता है सुधार। सबसे सरल उत्तर यह होगा कि उपयोगकर्ताओं को मौजूदा स्टोरेज अनुमति अनुरोध संवाद का उपयोग करके यह तय करने दिया जाए कि क्या वे किसी ऐप को स्कोप्ड या सामान्य फ़ाइल सिस्टम एक्सेस चाहते हैं। यदि यहां खराब निर्णय लेने वाले उपयोगकर्ताओं के लिए कोई विशेष चिंता है, तो यह निश्चित रूप से संभव है उस संवाद को अधिक प्रमुख बनाएं और किसी ऐप को पूर्ण रूप से स्वीकृत करने के लिए अतिरिक्त उपयोगकर्ता सहभागिता की आवश्यकता हो पहुँच।

एंड्रॉइड उपयोगकर्ताओं को उनकी फ़ाइलों पर अधिक नियंत्रण कैसे दे सकता है इसका उत्तर वास्तव में उपयोगकर्ताओं को अधिक नियंत्रण देना है, न कि इसे छीनना और एंड्रॉइड प्लेटफ़ॉर्म की क्षमताओं को मौलिक रूप से बाधित करना है।


संपादक का नोट: यह XDA के वरिष्ठ सदस्य द्वारा लिखा गया एक अतिथि लेख है tliebeck, अपने काम के लिए सबसे ज्यादा जाने जाते हैं एफएक्स फ़ाइल एक्सप्लोरर. इस लेख की सामग्री XDA-डेवलपर्स के प्रधान संपादक मिशाल रहमान के न्यूनतम इनपुट और संपादन के साथ, एंड्रॉइड Q के स्कोप्ड स्टोरेज प्रतिबंधों के बारे में उनकी अपनी राय और विश्लेषण को दर्शाती है। हमने इनमें से कुछ चिंताओं के बारे में पूछने के लिए Google से संपर्क किया, लेकिन प्रकाशन के समय तक कंपनी से कोई जवाब नहीं मिला।