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

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

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

ध्यान दें: इस पेज पर, कुछ अहम बदलावों की सूची दी गई है. ज़्यादा जानकारी के लिए, Android 17 के रिलीज़ नोट देखें.

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

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

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

从 Android 17 开始，对于以 Android 17（API 级别 37）或更高版本为目标平台的应用，系统会对 RemoteViews 软件包中存在的位图和图标的组合内存使用量强制执行严格的内存限制 (1.5 * 屏幕宽度 * 屏幕高度 * 4)。超出这些限制会抛出致命的 IllegalArgumentException 并导致应用进程崩溃。

如需了解详情，请参阅 UpdateAppWidget。

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

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

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

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

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

Apps running on Android 17 or higher that target Android 17 (API level 37) or higher cannot change static final fields. If an app attempts to change a static final field by using reflection, it will cause an IllegalAccessException. Attempting to modify one of these fields through JNI APIs (such as SetStaticLongField()) will cause the app to crash.

सुलभता

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.

Note: In Android 16, apps could opt in to local network permissions. Beginning with Android 17, enforcement is mandatory for apps that target Android 17 (API level 37) or higher.

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

If an app targets Android 17 (API level 37) or higher and the user is using a physical input device (for example, an external keyboard), the Android operating system applies the new show_passwords_physical setting to all characters in the password field. By default, that setting hides all password characters.

The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.

If the user is using the device's touchscreen, the system applies the new show_passwords_touch setting.

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

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

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

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

सुरक्षा

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

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

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

डेवलपर पर पड़ने वाले मुख्य असर:

• बैकग्राउंड ऐक्टिविटी लॉन्च (बीएएल) की पाबंदियों को और सख्त किया जा रहा है और ऑप्ट-इन करने की सुविधा को बेहतर बनाया जा रहा है: हम बैकग्राउंड ऐक्टिविटी लॉन्च (बीएएल) की पाबंदियों को और सख्त कर रहे हैं. साथ ही, IntentSender के लिए सुरक्षा को बेहतर बना रहे हैं. डेवलपर को लेगसी MODE_BACKGROUND_ACTIVITY_START_ALLOWED कॉन्स्टेंट से माइग्रेट करना होगा. इसके बजाय, आपको MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE जैसे बेहतर कंट्रोल का इस्तेमाल करना चाहिए. इससे, ऐक्टिविटी सिर्फ़ उन स्थितियों में शुरू हो पाती है जहां कॉल करने वाला ऐप्लिकेशन दिखता है. इससे, हमले की आशंका काफ़ी कम हो जाती है.
• अपनाने के टूल: डेवलपर को लेगसी पैटर्न की पहचान करने के लिए, स्ट्रिक्ट मोड और अपडेट किए गए लिंट चेक का इस्तेमाल करना चाहिए. साथ ही, यह पक्का करना चाहिए कि वे आने वाले समय में टारगेट किए जाने वाले एसडीके की ज़रूरी शर्तों को पूरा कर सकें.

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

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

Safer Native DCL—C

如果您的应用以 Android 17（API 级别 37）或更高版本为目标平台，则 Android 14 中针对 DEX 和 JAR 文件引入的更安全的动态代码加载 (DCL) 保护功能现在也适用于原生库。

使用 System.load() 加载的所有原生文件都必须标记为只读。否则，系统会抛出 UnsatisfiedLinkError。

我们建议应用尽可能避免动态加载代码，因为这样做会大大增加应用因代码注入或代码篡改而遭到入侵的风险。

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

对于以 Android 17（API 级别 Android 17（API 级别 37））及更高版本为目标平台的应用，联系人提供程序 2 (CP2) 会限制数据视图中包含某些个人身份信息 (PII) 的列。启用此变更后，这些列将从数据视图中移除，以增强用户隐私保护。 受限列包括：

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

如果应用正在使用 ContactsContract.Data 中的这些列，则可以通过与 RAW_CONTACT_ID 联接，改为从 ContactsContract.RawContacts 中提取这些列。

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 में, सिस्टम इंटेलिजेंस से जुड़े ये बदलाव किए गए हैं.

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

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

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

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

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

Kotlin

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

Java

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

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

मीडिया

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

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

从 Android 17 开始，音频框架对后台音频互动（包括音频播放、音频焦点请求和音量更改 API）强制执行限制，以确保这些更改是由用户有意启动的。

部分音频限制适用于所有应用。不过，如果应用以 Android 17（API 级别 37）为目标平台，则限制会更加严格。如果这些应用在后台运行时与音频互动，则必须有前台服务正在运行。此外，应用还必须满足以下一项或两项要求：

• 前台服务必须具有仅在使用时授予的权限 (WIU)。
• 应用必须具有精确闹钟权限，并且正在与 USAGE_ALARM 音频流互动。

如需了解详情（包括缓解措施），请参阅后台音频安全加固。

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

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

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

我们在 Android 16 中引入了平台 API 变更，以 忽略屏幕方向、 宽高比和尺寸调整能力限制（针对大型屏幕，sw >= 600dp），适用于面向 API 级别 36 或更高级别的应用。开发者可以选择使用 SDK 36 退出这些变更，但对于面向 Android 17（API 级别 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.