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

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

ऐप्लिकेशन के काम करने के तरीके में हुए उन बदलावों की सूची भी देखना न भूलें जिनका असर सिर्फ़ Android 12 को टारगेट करने वाले ऐप्लिकेशन पर पड़ता है.

उपयोगकर्ता अनुभव

स्ट्रेच ओवरस्क्रोल इफ़ेक्ट

Android 12 और उसके बाद के वर्शन वाले डिवाइसों पर, ओवरस्क्रोल इवेंट के लिए विज़ुअल व्यवहार बदल जाता है.

Android 11 और उससे पहले के वर्शन पर, ओवरस्क्रोल इवेंट की वजह से विज़ुअल एलिमेंट चमकते हैं. वहीं, Android 12 और उसके बाद के वर्शन पर, विज़ुअल एलिमेंट खींचने और छोड़ने पर स्ट्रेच होते हैं और वापस आ जाते हैं. साथ ही, फ़्लिंग इवेंट पर फ़्लिंग होते हैं और वापस आ जाते हैं.

ज़्यादा जानकारी के लिए, स्क्रोल करने के जेस्चर को ऐनिमेट करने के बारे में गाइड देखें.

ऐप्लिकेशन की स्प्लैश स्क्रीन

अगर आपने पहले Android 11 या इससे पहले के वर्शन में कस्टम स्प्लैश स्क्रीन लागू की है, तो आपको अपने ऐप्लिकेशन को SplashScreen API पर माइग्रेट करना होगा. इससे यह पक्का किया जा सकेगा कि Android 12 से यह सही तरीके से दिखे. अपने ऐप्लिकेशन को माइग्रेट न करने पर, ऐप्लिकेशन लॉन्च करने का अनुभव खराब हो सकता है या अनचाहा अनुभव मिल सकता है.

निर्देशों के लिए, Android 12 पर स्प्लैश स्क्रीन को लागू करने के मौजूदा तरीके को माइग्रेट करना लेख पढ़ें.

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

ज़्यादा जानकारी के लिए, स्प्लैश स्क्रीन डेवलपर गाइड देखें.

वेब इंटेंट रिज़ॉल्यूशन

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

ऐप्लिकेशन को यह अनुमति पाने के लिए, इनमें से कोई एक तरीका अपनाना होगा:

• Android ऐप्लिकेशन के लिंक का इस्तेमाल करके, डोमेन की पुष्टि करें.

  Android 12 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन पर, सिस्टम आपके ऐप्लिकेशन के Android ऐप्लिकेशन लिंक की अपने-आप पुष्टि होने का तरीका बदलता है. अपने ऐप्लिकेशन के इंटेंट फ़िल्टर में, देखें कि आपने BROWSABLE कैटगरी शामिल की है या नहीं. साथ ही, यह भी देखें कि आपका ऐप्लिकेशन https स्कीम के साथ काम करता है या नहीं.

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

• सिस्टम सेटिंग में जाकर, उपयोगकर्ता से अपने ऐप्लिकेशन को डोमेन से जोड़ने का अनुरोध करें.

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

जेस्चर वाले नेविगेशन के लिए इमर्सिव मोड में सुधार

Android 12 में, मौजूदा व्यवहार को बेहतर बनाया गया है, ताकि उपयोगकर्ता इमर्सिव मोड में रहते हुए, जेस्चर नेविगेशन के निर्देशों को आसानी से इस्तेमाल कर सकें. इसके अलावा, Android 12 में स्टिकी इमर्सिव मोड के लिए, पुराने सिस्टम के साथ काम करने की सुविधा भी उपलब्ध है.

Display#getRealSize और getRealMetrics: इस्तेमाल बंद करना और पाबंदियां

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

• Display.getSize()
• Display.getMetrics()

हम Android 12 में, WindowMetrics का इस्तेमाल करने के सुझाव लगातार देते रहेंगे. साथ ही, अब इन तरीकों को बंद कर दिया जाएगा:

• Display.getRealSize()
• Display.getRealMetrics()

