काम करने के तरीके में बदलाव: 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 पर सेट करके, इस सुविधा से कुछ समय के लिए ऑप्ट आउट करें.

प्रिडिक्टिव बैक-टू-होम ऐनिमेशन.

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

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

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 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 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
• 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（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 版本中以 API 级别 37 为目标平台时，此选择停用将不再适用。也就是说，对于以 API 级别 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 या त्वचा के तापमान की निगरानी करने के लिए: BODY_SENSORS के बजाय, android.permissions.health में जाकर 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 还引入了 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 को शेल प्रोसेस या डीबग किए जा सकने वाले ऐप्लिकेशन के लिए सीमित कर दिया गया है. प्लैटफ़ॉर्म लेवल की नीति के बारे में ज़्यादा जानने के लिए, SAC से जुड़ा अपडेट देखें.

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

इस बदलाव से, ग्राफ़िक्स एपीआई (इनमें Vulkan और OpenGL शामिल हैं) पर कोई असर नहीं पड़ेगा. साथ ही, इससे डेवलपर या मौजूदा ऐप्लिकेशन पर भी कोई असर नहीं पड़ेगा. जीपीयू की परफ़ॉर्मेंस की जांच करने वाले टूल, जैसे कि 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. क्या नीति में किया गया यह बदलाव सभी ओईएम पर लागू होता है? यह बदलाव ऑप्ट-इन होगा. हालांकि, यह उन सभी ओईएम के लिए उपलब्ध होगा जो इस सुरक्षा बढ़ाने वाले तरीके का इस्तेमाल करना चाहते हैं. बदलाव को लागू करने के निर्देश, लागू करने से जुड़े दस्तावेज़ में दिए गए हैं.

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

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

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

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

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

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

निजता

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

लोकल नेटवर्क का ऐक्सेस देने की अनुमति

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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

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

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

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

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

गड़बड़ियां

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

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

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

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

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

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

IPv4:

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