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

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

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

status

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

निजता

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

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

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

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

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

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

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

सुरक्षा

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

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

बैकग्राउंड ऑडियो सुरक्षा कड़ी करना

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

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

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

कनेक्टिविटी

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

ब्लूटूथ कनेक्शन के बंद होने पर, अपने-आप फिर से कनेक्ट होने की सुविधा

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

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

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

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

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

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