تغییرات رفتار: برنامه‌هایی که Android نسخه ۱۷ یا بالاتر را هدف‌یابی می‌کنند

‫Android 17، مانند نسخه‌های قبلی، شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامه‌هایی اعمال می‌شود که Android 17 یا بالاتر را هدف قرار می‌دهند. اگر برنامه شما Android نسخه ۱۷ یا بالاتر را هدف قرار می‌دهد، باید برنامه خود را برای پشتیبانی از این رفتارها، درصورت لزوم، اصلاح کنید.

حتماً فهرست تغییرات رفتاری را که بر همه برنامه‌های اجراشده در Android 17 تأثیر می‌گذارد، صرف‌نظر از targetSdkVersion برنامه‌تان، مرور کنید.

تجربه کاربری و واسط کاربر سیستم

Android 17 شامل تغییرات زیر است که هدف آن‌ها ایجاد تجربه کاربری یکپارچه‌تر و شهودی‌تر است.

ابزاره حد مجاز حافظه

از Android 17، سیستم محدودیت حافظه سخت‌گیرانه‌ای را برای به‌روزرسانی‌های RemoteViews برای برنامه‌هایی که Android 17 (سطح ای‌پی‌آی ۳۷) یا بالاتر را هدف قرار می‌دهند اعمال می‌کند. وقتی برنامه‌ای شیء RemoteViews را به AppWidgetManager.updateAppWidget ارسال می‌کند، system_server ردپای حافظه کل همه داده‌های تصویر را در هر جهت و دسته اندازه در بار خالص محاسبه می‌کند. اگر کل حافظه از سقف سیستم (mMaxWidgetBitmapMemory) فراتر رود، سیستم به‌روزرسانی را رد می‌کند و IllegalArgumentException را برمی‌گرداند:

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

برای برنامه‌هایی که سطح میانای برنامه‌سازی کاربردی ۳۶ یا پایین‌تر را هدف قرار می‌دهند، سیستم این نقض حافظه را به‌عنوان هشدار (Slog.w) بدون ایجاد استثنا ثبت می‌کند.

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

نحوه محاسبه سقف حافظه توسط سیستم

سیستم بودجه حافظه نقشه بیتی ابزاره را روی 6 * width * height بایت (1.5 * 4 * width * height، معادل ۱٫۵ برابر اندازه میان‌گیر ARGB_8888 تمام‌صفحه) برای پیکربندی نمایشگر فعال تنظیم می‌کند. در سطح میانای برنامه‌سازی کاربردی ۳۷ و بالاتر، این محاسبه شامل هر دو مورد زیر می‌شود:

• اشیاء Bitmap در حافظه و با پشتیبانی نگاشت بیتی Icon (Icon.TYPE_BITMAP و Icon.TYPE_ADAPTIVE_BITMAP) ذخیره‌شده در RemoteViews.mBitmapCache (مانند تماس با setImageViewBitmap، Icon.createWithBitmap، Icon.createWithAdaptiveBitmap، یا Jetpack Glance ImageProvider(bitmap)). هر نمونه Bitmap منحصربه‌فرد یا با پشتیبانی نگاشت بیتی Icon در mBitmapCache یک‌بار در هر سلسله‌مراتب RemoteViews شمرده می‌شود.
• تصاویر با پشتیبانی URI (Icon.createWithContentUri، setImageViewUri، یا Glance ImageProvider(uri)) در سقف بایت IPC RemoteViews در system_server محاسبه نمی‌شوند، اما فرایند میزبان ابزاره فایل content:// ارجاع‌شده را با وضوح کامل در توده خودش رمزگشایی می‌کند. همیشه تصویر نمونه‌کاهی‌شده را قبل‌از نمایش ازطریق URI‏ FileProvider در context.cacheDir بنویسید.

مراحل کاهش

برای اینکه به‌روزرسانی‌های ابزارک در تلفن‌ها، رایانه‌های لوحی، و دستگاه‌های تاشو در محدوده سقف حافظه باقی بماند، کارهای زیر را انجام دهید:

