व्यवहार में बदलाव: Android 12 को टारगेट करने वाले ऐप्लिकेशन

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

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

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

पसंद के मुताबिक सूचनाएं

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

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

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

नीचे दिए गए इलस्ट्रेशन में, स्टैंडर्ड टेंप्लेट में कस्टम सूचना दिखाई गई है:

नीचे दिए गए उदाहरण दिखाते हैं कि कस्टम नोटिफ़िकेशन, छोटा और बड़ा करने की स्थिति में कैसे रेंडर होंगे:

Android 12 में हुए बदलाव का असर उन ऐप्लिकेशन पर पड़ता है जो Notification.Style के कस्टम सबक्लास तय करते हैं या Notification.Builder के तरीकों setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews), और setCustomHeadsUpContentView(RemoteViews) का इस्तेमाल करते हैं.

अगर आपका ऐप्लिकेशन पूरी तरह से कस्टम सूचनाओं का इस्तेमाल कर रहा है, तो हमारा सुझाव है कि आप जल्द से जल्द नए टेंप्लेट के साथ टेस्टिंग करें.

1. कस्टम नोटिफ़िकेशन में बदलाव करने की सुविधा चालू करने के लिए:

   1. नई सुविधा चालू करने के लिए, अपने ऐप्लिकेशन के targetSdkVersion को S में बदलें.
   2. फिर से कंपाइल करें.
   3. Android 12 पर काम करने वाले डिवाइस या एमुलेटर पर अपना ऐप्लिकेशन इंस्टॉल करें.

2. कस्टम व्यू का इस्तेमाल करने वाली सभी सूचनाओं की जांच करें. इससे यह पक्का किया जा सकेगा कि वे शेड में ठीक से दिखें. टेस्टिंग के दौरान, इन बातों का ध्यान रखें और ज़रूरी बदलाव करें:

   • कस्टम व्यू के डाइमेंशन बदल गए हैं. आम तौर पर, कस्टम सूचनाओं की ऊंचाई पहले की तुलना में कम होती है. छोटा किए जाने पर, कस्टम कॉन्टेंट की ज़्यादा से ज़्यादा ऊंचाई 106 डीपी से घटकर 48 डीपी हो गई है. साथ ही, इसमें हॉरिज़ॉन्टल स्पेस भी कम होता है.

   • Android 12 को टारगेट करने वाले ऐप्लिकेशन के लिए, सभी सूचनाएं बड़ी की जा सकती हैं. आम तौर पर, इसका मतलब है कि अगर setCustomContentView का इस्तेमाल किया जा रहा है, तो setBigCustomContentView का भी इस्तेमाल किया जाना चाहिए. इससे यह पक्का किया जा सकता है कि छोटा और बड़ा किया गया स्टेटस एक जैसा हो.

   • "हेड्स अप" स्टेटस को उम्मीद के मुताबिक दिखाने के लिए, सूचना चैनल की प्राथमिकता को "ज़्यादा" (स्क्रीन पर पॉप-अप) पर सेट करना न भूलें.

Android ऐप्लिकेशन के लिंक की पुष्टि करने के तरीके में बदलाव

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

अगर आप अपने ऐप्लिकेशन में वेब लिंक खोलने के लिए, Android ऐप्लिकेशन के लिंक की पुष्टि पर भरोसा करते हैं, तो देखें कि Android ऐप्लिकेशन लिंक की पुष्टि के लिए, इंटेंट फ़िल्टर जोड़ते समय सही फ़ॉर्मैट का इस्तेमाल किया जा रहा हो. खास तौर पर, पक्का करें कि इन इंटेंट फ़िल्टर में BROWSABLE कैटगरी शामिल हो और वे https स्कीम के साथ काम करती हों.

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

'पिक्चर में पिक्चर' मोड के काम करने के तरीके में सुधार

Android 12 में, पिक्चर में पिक्चर (PiP) मोड के काम करने के तरीके को बेहतर बनाया गया है. साथ ही, जेस्चर नेविगेशन और एलिमेंट पर आधारित नेविगेशन, दोनों के लिए ट्रांज़िशन ऐनिमेशन को बेहतर बनाने के सुझाव दिए गए हैं.

