काम करने के तरीके में बदलाव: Android 15 या उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन

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

Android 15 पर काम करने वाले सभी ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची भी देखना न भूलें. भले ही, आपके ऐप्लिकेशन का targetSdkVersion कुछ भी हो.

मुख्य फ़ंक्शन

Android 15, Android सिस्टम की कई मुख्य सुविधाओं में बदलाव करता है या उन्हें बेहतर बनाता है.

फ़ोरग्राउंड सेवाओं में हुए बदलाव

हम Android 15 में फ़ोरग्राउंड सेवाओं में ये बदलाव कर रहे हैं.

• डेटा सिंक करने वाली फ़ोरग्राउंड सेवा के टाइम आउट का व्यवहार
• मीडिया प्रोसेस करने वाली नई फ़ोरग्राउंड सेवा का टाइप
• फ़ोरग्राउंड सेवाएं लॉन्च करने वाले BOOT_COMPLETED ब्रॉडकास्ट रिसीवर पर पाबंदियां
• ऐप्लिकेशन के पास SYSTEM_ALERT_WINDOW अनुमति होने पर, फ़ोरग्राउंड सेवाएं शुरू करने से जुड़ी पाबंदियां

डेटा सिंक करने वाली फ़ोरग्राउंड सेवा के टाइम आउट का व्यवहार

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

सिस्टम, किसी ऐप्लिकेशन की dataSync सेवाओं को 24 घंटे में कुल छह घंटे तक चलने की अनुमति देता है. इसके बाद, सिस्टम चल रही सेवा के Service.onTimeout(int, int) तरीके को कॉल करता है. इसे Android 15 में लॉन्च किया गया था. इस दौरान, सेवा के पास Service.stopSelf() को कॉल करने के लिए कुछ सेकंड होते हैं. Service.onTimeout() को कॉल करने के बाद, सेवा को फ़ोरग्राउंड सेवा नहीं माना जाता. अगर सेवा Service.stopSelf() को कॉल नहीं करती है, तो सिस्टम में कोई इंटरनल अपवाद दिखता है. अपवाद को Logcat में इस मैसेज के साथ लॉग किया जाता है:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"

इस बदलाव की वजह से होने वाली समस्याओं से बचने के लिए, इनमें से एक या एक से ज़्यादा काम किए जा सकते हैं:

1. अपनी सेवा में Service.onTimeout(int, int) का नया तरीका लागू करें. जब आपके ऐप्लिकेशन को कॉलबैक मिल जाए, तो stopSelf() को कुछ सेकंड के अंदर कॉल करना न भूलें. (अगर ऐप्लिकेशन को तुरंत बंद नहीं किया जाता है, तो सिस्टम गड़बड़ी का मैसेज जनरेट करता है.)
2. पक्का करें कि आपके ऐप्लिकेशन की dataSync सेवाएं, 24 घंटे में कुल छह घंटे से ज़्यादा न चलें. ऐसा तब तक नहीं होगा, जब तक उपयोगकर्ता ऐप्लिकेशन के साथ इंटरैक्ट करके, टाइमर को रीसेट नहीं करता.
3. सीधे उपयोगकर्ता के साथ इंटरैक्शन होने पर ही, dataSync फ़ोरग्राउंड सेवाएं शुरू करें. सेवा शुरू होने के समय, आपका ऐप्लिकेशन फ़ोरग्राउंड में होता है. इसलिए, ऐप्लिकेशन के बैकग्राउंड में चलने के बाद, आपकी सेवा को पूरे छह घंटे तक चालू रखा जाता है.
4. dataSync फ़ोरग्राउंड सेवा का इस्तेमाल करने के बजाय, किसी अन्य एपीआई का इस्तेमाल करें.

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

टेस्ट करना

अपने ऐप्लिकेशन के व्यवहार की जांच करने के लिए, डेटा सिंक टाइम आउट की सुविधा चालू की जा सकती है. भले ही, आपका ऐप्लिकेशन Android 15 को टारगेट न करता हो. हालांकि, यह ज़रूरी है कि ऐप्लिकेशन Android 15 वाले डिवाइस पर चल रहा हो. टाइम आउट की सुविधा चालू करने के लिए, यह adb कमांड चलाएं:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

टाइम आउट की अवधि में बदलाव भी किया जा सकता है. इससे यह जांचना आसान हो जाता है कि तय सीमा पूरी होने पर, आपका ऐप्लिकेशन कैसे काम करता है. टाइम आउट की नई अवधि सेट करने के लिए, यह adb कमांड चलाएं:

adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds

मीडिया प्रोसेस करने वाली नई फ़ोरग्राउंड सेवा का टाइप

Android 15 में, फ़ोरग्राउंड सेवा का एक नया टाइप mediaProcessing जोड़ा गया है. यह सेवा टाइप, मीडिया फ़ाइलों को ट्रांसकोड करने जैसे कामों के लिए सही है. उदाहरण के लिए, कोई मीडिया ऐप्लिकेशन किसी ऑडियो फ़ाइल को डाउनलोड कर सकता है और उसे चलाने से पहले, किसी दूसरे फ़ॉर्मैट में बदल सकता है. mediaProcessing फ़ोरग्राउंड सेवा का इस्तेमाल करके, यह पक्का किया जा सकता है कि ऐप्लिकेशन बैकग्राउंड में होने पर भी कन्वर्ज़न जारी रहे.

सिस्टम किसी ऐप्लिकेशन की mediaProcessing सेवाओं को 24 घंटों में कुल छह घंटे चलाने की अनुमति देता है. इसके बाद, सिस्टम, मौजूदा सेवा के Service.onTimeout(int, int) तरीके को कॉल करता है (Android 15 में शुरू किया गया). फ़िलहाल, Service.stopSelf() को कॉल करने के लिए सेवा को कुछ सेकंड मिलेंगे. अगर सेवा Service.stopSelf() को कॉल नहीं करती है, तो सिस्टम में कोई इंटरनल अपवाद दिखता है. अपवाद को Logcat में लॉग इन किया जाता है जिसमें यह मैसेज शामिल है:

Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"

