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 में, सुलभता को बेहतर बनाने के लिए ये बदलाव किए गए हैं.

This feature introduces new AccessibilityEvent and TextAttribute APIs to enhance screen reader spoken feedback for CJKV language input. CJKV IME apps can now signal whether a text conversion candidate has been selected during text composition. Apps with edit fields can specify text change types when sending text changed accessibility events. For example, apps can specify that a text change occurred during text composition, or that a text change resulted from a commit. Doing this enables accessibility services such as screen readers to deliver more precise feedback based on the nature of the text modification.

App adoption

IME Apps: When setting composing text in edit fields, IMEs can use TextAttribute.Builder.setTextSuggestionSelected() to indicate whether a specific conversion candidate was selected.
Apps with Edit Fields: Apps that maintain a custom InputConnection can retrieve candidate selection data by calling TextAttribute.isTextSuggestionSelected(). These apps should then call AccessibilityEvent.setTextChangeTypes() when dispatching TYPE_VIEW_TEXT_CHANGED events. Apps targeting Android 17 (API level 37) that use the standard TextView will have this feature enabled by default. (That is, TextView will handle retrieving data from the IME and setting text change types when sending events to accessibility services).
Accessibility Services: Accessibility services that process TYPE_VIEW_TEXT_CHANGED events can call AccessibilityEvent.getTextChangeTypes() to identify the nature of the modification and adjust their feedback strategies accordingly.

निजता

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

ECH (Encrypted Client Hello) की सुविधा चालू की गई

Android 17 introduces platform support for Encrypted Client Hello (ECH), a TLS extension that enhances user privacy by encrypting the Server Name Indication (SNI) in the TLS handshake. This encryption helps prevent network observers from easily identifying the specific domain your app is connecting to.

For apps targeting Android 17 (API level 37) or higher, ECH is opportunistically used for TLS connections. ECH is active only if the networking library used by the app (for example, HttpEngine, WebView, or OkHttp) has integrated ECH support and the remote server also supports the ECH protocol. If ECH cannot be negotiated, the connection automatically falls back to a standard TLS handshake without SNI encryption.

To allow apps to customize this behavior, Android 17 adds a new <domainEncryption> element to the Network Security Configuration file. Developers can use <domainEncryption> within <base-config> or <domain-config> tags to select an ECH mode (for example, "opportunistic", "enabled", or "disabled") on a global or per-domain basis.

For more information, see the Encrypted Client Hello documentation.

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 में, डिवाइस और ऐप्लिकेशन की सुरक्षा को बेहतर बनाने के लिए ये बदलाव किए गए हैं.

गतिविधि की सुरक्षा

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 डेटा व्यू में पीआईआई फ़ील्ड को सीमित करना

For apps targeting Android 17 (API level Android 17 (API level 37)) and higher, Contacts Provider 2 (CP2) restricts certain columns containing Personally Identifiable Information (PII) from the data view. When this change is enabled, these columns are removed from the data view to enhance user privacy. The restricted columns include:

Apps that are using these columns from ContactsContract.Data can extract them from ContactsContract.RawContacts instead, by joining with 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 में, मीडिया के व्यवहार में ये बदलाव किए गए हैं.

बैकग्राउंड ऑडियो को बेहतर बनाना

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

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

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

ज़्यादा जानकारी के लिए, बैकग्राउंड में ऑडियो को सुरक्षित करने के तरीके देखें. इसमें, इन समस्याओं को कम करने की रणनीतियां भी शामिल हैं.

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

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

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

We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.

For more information, see Restrictions on orientation and resizability are ignored.

कनेक्टिविटी

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 की रिटर्न वैल्यू की साफ़ तौर पर जांच की जा सके. इससे यह पक्का होता है कि रिमोट डिवाइस के डिसकनेक्ट होने या सॉकेट के बंद होने पर, लूप सही तरीके से खत्म हो जाए. सुझाई गई प्रोसेस के उदाहरण के लिए, ब्लूटूथ से डेटा ट्रांसफ़र करने की गाइड में दिया गया कोड स्निपेट देखें.