ऐप्लिकेशन के बॉउंड को वापस पाने के लिए, डिसप्ले एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन के व्यवहार को कम करने के लिए, Android 12 उन ऐप्लिकेशन के लिए एपीआई से मिली वैल्यू पर पाबंदी लगाता है जिनका साइज़ पूरी तरह से बदला नहीं जा सकता. इससे उन ऐप्लिकेशन पर असर पड़ सकता है जो MediaProjection के साथ इस जानकारी का इस्तेमाल कर रहे हैं.

ऐप्लिकेशन को अपनी विंडो की सीमाओं के बारे में क्वेरी करने के लिए, WindowMetrics एपीआई का इस्तेमाल करना चाहिए. साथ ही, Configuration.densityDpi का इस्तेमाल मौजूदा डेंसिटी के बारे में क्वेरी करने के लिए करना चाहिए.

Android के पुराने वर्शन के साथ काम करने के लिए, आपके पास WindowManager Jetpack लाइब्रेरी का इस्तेमाल करने का विकल्प है. इसमें एक WindowMetrics क्लास शामिल है, जो Android 4.0 (एपीआई लेवल 14) और उसके बाद के वर्शन के साथ काम करती है.

WindowMetrics का इस्तेमाल करने के उदाहरण

सबसे पहले, पक्का करें कि आपके ऐप्लिकेशन की गतिविधियों को पूरी तरह से रीसाइज़ किया जा सकता हो.

यूज़र इंटरफ़ेस (यूआई) से जुड़े किसी भी काम के लिए, गतिविधि को गतिविधि के संदर्भ से WindowMetrics पर निर्भर रहना चाहिए. खास तौर पर, WindowManager.getCurrentWindowMetrics() या Jetpack के WindowMetricsCalculator.computeCurrentWindowMetrics() पर.

अगर आपका ऐप्लिकेशन, MediaProjection बनाता है, तो बाउंड का साइज़ सही होना चाहिए. ऐसा इसलिए, क्योंकि प्रोजेक्शन में उस हिस्से को कैप्चर किया जाता है जिसमें प्रोजेक्टर ऐप्लिकेशन चल रहा है.

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

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

अगर ऐप्लिकेशन का साइज़ पूरी तरह से साइज़ नहीं बदला जा सकता है, तो इसे WindowContext इंस्टेंस से क्वेरी करनी चाहिए और WindowManager.getMaximumWindowMetrics() या Jetpack तरीके WindowMetricsCalculator.computeMaximumWindowMetrics() का इस्तेमाल करके WindowMetrics ऐक्टिविटी बाउंड को हासिल करना चाहिए.

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

मल्टी-विंडो मोड में सभी ऐप्लिकेशन

Android 12 में, मल्टी-विंडो मोड को स्टैंडर्ड मोड के तौर पर इस्तेमाल किया जा सकता है.

बड़ी स्क्रीन (sw >= 600dp) पर, प्लैटफ़ॉर्म सभी ऐप्लिकेशन को मल्टी-विंडो मोड में इस्तेमाल करने की सुविधा देता है. भले ही, ऐप्लिकेशन का कॉन्फ़िगरेशन कुछ भी हो. अगर resizeableActivity="false" है, तो डिसप्ले डाइमेंशन के हिसाब से ऐप्लिकेशन को ज़रूरत पड़ने पर कंपैटबिलिटी मोड में डाला जाता है.

छोटी स्क्रीन (sw < 600dp) पर, सिस्टम किसी गतिविधि के minWidth और minHeight की जांच करता है. इससे यह पता चलता है कि गतिविधि, मल्टी-विंडो मोड में चल सकती है या नहीं. अगर resizeableActivity="false" है, तो ऐप्लिकेशन को मल्टी-विंडो मोड में चलने से रोक दिया जाता है. भले ही, उसकी कम से कम चौड़ाई और ऊंचाई कितनी भी हो.

ज़्यादा जानकारी के लिए, मल्टी-विंडो मोड लेख पढ़ें.

बड़ी स्क्रीन पर कैमरे की झलक

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

