काम करने के तरीके में बदलाव: Android 16 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

Android 16 पर काम करने वाले सभी ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची भी देखना न भूलें. भले ही, आपके ऐप्लिकेशन का targetSdkVersion कुछ भी हो.

उपयोगकर्ता अनुभव और सिस्टम यूज़र इंटरफ़ेस (यूआई)

Android 16 (एपीआई लेवल 36) में ये बदलाव किए गए हैं, ताकि उपयोगकर्ता को बेहतर और आसान अनुभव मिल सके.

एज-टू-एज ऑप्ट-आउट की सुविधा बंद होने वाली है

Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, Android 15 में एज-टू-एज डिसप्ले की सुविधा लागू की गई है. हालांकि, आपका ऐप्लिकेशन R.attr#windowOptOutEdgeToEdgeEnforcement को true पर सेट करके, इस सुविधा से ऑप्ट-आउट कर सकता है. Android 16 (एपीआई लेवल 36) को टारगेट करने वाले ऐप्लिकेशन के लिए, R.attr#windowOptOutEdgeToEdgeEnforcement एट्रिब्यूट का इस्तेमाल नहीं किया जा सकता. साथ ही, इसे बंद कर दिया गया है. इसलिए, आपका ऐप्लिकेशन एज-टू-एज डिसप्ले की सुविधा से ऑप्ट-आउट नहीं कर सकता.

• अगर आपका ऐप्लिकेशन Android 16 (एपीआई लेवल 36) को टारगेट करता है और वह Android 15 डिवाइस पर चल रहा है, तो R.attr#windowOptOutEdgeToEdgeEnforcement काम करता रहेगा.
• अगर आपका ऐप्लिकेशन Android 16 (एपीआई लेवल 36) को टारगेट करता है और वह Android 16 डिवाइस पर चल रहा है, तो R.attr#windowOptOutEdgeToEdgeEnforcement बंद हो जाता है.

Android 16 Beta 3 में टेस्ट करने के लिए, पक्का करें कि आपका ऐप्लिकेशन किनारे-किनारे तक दिखने की सुविधा के साथ काम करता हो. साथ ही, R.attr#windowOptOutEdgeToEdgeEnforcement का इस्तेमाल न करें, ताकि आपका ऐप्लिकेशन Android 15 डिवाइस पर भी किनारे-किनारे तक दिखने की सुविधा के साथ काम कर सके. पूरे स्क्रीन पर दिखने वाले आइटम के लिए, लिखें और व्यू से जुड़े दिशा-निर्देश देखें.

अनुमानित रीडायरेक्ट की सुविधा के लिए, माइग्रेट करना या ऑप्ट-आउट करना ज़रूरी है

Android 16 (एपीआई लेवल 36) या उसके बाद के वर्शन को टारगेट करने वाले और Android 16 या उसके बाद के वर्शन वाले डिवाइसों पर चलने वाले ऐप्लिकेशन के लिए, अनुमानित बैक सिस्टम ऐनिमेशन (होम स्क्रीन पर वापस जाने, एक टास्क से दूसरे टास्क पर जाने, और एक गतिविधि से दूसरी गतिविधि पर जाने) डिफ़ॉल्ट रूप से चालू होते हैं. इसके अलावा, onBackPressed को कॉल नहीं किया जाता और अब KeyEvent.KEYCODE_BACK को डिस्पैच नहीं किया जाता.

अगर आपका ऐप्लिकेशन, बैक इवेंट को इंटरसेप्ट करता है और आपने अब तक अनुमानित बैक पर माइग्रेट नहीं किया है, तो अपने ऐप्लिकेशन को अपडेट करें, ताकि वह बैक नेविगेशन के लिए काम करने वाले एपीआई का इस्तेमाल कर सके. इसके अलावा, अपने ऐप्लिकेशन की AndroidManifest.xml फ़ाइल के <application> या <activity> टैग में, android:enableOnBackInvokedCallback एट्रिब्यूट को false पर सेट करके, कुछ समय के लिए ऑप्ट आउट करें.

