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

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

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

为了加强用户隐私保护，Android 14 增加了系统显示您在 Play 管理中心表单中声明的信息的位置数量。目前，用户可以在 Google Play 中的应用详情的数据安全部分查看此信息。

我们建议您查看应用的位置数据分享政策，并花一点时间对应用的 Google Play“数据安全”部分进行任何适用的更新。

如需了解详情，请参阅有关如何在 Android 14 上以更显眼的方式显示数据安全信息的指南。

सुलभता

फ़ॉन्ट को 200% तक स्केल करने की सुविधा

Android 14 से, सिस्टम में फ़ॉन्ट को 200% तक बड़ा किया जा सकता है. इससे कम दृष्टि वाले उपयोगकर्ताओं को सुलभता से जुड़े ऐसे अन्य विकल्प मिलते हैं जो वेब कॉन्टेंट के लिए सुलभता से जुड़े दिशा-निर्देश (WCAG) के मुताबिक होते हैं.

अगर टेक्स्ट के साइज़ को तय करने के लिए, पहले से ही स्केलेबल पिक्सल (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 如何出于隐私保护目的而过滤软件包可见性。