Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

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

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

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

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

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

从 Android 17 开始，系统会对以 Android 17（API 级别 37）或更高版本为目标平台的应用的 RemoteViews 更新强制执行严格的内存限制。当应用将 RemoteViews 对象传递给 AppWidgetManager.updateAppWidget 时，system_server 会计算载荷中每个方向和大小存储桶中所有图片数据的总内存占用。如果总内存超出系统上限 (mMaxWidgetBitmapMemory)，系统会拒绝更新并抛出 IllegalArgumentException：

java.lang.IllegalArgumentException: RemoteViews for widget update exceeds maximum bitmap memory usage (used: XXXXX, max: YYYYY)

对于以 API 级别 36 或更低级别为目标平台的应用，系统会将此内存违规行为记录为警告 (Slog.w)，而不会抛出异常。

Android skills

在 GitHub 上查看

管理 AppWidget 更新和位图内存

使用 AppWidget 更新和内存 Android 技能，对 widget 位图进行降采样，删除重复的自适应图片，并确保 Glance 和传统 AppWidgetProvider widget 均符合 Android 17 RemoteViews 内存限制。

如需从 Android CLI 安装技能，请运行以下命令：

android skills add glance-appwidget-updates-and-memory

系统会将活跃显示配置的 widget 位图内存预算设置为 6 * width * height 字节（1.5 * 4 * width * height，相当于全屏 ARGB_8888 缓冲区大小的 1.5 倍）。在 API 级别 37 及更高级别下，此计算包括以下两项：

存储在 RemoteViews.mBitmapCache 中的内存中 Bitmap 和位图支持的 Icon 对象（Icon.TYPE_BITMAP 和 Icon.TYPE_ADAPTIVE_BITMAP），例如对 setImageViewBitmap、Icon.createWithBitmap、Icon.createWithAdaptiveBitmap 或 Jetpack Glance ImageProvider(bitmap) 的调用。mBitmapCache 中每个唯一的 Bitmap 或位图支持的 Icon 实例在每个 RemoteViews 层次结构中都会被计数一次。
URI 支持的图片（Icon.createWithContentUri、setImageViewUri 或 Glance ImageProvider(uri)）不计入 system_server 中的 RemoteViews IPC 字节上限，但 widget 宿主进程会以完整分辨率将引用的 content:// 文件解码到其自己的堆中。在通过 FileProvider URI 公开降采样图片之前，请务必先将其写入 context.cacheDir。

为了确保在手机、平板电脑和可折叠设备上，微件更新不会超出内存上限，请执行以下操作：

根据 WindowMetrics 计算运行时内存预算：在 API 级别 30 及更高级别，从 WindowManager.currentWindowMetrics.bounds 而不是 resources.displayMetrics 读取活动窗口边界。在多分辨率设备和可折叠设备上，displayMetrics 可能会报告非活动显示屏尺寸。将总微件图片预算估算为 6L * bounds.width() * bounds.height()，如以下示例所示：

private const val FALLBACK_MAX_BYTES = 15_000_000L

fun calculateWidgetMemoryCapBytes(context: Context): Long {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
        val wm = context.getSystemService(WindowManager::class.java)
            ?: return FALLBACK_MAX_BYTES
        val bounds = wm.currentWindowMetrics.bounds
        return 6L * bounds.width().toLong() * bounds.height().toLong()
    }
    val dm = context.resources.displayMetrics
    return 6L * dm.widthPixels.toLong() * dm.heightPixels.toLong()
}

将图片降采样到微件的可查看尺寸，并使用 RGB_565：使用 2 的幂 BitmapFactory.Options.inSampleSize 值（大小为微件的最大显示尺寸 [maxWidthDp x maxHeightDp]）解码位图，并对不透明的照片和缩略图使用 Bitmap.Config.RGB_565（每个像素 2 字节）而不是 ARGB_8888（每个像素 4 字节）。
在 Jetpack Glance 中，将位图解码提升到 provideContent 之外：使用 SizeMode.Responsive 或 SizeMode.Exact 时，Glance 会针对每个尺寸分桶调用一次 provideContent lambda。在调用 provideContent 之前，在 provideGlance 中对每个共享的 Bitmap 解码一次，以便所有大小存储桶都引用 RemoteViews.mBitmapCache 中的同一 Bitmap 实例。
替换图片时使用完整的 updateAppWidget 调用：在传统 AppWidgetProvider 实现中，避免调用 AppWidgetManager.partiallyUpdateAppWidget 来交换 Bitmap 或 Icon 视图。部分更新会将新操作合并到 system_server 中的现有 RemoteViews 树中，而不会逐出之前缓存的映像操作。构建完整的 RemoteViews 布局，并改为调用 updateAppWidget。
提供错误后备布局：在 Jetpack Glance 中，替换 onCompositionError，以便在更新失败时呈现零位图 RemoteViews 后备。

