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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Display#getRealSize और getRealMetrics: बंद होने की जानकारी और पाबंदियां

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

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

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

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

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

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

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

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

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

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

Kotlin

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

Java

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

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

Kotlin

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

Java

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"), वे अपने-आप इनसेट पोर्ट्रेट मोड में चले जाते हैं. इससे कैमरे की झलक का सही ओरिएंटेशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) पक्का होता है. फ़ोल्ड किए जा सकने वाले डिवाइसों और कैमरे की हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) वाले अन्य डिवाइसों पर, कैमरे के आउटपुट को और घुमाया जाता है. ऐसा कैमरे के सेंसर ओरिएंटेशन की भरपाई करने के लिए किया जाता है. साथ ही, कैमरे के आउटपुट को ऐप्लिकेशन के कैमरे की झलक के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से मैच करने के लिए काटा जाता है. इमेज को काटने और उसे ज़्यादा घुमाने से, कैमरे की झलक सही तरीके से दिखती है. इससे कोई फ़र्क़ नहीं पड़ता कि डिवाइस का ओरिएंटेशन क्या है और डिवाइस फ़ोल्ड है या अनफ़ोल्ड.

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

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

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

फ़ोरग्राउंड सेवा के ज़रिए जगह की जानकारी का अनुरोध करने वाले ऐप्लिकेशन को ये काम करने चाहिए:

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

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

जगह की अनुमानित जानकारी

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

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

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

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

  • सटीक: इससे जगह की सटीक जानकारी का ऐक्सेस मिलता है.
  • Approximate: इससे ऐप्लिकेशन को जगह की अनुमानित जानकारी का ऐक्सेस मिलता है.

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

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

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

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

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

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

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

पैकेज की जानकारी देखने की अनुमति

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

BouncyCastle का इस्तेमाल हटाया गया

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • अगर आपका ऐप्लिकेशन 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 फ़्लैग का इस्तेमाल करती हैं.

अपवाद

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

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

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

  • इनविज़िबल विंडो. विंडो का रूट व्यू GONE या INVISIBLE है.

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

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

यह पता लगाना कि भरोसेमंद न होने की वजह से, टच को कब ब्लॉक किया गया

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

Untrusted touch due to occlusion by PACKAGE_NAME

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

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

# 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() को कॉल किया जा सकेगा. super.onBackPressed() को कॉल करने से, ज़रूरत पड़ने पर गतिविधि और उसके टास्क को बैकग्राउंड में ले जाया जाता है. साथ ही, इससे उपयोगकर्ताओं को सभी ऐप्लिकेशन पर नेविगेशन का बेहतर अनुभव मिलता है.

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

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

रीफ़्रेश रेट स्विच करने की सुविधा को बेहतर बनाया गया है

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

यहां एक उदाहरण दिया गया है कि इसे कैसे लागू किया जा सकता है:

Kotlin

// 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)

Java

// 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);

कनेक्टिविटी

पासपॉइंट से जुड़े अपडेट

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

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

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

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

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

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

गैर-एसडीके इंटरफ़ेस से जुड़ी पाबंदियों को अपडेट किया गया

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

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

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

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