Android 12 पर, ऐसे कैमरा ऐप्लिकेशन जो किसी खास स्क्रीन ओरिएंटेशन का अनुरोध करते हैं और जिनका साइज़ बदला नहीं जा सकता (resizeableActivity="false"), अपने-आप इनसेट पोर्ट्रेट मोड में चले जाते हैं. इससे, कैमरे की झलक का सही ओरिएंटेशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) तय होता है. फ़ोल्ड किए जा सकने वाले डिवाइस और ऐसे अन्य डिवाइस जिनमें कैमरा हार्डवेयर ऐब्स्ट्रक्शन लेयर (HAL) की सुविधा होती है, कैमरे के आउटपुट पर ज़्यादा रोटेशन किया जाता है, ताकि सेंसर ओरिएंटेशन सही पाया जा सके. इसके बाद, कैमरे के आउटपुट को ऐप्लिकेशन के कैमरे की झलक के आसपेक्ट रेशियो के हिसाब से क्रॉप किया जाता है. फ़ोटो को काटने और उसे ज़्यादा घुमाने से, कैमरे की झलक सही तरीके से दिख रही है. इससे कोई फ़र्क़ नहीं पड़ता कि डिवाइस का ओरिएंटेशन सही है या नहीं. साथ ही, डिवाइस अनफ़ोल्ड या अनफ़ोल्ड भी हो सकता है.

फ़ोरग्राउंड सेवा की सूचनाओं के लिए यूज़र एक्सपीरियंस में देरी

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

परफ़ॉर्मेंस

पाबंदी वाले ऐप्लिकेशन का स्टैंडबाइ बकेट

Android 11 (एपीआई लेवल 30) ने ऐप्लिकेशन स्टैंडबाय बकेट के तौर पर पाबंदी वाले बकेट की सुविधा उपलब्ध कराई. Android 12 में, यह बकेट डिफ़ॉल्ट रूप से चालू रहती है. पाबंदी वाली बकेट की प्राथमिकता सभी बकेट में सबसे कम होती है. साथ ही, उस पर सबसे ज़्यादा पाबंदियां होती हैं. प्राथमिकता के हिसाब से, बकेट की सूची इस तरह से है:

1. ऐक्टिव: फ़िलहाल, ऐप्लिकेशन का इस्तेमाल किया जा रहा है या इसे हाल ही में इस्तेमाल किया गया है.
2. काम करने वाला सेट: ऐप्लिकेशन का नियमित तौर पर इस्तेमाल किया जा रहा है.
3. अक्सर इस्तेमाल किया जाता है: ऐप्लिकेशन का इस्तेमाल अक्सर किया जाता है, लेकिन हर दिन नहीं.
4. कम: ऐप्लिकेशन का इस्तेमाल अक्सर नहीं किया जाता.
5. पाबंदी है: ऐप्लिकेशन में सिस्टम के बहुत सारे संसाधनों का इस्तेमाल किया जाता है या ऐसा हो सकता है कि उसकी सेटिंग अनचाही हो.

सिस्टम, इस्तेमाल के पैटर्न के साथ-साथ आपके ऐप्लिकेशन के व्यवहार को भी ध्यान में रखता है. इससे यह तय किया जाता है कि आपके ऐप्लिकेशन को पाबंदी वाली बकेट में रखा जाए या नहीं.

अगर आपका ऐप्लिकेशन, सिस्टम से जुड़े संसाधनों का ज़्यादा ज़िम्मेदारी से इस्तेमाल करता है, तो हो सकता है कि आपके ऐप्लिकेशन को प्रतिबंधित बकेट में न रखा जाए. साथ ही, अगर उपयोगकर्ता सीधे आपके ऐप्लिकेशन से इंटरैक्ट करता है, तो सिस्टम आपके ऐप्लिकेशन को कम पाबंदी वाले बकेट में डाल देता है.

यह देखना कि आपका ऐप्लिकेशन प्रतिबंधित बकेट में है या नहीं

यह देखने के लिए कि सिस्टम ने आपके ऐप्लिकेशन को पाबंदी वाली बकेट में रखा है या नहीं, getAppStandbyBucket() को कॉल करें. अगर इस तरीके की रिटर्न वैल्यू STANDBY_BUCKET_RESTRICTED है, तो इसका मतलब है कि आपका ऐप्लिकेशन पाबंदी वाली बकेट में है.

प्रतिबंधित बकेट के व्यवहार की जांच करें

