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