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

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

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

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

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

मेमोरी की सीमा का विजेट

Android 17 से, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, सिस्टम मेमोरी की एक तय सीमा लागू करता है. यह सीमा, RemoteViews पार्सल में मौजूद बिटमैप और आइकॉन, दोनों के कुल मेमोरी इस्तेमाल के लिए तय की गई है. यह सीमा (1.5 * स्क्रीन की चौड़ाई * स्क्रीन की ऊंचाई * 4) है. इन सीमाओं का उल्लंघन करने पर, गंभीर IllegalArgumentException गड़बड़ी होती है और ऐप्लिकेशन की प्रोसेस क्रैश हो जाती है.

ज़्यादा जानकारी के लिए, UpdateAppWidget देखें.

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

Android 17 में ये बदलाव शामिल हैं. इनसे Android सिस्टम की कई मुख्य क्षमताओं में बदलाव होता है या उन्हें बढ़ाया जाता है.

MessageQueue को लॉक-फ़्री तरीके से लागू करने का नया तरीका

Android 17 से, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन को android.os.MessageQueue का नया लॉक-फ़्री वर्शन मिलता है. इस नई सुविधा को लागू करने से, परफ़ॉर्मेंस बेहतर होती है और छूटे हुए फ़्रेम की संख्या कम होती है. हालांकि, इससे उन क्लाइंट पर असर पड़ सकता है जो MessageQueue निजी फ़ील्ड और तरीकों को दिखाते हैं.

ज़्यादा जानकारी और समस्या को कम करने की रणनीतियों के लिए, MessageQueue के व्यवहार में हुए बदलाव से जुड़े दिशा-निर्देश देखें.

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

Android 17 या उसके बाद के वर्शन पर काम करने वाले ऐसे ऐप्लिकेशन जो Android 17 (एपीआई लेवल 37) या उसके बाद के वर्शन को टारगेट करते हैं वे static final फ़ील्ड में बदलाव नहीं कर सकते. अगर कोई ऐप्लिकेशन, रिफ़्लेक्शन का इस्तेमाल करके static final फ़ील्ड में बदलाव करने की कोशिश करता है, तो इससे IllegalAccessException की समस्या होगी. JNI एपीआई (जैसे कि SetStaticLongField()) के ज़रिए इनमें से किसी फ़ील्ड में बदलाव करने की कोशिश करने पर, ऐप्लिकेशन क्रैश हो जाएगा.

सुलभता

Android 17 में, सुलभता को बेहतर बनाने के लिए ये बदलाव किए गए हैं.

फ़िज़िकल कीबोर्ड से टाइप करने के लिए, जटिल आईएमई की सुलभता से जुड़ी सहायता

इस सुविधा में, AccessibilityEvent और TextAttribute नए एपीआई जोड़े गए हैं. इनसे, CJKV भाषाओं में टाइप किए गए टेक्स्ट को स्क्रीन रीडर के ज़रिए बोलकर सुनाने की सुविधा को बेहतर बनाया जा सकेगा. CJKV IME ऐप्लिकेशन अब यह सिग्नल दे सकते हैं कि टेक्स्ट कंपोज़िशन के दौरान, टेक्स्ट कन्वर्ज़न के लिए चुने गए शब्द को चुना गया है या नहीं. बदलाव करने के फ़ील्ड वाले ऐप्लिकेशन, टेक्स्ट में बदलाव होने से जुड़े ऐक्सेसिबिलिटी इवेंट भेजते समय, टेक्स्ट में बदलाव के टाइप के बारे में बता सकते हैं. उदाहरण के लिए, ऐप्लिकेशन यह बता सकते हैं कि टेक्स्ट कंपोज़िशन के दौरान टेक्स्ट में बदलाव हुआ है या टेक्स्ट में बदलाव, कमिट करने की वजह से हुआ है. ऐसा करने से, स्क्रीन रीडर जैसी सुलभता सेवाओं को टेक्स्ट में किए गए बदलाव के आधार पर ज़्यादा सटीक सुझाव देने में मदद मिलती है.

Android SDK इस्तेमाल करने वाले ऐप्लिकेशन की संख्या