अपवाद से बचने के लिए, इनमें से कोई एक काम किया जा सकता है:

1. अपनी सेवा में Service.onTimeout(int, int) का नया तरीका लागू करें. जब आपके ऐप्लिकेशन को कॉलबैक मिलता है, तो कुछ सेकंड के अंदर stopSelf() को कॉल करना न भूलें. (अगर ऐप्लिकेशन को तुरंत नहीं रोका जाता, तो सिस्टम गड़बड़ी जनरेट करता है.)
2. पक्का करें कि आपके ऐप्लिकेशन की mediaProcessing सेवाएं, 24 घंटे में कुल छह घंटे से ज़्यादा न चलें. ऐसा तब तक नहीं होगा, जब तक उपयोगकर्ता ऐप्लिकेशन के साथ इंटरैक्ट करके, टाइमर को रीसेट नहीं करता.
3. सीधे उपयोगकर्ता के साथ इंटरैक्शन होने पर ही, mediaProcessing फ़ोरग्राउंड सेवाएं शुरू करें. सेवा शुरू होने के समय, आपका ऐप्लिकेशन फ़ोरग्राउंड में होता है. इसलिए, ऐप्लिकेशन के बैकग्राउंड में चलने के बाद, आपकी सेवा को पूरे छह घंटे तक चालू रखा जाता है.
4. mediaProcessing फ़ोरग्राउंड सेवा का इस्तेमाल करने के बजाय, WorkManager जैसे अन्य एपीआई का इस्तेमाल करें.

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

mediaProcessing सेवा टाइप के बारे में ज़्यादा जानकारी के लिए, Android 15 के लिए फ़ोरग्राउंड सेवा टाइप में हुए बदलाव: मीडिया प्रोसेसिंग देखें.

टेस्ट करना

अपने ऐप्लिकेशन के काम करने के तरीके की जांच करने के लिए, मीडिया प्रोसेसिंग के टाइम आउट को चालू किया जा सकता है. भले ही, आपका ऐप्लिकेशन Android 15 को टारगेट न करता हो (जब तक कि ऐप्लिकेशन, Android 15 डिवाइस पर चल रहा हो). टाइम आउट की सुविधा चालू करने के लिए, यह adb कमांड चलाएं:

adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name

टाइम आउट की अवधि में बदलाव भी किया जा सकता है. इससे यह जांचना आसान हो जाता है कि तय सीमा पूरी होने पर, आपका ऐप्लिकेशन कैसे काम करता है. टाइम आउट की नई अवधि सेट करने के लिए, यह adb कमांड चलाएं:

adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds

फ़ोरग्राउंड सेवाएं लॉन्च करने वाले BOOT_COMPLETED ब्रॉडकास्ट रिसीवर पर पाबंदियां

BOOT_COMPLETED ब्रॉडकास्ट रिसीवर के लिए, फ़ोरग्राउंड सेवाएं लॉन्च करने से जुड़ी नई पाबंदियां हैं. BOOT_COMPLETED रिसीवर को फ़ोरग्राउंड सेवाओं के ये टाइप हैं:

• dataSync
• camera
• mediaPlayback
• phoneCall
• mediaProjection
• microphone (यह पाबंदी microphone के लिए तब से लागू है Android 14)

अगर BOOT_COMPLETED रिसीवर इनमें से किसी भी तरह के फ़ोरग्राउंड को लॉन्च करने की कोशिश करता है सिस्टम, ForegroundServiceStartNotAllowedException की जानकारी देता है.

टेस्ट करना

अपने ऐप्लिकेशन के व्यवहार की जांच करने के लिए, ये नई पाबंदियां चालू की जा सकती हैं. भले ही, आपका ऐप्लिकेशन Android 15 को टारगेट न करता हो. हालांकि, यह ज़रूरी है कि ऐप्लिकेशन Android 15 वाले डिवाइस पर चल रहा हो. यहां दिया गया adb निर्देश चलाएं:

adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name

डिवाइस को रीस्टार्ट किए बिना BOOT_COMPLETED ब्रॉडकास्ट भेजने के लिए, नीचे दिया गया adb निर्देश चलाएं:

adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name

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

पहले, अगर किसी ऐप्लिकेशन के पास SYSTEM_ALERT_WINDOW अनुमति होती थी, तो वह फ़ोरग्राउंड सेवा को लॉन्च कर सकता था. भले ही, वह ऐप्लिकेशन फ़िलहाल बैकग्राउंड में हो. इस बारे में बैकग्राउंड में शुरू करने से जुड़ी पाबंदियों से छूट में बताया गया है.

अगर कोई ऐप्लिकेशन Android 15 को टारगेट करता है, तो अब यह छूट कम हो गई है. ऐप्लिकेशन को अब SYSTEM_ALERT_WINDOW की अनुमति की ज़रूरत होगी. साथ ही, उसमें भी एक दिखने वाला ओवरले विंडो भी होनी चाहिए. इसका मतलब है कि ऐप्लिकेशन को सबसे पहले TYPE_APPLICATION_OVERLAY विंडो लॉन्च करनी होगी और फ़ोरग्राउंड सेवा शुरू करने से पहले, विंडो दिखनी चाहिए.

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

अगर आपका ऐप्लिकेशन SYSTEM_ALERT_WINDOW अनुमति का एलान करता है और बैकग्राउंड से फ़ोरग्राउंड सेवाएं लॉन्च करता है, तो इस बदलाव का उस पर असर पड़ सकता है. अगर आपके ऐप्लिकेशन को ForegroundServiceStartNotAllowedException मिलता है, तो अपने ऐप्लिकेशन के काम करने का क्रम देखें और पक्का करें कि बैकग्राउंड से फ़ोरग्राउंड सेवा शुरू करने से पहले, आपके ऐप्लिकेशन में एक ऐक्टिव ओवरले विंडो हो. View.getWindowVisibility() को कॉल करके, यह देखा जा सकता है कि ओवरले विंडो फ़िलहाल दिख रही है या नहीं. इसके अलावा, View.onWindowVisibilityChanged() को बदलकर, यह भी सेट किया जा सकता है कि ओवरले विंडो दिखने या न दिखने पर सूचना मिलती रहे.

