Android Applications Basics

Reading time: 23 minutes

Android Security Model

दो परतें हैं:

• OS, जो स्थापित अनुप्रयोगों को एक-दूसरे से अलग रखता है।
• अनुप्रयोग स्वयं, जो डेवलपर्स को कुछ कार्यक्षमताओं को उजागर करने की अनुमति देता है और अनुप्रयोग क्षमताओं को कॉन्फ़िगर करता है।

UID Separation

प्रत्येक अनुप्रयोग को एक विशिष्ट उपयोगकर्ता आईडी सौंपा जाता है। यह ऐप के इंस्टॉलेशन के दौरान किया जाता है ताकि ऐप केवल अपनी उपयोगकर्ता आईडी द्वारा स्वामित्व वाले फ़ाइलों या साझा फ़ाइलों के साथ इंटरैक्ट कर सके। इसलिए, केवल ऐप स्वयं, OS के कुछ घटक और रूट उपयोगकर्ता ऐप के डेटा तक पहुंच सकते हैं।

UID Sharing

दो अनुप्रयोगों को समान UID का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है। यह जानकारी साझा करने के लिए उपयोगी हो सकता है, लेकिन यदि उनमें से एक समझौता कर लिया जाता है तो दोनों अनुप्रयोगों का डेटा समझौता कर लिया जाएगा। यही कारण है कि इस व्यवहार को नकारा जाता है।
समान UID साझा करने के लिए, अनुप्रयोगों को अपने मैनिफेस्ट में समान android:sharedUserId मान को परिभाषित करना चाहिए।

Sandboxing

Android Application Sandbox प्रत्येक अनुप्रयोग को एक अलग उपयोगकर्ता आईडी के तहत एक अलग प्रक्रिया के रूप में चलाने की अनुमति देता है। प्रत्येक प्रक्रिया की अपनी वर्चुअल मशीन होती है, इसलिए एक ऐप का कोड अन्य ऐप्स से अलग-थलग चलता है।
Android 5.0(L) से SELinux लागू किया गया है। मूल रूप से, SELinux ने सभी प्रक्रिया इंटरैक्शन को अस्वीकार कर दिया और फिर उनके बीच केवल अपेक्षित इंटरैक्शन की अनुमति देने के लिए नीतियाँ बनाई।

Permissions

जब आप एक ऐप इंस्टॉल करते हैं और यह अनुमतियों के लिए पूछता है, तो ऐप uses-permission तत्वों में कॉन्फ़िगर की गई अनुमतियों के लिए पूछ रहा है जो AndroidManifest.xml फ़ाइल में हैं। uses-permission तत्व अनुरोधित अनुमति के नाम को name attribute के अंदर इंगित करता है। इसमें maxSdkVersion attribute भी है जो निर्दिष्ट संस्करण से उच्च संस्करणों पर अनुमतियों के लिए पूछना बंद कर देता है।
ध्यान दें कि Android अनुप्रयोगों को शुरुआत में सभी अनुमतियों के लिए पूछने की आवश्यकता नहीं है, वे डायनामिकली अनुमतियों के लिए भी पूछ सकते हैं लेकिन सभी अनुमतियों को मैनिफेस्ट में घोषित किया जाना चाहिए।

जब एक ऐप कार्यक्षमता को उजागर करता है, तो यह केवल उन ऐप्स तक पहुंच को सीमित कर सकता है जिनके पास निर्दिष्ट अनुमति है।
एक अनुमति तत्व में तीन विशेषताएँ होती हैं:

• अनुमति का नाम
• permission-group attribute, जो संबंधित अनुमतियों को समूहित करने की अनुमति देता है।
• protection-level जो इंगित करता है कि अनुमतियाँ कैसे दी जाती हैं। चार प्रकार हैं:
• Normal: जब ऐप के लिए कोई ज्ञात खतरे नहीं होते हैं। उपयोगकर्ता को इसे मंजूर करने की आवश्यकता नहीं है।
• Dangerous: इंगित करता है कि अनुमति अनुरोध करने वाले अनुप्रयोग को कुछ उच्च पहुंच प्रदान करती है। उपयोगकर्ताओं से उन्हें मंजूर करने के लिए कहा जाता है।
• Signature: केवल उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स को अनुमति दी जा सकती है जो घटक को निर्यात करता है। यह सुरक्षा का सबसे मजबूत प्रकार है।
• SignatureOrSystem: केवल उसी प्रमाणपत्र द्वारा हस्ताक्षरित ऐप्स या सिस्टम-स्तरीय पहुंच के साथ चलने वाले ऐप्स को अनुमतियाँ दी जा सकती हैं।

