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 के पुराने वर्शन के साथ ज़्यादा बेहतर तरीके से काम करने के लिए, 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"), वे अपने-आप इंसर्ट पोर्ट्रेट मोड में चले जाते हैं. इससे कैमरे की झलक का सही ओरिएंटेशन और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) तय होता है. फ़ोल्ड किए जा सकने वाले डिवाइसों और कैमरे वाले अन्य डिवाइसों पर, कैमरा हार्डवेयर ऐब्स्ट्रैक्शन लेयर (HAL) होती है. इन डिवाइसों पर, कैमरा सेंसर के ओरिएंटेशन की वजह से होने वाले बदलाव को ठीक करने के लिए, कैमरे के आउटपुट में रोटेशन जोड़ा जाता है. साथ ही, कैमरे के आउटपुट को ऐप्लिकेशन के कैमरा प्रीव्यू के आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से मैच करने के लिए काटा जाता है. फ़ोटो को काटा जाता है और उसे घुमाया जाता है, ताकि डिवाइस की ओरिएंटेशन और डिवाइस के मुड़े या खुले होने की स्थिति के बावजूद, कैमरे की झलक सही तरीके से दिखे.
फ़ोरग्राउंड सेवा की सूचनाओं के लिए यूज़र एक्सपीरियंस में देरी
कम समय तक चलने वाली फ़ोरग्राउंड सेवाओं के लिए, डिवाइसों पर बेहतर अनुभव दिया जा सकता है. इसके लिए, Android 12 या इसके बाद के वर्शन पर काम करने वाले डिवाइस, फ़ोरग्राउंड सेवा की सूचनाओं को 10 सेकंड तक दिखाने में देरी कर सकते हैं. हालांकि, कुछ अपवाद हैं. इस बदलाव से, कम समय के लिए किए जाने वाले टास्क को पूरा होने का समय मिल जाता है. इससे पहले कि उनकी सूचनाएं दिखें, वे पूरे हो जाते हैं.
परफ़ॉर्मेंस
ऐप्लिकेशन के स्टैंडबाइ मोड पर पाबंदी वाला बकेट
Android 11 (एपीआई लेवल 30) में, ऐप्लिकेशन स्टैंडबाय बकेट के तौर पर restricted bucket को लॉन्च किया गया था. Android 12 से, यह बकेट डिफ़ॉल्ट रूप से चालू रहता है. पाबंदी वाले बकेट की प्राथमिकता सबसे कम होती है. साथ ही, इसमें सभी बकेट के मुकाबले सबसे ज़्यादा पाबंदियां होती हैं. प्राथमिकता के हिसाब से, ज़्यादा से कम के क्रम में बकेट इस तरह से हैं:
- ऐक्टिव: ऐप्लिकेशन का इस्तेमाल अभी किया जा रहा है या हाल ही में किया गया था.
- वर्किंग सेट: ऐप्लिकेशन का नियमित तौर पर इस्तेमाल किया जा रहा है.
- अक्सर: ऐप्लिकेशन का इस्तेमाल अक्सर किया जाता है, लेकिन हर दिन नहीं.
- कभी-कभी: ऐप्लिकेशन का इस्तेमाल अक्सर नहीं किया जाता.
- पाबंदी लगी है: ऐप्लिकेशन, सिस्टम के ज़्यादा संसाधनों का इस्तेमाल करता है या इससे अवांछित व्यवहार हो सकता है.
सिस्टम, इस्तेमाल के पैटर्न के साथ-साथ आपके ऐप्लिकेशन के व्यवहार को भी ध्यान में रखता है. इससे यह तय किया जाता है कि आपके ऐप्लिकेशन को प्रतिबंधित बकेट में रखा जाए या नहीं.
अगर आपका ऐप्लिकेशन सिस्टम के संसाधनों का ज़्यादा ज़िम्मेदारी से इस्तेमाल करता है, तो उसे पाबंदी वाले बकेट में रखे जाने की संभावना कम हो जाती है. इसके अलावा, अगर उपयोगकर्ता सीधे तौर पर आपके ऐप्लिकेशन से इंटरैक्ट करता है, तो सिस्टम आपके ऐप्लिकेशन को कम पाबंदी वाले बकेट में रखता है.
देखें कि आपका ऐप्लिकेशन, प्रतिबंधित बकेट में है या नहीं
यह देखने के लिए कि सिस्टम ने आपके ऐप्लिकेशन को प्रतिबंधित बकेट में रखा है या नहीं, getAppStandbyBucket() पर कॉल करें.
अगर इस तरीके की रिटर्न वैल्यू STANDBY_BUCKET_RESTRICTED है, तो इसका मतलब है कि आपका ऐप्लिकेशन प्रतिबंधित बकेट में है.
प्रतिबंधित बकेट के व्यवहार की जांच करना
यह जांच करने के लिए कि सिस्टम आपके ऐप्लिकेशन को पाबंदी वाले बकेट में रखने पर, वह कैसे काम करता है, अपने ऐप्लिकेशन को मैन्युअल तरीके से उस बकेट में ले जाएं. इसके लिए, टर्मिनल विंडो में यह कमांड चलाएं:
adb shell am set-standby-bucket PACKAGE_NAME restricted
फ़ोरग्राउंड में जगह की जानकारी और बैटरी सेवर
Android 12 से, बैटरी सेवर चालू होने पर भी फ़ोरग्राउंड में जगह की जानकारी (इसमें फ़ोरग्राउंड सेवा से मिली जानकारी भी शामिल है) मिलती रहेगी. भले ही, स्क्रीन बंद हो.
इससे पहले, बैटरी सेवर मोड चालू होने पर स्क्रीन बंद होने पर जगह की जानकारी अपडेट नहीं होती थी. इस बदलाव से, उपयोगकर्ताओं को बैटरी की लाइफ़ बेहतर मिलती है. इसका मतलब है कि डेवलपर, उपयोगकर्ताओं से बैटरी सेवर मोड बंद करने के लिए नहीं कहेंगे, ताकि जगह की जानकारी के हिसाब से डिलीवरी की जा सके.
फ़ोरग्राउंड सेवा के ज़रिए जगह की जानकारी का अनुरोध करने वाले ऐप्लिकेशन को यह तरीका अपनाना चाहिए:
- बैटरी सेवर मोड चालू होने पर, डिवाइस की जगह की जानकारी देने वाली सुविधाएं कैसे काम करती हैं, यह जानने के लिए
getLocationPowerSaverMode()पर कॉल करें. - अगर यह
LOCATION_MODE_FOREGROUND_ONLYदिखाता है, तो बैटरी सेवर चालू होने और स्क्रीन बंद होने पर भी, आपका ऐप्लिकेशन फ़ोरग्राउंड में या फ़ोरग्राउंड सेवा के तौर पर चलने के दौरान, जगह की जानकारी के अपडेट पाना जारी रखेगा.
सुरक्षा और निजता
अनुमानित जगह
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के साथ अमान्य कुंजी साइज़ का इस्तेमाल करता है. BouncyCastle की तुलना में, ConscryptKeyGeneratorको लागू करने पर, मुख्य पैरामीटर की पुष्टि ज़्यादा बेहतर तरीके से होती है. उदाहरण के लिए, 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 इंटेंट ऐक्शन का इस्तेमाल बंद कर दिया गया है. कुछ खास मामलों को छोड़कर, जब आपका ऐप्लिकेशन इस कार्रवाई वाले इंटेंट को शुरू करने की कोशिश करता है, तो सिस्टम आपके ऐप्लिकेशन के टारगेट किए जा रहे एसडीके के वर्शन के आधार पर इनमें से कोई एक कार्रवाई करता है:
- अगर आपका ऐप्लिकेशन, 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 या इसके बाद के वर्शन वाले डिवाइसों पर, भरोसेमंद नहीं माने जाने वाले टच डिफ़ॉल्ट रूप से ब्लॉक होते हैं. भरोसेमंद नहीं माने जाने वाले टच की अनुमति देने के लिए, टर्मिनल विंडो में यह 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 में, सिस्टम अब ऐक्टिविटी को खत्म करने के बजाय, उसे और उसके टास्क को बैकग्राउंड में ले जाता है. होम बटन या जेस्चर का इस्तेमाल करके किसी ऐप्लिकेशन से बाहर निकलने पर, अब वही तरीका काम करेगा जो पहले काम करता था.
ज़्यादातर ऐप्लिकेशन के लिए, इस बदलाव का मतलब है कि जो उपयोगकर्ता आपके ऐप्लिकेशन से बाहर निकलने के लिए 'वापस जाएं' बटन का इस्तेमाल करते हैं वे वार्म स्टेट से आपके ऐप्लिकेशन को ज़्यादा तेज़ी से फिर से शुरू कर सकते हैं. इसके बजाय, उन्हें ऐप्लिकेशन को कोल्ड स्टेट से पूरी तरह से फिर से शुरू करना होगा.
हमारा सुझाव है कि आप इस बदलाव के साथ अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन फ़िलहाल, onBackPressed() को ओवरराइड करता है, ताकि बैक नेविगेशन को मैनेज किया जा सके और Activity को पूरा किया जा सके, तो अपने लागू करने के तरीके को अपडेट करें. इससे Activity को पूरा करने के बजाय, 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(): प्रीफ़िक्स डेकोरेशन वाले नेटवर्क से पुष्टि करते समय, डेकोरेट किया गया आइडेंटिटी प्रीफ़िक्स, नेटवर्क ऑपरेटर को नेटवर्क ऐक्सेस आइडेंटिफ़ायर (एनएआई) को अपडेट करने की अनुमति देता है. इससे, एएए नेटवर्क में मौजूद कई प्रॉक्सी के ज़रिए साफ़ तौर पर राउटिंग की जा सकती है. इसके बारे में ज़्यादा जानने के लिए, RFC 7542 देखें.Android 12 में इस सुविधा को लागू किया गया है, ताकि यह PPS-MO एक्सटेंशन के लिए WBA स्पेसिफ़िकेशन के मुताबिक काम कर सके. ऐसे ऐप्लिकेशन जो डेकोरेटेड आइडेंटिटी की ज़रूरत वाले Passpoint नेटवर्क का सुझाव देते हैं उन्हें सबसे पहले इस एपीआई को कॉल करना होगा. इससे यह पक्का किया जा सकेगा कि डिवाइस इस सुविधा के साथ काम करता है. अगर डिवाइस पर यह सुविधा काम नहीं करती है, तो पहचान को डेकोरेट नहीं किया जाएगा. साथ ही, नेटवर्क से पुष्टि करने में समस्या आ सकती है.
पासपॉइंट का सुझाव देने के लिए, ऐप्लिकेशन को PasspointConfiguration, Credential, और HomeSp क्लास का इस्तेमाल करना होगा. ये क्लास, Passpoint प्रोफ़ाइल के बारे में बताती हैं. इसे Wi-Fi Alliance Passpoint स्पेसिफ़िकेशन में तय किया गया है.
ज़्यादा जानकारी के लिए, इंटरनेट कनेक्टिविटी के लिए Wi-Fi suggestion API देखें.
ऐसे इंटरफ़ेस के इस्तेमाल से जुड़ी पाबंदियां अपडेट की गई हैं जो SDK टूल में उपलब्ध नहीं है
Android 12 में, पाबंदी वाले नॉन-एसडीके इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं. ये सूचियां, Android डेवलपर के साथ मिलकर काम करने और हाल ही में हुई इंटरनल टेस्टिंग के आधार पर बनाई गई हैं. हम यह पक्का करते हैं कि गैर-एसडीके इंटरफ़ेस को प्रतिबंधित करने से पहले, सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 12 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ नॉन-एसडीके इंटरफ़ेस (आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के हिसाब से) इस्तेमाल किए जा सकते हैं. हालांकि, किसी भी नॉन-एसडीके तरीके या फ़ील्ड का इस्तेमाल करने से, आपके ऐप्लिकेशन के काम न करने का जोखिम हमेशा ज़्यादा होता है.
अगर आपको पक्का नहीं है कि आपका ऐप्लिकेशन, SDK टूल के बाहर के इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो यह पता लगाने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, गैर-एसडीके इंटरफ़ेस पर निर्भर करता है, तो आपको एसडीके के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन के पास, गैर-एसडीके इंटरफ़ेस इस्तेमाल करने के लिए मान्य वजहें होती हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, गैर-एसडीके इंटरफ़ेस के इस्तेमाल का कोई विकल्प नहीं मिल रहा है, तो आपको नया सार्वजनिक एपीआई अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 12 में नॉन-एसडीके इंटरफ़ेस पर लगी पाबंदियों से जुड़े अपडेट लेख पढ़ें. SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर पाबंदियां लेख पढ़ें.