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

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

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

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

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

एज-टू-एज लेआउट की सुविधा बंद की जा रही है

Android 15 强制实行全屏显示，但您的应用可以通过将 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 和 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 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 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() अब हर ऐप्लिकेशन के लिए यूनीक होगा. इससे वर्शन स्ट्रिंग से पहचान करने वाली प्रॉपर्टी हट जाती हैं, ताकि फ़िंगरप्रिंटिंग तकनीकों के गलत इस्तेमाल को रोका जा सके. ऐप्लिकेशन को इस वर्शन के फ़ॉर्मैट के बारे में कोई अनुमान नहीं लगाना चाहिए. इस एपीआई का इस्तेमाल करते समय, ऐप्लिकेशन को पहले से ही वर्शन में होने वाले बदलावों को मैनेज करना चाहिए. ज़्यादातर मामलों में, उन्हें अपने मौजूदा व्यवहार में बदलाव करने की ज़रूरत नहीं पड़ती. हालांकि, ऐसा तब तक नहीं होगा, जब तक डेवलपर ने इस एपीआई के दायरे से बाहर की अतिरिक्त जानकारी का अनुमान लगाने की कोशिश नहीं की है.

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

सुरक्षित इंटेंट की सुविधा, सुरक्षा से जुड़ी एक पहल है. इसे कई चरणों में लागू किया जाता है. इसका मकसद, 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	आने वाले इंटेंट के लिए, सख्त मैचिंग लागू करता है
none	आने वाले इंटेंट के लिए, मैचिंग के सभी खास नियमों को बंद कर देता है. एक से ज़्यादा फ़्लैग तय करते समय, टकराव वाली वैल्यू को "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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。