Pre-Installed Applications

ये ऐप्स आमतौर पर /system/app या /system/priv-app निर्देशिकाओं में पाए जाते हैं और इनमें से कुछ अनुकूलित होते हैं (आपको classes.dex फ़ाइल भी नहीं मिल सकती है)। ये अनुप्रयोग जांचने के लायक हैं क्योंकि कभी-कभी वे बहुत सारी अनुमतियों के साथ चल रहे होते हैं (जैसे रूट)।

• AOSP (Android OpenSource Project) ROM के साथ शिप किए गए
• डिवाइस निर्माता द्वारा जोड़े गए
• सेल फोन प्रदाता द्वारा जोड़े गए (यदि उन्हें उनसे खरीदा गया हो)

Rooting

एक भौतिक Android डिवाइस में रूट एक्सेस प्राप्त करने के लिए आपको आमतौर पर 1 या 2 कमजोरियों का शोषण करने की आवश्यकता होती है जो डिवाइस और संस्करण के लिए विशिष्ट होती हैं।
एक बार जब शोषण काम कर जाता है, तो आमतौर पर Linux su बाइनरी को उपयोगकर्ता के PATH env वेरिएबल में निर्दिष्ट स्थान पर कॉपी किया जाता है जैसे /system/xbin।

एक बार जब su बाइनरी कॉन्फ़िगर हो जाती है, तो su बाइनरी के साथ इंटरफेस करने के लिए एक और Android ऐप का उपयोग किया जाता है और रूट एक्सेस के लिए अनुरोधों को संसाधित किया जाता है जैसे Superuser और SuperSU (जो Google Play स्टोर में उपलब्ध हैं)।

ROMs

यह कस्टम फर्मवेयर स्थापित करके OS को बदलना संभव है। ऐसा करने से एक पुराने डिवाइस की उपयोगिता बढ़ाई जा सकती है, सॉफ़्टवेयर प्रतिबंधों को बायपास किया जा सकता है या नवीनतम Android कोड तक पहुंच प्राप्त की जा सकती है।
OmniROM और LineageOS उपयोग करने के लिए दो सबसे लोकप्रिय फर्मवेयर हैं।

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

Implications

एक बार जब डिवाइस रूट हो जाता है, तो कोई भी ऐप रूट के रूप में एक्सेस का अनुरोध कर सकता है। यदि एक दुर्भावनापूर्ण ऐप इसे प्राप्त करता है, तो यह लगभग सब कुछ तक पहुंच प्राप्त कर लेगा और फोन को नुकसान पहुँचा सकेगा।

Android Application Fundamentals

• Android अनुप्रयोगों का प्रारूप APK फ़ाइल प्रारूप के रूप में संदर्भित किया जाता है। यह मूल रूप से एक ZIP फ़ाइल है (फ़ाइल एक्सटेंशन को .zip में बदलने पर, सामग्री को निकाला और देखा जा सकता है)।
• APK सामग्री (पूर्ण नहीं)
• AndroidManifest.xml
• resources.arsc/strings.xml
• resources.arsc: पूर्व-compiled संसाधनों को शामिल करता है, जैसे बाइनरी XML।
• res/xml/files_paths.xml
• META-INF/
• यहीं प्रमाणपत्र स्थित है!
• classes.dex
• इसमें डलविक बाइटकोड होता है, जो संकलित Java (या Kotlin) कोड का प्रतिनिधित्व करता है जिसे अनुप्रयोग डिफ़ॉल्ट रूप से निष्पादित करता है।
• lib/
• इसमें मूलभूत पुस्तकालय होते हैं, जो उपनिर्देशिकाओं में CPU आर्किटेक्चर द्वारा विभाजित होते हैं।
• armeabi: ARM आधारित प्रोसेसर के लिए कोड
• armeabi-v7a: ARMv7 और उच्चतर आधारित प्रोसेसर के लिए कोड
• x86: X86 प्रोसेसर के लिए कोड
• mips: केवल MIPS प्रोसेसर के लिए कोड
• assets/
• ऐप द्वारा आवश्यक विविध फ़ाइलों को संग्रहीत करता है, जिसमें अतिरिक्त मूलभूत पुस्तकालय या DEX फ़ाइलें शामिल हो सकती हैं, जिन्हें कभी-कभी मैलवेयर लेखकों द्वारा अतिरिक्त कोड को छिपाने के लिए उपयोग किया जाता है।
• res/
• संसाधनों को शामिल करता है जो resources.arsc में संकलित नहीं होते हैं।