यह जांचने के लिए कि सिस्टम आपके ऐप्लिकेशन को पाबंदी वाली बकेट में डालने पर, आपका ऐप्लिकेशन कैसे काम करता है, अपने ऐप्लिकेशन को मैन्युअल तरीके से उस बकेट में ले जाएं. ऐसा करने के लिए, टर्मिनल विंडो में यह कमांड चलाएं:

adb shell am set-standby-bucket PACKAGE_NAME restricted

सुरक्षा और निजता

अनुमानित जगह

Android 12 या उसके बाद के वर्शन वाले डिवाइसों पर, उपयोगकर्ता यह अनुरोध कर सकते हैं कि आपके ऐप्लिकेशन के पास सिर्फ़ जगह की अनुमानित जानकारी का ऐक्सेस हो.

अगर आपका ऐप्लिकेशन ACCESS_FINE_LOCATION रनटाइम की अनुमति का अनुरोध करता है, तो आपको ACCESS_COARSE_LOCATION अनुमति का भी अनुरोध करना चाहिए. इससे, उस स्थिति को मैनेज करने में मदद मिलेगी जब उपयोगकर्ता आपके ऐप्लिकेशन को जगह की अनुमानित जानकारी का ऐक्सेस देगा. आपको दोनों अनुमतियों को एक ही रनटाइम अनुरोध में शामिल करना चाहिए.

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

• सटीक: जगह की सटीक जानकारी का ऐक्सेस देता है.
• अनुमानित: यह सिर्फ़ जगह की अनुमानित जानकारी का ऐक्सेस देता है.

माइक्रोफ़ोन और कैमरा टॉगल करने की सुविधा

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

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

माइक्रोफ़ोन और कैमरे के इंडिकेटर

Android 12 या उसके बाद के वर्शन वाले डिवाइसों पर, जब कोई ऐप्लिकेशन माइक्रोफ़ोन या कैमरा ऐक्सेस करता है, तो स्टेटस बार में एक आइकॉन दिखता है.

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

अनुमति वाले पैकेज को किसको दिखाना है

Android 12 या उसके बाद के वर्शन वाले डिवाइसों पर, Android 11 (एपीआई लेवल 30) या उसके बाद के वर्शन को टारगेट करने वाले और इनमें से किसी एक तरीके को कॉल करने वाले ऐप्लिकेशन को, फ़िल्टर किए गए नतीजों का एक सेट मिलता है. यह सेट, दूसरे ऐप्लिकेशन में ऐप्लिकेशन के पैकेज के दिखने के आधार पर तय होता है:

• getAllPermissionGroups()
• getPermissionGroupInfo()
• getPermissionInfo()
• queryPermissionsByGroup()

BouncyCastle लागू करने की सुविधा हटाई गई

Android 12, ऐसे कई BouncyCastle एल्गोरिदम को हटा देता है जिन्हें पहले बंद किया गया था. इनमें सभी एईएस एल्गोरिदम भी शामिल हैं. इसके बजाय, सिस्टम इन एल्गोरिदम के Conscrypt लागू करने का इस्तेमाल करता है.

अगर इनमें से कोई भी बात आपके ऐप्लिकेशन पर लागू होती है, तो इस बदलाव का असर आपके ऐप्लिकेशन पर पड़ेगा:

• आपका ऐप्लिकेशन, 512-बिट की चाबियों का इस्तेमाल करता है. Conscrypt, इस पासकोड साइज़ के साथ काम नहीं करता. अगर ज़रूरी हो, तो अलग-अलग पासकोड साइज़ का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन के क्रिप्टोग्राफ़ी लॉजिक को अपडेट करें.

• आपका ऐप्लिकेशन, KeyGenerator के साथ अमान्य कुंजी साइज़ का इस्तेमाल करता है. Conscrypt में KeyGenerator को लागू करने पर, BouncyCastle की तुलना में मुख्य पैरामीटर की अतिरिक्त पुष्टि की जाती है. उदाहरण के लिए, Conscrypt, आपके ऐप्लिकेशन को 64-बिट एईएस पासकोड जनरेट करने की अनुमति नहीं देता, क्योंकि एईएस सिर्फ़ 128-, 192-, और 256-बिट पासकोड के साथ काम करता है.

  BouncyCastle, अमान्य साइज़ की कुंजियों को जनरेट करने की अनुमति देता है. हालांकि, अगर इन कुंजियों का इस्तेमाल Cipher के साथ किया जाता है, तो बाद में यह काम नहीं करता. जानकारी पहले नहीं दी जा सकी.