Elegant फ़ॉन्ट एपीआई बंद कर दिए गए हैं

Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन में, elegantTextHeight TextView एट्रिब्यूट की वैल्यू डिफ़ॉल्ट रूप से true पर सेट होती है. इससे कॉम्पैक्ट फ़ॉन्ट को ऐसे फ़ॉन्ट से बदल दिया जाता है जिसे पढ़ना आसान होता है. elegantTextHeight एट्रिब्यूट को false पर सेट करके, इसे बदला जा सकता है.

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

मुख्य फ़ंक्शन

Android 16 (एपीआई लेवल 36) में ये बदलाव किए गए हैं. इनसे Android सिस्टम की मुख्य सुविधाओं में बदलाव होता है या उन्हें बेहतर बनाया जाता है.

तय दर पर काम शेड्यूल करने की सुविधा को ऑप्टिमाइज़ करना

Android 16 को टारगेट करने से पहले, जब scheduleAtFixedRate किसी टास्क को पूरा करने के लिए, प्रोसेस लाइफ़साइकल के मान्य समयसीमा के बाहर होने की वजह से, टास्क पूरा नहीं हो पाता था, तो ऐप्लिकेशन के मान्य लाइफ़साइकल में वापस आने पर, सभी टास्क तुरंत पूरे हो जाते थे.

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

डिवाइस के नाप या आकार

Android 16 (एपीआई लेवल 36) में, बड़ी स्क्रीन वाले डिवाइसों पर ऐप्लिकेशन के दिखने के तरीके में ये बदलाव किए गए हैं.

अडैप्टिव लेआउट

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

ओरिएंटेशन, साइज़ बदलने, और आसपेक्ट रेशियो से जुड़ी पाबंदियों को अनदेखा करना

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

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

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

आम तौर पर होने वाले बदलाव

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

डिवाइस के रोटेशन की अनुमति देने पर, गतिविधि को फिर से बनाने की संख्या बढ़ जाती है. अगर उपयोगकर्ता की स्थिति को ठीक से सेव नहीं किया जाता है, तो इससे उपयोगकर्ता की स्थिति खो सकती है. यूज़र इंटरफ़ेस की स्थिति सेव करना लेख में, यूज़र इंटरफ़ेस की स्थिति को सही तरीके से सेव करने का तरीका जानें.

लागू करने से जुड़ी जानकारी

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

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

screenOrientation, setRequestedOrientation(), और getRequestedOrientation() के लिए, इन वैल्यू को अनदेखा किया जाता है:

• portrait
• reversePortrait
• sensorPortrait
• userPortrait
• landscape
• reverseLandscape
• sensorLandscape
• userLandscape

डिसप्ले के साइज़ में बदलाव करने के मामले में, android:resizeableActivity="false", android:minAspectRatio, और android:maxAspectRatio का कोई असर नहीं पड़ता.

Android 16 (एपीआई लेवल 36) को टारगेट करने वाले ऐप्लिकेशन के लिए, बड़ी स्क्रीन पर ऐप्लिकेशन के ओरिएंटेशन, साइज़ बदलने, और आसपेक्ट रेशियो से जुड़ी पाबंदियां डिफ़ॉल्ट रूप से लागू नहीं होती हैं. हालांकि, जो ऐप्लिकेशन पूरी तरह से तैयार नहीं हैं वे ऑप्ट आउट करके, कुछ समय के लिए इस व्यवहार को बदल सकते हैं. इससे, ऐप्लिकेशन को काम करने के लिए बनाए गए पुराने मोड में रखा जाता है.

अपवाद

Android 16 में, ओरिएंटेशन, साइज़ बदलने, और आसपेक्ट रेशियो से जुड़ी पाबंदियां इन स्थितियों में लागू नहीं होतीं:

• गेम (android:appCategory फ़्लैग के आधार पर)
• डिवाइस के आसपेक्ट रेशियो की सेटिंग में जाकर, उपयोगकर्ताओं ने ऐप्लिकेशन के डिफ़ॉल्ट तरीके के लिए साफ़ तौर पर ऑप्ट-इन किया हो
• sw600dp से छोटी स्क्रीन

