लोकल एरिया नेटवर्क (एलएएन) पर मौजूद डिवाइसों को, INTERNET की अनुमति वाले किसी भी ऐप्लिकेशन से ऐक्सेस किया जा सकता है.
इससे ऐप्लिकेशन के लिए, लोकल डिवाइसों से कनेक्ट करना आसान हो जाता है. हालांकि, इससे निजता से जुड़ी समस्याएं भी हो सकती हैं. जैसे, उपयोगकर्ता की फ़िंगरप्रिंट बनाना और जगह की जानकारी के लिए प्रॉक्सी के तौर पर काम करना.
लोकल नेटवर्क प्रोटेक्शन प्रोजेक्ट का मकसद, उपयोगकर्ता की निजता को सुरक्षित रखना है. इसके लिए, लोकल नेटवर्क के ऐक्सेस को रनटाइम की नई अनुमति के पीछे रखा गया है.
असर
Android 16 के दौरान, यह अनुमति ऑप्ट-इन करने की सुविधा है. इसका मतलब है कि इस पर सिर्फ़ वे ऐप्लिकेशन असर डालेंगे जिन्होंने ऑप्ट-इन किया है. ऑप्ट-इन करने का मकसद यह है कि ऐप्लिकेशन डेवलपर यह समझ सकें कि उनके ऐप्लिकेशन के कौनसे हिस्से, लोकल नेटवर्क के इंप्लिसिट ऐक्सेस पर निर्भर करते हैं. इससे वे Android के आने वाले वर्शन में, इन हिस्सों को अनुमति से सुरक्षित रखने की तैयारी कर सकें.
अगर ऐप्लिकेशन, उपयोगकर्ता के लोकल नेटवर्क को इन तरीकों से ऐक्सेस करते हैं, तो उन पर असर पड़ेगा:
- लोकल नेटवर्क के पतों पर रॉ सॉकेट का सीधे या लाइब्रेरी के ज़रिए इस्तेमाल करना. उदाहरण के लिए,
Multicast DNS (mDNS)याSimple Service Discovery Protocol (SSDP). - फ़्रेमवर्क-लेवल की उन क्लास का इस्तेमाल करना जो लोकल नेटवर्क को ऐक्सेस करती हैं. उदाहरण के लिए,
NsdManager.
असर की जानकारी
लोकल नेटवर्क के पते से आने-जाने वाले ट्रैफ़िक के लिए, लोकल नेटवर्क के ऐक्सेस की अनुमति ज़रूरी है. यहां दी गई टेबल में, कुछ सामान्य मामले दिए गए हैं:
| ऐप्लिकेशन का लो लेवल नेटवर्क ऑपरेशन | लोकल नेटवर्क के ऐक्सेस की अनुमति ज़रूरी है |
|---|---|
| आउटगोइंग टीसीपी कनेक्शन बनाना | हां |
| इनकमिंग टीसीपी कनेक्शन स्वीकार करना | हां |
| यूडीपी यूनिकास्ट, मल्टीकास्ट, ब्रॉडकास्ट भेजना | हां |
| इनकमिंग यूडीपी यूनिकास्ट, मल्टीकास्ट, ब्रॉडकास्ट पाना | हां |
ये पाबंदियां, नेटवर्किंग स्टैक में गहराई से लागू की जाती हैं. इसलिए, ये सभी नेटवर्किंग एपीआई पर लागू होती हैं. इनमें, प्लैटफ़ॉर्म या मैनेज किए गए कोड में बनाए गए सॉकेट, Cronet और OkHttp जैसी नेटवर्किंग लाइब्रेरी, और उन पर लागू किए गए सभी एपीआई शामिल हैं. लोकल नेटवर्क पर उन सेवाओं को हल करने के लिए, लोकल नेटवर्क के ऐक्सेस की अनुमति ज़रूरी है जिनके सफ़िक्स में .local है.
ऊपर बताए गए नियमों के अपवाद:
- अगर किसी डिवाइस का डीएनएस सर्वर, लोकल नेटवर्क पर है, तो पोर्ट 53 पर उससे आने-जाने वाले ट्रैफ़िक के लिए, लोकल नेटवर्क के ऐक्सेस की अनुमति की ज़रूरत नहीं होती.
- जो ऐप्लिकेशन, आउटपुट स्विचर को अपने इन-ऐप्लिकेशन पिकर के तौर पर इस्तेमाल करते हैं उन्हें लोकल नेटवर्क के ऐक्सेस की अनुमति की ज़रूरत नहीं होगी. इस बारे में ज़्यादा जानकारी, आने वाले वर्शन में दी जाएगी.
Android 17 में लागू करने की शर्तें
Android 17 से, लोकल नेटवर्क प्रोटेक्शन को लागू करना ज़रूरी है. यह Android 17 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए लागू किया जाएगा.
| पक्ष | Android 16 | Android 17 |
|---|---|---|
| टारगेट किए जा रहे SDK टूल | 36 | 37 या इसके बाद का वर्शन |
| अनुमति | कुछ समय के लिए NEARBY_WIFI_DEVICES का इस्तेमाल किया गया | ACCESS_LOCAL_NETWORK |
| डिफ़ॉल्ट ऐक्सेस | लोकल नेटवर्क का ऐक्सेस चालू है | अपने टारगेट SDK को अपडेट करने वाले सभी ऐप्लिकेशन के लिए, लोकल नेटवर्क का ऐक्सेस डिफ़ॉल्ट रूप से ब्लॉक कर दिया जाता है |
| अनुमतियों का ग्रुप | मौजूदा NEARBY_DEVICES अनुमति ग्रुप का हिस्सा | |
यह पुष्टि करने के लिए कि नीति लागू होने के बाद, ऐप्लिकेशन की मुख्य सुविधाएं काम करना बंद न करें, SDK 37 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को, लोकल नेटवर्क के ऐक्सेस को मैनेज करने के लिए इनमें से कोई एक तरीका अपनाना होगा:
पहला तरीका: निजता बनाए रखने वाले पिकर का इस्तेमाल करना
सिस्टम की मदद से खोज और कनेक्शन के टास्क के लिए, पिकर का इस्तेमाल करें, ताकि रनटाइम की पूरी अनुमति का अनुरोध न करना पड़े. अपने इस्तेमाल के हिसाब से, इन पिकर का इस्तेमाल करें:
- मीडिया स्ट्रीम करना: Google Cast के साथ काम करने वाले ऐप्लिकेशन,
आउटपुट स्विचर सुविधा का इस्तेमाल कर सकते हैं. इससे डेवलपर, उपयोगकर्ताओं को
खास स्ट्रीमिंग डिवाइस चुनने की अनुमति दे सकते हैं. इसके लिए, ऐप्लिकेशन को
ACCESS_LOCAL_NETWORKकी पूरी अनुमति का अनुरोध करने की ज़रूरत नहीं होगी. - सामान्य कनेक्टिविटी:
NsdManagerमें, mDNS की खोज के लिए सिस्टम-रन सर्विस पिकर शामिल है. ऐप्लिकेशन के पूरे नेटवर्क को स्कैन करने के बजाय, सिस्टम एक डायलॉग दिखाता है. इससे उपयोगकर्ता, ऐप्लिकेशन को ऐक्सेस करने के लिए कोई एक डिवाइस चुन सकता है.
val discoveryRequest = DiscoveryRequest.Builder("_http._tcp")
.setFlags(DiscoveryRequest.FLAG_SHOW_PICKER)
.build()
nsdManager.registerServiceInfoCallback(discoveryRequest, executor, object : NsdManager.ServiceInfoCallback {
override fun onServiceUpdated(serviceInfo: NsdServiceInfo) {
// Handle the user-selected and discovered service
// NsdServiceInfo.getHostAddresses() can now be connected to
// without ACCESS_LOCAL_NETWORK permission
}
})
दूसरा तरीका: रनटाइम की अनुमति का अनुरोध करना (पूरा ऐक्सेस)
यह तरीका, इस्तेमाल के उन मुश्किल उदाहरणों के लिए ज़रूरी है जिनमें होम ऑटोमेशन या IoT डिवाइस मैनेजमेंट जैसे कामों के लिए, लोकल नेटवर्क का पूरा और लगातार ऐक्सेस चाहिए.
मेनिफ़ेस्ट में अनुमति का एलान करना: साफ़ तौर पर
ACCESS_LOCAL_NETWORKका एलान करेंAndroidManifest.xmlमें.रंटाइम में अनुमति का अनुरोध करना: लोकल नेटवर्क के ऐक्सेस की कोशिश करने से पहले, ऐप्लिकेशन को यह देखना होगा कि अनुमति दी गई है या नहीं. अगर अनुमति नहीं दी गई है, तो उन्हें
Activity.requestPermission()को कॉल करना होगा, ताकि सिस्टम का स्टैंडर्ड प्रॉम्प्ट ट्रिगर हो सके.पहले से अनुमति मिली होने की स्थिति:
ACCESS_LOCAL_NETWORKकी अनुमति,NEARBY_DEVICESअनुमति ग्रुप का हिस्सा है. अगर किसी उपयोगकर्ता ने इस ग्रुप में पहले से कोई दूसरी अनुमति दी है (जैसे, ब्लूटूथ की अनुमतियां), तो उनसे लोकल नेटवर्क के ऐक्सेस के लिए फिर से अनुरोध नहीं किया जाएगा.अनुमति न देने और वापस लेने की स्थितियों को मैनेज करना: ऐप्लिकेशन को उन स्थितियों को मैनेज करना होगा जिनमें उपयोगकर्ता, अनुरोध को अस्वीकार कर देता है या बाद में सिस्टम की सेटिंग में जाकर अनुमति वापस ले लेता है. ऐसी स्थितियों में, लोकल नेटवर्क का ट्रैफ़िक ब्लॉक कर दिया जाएगा.
अनुमति के अनुरोध को रीसेट करने के काउंटर की रणनीति
प्लैटफ़ॉर्म, काउंटर रीसेट करने की रणनीति लागू करता है. यह उन स्थितियों को मैनेज करती है जिनमें
किसी ऐप्लिकेशन को पहले NEARBY_DEVICES अनुमति ग्रुप
(जिसमें अब ACCESS_LOCAL_NETWORK शामिल है) की अनुमति नहीं मिली थी. इस वजह से, ऐप्लिकेशन ने अपनी वजह बताने के बाद भी अनुमति का अनुरोध नहीं किया. इस तरीके से, ऐप्लिकेशन को
requestPermission()
एपीआई को लागू करने के ज़्यादा मौके मिलते हैं. इससे ACCESS_LOCAL_NETWORK
की अनुमति के लिए, अनुमति न देने की संख्या रीसेट हो जाती है. इससे उपयोगकर्ता के साथ बेहतर तरीके से फिर से जुड़ने में मदद मिलती है. खास तौर पर, तब जब ऐप्लिकेशन की मुख्य सुविधाओं के लिए, लोकल नेटवर्क के ऐक्सेस की ज़रूरत के बारे में बताने से पहले ही, उपयोगकर्ता ने अनुमति न दी हो.
अनुमति का मॉडल बांटना
लोकल नेटवर्क के ऐक्सेस की अनुमति के लिए, अनुमति माइग्रेशन की रणनीति का इस्तेमाल किया जाता है. इससे नए और पुराने ऐप्लिकेशन को, टारगेट किए जा रहे SDK के हिसाब से अलग-अलग तरीके से मैनेज किया जाता है
| कैटगरी | टारगेट किए जा रहे SDK का लेवल | लोकल नेटवर्क के ऐक्सेस का तरीका | डेवलपर को यह कार्रवाई करनी होगी |
|---|---|---|---|
| नए ऐप्लिकेशन / अपडेट किए गए ऐप्लिकेशन | >= 37 (Android 17) | डिफ़ॉल्ट रूप से ब्लॉक किया गया | ACCESS_LOCAL_NETWORK की रनटाइम अनुमति का एलान करें और इसका अनुरोध करें |
| पुराने ऐप्लिकेशन | < 37 | INTERNET की अनुमति वाले ऐप्लिकेशन को ACCESS_LOCAL_NETWORK की अनुमति अपने-आप मिल जाती है. इससे वे ऐक्सेस बनाए रख सकते हैं. यह अनुमति कुछ समय के लिए मिलती है. जब ऐप्लिकेशन, टारगेट किए जा रहे SDK को 37 पर अपडेट करेगा, तो यह अनुमति डिफ़ॉल्ट रूप से ब्लॉक हो जाएगी |
कोड में तुरंत बदलाव करने की ज़रूरत नहीं है. SDK 37 को टारगेट करने से पहले, रनटाइम में ACCESS_LOCAL_NETWORK का अनुरोध न करें. |
इस्तेमाल के हिसाब से एलएनपी की रणनीति
कास्टिंग: मीडिया कास्ट करने की सुविधाओं के लिए, सबसे सही और निजता बनाए रखने वाली रणनीति, आउटपुट स्विचर का इस्तेमाल करना है. इस तरीके से, सिस्टम उपयोगकर्ता की ओर से लोकल नेटवर्क की खोज और कनेक्शन को मैनेज कर सकता है. इससे ऐप्लिकेशन को
ACCESS_LOCAL_NETWORKकी अनुमति का अनुरोध करने की ज़रूरत नहीं होती.ब्राउज़र: गड़बड़ियों को मैनेज करने के लिए, प्रोटोकॉल के हिसाब से अलग-अलग तरीकों की ज़रूरत होती है. यूडीपी की गड़बड़ियों से,
EPERMगड़बड़ी कोड मिलता है. टीसीपी कनेक्शन के लिए, ब्राउज़र को NDK APIandroid_getnetworkblockedreason(int sockFd)का इस्तेमाल करना चाहिए, ताकि यह पता चल सके कि एलएनपी ने कोई पैकेट ब्लॉक किया है या नहीं. यह एपीआईANDROID_NETWORK_BLOCKED_REASON_LNPदिखाता है.इस्तेमाल के अन्य उदाहरण (जैसे, IoT): mDNS का इस्तेमाल करके डिवाइस ढूंढने वाले ऐप्लिकेशन को
android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKERका इस्तेमाल करना चाहिए. इससे अनुमति के बिना डिवाइस ढूंढे जा सकते हैं. साथ ही, आईपी पते पाने के लिएNsdManager#registerServiceInfoCallback/NsdManager#resolveServiceका इस्तेमाल करना चाहिए. इस तरीके से मिले आईपी पतों से कनेक्ट करने के लिए,ACCESS_LOCAL_NETWORKकी अनुमति की ज़रूरत नहीं होती.
जिन ऐप्लिकेशन को लोकल नेटवर्क से सीधे कम्यूनिकेट करने की ज़रूरत होती है और वे सिस्टम की मदद से काम करने वाले पिकर का इस्तेमाल नहीं कर सकते उनके लिए, Android 17 (SDK 37) या इसके बाद के वर्शन को टारगेट करते समय, अनुमति रीसेट करने के काउंटर की रणनीति का इस्तेमाल करने का सुझाव दिया जाता है. अगर उपयोगकर्ता,
ACCESS_LOCAL_NETWORK की अनुमति वापस ले लेता है, तो इस तरीके से ऐप्लिकेशन को अनुमति का फिर से अनुरोध करने के ज़्यादा मौके मिलते हैं.
इससे डेवलपर, उपयोगकर्ता को अनुमति की ज़रूरत की वजह साफ़ तौर पर बता सकते हैं.
Android 16 के लिए दिशा-निर्देश
लोकल नेटवर्क की पाबंदियों के लिए ऑप्ट-इन करने के लिए, यह तरीका अपनाएं:
- अपने डिवाइस को Android 16 Beta 3 या इसके बाद के वर्शन वाले बिल्ड पर फ़्लैश करें
- टेस्ट किया जाने वाला ऐप्लिकेशन इंस्टॉल करें
adb का इस्तेमाल करके, Appcompat कॉन्फ़िगरेशन को टॉगल करें
adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>डिवाइस को रीबूट करें
अब आपके ऐप्लिकेशन का लोकल नेटवर्क का ऐक्सेस सीमित हो गया है. साथ ही, लोकल नेटवर्क को ऐक्सेस करने की किसी भी कोशिश से सॉकेट की गड़बड़ियां होती हैं.
अगर आपके ऐप्लिकेशन की प्रोसेस के बाहर, लोकल नेटवर्क के ऑपरेशन करने वाले एपीआई (जैसे, NsdManager) का इस्तेमाल किया जा रहा है, तो ऑप्ट-इन करने के दौरान उन पर कोई असर नहीं पड़ता.
ऐक्सेस वापस पाने के लिए, आपको अपने ऐप्लिकेशन को NEARBY_WIFI_DEVICES की अनुमति देनी होगी.
- पक्का करें कि ऐप्लिकेशन के
manifestमें,NEARBY_WIFI_DEVICESकी अनुमति का एलान किया गया हो. - सेटिंग > ऐप्लिकेशन > [ऐप्लिकेशन का नाम] > अनुमतियां > आस-पास के डिवाइस > अनुमति दें पर जाएं
अब आपके ऐप्लिकेशन का लोकल नेटवर्क का ऐक्सेस वापस मिल जाना चाहिए. साथ ही, आपके सभी उदाहरण, ऐप्लिकेशन के ऑप्ट-इन करने से पहले की तरह काम करने चाहिए. यहां बताया गया है कि ऐप्लिकेशन के नेटवर्क ट्रैफ़िक पर किस तरह असर पड़ता है.
| अनुमति | आउटबाउंड एलएएन अनुरोध | आउटबाउंड/इनबाउंड इंटरनेट अनुरोध | इनबाउंड एलएएन अनुरोध |
|---|---|---|---|
| अनुमति दी गई | काम करता है | काम करता है | काम करता है |
| अनुमति नहीं दी गई | विफल | काम करता है | विफल |
Appcompat कॉन्फ़िगरेशन को टॉगल-ऑफ़ करने के लिए, इस निर्देश का इस्तेमाल करें
adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>
गड़बड़ियां
अगर अनुमति न होने की वजह से, लोकल नेटवर्क के ऐक्सेस का अनुरोध पूरा नहीं हो पाता है, तो:
आम तौर पर, टीसीपी कनेक्शन में टाइमआउट की गड़बड़ी होती है.
आम तौर पर, यूडीपी की गड़बड़ियों और अनुमति न मिलने की स्थितियों में EPERM गड़बड़ी कोड मिलता है
बग
इनके लिए बग और सुझाव, शिकायत या राय सबमिट करें:
- एलएएन ऐक्सेस में अंतर (आपको लगता है कि किसी खास ऐक्सेस को "लोकल नेटवर्क" ऐक्सेस नहीं माना जाना चाहिए)
- ऐसे बग जिनमें एलएएन ऐक्सेस ब्लॉक होना चाहिए, लेकिन ब्लॉक नहीं है
- ऐसे बग जिनमें एलएएन ऐक्सेस ब्लॉक नहीं होना चाहिए, लेकिन ब्लॉक है
इस बदलाव से इन पर कोई असर नहीं पड़ेगा:
- इंटरनेट का ऐक्सेस
- मोबाइल नेटवर्क