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

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

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

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

Android 17 (एपीआई लेवल 37) में, ये बदलाव शामिल हैं. इनसे Android सिस्टम की कई मुख्य क्षमताओं में बदलाव होता है या उन्हें बढ़ाया जाता है.

ऐप्लिकेशन के लिए मेमोरी की सीमाएं

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

`ApplicationExitInfo` में ` getDescription` को कॉल करके, यह पता लगाया जा सकता है कि आपके ऐप्लिकेशन सेशन पर असर पड़ा है या नहीं. अगर आपके ऐप्लिकेशन पर असर पड़ा है, तो बंद होने की वजह `REASON_OTHER` होगी. साथ ही, जानकारी में `"MemoryLimiter:AnonSwap"` स्ट्रिंग के साथ-साथ अन्य जानकारी भी शामिल होगी. मेमोरी की सीमा पूरी होने पर, हीप डंप पाने के लिए, ट्रिगर-आधारित प्रोफ़ाइलिंग के साथ TRIGGER_TYPE_ANOMALY का भी इस्तेमाल किया जा सकता है.

Android Studio Panda में, मेमोरी लीक की समस्याओं को ढूंढने के लिए, Android Studio Profiler में सीधे तौर पर LeakCanary इंटिग्रेशन जोड़ा गया है. यह एक खास टास्क के तौर पर काम करता है. इसे आईडीई में कॉन्टेक्स्चुअलाइज़ किया गया है और यह आपके सोर्स कोड के साथ पूरी तरह से इंटिग्रेट किया गया है.

सुरक्षा

Android 17 में, डिवाइस और ऐप्लिकेशन की सुरक्षा को बेहतर बनाने के लिए, ये बदलाव किए गए हैं.

usesClearTraffic को बंद करने की योजना

In a future release, we plan to deprecate the usesCleartextTraffic element. Apps that need to make unencrypted (HTTP) connections should migrate to using a network security configuration file, which lets you specify which domains your app needs to make cleartext connections to.

Be aware that network security configuration files are only supported on API levels 24 and higher. If your app has a minimum API level lower than 24, you should do both of the following:

• Set the usesCleartextTraffic attribute to true
• Use a network configuration file

If your app's minimum API level is 24 or higher, you can use a network configuration file and you don't need to set usesCleartextTraffic.

यूआरआई के लिए, बिना अनुमति के ग्रांट को सीमित करना

Currently, if an app launches an intent with a URI that has the action Send, SendMultiple, or ImageCapture, the system automatically grants the read and write URI permissions to the target app. We plan to change this behavior in Android 18. For this reason, we recommend that apps explicitly grant the relevant URI permissions instead of relying on the system to grant them.

हर ऐप्लिकेशन के लिए कीस्टोर की सीमाएं

ऐप्लिकेशन को Android Keystore में बहुत ज़्यादा कुंजियां नहीं बनानी चाहिए, क्योंकि यह डिवाइस पर मौजूद सभी ऐप्लिकेशन के लिए शेयर किया गया संसाधन है. Android 17 से, सिस्टम यह तय करता है कि कोई ऐप्लिकेशन कितनी कुंजियों का मालिकाना हक रख सकता है. Android 17 (एपीआई लेवल 37) या उसके बाद के वर्शन को टारगेट करने वाले सिस्टम ऐप्लिकेशन के लिए, 50,000 कुंजियों की सीमा तय की गई है. वहीं, अन्य सभी ऐप्लिकेशन के लिए, 2,00,000 कुंजियों की सीमा तय की गई है. सिस्टम ऐप्लिकेशन के लिए, 2,00,000 कुंजियों की सीमा तय की गई है. इससे कोई फ़र्क़ नहीं पड़ता कि वे किस एपीआई लेवल को टारगेट करते हैं.

