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

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

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

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

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

बिना बॉर्डर की फ़ुल साइज़ फ़ोटो दिखाने की सुविधा बंद की जा रही है

Android 15 में एज-टू-एज डिसप्ले की सुविधा ज़रूरी है. यह सुविधा उन ऐप्लिकेशन के लिए है जो Android 15 (एपीआई लेवल 35) को टारगेट करते हैं. हालांकि, आपका ऐप्लिकेशन 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 में टेस्टिंग के लिए, पक्का करें कि आपका ऐप्लिकेशन एज-टू-एज डिसप्ले की सुविधा के साथ काम करता हो. साथ ही, R.attr#windowOptOutEdgeToEdgeEnforcement का इस्तेमाल न करें, ताकि आपका ऐप्लिकेशन Android 15 वाले डिवाइस पर भी एज-टू-एज डिसप्ले की सुविधा के साथ काम कर सके. एज-टू-एज डिसप्ले की सुविधा के बारे में जानने के लिए, Compose और Views से जुड़े दिशा-निर्देश देखें.

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

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

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

होम स्क्रीन पर वापस जाने पर झलक दिखाने वाला ऐनिमेशन.

अलग-अलग गतिविधि के लिए, अनुमान के आधार पर तैयार किया गया ऐनिमेशन.

अलग-अलग टास्क के बीच स्विच करने पर, झलक दिखाने वाला ऐनिमेशन.

बेहतर फ़ॉन्ट वाले एपीआई बंद किए जा रहे हैं और उन्हें बंद कर दिया गया है

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Android 16 (एपीआई लेवल 36) को टारगेट करने वाले ऐप्लिकेशन के लिए, ओरिएंटेशन, साइज़ बदलने, और आसपेक्ट रेशियो से जुड़ी पाबंदियां, 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（API 级别 36）或更高版本为目标平台的应用， BODY_SENSORS 权限使用更精细的权限 under android.permissions.health，which Health Connect also uses。从 Android 16 开始，凡是以前需要具有 BODY_SENSORS 或 BODY_SENSORS_BACKGROUND 权限的 API，现在都需要获取相应的 android.permissions.health 权限。这会影响以下数据类型、API 和前台服务类型：

• HEART_RATE_BPM Wear OS 上的健康服务
• Sensor.TYPE_HEART_RATE 来自 Android Sensor Manager
• heartRateAccuracy 和 heartRateBpm（来自 Wear OS 上的 ProtoLayout）
• FOREGROUND_SERVICE_TYPE_HEALTH ，其中需要使用相应的 android.permission.health 权限来代替 BODY_SENSORS

如果您的应用使用这些 API，则应请求相应的精细权限：

• 如需在使用期间监测心率、血氧饱和度或体表温度： 请请求 android.permissions.health 下的精细权限，例如 READ_HEART_RATE，而不是 BODY_SENSORS。
• 如需访问后台传感器，请请求 READ_HEALTH_DATA_IN_BACKGROUND，而不是 BODY_SENSORS_BACKGROUND。

这些权限与保护对 Health Connect（用于存储健康、 健身和保健数据的 Android 数据存储区）中数据的读取访问权限的权限相同。

移动应用

迁移为使用 READ_HEART_RATE 和其他精细权限的移动应用还必须 声明一项 activity 以显示应用的隐私权政策。这与健康数据共享的要求相同。

**重要提示：** 如果未能为移动应用提供理由，系统将撤消相应 权限。

कनेक्टिविटी

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

डिवाइसों के बीच कनेक्शन टूटने और एन्क्रिप्ट किए गए डेटा में बदलाव होने की सूचना देने वाले नए इंटेंट

作为改进了对键值对丢失的处理的一部分，Android 16 还引入了 2 个新 intent，以便应用更好地了解键值对丢失和加密更改。

以 Android 16 为目标平台的应用现在可以：

• 在检测到远程键盘连接丢失时接收 ACTION_KEY_MISSING intent，以便提供更具信息量的用户反馈并采取适当的措施。
• 每当链接的加密状态发生变化时，都会收到 ACTION_ENCRYPTION_CHANGE intent。这包括加密状态更改、加密算法更改和加密密钥大小更改。如果应用在稍后收到 ACTION_ENCRYPTION_CHANGE intent 时成功加密了链接，则必须将该绑定视为已恢复。

适应不同的 OEM 实现

虽然 Android 16 引入了这些新 intent，但其实现和广播可能会因不同的设备制造商 (OEM) 而异。为了确保您的应用在所有设备上都能提供一致且可靠的体验，开发者应设计其绑定丢失处理机制，以妥善适应这些潜在的变化。