您可以通过运行以下命令，在已连接的设备上检查微件当前的序列化位图内存用量：

adb shell dumpsys appwidget

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

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

MessageQueue को लॉक-फ़्री तरीके से लागू करने की नई सुविधा

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

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

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

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

सुलभता

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

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

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

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

निजता

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

ईसीएच (एन्क्रिप्ट किया गया ClientHello) चालू है

Android 17 में, एन्क्रिप्ट (सुरक्षित) किए गए ClientHello (ईसीएच) के लिए प्लैटफ़ॉर्म सपोर्ट की सुविधा जोड़ी गई है. यह एक टीएलएस एक्सटेंशन है, जो टीएलएस हैंडशेक में सर्वर नेम इंडिकेशन (एसएनआई) को एन्क्रिप्ट करके, उपयोगकर्ता की निजता को बेहतर बनाता है. एन्क्रिप्ट करने के इस तरीके से, नेटवर्क पर नज़र रखने वाले लोगों को उस डोमेन की पहचान करने में मुश्किल होती है जिससे आपका ऐप्लिकेशन कनेक्ट हो रहा है.

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

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

ज़्यादा जानकारी के लिए, एन्क्रिप्ट किया गया क्लाइंट हेलो दस्तावेज़ देखें.

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) या इसके बाद के वर्शन को टारगेट करने वाले ज़्यादातर ऐप्लिकेशन के लिए, ये एसएमएस मिलने के तीन घंटे बाद तक उपलब्ध नहीं होते. इस देरी का मकसद, ओटीपी को हाइजैक होने से रोकना है. इस तीन घंटे की देरी के दौरान, SMS_RECEIVED_ACTION ब्रॉडकास्ट को रोक दिया जाता है और एसएमएस सेवा देने वाली कंपनी के डेटाबेस की क्वेरी फ़िल्टर की जाती हैं. देरी के बाद, इन ऐप्लिकेशन के लिए एसएमएस उपलब्ध हो जाता है.

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

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

सुरक्षा

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

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

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

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

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

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

如果应用以 Android 17（API 级别 37）或更高版本为目标平台，则默认启用证书透明度 (CT)。（在 Android 16 中，CT 可用，但应用必须选择启用。）

Safer Native DCL—C

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

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

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

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

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

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

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

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

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

इंटेलिजेंस

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 से, ऑडियो फ़्रेमवर्क बैकग्राउंड में ऑडियो इंटरैक्शन पर पाबंदियां लागू करता है. इनमें ऑडियो प्लेबैक, ऑडियो फ़ोकस के अनुरोध, और आवाज़ बदलने वाले एपीआई शामिल हैं. इससे यह पक्का किया जाता है कि ये बदलाव उपयोगकर्ता की अनुमति से ही शुरू किए गए हों.

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

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

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

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

Android skills

管理 AppWidget 更新和位图内存

系统如何计算内存上限

缓解步骤

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

MessageQueue को लॉक-फ़्री तरीके से लागू करने की नई सुविधा

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

सुलभता

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

निजता

ईसीएच (एन्क्रिप्ट किया गया ClientHello) चालू है

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

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

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

सुरक्षा

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

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

Safer Native DCL—C

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

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

इंटेलिजेंस

setContentCaptureEnabled को बंद करना

Kotlin

Java

मीडिया

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

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

कनेक्टिविटी

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

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

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

系统如何计算内存上限

缓解步骤

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

MessageQueue को लॉक-फ़्री तरीके से लागू करने की नई सुविधा

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

सुलभता

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

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

निजता

ईसीएच (एन्क्रिप्ट किया गया ClientHello) चालू है

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

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

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

सुरक्षा

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

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

Safer Native DCL—C

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

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

इंटेलिजेंस

setContentCaptureEnabled को बंद करना

Kotlin

Java

मीडिया

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

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

कनेक्टिविटी

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