Android Applications Basics
Try Hard सुरक्षा समूह
एंड्रॉयड सुरक्षा मॉडल
यहाँ दो परतें हैं:
ओएस, जो स्थापित एप्लिकेशनों को एक दूसरे से अलग रखता है।
एप्लिकेशन खुद, जो डेवलपरों को निश्चित कार्यों को उजागर करने और एप्लिकेशन क्षमताओं को कॉन्फ़िगर करने की अनुमति देता है।
UID विभाजन
प्रत्येक एप्लिकेशन को एक विशिष्ट उपयोगकर्ता आईडी सौंपी जाती है। यह एप्लिकेशन के स्थापना के दौरान किया जाता है ताकि एप्लिकेशन केवल अपने उपयोगकर्ता आईडी या साझा फ़ाइलों के स्वामित्व वाले फ़ाइलों के साथ बातचीत कर सके। इसलिए, केवल एप्लिकेशन खुद, ओएस के कुछ घटक और रूट उपयोगकर्ता ही एप्लिकेशन के डेटा तक पहुंच सकते हैं।
UID साझा करना
दो एप्लिकेशन को समान UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। यह सूचना साझा करने के लिए उपयोगी हो सकता है, लेकिन अगर इनमें से कोई भी संक्रमित हो जाता है तो दोनों एप्लिकेशनों के डेटा संक्रमित हो जाएगा। इसलिए यह व्यवहार असलाह है।
एक ही UID को साझा करने के लिए, एप्लिकेशनों को अपने मैनिफ़ेस्ट में समान android:sharedUserId मान की परिभाषा करनी होगी।
सैंडबॉक्सिंग
एंड्रॉयड एप्लिकेशन सैंडबॉक्स हर एप्लिकेशन को एक अलग प्रक्रिया के रूप में एक अलग उपयोगकर्ता आईडी के तहत चलाने की अनुमति देता है। प्रत्येक प्रक्रिया का अपना वर्चुअल मशीन होता है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग चलता है। एंड्रॉयड 5.0(L) से SELinux लागू है। मूल रूप से, SELinux ने सभी प्रक्रिया अंतराक्रियाओं को इनकार किया और फिर उनके बीच केवल उम्मीद की जाने वाली अंतराक्रियाओं को अनुमति देने के नीतियाँ बनाईं।
अनुमतियाँ
जब आप एक ऐप स्थापित करते हैं और यह अनुमतियाँ मांगता है, तो ऐप वह अनुमतियाँ मांग रहा है जो AndroidManifest.xml फ़ाइल में uses-permission तत्वों में कॉन्फ़िगर की गई हैं। uses-permission तत्व अनुमति का नाम निर्दिष्ट करता है जो नाम विशेषता में अनुमति के लिए पूछता है। इसमें maxSdkVersion विशेषता भी होती है जो उच्च संस्करणों पर अनुमतियाँ मांगना बंद कर देती है।
ध्यान दें कि एंड्रॉयड एप्लिकेशनों को शुरू में सभी अनुमतियाँ मांगने की आवश्यकता नहीं है, वे डायनेमिक रूप से भी अनुमतियाँ मांग सकते हैं लेकिन सभी अनुमतियाँ मैनिफ़ेस्ट में घोषित होनी चाहिए।
जब एक ऐप कार्यक्षमता उजागर करता है तो वह केवल उन ऐप्स तक की पहुंच को सीमित कर सकता है जिनके पास निर्दिष्ट अनुमति है। एक अनुमति तत्व में तीन विशेषताएँ होती हैं:
अनुमति का नाम
अनुमति समूह विशेषता, जो संबंधित अनुमतियों को समूहित करने की अनुमति देती है।
संरक्षण स्तर जो यह दर्शाता है कि अनुमतियाँ कैसे प्रदान की जाती हैं। चार प्रकार होते हैं:
सामान्य: जब किसी एप्लिकेशन के लिए कोई ज्ञात खतरे नहीं होते हैं। उपयोगकर्ता को इसे स्वीकृत करने की आवश्यकता नहीं होती है।
खतरनाक: यह अनुमति अनुरोध करने वाले एप्लिकेशन को कुछ उच्च पहुंच प्रदान करती है। उपयोगकर्ताओं से इन्हें स्वीकृत करने का अनुरोध किया जाता है।
हस्ताक्षर: केवल उन ऐप्स को ही अनुमति दी जा सकती है जिन्होंने उन ऐप्लिकेशन के साथ समान प्रमाणपत्र द्वारा हस्ताक्षरित किया है जैसा कि निर्यात करने वाला एक है। यह सबसे मजबूत स्तर की सुरक्षा है।
SignatureOrSystem: केवल उन ऐप्स को ही अनुमति दी जा सकती है जिन्होंने उन ऐप्लिकेशन के साथ समान प्रमाणपत्र द्वारा हस्ताक्षरित किया है या सिस्टम स्तर की पहुंच के साथ चल रहे ऐप्स को।
पूर्व-स्थापित एप्लिकेशन
ये एप्लिकेशन आम तौर पर /system/app या /system/priv-app निर्देशिकाओं में पाए जाते हैं और कुछ समय तक वे अनुकूलित होते हैं (आप classes.dex फ़ाइल भी नहीं मिल सकती है)। इन एप्लिकेशनों की जांच करना महत्वपूर्ण है क्योंकि कभी-कभी वे बहुत सारी अनुमतियों के साथ चल रहे होते हैं (जैसे रूट के रूप में)।
AOSP (Android OpenSource Project) ROM के साथ शिप किए गए
उपकरण निर्माता द्वारा जोड़ा गया
सेल फोन प्रदाता द्वारा जोड़ा गया (अगर उनसे खरीदा गया है)
रूटिंग
एक फिजिकल एंड्रॉयड उपकरण में रूट एक्सेस प्राप्त करने के लिए आम तौर पर आपको 1 या 2 वंशानुक्रमों का शोधन करना होता है जो आम तौर पर उपकरण और संस्करण के लिए विशेष होते हैं।\
डलविक और स्माली
एंड्रॉइड विकास में, जावा या कोटलिन का उपयोग ऐप्स बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग न करके, एंड्रॉइड इस कोड को डलविक एग्जीक्यूटेबल (DEX) बाइटकोड में कंपाइल करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को हैंडल करती थी, लेकिन अब, नए एंड्रॉइड संस्करणों में एंड्रॉइड रनटाइम (ART) इसे संभालता है।
पुनर्मुहानी के लिए, स्माली महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, स्रोत कोड को बाइटकोड निर्देशों में अनुवाद करके एसेम्बली भाषा की तरह काम करता है। स्माली और बैकस्माली इस संदर्भ में एसेम्बली और डिसेम्बली उपकरणों को संदर्भित करते हैं।
इंटेंट्स
इंटेंट्स एंड्रॉइड ऐप्स के घटकों के बीच या अन्य ऐप्स के साथ संवाद करने का मुख्य साधन हैं। ये संदेश वस्तुएं डेटा भी ले सकती हैं, जैसे कि GET/POST अनुरोध HTTP संचार में उपयोग किया जाता है।
इसलिए एक इंटेंट बुनियादी रूप से घटकों के बीच पारित संदेश है। इंटेंट्स निर्दिष्ट घटकों या ऐप्स के लिए निर्दिष्ट प्राप्तकर्ता के बिना भेजे जा सकते हैं। सरल होने के लिए इंटेंट का उपयोग किया जा सकता है:
एक एक्टिविटी शुरू करने के लिए, सामान्यत: ऐप के लिए एक उपयोगकर्ता इंटरफेस खोलना
परिवर्तनों की सूचना देने के लिए ब्रॉडकास्ट्स के रूप में
बैकग्राउंड सेवा को शुरू, रोकने और संवाद करने के लिए
ContentProviders के माध्यम से डेटा तक पहुंचने के लिए
घटनाओं को संभालने के लिए कॉलबैक के रूप में
अगर सुरक्षित नहीं हैं, इंटेंट्स कई प्रकार के हमले करने के लिए उपयोग किए जा सकते हैं।
इंटेंट-फ़िल्टर
इंटेंट फ़िल्टर्स परिभाषित करते हैं कि एक एक्टिविटी, सेवा, या ब्रॉडकास्ट रिसीवर विभिन्न प्रकार के इंटेंट्स के साथ कैसे बातचीत कर सकते हैं। मुख्य रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन-कौन से क्रियाएँ कर सकते हैं या वे किस प्रकार के ब्रॉडकास्ट्स को प्रसंस्कृत कर सकते हैं। इन फ़िल्टर्स को प्रमुख रूप से AndroidManifest.xml फ़ाइल में घोषित किया जाता है, हालांकि ब्रॉडकास्ट रिसीवर्स के लिए, इन्हें कोडिंग करना भी एक विकल्प है।
इंटेंट फ़िल्टर्स श्रेणियों, क्रियाएँ, और डेटा फ़िल्टर्स से मिलकर बने होते हैं, और अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को विशेष इंटेंट्स को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।
एंड्रॉइड के घटकों (एक्टिविटी/सेवा/कंटेंट प्रोवाइडर/ब्रॉडकास्ट रिसीवर) का एक महत्वपूर्ण पहलू उनकी दृश्यता या सार्वजनिक स्थिति है। यदि कोई घटक सार्वजनिक माना जाता है और अन्य ऐप्स के साथ बातचीत कर सकता है अगर इसे मेनिफेस्ट में exported के साथ true मान दिया गया है या अगर इसके लिए एक इंटेंट फ़िल्टर घोषित किया गया है। हालांकि, डेवलपर्स के लिए इन घटकों को अनजाने में अन्य ऐप्स के साथ बातचीत न करने के लिए स्पष्ट रूप से रखने का एक तरीका है। इसे उनके मेनिफेस्ट परिभाषाओं में exported विशेषता को false में सेट करके प्राप्त किया जाता है।
इसके अतिरिक्त, डेवलपर्स को इन घटकों तक पहुंच को और भी सुरक्षित बनाने का विकल्प है। permission विशेषता को सेट करने से केवल उन ऐप्स को पहुंच मिल सकती है जिनके पास निर्धारित अनुमति है, जो एक अतिरिक्त सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ता है कि कौन इससे बातचीत कर सकता है।
निहित इंटेंट्स
इंटेंट्स को कार्यात्मक रूप से एक इंटेंट निर्माता का उपयोग करके बनाया जाता है:
क्रिया पहले घोषित intent की ACTION_SEND है और अतिरिक्त एक mailto Uri है (अतिरिक्त जो intent की अतिरिक्त जानकारी की अपेक्षा कर रहा है)।
यह intent मैनिफेस्ट के अंदर घोषित किया जाना चाहिए जैसे निम्नलिखित उदाहरण में:
एक intent-filter को संदेश प्राप्त करने के लिए क्रिया, डेटा और श्रेणी को मिलान करने की आवश्यकता होती है।
"Intent resolution" प्रक्रिया तय करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया प्राथमिकता विशेषता को ध्यान में रखती है, जो intent-filter घोषणा में सेट किया जा सकता है, और जिसकी प्राथमिकता अधिक होगी, वह चयनित किया जाएगा। यह प्राथमिकता -1000 से 1000 के बीच सेट की जा सकती है और ऐप्लिकेशन SYSTEM_HIGH_PRIORITY मान का उपयोग कर सकते हैं। यदि संघर्ष उत्पन्न होता है, तो "चयनकर्ता" विंडो दिखाई देती है ताकि उपयोगकर्ता निर्णय कर सके।
स्पष्ट इंटेंट
एक स्पष्ट इंटेंट उस कक्षा का नाम निर्दिष्ट करता है जिसे यह लक्षित है:
Hindi Translation: अन्य एप्लिकेशन में पहले घोषित इंटेंट तक पहुंचने के लिए आप इस्तेमाल कर सकते हैं:
Pending Intents
ये अन्य एप्लिकेशनों को आपकी एप्लिकेशन की पहचान और अनुमतियों का उपयोग करके कार्रवाई करने की अनुमति देते हैं। Pending Intent बनाते समय एक इंटेंट और करने के लिए कार्रवाई को निर्दिष्ट करना चाहिए। यदि निर्धारित इंटेंट स्पष्ट नहीं है (जो इंटेंट को कौन कॉल कर सकता है यह निर्धारित नहीं करता), तो किसी दुरुपयोगी एप्लिकेशन को पीड़ित एप्लिकेशन के नाम पर घोषित कार्रवाई करने की अनुमति हो सकती है। इसके अतिरिक्त, यदि कोई कार्रवाई निर्दिष्ट नहीं है, तो दुरुपयोगी एप्लिकेशन को पीड़ित के नाम पर कोई भी कार्रवाई करने की अनुमति होगी।
Broadcast Intents
पिछले इंटेंट के विपरीत, जो केवल एक एप्लिकेशन द्वारा प्राप्त किए जाते हैं, ब्रॉडकास्ट इंटेंट कई एप्लिकेशनों द्वारा प्राप्त किए जा सकते हैं। हालांकि, API संस्करण 14 से, यह संदेश प्राप्त करने वाला ऐप स्पष्ट करना संभव है उपयोग करके Intent.set Package करना।
विकल्प से ब्रॉडकास्ट भेजते समय एक अनुमति निर्दिष्ट करना भी संभव है। प्राप्तकर्ता एप्लिकेशन को उस अनुमति की आवश्यकता होगी।
ब्रॉडकास्ट के दो प्रकार होते हैं: सामान्य (असमंजस) और क्रमबद्ध (समंजस)। क्रम प्राप्तकर्ता तत्व के भीतर विन्यासित प्राथमिकता पर आधारित है। प्रत्येक एप्लिकेशन ब्रॉडकास्ट को प्रसंस्करण, पुनर्प्रेषण या छोड़ सकता है।
एक ब्रॉडकास्ट भेजना संबंधित फ़ंक्शन sendBroadcast(intent, receiverPermission) का उपयोग करके Context वर्ग से किया जा सकता है।
आप LocalBroadCastManager से sendBroadcast फ़ंक्शन का उपयोग कर सकते हैं जिससे संदेश कभी भी ऐप नहीं छोड़ता। इसका उपयोग करके आपको एक प्राप्तकर्ता घटक को निर्यात करने की आवश्यकता नहीं होगी।
Sticky Broadcasts
इस प्रकार के ब्रॉडकास्ट उन्हें भेजे जाने के बाद भी लंबे समय तक उपयोग किया जा सकता है। ये API स्तर 21 में विचलित किए गए थे और उनका उपयोग न करने की सिफारिश की जाती है। इन्हें किसी भी एप्लिकेशन को डेटा को स्निफ़ करने की अनुमति देते हैं, लेकिन उसे संशोधित भी करने की अनुमति देते हैं।
यदि आप "sticky" शब्द वाले फ़ंक्शन जैसे sendStickyBroadcast या sendStickyBroadcastAsUser पाते हैं, उनका प्रभाव जांचें और उन्हें हटाने की कोशिश करें।
गहरे संवाद / URL योजनाएँ
Android एप्लिकेशन में, गहरे संवाद का उपयोग URL के माध्यम से सीधे कार्रवाई (इंटेंट) प्रारंभ करने के लिए किया जाता है। इसे एक विशेष URL योजना की घोषणा करके एक गतिविधि के भीतर किया जाता है। जब एक Android उपकरण इस योजना के साथ एक URL तक पहुंचने की कोशिश करता है, तो एप्लिकेशन के भीतर निर्धारित गतिविधि लॉन्च की जाती है।
योजना को AndroidManifest.xml फ़ाइल में घोषित किया जाना चाहिए:
अगले उदाहरण से योजना exampleapp:// है (नोट करें भी श्रेणी BROWSABLE)
फिर, डेटा फ़ील्ड में, आप होस्ट और पथ निर्दिष्ट कर सकते हैं:
इसे वेब से एक लिंक के रूप में एक्सेस करना संभव है:
ऐप में वह कोड खोजें जो ऐप में निष्पादित होगा, डीपलिंक द्वारा बुलाए गए गतिविधि में जाएं और onNewIntent फ़ंक्शन को खोजें।
जानें कैसे एचटीएमएल पेज का उपयोग किए बिना डीप लिंक को कॉल करें।
AIDL - एंड्रॉइड इंटरफेस परिभाषा भाषा
एंड्रॉइड इंटरफेस परिभाषा भाषा (AIDL) का उद्देश्य एंड्रॉइड एप्लिकेशन में क्लाइंट और सर्विस के बीच संचार को सुविधाजनक बनाना है इंटरप्रोसेस संचार (IPC) के माध्यम से। एंड्रॉइड पर दूसरे प्रक्रिया की मेमोरी तक सीधे पहुंचने की अनुमति नहीं है, इसलिए AIDL ऑब्जेक्ट्स को ऑपरेटिंग सिस्टम द्वारा समझे जाने वाले एक फॉर्मेट में मार्शल करके प्रक्रियाओं के बीच संचार को सुविधाजनक बनाता है।
मुख्य अवधारणाएँ
बाउंड सेवाएं: ये सेवाएं IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियों या घटकों को सेवा से जोड़ने, अनुरोध करने और प्रतिक्रिया प्राप्त करने की सुविधा होती है। सेवा की कक्षा में
onBindविधि संवेदनशीलता समीक्षा के लिए महत्वपूर्ण है, जिसे सुरक्षा की दृष्टि से खोजने के लिए महत्वपूर्ण क्षेत्र माना जाता है।मेसेंजर: एक बाउंड सेवा के रूप में काम करते हुए, मेसेंजर IPC को सुविधाजनक बनाता है जिसका मुख्य ध्यान डेटा को
onBindविधि के माध्यम से प्रसंस्करण करने पर होता है। इस विधि को किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील फ़ंक्शनों के निष्पादन के लिए ध्यान से जांचना महत्वपूर्ण है।बाइंडर: AIDL की अवस्थान के कारण बाइंडर क्लास का सीधा उपयोग कम होता है, लेकिन बाइंडर का उपयोग अलग-अलग प्रक्रियाओं की मेमोरी स्थानों के बीच डेटा स्थानांतरण सुविधा प्रदान करने वाले कर्नेल स्तर के ड्राइवर के रूप में करता है। अधिक समझने के लिए, एक संसाधन उपलब्ध है https://www.youtube.com/watch?v=O-UHvFjxwZ8।
घटक
इनमें शामिल हैं: गतिविधियाँ, सेवाएं, प्रसारण प्राप्तकर्ताएं और प्रदाताएं।
लॉन्चर गतिविधा और अन्य गतिविधाएँ
एंड्रॉइड ऐप्स में, गतिविधाएँ स्क्रीनों की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न हिस्से दिखाती हैं। एक ऐप में कई गतिविधाएँ हो सकती हैं, प्रत्येक एक उपयोगकर्ता को एक अद्वितीय स्क्रीन प्रस्तुत करती है।
लॉन्चर गतिविधा एक ऐप का मुख्य द्वार होती है, जिसे आप ऐप के प्रतीक पर टैप करते हैं तो लॉन्च होती है। इसे ऐप के मैनिफ़ेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इंटेंट्स के साथ परिभाषित किया जाता है:
नहीं सभी ऐप्स को एक लॉन्चर एक्टिविटी की आवश्यकता नहीं होती, खासकर जो उपयोगकर्ता इंटरफेस के बिना हों, जैसे बैकग्राउंड सेवाएं।
एक्टिविटी को "निर्यात" के रूप में चिह्नित करके अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध किया जा सकता है। इस सेटिंग से अन्य ऐप्स को इस एक्टिविटी को शुरू करने की अनुमति होती है:
हालांकि, एक एक्टिविटी को दूसरे ऐप से एक्सेस करना हमेशा एक सुरक्षा जोखिम नहीं है। चिंता उत्पन्न होती है अगर संवेदनशील डेटा गलत तरीके से साझा किया जा रहा है, जिससे सूचना लीक हो सकती है।
एक्टिविटी का जीवनचक्र onCreate मेथड के साथ शुरू होता है, UI को सेटअप करता है और एक्टिविटी को उपयोगकर्ता के साथ बातचीत के लिए तैयार करता है।
एप्लिकेशन सबक्लास
Android विकास में, एक ऐप को एप्लिकेशन क्लास का एक सबक्लास बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा सबक्लास परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाता है। यदि इस सबक्लास में attachBaseContext मेथड को लागू किया गया है, तो यह onCreate मेथड से पहले निष्पादित होता है। यह सेटअप अन्य एप्लिकेशन शुरू होने से पहले पहले प्रारंभिकीकरण की अनुमति देता है।
सेवाएं
सेवाएं पिछली प्रयोगकर्ता इंटरफ़ेस के बिना कार्यों को क्रियान्वित करने की क्षमता रखने वाले पृष्ठभूमि कार्यकर्ता हैं। ये कार्य चाहे उपयोगकर्ता विभिन्न एप्लिकेशनों में स्विच कर दें, तो भी चलते रह सकते हैं, जिससे सेवाएं लंबे समय तक चलने वाले कार्यों के लिए महत्वपूर्ण होती हैं।
सेवाएं विविध हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, इंटेंट्स इन्हें लॉन्च करने के लिए मुख्य तरीका होते हैं जैसे कि एक एप्लिकेशन का प्रवेश बिंदु। जब एक सेवा startService विधि का उपयोग करके शुरू की जाती है, तो उसकी onStart विधि क्रियाशील हो जाती है और stopService विधि को स्पष्ट रूप से बुलाया जाने तक चलती रहती है। अल्टरनेटिवली, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर है, तो bindService विधि का उपयोग सेवा को क्लाइंट से जोड़ने के लिए किया जाता है, डेटा पासेज के लिए onBind विधि को सक्रिय करता है।
सेवाओं का एक दिलचस्प उपयोग बैकग्राउंड संगीत प्लेबैक या नेटवर्क डेटा प्राप्ति जैसे कार्यों के लिए बिना एप्लिकेशन के उपयोगकर्ता के बातचीत को बाधित किए बिना किया जा सकता है। इसके अतिरिक्त, सेवाएं अन्य प्रक्रियाओं के लिए उपलब्ध कराई जा सकती हैं जो उसी उपकरण पर होती हैं। यह डिफ़ॉल्ट व्यवहार नहीं है और एंड्रॉइड मैनिफ़ेस्ट फ़ाइल में स्पष्ट रूप से कॉन्फ़िगरेशन की आवश्यकता होती है:
ब्रॉडकास्ट रिसीवर
ब्रॉडकास्ट रिसीवर मैसेजिंग सिस्टम में सुनने वाले के रूप में काम करते हैं, जो कई एप्लिकेशनों को सिस्टम से एक ही संदेश का जवाब देने की अनुमति देते हैं। एक एप्लिकेशन दो मुख्य तरीकों से रिसीवर को रजिस्टर कर सकता है: एप्लिकेशन के मैनिफेस्ट के माध्यम से या एप्लिकेशन के कोड के भीतर डायनामिक रूप से एपीआई के माध्यम से registerReceiver। मैनिफेस्ट में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिक रूप से रजिस्टर किए गए रिसीवर भी पंजीकरण के समय अनुमतियाँ निर्दिष्ट कर सकते हैं।
इंटेंट फ़िल्टर दोनों पंजीकरण विधियों में महत्वपूर्ण हैं, जो रिसीवर को कौन से ब्रॉडकास्ट को ट्रिगर करें यह निर्धारित करते हैं। एक मिलती जुलती ब्रॉडकास्ट भेजी जाती है, तो रिसीवर का onReceive मेथड चालू हो जाता है, जिससे एप्लिकेशन उसके अनुसार प्रतिक्रिया दे सकती है, जैसे किसी कम बैटरी अलर्ट के प्रतिक्रिया में व्यवहार समायोजित करना।
ब्रॉडकास्ट या तो असिंक्रोनस हो सकते हैं, जो सभी रिसीवर्स तय विन्यास के बिना पहुंच जाते हैं, या सिंक्रोनस, जहां रिसीवर्स को सेट की गई प्राथमिकताओं के आधार पर ब्रॉडकास्ट मिलती है। हालांकि, किसी भी एप्लिकेशन को ब्रॉडकास्ट को अंतर्गत करने के लिए अपने आप को प्राथमिकता देने की संभावना को ध्यान में रखना जरूरी है।
रिसीवर की कार्यक्षमता को समझने के लिए, उसकी कक्षा में onReceive मेथड खोजें। इस मेथड का कोड प्राप्त इंटेंट को संशोधित कर सकता है, रिसीवर्स द्वारा डेटा मान्यता की आवश्यकता को हाइलाइट करता है, विशेषकर ऑर्डर्ड ब्रॉडकास्ट्स में, जो इंटेंट को संशोधित या छोड़ सकते हैं।
कंटेंट प्रोवाइडर
कंटेंट प्रोवाइडर्स एप्लिकेशनों के बीच संरचित डेटा साझा करने के लिए महत्वपूर्ण हैं, डेटा सुरक्षा सुनिश्चित करने के लिए अनुमतियों को लागू करने की महत्वपूर्णता को जोर देते हैं। वे एप्लिकेशनों को विभिन्न स्रोतों से डेटा तक पहुंचने की अनुमति देते हैं, जैसे डेटाबेस, फ़ाइलसिस्टम, या वेब से। विशेष अनुमतियाँ, जैसे readPermission और writePermission, पहुंच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, अस्थायी पहुंच को एप्लिकेशन के मैनिफेस्ट में grantUriPermission सेटिंग्स के माध्यम से प्रदान किया जा सकता है, जिसमें path, pathPrefix, और pathPattern जैसे विस्तृत पहुंच नियंत्रण के लिए गुणों का उपयोग किया जा सकता है।
इनपुट मान्यता महत्वपूर्ण है ताकि सुरक्षा दोषों, जैसे एसक्यूएल इंजेक्शन, को रोकने में मदद मिले। कंटेंट प्रोवाइडर्स मूल ऑपरेशन्स का समर्थन करते हैं: insert(), update(), delete(), और query(), डेटा संशोधन और एप्लिकेशनों के बीच साझा करने की सुविधा प्रदान करते हैं।
FileProvider, एक विशेष रूप से डेटा सुरक्षित रूप से साझा करने पर ध्यान केंद्रित करने वाला कंटेंट प्रोवाइडर, एप्लिकेशन के मैनिफेस्ट में परिभाषित है। इसमें फ़ोल्डर तक पहुंच को नियंत्रित करने के लिए विशेष गुणों के साथ परिभाषित किया जाता है, जिन्हें android:exported और android:resource द्वारा फ़ोल्डर कॉन्फ़िगरेशन को संकेतित करने के लिए उपयोग किया जाता है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए डायरेक्टरी साझा करते समय सावधानी बरतने की सलाह दी जाती है।
उदाहरण मैनिफेस्ट घोषणा FileProvider के लिए:
और filepaths.xml में साझा फ़ोल्डर्स को निर्दिष्ट करने का एक उदाहरण:
For further information check:
WebViews
WebViews are like mini web browsers inside Android apps, pulling content either from the web or from local files. They face similar risks as regular browsers, yet there are ways to reduce these risks through specific settings.
Android offers two main WebView types:
WebViewClient is great for basic HTML but doesn't support the JavaScript alert function, affecting how XSS attacks can be tested.
WebChromeClient acts more like the full Chrome browser experience.
A key point is that WebView browsers do not share cookies with the device's main browser.
For loading content, methods such as loadUrl, loadData, and loadDataWithBaseURL are available. It's crucial to ensure these URLs or files are safe to use. Security settings can be managed via the WebSettings class. For instance, disabling JavaScript with setJavaScriptEnabled(false) can prevent XSS attacks.
The JavaScript "Bridge" lets Java objects interact with JavaScript, requiring methods to be marked with @JavascriptInterface for security from Android 4.2 onwards.
Allowing content access (setAllowContentAccess(true)) lets WebViews reach Content Providers, which could be a risk unless the content URLs are verified as secure.
To control file access:
Disabling file access (
setAllowFileAccess(false)) limits access to the filesystem, with exceptions for certain assets, ensuring they're only used for non-sensitive content.
Other App Components and Mobile Device Management
Digital Signing of Applications
Digital signing is a must for Android apps, ensuring they're authentically authored before installation. This process uses a certificate for app identification and must be verified by the device's package manager upon installation. Apps can be self-signed or certified by an external CA, safeguarding against unauthorized access and ensuring the app remains untampered during its delivery to the device.
App Verification for Enhanced Security
Starting from Android 4.2, a feature called Verify Apps allows users to have apps checked for safety before installation. This verification process can warn users against potentially harmful apps, or even prevent the installation of particularly malicious ones, enhancing user security.
Mobile Device Management (MDM)
MDM solutions provide oversight and security for mobile devices through Device Administration API. They necessitate the installation of an Android app to manage and secure mobile devices effectively. Key functions include enforcing password policies, mandating storage encryption, and permitting remote data wipe, ensuring comprehensive control and security over mobile devices.
ट्राई हार्ड सिक्योरिटी ग्रुप
Last updated
