काम करने के तरीके में बदलाव: 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 और व्यू से जुड़े दिशा-निर्देश देखें.

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

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

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

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

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

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

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

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

• Wear OS पर स्वास्थ्य सेवाओं से HEART_RATE_BPM
• Sensor.TYPE_HEART_RATE, Android सेंसर मैनेजर से
• ProtoLayout से Wear OS पर heartRateAccuracy और heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH जहां BODY_SENSORS के बजाय, android.permission.health अनुमति की ज़रूरत होती है

अगर आपका ऐप्लिकेशन इन एपीआई का इस्तेमाल करता है, तो उसे अलग-अलग अनुमतियों का अनुरोध करना चाहिए:

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

सुरक्षा

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

MediaStore वर्शन लॉकडाउन

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

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

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

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

दो मुख्य बदलाव लागू किए जा रहे हैं:

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

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

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

असर

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

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

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

हालांकि, Android 16 में इसका असर सीमित हो सकता है, लेकिन Safer Intents पहल का रोडमैप, आने वाले Android रिलीज़ में ज़्यादा असर डालने के लिए तैयार किया गया है. हमारा मकसद, इंटेंट रिज़ॉल्यूशन की सख्त नीति को डिफ़ॉल्ट तौर पर लागू करना है.

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

हालांकि, ऑप्ट-आउट करने और नीति उल्लंघन ठीक करने के तरीके को लागू करने की प्रोसेस को सावधानी से मैनेज करना ज़रूरी है. इससे मौजूदा ऐप्लिकेशन के साथ काम करने से जुड़ी संभावित समस्याओं को हल किया जा सकता है.

लागू करना

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

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

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

जांच और डीबग करना

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

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

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

जांच करना

अगर आपको SELinux से जुड़ी गड़बड़ी का ऐसा मैसेज दिखता है जो यहां दिए गए मैसेज से मिलता-जुलता है, तो हो सकता है कि इस बदलाव का असर आपके ऐप्लिकेशन पर पड़ा हो:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

अगर आपके ऐप्लिकेशन को ब्लॉक किए गए IOCTL का इस्तेमाल करना है, तो कृपया गड़बड़ी की शिकायत करें और उसे android-partner-security@google.com पर असाइन करें.

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

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

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

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

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

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

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

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

निजता

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

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

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

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

रिलीज़ प्लान

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

असर

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

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

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

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

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

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

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 // 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), दोनों को लोकल नेटवर्क पतों के तौर पर बांटा गया है.

ऐप्लिकेशन के मालिकाना हक वाली फ़ोटो

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