Android 13 में, पहले की रिलीज़ की तरह ही कुछ बदलाव किए गए हैं. इनका असर आपके ऐप्लिकेशन पर पड़ सकता है. यहां दिए गए बदलाव, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो Android 13 या इसके बाद के वर्शन को टारगेट कर रहे हैं. अगर आपका ऐप्लिकेशन, Android 13 या उसके बाद के वर्शन को टारगेट कर रहा है, तो आपको अपने ऐप्लिकेशन में बदलाव करना चाहिए, ताकि वह इन व्यवहारों को सही तरीके से सपोर्ट कर सके. हालांकि, ऐसा सिर्फ़ उन मामलों में करना होगा जहां यह लागू होता है.
Android 13 पर काम करने वाले सभी ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची ज़रूर देखें.
निजता
सूचना की अनुमति से, फ़ोरग्राउंड सेवा के दिखने के तरीके पर असर पड़ता है
अगर उपयोगकर्ता, सूचनाएं पाने की अनुमति नहीं देता है, तो उसे सूचना पैनल में फ़ोरग्राउंड सेवाओं से जुड़ी सूचनाएं नहीं दिखेंगी. हालांकि, उपयोगकर्ताओं को टास्क मैनेजर में फ़ोरग्राउंड सेवाओं से जुड़ी सूचनाएं अब भी दिखती हैं. भले ही, सूचना पाने की अनुमति दी गई हो या नहीं.
आस-पास मौजूद वाई-फ़ाई डिवाइसों के लिए, रनटाइम की नई अनुमति
Android के पिछले वर्शन पर, वाई-फ़ाई से जुड़े कई सामान्य कामों को पूरा करने के लिए, उपयोगकर्ता को आपके ऐप्लिकेशन को ACCESS_FINE_LOCATION अनुमति देनी होगी.
उपयोगकर्ताओं के लिए, जगह की जानकारी की अनुमतियों को वाई-फ़ाई की सुविधा से जोड़ना मुश्किल होता है. इसलिए, Android 13 (एपीआई लेवल 33) में, NEARBY_DEVICES अनुमतियों के समूह में रनटाइम की अनुमति जोड़ी गई है. यह उन ऐप्लिकेशन के लिए है जो वाई-फ़ाई के ज़रिए, आस-पास मौजूद ऐक्सेस पॉइंट से डिवाइस के कनेक्शन मैनेज करते हैं. इस अनुमति NEARBY_WIFI_DEVICES से, वाई-फ़ाई के इस्तेमाल से जुड़े इन मामलों को पूरा किया जा सकता है:
- आस-पास मौजूद डिवाइसों को ढूंढने या उनसे कनेक्ट करने की अनुमति. जैसे, प्रिंटर या मीडिया कास्टिंग डिवाइस.
इस वर्कफ़्लो की मदद से, आपका ऐप्लिकेशन इस तरह के काम कर सकता है:
- एपी की जानकारी, आउट ऑफ़ बैंड (जैसे, बीएलई) के ज़रिए मिलती है.
- वाई-फ़ाई अवेयर की सुविधा का इस्तेमाल करके, डिवाइसों को ढूंढना और उनसे कनेक्ट करना. साथ ही, सिर्फ़ लोकल हॉटस्पॉट का इस्तेमाल करके कनेक्ट करना.
- Wi-Fi Direct की मदद से, डिवाइसों को खोजना और उनसे कनेक्ट करना.
- किसी जाने-पहचाने एसएसआईडी से कनेक्शन शुरू करें. जैसे, कार या स्मार्ट होम डिवाइस.
- सिर्फ़ स्थानीय हॉटस्पॉट की सुविधा चालू करें.
- आस-पास मौजूद 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 की मौजूदा स्थिति इनमें से कोई एक हो सकती है:
|
| लोड होने की जानकारी देने वाला स्पिनर |
PlaybackState की मौजूदा स्थिति इनमें से कोई एक हो सकती है:
|
|
| रोकें | 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 में उसी क्रम में दिखते हैं जिस क्रम में उन्हें जोड़ा गया था.
ऐप्लिकेशन की रंग वाली थीम, वेबव्यू कॉन्टेंट पर अपने-आप लागू हो जाती है
Android 13 (एपीआई लेवल 33) या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, setForceDark() तरीका अब काम नहीं करता. इसलिए, इस तरीके को कॉल करने पर कोई कार्रवाई नहीं होगी.
इसके बजाय, WebView अब हमेशा ऐप्लिकेशन के थीम ऐट्रिब्यूट isLightTheme के हिसाब से मीडिया क्वेरी prefers-color-scheme सेट करता है. दूसरे शब्दों में कहें, तो अगर 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 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 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ गैर-एसडीके इंटरफ़ेस (आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के हिसाब से) इस्तेमाल किए जा सकते हैं. हालांकि, किसी भी गैर-एसडीके तरीके या फ़ील्ड का इस्तेमाल करने से, आपके ऐप्लिकेशन के काम न करने का जोखिम हमेशा ज़्यादा होता है.
अगर आपको पक्का नहीं है कि आपका ऐप्लिकेशन, गैर-एसडीके इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो यह पता लगाने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, गैर-एसडीके इंटरफ़ेस पर निर्भर करता है, तो आपको एसडीके के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन के पास, गैर-एसडीके इंटरफ़ेस इस्तेमाल करने के लिए मान्य वजहें होती हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, गैर-एसडीके इंटरफ़ेस के इस्तेमाल का कोई विकल्प नहीं मिल रहा है, तो आपको नया सार्वजनिक एपीआई का अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 13 में एसडीके टूल में उपलब्ध नहीं होने वाले इंटरफ़ेस पर पाबंदियों से जुड़े अपडेट लेख पढ़ें. SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर पाबंदियां लेख पढ़ें.