Dalvik & Smali

Android विकास में, Java या Kotlin का उपयोग ऐप बनाने के लिए किया जाता है। डेस्कटॉप ऐप्स की तरह JVM का उपयोग करने के बजाय, Android इस कोड को Dalvik Executable (DEX) बाइटकोड में संकलित करता है। पहले, डलविक वर्चुअल मशीन इस बाइटकोड को संभालती थी, लेकिन अब, नए Android संस्करणों में Android Runtime (ART) इसका प्रभार लेता है।

रिवर्स इंजीनियरिंग के लिए, Smali महत्वपूर्ण हो जाता है। यह DEX बाइटकोड का मानव-पठनीय संस्करण है, जो स्रोत कोड को बाइटकोड निर्देशों में अनुवादित करके असेंबली भाषा की तरह कार्य करता है। Smali और baksmali इस संदर्भ में असेंबली और डिसअसेंबली उपकरणों को संदर्भित करते हैं।

Intents

Intents Android ऐप्स के बीच उनके घटकों या अन्य ऐप्स के साथ संवाद करने के प्राथमिक साधन हैं। ये संदेश वस्तुएं ऐप्स या घटकों के बीच डेटा ले जा सकती हैं, जैसे HTTP संचार में GET/POST अनुरोधों का उपयोग किया जाता है।

तो एक Intent मूल रूप से घटकों के बीच पारित किया जाने वाला एक संदेश है। Intents विशिष्ट घटकों या ऐप्स की ओर निर्देशित किए जा सकते हैं, या बिना किसी विशिष्ट प्राप्तकर्ता के भेजे जा सकते हैं।
सरलता के लिए Intent का उपयोग किया जा सकता है:

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

यदि कमजोर हैं, तो Intents का उपयोग विभिन्न प्रकार के हमलों को करने के लिए किया जा सकता है।

Intent-Filter

Intent Filters परिभाषित करते हैं कैसे एक गतिविधि, सेवा, या ब्रॉडकास्ट रिसीवर विभिन्न प्रकार के Intents के साथ इंटरैक्ट कर सकता है। मूल रूप से, वे इन घटकों की क्षमताओं का वर्णन करते हैं, जैसे कि वे कौन से कार्य कर सकते हैं या वे किस प्रकार के प्रसारण को संसाधित कर सकते हैं। इन फ़िल्टरों की घोषणा करने का प्राथमिक स्थान AndroidManifest.xml फ़ाइल के भीतर है, हालांकि ब्रॉडकास्ट रिसीवर्स के लिए, उन्हें कोडिंग करना भी एक विकल्प है।

Intent Filters श्रेणियों, क्रियाओं और डेटा फ़िल्टरों से बने होते हैं, जिसमें अतिरिक्त मेटाडेटा शामिल करने की संभावना होती है। यह सेटअप घटकों को उन विशिष्ट Intents को संभालने की अनुमति देता है जो घोषित मानदंडों से मेल खाते हैं।

Android घटकों (गतिविधियाँ/सेवाएँ/सामग्री प्रदाता/ब्रॉडकास्ट रिसीवर्स) का एक महत्वपूर्ण पहलू उनकी दृश्यता या सार्वजनिक स्थिति है। एक घटक को सार्वजनिक माना जाता है और यह अन्य ऐप्स के साथ इंटरैक्ट कर सकता है यदि इसे exported के मान के साथ true के रूप में सेट किया गया है या यदि इसके लिए मैनिफेस्ट में एक Intent Filter घोषित किया गया है। हालाँकि, डेवलपर्स के लिए इन घटकों को स्पष्ट रूप से निजी रखना संभव है, यह सुनिश्चित करते हुए कि वे अनजाने में अन्य ऐप्स के साथ इंटरैक्ट न करें। यह उनके मैनिफेस्ट परिभाषाओं में exported attribute को false पर सेट करके प्राप्त किया जाता है।

इसके अलावा, डेवलपर्स के पास इन घटकों तक पहुंच को और सुरक्षित करने का विकल्प होता है, विशेष अनुमतियों की आवश्यकता करके। permission attribute को सेट किया जा सकता है ताकि केवल उन ऐप्स को अनुमति दी जा सके जिनके पास निर्दिष्ट अनुमति है, जिससे सुरक्षा और नियंत्रण की एक अतिरिक्त परत जोड़ी जा सके कि कौन इसके साथ इंटरैक्ट कर सकता है।