टेस्ट करना

अपने ऐप्लिकेशन के व्यवहार की जांच करने के लिए, ये नई पाबंदियां चालू की जा सकती हैं. भले ही, आपका ऐप्लिकेशन Android 15 को टारगेट न करता हो. हालांकि, यह ज़रूरी है कि ऐप्लिकेशन Android 15 वाले डिवाइस पर चल रहा हो. बैकग्राउंड से फ़ोरग्राउंड सेवाएं शुरू करने से जुड़ी इन नई पाबंदियों को चालू करने के लिए, यहां दिया गया adb निर्देश चलाएं:

adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name

ऐप्लिकेशन, 'परेशान न करें' मोड की ग्लोबल स्थिति में कब बदलाव कर सकते हैं, इसमें बदलाव

Android 15 (एपीआई लेवल 35) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, अब किसी डिवाइस पर 'परेशान न करें' (डीएनडी) मोड की ग्लोबल स्थिति या नीति को नहीं बदल सकते. ऐसा, उपयोगकर्ता की सेटिंग में बदलाव करके या डीएनडी मोड को बंद करके नहीं किया जा सकता. इसके बजाय, ऐप्लिकेशन को AutomaticZenRule का योगदान देना होगा. सिस्टम, इस योगदान को सबसे ज़्यादा पाबंदी वाली मौजूदा नीति के साथ मिलाकर, ग्लोबल नीति बनाता है. पहले जिन मौजूदा एपीआई कॉल से ग्लोबल स्टेटस (setInterruptionFilter, setNotificationPolicy) पर असर पड़ा था उनसे, एक 'असहमति' वाला AutomaticZenRule पैरामीटर बनता है या अपडेट होता है. यह पैरामीटर, उन एपीआई कॉल के कॉल-साइकल के हिसाब से टॉगल किया जाता है.

ध्यान दें कि इस बदलाव का असर सिर्फ़ तब पड़ता है, जब ऐप्लिकेशन setInterruptionFilter(INTERRUPTION_FILTER_ALL) को कॉल कर रहा हो और उसे उम्मीद हो कि उस कॉल से, AutomaticZenRule को बंद किया जा सकेगा. AutomaticZenRule को पहले उसके मालिकों ने चालू किया था.

OpenJDK API में हुए बदलाव

Android 15 में, Android की मुख्य लाइब्रेरी को रीफ़्रेश करने का काम जारी है, ताकि इसे OpenJDK LTS के नए रिलीज़ की सुविधाओं के साथ अलाइन किया जा सके.

इनमें से कुछ बदलावों का असर, Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के साथ काम करने की सुविधा पर पड़ सकता है:

• स्ट्रिंग फ़ॉर्मैटिंग एपीआई में बदलाव: इन String.format() और Formatter.format() एपीआई का इस्तेमाल करते समय, आर्ग्युमेंट इंडेक्स, फ़्लैग, चौड़ाई, और सटीक वैल्यू की पुष्टि अब ज़्यादा सख्त तरीके से की जाती है:

  • String.format(String, Object[])
  • String.format(Locale, String, Object[])
  • Formatter.format(String, Object[])
  • Formatter.format(Locale, String, Object[])

  उदाहरण के लिए, आर्ग्युमेंट के इंडेक्स के तौर पर 0 का इस्तेमाल करने पर (फ़ॉर्मैट स्ट्रिंग में %0), यह अपवाद दिखता है:

  IllegalFormatArgumentIndexException: Illegal format argument index = 0
  

  इस मामले में, फ़ॉर्मैट स्ट्रिंग में 1 (%1) के आर्ग्युमेंट इंडेक्स का इस्तेमाल करके, समस्या को ठीक किया जा सकता है.

• Arrays.asList(...).toArray() के कॉम्पोनेंट टाइप में बदलाव: Arrays.asList(...).toArray() का इस्तेमाल करने पर, नतीजे के ऐरे का कॉम्पोनेंट टाइप अब Object है, न कि ऐरे के एलिमेंट का टाइप. इसलिए, यह कोड ClassCastException दिखाता है:

  String[] elements = (String[]) Arrays.asList("one", "two").toArray();
  

  इस मामले में, नतीजे के ऐरे में String को कॉम्पोनेंट टाइप के तौर पर बनाए रखने के लिए, Collection.toArray(Object[]) का इस्तेमाल किया जा सकता है:

  String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
  

• भाषा कोड को मैनेज करने के तरीके में बदलाव: Locale एपीआई का इस्तेमाल करते समय, अब हिब्रू, येहुदी, और इंडोनेशियन भाषा के कोड, उनके पुराने फ़ॉर्म (हिब्रू: iw, येहुदी: ji, और इंडोनेशियन: in) में बदले नहीं जाते. इनमें से किसी एक स्थानीय भाषा के लिए भाषा कोड तय करते समय, ISO 639-1 के कोड का इस्तेमाल करें (हिब्रू: he, येहुदी: yi, और इंडोनेशियन: id).

• रैंडम int सीक्वेंस में बदलाव: https://bugs.openjdk.org/browse/JDK-8301574 में किए गए बदलावों के बाद, यहां दिए गए Random.ints() तरीके अब संख्याओं का एक अलग क्रम दिखाते हैं, जबकि Random.nextInt() तरीके ऐसा नहीं करते:

  • Random.ints(long)
  • Random.ints(long, int, int)
  • Random.ints(int, int)
  • Random.ints()

  आम तौर पर, इस बदलाव से ऐप्लिकेशन के काम करने के तरीके पर कोई असर नहीं पड़ना चाहिए. हालांकि, आपके कोड को यह उम्मीद नहीं करनी चाहिए कि Random.ints() तरीकों से जनरेट किया गया क्रम, Random.nextInt() से मैच करेगा.

Android 15 (एपीआई लेवल 35) का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन के बिल्ड कॉन्फ़िगरेशन में compileSdk को अपडेट करने के बाद, नए SequencedCollection एपीआई से आपके ऐप्लिकेशन के काम करने के तरीके पर असर पड़ सकता है:

