व्यवहार में बदलाव: 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 की मदद से डिवाइसों को ढूंढना और उनसे कनेक्ट करना.
• किसी जाने-पहचाने एसएसआईडी से कनेक्शन शुरू करना. जैसे, कार या स्मार्ट होम डिवाइस.
• सिर्फ़ स्थानीय हॉटस्पॉट शुरू करना.
• आस-पास मौजूद Wi-Fi Aware डिवाइसों की रेंज.

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

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

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

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

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

पहली इमेज में, एक ऐसा ऐप्लिकेशन दिखाया गया है जो 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 के अन्य प्लैटफ़ॉर्म (जैसे, Android Auto और Android TV) पर मीडिया कंट्रोल के रेंडर होने के तरीके के मुताबिक भी होता है.

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

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

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

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

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

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

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

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

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

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

कनेक्टिविटी

`BluetoothAdapter#enable()` और `BluetoothAdapter#disable()` तरीके बंद किए गए

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

इन बदलावों से, इन टाइप के ऐप्लिकेशन पर असर नहीं पड़ता:

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

Google Play सेवाएं

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

Google Play सेवाओं के विज्ञापन आईडी का इस्तेमाल करने वाले और 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 या इसके बाद के वर्शन को टारगेट करते समय इस अनुमति का एलान नहीं करता है, तो विज्ञापन आईडी अपने-आप हट जाएगा और उसकी जगह पर कई ज़ीरो दिखेंगे.

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

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

एसडीके टूल में उपलब्ध नहीं होने वाले इंटरफ़ेस पर लगाई गई पाबंदियां अपडेट की गईं

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

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

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

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