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

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

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

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

सटीक समय वाले अलार्म शेड्यूल करने की अनुमति डिफ़ॉल्ट रूप से नहीं दी जाती

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

ठीक समय पर अलार्म शेड्यूल करने की अनुमति में हुए बदलावों के बारे में ज़्यादा जानें.

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

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

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

ऐप्लिकेशन, सिर्फ़ अपनी बैकग्राउंड प्रोसेस बंद कर सकते हैं

Starting in Android 14, when your app calls killBackgroundProcesses(), the API can kill only the background processes of your own app.

If you pass in the package name of another app, this method has no effect on that app's background processes, and the following message appears in Logcat:

Invalid packageName: com.example.anotherapp

Your app shouldn't use the killBackgroundProcesses() API or otherwise attempt to influence the process lifecycle of other apps, even on older OS versions. Android is designed to keep cached apps in the background and kill them automatically when the system needs memory. If your app kills other apps unnecessarily, it can reduce system performance and increase battery consumption by requiring full restarts of those apps later, which takes significantly more resources than resuming an existing cached app.

MTU का अनुरोध करने वाले पहले GATT क्लाइंट के लिए, MTU को 517 पर सेट किया जाता है

Android 14 से, Android ब्लूटूथ स्टैक ब्लूटूथ कोर स्पेसिफ़िकेशन के वर्शन 5.2 का ज़्यादा सख्ती से पालन करता है. साथ ही, जब पहला GATT क्लाइंट BluetoothGatt#requestMtu(int) एपीआई का इस्तेमाल करके एमटीयू का अनुरोध करता है, तो BLE ATT एमटीयू को 517 बाइट तक का अनुरोध करता है. साथ ही, उस एसीएल कनेक्शन पर एमटीयू के सभी अनुरोधों को अनदेखा करता है.

इस बदलाव को ठीक करने और अपने ऐप्लिकेशन को ज़्यादा बेहतर बनाने के लिए, इन विकल्पों पर विचार करें:

• आपका पेरिफ़रल डिवाइस, Android डिवाइस के एमटीयू अनुरोध का जवाब, ऐसी सही वैल्यू के साथ देना चाहिए जिसे पेरिफ़रल डिवाइस इस्तेमाल कर सके. बातचीत के बाद तय की गई आखिरी वैल्यू, Android के अनुरोध की गई वैल्यू और रिमोट की दी गई वैल्यू (उदाहरण के लिए, min(517, remoteMtu)) में से कम से कम वैल्यू होगी
  • इस समस्या को ठीक करने के लिए, सहायक डिवाइस के फ़र्मवेयर को अपडेट करना पड़ सकता है
• इसके अलावा, अपने GATT विशेषता के डेटा को लिखने की सीमा तय करें. यह सीमा, आपके डिवाइस के लिए काम करने वाली वैल्यू और एमटीयू में हुए बदलाव के बीच की कम से कम वैल्यू के आधार पर तय की जा सकती है
  • आपको हेडर के लिए, इस्तेमाल किए जा सकने वाले साइज़ से 5 बाइट कम करने चाहिए
  • उदाहरण के लिए: arrayMaxLength = min(SUPPORTED_MTU, GATT_MAX_ATTR_LEN(517)) - 5

ऐप्लिकेशन को प्रतिबंधित स्टैंडबाय बकेट में रखने की नई वजह

Android 14 में, प्रतिबंधित स्टैंडबाय बकेट में ऐप्लिकेशन को डालने की एक नई वजह जोड़ी गई है. ऐप्लिकेशन के जॉब, onStartJob, onStopJob या onBind तरीके के टाइम आउट की वजह से, कई बार ANR गड़बड़ियां ट्रिगर करते हैं. onStartJob और onStopJob में बदलावों के लिए, JobScheduler, कॉलबैक और नेटवर्क के व्यवहार को बेहतर बनाता है देखें.

यह ट्रैक करने के लिए कि ऐप्लिकेशन, पाबंदी वाली स्टैंडबाय बकेट में शामिल है या नहीं, हमारा सुझाव है कि आप जॉब के लागू होने पर UsageStatsManager.getAppStandbyBucket() या ऐप्लिकेशन के शुरू होने पर UsageStatsManager.queryEventsForSelf() एपीआई के साथ लॉग करें.

mlock का इस्तेमाल 64 केबी तक ही किया जा सकता है

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

सिस्टम, कैश मेमोरी में सेव किए गए ऐप्लिकेशन के लिए संसाधनों के इस्तेमाल को लागू करता है

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

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

फ़्रेमवर्क के साथ काम करने वाले लाइफ़साइकल एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन पर, इन बदलावों का कोई असर नहीं पड़ेगा. जैसे, services, JobScheduler, और Jetpack WorkManager.

उपयोगकर्ता अनुभव

सूचनाओं को खारिज न कर पाने की सुविधा का इस्तेमाल करने वाले लोगों के अनुभव में बदलाव

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

यह बदलाव उन ऐप्लिकेशन पर लागू होता है जो उपयोगकर्ताओं को फ़ोरग्राउंड खारिज करने से रोकते हैं Notification.FLAG_ONGOING_EVENT को इसके ज़रिए सेट करने पर मिलने वाली सूचनाएँ Notification.Builder#setOngoing(true) या NotificationCompat.Builder#setOngoing(true). इसका व्यवहार इस तरह की सूचनाओं को असल में दिखाने के लिए, FLAG_ONGOING_EVENT को बदल दिया गया है जिसे उपयोगकर्ता खारिज कर सकता है.