1. بودجه حافظه زمان اجرای خود را از WindowMetrics محاسبه کنید: در سطح API‏ ۳۰ و بالاتر، مرزهای پنجره فعال را از 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()
   }
   

2. تصاویر را به ابعاد قابل‌مشاهده ابزاره کاهش نمونه دهید و از RGB_565 استفاده کنید: نقشه‌های بیتی را با مقادیر توان دو BitmapFactory.Options.inSampleSize به اندازه حداکثر ابعاد نمایش ابزاره (maxWidthDp در maxHeightDp) رمزگشایی کنید و از Bitmap.Config.RGB_565 (2 بایت در هر پیکسل) به‌جای ARGB_8888 (4 بایت در هر پیکسل) برای عکس‌های مات و ریزعکس‌ها استفاده کنید.

3. Hoist bitmap decoding outside provideContent in Jetpack Glance: When using SizeMode.Responsive or SizeMode.Exact, Glance invokes your provideContent lambda once per size bucket. هر Bitmap هم‌رسانی‌شده را یک‌بار در provideGlance قبل‌از فراخوانی provideContent رمزگشایی کنید تا همه دسته‌های اندازه به همان نمونه Bitmap در RemoteViews.mBitmapCache ارجاع دهند.

4. هنگام جایگزین کردن تصاویر، از فراخوانی‌های کامل updateAppWidget استفاده کنید: در پیاده‌سازی‌های کلاسیک AppWidgetProvider، از فراخوانی AppWidgetManager.partiallyUpdateAppWidget برای جابه‌جا کردن نماهای Bitmap یا Icon خودداری کنید. به‌روزرسانی‌های جزئی کنش‌های جدید را در درخت RemoteViews موجود در system_server ادغام می‌کنند، بدون اینکه کنش‌های تصویری که قبلاً در حافظه نهان ذخیره شده‌اند حذف شوند. به‌جای آن، چیدمان RemoteViews کامل بسازید و updateAppWidget را فراخوانی کنید.

5. ارائه چیدمان جایگزین خطا: در Jetpack Glance، onCompositionError را لغو کنید تا اگر به‌روزرسانی ناموفق بود، جایگزین RemoteViews با نقشه بیتی صفر ارائه شود.

می‌توانید با اجرای دستور زیر، میزان استفاده فعلی از حافظه بیت‌مپ سریالی‌شده ابزارکتان را در دستگاه متصل‌شده بررسی کنید:

adb shell dumpsys appwidget

عملکرد اصلی

Android 17 شامل تغییرات زیر است که قابلیت‌های اصلی مختلف سیستم Android را اصلاح یا گسترش می‌دهد.

پیاده‌سازی جدید بدون قفل MessageQueue

از Android 17، برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند، پیاده‌سازی جدیدی از android.os.MessageQueue بدون قفل دریافت می‌کنند. پیاده‌سازی جدید عملکرد را بهبود می‌بخشد و فریم‌های ازدست‌رفته را کاهش می‌دهد، اما ممکن است مشتریانی را که به MessageQueue فیلدها و روش‌های خصوصی ارجاع می‌دهند خراب کند.

برای اطلاعات بیشتر، ازجمله استراتژی‌های کاهش، به راهنمای تغییر رفتار MessageQueue مراجعه کنید.

فیلدهای نهایی ثابت اکنون غیرقابل‌تغییر هستند

برنامه‌هایی که در Android 17 یا بالاتر اجرا می‌شوند و Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند نمی‌توانند فیلدهای static final را تغییر دهند. اگر برنامه‌ای تلاش کند فیلد static final را بااستفاده از بازتاب تغییر دهد، IllegalAccessException ایجاد خواهد شد. تلاش برای اصلاح یکی از این فیلدها ازطریق میاناهای برنامه‌سازی کاربردی JNI (مثل SetStaticLongField()) باعث ازکار افتادن برنامه می‌شود.

