हर किसी के लिए, जो सब कुछ के बावजूद, सही विकल्प बनाने में कामयाब रहा।

यह कॉमन्सवेयर से मार्क मर्फी के लेखों की एक श्रृंखला का अनुवाद है, जो कि स्टैवर्डोफ़्लो पर व्यापक रूप से जाना जाता है, साथ ही साथ "एंड्रॉइड के आर्किटेक्चर कंपोनेंट्स" पुस्तकों के लेखक "द व्यस्त कोडर गाइड टू एंड्रॉइड डेवलपमेंट" भी हैं। कुछ शब्दों का विशेष रूप से अनुवाद नहीं किया गया है।

आंतरिक भंडारण

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

क्या उपयोगकर्ता आंतरिक भंडारण पर विचार करते हैं

आपके डिवाइस के मॉडल के आधार पर, उपयोगकर्ता अंततः सेटिंग्स में आ जाएंगे -> अपने डिवाइस या एक समतुल्य स्थान पर भंडारण, और "इंटरनल स्टोरेज" का वर्णन करने वाली स्क्रीन देख सकते हैं ।

उपयोगकर्ता को लगता है कि संपूर्ण अंतर्निहित फ्लैश ड्राइव "आंतरिक संग्रहण" है। सौभाग्य से, Google ने "आंतरिक भंडारण" के बजाय "सामान्य भंडारण" की ओर बढ़ते हुए, एंड्रॉइड 8.0 के साथ इस शब्द को बदलना शुरू कर दिया।

हालाँकि, उपयोगकर्ता अभी भी "आंतरिक भंडारण" जैसे कि विंडोज एक्सप्लोरर विंडो जैसी जगहों पर देख सकते हैं जब उनका डिवाइस यूएसबी के माध्यम से जुड़ा हुआ है।

क्या Google आंतरिक संग्रहण को सुरक्षित रखता है

काश, उपयोगकर्ताओं को जो दिखता है वह वैसा नहीं है जैसा कि एंड्रॉइड एसडीके "आंतरिक भंडारण" को मानता है, जिससे कुछ भ्रम होता है। यदि आप आंतरिक भंडार पर Android दस्तावेज़ पढ़ते हैं , तो यह विवरण ... कम से कम धूमिल है (लेखन के समय से पाठ बदल गया है):

आप डिवाइस की आंतरिक मेमोरी में फ़ाइलों को सीधे सहेज सकते हैं। डिफ़ॉल्ट रूप से, आंतरिक संग्रहण में संग्रहीत फ़ाइलें आपके एप्लिकेशन के लिए निजी होती हैं, और अन्य एप्लिकेशन उन्हें (साथ ही उपयोगकर्ता) एक्सेस नहीं कर सकते हैं। जब उपयोगकर्ता एप्लिकेशन को अनइंस्टॉल करता है, तो ये फ़ाइलें हटा दी जाती हैं।

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

संदर्भ में कुछ बुनियादी विधियां हैं जो आपको आंतरिक भंडारण तक पहुंच प्रदान करती हैं, जिनमें शामिल हैं:

• getCacheDir()
• getDir()
• getDatabasePath()
• getFilesDir()
• openFileInput()
• openFileOutput()

अन्य विधियां उन पर भरोसा करेंगी, जैसे कि openOrCreateDatabase() । अन्य वर्ग भी उन पर भरोसा करेंगे, जैसे कि SQLiteOpenHelper और SharedPreferences ।

आंतरिक संग्रहण कहाँ संग्रहीत है ... कभी-कभी

यदि आप विभिन्न ब्लॉग पोस्ट, StackOverflow प्रतिक्रियाओं और 2012 या उससे पहले जारी पुस्तकों को देखते हैं, तो आपको सूचित किया जाता है कि आपके आवेदन का "आंतरिक संग्रहण" /data/data/your.application.package.name पर स्थित है।

अंदर कुछ निर्देशिकाएं स्वचालित रूप से एंड्रॉइड द्वारा बनाई जाएंगी, जैसा कि आप कुछ संदर्भ विधियों का उपयोग करते हैं। उदाहरण के लिए, getFilesDir() आपके एप्लिकेशन के आंतरिक संग्रहण में files/ निर्देशिका की ओर इशारा करते हुए एक File ऑब्जेक्ट लौटाता है।

