Android 12 प्लैटफ़ॉर्म में, ऐप्लिकेशन के काम करने के तरीके में कुछ बदलाव किए गए हैं. इन बदलावों का असर आपके ऐप्लिकेशन पर पड़ सकता है. ऐप्लिकेशन के काम करने के तरीके में ये बदलाव, Android 12 पर चलने वाले सभी ऐप्लिकेशन पर लागू होते हैं. भले ही, वे targetSdkVersion के हिसाब से हों या नहीं. आपको अपने ऐप्लिकेशन की जांच करनी चाहिए. इसके बाद, ज़रूरत पड़ने पर उसमें बदलाव करना चाहिए, ताकि ये सुविधाएं सही तरीके से काम कर सकें.
उपयोगकर्ता अनुभव
स्ट्रेच ओवरस्क्रोल इफ़ेक्ट
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-बिट पासकोड के साथ काम करता है.BouncyCastle, अमान्य साइज़ की कुंजियों को जनरेट करने की अनुमति देता है. हालांकि, अगर इन कुंजियों का इस्तेमाल
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() 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 की एक सुविधा है. इसकी मदद से, नेटवर्क डिप्लॉयमेंट में, असुरक्षित कैप्टिव पोर्टल को सुरक्षित Passpoint नेटवर्क से बदला जा सकता है. कैप्टिव पोर्टल, ओपन नेटवर्क का इस्तेमाल करते हैं. नियम और शर्तें स्वीकार करने के लिए, उपयोगकर्ता को एक सूचना दिखाई जाती है. जिन ऐप्लिकेशन में, शर्तों और नीतियों के मुताबिक Passpoint नेटवर्क का सुझाव दिया जाता है उन्हें सबसे पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस पर यह सुविधा काम करती है या नहीं. अगर डिवाइस में यह सुविधा काम नहीं करती है, तो वह इस नेटवर्क से कनेक्ट नहीं हो पाएगा. साथ ही, उसे किसी अन्य या लेगसी नेटवर्क से कनेक्ट करने का सुझाव दिया जाएगा.isDecoratedIdentitySupported(): प्रीफ़िक्स डेकोरेशन वाले नेटवर्क की पुष्टि करते समय, डेकोरेट की गई पहचान के प्रीफ़िक्स की मदद से नेटवर्क ऑपरेटर, नेटवर्क ऐक्सेस आइडेंटिफ़ायर (एनएआई) को अपडेट कर सकते हैं. इससे, एएए नेटवर्क के अंदर मौजूद कई प्रॉक्सी के ज़रिए साफ़ तौर पर रूटिंग की जा सकती है. इस बारे में ज़्यादा जानने के लिए, आरएफ़सी 7542 देखें.Android 12 में यह सुविधा, PPS-MO एक्सटेंशन के लिए डब्ल्यूबीए स्पेसिफ़िकेशन का पालन करने के लिए लागू की गई है. जिन ऐप्लिकेशन में ऐसे Passpoint नेटवर्क के सुझाव दिए जाते हैं जिनके लिए डेकोरेट की गई पहचान की ज़रूरत होती है उन्हें सबसे पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस इस सुविधा के साथ काम करता है या नहीं. अगर डिवाइस पर यह सुविधा काम नहीं करती है, तो पहचान को सजा नहीं दिया जाएगा और नेटवर्क की पुष्टि नहीं हो पाएगी.
पासपॉइंट का सुझाव देने के लिए, ऐप्लिकेशन को
PasspointConfiguration,
Credential, और
HomeSp क्लास का इस्तेमाल करना होगा. ये क्लास, पासपॉइंट प्रोफ़ाइल के बारे में बताती हैं. इस प्रोफ़ाइल के बारे में Wi-Fi Alliance के पासपॉइंट स्पेसिफ़िकेशन में बताया गया है.
ज़्यादा जानकारी के लिए, इंटरनेट कनेक्टिविटी के लिए वाई-फ़ाई सुझाव एपीआई देखें.
SDK टूल के अलावा किसी दूसरे इंटरफ़ेस के इस्तेमाल से जुड़ी पाबंदियां अपडेट की गईं
Android 12 में, पाबंदी वाले ऐसे इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं जो एसडीके के दायरे में नहीं आते. ये सूचियां, Android डेवलपर के साथ मिलकर की गई जांच और नई इंटरनल जांच के आधार पर बनाई गई हैं. जब भी मुमकिन हो, हम यह पक्का करते हैं कि SDK टूल के बाहर के इंटरफ़ेस पर पाबंदी लगाने से पहले, सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 12 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ ऐसे इंटरफ़ेस इस्तेमाल किए जा सकते हैं जो SDK टूल के नहीं हैं. यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन का टारगेट एपीआई लेवल क्या है. हालांकि, SDK टूल के अलावा किसी भी दूसरे तरीके या फ़ील्ड का इस्तेमाल करने पर, आपके ऐप्लिकेशन के काम न करने का खतरा हमेशा बना रहता है.
अगर आपको नहीं पता कि आपका ऐप्लिकेशन, SDK टूल के बाहर के इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो इस बारे में जानने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस पर निर्भर करता है, तो आपको SDK टूल के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन में, गैर-SDK इंटरफ़ेस का इस्तेमाल करने के लिए मान्य उदाहरण हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस का इस्तेमाल करने का विकल्प नहीं मिल रहा है, तो आपको नए सार्वजनिक एपीआई का अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 12 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट लेख पढ़ें. आम तौर पर, SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर पाबंदियां देखें.