• आपने 12 बाइट के बजाय किसी दूसरे साइज़ का इस्तेमाल करके, अपने Galois/Counter Mode (GCM) सिफर को शुरू किया है. Conscrypt में GcmParameterSpec को लागू करने के लिए, 12 बाइट का शुरूआती डेटा होना ज़रूरी है. NIST ने ऐसा करने का सुझाव दिया है.

क्लिपबोर्ड का डेटा ऐक्सेस किए जाने पर सूचनाएं पाना

Android 12 और उसके बाद वाले वर्शन में, जब कोई ऐप्लिकेशन पहली बार getPrimaryClip() किसी दूसरे ऐप्लिकेशन से क्लिप का डेटा ऐक्सेस करने के लिए कॉल करता है, तो टोस्ट मैसेज से उपयोगकर्ता को क्लिपबोर्ड का ऐक्सेस मिलने की सूचना मिलती है.

टोस्ट मैसेज के अंदर के टेक्स्ट का फ़ॉर्मैट इस तरह है: APP pasted from your clipboard.

क्लिप के ब्यौरे में मौजूद टेक्स्ट की जानकारी

Android 12 और उसके बाद के वर्शन पर, getPrimaryClipDescription() इन चीज़ों का पता लगा सकता है:

• isStyledText() का इस्तेमाल करके, स्टाइल किया गया टेक्स्ट.
• getConfidenceScore() का इस्तेमाल करके, टेक्स्ट की अलग-अलग कैटगरी, जैसे कि यूआरएल.

ऐप्लिकेशन, सिस्टम डायलॉग बॉक्स बंद नहीं कर सकते

ऐप्लिकेशन और सिस्टम का इस्तेमाल करते समय उपयोगकर्ता के कंट्रोल को बेहतर बनाने के लिए, Android 12 से ACTION_CLOSE_SYSTEM_DIALOGS इंटेंट कार्रवाई को बंद कर दिया गया है. कुछ खास मामलों को छोड़कर, जब आपका ऐप्लिकेशन इस कार्रवाई वाले इंटेंट को ट्रिगर करने की कोशिश करता है, तो सिस्टम आपके ऐप्लिकेशन के टारगेट किए जा रहे SDK टूल के वर्शन के आधार पर, इनमें से कोई एक काम करता है:

• अगर आपका ऐप्लिकेशन, Android 12 या उसके बाद के वर्शन को टारगेट करता है, तो SecurityException दिखता है.

• अगर आपका ऐप्लिकेशन, Android 11 (एपीआई लेवल 30) या इससे पहले के वर्शन को टारगेट करता है, तो यह इंटेंट लागू नहीं होता है और Logcat में यह मैसेज दिखता है:

  E ActivityTaskManager Permission Denial: \
  android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
  com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
  dropping broadcast.
  

अपवाद

नीचे दिए गए मामलों में, ऐप्लिकेशन अब भी Android 12 या उसके बाद के वर्शन पर सिस्टम डायलॉग बंद कर सकता है:

• आपका ऐप्लिकेशन इंस्ट्रूमेंटेशन जांच कर रहा है.

• आपका ऐप्लिकेशन, Android 11 या उससे पहले के वर्शन को टारगेट करता है और सूचना खींचने वाले बॉक्स के ऊपर एक विंडो दिखा रहा है.

• आपका ऐप्लिकेशन, Android 11 या इससे पहले के वर्शन को टारगेट करता है. इसके अलावा, उपयोगकर्ता ने सूचना के ऐक्शन बटन का इस्तेमाल करके, सूचना के साथ इंटरैक्ट किया है. साथ ही, उपयोगकर्ता की उस कार्रवाई के जवाब में, आपका ऐप्लिकेशन किसी सेवा या ब्रॉडकास्ट रिसीवर को प्रोसेस कर रहा है.

• आपका ऐप्लिकेशन Android 11 या इससे पहले के वर्शन को टारगेट करता है और उसमें कोई चालू सुलभता सेवा मौजूद है. अगर आपका ऐप्लिकेशन Android 12 को टारगेट करता है और आपको सूचना बार बंद करना है, तो इसके बजाय GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE ऐक्सेसबिलिटी ऐक्शन का इस्तेमाल करें.

