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

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

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

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

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

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

Android 15 强制执行全屏显示，以针对 Android 15（API 级别 35）的应用为目标平台，但您的应用可以通过将 R.attr#windowOptOutEdgeToEdgeEnforcement 设置为 true 来选择停用。对于以 Android 16（API 级别 36）为目标平台的应用，R.attr#windowOptOutEdgeToEdgeEnforcement 已被废弃并停用，并且您的应用无法选择不采用从边缘到边缘的布局。

• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 15 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会继续正常运行。
• 如果您的应用以 Android 16（API 级别 36）为目标平台，并且在 Android 16 设备上运行，则 R.attr#windowOptOutEdgeToEdgeEnforcement 会被停用。

如需在 Android 16 中进行测试，请确保您的应用支持无边框设计，并移除所有 R.attr#windowOptOutEdgeToEdgeEnforcement 用法，以便您的应用在 Android 15 设备上也能支持无边框设计。如需支持从边缘到边缘的显示，请参阅 Compose 和 View 指南。

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

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

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

होम स्क्रीन पर वापस जाने के लिए, प्रिडिक्टिव ऐनिमेशन.

प्रिडिक्टिव क्रॉस-ऐक्टिविटी ऐनिमेशन.

प्रिडिक्टिव क्रॉस-टास्क ऐनिमेशन.

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

以 Android 15（API 级别 35）为目标平台的应用默认将 elegantTextHeight TextView 属性设置为 true，从而将紧凑型字体替换为可读性更高的字体。您可以通过将 elegantTextHeight 属性设置为 false 来替换此设置。

Android 16 弃用了 elegantTextHeight 属性，当您的应用以 Android 16 为目标平台后，系统会忽略该属性。由这些 API 控制的“界面字体”即将停用，因此您应调整所有布局，以确保阿拉伯语、老挝语、缅甸语、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语文本的呈现效果一致且不受未来变化的影响。

针对以 Android 14（API 级别 34）及更低版本为目标平台的应用，或针对以 Android 15（API 级别 35）为目标平台且通过将 elegantTextHeight 属性设置为 false 替换默认值的应用，

elegantTextHeight 行为。

以 Android 16（API 级别 36）为目标平台的应用，或以 Android 15（API 级别 35）为目标平台但未通过将 elegantTextHeight 属性设置为 false 来替换默认值的应用，其

elegantTextHeight 行为。

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

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 के किसी नए वर्शन में एपीआई लेवल 37 को टारगेट करने पर लागू नहीं होगी. इसका मतलब है कि एपीआई लेवल 37 को टारगेट करने वाले ऐप्लिकेशन के लिए, कम से कम sw600dp डाइमेंशन वाले डिसप्ले पर, ओरिएंटेशन, आसपेक्ट रेशियो, और साइज़ बदलने से जुड़ी पाबंदियों को अनदेखा किया जाता है.

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

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

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

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

• Wear OS पर Health Services से HEART_RATE_BPM
• Android Sensor Manager से Sensor.TYPE_HEART_RATE
• Wear OS पर 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 से डेटा पढ़ने की अनुमतियों जैसी ही हैं. Health Connect, सेहत, फ़िटनेस, और तंदुरुस्ती से जुड़े डेटा के लिए Android का डेटास्टोर है.

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

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

अहम जानकारी: मोबाइल ऐप्लिकेशन के लिए वजह न बताने पर, अनुमति रद्द कर दी जाएगी.

कनेक्टिविटी

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

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

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

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

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

अलग-अलग ओईएम के लागू करने के तरीकों के हिसाब से बदलाव करना

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

हमारा सुझाव है कि आपके ऐप्लिकेशन में ये काम किए जाएं:

• अगर ACTION_KEY_MISSING इंटेंट ब्रॉडकास्ट किया जाता है, तो:

  सिस्टम, एसीएल (असिंक्रोनस कनेक्शन-लेस) लिंक को डिसकनेक्ट कर देगा. हालांकि, डिवाइस के लिए बॉन्ड की जानकारी को बनाए रखा जाएगा, जैसा कि यहां बताया गया है.

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

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

• अगर ACTION_KEY_MISSING इंटेंट ब्रॉडकास्ट नहीं किया जाता है, तो:

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

  इस स्थिति में, आपके ऐप्लिकेशन को बॉन्ड के खत्म होने की जानकारी देने वाले मौजूदा तरीकों का इस्तेमाल करना जारी रखना चाहिए. ऐसा Android की पिछली रिलीज़ की तरह ही करना होगा, ताकि बॉन्ड के खत्म होने की जानकारी का पता लगाया जा सके और उसे मैनेज किया जा सके.

ब्लूटूथ बॉन्ड हटाने का नया तरीका

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

सुरक्षा

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

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

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

सेफ़र इंटेंट

'ज़्यादा सुरक्षित इंटेंट' सुविधा, सुरक्षा से जुड़ी एक ऐसी पहल है जिसे कई चरणों में लागू किया जाता है. इसे Android के इंटेंट रिज़ॉल्यूशन मैकेनिज्म की सुरक्षा को बेहतर बनाने के लिए डिज़ाइन किया गया है. इसका मकसद, इंटेंट प्रोसेस करने के दौरान जांच जोड़कर और खास शर्तें पूरी न करने वाले इंटेंट को फ़िल्टर करके, ऐप्लिकेशन को नुकसान पहुंचाने वाली कार्रवाइयों से बचाना है.

Android 15 में, यह सुविधा भेजने वाले ऐप्लिकेशन पर फ़ोकस करती थी. अब Android 16 में, यह कंट्रोल पाने वाले ऐप्लिकेशन पर फ़ोकस करती है. इससे डेवलपर, अपने ऐप्लिकेशन मेनिफ़ेस्ट का इस्तेमाल करके, इंटेंट रिज़ॉल्यूशन के सख्त नियमों के लिए ऑप्ट-इन कर सकते हैं.

