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

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

Android 13 पर काम करने वाले सभी ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची भी ज़रूर देखें.

निजता

सूचना की अनुमति से, फ़ोरग्राउंड सेवा के दिखने के तरीके पर असर पड़ता है

अगर उपयोगकर्ता सूचना पाने की अनुमति नहीं देता है, तो उसे सूचना पैनल में फ़ोरग्राउंड सेवाओं से जुड़ी सूचनाएं नहीं दिखेंगी. हालांकि, उपयोगकर्ताओं को टास्क मैनेजर में फ़ोरग्राउंड सेवाओं से जुड़ी सूचनाएं अब भी दिखती हैं. भले ही, सूचना पाने की अनुमति दी गई हो या नहीं.

आस-पास मौजूद वाई-फ़ाई डिवाइसों के लिए नई रनटाइम अनुमति

Android के पिछले वर्शन पर, वाई-फ़ाई से जुड़े कई सामान्य कामों को पूरा करने के लिए, उपयोगकर्ता को आपके ऐप्लिकेशन को ACCESS_FINE_LOCATION की अनुमति देनी होगी.

उपयोगकर्ताओं के लिए, जगह की जानकारी ऐक्सेस करने की अनुमतियों को वाई-फ़ाई की सुविधा से जोड़ना मुश्किल होता है. इसलिए, Android 13 (एपीआई लेवल 33) में, NEARBY_DEVICES अनुमति वाले ग्रुप में रनटाइम की अनुमति दी गई है. यह अनुमति उन ऐप्लिकेशन के लिए है जो वाई-फ़ाई के ज़रिए, आस-पास मौजूद ऐक्सेस पॉइंट से डिवाइस के कनेक्शन मैनेज करते हैं. इस अनुमति, NEARBY_WIFI_DEVICES, से वाई-फ़ाई के इस्तेमाल से जुड़े इन मामलों को पूरा किया जा सकता है:

  • आस-पास मौजूद डिवाइसों को खोजने या उनसे कनेक्ट करने की अनुमति दें. जैसे, प्रिंटर या मीडिया कास्टिंग डिवाइस. इस वर्कफ़्लो की मदद से, आपका ऐप्लिकेशन इस तरह के काम कर सकता है:
    • एपी की जानकारी को आउट ऑफ़ बैंड तरीके से पाना. जैसे, बीएलई के ज़रिए.
    • Wi-Fi Aware की सुविधा का इस्तेमाल करके, डिवाइसों को ढूंढना और उनसे कनेक्ट करना. साथ ही, सिर्फ़ सीमित दायरे में इस्तेमाल होने वाले हॉटस्पॉट का इस्तेमाल करके कनेक्ट करना.
    • Wi-Fi Direct की मदद से, डिवाइसों को खोजें और उनसे कनेक्ट करें.
  • किसी जाने-पहचाने SSID से कनेक्शन शुरू करें. जैसे, कार या स्मार्ट होम डिवाइस.
  • सिर्फ़ सीमित दायरे में इस्तेमाल होने वाला हॉटस्पॉट चालू करें.
  • आस-पास मौजूद Wi-Fi Aware डिवाइसों की रेंज.

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

आस-पास मौजूद वाई-फ़ाई डिवाइसों को ऐक्सेस करने की अनुमति का अनुरोध करने के तरीके के बारे में ज़्यादा जानें.

मीडिया से जुड़ी अनुमतियों को कंट्रोल करने की बेहतर सुविधा

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

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

मीडिया का टाइप अनुरोध करने की अनुमति
इमेज और फ़ोटो READ_MEDIA_IMAGES
वीडियो READ_MEDIA_VIDEO
ऑडियो फ़ाइलें READ_MEDIA_AUDIO

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

पहली इमेज में, READ_MEDIA_AUDIO अनुमति का अनुरोध करने वाला ऐप्लिकेशन दिखाया गया है.

अगर आपने एक ही समय में READ_MEDIA_IMAGES अनुमति और READ_MEDIA_VIDEO अनुमति, दोनों का अनुरोध किया है, तो सिस्टम की अनुमति वाला सिर्फ़ एक डायलॉग बॉक्स दिखेगा.

