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

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

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

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

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

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() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 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 表面，在生产 build 中，已废弃或仅用于 GPU 开发的 Mali GPU IOCTL 已被屏蔽。此外，用于 GPU 性能分析的 IOCTL 已限制为 shell 进程或可调试的应用。如需详细了解平台级政策，请参阅 SAC 更新。

此更改适用于使用 Mali GPU 的 Pixel 设备（Pixel 6-9）。Arm 已在其 r54p2 版本的 Documentation/ioctl-categories.rst 中提供了 IOCTL 的官方分类。此列表将在未来的驱动程序版本中继续维护。

此项变更不会影响受支持的图形 API（包括 Vulkan 和 OpenGL），预计也不会影响开发者或现有应用。 Streamline Performance Analyzer 和 Android GPU 检查器等 GPU 性能剖析工具不会受到影响。

测试

如果您看到类似如下所示的 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，请提交 bug 并将其分配给 [e-mail]。

常见问题解答

1. 此政策变更是否适用于所有原始设备制造商 (OEM)？ 此变更将采用选择启用模式，但任何想要使用此强化方法的 OEM 都可以使用。如需了解如何实现此变更，请参阅实现文档。

2. 是否必须在 OEM 代码库中进行更改才能实现此功能，还是默认随新的 AOSP 版本提供？ 平台级变更将默认随新的 AOSP 版本一起发布。如果供应商想要应用此变更，可以在其代码库中选择启用此变更。

3. SoC 是否负责使 IOCTL 列表保持最新状态？例如，如果我的设备使用 ARM Mali GPU，我是否需要就任何更改与 ARM 联系？ 各个 SoC 必须在驱动程序发布后根据设备更新其 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 分类为“受限”/“检测”，但我们希望在生产用例中使用其中一些 IOCTL，并拒绝其他 IOCTL。 各个 OEM/SoC 负责根据其用户空间 Mali 库的配置来决定如何对其使用的 IOCTL 进行分类。ARM 的列表可用于帮助确定这些值，但每个 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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。