ज़्यादा जानकारी के लिए, पिक्चर में पिक्चर मोड में हुए सुधार देखें.

टोस्ट को फिर से डिज़ाइन करना

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

ज़्यादा जानकारी के लिए, टोस्ट की खास जानकारी देखें.

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

अनुमानित जगह

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

वेबव्यू में आधुनिक SameSite कुकी

Android का वेबव्यू घटक Chromium पर आधारित है, जो Google के Chrome ब्राउज़र को चलाने वाला ओपन सोर्स प्रोजेक्ट है. Chromium ने तीसरे पक्ष की कुकी को मैनेज करने के तरीके में बदलाव किए हैं. इससे उपयोगकर्ताओं को ज़्यादा सुरक्षा और निजता मिलेगी. साथ ही, उन्हें ज़्यादा पारदर्शिता और कंट्रोल भी मिलेगा. Android 12 से, ऐप्लिकेशन के टारगेट किए गए वर्शन के तौर पर Android 12 (एपीआई लेवल 31) या उसके बाद के वर्शन का इस्तेमाल करने पर, ये बदलाव WebView में भी शामिल हो जाएंगे.

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

• जिन कुकी में SameSite एट्रिब्यूट नहीं होता है उन्हें SameSite=Lax के तौर पर माना जाता है.
• SameSite=None एट्रिब्यूट वाली कुकी के लिए, Secure एट्रिब्यूट की जानकारी भी देनी होगी. इसका मतलब है कि उन्हें सुरक्षित कॉन्टेक्स्ट की ज़रूरत होती है और उन्हें एचटीटीपीएस से भेजा जाना चाहिए.
• किसी साइट के एचटीटीपी और एचटीटीपीएस वर्शन के बीच के लिंक को अब क्रॉस-साइट अनुरोध माना जाता है. इसलिए, कुकी तब तक नहीं भेजी जाती, जब तक कि उन्हें सही तरीके से SameSite=None; Secure के तौर पर मार्क न किया गया हो.

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

इन बदलावों के बारे में वेब डेवलपर को पूरी जानकारी देने के लिए, SameSite कुकी की व्याख्या और Schemeful SameSite लेख पढ़ें.

अपने ऐप्लिकेशन में SameSite कुकी के व्यवहार की जांच करना

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

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

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

• वेबव्यू डेवलपर टूल में, यूज़र इंटरफ़ेस (यूआई) फ़्लैग को टॉगल करके, टेस्ट डिवाइस पर SameSite व्यवहार को मैन्युअल तरीके से चालू करें. इसके लिए, webview-enable-modern-cookie-same-site को टॉगल करें.

  इस तरीके से, Android 5.0 (एपीआई लेवल 21) या इसके बाद के वर्शन पर चलने वाले किसी भी डिवाइस पर टेस्ट किया जा सकता है. इसमें Android 12 और वेबव्यू का 89.0.4385.0 या इसके बाद का वर्शन शामिल है.

• targetSdkVersion तक, अपने ऐप्लिकेशन को Android 12 (एपीआई लेवल 31) को टारगेट करने के लिए कंपाइल करें.

  अगर यह तरीका अपनाया जाता है, तो आपको ऐसा डिवाइस इस्तेमाल करना होगा जिसमें Android 12 चलता हो.

Android पर वेबव्यू को रिमोट तरीके से डीबग करने के बारे में जानने के लिए, Android डिवाइसों को रिमोट तरीके से डीबग करना लेख पढ़ें.

अन्य संसाधन

SameSite के आधुनिक व्यवहार और Chrome और वेबव्यू पर रोल आउट के बारे में ज़्यादा जानने के लिए, Chromium के SameSite से जुड़े अपडेट पेज पर जाएं. अगर आपको वेबव्यू या Chromium में कोई गड़बड़ी मिलती है, तो सार्वजनिक Chromium से जुड़ी समस्या को ट्रैक करने वाले टूल में उसकी शिकायत की जा सकती है.

मोशन सेंसर की दर सीमित होती है

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