دسترس‌پذیری

Android 17 تغییرات زیر را برای بهبود دسترس‌پذیری ایجاد می‌کند.

پشتیبانی دسترس‌پذیری از تایپ پیچیده با صفحه‌کلید فیزیکی IME

این ویژگی میاناهای برنامه‌سازی کاربردی جدید AccessibilityEvent و TextAttribute را برای بهبود بازخورد گفتاری صفحه‌خوان برای ورودی زبان‌های چینی، ژاپنی، کره‌ای، و ویتنامی معرفی می‌کند. برنامه‌های CJKV IME اکنون می‌توانند نشان دهند که آیا نامزد تبدیل نوشتار درطول ترکیب نوشتار انتخاب شده است یا نه. برنامه‌هایی که فیلدهای ویرایش دارند می‌توانند هنگام ارسال رویدادهای دسترس‌پذیری تغییر نوشتار، انواع تغییر نوشتار را مشخص کنند. برای مثال، برنامه‌ها می‌توانند مشخص کنند که تغییر نوشتار درطول ترکیب‌بندی نوشتار رخ داده است، یا اینکه تغییر نوشتار ناشی از یک ثبت بوده است. با این کار، سرویس‌های دسترس‌پذیری مثل صفحه‌خوان‌ها می‌توانند براساس ماهیت اصلاح نوشتار، بازخورد دقیق‌تری ارائه دهند.

پذیرش برنامه

• برنامه‌های IME: هنگام تنظیم نوشتار ترکیب‌بندی در فیلدهای ویرایش، IMEها می‌توانند از TextAttribute.Builder.setTextSuggestionSelected() برای نشان دادن اینکه آیا نامزد تبدیل خاصی انتخاب شده است یا نه استفاده کنند.

• برنامه‌های دارای فیلدهای ویرایش: برنامه‌هایی که InputConnection سفارشی را حفظ می‌کنند می‌توانند داده‌های انتخاب نامزد را با فراخوانی TextAttribute.isTextSuggestionSelected() بازیابی کنند. سپس این برنامه‌ها باید هنگام ارسال رویدادهای TYPE_VIEW_TEXT_CHANGED، AccessibilityEvent.setTextChangeTypes() را فراخوانی کنند. برنامه‌هایی که Android 17 (سطح ای‌پی‌آی ۳۷) را هدف قرار می‌دهند و از TextView استاندارد استفاده می‌کنند، این ویژگی را به‌طور پیش‌فرض فعال خواهند داشت. (یعنی TextView بازیابی داده‌ها از IME و تنظیم انواع تغییر نوشتار را هنگام ارسال رویدادها به سرویس‌های دسترس‌پذیری مدیریت خواهد کرد).

• خدمات دسترس‌پذیری: خدمات دسترس‌پذیری که رویدادهای TYPE_VIEW_TEXT_CHANGED را پردازش می‌کنند می‌توانند AccessibilityEvent.getTextChangeTypes() را فراخوانی کنند تا ماهیت اصلاح را شناسایی کنند و راهبردهای بازخوردشان را براساس آن تنظیم کنند.

حریم خصوصی

Android 17 شامل تغییرات زیر برای بهبود حریم خصوصی کاربر است.

ECH (Encrypted Client Hello) فعال شد

‫Android 17 پشتیبانی پلاتفرم را برای Encrypted Client Hello (ECH) معرفی می‌کند، یک افزونه TLS که با رمزگذاری Server Name Indication (SNI) در دست‌دهی TLS، حریم خصوصی کاربر را بهبود می‌بخشد. این رمزگذاری کمک می‌کند ناظران شبکه نتوانند به‌راحتی دامنه خاصی را که برنامه‌تان به آن متصل می‌شود شناسایی کنند.