• IME ऐप्लिकेशन: IME, एडिट फ़ील्ड में टेक्स्ट लिखते समय TextAttribute.Builder.setTextSuggestionSelected() का इस्तेमाल कर सकते हैं. इससे यह पता चलता है कि किसी खास कन्वर्ज़न कैंडिडेट को चुना गया है या नहीं.

• 'फ़ील्ड में बदलाव करें' सुविधा वाले ऐप्लिकेशन: कस्टम InputConnection को बनाए रखने वाले ऐप्लिकेशन, TextAttribute.isTextSuggestionSelected() को कॉल करके उम्मीदवार चुनने का डेटा वापस पा सकते हैं. इसके बाद, इन ऐप्लिकेशन को AccessibilityEvent.setTextChangeTypes() इवेंट भेजते समय, TYPE_VIEW_TEXT_CHANGED को कॉल करना चाहिए. Android 17 (एपीआई लेवल 37) को टारगेट करने वाले ऐसे ऐप्लिकेशन जो स्टैंडर्ड TextView का इस्तेमाल करते हैं उनमें यह सुविधा डिफ़ॉल्ट रूप से चालू होगी. (इसका मतलब है कि TextView, IME से डेटा पाने और सुलभता सेवाओं को इवेंट भेजते समय टेक्स्ट में बदलाव के टाइप सेट करने का काम करेगा).

• सुलभता सेवाएं: TYPE_VIEW_TEXT_CHANGED इवेंट को प्रोसेस करने वाली सुलभता सेवाएं, AccessibilityEvent.getTextChangeTypes() को कॉल कर सकती हैं. इससे उन्हें बदलाव के बारे में पता चलता है और वे उसके हिसाब से, सुझाव देने की रणनीतियों में बदलाव कर सकती हैं.

निजता

Android 17 में, उपयोगकर्ता की निजता को बेहतर बनाने के लिए ये बदलाव किए गए हैं.

ECH (Encrypted Client Hello) चालू है

Android 17 में, Encrypted Client Hello (ECH) के लिए प्लैटफ़ॉर्म सपोर्ट की सुविधा जोड़ी गई है. यह TLS का एक एक्सटेंशन है. इससे, TLS हैंडशेक में Server Name Indication (एसएनआई) को एन्क्रिप्ट करके, उपयोगकर्ता की निजता को बेहतर बनाया जाता है. एन्क्रिप्शन की इस सुविधा से, नेटवर्क पर नज़र रखने वाले लोगों को यह पता लगाने में मुश्किल होती है कि आपका ऐप्लिकेशन किस डोमेन से कनेक्ट हो रहा है.

Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, TLS कनेक्शन के लिए ECH का इस्तेमाल किया जाता है. ECH सिर्फ़ तब चालू होता है, जब ऐप्लिकेशन में इस्तेमाल की गई नेटवर्किंग लाइब्रेरी (उदाहरण के लिए, HttpEngine, WebView या OkHttp) में ECH की सुविधा इंटिग्रेट की गई हो और रिमोट सर्वर भी ECH प्रोटोकॉल के साथ काम करता हो. अगर ईसीएच पर बातचीत नहीं हो पाती है, तो क्लाइंट, ईसीएच एक्सटेंशन भेजता है. इसमें कॉन्टेंट को रैंडमाइज़ किया जाता है. इस प्रोसेस को ईसीएच ग्रीस कहा जाता है. ECH GREASE के काम करने के तरीके के बारे में ज़्यादा जानने के लिए, RFC 9849 देखें.

ऐप्लिकेशन को इस सुविधा को पसंद के मुताबिक बनाने की अनुमति देने के लिए, Android 17 ने नेटवर्क सुरक्षा कॉन्फ़िगरेशन फ़ाइल में एक नया <domainEncryption> एलिमेंट जोड़ा है. डेवलपर, <domainEncryption> टैग के अंदर <base-config> या <domain-config> टैग का इस्तेमाल करके, ग्लोबल या हर डोमेन के हिसाब से ईसीएच मोड (उदाहरण के लिए, "enabled" या "disabled") चुन सकते हैं.

ज़्यादा जानकारी के लिए, Encrypted Client Hello का दस्तावेज़ देखें.