कुछ समय के लिए ऑप्ट आउट करना

किसी खास गतिविधि से ऑप्ट आउट करने के लिए, PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY मेनिफ़ेस्ट प्रॉपर्टी का एलान करें:

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

अगर आपके ऐप्लिकेशन के कई हिस्से Android 16 के लिए तैयार नहीं हैं, तो ऐप्लिकेशन लेवल पर उसी प्रॉपर्टी को लागू करके, पूरी तरह से ऑप्ट आउट किया जा सकता है:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

सेहत और फ़िटनेस

Android 16 (एपीआई लेवल 36) में, सेहत और फ़िटनेस से जुड़े डेटा से जुड़े ये बदलाव किए गए हैं.

सेहत और फ़िटनेस से जुड़ी अनुमतियां

Android 16 (एपीआई लेवल 36) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, BODY_SENSORS अनुमतियां, android.permissions.health में मौजूद ज़्यादा सटीक अनुमतियों में बदल रही हैं. इनका इस्तेमाल Health Connect भी करता है. पहले जिस एपीआई को BODY_SENSORS या BODY_SENSORS_BACKGROUND की ज़रूरत थी उसे अब उससे जुड़ी android.permissions.health अनुमति की ज़रूरत होगी. इसका असर इन डेटा टाइप, एपीआई, और फ़ोरग्राउंड सेवा के टाइप पर पड़ता है:

• Wear Health Services से HEART_RATE_BPM
• Android Sensor Manager से Sensor.TYPE_HEART_RATE
• Wear ProtoLayout से heartRateAccuracy और heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH, जहां BODY_SENSORS के बजाय, संबंधित android.permission.health अनुमति की ज़रूरत है

अगर आपका ऐप्लिकेशन इन एपीआई का इस्तेमाल करता है, तो अब उसे ज़्यादा जानकारी वाली अनुमतियों का अनुरोध करना चाहिए:

• ऐप्लिकेशन इस्तेमाल करने के दौरान, दिल की धड़कन, SpO2 या त्वचा के तापमान को मॉनिटर करने के लिए: android.permissions.health में जाकर, ज़्यादा जानकारी वाली अनुमति का अनुरोध करें. जैसे, BODY_SENSORS के बजाय READ_HEART_RATE.
• बैकग्राउंड में सेंसर का ऐक्सेस पाने के लिए: BODY_SENSORS_BACKGROUND के बजाय, READ_HEALTH_DATA_IN_BACKGROUND का अनुरोध करें.

ये अनुमतियां, Health Connect से डेटा पढ़ने के ऐक्सेस की सुरक्षा करने वाली अनुमतियों जैसी ही हैं. यह Android का डेटास्टोर है, जिसमें सेहत, फ़िटनेस, और सेहत से जुड़ी जानकारी का डेटा सेव होता है.

मोबाइल ऐप्लिकेशन पर मौजूद हैं

READ_HEART_RATE और अन्य ज़्यादा जानकारी वाली अनुमतियों का इस्तेमाल करने के लिए माइग्रेट करने वाले मोबाइल ऐप्लिकेशन को, ऐप्लिकेशन की निजता नीति दिखाने के लिए किसी गतिविधि का एलान भी करना होगा. यह वही ज़रूरी शर्त है जो Health Connect के लिए भी है.

कनेक्टिविटी

Android 16 (एपीआई लेवल 36) में, ब्लूटूथ स्टैक में ये बदलाव किए गए हैं, ताकि सहायक डिवाइसों के साथ कनेक्टिविटी को बेहतर बनाया जा सके.

बॉन्ड के खत्म होने और एन्क्रिप्शन में बदलावों को मैनेज करने के लिए नए इंटेंट

बॉन्ड के खोने की बेहतर तरीके से निगरानी करने के लिए, Android 16 में दो नए इंटेंट भी जोड़े गए हैं. इनसे ऐप्लिकेशन को बॉन्ड के खोने और एन्क्रिप्शन में हुए बदलावों के बारे में ज़्यादा जानकारी मिलती है.

