ऐप्लिकेशन के व्यवहार में बदलाव: सभी ऐप्लिकेशन

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

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

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

Android 16 में ये बदलाव किए गए हैं. इनसे Android सिस्टम की मुख्य सुविधाओं में बदलाव होता है या उन्हें बेहतर बनाया जाता है.

JobScheduler कोटा ऑप्टिमाइज़ेशन

Android 16 से, हम सामान्य और तेज़ी से होने वाली प्रोसेस के लिए, टास्क को पूरा करने में लगने वाले समय के कोटे में बदलाव कर रहे हैं. यह बदलाव इन बातों के आधार पर किया जा रहा है:

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

इस बदलाव का असर, WorkManager, JobScheduler, और DownloadManager का इस्तेमाल करके शेड्यूल किए गए टास्क पर पड़ेगा. किसी जॉब के रुकने की वजह जानने के लिए, हमारा सुझाव है कि आप WorkInfo.getStopReason() को कॉल करके, यह लॉग करें कि आपकी जॉब क्यों रुकी. JobScheduler जॉब के लिए, JobParameters.getStopReason() को कॉल करें.

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

हमारा सुझाव है कि किसी जॉब के लागू न होने की वजह जानने के लिए, Android 16 में जोड़े गए नए JobScheduler#getPendingJobReasonsHistory एपीआई का इस्तेमाल करें.

टेस्ट करना

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

"टॉप स्टेटस, जॉब के रनटाइम कोटा का पालन करेगा" को लागू करने की सुविधा बंद करने के लिए, यह adb निर्देश चलाएं:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_TOP_STARTED_JOBS APP_PACKAGE_NAME

"फ़ोरग्राउंड सेवा के साथ-साथ चल रही जॉब, जॉब के रनटाइम कोटे का पालन करेंगी" को लागू करने की सुविधा बंद करने के लिए, यह adb कमांड चलाएं:

adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS APP_PACKAGE_NAME

ऐप्लिकेशन की स्टैंडबाय बकेट के कुछ व्यवहार की जांच करने के लिए, यहां दिए गए adb कमांड का इस्तेमाल करके, अपने ऐप्लिकेशन की स्टैंडबाय बकेट सेट की जा सकती है:

adb shell am set-standby-bucket APP_PACKAGE_NAME active|working_set|frequent|rare|restricted

आपका ऐप्लिकेशन, ऐप्लिकेशन स्टैंडबाय बकेट में किस कैटगरी में आता है, यह जानने के लिए, adb कमांड का इस्तेमाल करके अपने ऐप्लिकेशन की ऐप्लिकेशन स्टैंडबाय बकेट देखी जा सकती है:

adb shell am get-standby-bucket APP_PACKAGE_NAME

खाली नौकरियों को बंद करने की वजह

जब जॉब से जुड़े JobParameters ऑब्जेक्ट को गै़रबैज इकट्ठा करने की प्रोसेस के तहत हटा दिया जाता है, लेकिन जॉब पूरा होने का सिग्नल देने के लिए JobService#jobFinished(JobParameters, boolean) को कॉल नहीं किया जाता है, तो जॉब को छोड़ दिया जाता है. इससे पता चलता है कि ऐप्लिकेशन के बिना, शायद जॉब चल रहा हो और उसे फिर से शेड्यूल किया जा रहा हो.

JobScheduler पर निर्भर ऐप्लिकेशन, JobParameters ऑब्जेक्ट का सटीक रेफ़रंस नहीं रखते. साथ ही, टाइम आउट होने पर अब STOP_REASON_TIMEOUT के बजाय, STOP_REASON_TIMEOUT_ABANDONED को नौकरी के रुकने की नई वजह के तौर पर इस्तेमाल किया जाएगा.

अगर 'नया काम बंद होने की वजह' बार-बार दिखती है, तो सिस्टम, जॉब की फ़्रीक्वेंसी कम करने के लिए कदम उठाएगा.

ऐप्लिकेशन को, 'कार्रवाई रोकने की नई वजह' का इस्तेमाल करके, अधूरे रह गए टास्क का पता लगाना चाहिए और उनकी संख्या कम करनी चाहिए.