Android 17 को टारगेट करने वाले ऐप्लिकेशन के लिए, लोकल नेटवर्क ऐक्सेस करने की अनुमति ज़रूरी है

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

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

ज़्यादा जानकारी के लिए, लोकल नेटवर्क की अनुमति से जुड़ा दस्तावेज़ देखें.

फ़िज़िकल डिवाइसों से पासवर्ड छिपाना

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

Android सिस्टम, टाइप किए गए पासवर्ड का आखिरी वर्ण दिखाता है. इससे उपयोगकर्ता को यह देखने में मदद मिलती है कि उसने पासवर्ड गलत तो नहीं टाइप किया है. हालांकि, बड़े बाहरी कीबोर्ड के साथ इसकी ज़रूरत कम होती है. इसके अलावा, बाहरी कीबोर्ड वाले डिवाइसों में अक्सर बड़े डिसप्ले होते हैं. इससे, टाइप किया गया पासवर्ड किसी और को दिखने का खतरा बढ़ जाता है.

अगर उपयोगकर्ता डिवाइस की टचस्क्रीन का इस्तेमाल कर रहा है, तो सिस्टम नई show_passwords_touch सेटिंग लागू करता है.

सामान्य एसएमएस मैसेज के लिए ओटीपी सुरक्षा

Android 17 से, Android अपने एसएमएस ओटीपी सुरक्षा फ़ीचर को स्टैंडर्ड एसएमएस मैसेज पर भी लागू कर रहा है. स्टैंडर्ड एसएमएस मैसेज ऐसे एसएमएस मैसेज होते हैं जिनमें ओटीपी होता है और जो WebOTP या SMS Retriever फ़ॉर्मैट का इस्तेमाल नहीं करते हैं. Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ज़्यादातर ऐप्लिकेशन के लिए, ये एसएमएस मैसेज मिलने के तीन घंटे बाद तक उपलब्ध नहीं होते. इस देरी का मकसद, ओटीपी को हाइजैक होने से रोकना है. तीन घंटे की इस देरी के दौरान, SMS_RECEIVED_ACTION ब्रॉडकास्ट को रोक दिया जाता है. साथ ही, एसएमएस सेवा देने वाली कंपनी के डेटाबेस की क्वेरी को फ़िल्टर किया जाता है. एसएमएस मैसेज, कुछ समय बाद इन ऐप्लिकेशन के लिए उपलब्ध हो जाता है.

डिफ़ॉल्ट एसएमएस असिस्टेंट ऐप्लिकेशन, कनेक्ट किए गए डिवाइस के कंपैनियन ऐप्लिकेशन वगैरह जैसे कुछ ऐप्लिकेशन को इस देरी से छूट मिली है. ओटीपी निकालने के लिए एसएमएस मैसेज पढ़ने की सुविधा पर निर्भर रहने वाले सभी ऐप्लिकेशन को SMS Retriever या SMS User Consent API का इस्तेमाल करना चाहिए, ताकि यह सुविधा काम करती रहे.

सुरक्षा

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

ऐक्टिविटी की सुरक्षा

In Android 17, the platform continues its shift toward a "secure-by-default" architecture, introducing a suite of enhancements designed to mitigate high-severity exploits such as phishing, interaction hijacking, and confused deputy attacks. This update requires developers to explicitly opt in to new security standards to maintain app compatibility and user protection.

Key impacts for developers include:

• BAL hardening & improved opt-in: We are refining Background Activity Launch (BAL) restrictions by extending protections to IntentSender. Developers must migrate away from the legacy MODE_BACKGROUND_ACTIVITY_START_ALLOWED constant. Instead, you should adopt granular controls like MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, which restricts activity starts to scenarios where the calling app is visible, significantly reducing the attack surface.
• Adoption tools: Developers should utilize strict mode and updated lint checks to identify legacy patterns and ensure readiness for future target SDK requirements.

डिफ़ॉल्ट रूप से सीटी चालू करें

अगर कोई ऐप्लिकेशन, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करता है, तो सर्टिफ़िकेट ट्रांसपैरेंसी (सीटी) डिफ़ॉल्ट रूप से चालू होती है. (Android 16 पर, सीटी उपलब्ध है. हालांकि, ऐप्लिकेशन को ऑप्ट इन करना होगा.)

