पहले की रिलीज़ की तरह ही, 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 |
किसी दूसरे ऐप्लिकेशन की मीडिया फ़ाइलों को ऐक्सेस करने से पहले, पुष्टि करें कि उपयोगकर्ता ने आपके ऐप्लिकेशन को मीडिया फ़ाइलों को ऐक्सेस करने की ज़रूरी अनुमतियां दी हैं.
इमेज 1 में एक ऐसा ऐप्लिकेशन दिखाया गया है जो READ_MEDIA_AUDIO अनुमति का अनुरोध करता है.
अगर आपने READ_MEDIA_IMAGES और READ_MEDIA_VIDEO, दोनों अनुमतियों के लिए एक साथ अनुरोध किया है, तो सिस्टम की अनुमति वाला सिर्फ़ एक डायलॉग बॉक्स दिखेगा.
अगर आपके ऐप्लिकेशन को पहले ही
READ_EXTERNAL_STORAGE
की अनुमति मिल चुकी है, तो अपग्रेड करने पर, अनुरोध की गई READ_MEDIA_* अनुमतियां अपने-आप मिल जाती हैं. अपग्रेड की गई अनुमतियों की समीक्षा करने के लिए, इस एडीबी कमांड का इस्तेमाल किया जा सकता है:
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 या इसके बाद के वर्शन को टारगेट करते समय इस अनुमति का एलान नहीं करता है, तो विज्ञापन आईडी अपने-आप हट जाता है और उसकी जगह पर कई ज़ीरो दिखते हैं.
अगर आपका ऐप्लिकेशन ऐसे SDK टूल इस्तेमाल करता है जो लाइब्रेरी के मेनिफ़ेस्ट में AD_ID अनुमति का एलान करते हैं, तो यह अनुमति आपके ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में डिफ़ॉल्ट रूप से मर्ज हो जाती है. इस मामले में, आपको अपने ऐप्लिकेशन की मेनिफ़ेस्ट फ़ाइल में अनुमति का एलान करने की ज़रूरत नहीं है.
ज़्यादा जानने के लिए, Play Console के सहायता केंद्र में विज्ञापन आईडी देखें.
गैर-एसडीके इंटरफ़ेस से जुड़ी पाबंदियों को अपडेट किया गया
Android 13 में, पाबंदी वाले गैर-एसडीके इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं. ये सूचियां, Android डेवलपर के साथ मिलकर काम करने और हाल ही में हुई इंटरनल टेस्टिंग के आधार पर बनाई गई हैं. हम यह पक्का करते हैं कि गैर-एसडीके इंटरफ़ेस को प्रतिबंधित करने से पहले, सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 13 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, फ़िलहाल कुछ गैर-एसडीके इंटरफ़ेस (आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के हिसाब से) इस्तेमाल किए जा सकते हैं. हालांकि, किसी भी गैर-एसडीके तरीके या फ़ील्ड का इस्तेमाल करने से, आपके ऐप्लिकेशन के काम न करने का जोखिम हमेशा ज़्यादा होता है.
अगर आपको पक्का नहीं है कि आपका ऐप्लिकेशन, गैर-एसडीके इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो यह पता लगाने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, गैर-एसडीके इंटरफ़ेस पर निर्भर करता है, तो आपको एसडीके के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन के पास, गैर-एसडीके इंटरफ़ेस इस्तेमाल करने के लिए मान्य वजहें होती हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, गैर-एसडीके इंटरफ़ेस के इस्तेमाल का कोई विकल्प नहीं मिल रहा है, तो आपको नया सार्वजनिक एपीआई का अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 13 में गैर-एसडीके इंटरफ़ेस से जुड़ी पाबंदियों के बारे में अपडेट देखें. SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर पाबंदियां देखें.