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 को लॉन्च किया और इन तरीकों को बंद कर दिया:
हम Android 12 में, WindowMetrics का इस्तेमाल करने के सुझाव लगातार देते रहेंगे. साथ ही, अब इन तरीकों को बंद कर दिया जाएगा:
ऐप्लिकेशन के बॉउंड को वापस पाने के लिए, डिसप्ले एपीआई का इस्तेमाल करने वाले ऐप्लिकेशन के व्यवहार को कम करने के लिए, Android 12 उन ऐप्लिकेशन के लिए एपीआई से मिली वैल्यू पर पाबंदी लगाता है जिनका साइज़ पूरी तरह से बदला नहीं जा सकता. इससे उन ऐप्लिकेशन पर असर पड़ सकता है जो MediaProjection के साथ इस जानकारी का इस्तेमाल कर रहे हैं.
ऐप्लिकेशन को अपनी विंडो की सीमाओं के बारे में जानकारी पाने के लिए, WindowMetrics एपीआई का इस्तेमाल करना चाहिए. साथ ही, मौजूदा डेंसिटी के बारे में जानकारी पाने के लिए, Configuration.densityDpi का इस्तेमाल करना चाहिए.
Android के पुराने वर्शन के साथ काम करने के लिए, आपके पास WindowManager Jetpack लाइब्रेरी का इस्तेमाल करने का विकल्प है. इसमें एक 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"), अपने-आप इनसेट पोर्ट्रेट मोड में चले जाते हैं. इससे, कैमरे की झलक का सही ओरिएंटेशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) तय होता है. फ़ोल्ड किए जा सकने वाले डिवाइसों और उन अन्य डिवाइसों पर जिनमें कैमरा हार्डवेयर एब्स्ट्रैक्शन लेयर (HAL) है, कैमरे के सेंसर के ओरिएंटेशन को ठीक करने के लिए, कैमरे के आउटपुट में अतिरिक्त रोटेशन लागू किया जाता है. साथ ही, ऐप्लिकेशन के कैमरे की झलक के आसपेक्ट रेशियो से मैच करने के लिए, कैमरे के आउटपुट को काटा जाता है. काट-छांट और ज़्यादा रोटेशन की सुविधा से, कैमरे की झलक को सही तरीके से दिखाया जा सकता है. भले ही, डिवाइस का ओरिएंटेशन और डिवाइस के फ़ोल्ड किए गए या अनफ़ोल्ड किए गए होने से कोई फ़र्क़ न पड़े.
फ़ोरग्राउंड सेवा की सूचनाओं के लिए यूज़र एक्सपीरियंस में देरी
कुछ समय के लिए चलने वाली फ़ोरग्राउंड सेवाओं के लिए बेहतर अनुभव देने के लिए, Android 12 या इसके बाद के वर्शन वाले डिवाइसों पर, फ़ोरग्राउंड सेवा की सूचनाएं 10 सेकंड देर से दिख सकती हैं. हालांकि, कुछ मामलों में ऐसा नहीं होता. इस बदलाव की वजह से, कम समय वाले टास्क की सूचनाएं दिखने से पहले ही उन्हें पूरा किया जा सकता है.
परफ़ॉर्मेंस
पाबंदी वाले ऐप्लिकेशन का स्टैंडबाइ बकेट
Android 11 (एपीआई लेवल 30) में, ऐप्लिकेशन स्टैंडबाय बकेट के तौर पर प्रतिबंधित बकेट की सुविधा जोड़ी गई है. Android 12 में, यह बकेट डिफ़ॉल्ट रूप से चालू रहती है. पाबंदी वाली बकेट की प्राथमिकता सभी बकेट में सबसे कम होती है. साथ ही, उस पर सबसे ज़्यादा पाबंदियां होती हैं. प्राथमिकता के हिसाब से, बकेट की सूची इस तरह से है:
- ऐक्टिव: फ़िलहाल, ऐप्लिकेशन का इस्तेमाल किया जा रहा है या इसे हाल ही में इस्तेमाल किया गया है.
- वर्किंग सेट: ऐप्लिकेशन का इस्तेमाल नियमित तौर पर किया जा रहा है.
- अक्सर इस्तेमाल किए जाने वाले ऐप्लिकेशन: ऐप्लिकेशन का इस्तेमाल अक्सर किया जाता है, लेकिन हर दिन नहीं.
- खास: ऐप्लिकेशन का इस्तेमाल कम ही किया जाता है.
- पाबंदी वाला: ऐप्लिकेशन, सिस्टम के संसाधनों का बहुत ज़्यादा इस्तेमाल करता है या ऐसा व्यवहार कर सकता है जो आपके काम का न हो.
सिस्टम, इस्तेमाल के पैटर्न के साथ-साथ आपके ऐप्लिकेशन के व्यवहार को भी ध्यान में रखता है. इससे यह तय किया जाता है कि आपके ऐप्लिकेशन को पाबंदी वाली बकेट में रखा जाए या नहीं.
अगर आपका ऐप्लिकेशन, सिस्टम से जुड़े संसाधनों का ज़्यादा ज़िम्मेदारी से इस्तेमाल करता है, तो हो सकता है कि आपके ऐप्लिकेशन को प्रतिबंधित बकेट में न रखा जाए. अगर उपयोगकर्ता सीधे आपके ऐप्लिकेशन से इंटरैक्ट करता है, तो सिस्टम आपके ऐप्लिकेशन को कम पाबंदी वाली बकेट में डाल देता है.
देखें कि आपका ऐप्लिकेशन, पाबंदी वाली बकेट में है या नहीं
यह देखने के लिए कि सिस्टम ने आपके ऐप्लिकेशन को पाबंदी वाली बकेट में रखा है या नहीं, 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) या उसके बाद के वर्शन को टारगेट करने वाले और इनमें से किसी एक तरीके को कॉल करने वाले ऐप्लिकेशन को नतीजों का फ़िल्टर किया गया सेट मिलता है. यह इस आधार पर तय होता है कि अन्य ऐप्लिकेशन पर, ऐप्लिकेशन पैकेज किसको दिखे:
BouncyCastle लागू करने की सुविधा हटाई गई
Android 12 में, क्रिप्टोग्राफ़िक एल्गोरिदम के लिए BouncyCastle के कई ऐसे लागू किए गए वर्शन हटा दिए गए हैं जिन्हें पहले बंद कर दिया गया था. इनमें सभी AES एल्गोरिदम भी शामिल हैं. इसके बजाय, सिस्टम इन एल्गोरिदम के लागू किए गए Conscrypt का इस्तेमाल करता है.
अगर इनमें से कोई भी बात आपके ऐप्लिकेशन पर लागू होती है, तो इस बदलाव का असर आपके ऐप्लिकेशन पर पड़ेगा:
- आपका ऐप्लिकेशन, 512-बिट की चाबियों का इस्तेमाल करता है. Conscrypt इस कुंजी के आकार का समर्थन नहीं करता. अगर ज़रूरी हो, तो अपने ऐप्लिकेशन के क्रिप्टोग्राफ़ी लॉजिक को अपडेट करें, ताकि अलग-अलग साइज़ के कुंजी का इस्तेमाल किया जा सके.
आपका ऐप्लिकेशन,
KeyGeneratorके साथ अमान्य कुंजी साइज़ का इस्तेमाल करता है. Conscrypt मेंKeyGeneratorको लागू करने पर, BouncyCastle की तुलना में मुख्य पैरामीटर की अतिरिक्त पुष्टि की जाती है. उदाहरण के लिए, Conscrypt, आपके ऐप्लिकेशन को 64-बिट एईएस पासकोड जनरेट करने की अनुमति नहीं देता, क्योंकि एईएस सिर्फ़ 128-, 192-, और 256-बिट पासकोड के साथ काम करता है.BoncyCastle, अमान्य साइज़ की कुंजियों को जनरेट करने की अनुमति देता है. हालांकि, बाद में ऐसा तब नहीं होता, जब इन कुंजियों को
Cipherके साथ इस्तेमाल किया गया हो. Conscrypt पहले ही काम नहीं करता.आपने 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 Intent ऐक्शन का इस्तेमाल नहीं किया जा सकता. कुछ खास मामलों को छोड़कर, जब आपका ऐप्लिकेशन इस कार्रवाई वाले इंटेंट को ट्रिगर करने की कोशिश करता है, तो सिस्टम आपके ऐप्लिकेशन के टारगेट किए जा रहे 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फ़्लैग का इस्तेमाल करने वाली गतिविधि विंडो.
अपवाद
इन मामलों में, "पास-थ्रू" टच की अनुमति है:
- आपके ऐप्लिकेशन में होने वाले इंटरैक्शन. आपका ऐप्लिकेशन, ओवरले दिखाता है और ओवरले सिर्फ़ तब दिखता है, जब उपयोगकर्ता आपके ऐप्लिकेशन के साथ इंटरैक्ट कर रहा हो.
भरोसेमंद विंडो. इन विंडो में ये शामिल हैं, लेकिन इनमें और भी विंडो हो सकती हैं:
भरोसा नहीं किया जाता.पूरी तरह से पारदर्शी विंडो. विंडो के लिए,
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() को कॉल किया जाता है. हालांकि, बाहर से कनेक्ट किए गए कुछ डिसप्ले के लिए, इसे बिना किसी रुकावट के ट्रांज़िशन के दौरान कॉल किया जाता है.
इसे लागू करने का तरीका यहां बताया गया है:
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);
कनेक्टिविटी
Passpoint से जुड़े अपडेट
Android 12 में ये एपीआई जोड़े गए हैं:
isPasspointTermsAndConditionsSupported(): नियम और शर्तें एक पासपॉइंट की सुविधा है. इसकी मदद से, नेटवर्क डिप्लॉयमेंट की मदद से असुरक्षित कैप्टिव पोर्टल को सुरक्षित पासपॉइंट नेटवर्क से बदला जा सकता है. इन पोर्टल में ओपन नेटवर्क इस्तेमाल किए जाते हैं. नियम और शर्तें स्वीकार करने के लिए, उपयोगकर्ता को एक सूचना दिखाई जाती है. जिन ऐप्लिकेशन में, शर्तों और नीतियों के हिसाब से सीमित Passpoint नेटवर्क का सुझाव दिया जाता है उन्हें सबसे पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस पर यह सुविधा काम करती है या नहीं. अगर डिवाइस पर यह सुविधा काम नहीं करती है, तो यह इस नेटवर्क से कनेक्ट नहीं हो पाएगा. साथ ही, आपको किसी दूसरे या लेगसी नेटवर्क का सुझाव देना चाहिए.isDecoratedIdentitySupported(): प्रीफ़िक्स डेकोरेशन वाले नेटवर्क की पुष्टि करते समय, डेकोरेट की गई पहचान के प्रीफ़िक्स की मदद से नेटवर्क ऑपरेटर, नेटवर्क ऐक्सेस आइडेंटिफ़ायर (एनएआई) को अपडेट कर सकते हैं. इससे, एएए नेटवर्क के अंदर मौजूद कई प्रॉक्सी के ज़रिए साफ़ तौर पर रूटिंग की जा सकती है. इस बारे में ज़्यादा जानने के लिए, आरएफ़सी 7542 देखें.Android 12 में यह सुविधा, PPS-MO एक्सटेंशन के लिए डब्ल्यूबीए स्पेसिफ़िकेशन का पालन करने के लिए लागू की गई है. जो ऐप्लिकेशन ऐसे पासपॉइंट नेटवर्क का सुझाव देते हैं जिन्हें सजी हुई पहचान की ज़रूरत होती है, उन्हें पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस उनके साथ काम करता है. अगर डिवाइस पर यह सुविधा काम नहीं करती है, तो पहचान को सजाने की सुविधा काम नहीं करेगी. साथ ही, नेटवर्क की पुष्टि नहीं हो पाएगी.
पासपॉइंट का सुझाव बनाने के लिए, ऐप्लिकेशन को PasspointConfiguration, Credential, और HomeSp क्लास का इस्तेमाल करना होगा. ये क्लास, पासपॉइंट प्रोफ़ाइल के बारे में बताती हैं. इस प्रोफ़ाइल के बारे में Wi-Fi Alliance के पासपॉइंट स्पेसिफ़िकेशन में बताया गया है.
ज़्यादा जानकारी के लिए, इंटरनेट कनेक्टिविटी के लिए वाई-फ़ाई सुझाव एपीआई देखें.
SDK टूल के अलावा किसी दूसरे इंटरफ़ेस के इस्तेमाल से जुड़ी पाबंदियां अपडेट की गईं
Android 12 में, बिना SDK टूल वाले प्रतिबंधित इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं. ये सूचियां Android डेवलपर के साथ मिलकर काम करने और नई इंटरनल टेस्टिंग के आधार पर हैं. जब भी मुमकिन हो, हम यह पक्का करते हैं कि बिना SDK टूल वाले इंटरफ़ेस पर पाबंदी लगाने से पहले, हम यह पक्का करते हैं कि सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 12 को टारगेट नहीं करता है, तो शायद इनमें से कुछ बदलावों का आप पर तुरंत असर न पड़े. हालांकि, फ़िलहाल कुछ ऐसे इंटरफ़ेस इस्तेमाल किए जा सकते हैं जो SDK टूल के नहीं हैं. यह आपके ऐप्लिकेशन के टारगेट एपीआई लेवल पर निर्भर करता है. हालांकि, SDK टूल के अलावा किसी भी तरीके या फ़ील्ड का इस्तेमाल करने पर, आपके ऐप्लिकेशन के काम न करने का खतरा हमेशा बना रहता है.
अगर आपको नहीं पता कि आपका ऐप्लिकेशन ऐसे इंटरफ़ेस पर है या नहीं जिनमें SDK टूल मौजूद नहीं है, तो यह पता लगाने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस पर निर्भर करता है, तो आपको SDK टूल के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन में, गैर-एसडीके इंटरफ़ेस का इस्तेमाल करने के लिए मान्य उदाहरण हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, बिना SDK टूल वाले इंटरफ़ेस का इस्तेमाल करने का विकल्प नहीं मिलता है, तो आपको नए सार्वजनिक एपीआई का अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 12 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट लेख पढ़ें. बिना SDK टूल वाले इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के अलावा अन्य इंटरफ़ेस पर लगने वाली पाबंदियां देखें.