• kotlin-stdlib में MutableList.removeFirst() और MutableList.removeLast() एक्सटेंशन फ़ंक्शन के साथ कॉलिज़न

  Java में List टाइप, Kotlin में MutableList टाइप से मैप होता है. Android 15 (एपीआई लेवल 35) में List.removeFirst() और List.removeLast() एपीआई को शामिल किया गया है. इसलिए, Kotlin कंपाइलर, list.removeFirst() जैसे फ़ंक्शन कॉल को kotlin-stdlib में मौजूद एक्सटेंशन फ़ंक्शन के बजाय, नए List एपीआई के लिए स्टैटिक तौर पर हल करता है.

  अगर किसी ऐप्लिकेशन को compileSdk को 35 पर सेट करके और minSdk को 34 या उससे पहले के वर्शन पर सेट करके फिर से कंपाइल किया जाता है और फिर उस ऐप्लिकेशन को Android 14 और उससे पहले के वर्शन पर चलाया जाता है, तो रनटाइम के दौरान गड़बड़ी का मैसेज दिखता है:

  java.lang.NoSuchMethodError: No virtual method
  removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
  

  Android Gradle प्लग इन में मौजूद NewApi lint विकल्प, एपीआई के इन नए इस्तेमालों का पता लगा सकता है.

  ./gradlew lint
  
  MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
        list.removeFirst()
  

  रनटाइम अपवाद और लिंट की गड़बड़ियों को ठीक करने के लिए, Kotlin में removeFirst() और removeLast() फ़ंक्शन कॉल को क्रमशः removeAt(0) और removeAt(list.lastIndex) से बदला जा सकता है. अगर Android Studio Ladybug | 2024.1.3 या इसके बाद के वर्शन का इस्तेमाल किया जा रहा है, तो इन गड़बड़ियों को तुरंत ठीक करने का विकल्प भी मिलता है.

  अगर लिंट करने का विकल्प बंद है, तो @SuppressLint("NewApi") और lintOptions { disable 'NewApi' } को हटाएं.

• Java में अन्य तरीकों के साथ टकराव

  मौजूदा टाइप में नए तरीके जोड़े गए हैं. उदाहरण के लिए, List और Deque. ऐसा हो सकता है कि ये नए तरीके, दूसरे इंटरफ़ेस और क्लास में मौजूद, एक जैसे नाम और आर्ग्युमेंट टाइप वाले तरीकों के साथ काम न करें. अगर किसी मेथड के सिग्नेचर में, काम न करने वाले सिग्नेचर का इस्तेमाल किया गया है, तो javac कंपाइलर, बिल्ड के समय गड़बड़ी का मैसेज दिखाता है. उदाहरण के लिए:

  गड़बड़ी का पहला उदाहरण:

  javac MyList.java
  
  MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List
    public void removeLast() {
                ^
    return type void is not compatible with Object
    where E is a type-variable:
      E extends Object declared in interface List
  

  गड़बड़ी का दूसरा उदाहरण:

  javac MyList.java
  
  MyList.java:7: error: types Deque<Object> and List<Object> are incompatible;
  public class MyList implements  List<Object>, Deque<Object> {
    both define reversed(), but with unrelated return types
  1 error
  

  तीसरी गड़बड़ी का उदाहरण:

  javac MyList.java
  
  MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible;
  public static class MyList implements List<Object>, MyInterface<Object> {
    class MyList inherits unrelated defaults for getFirst() from types List and MyInterface
    where E#1,E#2 are type-variables:
      E#1 extends Object declared in interface List
      E#2 extends Object declared in interface MyInterface
  1 error
  

  बिल्ड से जुड़ी इन गड़बड़ियों को ठीक करने के लिए, इन इंटरफ़ेस को लागू करने वाली क्लास को, काम करने वाले रिटर्न टाइप के साथ, तरीके को बदलना चाहिए. उदाहरण के लिए:

  @Override
  public Object getFirst() {
      return List.super.getFirst();
  }
  

सुरक्षा

Android 15 में ऐसे बदलाव किए गए हैं जिनसे सिस्टम की सुरक्षा को बेहतर बनाया जा सके. इससे ऐप्लिकेशन और उपयोगकर्ताओं को नुकसान पहुंचाने वाले ऐप्लिकेशन से बचाने में मदद मिलती है.

बैकग्राउंड में सुरक्षित गतिविधि शुरू होना

Android 15, उपयोगकर्ताओं को नुकसान पहुंचाने वाले ऐप्लिकेशन से सुरक्षित रखता है. साथ ही, उन्हें अपने डिवाइसों पर ज़्यादा कंट्रोल देता है. इसके लिए, इसमें ऐसे बदलाव किए गए हैं जिनसे बैकग्राउंड में चल रहे नुकसान पहुंचाने वाले ऐप्लिकेशन, दूसरे ऐप्लिकेशन को फ़ोरग्राउंड पर नहीं ला पाते. साथ ही, वे अपने ऐक्सेस लेवल को बढ़ा नहीं पाते और उपयोगकर्ता के इंटरैक्शन का गलत इस्तेमाल नहीं कर पाते. इस तारीख से बैकग्राउंड में होने वाली गतिविधि के लॉन्च पर पाबंदी लगी हुई है Android 10 (एपीआई लेवल 29).

उन ऐप्लिकेशन को लॉन्च करने से रोकें जो स्टैक में मौजूद मुख्य यूआईडी से मेल नहीं खाते

नुकसान पहुंचाने वाले ऐप्लिकेशन उसी टास्क में किसी अन्य ऐप्लिकेशन की गतिविधि को लॉन्च कर सकते हैं. इसके बाद, अपने-आप को ओवरले कर लेता है, जिससे उस ऐप्लिकेशन के होने का भ्रम पैदा होता है. यह "टास्क हाइजैकिंग" हमले से वीडियो को बैकग्राउंड में लॉन्च करने की मौजूदा पाबंदियों को बायपास कर दिया जाता है. ऐसा इसलिए, क्योंकि उसी टास्क में होता हो जो उपयोगकर्ताओं को दिखता है. इस जोखिम को कम करने के लिए, Android 15 यह फ़्लैग उन ऐप्लिकेशन को लॉन्च होने से रोकता है जो स्टैक में मौजूद मुख्य यूआईडी से मेल नहीं खाते गतिविधियां. अपने ऐप्लिकेशन की सभी गतिविधियों में ऑप्ट इन करने के लिए, allowCrossUidActivitySwitchFromBelow विशेषता AndroidManifest.xml फ़ाइल में:

<application android:allowCrossUidActivitySwitchFromBelow="false" >

सुरक्षा से जुड़े नए उपाय तब चालू किए जा सकते हैं, जब:

• लॉन्च करने वाला ऐप्लिकेशन, Android 15 को टारगेट करता हो.
• टास्क स्टैक में सबसे ऊपर मौजूद ऐप्लिकेशन, Android 15 को टारगेट करता है.
• दिखने वाली किसी भी गतिविधि को, नई सुरक्षा सुविधाओं में ऑप्ट-इन किया गया है

अगर सुरक्षा उपाय चालू हैं, तो ऐप्लिकेशन ऐप्लिकेशन, जो अपना टास्क पूरा कर लेता है, वह आखिरी बार दिखने वाला ऐप्लिकेशन होता है.

अन्य बदलाव

यूआईडी मैच करने से जुड़ी पाबंदी के अलावा, इन अन्य बदलावों को भी शामिल किया गया है:

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

ज़्यादा सुरक्षित इंटेंट

Android 15 में, इंटेंट को ज़्यादा सुरक्षित और बेहतर बनाने के लिए, सुरक्षा से जुड़े नए विकल्प जोड़े गए हैं. हालांकि, इनका इस्तेमाल करना ज़रूरी नहीं है. इन बदलावों का मकसद, संभावित जोखिमों को रोकना और उन इंटेंट का गलत इस्तेमाल करना है जिनका इस्तेमाल नुकसान पहुंचाने वाले ऐप्लिकेशन कर सकते हैं. Android 15 में इंटेंट की सुरक्षा में दो मुख्य सुधार किए गए हैं:

• टारगेट इंटेंट-फ़िल्टर से मैच करना: किसी खास कॉम्पोनेंट को टारगेट करने वाले इंटेंट, टारगेट के इंटेंट-फ़िल्टर की खास बातों से सटीक तौर पर मैच होने चाहिए. अगर आपकी ओर से किसी दूसरे ऐप्लिकेशन की गतिविधि को लॉन्च करने का अनुरोध भेजा जाता है, तो टारगेट इंटेंट कॉम्पोनेंट को, सूचना पाने वाली गतिविधि के एलान किए गए इंटेंट फ़िल्टर के साथ अलाइन होना चाहिए.
• इंटेंट में कार्रवाइयां होनी चाहिए: बिना कार्रवाई वाले इंटेंट, अब किसी भी इंटेंट-फ़िल्टर से मैच नहीं करेंगे. इसका मतलब है कि गतिविधियों या सेवाओं को शुरू करने के लिए इस्तेमाल किए गए इंटेंट में, साफ़ तौर पर बताई गई कार्रवाई होनी चाहिए.

यह देखने के लिए कि आपका ऐप्लिकेशन इन बदलावों का जवाब कैसे देता है, अपने ऐप्लिकेशन में StrictMode का इस्तेमाल करें. Intent के इस्तेमाल से जुड़े उल्लंघनों के बारे में ज़्यादा जानकारी वाले लॉग देखने के लिए, यह तरीका जोड़ें:

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        .detectUnsafeIntentLaunch()
        .build()
    )
}

public void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
            .detectUnsafeIntentLaunch()
            .build());
}

