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

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

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

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

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

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

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

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

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

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

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

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

अगर किसी दूसरे ऐप्लिकेशन का पैकेज नाम पास किया जाता है, तो इस तरीके का उस ऐप्लिकेशन की बैकग्राउंड प्रोसेस पर कोई असर नहीं पड़ता. साथ ही, Logcat में यह मैसेज दिखता है:

Invalid packageName: com.example.anotherapp

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

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% तक बड़ा किया जा सकता है. इससे कम दृष्टि वाले उपयोगकर्ताओं को सुलभता से जुड़े ऐसे अन्य विकल्प मिलते हैं जो वेब कॉन्टेंट के लिए सुलभता से जुड़े दिशा-निर्देश (WCAG) के मुताबिक होते हैं.

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

सुरक्षा

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

Starting with Android 14, apps with a targetSdkVersion lower than 23 can't be installed. Requiring apps to meet these minimum target API level requirements improves security and privacy for users.

Malware often targets older API levels in order to bypass security and privacy protections that have been introduced in newer Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 14 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level will result in an installation failure, with the following message appearing in Logcat:

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

On devices upgrading to Android 14, any apps with a targetSdkVersion lower than 23 will remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

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

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

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

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

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

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