<activity android:name=".MyActivity" android:exported="false">
<!-- Intent filters go here -->
</activity>

Implicit Intents

Intents को एक Intent कंस्ट्रक्टर का उपयोग करके प्रोग्रामेटिक रूप से बनाया जाता है:

Intent email = new Intent(Intent.ACTION_SEND, Uri.parse("mailto:"));

Action पहले घोषित किए गए इरादे का ACTION_SEND है और Extra एक mailto Uri है (Extra वह अतिरिक्त जानकारी है जिसकी अपेक्षा इरादा कर रहा है)।

इस इरादे को मैनिफेस्ट के अंदर निम्नलिखित उदाहरण के रूप में घोषित किया जाना चाहिए:

<activity android:name="ShareActivity">
<intent-filter>
<action android:name="android.intent.action.SEND" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>

एक intent-filter को संदेश प्राप्त करने के लिए action, data और category से मेल खाना चाहिए।

"Intent resolution" प्रक्रिया यह निर्धारित करती है कि प्रत्येक संदेश को कौन सा ऐप प्राप्त करना चाहिए। यह प्रक्रिया priority attribute पर विचार करती है, जिसे intent-filter declaration में सेट किया जा सकता है, और उच्च प्राथमिकता वाला चयनित होगा। यह प्राथमिकता -1000 से 1000 के बीच सेट की जा सकती है और एप्लिकेशन SYSTEM_HIGH_PRIORITY मान का उपयोग कर सकते हैं। यदि conflict उत्पन्न होता है, तो एक "choser" Window प्रकट होती है ताकि उपयोगकर्ता निर्णय ले सके।

Explicit Intents

एक explicit intent उस क्लास नाम को निर्दिष्ट करता है जिसे यह लक्षित कर रहा है:

Intent downloadIntent = new (this, DownloadService.class):

अन्य अनुप्रयोगों में पूर्व में घोषित इरादे तक पहुँचने के लिए आप उपयोग कर सकते हैं:

Intent intent = new Intent();
intent.setClassName("com.other.app", "com.other.app.ServiceName");
context.startService(intent);

Pending Intents

ये अन्य अनुप्रयोगों को आपके अनुप्रयोग की ओर से क्रियाएँ करने की अनुमति देते हैं, आपके ऐप की पहचान और अनुमतियों का उपयोग करते हुए। एक Pending Intent बनाने के लिए एक इरादा और प्रदर्शन करने के लिए क्रिया को निर्दिष्ट किया जाना चाहिए। यदि घोषित इरादा स्पष्ट नहीं है (यह नहीं बताता कि कौन सा इरादा इसे कॉल कर सकता है) तो एक दुष्ट अनुप्रयोग घोषित क्रिया को पीड़ित ऐप की ओर से प्रदर्शन कर सकता है। इसके अलावा, यदि कोई क्रिया निर्दिष्ट नहीं की गई है, तो दुष्ट ऐप पीड़ित की ओर से कोई भी क्रिया कर सकेगा।

Broadcast Intents

पिछले इरादों के विपरीत, जो केवल एक ऐप द्वारा प्राप्त होते हैं, ब्रॉडकास्ट इरादे कई ऐप द्वारा प्राप्त किए जा सकते हैं। हालाँकि, API संस्करण 14 से, यह संदेश प्राप्त करने वाले ऐप को निर्दिष्ट करना संभव है Intent.set Package का उपयोग करके।

वैकल्पिक रूप से, ब्रॉडकास्ट भेजते समय एक अनुमति निर्दिष्ट करना भी संभव है। रिसीवर ऐप को उस अनुमति की आवश्यकता होगी।

ब्रॉडकास्ट के दो प्रकार होते हैं: सामान्य (असिंक्रोनस) और क्रमबद्ध (सिंक्रोनस)। क्रम रिसीवर तत्व के कॉन्फ़िगर की गई प्राथमिकता पर आधारित है। प्रत्येक ऐप ब्रॉडकास्ट को प्रोसेस, रिले या ड्रॉप कर सकता है।

आप Context क्लास से sendBroadcast(intent, receiverPermission) फ़ंक्शन का उपयोग करके ब्रॉडकास्ट भेजना संभव है।
आप LocalBroadCastManager से sendBroadcast फ़ंक्शन का भी उपयोग कर सकते हैं, जो सुनिश्चित करता है कि संदेश ऐप से कभी बाहर नहीं जाता। इसका उपयोग करते समय आपको रिसीवर घटक को निर्यात करने की भी आवश्यकता नहीं होगी।

