Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

काम करने के तरीके में बदलाव: 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（API 级别 36）或更高版本为目标平台且在 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

“返回主页”预测性返回动画。

预测性跨 activity 动画。

预测性跨任务动画。

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

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（API 级别 36）为目标平台的应用，在最小宽度 >= 600dp 的显示屏上，屏幕方向、尺寸调整能力和宽高比限制不再适用。应用会填满整个显示窗口，无论宽高比或用户偏好的屏幕方向如何，都不会使用竖屏黑边模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素：例如，布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留用户状态，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 API 会被大屏设备忽略：

系统会忽略 screenOrientation、setRequestedOrientation() 和 getRequestedOrientation() 的以下值：

portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape

对于显示屏可调整大小性，android:resizeableActivity="false"、android:minAspectRatio 和 android:maxAspectRatio 没有影响。

对于以 Android 16（API 级别 36）为目标平台的应用，默认情况下，大屏设备会忽略应用的屏幕方向、尺寸调整和宽高比限制。尚未完全准备就绪的每个应用都可以通过选择停用来暂时替换此行为，这会导致应用恢复到之前放置在兼容模式下的行为。

例外情况

在以下情况下，Android 16 的屏幕方向、尺寸调整能力和宽高比限制不适用：

游戏（基于 android:appCategory 标志）
用户在设备的宽高比设置中明确选择启用应用的默认行为
小于 sw600dp 的屏幕

暂时选择不接收

如需选择停用特定 activity，请声明 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 भी इनका इस्तेमाल करता है. 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 में जाकर, ज़्यादा जानकारी वाली अनुमति का अनुरोध करें. जैसे, READ_HEART_RATE के बजाय BODY_SENSORS.
बैकग्राउंड में सेंसर ऐक्सेस करने के लिए: 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 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

सुरक्षा

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

MediaStore के वर्शन को लॉक करने की सुविधा

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

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

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

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

दो अहम बदलाव लागू किए जा रहे हैं:

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

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

असर

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

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

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

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>

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

फ़्लैग का नाम	ब्यौरा
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 का इस्तेमाल करना है, तो कृपया गड़बड़ी की शिकायत करें और उसे android-partner-security@google.com को असाइन करें.

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

क्या नीति में किया गया यह बदलाव, सभी OEM पर लागू होता है? यह बदलाव ऑप्ट-इन होगा. हालांकि, यह उन सभी OEM के लिए उपलब्ध होगा जो सुरक्षा बढ़ाने के इस तरीके का इस्तेमाल करना चाहते हैं. बदलाव को लागू करने के निर्देश, लागू करने से जुड़े दस्तावेज़ में देखे जा सकते हैं.
क्या इसे लागू करने के लिए, OEM को अपने कोडबेस में बदलाव करना ज़रूरी है या यह डिफ़ॉल्ट रूप से, AOSP के नए वर्शन के साथ उपलब्ध होता है? प्लेटफ़ॉर्म-लेवल का यह बदलाव, डिफ़ॉल्ट रूप से AOSP के नए वर्शन के साथ उपलब्ध होगा. अगर वेंडर इस बदलाव को लागू करना चाहते हैं, तो वे अपने कोडबेस में इसके लिए ऑप्ट-इन कर सकते हैं.
क्या IOCTL की सूची को अप-टू-डेट रखने की ज़िम्मेदारी SoC की है? उदाहरण के लिए, अगर मेरे डिवाइस में ARM Mali GPU का इस्तेमाल किया जाता है, तो क्या मुझे किसी भी बदलाव के लिए ARM से संपर्क करना होगा? ड्राइवर रिलीज़ होने के बाद, हर SoC को डिवाइस के हिसाब से अपने IOCTL की सूची अपडेट करनी होगी. उदाहरण के लिए, ड्राइवर के अपडेट होने पर, ARM पब्लिश की गई अपनी IOCTL की सूची को अपडेट करेगा. हालांकि, OEM को यह पक्का करना चाहिए कि वे अपने SEPolicy में अपडेट शामिल करें. साथ ही, ज़रूरत के हिसाब से चुनिंदा कस्टम IOCTL को सूचियों में जोड़ें.
क्या यह बदलाव, बाज़ार में मौजूद सभी Pixel डिवाइसों पर अपने-आप लागू हो जाता है या इसे लागू करने के लिए, उपयोगकर्ता को कोई कार्रवाई करनी पड़ती है? यह बदलाव, बाज़ार में मौजूद Mali GPU (Pixel 6-9) का इस्तेमाल करने वाले सभी Pixel डिवाइसों पर लागू होता है. इस बदलाव को लागू करने के लिए, उपयोगकर्ता को कोई कार्रवाई नहीं करनी पड़ती.
क्या इस नीति के इस्तेमाल से, कर्नेल ड्राइवर की परफ़ॉर्मेंस पर असर पड़ेगा? इस नीति को GFXBench का इस्तेमाल करके, Mali GPU पर टेस्ट किया गया. इस दौरान, GPU की परफ़ॉर्मेंस में कोई बदलाव नहीं दिखा.
क्या IOCTL की सूची का, मौजूदा यूज़रस्पेस और कर्नेल ड्राइवर के वर्शन के साथ अलाइन होना ज़रूरी है? हां, अनुमति वाले IOCTL की सूची को, यूज़रस्पेस और कर्नेल ड्राइवर, दोनों के साथ काम करने वाले IOCTL के साथ सिंक करना ज़रूरी है. अगर यूज़रस्पेस या कर्नेल ड्राइवर में मौजूद IOCTL को अपडेट किया जाता है, तो SEPolicy IOCTL की सूची को भी अपडेट करना ज़रूरी है.
ARM ने IOCTL को 'प्रतिबंधित' / 'इंस्ट्रूमेंटेशन' के तौर पर कैटगरी में बांटा है. हालांकि, हम इनमें से कुछ का इस्तेमाल प्रोडक्शन के इस्तेमाल के उदाहरणों में करना चाहते हैं और/या कुछ को अस्वीकार करना चाहते हैं. OEM/SoC, अपने यूज़रस्पेस Mali लाइब्रेरी के कॉन्फ़िगरेशन के आधार पर, इस्तेमाल किए जाने वाले IOCTL को कैटगरी में बांटने का फ़ैसला खुद लेते हैं. इनके बारे में फ़ैसला लेने के लिए, ARM की सूची का इस्तेमाल किया जा सकता है. हालांकि, हर OEM/SoC के इस्तेमाल के उदाहरण अलग-अलग हो सकते हैं.

निजता

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

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

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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

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

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

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

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

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

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

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

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

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

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

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

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

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

अनुमति	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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。