लोकल नेटवर्क की अनुमति

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

Local Network Protections प्रोजेक्ट का मकसद, उपयोगकर्ता की निजता को सुरक्षित रखना है. इसके लिए, लोकल नेटवर्क के ऐक्सेस को नई रनटाइम अनुमति के पीछे रखा जाता है.

असर

Android 16 में, यह अनुमति ऑप्ट-इन करने की सुविधा है. इसका मतलब है कि सिर्फ़ उन ऐप्लिकेशन पर इसका असर पड़ेगा जिन्होंने ऑप्ट-इन किया है. ऑप्ट-इन करने का मकसद यह है कि ऐप्लिकेशन डेवलपर यह समझ सकें कि उनके ऐप्लिकेशन के कौनसे हिस्से, लोकल नेटवर्क के इंप्लिसिट ऐक्सेस पर निर्भर करते हैं. इससे वे Android के आने वाले वर्शन में, उन हिस्सों को अनुमति से जुड़ी सुरक्षा के लिए तैयार कर पाएंगे.

अगर ऐप्लिकेशन, उपयोगकर्ता के लोकल नेटवर्क को इन तरीकों से ऐक्सेस करते हैं, तो उन पर असर पड़ेगा:

• लोकल नेटवर्क पतों पर रॉ सॉकेट का सीधे तौर पर या लाइब्रेरी के ज़रिए इस्तेमाल करना. उदाहरण के लिए, Multicast DNS (mDNS) या Simple Service Discovery Protocol (SSDP).
• फ़्रेमवर्क-लेवल की ऐसी क्लास का इस्तेमाल करना जो लोकल नेटवर्क को ऐक्सेस करती हैं. उदाहरण के लिए, NsdManager.

असर की जानकारी

लोकल नेटवर्क के पते से आने-जाने वाले ट्रैफ़िक के लिए, लोकल नेटवर्क ऐक्सेस करने की अनुमति ज़रूरी है. यहां दी गई टेबल में, कुछ सामान्य मामलों के बारे में बताया गया है:

ये पाबंदियां, नेटवर्किंग स्टैक में गहराई से लागू की जाती हैं. इसलिए, ये सभी नेटवर्किंग एपीआई पर लागू होती हैं. इसमें प्लैटफ़ॉर्म या मैनेज किए गए कोड में बनाए गए सॉकेट, Cronet और OkHttp जैसी नेटवर्किंग लाइब्रेरी, और उन पर लागू किए गए कोई भी एपीआई शामिल हैं. लोकल नेटवर्क पर मौजूद उन सेवाओं को हल करने के लिए, लोकल नेटवर्क का ऐक्सेस देना ज़रूरी है जिनके नाम के आखिर में .local सफ़िक्स है.

ऊपर दिए गए नियमों के अपवाद:

• अगर किसी डिवाइस का डीएनएस सर्वर लोकल नेटवर्क पर है, तो उसके साथ पोर्ट 53 पर होने वाले ट्रैफ़िक के लिए, लोकल नेटवर्क का ऐक्सेस पाने की अनुमति की ज़रूरत नहीं होती.
• जिन ऐप्लिकेशन में आउटपुट स्विचर को इन-ऐप्लिकेशन पिकर के तौर पर इस्तेमाल किया जाता है उन्हें लोकल नेटवर्क की अनुमतियों की ज़रूरत नहीं होगी. इस बारे में ज़्यादा जानकारी बाद में दी जाएगी.

Android 17 के लिए ज़रूरी शर्तें

Android 17 से, लोकल नेटवर्क की सुरक्षा से जुड़ी सेटिंग को चालू करना ज़रूरी है. साथ ही, Android 17 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, इसे लागू किया जाता है.

नीति लागू होने के बाद, ऐप्लिकेशन के काम करने के तरीके में कोई गड़बड़ी तो नहीं हुई है, इसकी पुष्टि करने के लिए, SDK 37 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को, लोकल नेटवर्क का ऐक्सेस मैनेज करने के लिए इनमें से कोई एक तरीका अपनाना होगा:

पाथ A: निजता बनाए रखने वाले पिकर का इस्तेमाल करना

सिस्टम की मदद से डिवाइसों को खोजने और कनेक्ट करने के लिए, पिकर का इस्तेमाल करें. इससे रनटाइम की अनुमति के लिए अनुरोध करने से बचा जा सकता है. अपने इस्तेमाल के उदाहरण के हिसाब से, इन पिकर का इस्तेमाल करें:

• मीडिया स्ट्रीमिंग: 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
    }
})

पाथ B: रनटाइम के दौरान अनुमति का अनुरोध करना (ब्रॉड ऐक्सेस)

