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

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

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

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

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 का गड़बड़ी का मैसेज दिखाता है. जैसे, "फ़ोरग्राउंड सेवा के लिए समयसीमा खत्म हो चुकी है" डेटा सिंक करें.

टेस्ट करना

अपने ऐप्लिकेशन के व्यवहार की जांच करने के लिए, डेटा सिंक टाइम आउट की सुविधा चालू की जा सकती है. भले ही, आपका ऐप्लिकेशन 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 रिसीवर को फ़ोरग्राउंड सेवाओं के ये टाइप हैं:

अगर 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() एपीआई का इस्तेमाल करते समय, आर्ग्युमेंट इंडेक्स, फ़्लैग, चौड़ाई, और सटीक वैल्यू की पुष्टि करने के लिए ज़्यादा सख्त नियम लागू होंगे:

    उदाहरण के लिए, जब फ़ॉर्मैट स्ट्रिंग में 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 API का इस्तेमाल करते समय, हिब्रू, येडिश, और इंडोनेशियाई भाषा के कोड अब पुराने फ़ॉर्मैट में नहीं बदले जाते (हिब्रू: iw, येडिश: ji, और इंडोनेशियाई: in). इनमें से किसी एक भाषा के लिए भाषा कोड तय करते समय, ISO 639-1 से कोड इस्तेमाल करें (हिब्रू: he, येडिश: yi, और इंडोनेशियाई: id).

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

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

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

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

    Java में List टाइप को Kotlin में MutableList टाइप पर मैप किया जाता है. List.removeFirst() और List.removeLast() एपीआई, Android 15 (एपीआई लेवल 35) में पेश किए गए हैं. इसलिए, 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 लिंट विकल्प, एपीआई के इन नए इस्तेमाल का पता लगा सकता है.

    ./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 restricts the usage of TLS versions 1.0 and 1.1. These versions had previously been deprecated in Android, but are now disallowed for apps targeting Android 15.

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

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

अन्य बदलाव

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

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

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

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

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

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

Kotlin

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

Java

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

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

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

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

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

Edge-to-edge enforcement

如果应用以 Android 15（API 级别 35）为目标平台，则在搭载 Android 15 的设备上默认以无边框显示。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。


以 Android 15（API 级别 35）为目标平台且在 Android 15 设备上实现全屏显示的应用。此应用主要使用会自动应用边衬区的 Material 3 Compose 组件。此屏幕不受 Android 15 强制执行的无边框措施的负面影响。

这是一项重大变更，可能会对应用的界面产生负面影响。这些更改会影响以下界面区域：

  • 手势柄导航栏
    • 默认透明。
    • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
    • setNavigationBarColor 和 R.attr#navigationBarColor 已被弃用，不会影响手势导航。
    • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 继续对基于手势的导航没有任何影响。
  • “三按钮”导航
    • 默认情况下，不透明度设置为 80%，颜色可能与窗口背景颜色一致。
    • 底部偏移量处于停用状态，因此内容会绘制在系统导航栏后面，除非应用了边衬区。
    • 默认情况下，setNavigationBarColor 和 R.attr#navigationBarColor 设置为与窗口背景相匹配。窗口背景必须是颜色可绘制对象，才能应用此默认值。此 API 已弃用，但仍会影响三按钮导航。
    • setNavigationBarContrastEnforced 和 R.attr#navigationBarContrastEnforced 默认值为 true，这会在三按钮导航栏中添加 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（API 级别 35）为目标平台之前和之后，以及在应用边衬区之前和之后的效果。此示例并不全面，在 Android Auto 上可能会显示不同的内容。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。
以 Android 15（API 级别 35）为目标平台且在 Android 15 设备上实现全屏显示的应用。不过，由于 Android 15 强制执行边缘到边缘显示，许多元素现在会被状态栏、三按钮导航栏或刘海屏遮挡。隐藏界面包括 Material 2 顶部应用栏、悬浮操作按钮和列表项。
以 Android 15（API 级别 35）为目标平台的应用在 Android 15 设备上是全屏显示，并应用了边衬区，因此界面不会被隐藏。
如果应用已实现全屏显示，需要检查哪些方面