अगर कोई ऐप्लिकेशन तय सीमा से ज़्यादा कुंजियां बनाने की कोशिश करता है, तो KeyStoreException गड़बड़ी की वजह से कुंजियां नहीं बन पाएंगी. अपवाद के मैसेज स्ट्रिंग में, कुंजी की सीमा के बारे में जानकारी होती है. अगर ऐप्लिकेशन, अपवाद पर getNumericErrorCode() को कॉल करता है, तो रिटर्न वैल्यू इस बात पर निर्भर करती है कि ऐप्लिकेशन किस एपीआई लेवल को टारगेट करता है:

• Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए: getNumericErrorCode() नई ERROR_TOO_MANY_KEYS वैल्यू दिखाता है.
• अन्य सभी ऐप्लिकेशन के लिए: getNumericErrorCode(), ERROR_INCORRECT_USAGE दिखाता है.

लोगों का अनुभव और सिस्टम यूज़र इंटरफ़ेस (यूआई)

Android 17 में, ये बदलाव शामिल हैं. इनका मकसद, लोगों को बेहतर और आसान अनुभव देना है.

स्क्रीन रोटेट करने के बाद, डिफ़ॉल्ट आईएमई की विज़िबिलिटी को वापस लाना

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

अगर आपके ऐप्लिकेशन के कॉन्फ़िगरेशन में कोई ऐसा बदलाव होता है जिसे वह मैनेज नहीं करता है और बदलाव के बाद ऐप्लिकेशन को कीबोर्ड दिखाने की ज़रूरत है, तो आपको साफ़ तौर पर इसके लिए अनुरोध करना होगा. इसके लिए, इनमें से कोई एक तरीका अपनाएं:

• android:windowSoftInputMode एट्रिब्यूट को stateAlwaysVisible पर सेट करें.
• अपने ऐप्लिकेशन की onCreate() तरीके में, प्रोग्राम के ज़रिए सॉफ़्ट कीबोर्ड का अनुरोध करें या onConfigurationChanged() तरीका जोड़ें.

लोगों से मिले इनपुट

Android 17 में, ये बदलाव शामिल हैं. इनसे, कीबोर्ड और टचपैड जैसे लोगों से मिले इनपुट वाले डिवाइसों के साथ ऐप्लिकेशन के इंटरैक्ट करने के तरीके पर असर पड़ता है.

पॉइंटर कैप्चर करने के दौरान, टचपैड डिफ़ॉल्ट रूप से रिलेटिव इवेंट डिलीवर करते हैं

Android 17 से, अगर कोई ऐप्लिकेशन View.requestPointerCapture() का इस्तेमाल करके पॉइंटर कैप्चर करने का अनुरोध करता है और उपयोगकर्ता टचपैड का इस्तेमाल करता है, तो सिस्टम उपयोगकर्ता के टच से पॉइंटर की गतिविधि और स्क्रोलिंग के जेस्चर को पहचानता है. साथ ही, उन्हें ऐप्लिकेशन को उसी तरह से रिपोर्ट करता है जिस तरह से कैप्चर किए गए माउस से पॉइंटर और स्क्रोल व्हील की गतिविधियों को रिपोर्ट किया जाता है. ज़्यादातर मामलों में, इससे उन ऐप्लिकेशन की ज़रूरत खत्म हो जाती है जो कैप्चर किए गए चूहों के साथ काम करते हैं. साथ ही, टचपैड के लिए खास हैंडलिंग लॉजिक जोड़ते हैं. ज़्यादा जानकारी के लिए, View.POINTER_CAPTURE_MODE_RELATIVE का दस्तावेज़ देखें.

इससे पहले, सिस्टम टचपैड से किए गए जेस्चर को नहीं पहचानता था. इसके बजाय, यह उंगलियों की सटीक जगह की जानकारी को ऐप्लिकेशन को उसी फ़ॉर्मैट में भेजता था जिस फ़ॉर्मैट में टचस्क्रीन पर किए गए टच की जानकारी भेजी जाती है. अगर किसी ऐप्लिकेशन को अब भी इस डेटा की ज़रूरत है, तो उसे View.POINTER_CAPTURE_MODE_ABSOLUTE के साथ View.requestPointerCapture(int) तरीके को कॉल करना चाहिए.

