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

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

ऐप्लिकेशन के व्यवहार में होने वाले उन बदलावों की सूची देखना न भूलें जिनका असर सभी ऐप्लिकेशन पर पड़ता है चाहे, आपके ऐप्लिकेशन का targetSdkVersion कोई भी हो, जो Android 15 पर चल रहा हो.

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

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

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

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

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

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 सेवाओं को कुल 6 तक चलने की अनुमति देता है 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 फ़ोरग्राउंड सेवा का इस्तेमाल करने के बजाय, किसी अन्य सेवा का इस्तेमाल करें API, जैसे कि WorkManager.

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

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 रिसीवर को फ़ोरग्राउंड सेवाओं के ये टाइप हैं:

अगर 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

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

Apps that target Android 15 (API level 35) and higher can no longer change the global state or policy of Do Not Disturb (DND) on a device (either by modifying user settings, or turning off DND mode). Instead, apps must contribute an AutomaticZenRule, which the system combines into a global policy with the existing most-restrictive-policy-wins scheme. Calls to existing APIs that previously affected global state (setInterruptionFilter, setNotificationPolicy) result in the creation or update of an implicit AutomaticZenRule, which is toggled on and off depending on the call-cycle of those API calls.

Note that this change only affects observable behavior if the app is calling setInterruptionFilter(INTERRUPTION_FILTER_ALL) and expects that call to deactivate an AutomaticZenRule that was previously activated by their owners.

OpenJDK एपीआई में बदलाव

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

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

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

    उदाहरण के लिए, 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).

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

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

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

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

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

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

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

    'Android Gradle प्लग इन' में मौजूद NewApi लिंट विकल्प इन्हें पकड़ सकता है एपीआई के नए इस्तेमाल के बारे में जानकारी.

    ./gradlew lint

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

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

    अगर लिंट विकल्प बंद किया गया है, तो @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

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

    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.getLast();
}

सुरक्षा

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 में इंटेंट की सुरक्षा में किए गए सुधार:

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

Kotlin


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

Java


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

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

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

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

There are two changes related to window insets in Android 15: edge-to-edge is enforced by default, and there are also configuration changes, such as the default configuration of system bars.

Edge-to-edge enforcement

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

ऐसा ऐप्लिकेशन जो Android 14 को टारगेट करता है और Android 15 डिवाइस.


ऐसा ऐप्लिकेशन जो Android 15 (एपीआई लेवल 35) को टारगेट करता है और एक से दूसरी जगह तक जाता है Android 15 वाले डिवाइस पर. इस ऐप्लिकेशन में ज़्यादातर मटीरियल 3 कंपोज़ कॉम्पोनेंट का इस्तेमाल किया जाता है जो अपने-आप इनसेट लागू करते हैं. इस स्क्रीन पर, 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) और इनसेट को लागू करने से पहले और बाद में इस्तेमाल किया जा सकता है.

ऐसा ऐप्लिकेशन जो Android 14 को टारगेट करता है और Android 15 डिवाइस.
ऐसा ऐप्लिकेशन जो Android 15 (एपीआई लेवल 35) को टारगेट करता है और एक से दूसरी जगह तक जाता है Android 15 वाले डिवाइस पर. हालांकि, कई एलिमेंट अब स्थिति की वजह से छिपा दिए जाते हैं बार, तीन बटन वाला नेविगेशन बार या डिसप्ले कटआउट की वजह से Android 15 नीति उल्लंघन ठीक करने के तरीके (एनफ़ोर्समेंट) इस्तेमाल किए जा सकते हैं. छिपे हुए यूज़र इंटरफ़ेस (यूआई) में मटीरियल 2 शामिल है कोई ऐप्लिकेशन बार, फ़्लोटिंग ऐक्शन बटन, और सूची आइटम.
Android 15 (एपीआई लेवल 35) को टारगेट करने वाला ऐप्लिकेशन, एक से दूसरी जगह ऐक्सेस किया जा सकता है Android 15 डिवाइस हो और इनसेट लागू करता हो, ताकि यूज़र इंटरफ़ेस (यूआई) छिपा हुआ है.
क्या पता करना चाहिए कि आपका ऐप्लिकेशन पहले से ही किसी एज-टू-एज पर है या नहीं

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

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

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

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

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

एक-दूसरे से जुड़े हुए अतिरिक्त संसाधन

Edge to Edge View और Edge to Edge Compose देखें गाइड पढ़ें.

ऐसे एपीआई जो अब काम नहीं करते

इन एपीआई का अब इस्तेमाल नहीं किया जा सकता:

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

ColorfulTextHight एट्रिब्यूट, डिफ़ॉल्ट रूप से 'सही' पर सेट होता है

For apps targeting Android 15 (API level 35), the elegantTextHeight TextView attribute becomes true by default, replacing the compact font used by default with some scripts that have large vertical metrics with one that is much more readable. The compact font was introduced to prevent breaking layouts; Android 13 (API level 33) prevents many of these breakages by allowing the text layout to stretch the vertical height utilizing the fallbackLineSpacing attribute.

In Android 15, the compact font still remains in the system, so your app can set elegantTextHeight to false to get the same behavior as before, but it is unlikely to be supported in upcoming releases. So, if your app supports the following scripts: Arabic, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu or Thai, test your app by setting elegantTextHeight to true.

elegantTextHeight behavior for apps targeting Android 14 (API level 34) and lower.
elegantTextHeight behavior for apps targeting Android 15.

अक्षर वाले मुश्किल आकारों के लिए, TextView की चौड़ाई में बदलाव

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

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

बाईं ओर की पैडिंग जोड़ने से, मौजूदा लेआउट के साथ गलत अलाइनमेंट हो सकता है. 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" />

एडिट टेक्स्ट के लिए स्थान-भाषा की डिफ़ॉल्ट लाइन की ऊंचाई

In previous versions of Android, the text layout stretched the height of the text to meet the line height of the font that matched the current locale. For example, if the content was in Japanese, because the line height of the Japanese font is slightly larger than the one of a Latin font, the height of the text became slightly larger. However, despite these differences in line heights, the EditText element was sized uniformly, regardless of the locale being used, as illustrated in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText is the same, even though these languages have different line heights from each other.

For apps targeting Android 15 (API level 35), a minimum line height is now reserved for EditText to match the reference font for the specified Locale, as shown in the following image:

Three boxes representing EditText elements that can contain text from English (en), Japanese (ja), and Burmese (my). The height of the EditText now includes space to accommodate the default line height for these languages' fonts.

If needed, your app can restore the previous behavior by specifying the useLocalePreferredLineHeightForMinimum attribute to false, and your app can set custom minimum vertical metrics using the setMinimumFontMetrics API in Kotlin and Java.

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

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

ऑडियो फ़ोकस के अनुरोध पर लागू होने वाली पाबंदियां

Apps that target Android 15 (API level 35) must be the top app or running a foreground service in order to request audio focus. If an app attempts to request focus when it does not meet one of these requirements, the call returns AUDIOFOCUS_REQUEST_FAILED.

You can learn more about audio focus at Manage audio focus.

बिना SDK टूल के अपडेट की गई पाबंदियां

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

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

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

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 15. To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces.