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

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

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

'पिक्चर में पिक्चर' सुविधा में सुधार

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

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

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

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

Android डिवाइस की इमेज, जिसमें किसी ऐप्लिकेशन आइकॉन के बगल में 'मैसेज भेजा जा रहा है' पॉप-अप दिख रहा है

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

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

अनुमानित जगह

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 व्यवहार को चालू करना होगा, जिसे टेस्ट करना है. इसके लिए, आपको इनमें से कोई एक तरीका अपनाना होगा:

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

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

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

    इस तरीके का इस्तेमाल करने के लिए, आपके पास 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 Canary 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'

बचे हुए इंटेंट म्यूटेबिलिटी

अगर आपका ऐप्लिकेशन 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 में बैकअप लेने की सुविधा बंद हो जाती है. हालांकि, ऐप्लिकेशन के लिए D2D ट्रांसफ़र की सुविधा बंद नहीं होती.

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

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

इसके अलावा, बैकअप लेने से जुड़े नियम तय करने के लिए भी इसका इस्तेमाल किया जा सकता है. ऐसे में, 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 पाने का तरीका बताया गया है:

Kotlin

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
    ...
  }
}

Java

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

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

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

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

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

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

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

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

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

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

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