अगर आपके ऐप्लिकेशन को पहले READ_EXTERNAL_STORAGE अनुमति दी गई थी, तो अपग्रेड करते समय, अनुरोध की गई READ_MEDIA_* अनुमतियां अपने-आप मिल जाती हैं. अपग्रेड की गई अनुमतियों की समीक्षा करने के लिए, इस ADB कमांड का इस्तेमाल किया जा सकता है:

adb shell cmd appops get --uid PACKAGE_NAME

बैकग्राउंड में बॉडी सेंसर का इस्तेमाल करने के लिए, नई अनुमति की ज़रूरत होती है

Android 13 में, बॉडी सेंसर के लिए "इस्तेमाल के दौरान" ऐक्सेस का कॉन्सेप्ट पेश किया गया है. जैसे, धड़कन की दर, तापमान, और खून में ऑक्सीजन का प्रतिशत. यह ऐक्सेस मॉडल, उस मॉडल से काफ़ी मिलता-जुलता है जिसे सिस्टम ने Android 10 (एपीआई लेवल 29) में जगह की जानकारी के लिए पेश किया था.

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

परफ़ॉर्मेंस और बैटरी

बैटरी के संसाधन का इस्तेमाल

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

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

PlaybackState से मिले मीडिया कंट्रोल

Android 13 (एपीआई लेवल 33) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, सिस्टम PlaybackState कार्रवाइयों से मीडिया कंट्रोल हासिल करता है. इससे सिस्टम को कंट्रोल का बेहतर सेट दिखाने की अनुमति मिलती है. तकनीकी तौर पर, यह सेट फ़ोन और टैबलेट डिवाइसों के लिए एक जैसा होता है. साथ ही, यह Android Auto और Android TV जैसे अन्य Android प्लैटफ़ॉर्म पर मीडिया कंट्रोल के रेंडर होने के तरीके के मुताबिक होता है.

दूसरी इमेज में, फ़ोन और टैबलेट डिवाइस पर यह सुविधा कैसी दिखती है, इसका उदाहरण दिखाया गया है.

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

Android 13 से पहले, सिस्टम MediaStyle सूचना में ज़्यादा से ज़्यादा पांच कार्रवाइयां दिखाता था. ये कार्रवाइयां उसी क्रम में दिखती थीं जिस क्रम में उन्हें जोड़ा गया था. कॉम्पैक्ट मोड में, setShowActionsInCompactView() प्रॉपर्टी का इस्तेमाल करके तय की गई ज़्यादा से ज़्यादा तीन कार्रवाइयां दिखाई जाती थीं. उदाहरण के लिए, कम की गई क्विक सेटिंग में.

Android 13 से, सिस्टम PlaybackState के आधार पर पांच ऐक्शन बटन दिखाता है. इनके बारे में यहां बताया गया है. कॉम्पैक्ट मोड में, सिर्फ़ पहले तीन ऐक्शन स्लॉट दिखेंगे. Android 13 को टारगेट न करने वाले ऐप्लिकेशन या PlaybackState शामिल न करने वाले ऐप्लिकेशन के लिए, सिस्टम MediaStyle सूचना में जोड़ी गई Action सूची के आधार पर कंट्रोल दिखाएगा. इसके बारे में पिछले पैराग्राफ़ में बताया गया है.

स्लॉट कार्रवाई शर्तें
1 चलाएं PlaybackState की मौजूदा स्थिति इनमें से कोई एक हो सकती है:
  • STATE_NONE
  • STATE_STOPPED
  • STATE_PAUSED
  • STATE_ERROR
लोड होने की जानकारी देने वाला स्पिनर PlaybackState की मौजूदा स्थिति इनमें से कोई एक हो सकती है:
  • STATE_CONNECTING
  • STATE_BUFFERING