Android 16 को टारगेट करने वाले ऐप्लिकेशन अब ये काम कर सकते हैं:

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

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

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

सुरक्षा

Android 16 (एपीआई लेवल 36) में सुरक्षा से जुड़े ये बदलाव शामिल हैं.

MediaStore के वर्शन को लॉक करना

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

निजता

Android 16 (एपीआई लेवल 36) में निजता से जुड़े ये बदलाव शामिल हैं.

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

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

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

रिलीज़ प्लान

यह बदलाव, 25Q2 और TBD, दोनों रिलीज़ के बीच डिप्लॉय किया जाएगा. यह ज़रूरी है कि डेवलपर 25Q2 के लिए इन दिशा-निर्देशों का पालन करें और सुझाव/राय/शिकायत शेयर करें. ऐसा इसलिए, क्योंकि सुरक्षा से जुड़ी ये सुविधाएं Android के किसी नए वर्शन में लागू की जाएंगी. इसके अलावा, उन्हें यहां दिए गए दिशा-निर्देशों का इस्तेमाल करके, उन स्थितियों को अपडेट करना होगा जो डिफ़ॉल्ट रूप से स्थानीय नेटवर्क ऐक्सेस पर निर्भर हैं. साथ ही, उन्हें उपयोगकर्ता की ओर से नई अनुमति अस्वीकार किए जाने और उसे रद्द किए जाने के लिए तैयार रहना होगा.

असर

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

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

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

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

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

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

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

डेवलपर के लिए दिशा-निर्देश (ऑप्ट-इन)

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

1. डिवाइस को 25Q2 Beta 3 या उसके बाद के वर्शन वाले बिल्ड पर फ़्लैश करें.
2. जिस ऐप्लिकेशन की जांच करनी है उसे इंस्टॉल करें.

3. adb में, Appcompat फ़्लैग को टॉगल करें:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

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

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

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

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

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

लोकल नेटवर्क की सुरक्षा के लिए नीति लागू होने के बाद, ऐप्लिकेशन के नेटवर्क ट्रैफ़िक पर यह असर पड़ेगा.

ऐप्लिकेशन के साथ काम करने की सुविधा वाले फ़्लैग को टॉगल-ऑफ़ करने के लिए, यह कमांड इस्तेमाल करें

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

गड़बड़ियां

इन पाबंदियों की वजह से होने वाली गड़बड़ियां, कॉल करने वाले सॉकेट को तब भेजी जाएंगी, जब वह किसी स्थानीय नेटवर्क पते पर send या send के किसी वैरिएंट को कॉल करेगा.

गड़बड़ियों के उदाहरण:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

लोकल नेटवर्क की परिभाषा

इस प्रोजेक्ट में, लोकल नेटवर्क से ऐसे आईपी नेटवर्क का मतलब है जो ब्रॉडकास्ट करने की सुविधा वाले नेटवर्क इंटरफ़ेस का इस्तेमाल करता है. जैसे, वाई-फ़ाई या ईथरनेट. इसमें मोबाइल (डब्ल्यूडब्ल्यूएएन) या वीपीएन कनेक्शन शामिल नहीं हैं.

इन नेटवर्क को लोकल नेटवर्क माना जाता है:

IPv4:

• 169.254.0.0/16 // लिंक लोकल
• 100.64.0.0/10 // सीजीएनएटी
• 10.0.0.0/8 // RFC1918
• 172.16.0.0/12 // RFC1918
• 192.168.0.0/16 // RFC1918

IPv6:

• लिंक-लोकल
• सीधे तौर पर कनेक्ट किए गए रास्ते
• Thread जैसे स्टब नेटवर्क
• एक से ज़्यादा सबनेट (अभी तय नहीं है)

इसके अलावा, मल्टीकास्ट पते (224.0.0.0/4, ff00::/8) और IPv4 ब्रॉडकास्ट पता (255.255.255.255), दोनों को लोकल नेटवर्क पते के तौर पर बांटा जाता है.