उपयोगकर्ता अनुभव और सिस्टम का यूज़र इंटरफ़ेस (यूआई)

Android 15 में कुछ बदलाव किए गए हैं. इनका मकसद, उपयोगकर्ताओं को ज़्यादा बेहतर और आसान अनुभव देना है.

विंडो इनसेट में बदलाव

Android 15 में, विंडो इनसेट से जुड़े दो बदलाव किए गए हैं: डिफ़ॉल्ट रूप से, स्क्रीन के किनारों तक विंडो दिखती है. साथ ही, कॉन्फ़िगरेशन में भी बदलाव किए गए हैं. जैसे, सिस्टम बार का डिफ़ॉल्ट कॉन्फ़िगरेशन.

Edge-to-edge enforcement

अगर कोई ऐप्लिकेशन, Android 15 (एपीआई लेवल 35) को टारगेट करता है, तो Android 15 वाले डिवाइसों पर ऐप्लिकेशन डिफ़ॉल्ट रूप से एज-टू-एज दिखते हैं.

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

• जेस्चर हैंडल वाला नेविगेशन बार
  • डिफ़ॉल्ट रूप से पारदर्शी.
  • बॉटम ऑफ़सेट बंद है, ताकि जब तक इनसेट लागू नहीं किए जाते, तब तक कॉन्टेंट सिस्टम नेविगेशन बार के पीछे दिखे.
  • setNavigationBarColor और R.attr#navigationBarColor का इस्तेमाल अब नहीं किया जा सकता. इनसे जेस्चर नेविगेशन पर कोई असर नहीं पड़ता.
  • setNavigationBarContrastEnforced और R.attr#navigationBarContrastEnforced से, जेस्चर नेविगेशन पर अब भी कोई असर नहीं पड़ेगा.
• तीन बटन वाला नेविगेशन
  • ओपैसिटी डिफ़ॉल्ट रूप से 80% पर सेट होती है. साथ ही, इसका रंग विंडो के बैकग्राउंड से मैच करता है.
  • बॉटम ऑफ़सेट की सुविधा बंद है, ताकि जब तक इनसेट लागू नहीं किए जाते, तब तक कॉन्टेंट सिस्टम नेविगेशन बार के पीछे दिखे.
  • setNavigationBarColor और R.attr#navigationBarColor, डिफ़ॉल्ट रूप से विंडो के बैकग्राउंड से मैच करने के लिए सेट होते हैं. इस डिफ़ॉल्ट विकल्प को लागू करने के लिए, विंडो का बैकग्राउंड रंग में ड्रॉ किया जा सकने वाला होना चाहिए. इस एपीआई का इस्तेमाल अब नहीं किया जा सकता. हालांकि, तीन बटन वाले नेविगेशन पर इसका असर अब भी पड़ता है.
  • setNavigationBarContrastEnforced और R.attr#navigationBarContrastEnforced की वैल्यू डिफ़ॉल्ट रूप से 'सही' होती है. इससे तीन बटन वाले नेविगेशन में, 80% अपारदर्शी बैकग्राउंड जुड़ जाता है.
• स्टेटस बार
  • डिफ़ॉल्ट रूप से पारदर्शी.
  • टॉप ऑफ़सेट बंद है, ताकि जब तक इनसेट लागू न हों, तब तक कॉन्टेंट स्टेटस बार के पीछे दिखे.
  • setStatusBarColor और R.attr#statusBarColor का इस्तेमाल अब नहीं किया जा सकता. इनका Android 15 पर कोई असर नहीं पड़ेगा.
  • setStatusBarContrastEnforced और R.attr#statusBarContrastEnforced का इस्तेमाल अब नहीं किया जा सकता. हालांकि, इनका असर अब भी Android 15 पर पड़ता है.
• कटआउट दिखाना
  • नॉन-फ़्लोटिंग विंडो के layoutInDisplayCutoutMode की वैल्यू LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS होनी चाहिए. SHORT_EDGES, NEVER, और DEFAULT को ALWAYS के तौर पर समझा जाता है, ताकि उपयोगकर्ताओं को डिसप्ले के कटी हुई जगह की वजह से काला बार न दिखे और डिसप्ले किनारे से किनारे तक दिखे.

नीचे दिए गए उदाहरण में, Android 15 (एपीआई लेवल 35) को टारगेट करने से पहले और बाद के साथ-साथ, इनसेट लागू करने से पहले और बाद के ऐप्लिकेशन को दिखाया गया है.

अगर आपका ऐप्लिकेशन पहले से ही पूरे डिवाइस के साइज़ का है, तो क्या देखना चाहिए

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

• आपके पास ऐसी विंडो है जो फ़्लोटिंग नहीं है. जैसे, Activity, जो LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS के बजाय SHORT_EDGES, NEVER या DEFAULT का इस्तेमाल करती है. अगर आपका ऐप्लिकेशन लॉन्च होने पर क्रैश हो जाता है, तो ऐसा स्प्लैशस्क्रीन की वजह से हो सकता है. core splashscreen डिपेंडेंसी को 1.2.0-alpha01 या उसके बाद के वर्शन पर अपग्रेड किया जा सकता है या window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always सेट किया जा सकता है.
• हो सकता है कि कुछ स्क्रीन पर यूज़र इंटरफ़ेस (यूआई) का कुछ हिस्सा छिपा हो और उन पर कम ट्रैफ़िक हो. पुष्टि करें कि कम देखी गई इन स्क्रीन पर, यूज़र इंटरफ़ेस (यूआई) नहीं छिपा है. कम ट्रैफ़िक वाली स्क्रीन में ये शामिल हैं:
  • ऑनबोर्डिंग या साइन-इन स्क्रीन
  • सेटिंग पेज

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

अगर आपका ऐप्लिकेशन पहले से ही पूरे डिवाइस की स्क्रीन पर नहीं दिखता है, तो हो सकता है कि इस बदलाव का असर आप पर पड़े. पहले से ही पूरे डिवाइस के स्क्रीन साइज़ के ऐप्लिकेशन के अलावा, आपको इन बातों का भी ध्यान रखना चाहिए:

• अगर आपका ऐप्लिकेशन, कॉम्पोनेंट बनाने के लिए Material 3 कॉम्पोनेंट ( androidx.compose.material3) का इस्तेमाल करता है, जैसे कि TopAppBar, BottomAppBar, और NavigationBar, तो इन कॉम्पोनेंट पर कोई असर नहीं पड़ेगा, क्योंकि ये इनसेट को अपने-आप मैनेज करते हैं.
• अगर आपका ऐप्लिकेशन, Compose में Material 2 कॉम्पोनेंट ( androidx.compose.material) का इस्तेमाल कर रहा है, तो ये कॉम्पोनेंट अपने-आप इनसेट मैनेज नहीं करते. हालांकि, इनसेट का ऐक्सेस पाकर, उन्हें मैन्युअल तरीके से लागू किया जा सकता है. androidx.compose.material 1.6.0 और उसके बाद के वर्शन में, windowInsets पैरामीटर का इस्तेमाल करके, BottomAppBar, TopAppBar, BottomNavigation, और NavigationRail के लिए इनसेट को मैन्युअल तरीके से लागू करें. इसी तरह, Scaffold के लिए contentWindowInsets पैरामीटर का इस्तेमाल करें.
• अगर आपका ऐप्लिकेशन व्यू और Material Components (com.google.android.material) का इस्तेमाल करता है, तो BottomNavigationView, BottomAppBar, NavigationRailView या NavigationView जैसे ज़्यादातर व्यू-आधारित Material Components, इनसेट को मैनेज करते हैं और इसके लिए किसी और काम की ज़रूरत नहीं होती. हालांकि, AppBarLayout का इस्तेमाल करने पर, आपको android:fitsSystemWindows="true" जोड़ना होगा.
• कस्टम कॉम्पोज़ेबल के लिए, इनसेट को पैडिंग के तौर पर मैन्युअल तरीके से लागू करें. अगर आपका कॉन्टेंट Scaffold में है, तो Scaffold पैडिंग वैल्यू का इस्तेमाल करके इनसेट का इस्तेमाल किया जा सकता है. इसके अलावा, WindowInsets में से किसी एक का इस्तेमाल करके पैडिंग लागू करें.
• अगर आपका ऐप्लिकेशन व्यू और BottomSheet, SideSheet या कस्टम कंटेनर का इस्तेमाल कर रहा है, तो ViewCompat.setOnApplyWindowInsetsListener का इस्तेमाल करके पैडिंग लागू करें. RecyclerView के लिए, इस लिसनर का इस्तेमाल करके पैडिंग लागू करें. साथ ही, clipToPadding="false" भी जोड़ें.