Sticky Broadcasts

इस प्रकार के ब्रॉडकास्ट भेजे जाने के लंबे समय बाद भी एक्सेस किए जा सकते हैं।
इनका API स्तर 21 में डिप्रिकेट किया गया था और इनका उपयोग न करने की सिफारिश की गई है।
ये किसी भी अनुप्रयोग को डेटा को स्निफ़ करने, बल्कि इसे संशोधित करने की अनुमति देते हैं।

यदि आप "sticky" शब्द वाले फ़ंक्शंस जैसे sendStickyBroadcast या sendStickyBroadcastAsUser पाते हैं, तो प्रभाव की जांच करें और उन्हें हटाने का प्रयास करें।

Deep links / URL schemes

Android अनुप्रयोगों में, डीप लिंक का उपयोग एक क्रिया (Intent) को सीधे एक URL के माध्यम से प्रारंभ करने के लिए किया जाता है। यह एक गतिविधि के भीतर एक विशिष्ट URL स्कीम घोषित करके किया जाता है। जब एक Android डिवाइस इस स्कीम के साथ एक URL तक पहुँचने की कोशिश करता है, तो अनुप्रयोग के भीतर निर्दिष्ट गतिविधि लॉन्च होती है।

स्कीम को AndroidManifest.xml फ़ाइल में घोषित किया जाना चाहिए:

[...]
<activity android:name=".MyActivity">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="examplescheme" />
</intent-filter>
[...]

पिछले उदाहरण से योजना है examplescheme:// (ध्यान दें कि category BROWSABLE भी है)

फिर, डेटा फ़ील्ड में, आप host और path निर्दिष्ट कर सकते हैं:

<data android:scheme="examplescheme"
android:host="example"
/>

इसे वेब से एक्सेस करने के लिए एक लिंक सेट करना संभव है:

<a href="examplescheme://example/something">click here</a>
<a href="examplescheme://example/javascript://%250dalert(1)">click here</a>

ऐप में निष्पादित होने वाले कोड को खोजने के लिए, उस गतिविधि पर जाएं जिसे डीपलिंक द्वारा कॉल किया गया है और onNewIntent फ़ंक्शन को खोजें।

सीखें कि HTML पृष्ठों का उपयोग किए बिना डीप लिंक कैसे कॉल करें।

AIDL - Android इंटरफेस परिभाषा भाषा

Android इंटरफेस परिभाषा भाषा (AIDL) का उद्देश्य Android अनुप्रयोगों में इंटरप्रोसेस संचार (IPC) के माध्यम से क्लाइंट और सेवा के बीच संचार को सुविधाजनक बनाना है। चूंकि Android पर किसी अन्य प्रक्रिया की मेमोरी को सीधे एक्सेस करना अनुमति नहीं है, AIDL इस प्रक्रिया को सरल बनाता है, जिससे ऑब्जेक्ट्स को एक ऐसे प्रारूप में परिवर्तित किया जाता है जिसे ऑपरेटिंग सिस्टम समझता है, इस प्रकार विभिन्न प्रक्रियाओं के बीच संचार को आसान बनाता है।

प्रमुख अवधारणाएँ

• बाउंड सेवाएँ: ये सेवाएँ IPC के लिए AIDL का उपयोग करती हैं, जिससे गतिविधियाँ या घटक एक सेवा से बंध सकते हैं, अनुरोध कर सकते हैं, और प्रतिक्रियाएँ प्राप्त कर सकते हैं। सेवा की कक्षा में onBind विधि इंटरैक्शन शुरू करने के लिए महत्वपूर्ण है, इसे कमजोरियों की खोज में सुरक्षा समीक्षा के लिए एक महत्वपूर्ण क्षेत्र के रूप में चिह्नित किया गया है।

• मैसेंजर: एक बाउंड सेवा के रूप में कार्य करते हुए, मैसेंजर IPC को सुविधाजनक बनाता है, जिसका ध्यान onBind विधि के माध्यम से डेटा को संसाधित करने पर है। किसी भी असुरक्षित डेटा हैंडलिंग या संवेदनशील कार्यों के निष्पादन के लिए इस विधि की निकटता से जांच करना आवश्यक है।