अगर आपने WorkManager, AsyncTask या DownloadManager का इस्तेमाल किया है, तो आप पर इसका कोई असर नहीं पड़ेगा. ऐसा इसलिए, क्योंकि ये एपीआई आपके ऐप्लिकेशन की ओर से जॉब लाइफ़साइकल को मैनेज करते हैं.

JobInfo#setImportantWhileForeground को पूरी तरह बंद करना

JobInfo.Builder#setImportantWhileForeground(boolean) तरीका, शेड्यूलिंग ऐप्लिकेशन के फ़ोरग्राउंड में होने या बैकग्राउंड में काम करने से जुड़ी पाबंदियों से कुछ समय के लिए छूट मिलने पर, किसी टास्क की अहमियत दिखाता है.

Android 12 (एपीआई लेवल 31) के बाद, यह तरीका काम नहीं करता. Android 16 से, यह तरीका ठीक से काम नहीं करता. साथ ही, इस तरीके को कॉल करने पर, उसे अनदेखा कर दिया जाएगा.

यह सुविधा हटाने का फ़ैसला, JobInfo#isImportantWhileForeground() पर भी लागू होता है. Android 16 में, अगर इस तरीके को कॉल किया जाता है, तो यह false दिखाता है.

क्रम से चलने वाले ब्रॉडकास्ट की प्राथमिकता का दायरा अब ग्लोबल नहीं है

Android ऐप्लिकेशन, ब्रॉडकास्ट रिसीवर पर प्राथमिकताएं तय कर सकते हैं. इससे, यह कंट्रोल किया जा सकता है कि रिसीवर, ब्रॉडकास्ट को किस क्रम में पाएं और प्रोसेस करें. मेनिफ़ेस्ट में बताए गए रिसीवर के लिए, ऐप्लिकेशन प्राथमिकता तय करने के लिए android:priority एट्रिब्यूट का इस्तेमाल कर सकते हैं. वहीं, कॉन्टेक्स्ट के हिसाब से रजिस्टर किए गए रिसीवर के लिए, ऐप्लिकेशन प्राथमिकता तय करने के लिए IntentFilter#setPriority() एपीआई का इस्तेमाल कर सकते हैं. जब कोई ब्रॉडकास्ट भेजा जाता है, तो सिस्टम उसे पाने वालों को उनकी प्राथमिकता के हिसाब से डिलीवर करता है. इसमें, सबसे ज़्यादा प्राथमिकता वाले व्यक्ति से लेकर सबसे कम प्राथमिकता वाले व्यक्ति तक का क्रम होता है.

Android 16 में, अलग-अलग प्रोसेस में android:priority एट्रिब्यूट या IntentFilter#setPriority() का इस्तेमाल करके, ब्रॉडकास्ट डिलीवरी के क्रम की गारंटी नहीं दी जाएगी. ब्रॉडकास्ट की प्राथमिकताएं, सभी प्रोसेस के बजाय सिर्फ़ एक ही आवेदन की प्रोसेस में लागू होंगी.

साथ ही, ब्रॉडकास्ट की प्राथमिकताएं अपने-आप इस सीमा में सीमित हो जाएंगी (SYSTEM_LOW_PRIORITY + 1, SYSTEM_HIGH_PRIORITY - 1). सिर्फ़ सिस्टम कॉम्पोनेंट को SYSTEM_LOW_PRIORITY, SYSTEM_HIGH_PRIORITY को ब्रॉडकास्ट प्राथमिकता के तौर पर सेट करने की अनुमति होगी.

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

1. आपके ऐप्लिकेशन ने एक ही ब्रॉडकास्ट इंटेंट के साथ कई प्रोसेस का एलान किया है. साथ ही, प्राथमिकता के आधार पर उन इंटेंट को किसी खास क्रम में पाने की उम्मीद की है.
2. आपके ऐप्लिकेशन की प्रोसेस, अन्य प्रोसेस के साथ इंटरैक्ट करती है. साथ ही, यह किसी खास क्रम में ब्रॉडकास्ट इंटेंट पाने की उम्मीद करती है.

