पिछले रिलीज़ की तरह ही, Android 15 में भी ऐप्लिकेशन के काम करने के तरीके में बदलाव किए गए हैं. इन बदलावों का आपके ऐप्लिकेशन पर असर पड़ सकता है. ऐप्लिकेशन के काम करने के तरीके में ये बदलाव, सिर्फ़ उन ऐप्लिकेशन पर लागू होते हैं जो Android 15 या इसके बाद के वर्शन को टारगेट करते हैं. अगर आपका ऐप्लिकेशन Android 15 या उसके बाद के वर्शन को टारगेट कर रहा है, तो आपको अपने ऐप्लिकेशन में बदलाव करना चाहिए, ताकि जहां भी लागू हो वहां इन बदलावों का सही तरीके से इस्तेमाल किया जा सके.
Android 15 पर काम करने वाले सभी ऐप्लिकेशन पर असर डालने वाले बदलावों की सूची भी देखना न भूलें. भले ही, आपके ऐप्लिकेशन का targetSdkVersion कुछ भी हो.
मुख्य फ़ंक्शन
Android 15 में, Android सिस्टम की कई मुख्य सुविधाओं में बदलाव किया गया है या उन्हें बेहतर बनाया गया है.
फ़ोरग्राउंड सेवाओं में हुए बदलाव
हम Android 15 में फ़ोरग्राउंड सेवाओं में ये बदलाव कर रहे हैं.
- डेटा सिंक करने वाली फ़ोरग्राउंड सेवा के टाइम आउट का व्यवहार
- मीडिया प्रोसेस करने वाली नई फ़ोरग्राउंड सेवा का टाइप
- फ़ोरग्राउंड सेवाएं लॉन्च करने वाले
BOOT_COMPLETEDब्रॉडकास्ट रिसीवर पर पाबंदियां - ऐप्लिकेशन के पास
SYSTEM_ALERT_WINDOWअनुमति होने पर, फ़ोरग्राउंड सेवाएं शुरू करने से जुड़ी पाबंदियां
डेटा सिंक करने वाली फ़ोरग्राउंड सेवा के टाइम आउट का व्यवहार
对于以 Android 15（API 级别 35）或更高版本为目标平台的应用，Android 15 为 dataSync 引入了新的超时行为。此行为也适用于新的 mediaProcessing 前台服务类型。
系统允许应用的 dataSync 服务在 24 小时内共运行 6 小时，之后系统会调用正在运行的服务的 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 小时内总运行时间不超过 6 小时（除非用户与应用互动，重置计时器）。 - 仅在有直接用户互动时启动
dataSync前台服务；由于服务启动时应用位于前台，因此您的服务在应用进入后台后有完整的 6 小时时间。 - 请使用替代 API，而不是使用
dataSync前台服务。
如果您的应用的 dataSync 前台服务在过去 24 小时内运行了 6 小时，则您无法启动其他 dataSync 前台服务，除非用户已将您的应用切换到前台（这会重置计时器）。如果您尝试启动其他 dataSync 前台服务，系统会抛出 ForegroundServiceStartNotAllowedException，并显示类似“前台服务类型 dataSync 的时间限制已用尽”的错误消息。
测试
如需测试应用的行为，即使您的应用并非以 Android 15 为目标平台（只要该应用在 Android 15 设备上运行），您也可以启用数据同步超时。如需启用超时，请运行以下 adb 命令：
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
您还可以调整超时期限，以便更轻松地测试应用在达到上限时的行为方式。如需设置新的超时期限，请运行以下 adb 命令：
adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds
मीडिया प्रोसेस करने वाली नई फ़ोरग्राउंड सेवा का टाइप
Android 15 में, फ़ोरग्राउंड सेवा का एक नया टाइप mediaProcessing जोड़ा गया है. यह सेवा टाइप, मीडिया फ़ाइलों को ट्रांसकोड करने जैसे कामों के लिए सही है. उदाहरण के लिए, कोई मीडिया ऐप्लिकेशन किसी ऑडियो फ़ाइल को डाउनलोड कर सकता है और उसे चलाने से पहले, किसी दूसरे फ़ॉर्मैट में बदल सकता है. mediaProcessing फ़ोरग्राउंड सेवा का इस्तेमाल करके, यह पक्का किया जा सकता है कि ऐप्लिकेशन बैकग्राउंड में होने पर भी कन्वर्ज़न जारी रहे.
सिस्टम किसी ऐप्लिकेशन की mediaProcessing सेवाओं को 24 घंटों में कुल छह घंटे चलाने की अनुमति देता है. इसके बाद, सिस्टम, मौजूदा सेवा के Service.onTimeout(int, int) तरीके को कॉल करता है (Android 15 में शुरू किया गया). फ़िलहाल, Service.stopSelf() को कॉल करने के लिए सेवा को कुछ सेकंड मिलेंगे. अगर सेवा Service.stopSelf() को कॉल नहीं करती है, तो सिस्टम में कोई इंटरनल अपवाद दिखता है. अपवाद को Logcat में लॉग इन किया जाता है जिसमें यह मैसेज शामिल है:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
अपवाद से बचने के लिए, इनमें से कोई एक काम किया जा सकता है:
- अपनी सेवा में
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 रिसीवर को
फ़ोरग्राउंड सेवाओं के ये टाइप हैं:
dataSynccameramediaPlaybackphoneCallmediaProjectionmicrophone(यह पाबंदीmicrophoneके लिए तब से लागू है Android 14)
अगर BOOT_COMPLETED रिसीवर इनमें से किसी भी तरह के फ़ोरग्राउंड को लॉन्च करने की कोशिश करता है
सिस्टम, ForegroundServiceStartNotAllowedException की जानकारी देता है.
टेस्ट करना
अपने ऐप्लिकेशन के व्यवहार की जांच करने के लिए, ये नई पाबंदियां चालू की जा सकती हैं. भले ही, आपका ऐप्लिकेशन Android 15 को टारगेट न करता हो. हालांकि, यह ज़रूरी है कि ऐप्लिकेशन Android 15 वाले डिवाइस पर चल रहा हो. यहां दिया गया adb निर्देश चलाएं:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
डिवाइस को रीस्टार्ट किए बिना BOOT_COMPLETED ब्रॉडकास्ट भेजने के लिए,
नीचे दिया गया adb निर्देश चलाएं:
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name
जब कोई ऐप्लिकेशन SYSTEM_ALERT_WINDOW अनुमति का इस्तेमाल कर रहा हो, तब फ़ोरग्राउंड सेवाएं शुरू करने से जुड़ी पाबंदियां
以前，如果应用拥有 SYSTEM_ALERT_WINDOW 权限，即使应用当前在后台运行，也可以启动前台服务（如免于后台启动限制中所述）。
如果应用以 Android 15 为目标平台，则此豁免范围现在更窄。现在，应用需要具有 SYSTEM_ALERT_WINDOW 权限，并且还需要有一个可见的叠加窗口。也就是说，应用需要先启动 TYPE_APPLICATION_OVERLAY 窗口，并且该窗口需要处于可见状态，然后您才能启动前台服务。
如果您的应用尝试从后台启动前台服务，但不符合这些新要求（并且没有其他豁免情况），系统会抛出 ForegroundServiceStartNotAllowedException。
如果您的应用声明了 SYSTEM_ALERT_WINDOW 权限并从后台启动前台服务，则可能会受到此变更的影响。如果您的应用获得了 ForegroundServiceStartNotAllowedException，请检查应用的操作顺序，并确保应用在尝试从后台启动前台服务之前已具有有效的叠加层窗口。您可以通过调用 View.getWindowVisibility() 检查叠加层窗口当前是否可见，也可以替换 View.onWindowVisibilityChanged()，以便在可见性发生变化时收到通知。
测试
如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 15 为目标平台（只要应用在 Android 15 设备上运行）也是如此。如需针对从后台启动前台服务启用这些新限制，请运行以下 adb 命令：
adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name
ऐप्लिकेशन, परेशान न करें मोड की ग्लोबल स्थिति में कब बदलाव कर सकते हैं, इसमें बदलाव
Android 15 (एपीआई लेवल 35) और उसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन, अब किसी डिवाइस पर 'परेशान न करें' (डीएनडी) मोड की ग्लोबल स्थिति या नीति को नहीं बदल सकते. ऐसा, उपयोगकर्ता की सेटिंग में बदलाव करके या डीएनडी मोड को बंद करके नहीं किया जा सकता. इसके बजाय, ऐप्लिकेशन को AutomaticZenRule का योगदान देना होगा. सिस्टम, इस योगदान को सबसे ज़्यादा पाबंदी वाली मौजूदा नीति के साथ मिलाकर, ग्लोबल नीति बनाता है. पहले जिन मौजूदा एपीआई कॉल से ग्लोबल स्टेटस (setInterruptionFilter,
setNotificationPolicy) पर असर पड़ा था उनसे, एक 'असहमति' वाला AutomaticZenRule पैरामीटर बनता है या अपडेट होता है. यह पैरामीटर, उन एपीआई कॉल के कॉल-साइकल के हिसाब से टॉगल किया जाता है.
ध्यान दें कि इस बदलाव का असर सिर्फ़ तब पड़ता है, जब ऐप्लिकेशन setInterruptionFilter(INTERRUPTION_FILTER_ALL) को कॉल कर रहा हो और उसे उम्मीद हो कि उस कॉल से, AutomaticZenRule को बंद किया जा सकेगा. AutomaticZenRule को पहले उसके मालिकों ने चालू किया था.
OpenJDK API में हुए बदलाव
Android 15 में, Android की मुख्य लाइब्रेरी को रीफ़्रेश करने का काम जारी है, ताकि इसे OpenJDK LTS के नए रिलीज़ की सुविधाओं के साथ अलाइन किया जा सके.
इनमें से कुछ बदलावों का असर, Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के साथ काम करने की सुविधा पर पड़ सकता है:
स्ट्रिंग फ़ॉर्मैटिंग एपीआई में बदलाव: इन
String.format()औरFormatter.format()एपीआई का इस्तेमाल करते समय, आर्ग्युमेंट इंडेक्स, फ़्लैग, चौड़ाई, और सटीक वैल्यू की पुष्टि अब ज़्यादा सख्त तरीके से की जाती है:String.format(String, Object[])String.format(Locale, String, Object[])Formatter.format(String, Object[])Formatter.format(Locale, String, Object[])
उदाहरण के लिए, आर्ग्युमेंट के इंडेक्स के तौर पर 0 का इस्तेमाल करने पर (फ़ॉर्मैट स्ट्रिंग में
%0), यह अपवाद दिखता है:IllegalFormatArgumentIndexException: Illegal format argument index = 0इस मामले में, फ़ॉर्मैट स्ट्रिंग में 1 (
%1) के आर्ग्युमेंट इंडेक्स का इस्तेमाल करके, समस्या को ठीक किया जा सकता है.Arrays.asList(...).toArray()के कॉम्पोनेंट टाइप में बदलाव:Arrays.asList(...).toArray()का इस्तेमाल करने पर, नतीजे के ऐरे का कॉम्पोनेंट टाइप अबObjectहै, न कि ऐरे के एलिमेंट का टाइप. इसलिए, यह कोडClassCastExceptionदिखाता है:String[] elements = (String[]) Arrays.asList("one", "two").toArray();इस मामले में, नतीजे के ऐरे में
Stringको कॉम्पोनेंट टाइप के तौर पर बनाए रखने के लिए,Collection.toArray(Object[])का इस्तेमाल किया जा सकता है:String[] elements = Arrays.asList("two", "one").toArray(new String[0]);भाषा कोड को मैनेज करने के तरीके में बदलाव:
Localeएपीआई का इस्तेमाल करते समय, अब हिब्रू, येहुदी, और इंडोनेशियन भाषा के कोड, उनके पुराने फ़ॉर्म (हिब्रू:iw, येहुदी:ji, और इंडोनेशियन:in) में बदले नहीं जाते. इनमें से किसी एक स्थानीय भाषा के लिए भाषा कोड तय करते समय, ISO 639-1 के कोड का इस्तेमाल करें (हिब्रू:he, येहुदी:yi, और इंडोनेशियन:id).रैंडम int सीक्वेंस में बदलाव: https://bugs.openjdk.org/browse/JDK-8301574 में किए गए बदलावों के बाद, यहां दिए गए
Random.ints()तरीके अब संख्याओं का एक अलग क्रम दिखाते हैं, जबकिRandom.nextInt()तरीके ऐसा नहीं करते:आम तौर पर, इस बदलाव से ऐप्लिकेशन के काम करने के तरीके पर कोई असर नहीं पड़ना चाहिए. हालांकि, आपके कोड को यह उम्मीद नहीं करनी चाहिए कि
Random.ints()तरीकों से जनरेट किया गया क्रम,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 प्लग इन में मौजूद
NewApilint विकल्प, एपीआई के इन नए इस्तेमालों का पता लगा सकता है../gradlew lintMainActivity.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.javaMyList.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.javaMyList.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.javaMyList.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 में ऐसे बदलाव किए गए हैं जिनसे सिस्टम की सुरक्षा को बेहतर बनाया जा सके. इससे ऐप्लिकेशन और उपयोगकर्ताओं को नुकसान पहुंचाने वाले ऐप्लिकेशन से सुरक्षित रखने में मदद मिलती है.
प्रतिबंधित TLS वर्शन
Android 15, TLS के 1.0 और 1.1 वर्शन के इस्तेमाल पर पाबंदी लगाता है. इन वर्शन को पहले Android में बंद कर दिया गया था. हालांकि, अब 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 引入了新的可选安全措施，以提高 intent 的安全性和稳健性。这些变更旨在防止潜在的漏洞以及恶意应用可能利用的 intent 滥用行为。Android 15 对 intent 的安全性进行了两项主要改进：
- 与目标 intent 过滤器匹配：定位到特定组件的 intent 必须与目标的 intent 过滤器规范完全匹配。如果您发送 intent 来启动其他应用的 activity，目标 intent 组件需要与接收 activity 声明的 intent 过滤器保持一致。
- intent 必须具有操作：没有操作的 intent 将不再与任何 intent 过滤器匹配。这意味着，用于启动 activity 或服务的 intent 必须具有明确定义的操作。
如需检查您的应用对这些更改的响应方式，请在应用中使用 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का इस्तेमाल करती है. अगर आपका ऐप्लिकेशन लॉन्च होने पर क्रैश हो जाता है, तो ऐसा स्प्लैशस्क्रीन की वजह से हो सकता है. core splashscreen डिपेंडेंसी को 1.2.0-alpha01 या उसके बाद के वर्शन पर अपग्रेड किया जा सकता है याwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.alwaysसेट किया जा सकता है. - हो सकता है कि कुछ स्क्रीन पर यूज़र इंटरफ़ेस (यूआई) का कुछ हिस्सा छिपा हो और उन पर कम ट्रैफ़िक हो. पुष्टि करें कि कम देखी गई इन स्क्रीन पर, यूज़र इंटरफ़ेस (यूआई) नहीं छिपा है. कम ट्रैफ़िक वाली स्क्रीन में ये शामिल हैं:
- ऑनबोर्डिंग या साइन-इन स्क्रीन
- सेटिंग पेज
अगर आपका ऐप्लिकेशन पहले से ही पूरे डिवाइस के साइज़ का नहीं है, तो क्या देखना चाहिए
अगर आपका ऐप्लिकेशन पहले से ही पूरे डिवाइस की स्क्रीन पर नहीं दिखता है, तो हो सकता है कि इस बदलाव का असर आप पर पड़े. पहले से ही पूरे डिवाइस के स्क्रीन साइज़ के ऐप्लिकेशन के अलावा, आपको इन बातों का भी ध्यान रखना चाहिए:
- अगर आपका ऐप्लिकेशन, कॉम्पोनेंट बनाने के लिए Material 3 कॉम्पोनेंट (
androidx.compose.material3) का इस्तेमाल करता है, जैसे किTopAppBar,BottomAppBar, औरNavigationBar, तो इन कॉम्पोनेंट पर कोई असर नहीं पड़ेगा, क्योंकि ये इनसेट को अपने-आप मैनेज करते हैं. - अगर आपका ऐप्लिकेशन, Compose में Material 2 कॉम्पोनेंट (
androidx.compose.material) का इस्तेमाल कर रहा है, तो ये कॉम्पोनेंट अपने-आप इनसेट मैनेज नहीं करते. हालांकि, इनसेट का ऐक्सेस पाकर, उन्हें मैन्युअल तरीके से लागू किया जा सकता है. androidx.compose.material 1.6.0 और उसके बाद के वर्शन में,windowInsetsपैरामीटर का इस्तेमाल करके,BottomAppBar,TopAppBar,BottomNavigation, औरNavigationRailके लिए इनसेट को मैन्युअल तरीके से लागू करें. इसी तरह,Scaffoldके लिएcontentWindowInsetsपैरामीटर का इस्तेमाल करें. - अगर आपका ऐप्लिकेशन व्यू और Material Components (
com.google.android.material) का इस्तेमाल करता है, तोBottomNavigationView,BottomAppBar,NavigationRailViewयाNavigationViewजैसे ज़्यादातर व्यू-आधारित Material Components, इनसेट को मैनेज करते हैं और इसके लिए किसी और काम की ज़रूरत नहीं होती. हालांकि,AppBarLayoutका इस्तेमाल करने पर, आपकोandroid:fitsSystemWindows="true"जोड़ना होगा. - कस्टम कॉम्पोज़ेबल के लिए, इनसेट को पैडिंग के तौर पर मैन्युअल तरीके से लागू करें. अगर आपका कॉन्टेंट
Scaffoldमें है, तोScaffoldपैडिंग वैल्यू का इस्तेमाल करके इनसेट का इस्तेमाल किया जा सकता है. इसके अलावा,WindowInsetsमें से किसी एक का इस्तेमाल करके पैडिंग लागू करें. - अगर आपका ऐप्लिकेशन व्यू और
BottomSheet,SideSheetया कस्टम कंटेनर का इस्तेमाल कर रहा है, तोViewCompat.setOnApplyWindowInsetsListenerका इस्तेमाल करके पैडिंग लागू करें.RecyclerViewके लिए, इस लिसनर का इस्तेमाल करके पैडिंग लागू करें. साथ ही,clipToPadding="false"भी जोड़ें.
बैकग्राउंड में काम करने वाले ऐप्लिकेशन को कस्टम सुरक्षा देने के लिए, क्या-क्या देखना चाहिए
अगर आपके ऐप्लिकेशन को तीन बटन वाले नेविगेशन या स्टेटस बार के लिए, बैकग्राउंड की कस्टम सुरक्षा की सुविधा देनी है, तो आपके ऐप्लिकेशन को WindowInsets.Type#tappableElement() का इस्तेमाल करके, सिस्टम बार के पीछे कोई कॉम्पोज़ेबल या व्यू डालना चाहिए. इससे, तीन बटन वाले नेविगेशन बार की ऊंचाई या WindowInsets.Type#statusBars की जानकारी मिलती है.
एज-टू-एज के लिए अन्य संसाधन
इनसेट लागू करने के बारे में ज़्यादा जानने के लिए, एज-टू-एज व्यू और एज-टू-एज कॉम्पोज़ के दिशा-निर्देश देखें.
बंद किए गए एपीआई
यहां दिए गए एपीआई बंद कर दिए गए हैं, लेकिन बंद नहीं किए गए हैं:
R.attr#enforceStatusBarContrastR.attr#navigationBarColor(80% ऐल्फ़ा वाले तीन बटन वाले नेविगेशन के लिए)Window#isStatusBarContrastEnforcedWindow#setNavigationBarColor(तीन बटन वाले नेविगेशन के लिए, 80% ऐल्फ़ा के साथ)Window#setStatusBarContrastEnforced
यहां दिए गए एपीआई बंद कर दिए गए हैं:
R.attr#navigationBarColor(जेस्चर वाले नेविगेशन के लिए)R.attr#navigationBarDividerColorR.attr#statusBarColorWindow#setDecorFitsSystemWindowsWindow#getNavigationBarColorWindow#getNavigationBarDividerColorWindow#getStatusBarColorWindow#setNavigationBarColor(जेस्चर वाले नेविगेशन के लिए)Window#setNavigationBarDividerColorWindow#setStatusBarColor
稳定配置
अगर आपका ऐप्लिकेशन Android 15 (एपीआई लेवल 35) या उसके बाद के वर्शन को टारगेट करता है, तो Configuration अब सिस्टम बार को शामिल नहीं करता. अगर लेआउट का हिसाब लगाने के लिए, Configuration क्लास में स्क्रीन साइज़ का इस्तेमाल किया जाता है, तो आपको इसे बेहतर विकल्पों से बदलना चाहिए. जैसे, अपनी ज़रूरत के हिसाब से ViewGroup, WindowInsets या WindowMetricsCalculator.
Configuration, एपीआई 1 से उपलब्ध है. आम तौर पर, यह जानकारी Activity.onConfigurationChanged से मिलती है. इसमें विंडो की डेंसिटी, ओरिएंटेशन, और साइज़ जैसी जानकारी मिलती है. Configuration से मिली विंडो के साइज़ की एक अहम खासियत यह है कि पहले इसमें सिस्टम बार शामिल नहीं थे.
कॉन्फ़िगरेशन साइज़ का इस्तेमाल आम तौर पर संसाधन चुनने के लिए किया जाता है, जैसे कि
/res/layout-h500dp. यह अब भी इस्तेमाल का मान्य उदाहरण है. हालांकि, लेआउट के हिसाब लगाने के लिए, इसका इस्तेमाल करने का सुझाव नहीं दिया जाता. अगर ऐसा है, तो आपको अब इससे दूर हो जाना चाहिए. आपको अपने इस्तेमाल के उदाहरण के आधार पर, Configuration के इस्तेमाल को किसी और ज़्यादा सही चीज़ से बदलना चाहिए.
अगर लेआउट का हिसाब लगाने के लिए इसका इस्तेमाल किया जाता है, तो सही ViewGroup का इस्तेमाल करें, जैसे कि
CoordinatorLayout या ConstraintLayout. अगर इसका इस्तेमाल सिस्टम के नेविगेशन बार की ऊंचाई तय करने के लिए किया जाता है, तो WindowInsets का इस्तेमाल करें. अगर आपको अपने ऐप्लिकेशन की विंडो का मौजूदा साइज़ जानना है, तो computeCurrentWindowMetrics का इस्तेमाल करें.
इस बदलाव से जिन फ़ील्ड पर असर पड़ा है उनके बारे में यहां बताया गया है:
Configuration.screenWidthDpऔरscreenHeightDpसाइज़ में अब सिस्टम बार शामिल नहीं किए जाते.screenWidthDpऔरscreenHeightDpमें किए गए बदलावों का असर,Configuration.smallestScreenWidthDpपर भी पड़ता है.- स्क्वेयर के करीब के डिवाइसों पर,
screenWidthDpऔरscreenHeightDpमें किए गए बदलावों काConfiguration.orientationपर असर पड़ता है. Configurationमें किए गए बदलावों का असर,Display.getSize(Point)पर सीधे तौर पर नहीं पड़ता. एपीआई लेवल 30 से, इसे बंद कर दिया गया था.- एपीआई लेवल 33 से ही
Display.getMetrics()इस तरह काम कर रहा है.
elegantTextHeight एट्रिब्यूट की वैल्यू डिफ़ॉल्ट रूप से 'सही' पर सेट होती है
Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, elegantTextHeight TextView एट्रिब्यूट डिफ़ॉल्ट रूप से true हो जाता है. इससे, डिफ़ॉल्ट रूप से इस्तेमाल किए जाने वाले कॉम्पैक्ट फ़ॉन्ट की जगह, कुछ ऐसी स्क्रिप्ट का इस्तेमाल किया जाता है जिनमें बड़ी वर्टिकल मेट्रिक होती हैं. इन मेट्रिक को पढ़ना ज़्यादा आसान होता है.
कॉम्पैक्ट फ़ॉन्ट को लेआउट के बीच में रुकावट आने से रोकने के लिए लॉन्च किया गया था. Android 13 (एपीआई लेवल 33), fallbackLineSpacing एट्रिब्यूट का इस्तेमाल करके, टेक्स्ट लेआउट की वर्टिकल ऊंचाई को बढ़ाकर, इनमें से कई रुकावटों को रोकता है.
Android 15 में, कॉम्पैक्ट फ़ॉन्ट अब भी सिस्टम में मौजूद है. इसलिए, आपका ऐप्लिकेशन पहले जैसा व्यवहार पाने के लिए, elegantTextHeight को false पर सेट कर सकता है. हालांकि, आने वाले समय में रिलीज़ होने वाले वर्शन में, इसकी सुविधा काम नहीं करेगी. इसलिए, अगर आपका ऐप्लिकेशन इन स्क्रिप्ट के साथ काम करता है: ऐरेबिक, लाओ, म्यांमार, तमिल, गुजराती, कन्नड़, मलयालम, उड़ीया, तेलुगु या थाई, तो elegantTextHeight को true पर सेट करके अपने ऐप्लिकेशन की जांच करें.
elegantTextHeight Android 14 (एपीआई लेवल 34) और उससे पहले के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए व्यवहार.
elegantTextHeight Android 15 को टारगेट करने वाले ऐप्लिकेशन के लिए व्यवहार.अक्षरों के जटिल आकार के लिए, TextView की चौड़ाई में बदलाव
Android के पिछले वर्शन में, पेचीदा आकार वाले कुछ कर्सिव फ़ॉन्ट या भाषाएं, पिछले या अगले वर्ण के एरिया में अक्षर खींच सकती हैं.
कुछ मामलों में, ऐसे अक्षरों को शुरुआत या आखिर में काटकर छोटा किया गया था.
Android 15 से, TextView ऐसे अक्षरों के लिए ज़रूरी जगह बनाने के लिए
चौड़ाई तय करता है. साथ ही, क्लिप बनाने से रोकने के लिए,
ऐप्लिकेशन बाईं ओर ज़्यादा पैडिंग (जगह) का अनुरोध कर सकते हैं.
इस बदलाव का असर इस बात पर पड़ता है कि TextView, चौड़ाई का फ़ैसला कैसे लेता है. इसलिए, अगर ऐप्लिकेशन Android 15 (एपीआई लेवल 35) या उसके बाद के वर्शन को टारगेट करता है, तो TextView डिफ़ॉल्ट रूप से ज़्यादा चौड़ाई तय करता है. setUseBoundsForWidth पर एपीआई को कॉल करके, इस सुविधा को चालू या बंद किया जा सकता है.TextView
बाईं ओर की पैडिंग जोड़ने से, हो सकता है कि मौजूदा लेआउट गलत तरीके से अलाइन हो जाएं. ऐसा होने पर, Android 15 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए भी पैडिंग (जगह) डिफ़ॉल्ट रूप से नहीं जोड़ी जाती.
हालांकि, setShiftDrawingOffsetForStartOverhang को कॉल करके, क्लिपिंग को रोकने के लिए अतिरिक्त पैडिंग जोड़ी जा सकती है.
नीचे दिए गए उदाहरणों से पता चलता है कि इन बदलावों से कुछ फ़ॉन्ट और भाषाओं के लिए टेक्स्ट लेआउट को बेहतर कैसे बनाया जा सकता है.
<TextView android:fontFamily="cursive" android:text="java" />
<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
<TextView android:text="คอมพิวเตอร์" />
<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
EditText के लिए, स्थानीय भाषा के हिसाब से डिफ़ॉल्ट लाइन की ऊंचाई
Android के पिछले वर्शन में, टेक्स्ट लेआउट, टेक्स्ट की ऊंचाई को बढ़ा देता था, ताकि मौजूदा स्थानीय भाषा से मैच करने वाले फ़ॉन्ट की लाइन की ऊंचाई पूरी की जा सके. उदाहरण के लिए, अगर कॉन्टेंट जैपनीज़ में था, तो टेक्स्ट की ऊंचाई थोड़ी ज़्यादा हो गई, क्योंकि जैपनीज़ फ़ॉन्ट की लाइन की ऊंचाई, लैटिन फ़ॉन्ट की लाइन की ऊंचाई से थोड़ी ज़्यादा होती है. हालांकि, लाइन हाइट में इन अंतरों के बावजूद, इस्तेमाल किए जा रहे स्थानीय भाषा के बावजूद, EditText एलिमेंट का साइज़ एक जैसा था, जैसा कि इस इमेज में दिखाया गया है:
EditText एलिमेंट दिखाने वाले तीन बॉक्स, जिनमें इंग्लिश (en), जैपनीज़ (ja), और बर्मीज़ (my) भाषा का टेक्स्ट हो सकता है. EditText की ऊंचाई एक जैसी है, भले ही इन भाषाओं की लाइन की ऊंचाई एक-दूसरे से अलग हो.Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन के लिए, EditText के लिए कम से कम लाइन हाइट तय की गई है. इससे, तय की गई लोकेल के रेफ़रंस फ़ॉन्ट से मैच करने में मदद मिलती है. इसकी जानकारी इस इमेज में दी गई है:
EditText एलिमेंट दिखाने वाले तीन बॉक्स, जिनमें इंग्लिश (en), जैपनीज़ (ja), और बर्मीज़ (my) भाषा का टेक्स्ट हो सकता है. EditText की ऊंचाई में अब इन भाषाओं के फ़ॉन्ट के लिए, डिफ़ॉल्ट लाइन की ऊंचाई को शामिल करने के लिए स्पेस शामिल है.ज़रूरत पड़ने पर, आपका ऐप्लिकेशन useLocalePreferredLineHeightForMinimum एट्रिब्यूट को false पर सेट करके, पहले जैसा व्यवहार वापस ला सकता है. साथ ही, आपका ऐप्लिकेशन Kotlin और Java में setMinimumFontMetrics एपीआई का इस्तेमाल करके, कस्टम मिनिमम वर्टिकल मेट्रिक सेट कर सकता है.
कैमरा और मीडिया
Android 15 में, कैमरे और मीडिया के व्यवहार में ये बदलाव किए गए हैं. ये बदलाव, Android 15 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए किए गए हैं.
ऑडियो फ़ोकस का अनुरोध करने से जुड़ी पाबंदियां
Android 15 (एपीआई लेवल 35) को टारगेट करने वाले ऐप्लिकेशन को ऑडियो फ़ोकस का अनुरोध करने के लिए, टॉप ऐप्लिकेशन या फ़ोरग्राउंड सेवा के तौर पर चलना होगा. अगर कोई ऐप्लिकेशन इनमें से किसी एक ज़रूरी शर्त को पूरा न करने पर फ़ोकस का अनुरोध करता है, तो कॉल AUDIOFOCUS_REQUEST_FAILED दिखाता है.
ऑडियो फ़ोकस के बारे में ज़्यादा जानने के लिए, ऑडियो फ़ोकस मैनेज करें पर जाएं.
SDK टूल के अलावा अन्य तरीकों से डेटा इकट्ठा करने पर लगी पाबंदियां अपडेट की गईं
Android 15 में, पाबंदी वाले ऐसे इंटरफ़ेस की अपडेट की गई सूचियां शामिल हैं जो एसडीके टूल के दायरे में नहीं आते. ये सूचियां, Android डेवलपर के साथ मिलकर की गई जांच और नई इंटरनल जांच के आधार पर बनाई गई हैं. जब भी मुमकिन हो, हम यह पक्का करते हैं कि SDK टूल के बाहर के इंटरफ़ेस पर पाबंदी लगाने से पहले, सार्वजनिक विकल्प उपलब्ध हों.
अगर आपका ऐप्लिकेशन Android 15 को टारगेट नहीं करता है, तो हो सकता है कि इनमें से कुछ बदलावों का असर आप पर तुरंत न पड़े. हालांकि, आपके ऐप्लिकेशन के टारगेट एपीआई लेवल के आधार पर, आपके ऐप्लिकेशन के पास कुछ ऐसे इंटरफ़ेस को ऐक्सेस करने का विकल्प होता है जो SDK टूल के नहीं होते. हालांकि, SDK टूल के अलावा किसी भी तरीके या फ़ील्ड का इस्तेमाल करने पर, आपके ऐप्लिकेशन के क्रैश होने का खतरा हमेशा बना रहता है.
अगर आपको नहीं पता कि आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस का इस्तेमाल करता है या नहीं, तो इसकी पुष्टि करने के लिए अपने ऐप्लिकेशन की जांच करें. अगर आपका ऐप्लिकेशन, SDK टूल के अलावा किसी दूसरे इंटरफ़ेस पर निर्भर है, तो आपको SDK टूल के विकल्पों पर माइग्रेट करने की योजना बनानी चाहिए. हालांकि, हम समझते हैं कि कुछ ऐप्लिकेशन के लिए, गैर-SDK इंटरफ़ेस इस्तेमाल करने के मान्य उदाहरण हैं. अगर आपको अपने ऐप्लिकेशन में किसी सुविधा के लिए, SDK इंटरफ़ेस के अलावा कोई दूसरा विकल्प नहीं मिल रहा है, तो आपको नए सार्वजनिक एपीआई का अनुरोध करना चाहिए.
Android के इस वर्शन में हुए बदलावों के बारे में ज़्यादा जानने के लिए, Android 15 में, SDK टूल के अलावा अन्य इंटरफ़ेस से जुड़ी पाबंदियों में हुए अपडेट देखें. आम तौर पर, SDK टूल के बाहर के इंटरफ़ेस के बारे में ज़्यादा जानने के लिए, SDK टूल के बाहर के इंटरफ़ेस पर लगी पाबंदियां देखें.