दो मुख्य बदलाव लागू किए जा रहे हैं:

1. एक्सप्लिसिट इंटेंट, टारगेट कॉम्पोनेंट के इंटेंट फ़िल्टर से मैच होने चाहिए: अगर कोई इंटेंट साफ़ तौर पर किसी कॉम्पोनेंट को टारगेट करता है, तो उसे उस कॉम्पोनेंट के इंटेंट फ़िल्टर से मैच करना चाहिए.

2. जिन इंटेंट में कोई कार्रवाई तय नहीं की गई है वे किसी भी इंटेंट फ़िल्टर से मैच नहीं कर सकते: जिन इंटेंट में कोई कार्रवाई तय नहीं की गई है उन्हें किसी भी इंटेंट फ़िल्टर से हल नहीं किया जाना चाहिए.

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

असर

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

• आपको 'सुरक्षित इंटेंट' सुविधा और इसके फ़ायदों के बारे में पता हो.
• अपने ऐप्लिकेशन में, इंटेंट मैनेज करने के सख्त तरीकों को शामिल करने का विकल्प चुनें.

ऑप्ट-इन करने का यह तरीका, मौजूदा ऐप्लिकेशन के काम न करने के जोखिम को कम करता है. ये ऐप्लिकेशन, इंटेंट रिज़ॉल्यूशन के मौजूदा तरीके पर भरोसा कर सकते हैं, जो कम सुरक्षित है.

Android 16 में शुरुआती असर सीमित हो सकता है. हालांकि, 'ज़्यादा सुरक्षित इंटेंट' इनिशिएटिव के तहत, Android के आने वाले वर्शन में ज़्यादा असर डालने के लिए रोडमैप तैयार किया गया है. हमारा प्लान है कि हम इंटेंट रिज़ॉल्यूशन को डिफ़ॉल्ट तौर पर लागू करें.

'ज़्यादा सुरक्षित इंटेंट' सुविधा से, Android नेटवर्क की सुरक्षा को बेहतर बनाया जा सकता है. इससे नुकसान पहुंचाने वाले ऐप्लिकेशन के लिए, इंटेंट रिज़ॉल्यूशन मैकेनिज्म में मौजूद जोखिम का फ़ायदा उठाना मुश्किल हो जाता है.

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

लागू करना

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

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

ध्यान दें: इस एट्रिब्यूट की वैल्यू को <application> टैग के साथ-साथ, <activity>, <activity-alias>, <receiver>, <service>, <provider> जैसे कॉम्पोनेंट टैग पर भी सेट किया जा सकता है. साथ ही, कॉम्पोनेंट पर मौजूद एट्रिब्यूट की वैल्यू का इस्तेमाल, <application> टैग पर मौजूद वैल्यू को बदलने के लिए किया जा सकता है

इस्तेमाल किए जा सकने वाले फ़्लैग के बारे में ज़्यादा जानकारी:

फ़्लैग का नाम	ब्यौरा
enforceIntentFilter	आने वाले इंटेंट के लिए, ज़्यादा सख्त मैचिंग लागू करता है
कोई नहीं	इनकमिंग इंटेंट के लिए, मैच करने के सभी खास नियमों को बंद कर देता है. एक से ज़्यादा फ़्लैग तय करने पर, "कोई नहीं" फ़्लैग को प्राथमिकता देकर, अलग-अलग वैल्यू को हल किया जाता है
allowNullAction	मैच करने के नियमों को आसान बनाता है, ताकि बिना किसी कार्रवाई के भी इंटेंट को मैच किया जा सके. किसी खास व्यवहार को हासिल करने के लिए, इस फ़्लैग का इस्तेमाल "enforceIntentFilter" के साथ किया जाना चाहिए

जांच करना और डीबग करना

नीति उल्लंघन ठीक करने की सुविधा चालू होने पर, अगर इंटेंट कॉलर ने इंटेंट को सही तरीके से भरा है, तो ऐप्लिकेशन ठीक से काम करने चाहिए. हालांकि, ब्लॉक किए गए इंटेंट से, "PackageManager." टैग के साथ "Intent does not match component's intent filter:" और "Access blocked:" जैसे चेतावनी वाले लॉग मैसेज ट्रिगर होंगे. इससे, किसी ऐसी संभावित समस्या का पता चलता है जिससे ऐप्लिकेशन पर असर पड़ सकता है और जिस पर ध्यान देने की ज़रूरत है.

Logcat फ़िल्टर:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

निजता

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

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

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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

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

• अगर किसी डिवाइस का डीएनएस सर्वर लोकल नेटवर्क पर है, तो उस पर या उससे आने-जाने वाले ट्रैफ़िक (पोर्ट 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. सेटिंग > ऐप्लिकेशन > [ऐप्लिकेशन का नाम] > अनुमतियां > आस-पास के डिवाइस > अनुमति दें पर जाएं.

ध्यान दें: आने वाले समय में Android के किसी नए वर्शन में, इस सुविधा को आस-पास मौजूद डिवाइसों से कनेक्ट करने की अनुमति वाले ग्रुप में नई अनुमति से सुरक्षित किया जाएगा

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

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

अनुमति	आउटबाउंड LAN अनुरोध	आउटबाउंड/इनबाउंड इंटरनेट अनुरोध	इनबाउंड LAN अनुरोध
प्रदान किया गया	Works	Works	Works
अनुमति नहीं दी गई	विफल	Works	विफल

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

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), दोनों को लोकल नेटवर्क पते के तौर पर रखा जाता है.

ऐप्लिकेशन के मालिकाना हक वाली फ़ोटो

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