काम करने के तरीके में बदलाव: 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 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, elegantTextHeight TextView एट्रिब्यूट की वैल्यू डिफ़ॉल्ट रूप से true पर सेट होती है. इससे कॉम्पैक्ट फ़ॉन्ट को ऐसे फ़ॉन्ट से बदल दिया जाता है जिसे पढ़ना आसान होता है. elegantTextHeight एट्रिब्यूट को false पर सेट करके, इसे बदला जा सकता है.

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

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

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

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

Android 16 (एपीआई लेवल 36) में ये बदलाव शामिल हैं. इनसे Android सिस्टम की कई मुख्य क्षमताओं में बदलाव होता है या उन्हें बढ़ाया जाता है.

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

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

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

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

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

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

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

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

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

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

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

“更安全的 intent”功能是一项多阶段安全计划，旨在提升 Android 的 intent 解析机制的安全性。目标是在 intent 处理期间添加检查，并过滤不符合特定条件的 intent，从而保护应用免受恶意操作的侵害。

在 Android 15 中，该功能侧重于发送应用，现在在 Android 16 中，控制权转移到了接收应用，允许开发者使用其应用清单选择启用严格的 intent 解析。

我们正在实施两项关键变更：

1. 显式 intent 必须与目标组件的 intent 过滤器相匹配：如果 intent 显式定位到某个组件，则应与该组件的 intent 过滤器相匹配。

2. 没有操作的 intent 无法匹配任何 intent 过滤器：未指定操作的 intent 不应解析为任何 intent 过滤器。

这些变更仅在涉及多个应用时适用，不会影响单个应用内的 intent 处理。

影响

选择启用性质意味着，开发者必须在应用清单中明确启用它，才能使其生效。 因此，此功能的影响将仅限于以下应用（开发者）：

• 了解“更安全的 intent”功能及其优势。
• 主动选择在应用中采用更严格的 intent 处理实践。

这种选择性采用的方法可最大限度地降低破坏可能依赖于当前不太安全的 intent 解析行为的现有应用的风险。

虽然在 Android 16 中，初始影响可能有限，但“更安全的 intent”计划的路线图显示，未来 Android 版本中会产生更广泛的影响。我们计划最终将严格的 intent 解析设为默认行为。

“更安全的 intent”功能可让恶意应用更难利用 intent 解析机制中的漏洞，从而显著提升 Android 生态系统的安全性。

不过，向选择退出和强制执行的过渡必须谨慎管理，以解决现有应用的潜在兼容性问题。

实现

开发者需要在应用清单中使用 intentMatchingFlags 属性明确启用更严格的 intent 匹配。 以下示例展示了如何为整个应用选择启用该功能，但在接收器上停用/选择停用该功能：

<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	对传入的 intent 强制执行更严格的匹配
none	停用针对传入 intent 的所有特殊匹配规则。指定多个标志时，系统会优先考虑“无”标志，以解决值冲突问题
allowNullAction	放宽了匹配规则，允许匹配没有操作的 intent。此标志与“enforceIntentFilter”结合使用可实现特定行为

测试和调试

在强制执行处于有效状态时，如果 intent 调用方已正确填充 intent，应用应能正常运行。 不过，被屏蔽的 intent 会触发警告日志消息（例如 "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. क्या एसओसी, IOCTL की सूची को अप-टू-डेट रखने के लिए ज़िम्मेदार होते हैं? उदाहरण के लिए, अगर मेरे डिवाइस में 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 और TBD हैं. डेवलपर के लिए, 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 或更高版本的设备上提示用户授予照片和视频权限时，如果用户选择限制对所选媒体的访问权限，则会在照片选择器中看到该应用拥有的所有照片。用户可以取消选择任何这些预选项，这会撤消该应用对这些照片和视频的访问权限。