सेंसर चुनने की दर सीमित करने के बारे में ज़्यादा जानें.

ऐप्लिकेशन का हाइबरनेशन मोड

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

ज़्यादा जानकारी के लिए, ऐप्लिकेशन के हाइबरनेशन की गाइड में जाएं.

डेटा ऐक्सेस के ऑडिट में एट्रिब्यूशन का एलान

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

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

ADB बैकअप प्रतिबंध

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

अगर आपके टेस्टिंग या डेवलपमेंट वर्कफ़्लो, adb backup का इस्तेमाल करके ऐप्लिकेशन डेटा पर निर्भर हैं, तो अब अपने ऐप्लिकेशन के डेटा को एक्सपोर्ट करने के लिए ऑप्ट इन किया जा सकता है. इसके लिए, आपको अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में android:debuggable को true पर सेट करना होगा.

कॉम्पोनेंट को ज़्यादा सुरक्षित तरीके से एक्सपोर्ट करना

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

अगर ऐप्लिकेशन कॉम्पोनेंट में LAUNCHER कैटगरी शामिल है, तो android:exported को true पर सेट करें. ज़्यादातर अन्य मामलों में, android:exported को false पर सेट करें.

नीचे दिया गया कोड स्निपेट, ऐसी सेवा का उदाहरण दिखाता है जिसमें एक इंटेंट फ़िल्टर है. इसका android:exported एट्रिब्यूट, false पर सेट है:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Android Studio में Messages

अगर आपके ऐप्लिकेशन में कोई ऐसी गतिविधि, सेवा या ब्रॉडकास्ट रिसीवर है जो इंटेंट फ़िल्टर का इस्तेमाल करता है, लेकिन android:exported का एलान नहीं करता है, तो Android Studio के इस्तेमाल किए जा रहे वर्शन के आधार पर, चेतावनी के ये मैसेज दिखते हैं:

Android Studio 2020.3.1 कैनरी 11 या इसके बाद वाला वर्शन

आपको ये मैसेज दिखेंगे:

1. आपकी मेनिफ़ेस्ट फ़ाइल में, लिंट से जुड़ी यह चेतावनी दिखती है:

   When using intent filters, please specify android:exported as well
   

2. ऐप्लिकेशन को कंपाइल करने पर, आपको गड़बड़ी का यह मैसेज दिखता है:

   Manifest merger failed : Apps targeting Android 12 and higher are required \
   to specify an explicit value for android:exported when the corresponding \
   component has an intent filter defined.
   

Android Studio के पुराने वर्शन

अगर ऐप्लिकेशन इंस्टॉल करने की कोशिश की जाती है, तो Logcat आपको गड़बड़ी का यह मैसेज दिखाता है:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

PendingIntent की म्यूटेबिलिटी

अगर आपका ऐप्लिकेशन Android 12 को टारगेट करता है, तो आपको अपने ऐप्लिकेशन के बनाए गए हर PendingIntent ऑब्जेक्ट के लिए, म्यूटेबिलिटी की जानकारी देनी होगी. इस अतिरिक्त ज़रूरी शर्त से, आपके ऐप्लिकेशन की सुरक्षा बेहतर होती है.

PendingIntent की म्यूटेबिलिटी में हुए बदलाव की जांच करना

यह पता लगाने के लिए कि आपके ऐप्लिकेशन में, डेटा में बदलाव करने की अनुमति देने वाले एलान मौजूद हैं या नहीं, Android Studio में यह लिंट चेतावनी देखें:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

असुरक्षित इंटेंट लॉन्च

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

परफ़ॉर्मेंस

फ़ोरग्राउंड सेवा के लॉन्च से जुड़ी पाबंदियां

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

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

एग्ज़ैक्ट अलार्म के लिए अनुमति

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

ऐप्लिकेशन का यह खास ऐक्सेस पाने के लिए, मेनिफ़ेस्ट में SCHEDULE_EXACT_ALARM अनुमति का अनुरोध करें.

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

व्यवहार में बदलाव करने की सुविधा बंद करना

