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

    • यह सुनिश्चित करने के लिए कि "अलर्ट करने की सुविधा" बिलकुल आपकी उम्मीद के मुताबिक स्थिति दिख रही है सूचना चैनल की अहमियत को बढ़ाकर "High" करें (पॉप चालू है स्क्रीन).

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

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

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

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

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

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

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

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

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

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

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

अनुमानित जगह

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

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

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

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

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

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

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

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

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

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

वेबव्यू के साथ किसी ऐप्लिकेशन की जांच करने के लिए, आपको ऐप्लिकेशन की जांच करें, जिसकी जांच करने के लिए, इनमें से किसी एक चरण को पूरा करें:

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 श्रेणी, सेट true के लिए android:exported. ज़्यादातर अन्य मामलों में, 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_अनुमति.

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

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

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

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

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

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

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

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

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

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

काम करता है या नहीं

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

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

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

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

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

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

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

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

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

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

बिना SDK टूल के अपडेट की गई पाबंदियां

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

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

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

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