भरोसेमंद नहीं होने वाले टच इवेंट ब्लॉक किए जाते हैं

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

ऐसे ऐप्लिकेशन की संख्या जिन पर गड़बड़ी का असर पड़ा

इस बदलाव का असर उन ऐप्लिकेशन पर पड़ता है जो अपनी विंडो में टच को पास करने का विकल्प चुनते हैं. उदाहरण के लिए, FLAG_NOT_TOUCHABLE फ़्लैग का इस्तेमाल करके. इस तरह के कई उदाहरण हैं. हालांकि, इनमें ये ही शामिल नहीं हैं:

• ऐसे ओवरले जिनके लिए SYSTEM_ALERT_WINDOW अनुमति की ज़रूरत होती है. जैसे, TYPE_APPLICATION_OVERLAY का इस्तेमाल करने वाली विंडो और FLAG_NOT_TOUCHABLE फ़्लैग का इस्तेमाल करने वाली विंडो.
• FLAG_NOT_TOUCHABLE फ़्लैग का इस्तेमाल करने वाली गतिविधि विंडो.

अपवाद

नीचे दिए गए मामलों में, "पास-थ्रू" टच की अनुमति है:

• आपके ऐप्लिकेशन में इंटरैक्शन. आपका ऐप्लिकेशन ओवरले दिखाता है और ओवरले सिर्फ़ तब दिखता है, जब उपयोगकर्ता आपके ऐप्लिकेशन से इंटरैक्ट कर रहा हो.

• भरोसेमंद विंडो. इन विंडो में ये शामिल हैं (लेकिन इन्हीं तक सीमित नहीं हैं):

  • सुलभता विंडो
  • इनपुट के तरीके का संपादक (IME) विंडो
  • Assistant की विंडो
  भरोसा नहीं किया जाता.

• दिखाई न देने वाली विंडो. विंडो का रूट व्यू, GONE या INVISIBLE है.

• पूरी तरह से पारदर्शी विंडो. विंडो के लिए, alpha प्रॉपर्टी 0.0 है.

• सिस्टम अलर्ट विंडो ज़रूरत के मुताबिक पारदर्शी होनी चाहिए. सिस्टम, सूचना वाली विंडो के सेट को तब पारदर्शी मानता है, जब उन विंडो की कुल ओपैसिटी, टच के लिए सिस्टम की तय की गई ओपैसिटी से कम या उसके बराबर हो. Android 12 में, यह ओपैसिटी डिफ़ॉल्ट रूप से 0.8 होती है.

जब किसी अविश्वसनीय टच को ब्लॉक किया जाता है, तब उसका पता लगाना

अगर सिस्टम किसी टच ऐक्शन को ब्लॉक करता है, तो Logcat यह मैसेज लॉग करता है:

Untrusted touch due to occlusion by PACKAGE_NAME

बदलाव की जांच करना

Android 12 या उसके बाद के वर्शन वाले डिवाइसों पर, असुरक्षित टच डिफ़ॉल्ट रूप से ब्लॉक होते हैं. गैर-भरोसेमंद टच को अनुमति देने के लिए, टर्मिनल विंडो में नीचे दिए गए ADB कमांड को चलाएं:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

व्यवहार को डिफ़ॉल्ट पर वापस लाने के लिए (गैर-भरोसेमंद टच ब्लॉक किए गए हैं), यह निर्देश चलाएं:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

गतिविधि की लाइफ़साइकल

'वापस जाएं' बटन दबाने पर, रूट लॉन्चर की गतिविधियों को अब पूरा नहीं किया जा सकेगा

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

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

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

यह भी ध्यान दें कि आम तौर पर, हमारा सुझाव है कि onBackPressed() को बदलने के बजाय, पसंदीदा बैक नेविगेशन उपलब्ध कराने के लिए, AndroidX Activity API का इस्तेमाल करें. अगर सिस्टम के बैक बटन को दबाने पर कोई कॉम्पोनेंट इंटरसेप्ट नहीं करता है, तो AndroidX Activity API अपने-आप सिस्टम के सही व्यवहार पर स्विच कर जाते हैं.

