Android 14 प्लैटफ़ॉर्म में कुछ ऐसे बदलाव किए गए हैं जिनका असर आपके ऐप्लिकेशन पर पड़ सकता है.
Android 14 पर चलने वाले सभी ऐप्लिकेशन पर, ये बदलाव लागू होते हैं. भले ही,
targetSdkVersion. आपको अपने ऐप्लिकेशन की जांच करनी चाहिए. इसके बाद, जहां लागू हो वहां इन सुविधाओं को ठीक से काम करने के लिए, ऐप्लिकेशन में ज़रूरत के मुताबिक बदलाव करना चाहिए.
Android 14 को टारगेट करने वाले ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची भी ज़रूर देखें.
मुख्य फ़ंक्शन
सटीक समय वाले अलार्म शेड्यूल करने की अनुमति डिफ़ॉल्ट रूप से नहीं दी जाती
एग्ज़ैक्ट अलार्म, उपयोगकर्ता के हिसाब से सूचनाएं देने या ऐसी कार्रवाइयों के लिए होते हैं जिन्हें तय समय पर करना ज़रूरी होता है. Android 14 से, SCHEDULE_EXACT_ALARM अनुमति अब Android 13 और उसके बाद के वर्शन को टारगेट करने वाले ज़्यादातर नए इंस्टॉल किए गए ऐप्लिकेशन को पहले से नहीं दी जा रही है. यह अनुमति डिफ़ॉल्ट रूप से अस्वीकार कर दी जाती है.
ठीक समय पर अलार्म शेड्यूल करने की अनुमति में हुए बदलावों के बारे में ज़्यादा जानें.
ऐप्लिकेशन के कैश मेमोरी में सेव होने के दौरान, कॉन्टेक्स्ट के हिसाब से रजिस्टर की गई ब्रॉडकास्ट को लाइन में लगाया जाता है
在 Android 14 中,当应用处于缓存状态时,系统可以将上下文注册的广播放入队列中。这与 Android 12(API 级别 31)为异步 binder 事务引入的队列行为类似。在清单中声明的广播不会加入队列,并且应用会从缓存状态中移除以进行广播传递。
当应用离开缓存状态(例如返回前台)时,系统会传递所有已加入队列的广播。某些广播的多个实例 可能会合并为一个广播。取决于其他因素,如系统 运行状况,则可能会从缓存状态中移除应用,以及之前排队 广播。
ऐप्लिकेशन, सिर्फ़ अपनी बैकग्राउंड प्रोसेस बंद कर सकते हैं
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(API 级别 34)及更高版本中,平台将可使用 mlock() 锁定的最大内存量减少到每个进程 64 KB。在之前的版本中,每个进程的上限为 64 MB。此限制有助于更好地管理应用和系统的内存。为了在各种设备上提供更一致的体验,Android 14 针对兼容设备上的新 mlock() 限制添加了一项新的 CTS 测试。
सिस्टम, कैश मेमोरी में सेव किए गए ऐप्लिकेशन के लिए संसाधनों के इस्तेमाल को लागू करता है
डिज़ाइन के हिसाब से, जब किसी ऐप्लिकेशन को बैकग्राउंड में भेजा जाता है और कोई दूसरा ऐप्लिकेशन प्रोसेस कॉम्पोनेंट नहीं चल रहा होता है, तो ऐप्लिकेशन की प्रोसेस कैश मेमोरी में सेव होती है. सिस्टम की मेमोरी कम होने की वजह से, इस तरह की ऐप्लिकेशन प्रोसेस को बंद किया जा सकता है. 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条通知- 企业设备政策控制器 (DPC) 和支持软件包
- 媒体通知
- 默认的搜索选择器软件包
डेटा की सुरक्षा से जुड़ी जानकारी ज़्यादा आसानी से दिखती है
为了加强用户隐私保护,Android 14 增加了系统显示您在 Play 管理中心表单中声明的信息的位置数量。目前,用户可以在 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, पैकेज की उपलब्धता को कैसे फ़िल्टर करता है, इस बारे में ज़्यादा जानें.