Android 12 को टारगेट करने के लिए, अपने ऐप्लिकेशन को तैयार करते समय, जांच के मकसद से, डिबग किए जा सकने वाले बिल्ड वैरिएंट में व्यवहार में हुए बदलाव को कुछ समय के लिए बंद किया जा सकता है. ऐसा करने के लिए, यहां दिए गए टास्क में से कोई एक पूरा करें:

• डेवलपर के विकल्प सेटिंग स्क्रीन में, ऐप्लिकेशन के साथ काम करने की सुविधा में हुए बदलाव को चुनें. स्क्रीन पर दिख रही स्क्रीन पर, अपने ऐप्लिकेशन के नाम पर टैप करें. इसके बाद, REQUIRE_EXACT_ALARM_PERMISSION को बंद करें.

• अपनी डेवलपमेंट मशीन पर टर्मिनल विंडो में, यह कमांड चलाएं:

  adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
  

सूचना ट्रैंपोलिन से जुड़ी पाबंदियां

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

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

जब आपका ऐप्लिकेशन, सूचना ट्रैंपोलिन की तरह काम करने वाली किसी सेवा या ब्रॉडकास्ट रिसीवर की

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

यह पता लगाना कि ऐप्लिकेशन के कौनसे कॉम्पोनेंट, सूचना ट्रैंपोलिन के तौर पर काम करते हैं

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

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

आउटपुट के एक सेक्शन में "NotifDialogLog" टेक्स्ट शामिल होता है. इस सेक्शन में, सूचना पर टैप करने पर शुरू होने वाले कॉम्पोनेंट की पहचान करने के लिए ज़रूरी जानकारी होती है.

अपना ऐप्लिकेशन अपडेट करें

अगर आपका ऐप्लिकेशन, सूचना ट्रैंपोलिन के तौर पर काम करने वाली किसी सेवा या ब्रॉडकास्ट रिसीवर की गतिविधि शुरू करता है, तो माइग्रेशन के इन चरणों को पूरा करें:

1. एक ऐसा PendingIntent ऑब्जेक्ट बनाएं जो सूचना पर टैप करने के बाद, उपयोगकर्ताओं को दिखने वाली गतिविधि से जुड़ा हो.
2. सूचना बनाने के लिए, पिछले चरण में बनाए गए PendingIntent ऑब्जेक्ट का इस्तेमाल करें.

गतिविधि के शुरुआत की जगह की पहचान करने के लिए, उदाहरण के लिए लॉग करने के लिए, सूचना पोस्ट करते समय अतिरिक्त चीज़ों का इस्तेमाल करें. एक ही जगह पर लॉग इकट्ठा करने के लिए, ActivityLifecycleCallbacks या Jetpack लाइफ़साइकल ऑब्ज़र्वर का इस्तेमाल करें.

टॉगल करने का तरीका

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

बैकअप और पहले जैसा करने की सुविधा

Android 12 (एपीआई लेवल 31) पर काम करने वाले और उसे टारगेट करने वाले ऐप्लिकेशन में, बैकअप लेने और उसे वापस लाने के तरीके में बदलाव किए गए हैं. Android पर डेटा का बैकअप लेने और उसे वापस पाने की सुविधा के दो तरीके हैं:

• क्लाउड बैकअप: उपयोगकर्ता का डेटा, उसके Google Drive में सेव किया जाता है, ताकि बाद में उसे उस डिवाइस या किसी नए डिवाइस पर वापस लाया जा सके.
• एक डिवाइस से दूसरे डिवाइस (D2D) पर डेटा ट्रांसफ़र करना: उपयोगकर्ता के डेटा को सीधे उसके पुराने डिवाइस से नए डिवाइस पर भेजा जाता है. जैसे, केबल का इस्तेमाल करके.

डेटा का बैक अप लेने और उसे वापस लाने के तरीके के बारे में ज़्यादा जानने के लिए, ऑटो बैकअप की मदद से उपयोगकर्ता के डेटा का बैक अप लें और Android Backup Service की मदद से, कुंजी-वैल्यू पेयर का बैक अप लें लेख पढ़ें.