अगर प्रोसेस को एक-दूसरे के साथ काम करना है, तो उन्हें अन्य चैनलों का इस्तेमाल करके कम्यूनिकेट करना चाहिए.

एआरटी में हुए बदलाव

Android 16 में, Android Runtime (ART) के नए अपडेट शामिल हैं. इनसे Android Runtime (ART) की परफ़ॉर्मेंस बेहतर होती है और Java की अन्य सुविधाओं के साथ काम करने में मदद मिलती है. Google Play के सिस्टम अपडेट की मदद से, ये सुधार Android 12 (एपीआई लेवल 31) और उसके बाद के वर्शन वाले एक अरब से ज़्यादा डिवाइसों के लिए भी उपलब्ध हैं.

ये बदलाव रिलीज़ होने के बाद, हो सकता है कि ART के इंटरनल स्ट्रक्चर पर निर्भर रहने वाली लाइब्रेरी और ऐप्लिकेशन कोड, Android 16 वाले डिवाइसों पर सही से काम न करें. साथ ही, ऐसा उन Android वर्शन पर भी हो सकता है जो Google Play के सिस्टम अपडेट के ज़रिए ART मॉड्यूल को अपडेट करते हैं.

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

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

16 केबी पेज साइज़ कंपैटबिलिटी मोड

Android 15 में 16 केबी मेमोरी वाले पेजों के लिए सहायता जोड़ी गई है, ताकि प्लैटफ़ॉर्म की परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जा सके. Android 16 में कंपैटबिलिटी मोड जोड़ा गया है. इससे, 4 केबी मेमोरी वाले पेजों के लिए बनाए गए कुछ ऐप्लिकेशन, 16 केबी मेमोरी वाले पेजों के लिए कॉन्फ़िगर किए गए डिवाइस पर चल सकते हैं.

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

कंपैटबिलिटी मोड का डायलॉग बॉक्स, जो तब दिखता है, जब सिस्टम को पता चलता है कि 4 केबी वाले ऐप्लिकेशन को 16 केबी वाले ऐप्लिकेशन के तौर पर अलाइन करने पर, वह बेहतर तरीके से काम कर सकता है.

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

Android 16 में ये बदलाव किए गए हैं, ताकि उपयोगकर्ता को एक जैसा और बेहतर अनुभव मिल सके.

सुलभता से जुड़ी परेशान करने वाली सूचनाओं को बंद करना

Android 16 में, सुलभता से जुड़ी सूचनाओं का इस्तेमाल नहीं किया जा सकता. इन सूचनाओं के लिए, announceForAccessibility का इस्तेमाल किया जाता है या TYPE_ANNOUNCEMENT सुलभता इवेंट भेजे जाते हैं. इनकी वजह से, TalkBack और Android के स्क्रीन रीडर का इस्तेमाल करने वाले लोगों को अलग-अलग अनुभव मिल सकते हैं. साथ ही, Android की सहायक तकनीकों की मदद से, लोगों की ज़्यादा से ज़्यादा ज़रूरतों को पूरा करने के लिए, इन विकल्पों का इस्तेमाल किया जा सकता है.

विकल्पों के उदाहरण:

• विंडो में बदलाव जैसे यूज़र इंटरफ़ेस (यूआई) में होने वाले अहम बदलावों के लिए, Activity.setTitle(CharSequence) और setAccessibilityPaneTitle(java.lang.CharSequence) का इस्तेमाल करें. लिखने के लिए इस्तेमाल होने वाले टूल में, Modifier.semantics { paneTitle = "paneTitle" } का इस्तेमाल करें
• ज़रूरी यूज़र इंटरफ़ेस (यूआई) में हुए बदलावों के बारे में उपयोगकर्ता को बताने के लिए, setAccessibilityLiveRegion(int) का इस्तेमाल करें. लिखें में, Modifier.semantics { liveRegion = LiveRegionMode.[Polite|Assertive]} का इस्तेमाल करें . इनका इस्तेमाल कम से कम करना चाहिए, क्योंकि हर बार व्यू अपडेट होने पर ये सूचनाएं जनरेट कर सकते हैं.
• उपयोगकर्ताओं को गड़बड़ियों के बारे में सूचना देने के लिए, टाइप के AccessibilityEvent को भेजें AccessibilityEvent#CONTENT_CHANGE_TYPE_ERROR और AccessibilityNodeInfo#setError(CharSequence) सेट करें या TextView#setError(CharSequence) का इस्तेमाल करें.