如果您的应用已实现全屏显示并应用边衬区，则在大多数情况下不会受到影响，但以下情形除外。不过，即使您认为自己不受影响，我们仍建议您测试应用。

  • 您有一个非浮动窗口，例如使用 SHORT_EDGES、NEVER 或 DEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS 的 Activity。如果您的应用在启动时崩溃，这可能是由启动画面引起的。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本，也可以设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always。
  • 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括：
    • 初始配置或登录界面
    • “设置”页面
如果您的应用尚未实现全屏显示，需要检查哪些方面

如果您的应用尚未实现全屏显示，则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外，您还应考虑以下事项：

  • 如果您的应用在 Compose 中使用 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 组件 (com.google.android.material)，则大多数基于视图的 Material 组件（例如 BottomNavigationView、BottomAppBar、NavigationRailView 或 NavigationView）都会处理边衬区，因此不需要执行额外的操作。不过，如果使用的是 AppBarLayout，则需要添加 android:fitsSystemWindows="true"。
  • 对于自定义可组合项，请手动应用边衬区作为内边距。如果您的内容位于 Scaffold 内，则可以使用 Scaffold 内边距值来使用插边。否则，请使用 WindowInsets 之一应用内边距。
  • 如果应用使用的是视图和 BottomSheet、SideSheet 或自定义容器，请使用 ViewCompat.setOnApplyWindowInsetsListener 应用内边距。对于 RecyclerView，请使用此监听器应用内边距，同时添加 clipToPadding="false"。
如果应用必须提供自定义后台保护，需要检查哪些方面

如果您的应用必须为三按钮导航或状态栏提供自定义背景保护，则应使用 WindowInsets.Type#tappableElement() 或 WindowInsets.Type#statusBars 将可组合项或视图放置在系统栏后面，以获取三按钮导航栏高度。

其他全屏显示资源

如需了解有关应用边衬区的其他注意事项，请参阅全屏视图和全屏 Compose 指南。

已弃用的 API

以下 API 已弃用，但未停用：

以下 API 已弃用并停用：

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

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

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

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

elegantTextHeight Android 14 (एपीआई लेवल 34) और उससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए व्यवहार.
elegantTextHeight Android 15 को टारगेट करने वाले ऐप्लिकेशन के लिए व्यवहार.

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

In previous versions of Android, some cursive fonts or languages that have complex shaping might draw the letters in the previous or next character's area. In some cases, such letters were clipped at the beginning or ending position. Starting in Android 15, a TextView allocates width for drawing enough space for such letters and allows apps to request extra paddings to the left to prevent clipping.

Because this change affects how a TextView decides the width, TextView allocates more width by default if the app targets Android 15 (API level 35) or higher. You can enable or disable this behavior by calling the setUseBoundsForWidth API on TextView.

Because adding left padding might cause a misalignment for existing layouts, the padding is not added by default even for apps that target Android 15 or higher. However, you can add extra padding to preventing clipping by calling setShiftDrawingOffsetForStartOverhang.

The following examples show how these changes can improve text layout for some fonts and languages.

Standard layout for English text in a cursive font. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Layout for the same English text with additional width and padding. Here is the corresponding XML:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
Standard layout for Thai text. Some of the letters are clipped. Here is the corresponding XML:

<TextView
    android:text="คอมพิวเตอร์" />
Layout for the same Thai text with additional width and padding. Here is the corresponding XML:

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

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

在较低版本的 Android 中，文本布局会拉伸文本的高度，以满足与当前语言区域匹配的字体的行高。例如，如果内容是日语，由于日语字体的行高略高于拉丁字体，因此文本的高度会略高。不过，尽管行高存在这些差异，但无论使用的是哪种语言区域，EditText 元素的大小都是统一的，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度相同，即使这些语言的行高各不相同。

对于以 Android 15（API 级别 35）为目标平台的应用，现在为 EditText 预留了最小行高，以匹配指定语言区域的参考字体，如下图所示：

三个框，表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度现在包含足够的空间来容纳这些语言字体的默认行高。

如有需要，您的应用可以将 useLocalePreferredLineHeightForMinimum 属性指定为 false，以恢复之前的行为；您的应用还可以在 Kotlin 和 Java 中使用 setMinimumFontMetrics API 设置自定义最小垂直指标。

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

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

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

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

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

एसडीके इंटिग्रेट किए बगैर इस्तेमाल की जाने वाली सुविधाओं पर लगी पाबंदियां अपडेट की गईं

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

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

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

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