• बाइंडर: हालांकि बाइंडर क्लास का प्रत्यक्ष उपयोग AIDL के अमूर्तता के कारण कम सामान्य है, यह समझना फायदेमंद है कि बाइंडर विभिन्न प्रक्रियाओं की मेमोरी स्पेस के बीच डेटा ट्रांसफर को सुविधाजनक बनाने वाला एक कर्नेल-स्तरीय ड्राइवर है। आगे की समझ के लिए, एक संसाधन उपलब्ध है https://www.youtube.com/watch?v=O-UHvFjxwZ8।

घटक

इनमें शामिल हैं: गतिविधियाँ, सेवाएँ, ब्रॉडकास्ट रिसीवर्स और प्रदाता।

लॉन्चर गतिविधि और अन्य गतिविधियाँ

Android ऐप्स में, गतिविधियाँ स्क्रीन की तरह होती हैं, जो ऐप के उपयोगकर्ता इंटरफ़ेस के विभिन्न भागों को दिखाती हैं। एक ऐप में कई गतिविधियाँ हो सकती हैं, प्रत्येक एक अद्वितीय स्क्रीन प्रस्तुत करती है।

लॉन्चर गतिविधि ऐप का मुख्य गेटवे है, जो तब लॉन्च होती है जब आप ऐप के आइकन पर टैप करते हैं। इसे ऐप के मैनिफेस्ट फ़ाइल में विशिष्ट MAIN और LAUNCHER इंटेंट के साथ परिभाषित किया गया है:

<activity android:name=".LauncherActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>

सभी ऐप्स को एक लॉन्चर गतिविधि की आवश्यकता नहीं होती, विशेष रूप से उन ऐप्स को जिनका कोई उपयोगकर्ता इंटरफ़ेस नहीं होता, जैसे बैकग्राउंड सेवाएं।

गतिविधियों को अन्य ऐप्स या प्रक्रियाओं के लिए उपलब्ध कराया जा सकता है, यदि उन्हें मैनिफेस्ट में "निर्यातित" के रूप में चिह्नित किया जाए। यह सेटिंग अन्य ऐप्स को इस गतिविधि को प्रारंभ करने की अनुमति देती है:

<service android:name=".ExampleExportedService" android:exported="true"/>

हालांकि, किसी अन्य ऐप से गतिविधि तक पहुंचना हमेशा एक सुरक्षा जोखिम नहीं होता है। चिंता तब होती है जब संवेदनशील डेटा गलत तरीके से साझा किया जा रहा हो, जो जानकारी के लीक का कारण बन सकता है।

एक गतिविधि का जीवनचक्र onCreate विधि के साथ शुरू होता है, UI सेटअप करते हुए और उपयोगकर्ता के साथ बातचीत के लिए गतिविधि को तैयार करते हुए।

एप्लिकेशन उपवर्ग

Android विकास में, एक ऐप के पास Application क्लास का एक उपवर्ग बनाने का विकल्प होता है, हालांकि यह अनिवार्य नहीं है। जब ऐसा उपवर्ग परिभाषित किया जाता है, तो यह ऐप के भीतर पहली क्लास बन जाती है जिसे इंस्टेंटिएट किया जाता है। यदि इस उपवर्ग में attachBaseContext विधि लागू की गई है, तो इसे onCreate विधि से पहले निष्पादित किया जाता है। यह सेटअप बाकी एप्लिकेशन शुरू होने से पहले प्रारंभिक प्रारंभ की अनुमति देता है।

public class MyApp extends Application {
@Override
protected void attachBaseContext(Context base) {
super.attachBaseContext(base);
// Initialization code here
}

@Override
public void onCreate() {
super.onCreate();
// More initialization code
}
}

Services

Services बैकग्राउंड ऑपरेटिव्स हैं जो बिना उपयोगकर्ता इंटरफेस के कार्यों को निष्पादित करने में सक्षम हैं। ये कार्य तब भी चलते रह सकते हैं जब उपयोगकर्ता विभिन्न अनुप्रयोगों में स्विच करते हैं, जिससे सेवाएँ लंबी अवधि के संचालन के लिए महत्वपूर्ण हो जाती हैं।