यह पाथ, होम ऑटोमेशन या आईओटी डिवाइस मैनेजमेंट जैसे मुश्किल इस्तेमाल के मामलों के लिए ज़रूरी है. इन मामलों में, लोकल नेटवर्क का ऐक्सेस लंबे समय तक और ज़्यादा डिवाइसों के लिए चाहिए होता है.

• मेनिफ़ेस्ट में अनुमति के बारे में बताएं: AndroidManifest.xml में ACCESS_LOCAL_NETWORK के बारे में साफ़ तौर पर बताएं.

• रनटाइम के दौरान अनुमति का अनुरोध करना: लोकल नेटवर्क को ऐक्सेस करने से पहले, ऐप्लिकेशन को यह देखना होगा कि अनुमति दी गई है या नहीं. अगर ऐसा नहीं होता है, तो उन्हें Activity.requestPermission() पर कॉल करके, सिस्टम के स्टैंडर्ड प्रॉम्प्ट को ट्रिगर करना होगा.

• पहले से मिली अनुमति का उदाहरण: ACCESS_LOCAL_NETWORK अनुमति, NEARBY_DEVICES अनुमति ग्रुप का हिस्सा है. अगर किसी उपयोगकर्ता ने इस ग्रुप में पहले से ही कोई दूसरी अनुमति दी है (जैसे कि ब्लूटूथ की अनुमतियां), तो उसे स्थानीय नेटवर्क ऐक्सेस करने के लिए फिर से प्रॉम्प्ट नहीं किया जाएगा.

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

अनुमति के अनुरोध को रीसेट करने की रणनीति

यह प्लैटफ़ॉर्म, काउंटर रीसेट करने की रणनीति लागू करता है. इससे उन स्थितियों को हल किया जाता है जहां NEARBY_DEVICES अनुमति ग्रुप (जिसमें अब ACCESS_LOCAL_NETWORK शामिल है) के लिए, ऐप्लिकेशन के पहले के अनुरोध को अस्वीकार कर दिया गया था. इस वजह से, ऐप्लिकेशन को अनुमति मांगने से रोका गया था. हालांकि, ऐप्लिकेशन ने अनुमति मांगने की वजह को सही तरीके से बताया था. इस तरीके से, ऐप्लिकेशन को requestPermission() एपीआई को फिर से चालू करने के ज़्यादा मौके मिलते हैं. इससे ACCESS_LOCAL_NETWORK अनुमति के लिए, अस्वीकार किए जाने की संख्या को असरदार तरीके से रीसेट किया जाता है. इससे उपयोगकर्ता को फिर से जोड़ने में मदद मिलती है. ऐसा खास तौर पर तब होता है, जब ऐप्लिकेशन के मुख्य फ़ंक्शन के लिए लोकल नेटवर्क ऐक्सेस करने की ज़रूरत के बारे में बताने से पहले ही, उपयोगकर्ता ने ऐक्सेस करने से मना कर दिया हो.

अनुमति देने का स्प्लिट मॉडल

लोकल नेटवर्क की अनुमति, अनुमति को बांटने की माइग्रेशन रणनीति का इस्तेमाल करती है. इससे नए और लेगसी ऐप्लिकेशन को अलग-अलग तरीके से हैंडल किया जा सकता है. ऐसा उनके टारगेट SDK के आधार पर किया जाता है

इस्तेमाल के हिसाब से एलएनपी की रणनीति

• कास्टिंग: मीडिया कास्ट करने की सुविधाओं के लिए, सबसे सही और निजता बनाए रखने वाली रणनीति, आउटपुट स्विचर का इस्तेमाल करना है. इस तरीके से, सिस्टम को उपयोगकर्ता की ओर से लोकल नेटवर्क की खोज करने और उससे कनेक्ट करने की अनुमति मिलती है. इससे ऐप्लिकेशन को ACCESS_LOCAL_NETWORK अनुमति मांगने की ज़रूरत नहीं पड़ती.

• ब्राउज़र: गड़बड़ियों को ठीक करने के लिए, प्रोटोकॉल के आधार पर अलग-अलग तरीके अपनाने पड़ते हैं. यूडीपी से जुड़ी गड़बड़ियों की वजह से, EPERM गड़बड़ी कोड दिखता है. टीसीपी कनेक्शन के लिए, ब्राउज़र को NDK API android_getnetworkblockedreason(int sockFd) का इस्तेमाल करना चाहिए. इससे यह पता चलता है कि किसी पैकेट को LNP ने ब्लॉक किया है या नहीं. यह एपीआई ANDROID_NETWORK_BLOCKED_REASON_LNP दिखाता है.

