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

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

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

An abandoned job occurs when the JobParameters object associated with the job has been garbage collected, but JobService#jobFinished(JobParameters, boolean) has not been called to signal job completion. This indicates that the job may be running and being rescheduled without the app's awareness.

Apps that rely on JobScheduler, don't maintain a strong reference to the JobParameters object, and timeout will now be granted the new job stop reason STOP_REASON_TIMEOUT_ABANDONED, instead of STOP_REASON_TIMEOUT.

If there are frequent occurrences of the new abandoned stop reason, the system will take mitigation steps to reduce job frequency.

Apps should use the new stop reason to detect and reduce abandoned jobs.

If you're using WorkManager, AsyncTask, or DownloadManager, you aren't impacted because these APIs manage the job lifecycle on your app's behalf.

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 includes the latest updates to the Android Runtime (ART) that improve the Android Runtime's (ART's) performance and provide support for additional Java features. Through Google Play System updates, these improvements are also available to over a billion devices running Android 12 (API level 31) and higher.

As these changes are released, libraries and app code that rely on internal structures of ART might not work correctly on devices running Android 16, along with earlier Android versions that update the ART module through Google Play system updates.

Relying on internal structures (such as non-SDK interfaces) can always lead to compatibility problems, but it's particularly important to avoid relying on code (or libraries containing code) that leverages internal ART structures, since ART changes aren't tied to the platform version the device is running on and they go out to over a billion devices through Google Play system updates.

All developers should check whether their app is impacted by testing their apps thoroughly on Android 16. In addition, check the known issues to see if your app depends on any libraries that we've identified that rely on internal ART structures. If you do have app code or library dependencies that are affected, seek public API alternatives whenever possible and request public APIs for new use cases by creating a feature request in our issue tracker.

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 की सहायक तकनीकों की मदद से, लोगों की ज़्यादा से ज़्यादा ज़रूरतों को पूरा करने के लिए, इन विकल्पों का इस्तेमाल किया जा सकता है.

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

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

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

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

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

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

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

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

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

虚拟设备所有者是创建和管理虚拟设备的可信或特权应用。虚拟设备所有者可以在虚拟设备上运行应用,然后将应用投影到远程设备(例如个人计算机、虚拟现实设备或汽车信息娱乐系统)的显示屏上。虚拟设备所有者位于本地设备(例如手机)上。

手机上的虚拟设备所有者创建虚拟设备,将应用投影到远程显示屏。

按应用替换项

在搭载 Android 16(API 级别 36)的设备上,虚拟设备所有者可以在虚拟设备所有者管理的部分虚拟设备上替换应用设置。例如,为了改进应用布局,虚拟设备所有者可以在将应用投影到外部显示屏时忽略屏幕方向、宽高比和可调整大小限制。

常见的破坏性更改

Android 16 中的此行为可能会影响应用在汽车显示屏或 Chromebook 等大屏幕设备上的界面,尤其是针对纵向小屏幕设计的布局。如需了解如何让应用适应所有设备类型,请参阅自适应布局简介

参考文档

配套应用串流

सुरक्षा

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

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

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

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

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

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

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

Android 16 (एपीआई लेवल 36) 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() तरीके को ऐक्सेस करने के लिए, रिफ़्लेक्शन का इस्तेमाल न करें.

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