रोकें PlaybackState की मौजूदा स्थिति इनमें से कोई नहीं है.
2 पीछे जाएं PlaybackState कार्रवाइयों में ACTION_SKIP_TO_PREVIOUS शामिल हैं.
पसंद के मुताबिक PlaybackState कार्रवाइयों में ACTION_SKIP_TO_PREVIOUS शामिल नहीं है. साथ ही, PlaybackState कस्टम कार्रवाइयों में ऐसी कस्टम कार्रवाई शामिल है जिसे अब तक नहीं रखा गया है.
कोई भी तार नहीं लगा है PlaybackState extras में, कुंजी SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV के लिए true बूलियन वैल्यू शामिल है.
3 अगला PlaybackState कार्रवाइयों में ACTION_SKIP_TO_NEXT शामिल हैं.
पसंद के मुताबिक PlaybackState कार्रवाइयों में ACTION_SKIP_TO_NEXT शामिल नहीं है. साथ ही, PlaybackState कस्टम कार्रवाइयों में ऐसी कस्टम कार्रवाई शामिल है जिसे अब तक नहीं रखा गया है.
कोई भी तार नहीं लगा है PlaybackState extras में, कुंजी SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT के लिए true बूलियन वैल्यू शामिल है.
4 पसंद के मुताबिक PlaybackState कस्टम कार्रवाइयों में ऐसी कस्टम कार्रवाई शामिल है जिसे अब तक नहीं रखा गया है.
5 पसंद के मुताबिक PlaybackState कस्टम कार्रवाइयों में ऐसी कस्टम कार्रवाई शामिल है जिसे अब तक नहीं रखा गया है.

कस्टम कार्रवाइयों को उसी क्रम में रखा जाता है जिस क्रम में उन्हें PlaybackState में जोड़ा गया था.

ऐप्लिकेशन की कलर थीम, WebView कॉन्टेंट पर अपने-आप लागू हो जाती है

Android 13 (एपीआई लेवल 33) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, setForceDark() तरीके का इस्तेमाल नहीं किया जा सकता. इसलिए, अगर इस तरीके को कॉल किया जाता है, तो कोई कार्रवाई नहीं होगी.

इसके बजाय, अब WebView हमेशा ऐप्लिकेशन की थीम के ऐट्रिब्यूट isLightTheme के हिसाब से मीडिया क्वेरी prefers-color-scheme सेट करता है. दूसरे शब्दों में कहें, तो अगर isLightTheme की वैल्यू true है या इसे सेट नहीं किया गया है, तो prefers-color-scheme की वैल्यू light होगी. इसके अलावा, अगर isLightTheme की वैल्यू true नहीं है, तो prefers-color-scheme की वैल्यू dark होगी. इसका मतलब है कि अगर वेब कॉन्टेंट में यह सुविधा काम करती है, तो ऐप्लिकेशन की थीम से मेल खाने के लिए, वेब कॉन्टेंट की लाइट या डार्क स्टाइल अपने-आप लागू हो जाती है.

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

अगर आपको अब भी अपने ऐप्लिकेशन की कलर थीम के व्यवहार को पसंद के मुताबिक बनाना है, तो setAlgorithmicDarkeningAllowed() तरीके का इस्तेमाल करें. हमारा सुझाव है कि Android के पिछले वर्शन के साथ काम करने की सुविधा के लिए, AndroidX में setAlgorithmicDarkeningAllowed() तरीके का इस्तेमाल करें.

उस तरीके के बारे में ज़्यादा जानने के लिए, दस्तावेज़ देखें. इससे आपको यह पता चलेगा कि आपके ऐप्लिकेशन की targetSdkVersion और थीम सेटिंग के हिसाब से, ऐप्लिकेशन में किस तरह का व्यवहार देखने को मिल सकता है.

कनेक्टिविटी

BluetoothAdapter#enable() और BluetoothAdapter#disable() को बंद कर दिया गया है

Android 13 (एपीआई लेवल 33) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, BluetoothAdapter#enable() और BluetoothAdapter#disable() तरीकों का इस्तेमाल नहीं किया जा सकता. ये हमेशा false दिखाते हैं.

यहां दिए गए ऐप्लिकेशन, इन बदलावों से छूट पा सकते हैं:

  • डिवाइस के मालिक के ऐप्लिकेशन
  • प्रोफ़ाइल के मालिक के ऐप्लिकेशन
  • सिस्टम ऐप्लिकेशन

Google Play सेवाएं

विज्ञापन आईडी के लिए अनुमति ज़रूरी है

Google Play services विज्ञापन आईडी का इस्तेमाल करने वाले और Android 13 (एपीआई लेवल 33) और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को, अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में AD_ID सामान्य अनुमति के बारे में एलान करना होगा. इसके लिए, यह तरीका अपनाएं:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

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

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

ज़्यादा जानने के लिए, Play Console के सहायता केंद्र में विज्ञापन आईडी देखें.

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

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

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

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

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