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

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

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

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

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

बिना बॉर्डर की फ़ुल साइज़ फ़ोटो दिखाने की सुविधा बंद की जा रही है

Android 15 enforced edge-to-edge for apps targeting Android 15 (API level 35), but your app could opt-out by setting R.attr#windowOptOutEdgeToEdgeEnforcement to true. For apps targeting Android 16 (API level 36), R.attr#windowOptOutEdgeToEdgeEnforcement is deprecated and disabled, and your app can't opt-out of going edge-to-edge.

• If your app targets Android 16 (API level 36) and is running on an Android 15 device, R.attr#windowOptOutEdgeToEdgeEnforcement continues to work.
• If your app targets Android 16 (API level 36) and is running on an Android 16 device, R.attr#windowOptOutEdgeToEdgeEnforcement is disabled.

For testing in Android 16, ensure your app supports edge-to-edge and remove any use of R.attr#windowOptOutEdgeToEdgeEnforcement so that your app also supports edge-to-edge on an Android 15 device. To support edge-to-edge, see the Compose and Views guidance.

पीछे जाने के जेस्चर की सुविधा के लिए, माइग्रेट करना या ऑप्ट-आउट करना ज़रूरी है

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

अगर आपका ऐप्लिकेशन, 'वापस जाएं' इवेंट को इंटरसेप्ट करता है और आपने अब तक अनुमानित 'वापस जाएं' सुविधा पर माइग्रेट नहीं किया है, तो वापस जाने के लिए इस्तेमाल किए जाने वाले एपीआई का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन को अपडेट करें. इसके अलावा, AndroidManifest.xml फ़ाइल के <application> या <activity> टैग में android:enableOnBackInvokedCallback एट्रिब्यूट को false पर सेट करके, इस सुविधा से कुछ समय के लिए ऑप्ट आउट करें.

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

Apps targeting Android 15 (API level 35) have the elegantTextHeight TextView attribute set to true by default, replacing the compact font with one that is much more readable. You could override this by setting the elegantTextHeight attribute to false.

Android 16 deprecates the elegantTextHeight attribute, and the attribute will be ignored once your app targets Android 16. The "UI fonts" controlled by these APIs are being discontinued, so you should adapt any layouts to ensure consistent and future proof text rendering in Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai.

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

Android 16 (एपीआई लेवल 36) में ये बदलाव किए गए हैं. इनसे Android सिस्टम की अलग-अलग मुख्य क्षमताओं में बदलाव होता है या वे बेहतर होती हैं.

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

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

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

सुरक्षा

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

MediaStore के वर्शन को लॉक करना

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

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

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>

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

टेस्टिंग और डीबग करना

नीति उल्लंघन ठीक करने के लिए लागू की गई कार्रवाई के चालू होने पर, ऐप्लिकेशन ठीक से काम करने चाहिए. ऐसा तब होगा, जब इंटेंट कॉलर ने इंटेंट को सही तरीके से भरा हो. हालांकि, ब्लॉक किए गए इंटेंट, चेतावनी वाले लॉग मैसेज ट्रिगर करेंगे. जैसे, "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 का इस्तेमाल करना है, तो कृपया गड़बड़ी की शिकायत करें और उसे [email protected] को असाइन करें.

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

1. क्या नीति में किया गया यह बदलाव, सभी OEM पर लागू होता है? यह बदलाव ऑप्ट-इन होगा. हालांकि, यह उन सभी OEM के लिए उपलब्ध होगा जो सुरक्षा बढ़ाने के इस तरीके का इस्तेमाल करना चाहते हैं. बदलाव को लागू करने के निर्देश, लागू करने से जुड़े दस्तावेज़ में देखे जा सकते हैं.

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

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

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

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

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

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

निजता

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

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

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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

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

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

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

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

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

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

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

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

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

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

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

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) को लोकल नेटवर्क के पते के तौर पर क्लासिफ़ाई किया जाता है.

ऐप्लिकेशन की ली गई फ़ोटो

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