D2D ट्रांसफ़र फ़ंक्शन में बदलाव

Android 12 और उसके बाद के वर्शन पर चलने वाले और उन्हें टारगेट करने वाले ऐप्लिकेशन के लिए:

• एक्सएमएल कॉन्फ़िगरेशन के तरीके से, शामिल और बाहर रखने के नियमों को तय करने से, डिवाइस-से-डिवाइस ट्रांसफ़र पर कोई असर नहीं पड़ता. हालांकि, इसका असर अब भी क्लाउड पर आधारित बैकअप और रिस्टोर पर पड़ता है. जैसे, Google Drive बैकअप. डिवाइस से डिवाइस पर डेटा ट्रांसफ़र करने के लिए नियम तय करने के लिए, आपको अगले सेक्शन में बताए गए नए कॉन्फ़िगरेशन का इस्तेमाल करना होगा.

• डिवाइस बनाने वाली कुछ कंपनियों के डिवाइसों पर, android:allowBackup="false" का इस्तेमाल करने से Google Drive में बैकअप लेने की सुविधा बंद हो जाती है. हालांकि, ऐप्लिकेशन के लिए डिवाइस से डिवाइस पर डेटा ट्रांसफ़र करने की सुविधा बंद नहीं होती.

शामिल करने और बाहर रखने का नया फ़ॉर्मैट

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

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

एक्सएमएल फ़ॉर्मैट में बदलाव

Android 11 और उससे पहले के वर्शन में, बैकअप और डेटा वापस पाने की सुविधा के कॉन्फ़िगरेशन के लिए, इस फ़ॉर्मैट का इस्तेमाल किया जाता है:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

नीचे दिए गए फ़ॉर्मैट में, बदलावों को बोल्ड में दिखाया गया है.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

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

ऐप्लिकेशन के लिए मेनिफ़ेस्ट फ़्लैग

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

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

कनेक्टिविटी

ब्लूटूथ की अनुमतियां

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

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

एक साथ पीयर-टू-पीयर और इंटरनेट कनेक्शन

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

इनके साथ काम करता है

WifiManager.getConnectionInfo() सिर्फ़ एक नेटवर्क के लिए WifiInfo दिखा सकता है. इस वजह से, Android 12 और उसके बाद के वर्शन में, एपीआई के काम करने के तरीके में ये बदलाव किए गए हैं:

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

एक साथ दो वाई-फ़ाई नेटवर्क का इस्तेमाल करने की सुविधा वाले डिवाइसों पर बेहतर उपयोगकर्ता अनुभव देने के लिए, हमारा सुझाव है कि सभी ऐप्लिकेशन, कॉल करने के लिए WifiManager.getConnectionInfo() का इस्तेमाल करना बंद कर दें. खास तौर पर, वे ऐप्लिकेशन जो पीयर-टू-पीयर कनेक्शन को ट्रिगर करते हैं. इसके बजाय, NetworkCallback को रजिस्टर करने के लिए इस्तेमाल किए गए NetworkRequest से मैच करने वाले सभी WifiInfo ऑब्जेक्ट पाने के लिए, NetworkCallback.onCapabilitiesChanged() का इस्तेमाल करें. Android 12 के बाद से, getConnectionInfo() का इस्तेमाल नहीं किया जा सकता.

नीचे दिए गए कोड सैंपल में, NetworkCallback में WifiInfo पाने का तरीका बताया गया है:

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

m DNSResponseer नेटिव एपीआई

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

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

वेंडर लाइब्रेरी

वेंडर से मिली नेटिव शेयर की गई लाइब्रेरी

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

अगर ऐप्लिकेशन, Android 11 (एपीआई लेवल 30) या इससे पहले के वर्शन को टारगेट कर रहा है, तो <uses-native-library> टैग की ज़रूरत नहीं है. ऐसे में, शेयर की गई किसी भी नेटिव लाइब्रेरी को ऐक्सेस किया जा सकता है. भले ही, वह NDK लाइब्रेरी हो.

SDK टूल के अलावा अन्य चीज़ों पर लगी पाबंदियां अपडेट की गईं

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

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

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

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