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

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

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

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

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

Android 12 और उसके बाद के वर्शन वाले डिवाइसों पर, ओवरस्क्रोल इवेंट में किए गए बदलावों के हिसाब से.

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

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

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

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

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

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

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

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

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

ऐप्लिकेशन को यह मंज़ूरी देने के लिए, इनमें से कोई एक काम किया जा सकता है:

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

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

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

• उपयोगकर्ता से आपके ऐप्लिकेशन को डोमेन खोलें.

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

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

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

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

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

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

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

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

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

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

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

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

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

किसी भीWindowMetrics यूज़र इंटरफ़ेस (यूआई) से जुड़े काम, खास तौर पर WindowManager.getCurrentWindowMetrics() या Jetpack का WindowMetricsCalculator.computeCurrentWindowMetrics().

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

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

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

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

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

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

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

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

Android 12 में, मल्टी-विंडो मोड का स्टैंडर्ड वर्शन भी बनाया गया है.

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

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

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

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

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

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

फ़ोरग्राउंड सेवा की सूचनाएं मिलने पर, UX में हुई देरी की जानकारी

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

परफ़ॉर्मेंस

प्रतिबंधित ऐप्लिकेशन स्टैंडबाय बकेट

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

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

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

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

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

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

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

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

अनुमानित जगह

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

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

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

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

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

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

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

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

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

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

अनुमति पैकेज किसको दिखे

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

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

BoseCastle को लागू करने की प्रोसेस हटाई गई

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

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

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

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

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

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

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

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

टोस्ट मैसेज के अंदर के टेक्स्ट का फ़ॉर्मैट इस तरह है: APP pasted from your clipboard. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है

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

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

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

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

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

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

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

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

अपवाद

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

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

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

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

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

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

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

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

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

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

अपवाद

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

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

• भरोसेमंद विंडो. इन विंडो में फ़ॉलो किया जा रहा है:

  • सुलभता विंडो
  • इनपुट के तरीके में बदलाव करने वाला टूल (IME) विंडो
  • Assistant की विंडो

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

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

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

गैर-भरोसेमंद टच के ब्लॉक होने पर पता लगाएं

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

Untrusted touch due to occlusion by PACKAGE_NAME

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

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

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

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

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

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

# All apps
adb shell settings put global block_untrusted_touches 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

कनेक्टिविटी

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

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

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

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

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

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

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

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

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

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

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

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