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