नीचे दी गई स्थितियों में, इस तरह की सूचनाएं अब भी खारिज नहीं की जा सकतीं शर्तें:

• फ़ोन लॉक होने पर
• अगर उपयोगकर्ता, सूचना से जुड़ी सभी हटाएं कार्रवाई चुनता है (इससे गलती से खारिज हो जाना)

साथ ही, यह नई कार्रवाई इस्तेमाल के ये उदाहरण:

• CallStyle सूचनाएं
• एंटरप्राइज़ के लिए डिवाइस नीति नियंत्रक (डीपीसी) और सहायक पैकेज
• मीडिया से जुड़ी सूचनाएं
• डिफ़ॉल्ट खोज सिलेक्टर पैकेज

डेटा की सुरक्षा से जुड़ी जानकारी ज़्यादा आसानी से दिखती है

उपयोगकर्ता की निजता को बेहतर बनाने के लिए, Android 14 में उन जगहों की संख्या बढ़ाई गई है जहां सिस्टम, Play Console फ़ॉर्म में दी गई जानकारी दिखाता है. फ़िलहाल, उपयोगकर्ताओं को यह जानकारी Google Play में आपके ऐप्लिकेशन के स्टोर पेज पर, डेटा की सुरक्षा सेक्शन में दिख सकती है.

हमारा सुझाव है कि आप अपने ऐप्लिकेशन के लिए, जगह की जानकारी के डेटा को शेयर करने से जुड़ी नीतियों की समीक्षा करें. साथ ही, कुछ समय निकालकर अपने ऐप्लिकेशन के Google Play के डेटा की सुरक्षा वाले सेक्शन में, लागू होने वाले अपडेट करें.

Android 14 पर, डेटा की सुरक्षा से जुड़ी जानकारी ज़्यादा बेहतर तरीके से कैसे दिखती है, इस बारे में गाइड में ज़्यादा जानें.

सुलभता

फ़ॉन्ट को 200% तक नॉन-लीनियर तरीके से बड़ा करना

Android 14 से, सिस्टम में फ़ॉन्ट को 200% तक बड़ा किया जा सकता है. इससे उपयोगकर्ताओं को सुलभता से जुड़ी अतिरिक्त सुविधाएं मिलती हैं.

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

सुरक्षा

इंस्टॉल किए जा सकने वाले टारगेट एपीआई लेवल की ज़रूरी शर्तें

Android 14 और इसके बाद के वर्शन में, targetSdkVersion 23 से कम इंस्टॉल नहीं किया जा सकता. ऐप्लिकेशन को टारगेट एपीआई लेवल के इन कम से कम लेवल को पूरा करने के लिए ज़रूरी करना की शर्तों से, लोगों के लिए सुरक्षा और निजता को बेहतर बनाने में मदद मिलती है.

मैलवेयर, सुरक्षा और निजता को बायपास करने के लिए, अक्सर पुराने एपीआई लेवल को टारगेट करता है जो Android के नए वर्शन में उपलब्ध कराए गए हैं. उदाहरण के लिए, कुछ मैलवेयर ऐप्लिकेशनtargetSdkVersion रनटाइम अनुमति मॉडल को 2015 में Android 6.0 Marshmallow (एपीआई) ने लॉन्च किया था लेवल 23). Android 14 में किए गए इस बदलाव की वजह से, मैलवेयर से सुरक्षा को रोकना मुश्किल हो गया है और निजता में सुधार किए गए हैं. कम एपीआई लेवल को टारगेट करने वाले किसी ऐप्लिकेशन को इंस्टॉल करने की कोशिश करने पर, इंस्टॉल नहीं हो सका, और Logcat में यह मैसेज दिखता है:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7

Android 14 में अपग्रेड किए जा रहे डिवाइसों पर, targetSdkVersion से कम कीमत वाले ऐप्लिकेशन से 23 इंस्टॉल रहेंगे.

अगर आपको किसी पुराने एपीआई लेवल को टारगेट करने वाले ऐप्लिकेशन की जांच करनी है, तो ADB के इस कमांड का इस्तेमाल करें:

adb install --bypass-low-target-sdk-block FILENAME.apk

मीडिया फ़ाइलों के ओनर के पैकेज के नाम छिपाए जा सकते हैं

मीडिया स्टोर में, OWNER_PACKAGE_NAME कॉलम के लिए क्वेरी की सुविधा उपलब्ध है. इससे, किसी खास मीडिया फ़ाइल को सेव करने वाले ऐप्लिकेशन के बारे में पता चलता है. Android 14 से, इस वैल्यू को तब तक छिपाया जाता है, जब तक कि इनमें से कम से कम एक शर्त पूरी न हो:

• जिस ऐप्लिकेशन ने मीडिया फ़ाइल को सेव किया है उसका पैकेज नेम, दूसरे ऐप्लिकेशन को हमेशा दिखता है.

• मीडिया स्टोर से क्वेरी करने वाला ऐप्लिकेशन, QUERY_ALL_PACKAGES अनुमति का अनुरोध करता है.

निजता के मकसद से, Android, पैकेज की उपलब्धता को कैसे फ़िल्टर करता है, इस बारे में ज़्यादा जानें.