Safer Native DCL—C

अगर आपका ऐप्लिकेशन, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करता है, तो Android 14 में DEX और JAR फ़ाइलों के लिए शुरू की गई, ज़्यादा सुरक्षित डाइनैमिक कोड लोडिंग (डीसीएल) की सुविधा अब नेटिव लाइब्रेरी के लिए भी उपलब्ध है.

System.load() का इस्तेमाल करके लोड की गई सभी नेटिव फ़ाइलों को, रीड-ओनली के तौर पर मार्क किया जाना चाहिए. ऐसा न होने पर, सिस्टम UnsatisfiedLinkError दिखाता है.

हमारा सुझाव है कि ऐप्लिकेशन, कोड को डाइनैमिक तरीके से लोड करने से बचें. ऐसा करने से, कोड इंजेक्शन या कोड में छेड़छाड़ की वजह से ऐप्लिकेशन के हैक होने का खतरा बहुत बढ़ जाता है.

CP2 डेटा व्यू में व्यक्तिगत पहचान से जुड़ी जानकारी फ़ील्ड को सीमित करना

Android 17 (एपीआई लेवल Android 17 (एपीआई लेवल 37)) और इससे ऊपर के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, संपर्क सूची 2 (CP2), डेटा व्यू में व्यक्तिगत पहचान से जुड़ी जानकारी (पीआईआई) वाले कुछ कॉलम को प्रतिबंधित करता है. इस बदलाव को चालू करने पर, उपयोगकर्ता की निजता को बेहतर बनाने के लिए, इन कॉलम को डेटा व्यू से हटा दिया जाता है. पाबंदी वाले कॉलम में ये शामिल हैं:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

ContactsContract.Data से इन कॉलम का इस्तेमाल करने वाले ऐप्लिकेशन, RAW_CONTACT_ID के साथ जुड़कर, ContactsContract.RawContacts से इन्हें निकाल सकते हैं.

CP2 में एसक्यूएल की सख्त जांच लागू करना

Android 17 (एपीआई लेवल 37) और इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, संपर्क सूची 2 (CP2), एसक्यूएल क्वेरी की पुष्टि करने की प्रक्रिया को सख्ती से लागू करता है. ऐसा तब होता है, जब READ_CONTACTS अनुमति के बिना ContactsContract.Data टेबल को ऐक्सेस किया जाता है.

इस बदलाव के बाद, अगर किसी ऐप्लिकेशन के पास READ_CONTACTS की अनुमति नहीं है, तो ContactsContract.Data टेबल से क्वेरी करते समय, StrictColumns और StrictGrammar विकल्प सेट किए जाते हैं. अगर कोई क्वेरी ऐसे पैटर्न का इस्तेमाल करती है जो इनके साथ काम नहीं करता, तो उसे अस्वीकार कर दिया जाएगा. साथ ही, इससे एक अपवाद भी जनरेट होगा.

इंटेलिजेंस

Android 17 में, सिस्टम इंटेलिजेंस से जुड़े ये बदलाव किए गए हैं.

setContentCaptureEnabled के इस्तेमाल पर रोक

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

Android 17 से, ContentCaptureManager.setContentCaptureEnabled(boolean) एपीआई के तरीके का इस्तेमाल नहीं किया जा सकेगा. Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, setContentCaptureEnabled(false) को कॉल करने पर अब कॉन्टेंट कैप्चर करने की सुविधा बंद नहीं होती.

अगर आपके ऐप्लिकेशन को कॉन्टेंट कैप्चर करने की सुविधा बंद रखनी है या सिस्टम को स्क्रीन का कॉन्टेंट कैप्चर करने से रोकना है, तो आपको FLAG_SECURE विंडो लेआउट पैरामीटर का इस्तेमाल करना होगा.

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

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

ज़्यादा जानकारी के लिए, WindowManager.LayoutParams.FLAG_SECURE रेफ़रंस दस्तावेज़ देखें.

मीडिया

Android 17 में, मीडिया के व्यवहार में ये बदलाव किए गए हैं.

