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

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 Profiler में, LeakCanary टास्क.

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

निजता

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

एसएमएस के ज़रिए भेजे गए ओटीपी की सुरक्षा

Android 17 से, Android एक बार इस्तेमाल होने वाले पासवर्ड (ओटीपी) वाले एसएमएस मैसेज को ज़्यादा सुरक्षित बना रहा है.

Android के पिछले वर्शन में, इस सुरक्षा का मुख्य फ़ोकस SMS Retriever फ़ॉर्मैट पर था. एसएमएस रीट्रिवर हैश वाले मैसेज को डिलीवर करने में, ज़्यादातर ऐप्लिकेशन के लिए तीन घंटे की देरी हुई. हालांकि, कुछ ऐप्लिकेशन (जैसे कि डिफ़ॉल्ट एसएमएस हैंडलर) को इस देरी से छूट दी गई थी. साथ ही, जिस ऐप्लिकेशन के पास हैश का मालिकाना हक था उसे भी छूट दी गई थी.

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

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

डिफ़ॉल्ट एसएमएस असिस्टेंट ऐप्लिकेशन, कनेक्ट किए गए डिवाइस के कंपैनियन ऐप्लिकेशन वगैरह जैसे कुछ ऐप्लिकेशन को इस देरी से छूट मिली है. ओटीपी निकालने के लिए एसएमएस मैसेज पढ़ने की सुविधा पर निर्भर रहने वाले सभी ऐप्लिकेशन को SMS Retriever या SMS User Consent एपीआई का इस्तेमाल करना चाहिए, ताकि यह सुविधा काम करती रहे.

सुरक्षा

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

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

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

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

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

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

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

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

अपने ऐप्लिकेशन में इन इंटेंट के इस्तेमाल का पता लगाने के लिए, उल्लंघन ट्रिगर करने के लिए StrictMode के साथ detectImplicitUriPermissionGrant() का इस्तेमाल करें:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

इसके अलावा, लॉग किए गए उन अपवादों को मॉनिटर किया जा सकता है जिनमें यह मैसेज Please set the grant explicitly in the app शामिल हो. यह मैसेज तब दिखता है, जब सिस्टम अनुमति को अपने-आप सेट करता है. इन लॉग की निगरानी करने के लिए, adb कमांड का इस्तेमाल करें:

adb logcat | grep "Please set the grant explicitly in the app"

ज़रूरी अनुमतियां देने के लिए, ACTION_SEND और ACTION_SEND_MULTIPLE इंटेंट में FLAG_GRANT_READ_URI_PERMISSION फ़्लैग जोड़ें:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

ACTION_IMAGE_CAPTURE इंटेंट के लिए, FLAG_GRANT_READ_URI_PERMISSION और FLAG_GRANT_WRITE_URI_PERMISSION, दोनों फ़्लैग शामिल करें:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

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

ऐप्लिकेशन को 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 17 में, ये बदलाव किए गए हैं. इनका मकसद, लोगों को बेहतर और आसान अनुभव देना है.

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

从 Android 17 开始，当设备的配置发生变化（例如，通过旋转）且应用本身未处理此变化时，系统不会恢复之前的 IME 可见性。

如果应用经历了它无法处理的配置更改，并且应用需要在更改后显示键盘，您必须明确请求此行为。您可以通过以下方式之一提出此要求：

  • 将 android:windowSoftInputMode 属性设置为 stateAlwaysVisible。
  • 在 activity 的 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 इंटेंट अब सिर्फ़ तब ब्रॉडकास्ट होता है, जब अपने-आप फिर से पेयर करने की कोशिश नाकाम हो जाती है. अगर सिस्टम बैकग्राउंड में बॉन्ड को ठीक कर लेता है, तो इससे ऐप्लिकेशन में बिना वजह की गड़बड़ियों को ठीक करने की ज़रूरत नहीं पड़ती.
  • उपयोगकर्ता को सूचना: सिस्टम, नए यूज़र इंटरफ़ेस (यूआई) की सूचनाओं और डायलॉग बॉक्स के ज़रिए फिर से पेयर करने की प्रोसेस को मैनेज करता है. लोगों को फिर से पेयर करने की कोशिश की पुष्टि करने के लिए कहा जाएगा. इससे यह पक्का किया जा सकेगा कि उन्हें फिर से कनेक्ट होने के बारे में पता है.

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

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