برای برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند، از ECH برای اتصال‌های TLS استفاده می‌شود. ‫ECH فقط درصورتی فعال است که کتابخانه شبکه‌ای که برنامه استفاده می‌کند (برای مثال، HttpEngine،‏ WebView، یا OkHttp) پشتیبانی از ECH را ادغام کرده باشد و سرور راه دور نیز از پروتکل ECH پشتیبانی کند. اگر ECH قابل‌مذاکره نباشد، کارخواه افزونه ECH را با محتوای تصادفی ارسال می‌کند (سازوکاری به‌نام ECH GREASE). برای جزئیات بیشتر درباره نحوه عملکرد ECH GREASE، به RFC 9849 مراجعه کنید.

برای اینکه برنامه‌ها بتوانند این رفتار را سفارشی‌سازی کنند، Android 17 عنصر جدید <domainEncryption> را به فایل «پیکربندی امنیت شبکه» اضافه می‌کند. توسعه‌دهندگان می‌توانند از <domainEncryption> در برچسب‌های <base-config> یا <domain-config> برای انتخاب حالت ECH (برای مثال، "enabled" یا "disabled") به‌صورت سراسری یا برای هر دامنه استفاده کنند.

برای اطلاعات بیشتر، به مستندات Encrypted Client Hello مراجعه کنید.

اجازه شبکه محلی برای برنامه‌هایی که Android 17 را هدف قرار می‌دهند الزامی است

Android 17 اجازه زمان اجرای ACCESS_LOCAL_NETWORK را معرفی می‌کند تا از کاربران دربرابر دسترسی غیرمجاز به شبکه محلی محافظت کند. چون این مورد تحت گروه اجازه NEARBY_DEVICES موجود قرار می‌گیرد، از کاربرانی که قبلاً اجازه‌های دیگر NEARBY_DEVICES را اعطا کرده‌اند دوباره درخواست نمی‌شود. این الزام جدید مانع از آن می‌شود که برنامه‌های مخرب از دسترسی نامحدود به شبکه محلی برای ردگیری مخفیانه کاربر و انگشت‌نگاری سوءاستفاده کنند. با اعلام و درخواست این اجازه، برنامه‌تان می‌تواند دستگاه‌های موجود در شبکه محلی (LAN) را، مثل دستگاه‌های خانه هوشمند یا گیرنده‌های ارسال محتوا، پیدا کند و به آن‌ها متصل شود.

برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند، اکنون دو راه برای حفظ ارتباط با دستگاه‌های LAN دارند: استفاده از انتخاب‌گرهای دستگاه با واسطه سیستم و حافظ حریم خصوصی برای رد شدن از درخواست اجازه، یا درخواست صریح این اجازه جدید در زمان اجرا برای حفظ ارتباط شبکه محلی.

برای اطلاعات بیشتر، به سند اجازه شبکه محلی مراجعه کنید.

درحال پنهان کردن گذرواژه‌ها از دستگاه‌های فیزیکی

اگر برنامه‌ای Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار دهد و کاربر از دستگاه ورودی فیزیکی (برای مثال، صفحه‌کلید خارجی) استفاده کند، سیستم‌عامل Android تنظیم جدید show_passwords_physical را برای همه نویسه‌ها در فیلد گذرواژه اعمال می‌کند. به‌طور پیش‌فرض، این تنظیم همه نویسه‌های گذرواژه را پنهان می‌کند.

سیستم Android آخرین نویسه تایپ‌شده گذرواژه را نشان می‌دهد تا به کاربر کمک کند ببیند آیا گذرواژه را اشتباه تایپ کرده است یا نه. بااین‌حال، این کار برای صفحه‌کلیدهای خارجی بزرگ‌تر بسیار کمتر ضروری است. علاوه‌براین، دستگاه‌های دارای صفحه‌کلید خارجی اغلب نمایشگرهای بزرگ‌تری دارند که خطر دیده شدن گذرواژه تایپ‌شده توسط دیگران را افزایش می‌دهد.

اگر کاربر از صفحه لمسی دستگاه استفاده می‌کند، سیستم تنظیم جدید show_passwords_touch را اعمال می‌کند.

محافظت از گذرواژه یک‌بارمصرف برای پیامک‌های استاندارد

