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 में, 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 या एसएमएस रिट्रीवर फ़ॉर्मैट का इस्तेमाल नहीं करते) पर भी लागू कर रहा है. 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 को डिफ़ॉल्ट रूप से चालू करना

If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)

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 में, एसक्यूएल की सख्त जांच लागू करना

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) enforces strict SQL query validation when the ContactsContract.Data table is accessed without READ_CONTACTS permission.

With this change, if an app doesn't have READ_CONTACTS permission, StrictColumns and StrictGrammar options are set when querying the ContactsContract.Data table. If a query uses a pattern that isn't compatible with these, it will be rejected and cause an exception to be thrown.

मीडिया

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

बैकग्राउंड में ऑडियो चलाने की सुविधा को ज़्यादा सुरक्षित बनाना

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:

The foreground service must have while-in-use (WIU) capabilities.
The app must have the exact alarm permission and be interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

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

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

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

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

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

कनेक्टिविटी

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

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

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.