व्यवहार में बदलाव: 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. कस्टम व्यू का इस्तेमाल करने वाली सभी सूचनाओं की जांच करें. इससे यह पक्का किया जा सकेगा कि वे शेड में आपकी उम्मीद के मुताबिक दिखें. टेस्टिंग के दौरान, इन बातों का ध्यान रखें और ज़रूरी बदलाव करें:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

जगह की अनुमानित जानकारी

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

WebView में आधुनिक SameSite कुकी

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

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

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

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

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

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

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

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

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

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

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

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

    इस तरीके का इस्तेमाल करने के लिए, आपके पास Android 12 वाला डिवाइस होना चाहिए.

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

अन्य संसाधन

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

मोशन सेंसर के लिए, अनुरोध संख्या सीमित की गई है

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

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

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

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

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

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

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

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

एडीबी बैकअप पर पाबंदी

ऐप्लिकेशन के निजी डेटा को सुरक्षित रखने के लिए, 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 में मैसेज

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

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

यह पता लगाने के लिए कि आपके ऐप्लिकेशन में, म्यूटेबिलिटी डिक्लेरेशन मौजूद हैं या नहीं, 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() को कॉल नहीं कर सकता.

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

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

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

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

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

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

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

कॉन्फ़िगरेशन को टॉगल करना

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

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

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

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

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

D2D ट्रांसफ़र की सुविधा में बदलाव

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

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

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

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

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.onCapabilitiesChanged() का इस्तेमाल करें. इससे, NetworkCallback को रजिस्टर करने के लिए इस्तेमाल किए गए NetworkRequest से मैच करने वाले सभी WifiInfo ऑब्जेक्ट मिल सकेंगे. 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;
    ...
  }
  ...
};

mDNSResponder नेटिव एपीआई

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

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

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

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

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

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

गैर-एसडीके इंटरफ़ेस से जुड़ी पाबंदियों को अपडेट किया गया

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

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

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

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