از Android 17،‏ Android محافظت از گذرواژه یک‌بارمصرف پیامکی را گسترش می‌دهد تا برای پیامک‌های استاندارد (پیامک‌های حاوی گذرواژه یک‌بارمصرف که از قالب‌های WebOTP یا SMS Retriever استفاده نمی‌کنند) اعمال شود. برای اکثر برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند، این پیامک‌ها تا سه ساعت پس‌از دریافت دردسترس قرار نمی‌گیرند. هدف از این تأخیر کمک به جلوگیری از سرقت گذرواژه یک‌بارمصرف است. درطول این تأخیر سه‌ساعته، SMS_RECEIVED_ACTION پخش همگانی متوقف می‌شود و پُرسمان‌های پایگاه داده ارائه‌دهنده پیامک فیلتر می‌شود. پیامک پس‌از تأخیر برای این برنامه‌ها دردسترس است.

برخی‌از برنامه‌ها مانند برنامه دستیار پیامک پیش‌فرض، برنامه‌های همراه دستگاه متصل، و غیره از این تأخیر معاف هستند. همه برنامه‌هایی که برای استخراج گذرواژه یک‌بارمصرف به خواندن پیامک متکی هستند باید برای اطمینان از تداوم عملکرد به استفاده از میاناهای برنامه‌سازی کاربردی بازیابی پیامک یا رضایت کاربر پیامک روی آورند.

امنیت

Android 17 بهبودهای زیر را در امنیت دستگاه و برنامه ایجاد می‌کند.

امنیت فعالیت

در Android 17، این پلاتفرم به حرکت خود به‌سمت معماری «پیش‌فرضاً امن» ادامه می‌دهد و مجموعه‌ای از بهبودها را معرفی می‌کند که برای کاهش سوءاستفاده‌های با شدت بالا مانند رمزگیری، ربودن تعامل، و حملات «معاون سردرگم» طراحی شده‌اند. این به‌روزرسانی توسعه‌دهندگان را ملزم می‌کند که صریحاً با استانداردهای امنیتی جدید موافقت کنند تا سازگاری برنامه و محافظت از کاربر حفظ شود.

تأثیرات کلیدی برای توسعه‌دهندگان شامل موارد زیر است:

• تقویت BAL و بهبود موافقت: ما درحال اصلاح محدودیت‌های «راه‌اندازی فعالیت پس‌زمینه» (BAL) هستیم و این کار را با گسترش محافظت‌ها به IntentSender انجام می‌دهیم. توسعه‌دهندگان باید از ثابت قدیمی MODE_BACKGROUND_ACTIVITY_START_ALLOWED مهاجرت کنند. درعوض، باید کنترل‌های جزئی مثل MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE را اتخاذ کنید که شروع فعالیت را به سناریوهایی محدود می‌کند که برنامه تماس‌گیرنده نمایان است، و به‌طور قابل‌توجهی سطح حمله را کاهش می‌دهد.
• ابزارهای پذیرش: توسعه‌دهندگان باید از حالت سخت‌گیرانه و بررسی‌های lint به‌روزشده برای شناسایی الگوهای قدیمی و اطمینان از آمادگی برای الزامات کیت توسعه نرم‌افزار هدف آینده استفاده کنند.

فعال کردن CT به‌طور پیش‌فرض

اگر برنامه‌ای Android 17 (سطح ای‌پی‌آی ۳۷) یا بالاتر را هدف‌یابی کند، شفافیت گواهینامه (CT) به‌طور پیش‌فرض فعال می‌شود. (در Android 16،‏ CT دردسترس است اما برنامه‌ها باید موافقت کنند.)

Safer Native DCL—C

اگر برنامه شما Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار دهد، محافظت «بارگیری کد پویای ایمن‌تر» (DCL) که در Android 14 برای فایل‌های DEX و JAR معرفی شده است، اکنون به کتابخانه‌های بومی گسترش می‌یابد.

