पिछली रिलीज़ की तरह, 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]"
इस बदलाव की वजह से होने वाली समस्याओं से बचने के लिए, इनमें से एक या एक से ज़्यादा काम किए जा सकते हैं:
- अपनी सेवा में
Service.onTimeout(int, int)
का नया तरीका लागू करें. जब आपके ऐप्लिकेशन को कॉलबैक मिल जाए, तोstopSelf()
को कुछ सेकंड के अंदर कॉल करना न भूलें. (अगर ऐप्लिकेशन को तुरंत नहीं रोका जाता, तो सिस्टम गड़बड़ी जनरेट करता है.) - पक्का करें कि आपके ऐप्लिकेशन की
dataSync
सेवाएं किसी भी 24 घंटे में कुल छह घंटे से ज़्यादा न चलें (जब तक कि उपयोगकर्ता टाइमर को रीसेट करके ऐप्लिकेशन से इंटरैक्ट न करे). dataSync
फ़ोरग्राउंड सेवाओं को सिर्फ़ उपयोगकर्ता के सीधे इंटरैक्शन के ज़रिए शुरू करें. सेवा शुरू होने पर, आपका ऐप्लिकेशन फ़ोरग्राउंड में होता है. इसलिए, ऐप्लिकेशन के बैकग्राउंड में जाने के बाद भी, आपकी सेवा के पास पूरे छह घंटे होते हैं.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]"
अपवाद से बचने के लिए, इनमें से कोई एक काम किया जा सकता है:
- अपनी सेवा में
Service.onTimeout(int, int)
का नया तरीका लागू करें. जब आपके ऐप्लिकेशन को कॉलबैक मिलता है, तो कुछ सेकंड के अंदरstopSelf()
को कॉल करना न भूलें. (अगर ऐप्लिकेशन को तुरंत नहीं रोका जाता, तो सिस्टम गड़बड़ी जनरेट करता है.) - पक्का करें कि आपके ऐप्लिकेशन की
mediaProcessing
सेवाएं, 24 घंटे में कुल छह घंटे से ज़्यादा न चलें. ऐसा तब तक नहीं होगा, जब तक उपयोगकर्ता ऐप्लिकेशन के साथ इंटरैक्ट करके, टाइमर को रीसेट नहीं करता. - सीधे उपयोगकर्ता के साथ इंटरैक्शन होने पर ही,
mediaProcessing
फ़ोरग्राउंड सेवाएं शुरू करें. सेवा शुरू होने के समय, आपका ऐप्लिकेशन फ़ोरग्राउंड में होता है. इसलिए, ऐप्लिकेशन के बैकग्राउंड में चलने के बाद, आपकी सेवा को पूरे छह घंटे तक चालू रखा जाता है. 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 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策(通过修改用户设置或关闭 DND 模式)。相反,应用必须提供一个 AutomaticZenRule
,系统会将后者合并到一个具有现有最严格的政策胜出方案的全局政策中。调用之前影响全局状态的现有 API(setInterruptionFilter
、setNotificationPolicy
)会导致创建或更新隐式 AutomaticZenRule
,该 AutomaticZenRule
根据这些 API 调用的调用周期而开启或关闭。
请注意,只有在应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL)
且预期调用会停用之前由其所有者激活的 AutomaticZenRule
时,此变更才会影响可观察的行为。
OpenJDK एपीआई में बदलाव
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()
तरीकों से जनरेट किया गया क्रम,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 लेडीबग | 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गड़बड़ी 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.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
के इस्तेमाल से जुड़े उल्लंघनों के बारे में ज़्यादा जानकारी वाले लॉग देखने के लिए, यह तरीका जोड़ें:
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
public void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() .detectUnsafeIntentLaunch() .build()); }
उपयोगकर्ता अनुभव और सिस्टम यूज़र इंटरफ़ेस (यूआई)
Android 15 में कुछ बदलाव किए गए हैं. इनका मकसद, उपयोगकर्ताओं को ज़्यादा बेहतर और आसान अनुभव देना है.
विंडो इनसेट में बदलाव
Android 15 中有两个与窗口边衬区相关的变更:默认强制执行无边框模式;还存在配置变更,例如系统栏的默认配置。
全面实施政策
अगर ऐप्लिकेशन, 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
का इस्तेमाल करती है. अगर आपका ऐप्लिकेशन लॉन्च होने पर क्रैश हो जाता है, तो ऐसा स्प्लैशस्क्रीन की वजह से हो सकता है. कोर स्प्लैशस्क्रीन डिपेंडेंसी को 1.2.0-alpha01 या इसके बाद वाले वर्शन पर अपग्रेड किया जा सकता है. इसके अलावा,window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
को सेट किया जा सकता है. - हो सकता है कि कुछ स्क्रीन पर यूज़र इंटरफ़ेस (यूआई) का कुछ हिस्सा छिपा हो और उन पर कम ट्रैफ़िक हो. पुष्टि करें कि कम देखी गई इन स्क्रीन पर, यूज़र इंटरफ़ेस (यूआई) नहीं छिपा है. कम ट्रैफ़िक वाली स्क्रीन में ये शामिल हैं:
- ऑनबोर्डिंग या साइन-इन स्क्रीन
- सेटिंग पेज
अगर आपका ऐप्लिकेशन पहले से ही पूरे डिवाइस के साइज़ का नहीं है, तो क्या देखना चाहिए
अगर आपका ऐप्लिकेशन पहले से बेहतर नहीं है, तो इसका सबसे ज़्यादा असर आपके ऐप्लिकेशन पर पड़ सकता है. पहले से एक-दूसरे के पास मौजूद ऐप्लिकेशन के अलावा, दूसरी स्थितियों में भी आपको इन चीज़ों पर ध्यान देना चाहिए:
- अगर आपके ऐप्लिकेशन में
TopAppBar
,BottomAppBar
, औरNavigationBar
जैसे मटीरियल 3 कॉम्पोनेंट (androidx.compose.material3
) का इस्तेमाल किया जाता है, तो हो सकता है कि इन कॉम्पोनेंट पर असर नहीं हो, क्योंकि ये इनसेट को अपने-आप हैंडल करते हैं. - अगर आपका ऐप्लिकेशन, 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
R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#isStatusBarContrastEnforced
Window#setDecorFitsSystemWindows
Window#setNavigationBarColor
Window#setNavigationBarDividerColor
Window#setStatusBarColor
Window#setStatusBarContrastEnforced
稳定配置
अगर आपका ऐप्लिकेशन 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 为目标平台的应用,elegantTextHeight
TextView
属性默认变为 true
,将默认使用的紧凑字体替换为一些具有较大垂直指标的脚本,并且这种字体更易于阅读。紧凑字体的引入是为了防止破坏布局;Android 13(API 级别 33)允许文本布局利用 fallbackLineSpacing
属性拉伸垂直高度,以防止许多此类破坏。
在 Android 15 中,紧凑字体仍保留在系统中,因此您的应用可以将 elegantTextHeight
设置为 false
,以获得与之前相同的行为,但即将在未来版本中提供支持。因此,如果您的应用支持以下文字:阿拉伯语、老挝语、缅甸、泰米尔语、古吉拉特语、卡纳达语、马拉雅拉姆语、奥里亚语、泰卢固语或泰语,请将 elegantTextHeight
设置为 true
,以测试应用。
अक्षर वाले जटिल आकारों के लिए TextView की चौड़ाई में बदलाव
Android के पिछले वर्शन में, पेचीदा आकार वाले कुछ कर्सिव फ़ॉन्ट या भाषाएं, पिछले या अगले वर्ण के एरिया में अक्षर खींच सकती हैं.
कुछ मामलों में, ऐसे अक्षरों को शुरुआत या आखिर में काटकर छोटा किया गया था.
Android 15 से, TextView
ऐसे अक्षरों के लिए ज़रूरी जगह बनाने के लिए
चौड़ाई तय करता है. साथ ही, क्लिप बनाने से रोकने के लिए,
ऐप्लिकेशन बाईं ओर ज़्यादा पैडिंग (जगह) का अनुरोध कर सकते हैं.
इस बदलाव का असर इस बात पर पड़ता है कि TextView
, चौड़ाई का फ़ैसला कैसे लेता है. इसलिए, अगर ऐप्लिकेशन Android 15 (एपीआई लेवल 35) या उसके बाद के वर्शन को टारगेट करता है, तो TextView
डिफ़ॉल्ट रूप से ज़्यादा चौड़ाई तय करता है. setUseBoundsForWidth
पर एपीआई को कॉल करके, इस सुविधा को चालू या बंद किया जा सकता है.TextView
बाईं ओर की पैडिंग जोड़ने से, हो सकता है कि मौजूदा लेआउट गलत तरीके से अलाइन हो जाएं. ऐसा होने पर, Android 15 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए भी पैडिंग (जगह) डिफ़ॉल्ट रूप से नहीं जोड़ी जाती.
हालांकि, setShiftDrawingOffsetForStartOverhang
को कॉल करके, क्लिपिंग को रोकने के लिए अतिरिक्त पैडिंग जोड़ी जा सकती है.
नीचे दिए गए उदाहरणों से पता चलता है कि इन बदलावों से कुछ फ़ॉन्ट और भाषाओं के लिए टेक्स्ट लेआउट को बेहतर कैसे बनाया जा सकता है.
EditText के लिए, स्थानीय भाषा के हिसाब से डिफ़ॉल्ट लाइन की ऊंचाई
在以前的 Android 版本中,文本布局拉伸了文本的高度,使其适应与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高比拉丁字体的行高略大,因此文本的高度就略大了。不过,尽管行高存在这些差异,但无论使用何种语言区域,EditText
元素的大小都是一致的,如下图所示:
对于以 Android 15 为目标平台的应用,系统现在会为 EditText
预留最小行高,以匹配指定语言区域的参考字体,如下图所示:
如果需要,您的应用可以通过将 useLocalePreferredLineHeightForMinimum
属性设置为 false
来恢复之前的行为,并且可以通过 Kotlin 和 Java 中的 setMinimumFontMetrics
API 设置自定义最小行业指标。
कैमरा और मीडिया
Android 15 में, कैमरे और मीडिया के व्यवहार में ये बदलाव किए गए हैं. ये बदलाव, Android 15 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए किए गए हैं.
ऑडियो फ़ोकस के अनुरोध पर लागू होने वाली पाबंदियां
以 Android 15 为目标平台的应用必须是顶级应用或运行前台服务,才能请求音频焦点。如果应用在不符合其中任何一项要求时尝试请求焦点,该调用将返回 AUDIOFOCUS_REQUEST_FAILED
。
您可以参阅管理音频焦点,详细了解音频焦点。
बिना SDK टूल के अपडेट की गई पाबंदियां
Android 15 में, पाबंदी वाले ऐसे इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं जो एसडीके टूल नहीं हैं. ये सूचियां, Android डेवलपर के साथ मिलकर की गई जांच और नई इंटरनल जांच के आधार पर बनाई गई हैं. जब भी मुमकिन हो, हम यह पक्का करते हैं कि बिना SDK टूल वाले इंटरफ़ेस पर पाबंदी लगाने से पहले, हम यह पक्का करते हैं कि सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 15 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के आधार पर, आपके ऐप्लिकेशन के पास कुछ ऐसे इंटरफ़ेस को ऐक्सेस करने का विकल्प होता है जो SDK टूल के नहीं होते. हालांकि, SDK टूल के अलावा किसी भी तरीके या फ़ील्ड का इस्तेमाल करने पर, आपके ऐप्लिकेशन के क्रैश होने का खतरा हमेशा बना रहता है.
अगर आपको नहीं पता कि आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो इसकी पुष्टि करने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस पर निर्भर है, तो आपको SDK टूल के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. फिर भी, हम समझते हैं कि कुछ ऐप्लिकेशन में गैर-SDK इंटरफ़ेस का इस्तेमाल करने के लिए मान्य इस्तेमाल के उदाहरण होते हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, SDK के अलावा किसी दूसरे इंटरफ़ेस का इस्तेमाल करने का विकल्प नहीं मिल रहा है, तो आपको नए सार्वजनिक एपीआई का अनुरोध करना चाहिए.
如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。