• इस्तेमाल के अन्य उदाहरण (जैसे, IoT): mDNS का इस्तेमाल करके डिवाइसों का पता लगाने वाले ऐप्लिकेशन को android.net.nsd.DiscoveryRequest#FLAG_SHOW_PICKER का इस्तेमाल करना चाहिए. इससे बिना अनुमति के डिवाइसों का पता लगाया जा सकता है. साथ ही, आईपी पते पाने के लिए NsdManager#registerServiceInfoCallback / NsdManager#resolveService का इस्तेमाल करना चाहिए. इस तरह से हासिल किए गए आईपी पतों से कनेक्ट करने के लिए, ACCESS_LOCAL_NETWORK अनुमति की ज़रूरत नहीं होती.

जिन ऐप्लिकेशन को सीधे तौर पर लोकल नेटवर्क से कम्यूनिकेट करने की ज़रूरत होती है और वे सिस्टम-मीडिएटेड पिकर का इस्तेमाल नहीं कर सकते उनके लिए, अनुमति रीसेट करने की रणनीति का इस्तेमाल करने का सुझाव दिया जाता है. अगर उपयोगकर्ता ACCESS_LOCAL_NETWORK अनुमति को रद्द कर देता है, तो इस सुविधा की मदद से ऐप्लिकेशन को अनुमति का अनुरोध फिर से करने के ज़्यादा मौके मिलते हैं. इससे डेवलपर, उपयोगकर्ता को अनुमति का अनुरोध करने की वजह ज़्यादा साफ़ तौर पर बता पाते हैं.

Android 16 के लिए दिशा-निर्देश

लोकल नेटवर्क ऐक्सेस से जुड़ी पाबंदियों के लिए ऑप्ट इन करने के लिए, यह तरीका अपनाएं:

1. अपने डिवाइस पर Android 16 Beta 3 या इसके बाद के वर्शन वाला बिल्ड फ़्लैश करें
2. टेस्ट किया जाने वाला ऐप्लिकेशन इंस्टॉल करना

3. adb का इस्तेमाल करके, Appcompat कॉन्फ़िगरेशन को टॉगल करना

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. डिवाइस को रीबूट करें

अब आपके ऐप्लिकेशन का लोकल नेटवर्क ऐक्सेस सीमित कर दिया गया है. साथ ही, लोकल नेटवर्क को ऐक्सेस करने की किसी भी कोशिश से सॉकेट में गड़बड़ियां होती हैं. अगर ऐसे एपीआई का इस्तेमाल किया जा रहा है जो आपके ऐप्लिकेशन की प्रोसेस के बाहर लोकल नेटवर्क ऑपरेशन करते हैं (उदाहरण के लिए, NsdManager), तो ऑप्ट-इन करने के दौरान उन पर कोई असर नहीं पड़ता.

ऐक्सेस वापस पाने के लिए, आपको अपने ऐप्लिकेशन को NEARBY_WIFI_DEVICES की अनुमति देनी होगी.

• पक्का करें कि ऐप्लिकेशन ने अपने manifest में NEARBY_WIFI_DEVICES अनुमति का एलान किया हो.
• सेटिंग > ऐप्लिकेशन > [ऐप्लिकेशन का नाम] > अनुमतियां > आस-पास के डिवाइस > अनुमति दें पर जाएं

अब आपके ऐप्लिकेशन का ऐक्सेस, लोकल नेटवर्क पर वापस आ जाना चाहिए. साथ ही, सभी सुविधाएं पहले की तरह काम करनी चाहिए. यहां बताया गया है कि ऐप्लिकेशन नेटवर्क ट्रैफ़िक पर इसका क्या असर पड़ा.

Appcompat कॉन्फ़िगरेशन को टॉगल-ऑफ़ करने के लिए, इस कमांड का इस्तेमाल करें

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

गड़बड़ियां

अगर अनुमति न होने की वजह से, लोकल नेटवर्क ऐक्सेस करने का अनुरोध पूरा नहीं होता है, तो:

• टीसीपी कनेक्शन की वजह से आम तौर पर, टाइमआउट की गड़बड़ी होती है.

• आम तौर पर, यूडीपी से जुड़ी गड़बड़ियों और अनुमति न मिलने की वजह से, EPERM गड़बड़ी कोड दिखता है

बग

इनके लिए गड़बड़ियों की शिकायत करें और सुझाव, शिकायत या राय दें:

• LAN ऐक्सेस में अंतर (आपको लगता है कि किसी ऐक्सेस को "लोकल नेटवर्क" ऐक्सेस नहीं माना जाना चाहिए)
• ऐसे बग जिनमें LAN ऐक्सेस को ब्लॉक किया जाना चाहिए, लेकिन ब्लॉक नहीं किया गया है
• ऐसे बग जिनमें LAN का ऐक्सेस ब्लॉक नहीं किया जाना चाहिए, लेकिन ब्लॉक किया गया है

इस बदलाव से इन पर कोई असर नहीं पड़ना चाहिए:

• इंटरनेट का ऐक्सेस
• मोबाइल नेटवर्क