همه فایل‌های بومی بارشده بااستفاده از System.load() باید به‌عنوان فقط‌خواندنی علامت‌گذاری شوند. درغیراین‌صورت، سیستم UnsatisfiedLinkError را برمی‌گرداند.

توصیه می‌کنیم برنامه‌ها تا حد امکان از بار کردن پویای کد اجتناب کنند، زیرا این کار خطر به‌خطر افتادن برنامه ازطریق تزریق کد یا دست‌کاری کد را به‌شدت افزایش می‌دهد.

محدود کردن فیلدهای اطلاعات شناساننده شخصی در نمای داده CP2

برای برنامه‌هایی که Android 17 (سطح API‏ ۳۷) و بالاتر را هدف قرار می‌دهند، «ارائه‌دهنده مخاطبین ۲» (CP2) ستون‌های خاصی را که حاوی «اطلاعات شناساننده شخصی» (PII) هستند از نمای داده محدود می‌کند. وقتی این تغییر فعال شود، این ستون‌ها از نمای داده برداشته می‌شوند تا حریم خصوصی کاربر بهبود یابد. ستون‌های محدودشده شامل موارد زیر است:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

برنامه‌هایی که از این ستون‌ها از ContactsContract.Data استفاده می‌کنند می‌توانند آن‌ها را از ContactsContract.RawContacts استخراج کنند، با پیوستن به RAW_CONTACT_ID.

اجرای بررسی‌های سخت‌گیرانه SQL در CP2

برای برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) و بالاتر را هدف‌یابی می‌کنند، «ارائه‌کننده مخاطبین ۲» (CP2) هنگام دسترسی به جدول ContactsContract.Data بدون اجازه READ_CONTACTS، اعتبارسنجی سخت‌گیرانه پُرسمان SQL را اعمال می‌کند.

با این تغییر، اگر برنامه‌ای اجازه READ_CONTACTS نداشته باشد، هنگام پرسمان جدول ContactsContract.Data، گزینه‌های StrictColumns و StrictGrammar تنظیم می‌شوند. اگر پُرسمانی از الگویی استفاده کند که با این موارد سازگار نباشد، رد می‌شود و باعث ایجاد استثنا می‌شود.

هوش

Android 17 شامل تغییرات زیر در هوش سامانه است.

منسوخ شدن setContentCaptureEnabled

«ضبط محتوا» به‌طور پیش‌فرض در برخی دستگاه‌ها فعال است تا ویژگی‌های هوش مصنوعی درون‌دستگاهی بتوانند محتوای صفحه‌نمایش را برای تجربه‌های هوشمند تجزیه‌وتحلیل کنند.

از Android 17، روش API ContentCaptureManager.setContentCaptureEnabled(boolean) منسوخ شده است. برای برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف‌یابی می‌کنند، فراخوانی setContentCaptureEnabled(false) دیگر «ضبط محتوا» را غیرفعال نمی‌کند.

اگر برنامه‌تان باید همچنان «ضبط محتوا» را غیرفعال کند یا محتوای صفحه را از ضبط شدن توسط سیستم محدود کند، باید به استفاده از پارامتر چیدمان پنجره FLAG_SECURE منتقل شوید.

برای غیرفعال کردن «ضبط محتوا»، پرچم FLAG_SECURE را در پنجره‌تان تنظیم کنید، همان‌طور که در مثال زیر نشان داده شده است:

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

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

برای جزئیات بیشتر، سند مرجع WindowManager.LayoutParams.FLAG_SECURE را ببینید.

رسانه

Android 17 شامل تغییرات زیر در رفتار رسانه است.

تقویت صدای پس‌زمینه

از Android 17، چارچوب صوتی محدودیت‌هایی را بر تعاملات صوتی پس‌زمینه، ازجمله بازپخش صدا، درخواست‌های تمرکز صوتی، و میاناهای برنامه‌سازی کاربردی تغییر میزان صدا اعمال می‌کند تا اطمینان حاصل شود که این تغییرات به‌طور عمدی توسط کاربر شروع شده‌اند.

