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

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

Android 16 को टारगेट करने वाले ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची देखना न भूलें.

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

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

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

从 Android 16 开始，我们将根据以下因素调整常规作业和加急作业的执行运行时配额：

• 应用所处的应用待机存储分区：在 Android 16 中，活跃待机存储分区将开始通过宽松的运行时配额强制执行。
• 如果作业在应用处于前台状态时开始执行：在 Android 16 中，如果作业在应用对用户可见时开始执行，并在应用变为不可见后继续执行，则会遵守作业运行时配额。
• 如果作业在运行前台服务时执行：在 Android 16 中，与前台服务同时执行的作业将遵守作业运行时配额。如果您利用作业进行用户发起的数据传输，请考虑改用用户发起的数据传输作业。

此变更会影响使用 WorkManager、JobScheduler 和 DownloadManager 调度的任务。如需调试作业停止的原因，我们建议您通过调用 WorkInfo.getStopReason()（对于 JobScheduler 作业，请调用 JobParameters.getStopReason()）来记录作业停止的原因。

如需了解应用的状态如何影响其可使用的资源，请参阅电源管理资源限制。 如需详细了解电池优化方面的最佳实践，请参阅有关针对任务调度 API 优化电池使用的指南。

我们还建议利用 Android 16 中引入的新 JobScheduler#getPendingJobReasonsHistory API 来了解作业未执行的原因。

测试

如需测试应用的行为，只要应用在 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_ABANDONED，而不是 STOP_REASON_TIMEOUT。

如果新的作业被废弃停止原因频繁出现，系统会采取缓解措施来降低作业频率。

应用应使用新的停止原因来检测和减少被废弃的作业。

如果您使用的是 WorkManager、AsyncTask 或 DownloadManager，则不会受到影响，因为这些 API 会代表您的应用管理作业生命周期。

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 16 या उसके बाद के वर्शन वाले डिवाइस पर चल रहा है और Android को पता चलता है कि आपके ऐप्लिकेशन में 4 केबी के अलाइन किए गए मेमोरी पेज हैं, तो यह अपने-आप कंपैटबिलिटी मोड का इस्तेमाल करता है और उपयोगकर्ता को सूचना वाला डायलॉग बॉक्स दिखाता है. बैकवर्ड कम्पैटिबिलिटी मोड को चालू करने के लिए, AndroidManifest.xml में android:pageSizeCompat प्रॉपर्टी को सेट करने पर, ऐप्लिकेशन लॉन्च होने पर डायलॉग नहीं दिखेगा. android:pageSizeCompat प्रॉपर्टी का इस्तेमाल करने के लिए, Android 16 SDK का इस्तेमाल करके अपना ऐप्लिकेशन कंपाइल करें.

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

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

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

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

परेशान करने वाली सुलभता से जुड़ी सूचनाएँ पढ़कर सुनाने की सुविधा बंद की जा रही है

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 QPR 2 开始，Android 会自动将主题应用于应用图标，以打造一致的主屏幕体验。如果应用未提供自己的带主题的应用图标，就会发生这种情况。应用可以通过在自适应图标中添加单色图层来控制主题化应用图标的设计，并在 Android Studio 中预览应用图标的外观。

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

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

वर्चुअल डिवाइस के मालिक के लिए उपलब्ध सुविधाएं

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

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

हर ऐप्लिकेशन के हिसाब से ओवरराइड

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

नुकसान पहुंचाने वाले सामान्य बदलाव

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

संदर्भ

कंपैनियन ऐप्लिकेशन की स्ट्रीमिंग

सुरक्षा

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

इन्टेंट रीडायरेक्शन के हमलों से बचने के लिए बेहतर सुरक्षा

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

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

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

इंटेंट रीडायरेक्शन को हैंडल करने की सुविधा से ऑप्ट आउट करना

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

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

Android 16 (एपीआई लेवल 36) या इसके बाद के वर्शन के एसडीके के साथ कंपाइल किए जा रहे ऐप्लिकेशन के लिए

इंटेंट ऑब्जेक्ट पर, 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 के आने वाले वर्शन में, एपीआई में बदलाव किए जाएं. अगर मुमकिन हो, तो अपने कंपाइल एसडीके को Android 16 (एपीआई लेवल 36) या इसके बाद के वर्शन पर अपडेट करें, ताकि एपीआई का सीधे तौर पर इस्तेमाल किया जा सके.

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) }

कंपैनियन ऐप्लिकेशन को अब डिवाइस खोजने के लिए तय समयसीमा खत्म होने की सूचना नहीं दी जाएगी

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

डिवाइस खोजने की अवधि को भी 20 सेकंड से बढ़ाकर 30 सेकंड कर दिया गया है. साथ ही, उपयोगकर्ता डिवाइस खोजने की प्रोसेस को किसी भी समय रोक सकता है. अगर खोज शुरू करने के पहले 20 सेकंड में कम से कम एक डिवाइस मिल जाता है, तो सीडीएम अन्य डिवाइसों को खोजना बंद कर देता है.

कनेक्टिविटी

Android 16 (एपीआई लेवल 36) में, ब्लूटूथ स्टैक में ये बदलाव किए गए हैं, ताकि सहायक डिवाइसों से कनेक्टिविटी को बेहतर बनाया जा सके.

बॉन्ड के नुकसान को बेहतर तरीके से मैनेज करना

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

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