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

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

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

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

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

Exact alarms are meant for user-intentioned notifications, or for actions that need to happen at a precise time. Starting in Android 14, the SCHEDULE_EXACT_ALARM permission is no longer being pre-granted to most newly installed apps targeting Android 13 and higher—the permission is denied by default.

Learn more about the changes to the permission for scheduling exact alarms.

ऐप्लिकेशन के कैश किए जाने पर, कॉन्टेक्स्ट-रजिस्टर्ड ब्रॉडकास्ट को क्यू में रखा जाता है

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

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

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

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

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

Invalid packageName: com.example.anotherapp

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

एमटीयू का अनुरोध करने वाले पहले GATT क्लाइंट के लिए, एमटीयू को 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 introduces a new reason an app can be placed into the restricted standby bucket. The app's jobs trigger ANR errors multiple times due to onStartJob, onStopJob, or onBind method timeouts. (See JobScheduler reinforces callback and network behavior for changes to onStartJob and onStopJob.)

To track whether or not the app has entered the restricted standby bucket, we recommend logging with the API UsageStatsManager.getAppStandbyBucket() on job execution or UsageStatsManager.queryEventsForSelf() on app startup.

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 सूचनाएं
  • एंटरप्राइज़ के लिए डिवाइस नीति नियंत्रक (डीपीसी) और सहायक पैकेज
  • मीडिया से जुड़ी सूचनाएं
  • डिफ़ॉल्ट खोज सिलेक्टर पैकेज

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

To enhance user privacy, Android 14 increases the number of places where the system shows the information you have declared in the Play Console form. Currently, users can view this information in the Data safety section on your app's listing in Google Play.

We encourage you to review your app's location data sharing policies and take a moment to make any applicable updates to your app's Google Play Data safety section.

Learn more in the guide about how data safety information is more visible on Android 14.

सुलभता

फ़ॉन्ट स्केलिंग को 200% तक बढ़ाने के लिए, नॉन-लीनियर फ़ॉन्ट स्केलिंग का इस्तेमाल किया जाता है

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

अगर टेक्स्ट के साइज़ को तय करने के लिए, पहले से ही स्केल्ड पिक्सल (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

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

The media store supports queries for the OWNER_PACKAGE_NAME column, which indicates the app that stored a particular media file. Starting in Android 14, this value is redacted unless at least one of the following conditions is true:

  • The app that stored the media file has a package name that is always visible to other apps.

  • The app that queries the media store requests the QUERY_ALL_PACKAGES permission.

Learn more about how Android filters package visibility for privacy purposes.