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

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

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

सुरक्षा

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

usesClearTraffic के बंद होने का प्लान

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

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

usesCleartextTraffic एट्रिब्यूट को true पर सेट करें
नेटवर्क कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल करना

अगर आपके ऐप्लिकेशन का कम से कम एपीआई लेवल 24 या इससे ज़्यादा है, तो नेटवर्क कॉन्फ़िगरेशन फ़ाइल का इस्तेमाल किया जा सकता है. इसके लिए, आपको usesCleartextTraffic सेट करने की ज़रूरत नहीं है.

यूआरआई के लिए, बिना अनुमति के ऐक्सेस देने की सुविधा पर पाबंदी लगाना

फ़िलहाल, अगर कोई ऐप्लिकेशन ऐसे यूआरआई के साथ इंटेंट लॉन्च करता है जिसमें ऐक्शन Send, SendMultiple या ImageCapture है, तो सिस्टम टारगेट ऐप्लिकेशन को यूआरआई की पढ़ने और लिखने की अनुमतियां अपने-आप दे देता है. हम Android 18 में इस व्यवहार को बदलने का प्लान बना रहे हैं. इस वजह से, हमारा सुझाव है कि ऐप्लिकेशन, सिस्टम पर भरोसा करने के बजाय, यूआरआई से जुड़ी ज़रूरी अनुमतियां साफ़ तौर पर दें.

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

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

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

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

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

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

रोटेशन के बाद, IME की डिफ़ॉल्ट दृश्यता को वापस लाना

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

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

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 में, मीडिया के व्यवहार में ये बदलाव किए गए हैं.

बैकग्राउंड ऑडियो को बेहतर बनाना

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

If the app tries to call audio APIs while the app is not in a valid lifecycle, the audio playback and volume change APIs fail silently without throwing an exception or providing a failure message. The audio focus API fails with the result code AUDIOFOCUS_REQUEST_FAILED.

For more information, including mitigation strategies, see Background audio hardening.