सेवाएँ बहुपरकारी हैं; इन्हें विभिन्न तरीकों से प्रारंभ किया जा सकता है, जिसमें Intents इन्हें लॉन्च करने का प्राथमिक तरीका है, जो एक अनुप्रयोग के प्रवेश बिंदु के रूप में कार्य करता है। एक बार जब startService विधि का उपयोग करके सेवा शुरू की जाती है, तो इसका onStart विधि सक्रिय हो जाती है और तब तक चलती रहती है जब तक कि stopService विधि को स्पष्ट रूप से नहीं बुलाया जाता। वैकल्पिक रूप से, यदि किसी सेवा की भूमिका एक सक्रिय क्लाइंट कनेक्शन पर निर्भर करती है, तो क्लाइंट को सेवा से जोड़ने के लिए bindService विधि का उपयोग किया जाता है, जो डेटा पास करने के लिए onBind विधि को सक्रिय करता है।

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

<service android:name=".ExampleExportedService" android:exported="true"/>

Broadcast Receivers

Broadcast receivers एक मैसेजिंग सिस्टम में श्रोता के रूप में कार्य करते हैं, जिससे कई एप्लिकेशन सिस्टम से समान संदेशों का उत्तर दे सकते हैं। एक ऐप दो मुख्य तरीकों से एक रिसीवर को पंजीकृत कर सकता है: ऐप के Manifest के माध्यम से या ऐप के कोड में registerReceiver API के माध्यम से डायनामिकली। Manifest में, ब्रॉडकास्ट को अनुमतियों के साथ फ़िल्टर किया जाता है, जबकि डायनामिकली पंजीकृत रिसीवर पंजीकरण के समय अनुमतियों को भी निर्दिष्ट कर सकते हैं।

Intent filters दोनों पंजीकरण विधियों में महत्वपूर्ण हैं, यह निर्धारित करते हैं कि कौन से ब्रॉडकास्ट रिसीवर को ट्रिगर करते हैं। एक बार जब एक मेल खाने वाला ब्रॉडकास्ट भेजा जाता है, तो रिसीवर का onReceive मेथड सक्रिय होता है, जिससे ऐप को प्रतिक्रिया देने की अनुमति मिलती है, जैसे कि कम बैटरी अलर्ट के जवाब में व्यवहार को समायोजित करना।

ब्रॉडकास्ट असिंक्रोनस हो सकते हैं, जो सभी रिसीवर्स तक बिना क्रम के पहुँचते हैं, या सिंक्रोनस, जहाँ रिसीवर्स सेट प्राथमिकताओं के आधार पर ब्रॉडकास्ट प्राप्त करते हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि किसी भी ऐप को ब्रॉडकास्ट को इंटरसेप्ट करने के लिए खुद को प्राथमिकता देने का जोखिम होता है।

एक रिसीवर की कार्यक्षमता को समझने के लिए, उसकी क्लास के भीतर onReceive मेथड को देखें। इस मेथड का कोड प्राप्त Intent को संशोधित कर सकता है, जिससे रिसीवर्स द्वारा डेटा सत्यापन की आवश्यकता को उजागर किया जाता है, विशेष रूप से Ordered Broadcasts में, जो Intent को संशोधित या छोड़ सकते हैं।

Content Provider

Content Providers ऐप्स के बीच संरचित डेटा साझा करने के लिए आवश्यक हैं, डेटा सुरक्षा सुनिश्चित करने के लिए अनुमतियों को लागू करने के महत्व पर जोर देते हैं। वे ऐप्स को विभिन्न स्रोतों से डेटा तक पहुँचने की अनुमति देते हैं, जिसमें डेटाबेस, फ़ाइल सिस्टम, या वेब शामिल हैं। विशिष्ट अनुमतियाँ, जैसे readPermission और writePermission, पहुँच को नियंत्रित करने के लिए महत्वपूर्ण हैं। इसके अतिरिक्त, ऐप के मैनिफेस्ट में grantUriPermission सेटिंग्स के माध्यम से अस्थायी पहुँच प्रदान की जा सकती है, जिसमें path, pathPrefix, और pathPattern जैसे गुणों का उपयोग विस्तृत पहुँच नियंत्रण के लिए किया जाता है।

इनपुट सत्यापन कमजोरियों, जैसे SQL इंजेक्शन, को रोकने के लिए महत्वपूर्ण है। Content Providers बुनियादी संचालन का समर्थन करते हैं: insert(), update(), delete(), और query(), जो एप्लिकेशनों के बीच डेटा हेरफेर और साझा करने की सुविधा प्रदान करते हैं।