मीडिया

Android 17 में, मीडिया के व्यवहार में ये बदलाव किए गए हैं.

बैकग्राउंड में ऑडियो चलाने की सुविधा को बेहतर बनाना

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

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

ज़्यादा जानकारी के लिए, बैकग्राउंड में ऑडियो को सुरक्षित बनाने के बारे में पढ़ें. इसमें, सुरक्षा को बेहतर बनाने की रणनीतियां भी शामिल हैं.

कनेक्टिविटी

Android 17 में, डिवाइस की कनेक्टिविटी को बेहतर बनाने के लिए, ये बदलाव किए गए हैं.

ब्लूटूथ कनेक्शन टूटने पर, अपने-आप फिर से पेयर होना

Android 17 में, अपने-आप फिर से पेयर होने की सुविधा जोड़ी गई है. यह सिस्टम-लेवल पर किया गया सुधार है. इसे ब्लूटूथ कनेक्शन के बंद होने की समस्या को अपने-आप ठीक करने के लिए डिज़ाइन किया गया है.

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

ज़्यादातर ऐप्लिकेशन के लिए, कोड में बदलाव करने की ज़रूरत नहीं होगी. हालांकि, डेवलपर को ब्लूटूथ स्टैक में होने वाले इन बदलावों के बारे में पता होना चाहिए:

• पेयर करने का नया कॉन्टेक्स्ट: ACTION_PAIRING_REQUEST में अब EXTRA_PAIRING_CONTEXT एक्स्ट्रा शामिल है. इससे ऐप्लिकेशन, पेयर करने के सामान्य अनुरोध और ऑटोनॉमस सिस्टम की ओर से शुरू किए गए फिर से पेयर करने के अनुरोध के बीच अंतर कर सकते हैं.
• शर्तों के साथ कुंजी अपडेट करना: मौजूदा सुरक्षा कुंजियों को सिर्फ़ तब बदला जाएगा, जब फिर से पेयर करने की प्रोसेस पूरी हो जाए और नया कनेक्शन, पिछले कनेक्शन के सुरक्षा स्तर के बराबर या उससे ज़्यादा हो.
• बदली गई इंटेंट टाइमिंग: ACTION_KEY_MISSING इंटेंट अब सिर्फ़ तब ब्रॉडकास्ट होता है, जब अपने-आप फिर से पेयर करने की कोशिश नाकाम हो जाती है. अगर सिस्टम बैकग्राउंड में बॉन्ड को ठीक कर लेता है, तो इससे ऐप्लिकेशन में बिना वजह की गड़बड़ियों को ठीक करने की ज़रूरत नहीं पड़ती.
• उपयोगकर्ता को सूचना: सिस्टम, नए यूज़र इंटरफ़ेस (यूआई) की सूचनाओं और डायलॉग बॉक्स के ज़रिए फिर से पेयर करने की प्रोसेस को मैनेज करता है. लोगों को फिर से पेयर करने की कोशिश की पुष्टि करने के लिए कहा जाएगा. इससे यह पक्का किया जा सकेगा कि उन्हें फिर से कनेक्ट होने के बारे में पता है.

पेरिफ़रल डिवाइस बनाने वाली कंपनियों और कंपैनियन ऐप्लिकेशन के डेवलपर को यह पुष्टि करनी चाहिए कि हार्डवेयर और ऐप्लिकेशन, बॉन्ड ट्रांज़िशन को आसानी से मैनेज करते हैं. इस व्यवहार की जांच करने के लिए, इनमें से किसी एक तरीके का इस्तेमाल करके, रिमोट बॉन्ड के खत्म होने का सिम्युलेट करें:

• सहायक डिवाइस से, बॉन्ड की जानकारी को मैन्युअल तरीके से हटाएं
• डिवाइस को मैन्युअल तरीके से अनपेयर करें: सेटिंग > कनेक्ट किए गए डिवाइस