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 पर सेट किया जाता है
Starting from Android 14, the Android Bluetooth stack more strictly adheres to
Version 5.2 of the Bluetooth Core Specification and requests
the BLE ATT MTU to 517 bytes when the first GATT client requests an MTU using
the BluetoothGatt#requestMtu(int) API, and disregards all subsequent MTU
requests on that ACL connection.
To address this change and make your app more robust, consider the following options:
- Your peripheral device should respond to the Android device's MTU request
with a reasonable value that can be accommodated by the peripheral. The
final negotiated value will be a minimum of the Android requested value and
the remote provided value (for example,
min(517, remoteMtu))- Implementing this fix could require a firmware update for peripheral
- Alternatively, limit your GATT characteristic writes based on the minimum
between the known supported value of your peripheral and the received MTU
change
- A reminder that you should reduce 5 bytes from the supported size for the headers
- For example:
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 的应用无法安装。要求应用满足这些最低目标 API 级别要求有助于提高用户的安全性和隐私性。
恶意软件通常会以较旧的 API 级别为目标平台,以绕过在较新版本 Android 中引入的安全和隐私保护机制。例如,有些恶意软件应用使用 targetSdkVersion 22,以避免受到 Android 6.0 Marshmallow(API 级别 23)在 2015 年引入的运行时权限模型的约束。这项 Android 14 变更使恶意软件更难以规避安全和隐私权方面的改进限制。尝试安装以较低 API 级别为目标平台的应用将导致安装失败,并且 Logcat 中会显示以下消息:
INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 23, but found 7
在升级到 Android 14 的设备上,targetSdkVersion 低于 23 的所有应用都将继续保持安装状态。
如果您需要测试以旧版 API 级别为目标平台的应用,请使用以下 ADB 命令:
adb install --bypass-low-target-sdk-block FILENAME.apk
मीडिया फ़ाइलों के ओनर के पैकेज के नाम छिपाए जा सकते हैं
मीडिया स्टोर में, OWNER_PACKAGE_NAME कॉलम के लिए क्वेरी की सुविधा उपलब्ध है. इससे, किसी खास मीडिया फ़ाइल को सेव करने वाले ऐप्लिकेशन के बारे में पता चलता है. Android
14 से, इस वैल्यू को तब तक छिपाया जाता है, जब तक कि इनमें से कम से कम एक शर्त पूरी न हो:
- जिस ऐप्लिकेशन ने मीडिया फ़ाइल को सेव किया है उसका पैकेज नेम, दूसरे ऐप्लिकेशन को हमेशा दिखता है.
मीडिया स्टोर से क्वेरी करने वाला ऐप्लिकेशन,
QUERY_ALL_PACKAGESअनुमति का अनुरोध करता है.
निजता के मकसद से, Android, पैकेज की उपलब्धता को कैसे फ़िल्टर करता है, इस बारे में ज़्यादा जानें.