व्यवहार में बदलाव: 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 का भी इस्तेमाल करना होगा. इससे यह पक्का किया जा सकेगा कि कोलैप्स और एक्सपैंड की गई स्थितियां एक जैसी हों.

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

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

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

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

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

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

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

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

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 कुकी के व्यवहार की जांच करना

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

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

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

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

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

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

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

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

अन्य संसाधन

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

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

उपयोगकर्ताओं की संभावित संवेदनशील जानकारी को सुरक्षित रखने के लिए, अगर आपका ऐप्लिकेशन 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 या उसके बाद वाले वर्शन को टारगेट करता है और उसमें activities, services या broadcast receivers शामिल हैं, जो intent filters का इस्तेमाल करते हैं, तो आपको इन ऐप्लिकेशन कॉम्पोनेंट के लिए 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'

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

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

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

ऐप्लिकेशन की परफ़ॉर्मेंस और UX को बेहतर बनाने के लिए, 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 में सेव किया जाता है. इससे बाद में, उस डिवाइस या किसी नए डिवाइस पर डेटा को वापस लाया जा सकता है.
  • एक डिवाइस से दूसरे डिवाइस (D2D) में डेटा ट्रांसफ़र करना: इसमें उपयोगकर्ता के डेटा को सीधे उसके पुराने डिवाइस से नए डिवाइस में भेजा जाता है. जैसे, केबल का इस्तेमाल करके.

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

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

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

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

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

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

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 एट्रिब्यूट का इस्तेमाल करके, अपने ऐप्लिकेशन को नए एक्सएमएल कॉन्फ़िगरेशन पर ले जाएं. नए XML कॉन्फ़िगरेशन को पॉइंट करने पर, 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.onCapabilitiesChanged() का इस्तेमाल करके, WifiInfo के उन सभी ऑब्जेक्ट को पाया जा सकता है जो NetworkCallback को रजिस्टर करने के लिए इस्तेमाल किए गए NetworkRequest से मेल खाते हैं. 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> टैग की ज़रूरत नहीं है. ऐसे में, शेयर की गई किसी भी नेटिव लाइब्रेरी को ऐक्सेस किया जा सकता है. भले ही, वह NDK लाइब्रेरी हो या न हो.

एसडीके इंटिग्रेट किए बगैर इस्तेमाल की जाने वाली सुविधाओं पर लगी पाबंदियां अपडेट की गईं

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

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

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

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