आंतरिक संग्रहण कहां संग्रहीत किया जाता है ... शेष समय

हालाँकि, आपके एप्लिकेशन का आंतरिक संग्रहण हमेशा निर्दिष्ट स्थान पर नहीं होता है। डेवलपर्स के लिए, एक नियम है जो आपको ब्लॉग पोस्ट की इस श्रृंखला से सीखना चाहिए:

कभी भी पाथ्स की जगह न लें ।

समय-समय पर, मैं डेवलपर्स को कुछ इस तरह से करते हुए देखता हूं:

File f=new File("/data/data/their.app.package.name/files/foo.txt");

यह कोई अपराध नहीं है, यह बदतर है, यह एक गलती है।

सही कदम, और कम लिखें:

File f=new File(getFilesDir(), "foo.txt");

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

आंतरिक भंडारण की खोज

एंड्रॉइड स्टूडियो 3.0+ में डिवाइस फ़ाइल एक्सप्लोरर उपकरण एमुलेटर पर सभी आंतरिक भंडारण, साथ ही साथ उत्पादन उपकरणों पर डीबग किए गए एप्लिकेशन के आंतरिक भंडारण को देख सकता है।

कमांड लाइन पर, आप run-as adb विकल्प के साथ adb उपयोग कर सकते हैं।

उदाहरण के लिए, प्राथमिक उपयोगकर्ता के आंतरिक संग्रहण से डेटाबेस को अपनी विकास मशीन पर अपलोड करने के लिए, आप इसका उपयोग कर सकते हैं:

adb shell 'run-as your.application.package.name cp /data/data/your.application.package.name/databases/dbname.db /sdcard'

कृपया ध्यान दें कि:

• आपको उस गंतव्य को बदलने की आवश्यकता होगी जहां आपके डिवाइस पर बाहरी स्टोरेज को माउंट किया गया है (यहाँ पर /sdcard/ रूप में दिखाया गया है, जो सभी डिवाइसों पर समान नहीं होगा)
• आपको पुराने उपकरणों पर cp बजाय cat का उपयोग करने की आवश्यकता हो सकती है
• फ़ाइल बाहरी संग्रहण पर स्थित होने के बाद, आप इसे अपने कंप्यूटर पर डाउनलोड करने के लिए adb pull का उपयोग कर सकते हैं, या इसे अन्य सामान्य तरीकों से एक्सेस कर सकते हैं (उदाहरण के लिए, डिस्क के रूप में डिवाइस को माउंट करके)।

आंतरिक संग्रहण सीमाएँ

पुराने एंड्रॉइड 1.x और 2.x डिवाइस पर, आंतरिक भंडारण आमतौर पर फ़ाइल सिस्टम के एक समर्पित अनुभाग में स्थित था, और यह अनुभाग आमतौर पर काफी छोटा था। एचटीसी ड्रीम (उर्फ, टी-मोबाइल जी 1), मूल एंड्रॉइड डिवाइस, सभी अनुप्रयोगों द्वारा उपयोग के लिए एक विशाल 70 एमबी की आंतरिक मेमोरी थी (यह एक टाइपो नहीं है, उस समय हमने मेगाबाइट में मेमोरी को मापा था)।

जब तक 2.3 उपकरण सामने आए, तब तक आंतरिक भंडारण आकार में 1 जीबी हो सकता है।

एंड्रॉइड 3.0 ने स्टोरेज मॉडल को बदल दिया है, क्योंकि आंतरिक भंडारण अधिक मात्रा में हो गया है। 4 जीबी, 8 जीबी, 16 जीबी आदि के रूप में विज्ञापन देने वाले उपकरणों के लिए। भंडारण स्थान, आमतौर पर आंतरिक भंडारण के लिए यह सब (शून्य से मौजूदा सामग्री) उपलब्ध था। हम देखेंगे कि एंड्रॉइड 3.0 में क्या बदलाव आया है और बाहरी स्टोरेज के बारे में निम्नलिखित पोस्ट में स्टोरेज मॉडल पर इसका क्या प्रभाव पड़ता है।