FileProvider, एक विशेष Content Provider, फ़ाइलों को सुरक्षित रूप से साझा करने पर केंद्रित है। इसे ऐप के मैनिफेस्ट में विशिष्ट गुणों के साथ परिभाषित किया गया है जो फ़ोल्डरों तक पहुँच को नियंत्रित करते हैं, जिसे android:exported और android:resource द्वारा फ़ोल्डर कॉन्फ़िगरेशन की ओर इंगित किया गया है। संवेदनशील डेटा को अनजाने में उजागर करने से बचने के लिए निर्देशिकाएँ साझा करते समय सावधानी बरतने की सलाह दी जाती है।

FileProvider के लिए उदाहरण मैनिफेस्ट घोषणा:

<provider android:name="androidx.core.content.FileProvider"
android:authorities="com.example.myapp.fileprovider"
android:grantUriPermissions="true"
android:exported="false">
<meta-data android:name="android.support.FILE_PROVIDER_PATHS"
android:resource="@xml/filepaths" />
</provider>

और filepaths.xml में साझा फ़ोल्डरों को निर्दिष्ट करने का एक उदाहरण:

<paths>
<files-path path="images/" name="myimages" />
</paths>

For further information check:

• Android Developers: Content Providers
• Android Developers: FileProvider

WebViews

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

एंड्रॉइड दो मुख्य WebView प्रकार प्रदान करता है:

• WebViewClient बुनियादी HTML के लिए अच्छा है लेकिन JavaScript अलर्ट फ़ंक्शन का समर्थन नहीं करता, जो XSS हमलों का परीक्षण करने के तरीके को प्रभावित करता है।
• WebChromeClient पूर्ण Chrome ब्राउज़र अनुभव की तरह कार्य करता है।

एक महत्वपूर्ण बिंदु यह है कि WebView ब्राउज़र कुकीज़ को डिवाइस के मुख्य ब्राउज़र के साथ साझा नहीं करते।

सामग्री लोड करने के लिए, loadUrl, loadData, और loadDataWithBaseURL जैसे तरीके उपलब्ध हैं। यह सुनिश्चित करना महत्वपूर्ण है कि ये URLs या फ़ाइलें उपयोग के लिए सुरक्षित हैं। सुरक्षा सेटिंग्स को WebSettings क्लास के माध्यम से प्रबंधित किया जा सकता है। उदाहरण के लिए, setJavaScriptEnabled(false) के साथ JavaScript को अक्षम करना XSS हमलों को रोक सकता है।

JavaScript "Bridge" Java ऑब्जेक्ट्स को JavaScript के साथ इंटरैक्ट करने की अनुमति देता है, जिसमें Android 4.2 से सुरक्षा के लिए विधियों को @JavascriptInterface के साथ चिह्नित करना आवश्यक है।

सामग्री पहुंच की अनुमति देना (setAllowContentAccess(true)) WebViews को Content Providers तक पहुंचने की अनुमति देता है, जो एक जोखिम हो सकता है जब तक कि सामग्री URLs को सुरक्षित के रूप में सत्यापित नहीं किया जाता।

फ़ाइल पहुंच को नियंत्रित करने के लिए:

• फ़ाइल पहुंच को अक्षम करना (setAllowFileAccess(false)) फ़ाइल सिस्टम तक पहुंच को सीमित करता है, कुछ संपत्तियों के लिए अपवाद के साथ, यह सुनिश्चित करता है कि उन्हें केवल गैर-संवेदनशील सामग्री के लिए उपयोग किया जाए।

Other App Components and Mobile Device Management

Digital Signing of Applications

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

App Verification for Enhanced Security

• Android 4.2 से शुरू होकर, Verify Apps नामक एक सुविधा उपयोगकर्ताओं को इंस्टॉलेशन से पहले ऐप्स की सुरक्षा की जांच करने की अनुमति देती है। यह सत्यापन प्रक्रिया उपयोगकर्ताओं को संभावित रूप से हानिकारक ऐप्स के खिलाफ चेतावनी दे सकती है, या यहां तक कि विशेष रूप से दुर्भावनापूर्ण ऐप्स के इंस्टॉलेशन को रोक सकती है, जिससे उपयोगकर्ता की सुरक्षा बढ़ती है।

Mobile Device Management (MDM)

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

// Example of enforcing a password policy with MDM
DevicePolicyManager dpm = (DevicePolicyManager) getSystemService(Context.DEVICE_POLICY_SERVICE);
ComponentName adminComponent = new ComponentName(context, AdminReceiver.class);

if (dpm.isAdminActive(adminComponent)) {
// Set minimum password length
dpm.setPasswordMinimumLength(adminComponent, 8);
}