ग्राफ़िक और इमेज

रीफ़्रेश दर स्विच करने की बेहतर सुविधा

Android 12 में, setFrameRate() का इस्तेमाल करके रीफ़्रेश दर में बदलाव किए जा सकते हैं. इससे कोई फ़र्क़ नहीं पड़ता कि डिसप्ले, नई रीफ़्रेश दर पर आसानी से ट्रांज़िशन कर सकता है या नहीं. ऐसा ट्रांज़िशन प्रोसेस होता है जिसमें स्क्रीन को देखने में कोई रुकावट नहीं आती. जैसे, एक या दो सेकंड के लिए ब्लैक स्क्रीन. पहले, अगर डिसप्ले में आसानी से ट्रांज़िशन नहीं होता था, तो आम तौर पर setFrameRate() को कॉल करने के बाद, वह उसी रीफ़्रेश रेट का इस्तेमाल करता रहता था. getAlternativeRefreshRates() को कॉल करके, यह तय किया जा सकता है कि नए वर्शन पर डेटा रीफ़्रेश करना आसान होगा या नहीं. आम तौर पर, रीफ़्रेश रेट स्विच होने के बाद कॉलबैक onDisplayChanged() को कॉल किया जाता है. हालांकि, बाहर से कनेक्ट किए गए कुछ डिसप्ले के लिए, इसे बिना किसी रुकावट के ट्रांज़िशन के दौरान कॉल किया जाता है.

इसे लागू करने का तरीका यहां बताया गया है:

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

कनेक्टिविटी

Passpoint से जुड़े अपडेट

Android 12 में ये एपीआई जोड़े गए हैं:

• isPasspointTermsAndConditionsSupported(): शर्तें और नियम, Passpoint की एक सुविधा है. इसकी मदद से, नेटवर्क डिप्लॉयमेंट में, असुरक्षित कैप्टिव पोर्टल को सुरक्षित Passpoint नेटवर्क से बदला जा सकता है. कैप्टिव पोर्टल, ओपन नेटवर्क का इस्तेमाल करते हैं. नियम और शर्तें स्वीकार करने के लिए, उपयोगकर्ता को एक सूचना दिखाई जाती है. जिन ऐप्लिकेशन में, शर्तों और नीतियों के हिसाब से सीमित Passpoint नेटवर्क का सुझाव दिया जाता है उन्हें सबसे पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस पर यह सुविधा काम करती है या नहीं. अगर डिवाइस में यह सुविधा काम नहीं करती है, तो वह इस नेटवर्क से कनेक्ट नहीं हो पाएगा. साथ ही, उसे किसी अन्य या लेगसी नेटवर्क से कनेक्ट करने का सुझाव दिया जाएगा.

• isDecoratedIdentitySupported(): प्रीफ़िक्स डेकोरेशन वाले नेटवर्क की पुष्टि करते समय, डेकोरेट की गई पहचान के प्रीफ़िक्स की मदद से नेटवर्क ऑपरेटर, नेटवर्क ऐक्सेस आइडेंटिफ़ायर (एनएआई) को अपडेट कर सकते हैं. इससे, एएए नेटवर्क के अंदर मौजूद कई प्रॉक्सी के ज़रिए साफ़ तौर पर रूटिंग की जा सकती है. इस बारे में ज़्यादा जानने के लिए, आरएफ़सी 7542 देखें.

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

पासपॉइंट का सुझाव देने के लिए, ऐप्लिकेशन को PasspointConfiguration, Credential, और HomeSp क्लास का इस्तेमाल करना होगा. ये क्लास, पासपॉइंट प्रोफ़ाइल के बारे में बताती हैं. इस प्रोफ़ाइल के बारे में Wi-Fi Alliance के पासपॉइंट स्पेसिफ़िकेशन में बताया गया है.

ज़्यादा जानकारी के लिए, इंटरनेट कनेक्टिविटी के लिए वाई-फ़ाई सुझाव एपीआई देखें.

SDK टूल के अलावा किसी दूसरे इंटरफ़ेस के इस्तेमाल से जुड़ी पाबंदियां अपडेट की गईं

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

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

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

Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 12 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट लेख पढ़ें. आम तौर पर, SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर लगी पाबंदियां देखें.