Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

बर्ताव में किए गए उन बदलावों की सूची भी देखें जो Android 17 पर चलने वाले सभी ऐप्लिकेशन पर लागू होते हैं. भले ही, आपके ऐप्लिकेशन का targetSdkVersion कुछ भी हो.

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

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() इवेंट भेजते समय, 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 में, एन्क्रिप्ट (सुरक्षित) किए गए Client Hello (ECH) के लिए प्लैटफ़ॉर्म की सुविधा जोड़ी गई है. यह TLS का एक एक्सटेंशन है. इससे, TLS हैंडशेक में Server Name Indication (SNI) को एन्क्रिप्ट (सुरक्षित) करके, उपयोगकर्ता की निजता को बेहतर बनाया जाता है. इस एन्क्रिप्ट (सुरक्षित) करने की सुविधा से, नेटवर्क पर नज़र रखने वाले लोगों को यह आसानी से पता नहीं चल पाता कि आपका ऐप्लिकेशन किस डोमेन से कनेक्ट हो रहा है.

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

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

ज़्यादा जानकारी के लिए, एन्क्रिप्ट (सुरक्षित) किए गए Client Hello से जुड़ा दस्तावेज़ देखें.

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

Android 17 introduces the ACCESS_LOCAL_NETWORK runtime permission to protect users from unauthorized local network access. Because this falls under the existing NEARBY_DEVICES permission group, users who have already granted other NEARBY_DEVICES permissions aren't prompted again. This new requirement prevents malicious apps from exploiting unrestricted local network access for covert user tracking and fingerprinting. By declaring and requesting this permission, your app can discover and connect to devices on the local area network (LAN), such as smart home devices or casting receivers.

Apps targeting Android 17 (API level 37) or higher now have two paths to maintain communication with LAN devices: Adopt system-mediated, privacy-preserving device pickers to skip the permission prompt, or explicitly request this new permission at runtime to maintain local network communication.

For more information, see the Local network permission documentation.

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

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

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

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

एसएमएस के स्टैंडर्ड मैसेज के लिए, ओटीपी की सुरक्षा

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

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

सुरक्षा

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.

CT को डिफ़ॉल्ट रूप से चालू करना

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

Native DCL—C को ज़्यादा सुरक्षित बनाना

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

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

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

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

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

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

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

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

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

मीडिया

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) को टारगेट करने वाले ऐप्लिकेशन के लिए, InputStream से मिले RFCOMM पर आधारित BluetoothSocket का read() तरीका अब सॉकेट बंद होने या कनेक्शन ड्रॉप होने पर -1 दिखाता है.

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

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