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

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

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

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

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

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

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

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

अपने ऐप्लिकेशन की मेमोरी मैनेज करना दस्तावेज़ में, ऐप्लिकेशन की मेमोरी से जुड़ी समस्याओं का पता लगाने और उसके रिसॉर्स के इस्तेमाल को ऑप्टिमाइज़ करने के बारे में जानकारी दी गई है.

मेमोरी की कमी होने पर, अपने ऐप्लिकेशन की परफ़ॉर्मेंस की जांच करना

जिन डिवाइसों पर मेमोरी की सीमाएं लागू होती हैं उन पर, मेमोरी की सीमाओं को अडजस्ट या बंद करने के लिए, Android डीबग ब्रिज (adb) का इस्तेमाल किया जा सकता है. शेल कमांड am मेमोरी की सीमाओं को अडजस्ट करने के लिए, तीन सब-कमांड उपलब्ध कराता है. (इन कमांड का असर ऐसे डिवाइस पर नहीं पड़ता जिसमें मेमोरी की सीमाएं लागू नहीं होतीं.)

  • am memory-limiter ignore <uid>|none|all
  • am memory-limiter manual <pid> <limit>|max|none
  • am memory-limiter status
ignore

मेमोरी लिमिटर को कुछ या सभी प्रोसेस को अनदेखा करने का निर्देश देता है. यूआईडी (Android यूज़र आईडी) पास करने से, मेमोरी लिमिटर को उस यूआईडी से जुड़ी सभी प्रोसेस पर नीति उल्लंघन ठीक करने का तरीका लागू न करने का निर्देश मिलता है. all (सभी ऐप्लिकेशन को अनदेखा करें) या none (किसी भी ऐप्लिकेशन को अनदेखा न करें) भी पास किया जा सकता है. none को पास करने से, am memory-limiter ignore को किए गए पिछले कॉल बदल जाते हैं.

अगर आपने मेमोरी लिमिटर को किसी यूआईडी को अनदेखा करने का निर्देश दिया है, तो भी am memory-limiter manual को कॉल करके, ऐप्लिकेशन में किसी प्रोसेस के लिए मैन्युअल तरीके से मेमोरी की सीमा लागू की जा सकती है.

manual

यह सिस्टम को निर्देश देता है कि वह तय किए गए पीआईडी (प्रोसेस आईडी) वाली प्रोसेस पर, मेमोरी की सीमा लागू करे. मेमोरी की सीमा को एमबी में पूर्णांक के तौर पर बताया जाता है. उदाहरण के लिए, 30 पास करने का मतलब है कि प्रोसेस के लिए 30 एमबी मेमोरी तय की गई है. max पास करने पर, उस प्रोसेस के लिए मेमोरी की सभी सीमाएं हट जाती हैं. none पास करने पर, प्रोसेस पर सेट की गई कोई भी मैन्युअल सीमा हट जाती है. साथ ही, सिस्टम की डिफ़ॉल्ट सीमा (अगर कोई है) वापस आ जाती है.

status

मेमोरी लिमिटर की मौजूदा स्थिति की जानकारी देता है. स्टेटस में, दिखने वाली और न दिखने वाली प्रोसेस पर लागू की गई मेमोरी की सीमाएं शामिल होती हैं.

निजता

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

एसएमएस से मिलने वाले ओटीपी की सुरक्षा

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

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

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

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

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

सुरक्षा

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

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

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

ध्यान रखें कि नेटवर्क की सुरक्षा से जुड़ी कॉन्फ़िगरेशन फ़ाइलें, सिर्फ़ एपीआई लेवल 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);

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

Apps should avoid creating excessive numbers of keys in Android Keystore, because it is a shared resource for all apps on the device. Beginning with Android 17, the system enforces a limit on the number of keys an app can own. The limit is 50,000 keys for non-system apps targeting Android 17 (API level 37) or higher, and 200,000 keys for all other apps. System apps have a limit of 200,000 keys, regardless of which API level they target.

If an app attempts to create keys beyond the limit, the creation fails with a KeyStoreException. The exception's message string contains information about the key limit. If the app calls getNumericErrorCode() on the exception, the return value depends on what API level the app targets:

  • Apps targeting Android 17 (API level 37) or higher: getNumericErrorCode() returns the new ERROR_TOO_MANY_KEYS value.
  • All other apps: getNumericErrorCode() returns ERROR_INCORRECT_USAGE.

क्रॉस प्रोफ़ाइल लूपबैक ट्रैफ़िक को ब्लॉक करें

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

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

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

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

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