برخی محدودیت‌های صوتی برای همه برنامه‌ها اعمال می‌شود. بااین‌حال، اگر برنامه Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) را هدف قرار دهد، محدودیت‌ها سخت‌گیرانه‌تر است. اگر یکی از این برنامه‌ها هنگامی که در پس‌زمینه است با صدا تعامل داشته باشد، باید سرویس پیش‌زمینه‌ای در آن درحال اجرا باشد. علاوه‌براین، برنامه باید یکی از این الزامات یا هر دو را برآورده کند:

• سرویس پیش‌زمینه‌ای باید قابلیت‌های «درحال استفاده» (WIU) داشته باشد.
• برنامه باید اجازه زنگ ساعت دقیق را داشته باشد و با جاری‌سازی‌های صوتی USAGE_ALARM تعامل داشته باشد.

برای اطلاعات بیشتر، ازجمله استراتژی‌های کاهش، به تقویت صدای پس‌زمینه مراجعه کنید.

ضریب‌های شکل دستگاه

Android 17 شامل تغییرات زیر برای بهبود تجربه کاربری در طیفی از اندازه‌ها و ابعاد دستگاه است.

تغییرات میانای برنامه‌سازی کاربردی پلاتفرم برای نادیده گرفتن محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی در صفحه‌نمایش‌های بزرگ (sw>=600dp)

در Android 16، تغییراتی در میانای برنامه‌سازی کاربردی پلاتفرم ایجاد کردیم تا محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی در صفحه‌نمایش‌های بزرگ (sw >= 600dp) برای برنامه‌هایی که سطح میانای برنامه‌سازی کاربردی 36 یا بالاتر را هدف‌یابی می‌کنند نادیده گرفته شود. توسعه‌دهندگان می‌توانند با کیت توسعه نرم‌افزار ۳۶ از این تغییرات انصراف دهند، اما این انصراف دیگر برای برنامه‌هایی که Android ۱۷ (سطح API‏ ۳۷) یا بالاتر را هدف قرار می‌دهند دردسترس نخواهد بود.

برای اطلاعات بیشتر، محدودیت‌های مربوط به جهت و قابلیت تغییر اندازه نادیده گرفته می‌شوند را ببینید.

اتصال‌پذیری

‫Android 17 تغییر زیر را برای بهبود سازگاری و هم‌راستایی با رفتار استاندارد Java InputStream برای سوکت‌های RFCOMM بلوتوث معرفی می‌کند.

رفتار read()‎ در BluetoothSocket سازگار برای RFCOMM

برای برنامه‌هایی که Android 17 (سطح API‏ ۳۷) را هدف قرار می‌دهند، روش read() در InputStream که از BluetoothSocket مبتنی بر RFCOMM به‌دست می‌آید اکنون وقتی سوکت بسته می‌شود یا اتصال قطع می‌شود، -1 را برمی‌گرداند.

این تغییر باعث می‌شود رفتار سوکت RFCOMM با سوکت‌های LE CoC سازگار شود و با اسناد استاندارد InputStream.read() مطابقت داشته باشد، که بیان می‌کند وقتی به انتهای جریان می‌رسیم، -1 برگردانده می‌شود.

برنامه‌هایی که برای خارج شدن از حلقه خواندن صرفاً به گرفتن IOException متکی هستند ممکن است تحت تأثیر این تغییر قرار بگیرند و باید حلقه‌های خواندن BluetoothSocket را به‌روز کنند تا به‌طور صریح مقدار برگشتی -1 را بررسی کنند. این کار تضمین می‌کند که وقتی دستگاه ازراه‌دور قطع می‌شود یا سوکت بسته می‌شود، حلقه به‌درستی خاتمه می‌یابد. برای دیدن نمونه‌ای از پیاده‌سازی توصیه‌شده، به تکه‌کد در راهنمای انتقال داده‌های بلوتوث مراجعه کنید.