एंड्रॉइड 1.x और 2.x के लिए, आंतरिक भंडारण केवल छोटी फ़ाइलों के लिए मान्य था, और आपको हर चीज के लिए बाहरी भंडारण का उपयोग करना था। एंड्रॉइड 3.0+ का मतलब है कि अधिकांश उपकरणों और अधिकांश उपयोगकर्ताओं के लिए, आंतरिक भंडारण उन फ़ाइलों के लिए बहुत अच्छा है जो अन्य अनुप्रयोगों द्वारा सामान्य उपयोग के लिए अभिप्रेत नहीं हैं या जो आपके एप्लिकेशन की परवाह किए बिना उपयोगकर्ता के लिए सुलभ हैं। हालांकि, कुछ अनुभवी उपयोगकर्ताओं को पता चलता है कि एक ऑन-बोर्ड फ्लैश भी पर्याप्त नहीं है कि वे क्या स्टोर करना चाहते हैं, इसलिए वे हटाने योग्य भंडारण पर स्विच करते हैं ... जो कि कीड़े का एक नोट है (नोट λμινς) - कई अप्रत्याशित और जटिल समस्याओं का स्रोत।

आंतरिक भंडारण सामान्य प्रश्न

क्या मुझे विश्व-पठनीय या विश्व-लेखन योग्य आंतरिक भंडारण में फाइलें बनानी चाहिए?

ओह, $ भगवान, नहीं। FileProvider उपयोग करें और FileProvider के कार्यान्वयन के साथ इस सामग्री की सेवा करें। उसके बाद, आपके पास, कम से कम, आपके संस्करण के विपरीत, इन फ़ाइलों तक पहुंच को नियंत्रित करने के लिए एंड्रॉइड अनुमति प्रणाली का उपयोग करने का अवसर होता है, जब सिस्टम पर कोई भी एप्लिकेशन इन फ़ाइलों को बर्बाद कर सकता है।

खैर, android:sharedUserId बारे में क्या android:sharedUserId ?

मैं सलाह नहीं देता।

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

यह विशेषता वास्तव में पूर्व-स्थापित अनुप्रयोगों के लिए अभिप्रेत है, जैसे कि डिवाइस निर्माता, मोबाइल ऑपरेटर या संशोधित ROM फर्मवेयर के डेवलपर द्वारा पहले से लोड किए गए सॉफ़्टवेयर सूट। विशेष रूप से, जैसे ही आप अपने एप्लिकेशन को एक बार इंस्टॉल करते हैं, तब आप बिना किसी मौजूदा फ़ाइल के उपयोगकर्ता की पहुंच को अवरुद्ध किए बिना अपने android:sharedUserId मान को साझा कर सकते हैं android:sharedUserId ... चूंकि लिनक्स उपयोगकर्ता खाते को बदलते समय एंड्रॉइड मालिक के अधिकारों को मौजूदा फाइलों में नहीं बदलता है, जो अनुप्रयोग चलाता है।

जब विभिन्न प्रक्रियाएँ फ़ाइलों तक पहुँचती हैं तो विभिन्न जोखिम होते हैं। कुछ सबसिस्टम, जैसे कि SQLite, में इस समस्या को हल करने के लिए अंतर्निहित तर्क हैं। लेकिन अगर आप खुद फ़ाइल तक अपनी पहुँच को व्यवस्थित करते हैं (उदाहरण के लिए, File और जावा I / O के माध्यम से), तो आपको एक साथ कुछ करने की ज़रूरत है, और यह मुश्किल है।

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

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

आंतरिक भंडारण में मेरी फ़ाइलों तक पहुंचने से रूट किए गए उपकरणों के उपयोगकर्ताओं को कैसे रोका जाए?

बस फाइलों को आंतरिक भंडारण में न रखें। रूट किए गए डिवाइस के उपयोगकर्ता डिवाइस पर अपनी आवश्यकता के अनुसार पहुंच सकते हैं, इसलिए उन्हें आपके डेटा तक पहुंचने से रोकने का एकमात्र तरीका डिवाइस पर नहीं है।

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

सामान्य तौर पर, जड़ वाले उपकरणों के साथ अपेक्षाकृत कम लोग - मैं उन्हें 1% से कम दर पर। IMHO, आप रूट किए गए उपकरणों से सुरक्षा के लिए समय बिताने के बजाय, बेहतर इंजीनियरिंग लिखने पर अपने इंजीनियरिंग कार्य पर ध्यान केंद्रित करके अधिक सफल होंगे।