बैकग्राउंड ऑडियो सुरक्षा कड़ी करना

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

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

• फ़ोरग्राउंड सेवा में, 'इस्तेमाल के समय अनुमति दें' (डब्ल्यूआईयू) की सुविधाएं होनी चाहिए.
• ऐप्लिकेशन के पास सटीक अलार्म की अनुमति होनी चाहिए. साथ ही, वह USAGE_ALARM ऑडियो स्ट्रीम के साथ इंटरैक्ट कर रहा हो.

ज़्यादा जानकारी और इससे बचने के तरीकों के लिए, बैकग्राउंड में चलने वाले ऑडियो को सुरक्षित बनाना लेख पढ़ें.

डिवाइस के नाप या आकार

Android 17 में, उपयोगकर्ता अनुभव को बेहतर बनाने के लिए ये बदलाव किए गए हैं. ये बदलाव, अलग-अलग साइज़ और फ़ॉर्म फ़ैक्टर वाले डिवाइसों पर लागू होंगे.

प्लैटफ़ॉर्म एपीआई में बदलाव किए गए हैं, ताकि बड़ी स्क्रीन (sw>=600dp) पर स्क्रीन की दिशा, साइज़ बदलने, और आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात) से जुड़ी पाबंदियों को अनदेखा किया जा सके

हमने Android 16 में प्लैटफ़ॉर्म एपीआई में बदलाव किए हैं. इससे, एपीआई लेवल 36 या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, बड़ी स्क्रीन (sw >= 600dp) पर स्क्रीन की दिशा, आसपेक्ट रेशियो (लंबाई-चौड़ाई का अनुपात), और साइज़ बदलने से जुड़ी पाबंदियों को अनदेखा किया जा सकेगा. डेवलपर के पास एसडीके 36 के साथ इन बदलावों से ऑप्ट आउट करने का विकल्प है. हालांकि, Android 17 (एपीआई लेवल 37) या इसके बाद के वर्शन को टारगेट करने वाले ऐप्लिकेशन के लिए, यह ऑप्ट-आउट अब उपलब्ध नहीं होगा.

ज़्यादा जानकारी के लिए, स्क्रीन की दिशा और साइज़ बदलने से जुड़ी पाबंदियों को अनदेखा किया जाता है लेख पढ़ें.

कनेक्टिविटी

Android 17 में, ब्लूटूथ RFCOMM सॉकेट के लिए स्टैंडर्ड Java InputStream के व्यवहार के साथ अलाइन करने और एक जैसा अनुभव देने के लिए, यह बदलाव किया गया है.

RFCOMM के लिए, BluetoothSocket read() का एक जैसा व्यवहार

अगर कोई ऐप्लिकेशन Android 17 (एपीआई लेवल 37) को टारगेट करने के लिए बनाया जा रहा है, तो RFCOMM पर आधारित BluetoothSocket से मिले InputStream के read() तरीके को बंद करने पर, अब -1 दिखता है. ऐसा तब होता है, जब सॉकेट बंद हो जाता है या कनेक्शन हट जाता है.

इस बदलाव से, RFCOMM सॉकेट का व्यवहार LE CoC सॉकेट के जैसा हो जाता है. साथ ही, यह InputStream.read() के स्टैंडर्ड दस्तावेज़ के मुताबिक हो जाता है. इस दस्तावेज़ में बताया गया है कि स्ट्रीम के खत्म होने पर -1 दिखता है.

जो ऐप्लिकेशन, रीड लूप से बाहर निकलने के लिए सिर्फ़ IOException को पकड़ने पर निर्भर होते हैं उन पर इस बदलाव का असर पड़ सकता है. इसलिए, उन्हें BluetoothSocket रीड लूप को अपडेट करना चाहिए, ताकि वे -1 की रिटर्न वैल्यू की साफ़ तौर पर जांच कर सकें. इससे यह पक्का होता है कि रिमोट डिवाइस के डिसकनेक्ट होने या सॉकेट के बंद होने पर, लूप सही तरीके से बंद हो जाए. सुझाए गए तरीके से लागू करने का उदाहरण देखने के लिए, Bluetooth डेटा ट्रांसफ़र करना गाइड में कोड स्निपेट देखें.