बैकग्राउंड में काम करने वाले ऐप्लिकेशन को कस्टम सुरक्षा देने के लिए, क्या-क्या देखना चाहिए

अगर आपके ऐप्लिकेशन को तीन बटन वाले नेविगेशन या स्टेटस बार के लिए, बैकग्राउंड की कस्टम सुरक्षा की सुविधा देनी है, तो आपके ऐप्लिकेशन को WindowInsets.Type#tappableElement() का इस्तेमाल करके, सिस्टम बार के पीछे कोई कॉम्पोज़ेबल या व्यू डालना चाहिए. इससे, तीन बटन वाले नेविगेशन बार की ऊंचाई या WindowInsets.Type#statusBars की जानकारी मिलती है.

एज-टू-एज के लिए अन्य संसाधन

इनसेट लागू करने के बारे में ज़्यादा जानने के लिए, एज-टू-एज व्यू और एज-टू-एज कॉम्पोज़ के दिशा-निर्देश देखें.

बंद किए गए एपीआई

यहां दिए गए एपीआई बंद कर दिए गए हैं, लेकिन बंद नहीं किए गए हैं:

• R.attr#enforceStatusBarContrast
• R.attr#navigationBarColor (80% ऐल्फ़ा वाले तीन बटन वाले नेविगेशन के लिए)
• Window#isStatusBarContrastEnforced
• Window#setNavigationBarColor (तीन बटन वाले नेविगेशन के लिए, 80% ऐल्फ़ा के साथ)
• Window#setStatusBarContrastEnforced

यहां दिए गए एपीआई बंद कर दिए गए हैं:

• R.attr#navigationBarColor (जेस्चर वाले नेविगेशन के लिए)
• R.attr#navigationBarDividerColor
• R.attr#statusBarColor
• Window#setDecorFitsSystemWindows
• Window#getNavigationBarColor
• Window#getNavigationBarDividerColor
• Window#getStatusBarColor
• Window#setNavigationBarColor (जेस्चर वाले नेविगेशन के लिए)
• Window#setNavigationBarDividerColor
• Window#setStatusBarColor

Stable configuration

अगर आपका ऐप्लिकेशन Android 15 (एपीआई लेवल 35) या उसके बाद के वर्शन को टारगेट करता है, तो Configuration अब सिस्टम बार को शामिल नहीं करता. अगर लेआउट का हिसाब लगाने के लिए, Configuration क्लास में स्क्रीन साइज़ का इस्तेमाल किया जाता है, तो आपको इसे बेहतर विकल्पों से बदलना चाहिए. जैसे, अपनी ज़रूरत के हिसाब से ViewGroup, WindowInsets या WindowMetricsCalculator.

Configuration, एपीआई 1 से उपलब्ध है. आम तौर पर, यह जानकारी Activity.onConfigurationChanged से मिलती है. इसमें विंडो की डेंसिटी, ओरिएंटेशन, और साइज़ जैसी जानकारी मिलती है. Configuration से मिली विंडो के साइज़ की एक अहम खासियत यह है कि पहले इसमें सिस्टम बार शामिल नहीं थे.

कॉन्फ़िगरेशन साइज़ का इस्तेमाल आम तौर पर संसाधन चुनने के लिए किया जाता है, जैसे कि /res/layout-h500dp. यह अब भी इस्तेमाल का मान्य उदाहरण है. हालांकि, लेआउट के हिसाब लगाने के लिए, इसका इस्तेमाल करने का सुझाव नहीं दिया जाता. अगर ऐसा है, तो आपको अब इससे दूर हो जाना चाहिए. आपको अपने इस्तेमाल के उदाहरण के आधार पर, Configuration के इस्तेमाल को किसी और ज़्यादा सही चीज़ से बदलना चाहिए.

अगर लेआउट का हिसाब लगाने के लिए इसका इस्तेमाल किया जाता है, तो सही ViewGroup का इस्तेमाल करें, जैसे कि CoordinatorLayout या ConstraintLayout. अगर इसका इस्तेमाल सिस्टम के नेविगेशन बार की ऊंचाई तय करने के लिए किया जाता है, तो WindowInsets का इस्तेमाल करें. अगर आपको अपने ऐप्लिकेशन की विंडो का मौजूदा साइज़ जानना है, तो computeCurrentWindowMetrics का इस्तेमाल करें.

इस बदलाव से जिन फ़ील्ड पर असर पड़ा है उनके बारे में यहां बताया गया है:

• Configuration.screenWidthDp और screenHeightDp साइज़ में अब सिस्टम बार शामिल नहीं किए जाते.
• screenWidthDp और screenHeightDp में किए गए बदलावों का असर, Configuration.smallestScreenWidthDp पर भी पड़ता है.
• स्क्वेयर के करीब के डिवाइसों पर, screenWidthDp और screenHeightDp में किए गए बदलावों का Configuration.orientation पर असर पड़ता है.
• Configuration में किए गए बदलावों का असर, Display.getSize(Point) पर सीधे तौर पर नहीं पड़ता. एपीआई लेवल 30 से, इसे बंद कर दिया गया था.
• एपीआई लेवल 33 से ही Display.getMetrics() इस तरह काम कर रहा है.

elegantTextHeight एट्रिब्यूट की वैल्यू डिफ़ॉल्ट रूप से 'सही' पर सेट होती है

Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, elegantTextHeight TextView एट्रिब्यूट डिफ़ॉल्ट रूप से true हो जाता है. इससे, डिफ़ॉल्ट रूप से इस्तेमाल किए जाने वाले कॉम्पैक्ट फ़ॉन्ट की जगह, कुछ ऐसी स्क्रिप्ट का इस्तेमाल किया जाता है जिनमें बड़ी वर्टिकल मेट्रिक होती हैं. इन मेट्रिक को पढ़ना ज़्यादा आसान होता है. कॉम्पैक्ट फ़ॉन्ट को लेआउट के बीच में रुकावट आने से रोकने के लिए लॉन्च किया गया था. Android 13 (एपीआई लेवल 33), fallbackLineSpacing एट्रिब्यूट का इस्तेमाल करके, टेक्स्ट लेआउट की वर्टिकल ऊंचाई को बढ़ाकर, इनमें से कई रुकावटों को रोकता है.