我们建议您采用以下应用行为：

• 如果广播 ACTION_KEY_MISSING intent：

  系统会断开 ACL（异步无连接）链接，但会保留设备的配对信息（如此处所述）。

  您的应用应将此 intent 用作检测配对丢失的主要信号，并在发起设备忘记或重新配对之前引导用户确认远程设备是否在范围内。

  如果设备在收到 ACTION_KEY_MISSING 后断开连接，您的应用应谨慎重新连接，因为设备可能已不再与系统绑定。

• 如果未广播 ACTION_KEY_MISSING intent：

  ACL 链接将保持连接状态，系统会移除设备的配对信息，与 Android 15 中的行为相同。

  在这种情况下，您的应用应继续使用与之前的 Android 版本相同的现有配对丢失处理机制，以检测和管理配对丢失事件。

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

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

सुरक्षा

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

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

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

ज़्यादा सुरक्षित इंटेंट

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

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

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

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

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

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

असर

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

• Safer Intents सुविधा और इसके फ़ायदों के बारे में जानते हों.
• अपने ऐप्लिकेशन में, उपयोगकर्ता के इरादे को समझने के लिए बेहतर तरीकों का इस्तेमाल करें.

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

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

Safer Intents सुविधा, 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	इससे आने वाले इंटेंट के लिए, मैचिंग को ज़्यादा सख्ती से लागू किया जाता है
कोई नहीं	इससे, आने वाले इंटेंट के लिए मैचिंग के सभी खास नियम बंद हो जाते हैं. एक से ज़्यादा फ़्लैग तय करते समय, अलग-अलग वैल्यू को "none" फ़्लैग को प्राथमिकता देकर हल किया जाता है
allowNullAction	मैचिंग के नियमों को आसान बनाता है, ताकि बिना किसी कार्रवाई वाले इंटेंट को मैच किया जा सके. इस फ़्लैग का इस्तेमाल "enforceIntentFilter" के साथ किया जाता है, ताकि किसी खास व्यवहार को लागू किया जा सके

टेस्टिंग और डीबग करना

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

Logcat फ़िल्टर:

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

जीपीयू सिस्टम कॉल फ़िल्टरिंग

Mali GPU की सुरक्षा बढ़ाने के लिए, प्रोडक्शन बिल्ड में Mali GPU के उन IOCTL को ब्लॉक कर दिया गया है जो अब काम नहीं करते या जिनका इस्तेमाल सिर्फ़ GPU डेवलपमेंट के लिए किया जाता है. इसके अलावा, GPU की प्रोफ़ाइलिंग के लिए इस्तेमाल किए जाने वाले IOCTL को शेल प्रोसेस या डीबग किए जा सकने वाले ऐप्लिकेशन तक सीमित कर दिया गया है. प्लेटफ़ॉर्म-लेवल की नीति के बारे में ज़्यादा जानने के लिए, एसएसी का अपडेट देखें.

यह बदलाव, Mali GPU (Pixel 6-9) का इस्तेमाल करने वाले Pixel डिवाइसों पर लागू होता है. Arm ने अपने r54p2 रिलीज़ के Documentation/ioctl-categories.rst में, अपने IOCTL को आधिकारिक तौर पर अलग-अलग कैटगरी में बांटा है. ड्राइवर के आने वाले वर्शन में भी, इस सूची को अपडेट किया जाता रहेगा.

इस बदलाव से, ग्राफ़िक्स के काम करने वाले एपीआई (Vulkan और OpenGL शामिल हैं) पर कोई असर नहीं पड़ेगा. साथ ही, इससे डेवलपर या मौजूदा ऐप्लिकेशन पर भी कोई असर नहीं पड़ेगा. GPU की प्रोफ़ाइलिंग के टूल, जैसे कि Streamline Performance Analyzer और Android GPU Inspector पर कोई असर नहीं पड़ेगा.

जांच करना

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

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

अगर आपके ऐप्लिकेशन को ब्लॉक किए गए IOCTL का इस्तेमाल करना है, तो कृपया गड़बड़ी की शिकायत करें और उसे [e-mail] को असाइन करें.

अक्सर पूछे जाने वाले सवाल

1. क्या नीति में किया गया यह बदलाव, सभी OEM पर लागू होता है? यह बदलाव ऑप्ट-इन होगा. हालांकि, यह उन सभी OEM के लिए उपलब्ध होगा जो सुरक्षा बढ़ाने के इस तरीके का इस्तेमाल करना चाहते हैं. बदलाव को लागू करने के निर्देश, लागू करने से जुड़े दस्तावेज़ में देखे जा सकते हैं.