बंद किए गए announceForAccessibility एपीआई के रेफ़रंस दस्तावेज़ में, सुझाए गए विकल्पों के बारे में ज़्यादा जानकारी शामिल है.

तीन बटन वाले नेविगेशन के लिए सहायता

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

यह सुविधा, सिस्टम के उन सभी हिस्सों पर लागू होती है जिनमें प्रिडिक्टिव बैक ऐनिमेशन काम करते हैं. इनमें सिस्टम ऐनिमेशन (होम स्क्रीन पर वापस जाने, एक टास्क से दूसरे टास्क पर जाने, और एक गतिविधि से दूसरी गतिविधि पर जाने) भी शामिल हैं.

तीन बटन वाले नेविगेशन मोड में, प्रिडिक्टिव बैक ऐनिमेशन.

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

Android 16 में, डिसप्ले पर प्रोजेक्ट किए जाने पर ऐप्लिकेशन के लिए ये बदलाव किए गए हैं.

वर्चुअल डिवाइस के मालिक की ओर से बदलाव

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

वर्चुअल डिवाइस का मालिक, फ़ोन पर वर्चुअल डिवाइस बनाता है. यह डिवाइस, ऐप्लिकेशन को रिमोट डिसप्ले पर प्रोजेक्ट करता है.

हर ऐप्लिकेशन के लिए अलग से सेट की गई समयसीमा

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

आम तौर पर होने वाले बदलाव

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

रेफ़रंस

साथ-साथ चलने वाले ऐप्लिकेशन की स्ट्रीमिंग

सुरक्षा

Android 16 में ऐसे बदलाव किए गए हैं जिनसे सिस्टम की सुरक्षा को बेहतर बनाया गया है. इससे ऐप्लिकेशन और उपयोगकर्ताओं को नुकसान पहुंचाने वाले ऐप्लिकेशन से बचाने में मदद मिलती है.

इंटेंट रीडायरेक्टेशन अटैक से सुरक्षा को बेहतर बनाया गया

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

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

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

इंटेंट रीडायरेक्शन मैनेजमेंट से ऑप्ट आउट करना

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

अहम जानकारी: सुरक्षा से जुड़ी सुविधाओं से ऑप्ट आउट करने के लिए, सावधानी बरतें. ऐसा सिर्फ़ ज़रूरत पड़ने पर करें, क्योंकि इससे सुरक्षा से जुड़ी समस्याओं का खतरा बढ़ सकता है. इस एपीआई का इस्तेमाल करने से पहले, अपने ऐप्लिकेशन की सुरक्षा पर पड़ने वाले संभावित असर का ध्यान से आकलन करें.

Android 16 SDK या इसके बाद के वर्शन के लिए कॉम्पाइल किए जा रहे ऐप्लिकेशन के लिए

Intent ऑब्जेक्ट पर सीधे removeLaunchSecurityProtection() तरीके का इस्तेमाल किया जा सकता है.

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent")
iSublevel?.removeLaunchSecurityProtection() // Opt out from hardening
iSublevel?.let { startActivity(it) }

Android 15 (एपीआई लेवल 35) या इससे पहले के वर्शन के लिए कॉम्पाइल किए जा रहे ऐप्लिकेशन के लिए

हमारा सुझाव है कि आप removeLaunchSecurityProtection() तरीके को ऐक्सेस करने के लिए, रिफ़्लेक्शन का इस्तेमाल न करें.

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

val i = intent
val iSublevel: Intent? = i.getParcelableExtra("sub_intent", Intent::class.java)
try {
    val removeLaunchSecurityProtection = Intent::class.java.getDeclaredMethod("removeLaunchSecurityProtection")
    removeLaunchSecurityProtection.invoke(iSublevel)
} catch (e: Exception) {
    // Handle the exception, e.g., log it
} // Opt-out from the security hardening using reflection
iSublevel?.let { startActivity(it) }