Android 15 में, कॉम्पैक्ट फ़ॉन्ट अब भी सिस्टम में मौजूद है. इसलिए, आपका ऐप्लिकेशन पहले जैसा व्यवहार पाने के लिए, elegantTextHeight को false पर सेट कर सकता है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन में, इसकी सुविधा काम नहीं करेगी. इसलिए, अगर आपका ऐप्लिकेशन इन स्क्रिप्ट के साथ काम करता है: ऐरेबिक, लाओ, म्यांमार, तमिल, गुजराती, कन्नड़, मलयालम, उड़ीया, तेलुगु या थाई, तो elegantTextHeight को true पर सेट करके अपने ऐप्लिकेशन की जांच करें.

अक्षरों के जटिल आकार के लिए, TextView की चौड़ाई में बदलाव होता है

Android के पिछले वर्शन में, पेचीदा आकार वाले कुछ कर्सिव फ़ॉन्ट या भाषाएं, पिछले या अगले वर्ण के एरिया में अक्षर खींच सकती हैं. कुछ मामलों में, ऐसे अक्षरों को शुरुआत या आखिर में काटकर छोटा किया गया था. Android 15 से, TextView ऐसे अक्षरों के लिए ज़रूरी जगह बनाने के लिए चौड़ाई तय करता है. साथ ही, क्लिप बनाने से रोकने के लिए, ऐप्लिकेशन बाईं ओर ज़्यादा पैडिंग (जगह) का अनुरोध कर सकते हैं.

इस बदलाव का असर इस बात पर पड़ता है कि TextView, चौड़ाई का फ़ैसला कैसे लेता है. इसलिए, अगर ऐप्लिकेशन Android 15 (एपीआई लेवल 35) या उसके बाद के वर्शन को टारगेट करता है, तो TextView डिफ़ॉल्ट रूप से ज़्यादा चौड़ाई तय करता है. setUseBoundsForWidth पर एपीआई को कॉल करके, इस सुविधा को चालू या बंद किया जा सकता है.TextView

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

नीचे दिए गए उदाहरणों से पता चलता है कि इन बदलावों से कुछ फ़ॉन्ट और भाषाओं के लिए टेक्स्ट लेआउट को बेहतर कैसे बनाया जा सकता है.

कर्सिव फ़ॉन्ट में अंग्रेज़ी टेक्स्ट के लिए स्टैंडर्ड लेआउट. कुछ अक्षर काट दिए गए हैं. यहां उससे जुड़ा एक्सएमएल है:

<TextView
    android:fontFamily="cursive"
    android:text="java" />

अंग्रेज़ी के उसी टेक्स्ट का लेआउट जिसमें ज़्यादा चौड़ाई और पैडिंग है. यहां उससे जुड़ा एक्सएमएल है:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

थाई टेक्स्ट के लिए स्टैंडर्ड लेआउट. कुछ अक्षर काटे गए हैं. यहां उससे जुड़ा एक्सएमएल है:

<TextView
    android:text="คอมพิวเตอร์" />

ज़्यादा चौड़ाई और पैडिंग वाले एक ही थाई टेक्स्ट का लेआउट. यहां उससे जुड़ा एक्सएमएल है:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

EditText के लिए, स्थानीय भाषा के हिसाब से डिफ़ॉल्ट लाइन की ऊंचाई

Android के पिछले वर्शन में, टेक्स्ट लेआउट, टेक्स्ट की ऊंचाई को बढ़ा देता था, ताकि मौजूदा स्थानीय भाषा से मैच करने वाले फ़ॉन्ट की लाइन की ऊंचाई पूरी की जा सके. उदाहरण के लिए, अगर कॉन्टेंट जैपनीज़ में था, तो टेक्स्ट की ऊंचाई थोड़ी ज़्यादा हो गई, क्योंकि जैपनीज़ फ़ॉन्ट की लाइन की ऊंचाई, लैटिन फ़ॉन्ट की लाइन की ऊंचाई से थोड़ी ज़्यादा होती है. हालांकि, लाइन हाइट में इन अंतरों के बावजूद, इस्तेमाल किए जा रहे स्थानीय भाषा के बावजूद, EditText एलिमेंट का साइज़ एक जैसा था, जैसा कि इस इमेज में दिखाया गया है:

Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, EditText के लिए कम से कम लाइन हाइट तय की गई है. इससे, तय की गई लोकेल के रेफ़रंस फ़ॉन्ट से मैच करने में मदद मिलती है. इसकी जानकारी इस इमेज में दी गई है:

ज़रूरत पड़ने पर, आपका ऐप्लिकेशन useLocalePreferredLineHeightForMinimum एट्रिब्यूट को false पर सेट करके, पहले जैसा व्यवहार वापस ला सकता है. साथ ही, आपका ऐप्लिकेशन Kotlin और Java में setMinimumFontMetrics एपीआई का इस्तेमाल करके, कस्टम मिनिमम वर्टिकल मेट्रिक सेट कर सकता है.

कैमरा और मीडिया

Android 15 में, कैमरे और मीडिया के व्यवहार में ये बदलाव किए गए हैं. ये बदलाव, Android 15 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए किए गए हैं.

ऑडियो फ़ोकस का अनुरोध करने से जुड़ी पाबंदियां

Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन को ऑडियो फ़ोकस का अनुरोध करने के लिए, टॉप ऐप्लिकेशन या फ़ोरग्राउंड सेवा के तौर पर चलना होगा. अगर कोई ऐप्लिकेशन इनमें से किसी एक ज़रूरी शर्त को पूरा न करने पर फ़ोकस का अनुरोध करता है, तो कॉल AUDIOFOCUS_REQUEST_FAILED दिखाता है.

ऑडियो फ़ोकस के बारे में ज़्यादा जानने के लिए, ऑडियो फ़ोकस मैनेज करें पर जाएं.

SDK टूल के अलावा अन्य चीज़ों पर लगी पाबंदियां अपडेट की गईं

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

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

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

Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 15 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट देखें. आम तौर पर, SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर लगी पाबंदियां देखें.