2. क्या इसे लागू करने के लिए, OEM को अपने कोडबेस में बदलाव करना ज़रूरी है या यह डिफ़ॉल्ट रूप से, AOSP के नए वर्शन के साथ उपलब्ध होता है? प्लेटफ़ॉर्म-लेवल का यह बदलाव, डिफ़ॉल्ट रूप से AOSP के नए वर्शन के साथ उपलब्ध होगा. अगर वेंडर इस बदलाव को लागू करना चाहते हैं, तो वे अपने कोडबेस में इसके लिए ऑप्ट-इन कर सकते हैं.

3. क्या IOCTL की सूची को अप-टू-डेट रखने की ज़िम्मेदारी SoC की है? उदाहरण के लिए, अगर मेरे डिवाइस में ARM Mali GPU का इस्तेमाल किया जाता है, तो क्या मुझे किसी भी बदलाव के लिए ARM से संपर्क करना होगा? ड्राइवर रिलीज़ होने के बाद, हर SoC को डिवाइस के हिसाब से अपने IOCTL की सूची अपडेट करनी होगी. उदाहरण के लिए, ड्राइवर के अपडेट होने पर, ARM पब्लिश की गई अपनी IOCTL की सूची को अपडेट करेगा. हालांकि, OEM को यह पक्का करना चाहिए कि वे अपने SEPolicy में अपडेट शामिल करें. साथ ही, ज़रूरत के हिसाब से चुनिंदा कस्टम IOCTL को सूचियों में जोड़ें.

4. क्या यह बदलाव, बाज़ार में मौजूद सभी Pixel डिवाइसों पर अपने-आप लागू हो जाता है या इसे लागू करने के लिए, उपयोगकर्ता को कोई कार्रवाई करनी पड़ती है? यह बदलाव, बाज़ार में मौजूद Mali GPU (Pixel 6-9) का इस्तेमाल करने वाले सभी Pixel डिवाइसों पर लागू होता है. इस बदलाव को लागू करने के लिए, उपयोगकर्ता को कोई कार्रवाई नहीं करनी पड़ती.

5. क्या इस नीति के इस्तेमाल से, कर्नेल ड्राइवर की परफ़ॉर्मेंस पर असर पड़ेगा? इस नीति को GFXBench का इस्तेमाल करके, Mali GPU पर टेस्ट किया गया. इस दौरान, GPU की परफ़ॉर्मेंस में कोई बदलाव नहीं दिखा.

6. क्या IOCTL की सूची का, मौजूदा यूज़रस्पेस और कर्नेल ड्राइवर के वर्शन के साथ अलाइन होना ज़रूरी है? हां, अनुमति वाले IOCTL की सूची को, यूज़रस्पेस और कर्नेल ड्राइवर, दोनों के साथ काम करने वाले IOCTL के साथ सिंक करना ज़रूरी है. अगर यूज़रस्पेस या कर्नेल ड्राइवर में मौजूद IOCTL को अपडेट किया जाता है, तो SEPolicy IOCTL की सूची को भी अपडेट करना ज़रूरी है.

7. ARM ने IOCTL को 'प्रतिबंधित' / 'इंस्ट्रूमेंटेशन' के तौर पर कैटगरी में बांटा है. हालांकि, हम इनमें से कुछ का इस्तेमाल प्रोडक्शन के इस्तेमाल के उदाहरणों में करना चाहते हैं और/या कुछ को अस्वीकार करना चाहते हैं. OEM/SoC, अपने यूज़रस्पेस Mali लाइब्रेरी के कॉन्फ़िगरेशन के आधार पर, इस्तेमाल किए जाने वाले IOCTL को कैटगरी में बांटने का फ़ैसला खुद लेते हैं. इनके बारे में फ़ैसला लेने के लिए, ARM की सूची का इस्तेमाल किया जा सकता है. हालांकि, हर OEM/SoC के इस्तेमाल के उदाहरण अलग-अलग हो सकते हैं.

निजता

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

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

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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

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

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

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

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

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

1. डिवाइस को 25Q2 बीटा 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 के लिए इनबाउंड अनुरोध
प्रदान किया गया	काम करता है	काम करता है	काम करता है
अनुमति नहीं दी गई	विफल	काम करता है	विफल

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

गड़बड़ियां

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

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

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

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

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

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) को लोकल नेटवर्क के पते के तौर पर क्लासिफ़ाई किया जाता है.

ऐप्लिकेशन की ली गई फ़ोटो

当面向 SDK 36 或更高版本的应用在搭载 Android 16 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。