مانند نسخه‌های قبلی، Android 17 شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامه‌هایی اعمال می‌شود که Android 17 یا بالاتر را هدف‌یابی می‌کنند. اگر برنامه شما Android 17 یا بالاتر را هدف‌یابی می‌کند، باید برنامه خود را اصلاح کنید تا درصورت لزوم از این رفتارها پشتیبانی کند.
حتماً فهرست تغییرات رفتاری که بر همه برنامه‌های
اجراشده در Android 17 تأثیر می‌گذارد را صرف‌نظر از targetSdkVersion برنامه‌تان بررسی کنید.
تجربه کاربری و واسط کاربر سیستم
Android 17 شامل تغییرات زیر است که هدف آنها ایجاد تجربه کاربری یکپارچه‌تر و شهودی‌تر است.
ابزاره حد مجاز حافظه
از Android 17 شروع می‌شود، برای برنامه‌هایی که
Android 17 (سطح API 37) یا بالاتر را هدف‌یابی می‌کنند، سیستم محدودیت حافظه سخت‌گیرانه‌ای (۱٫۵ * عرض صفحه * ارتفاع صفحه * ۴) دربرابر استفاده ترکیبی از حافظه
هم «بیت‌مپ‌ها» و هم «نمادهای» موجود در بسته RemoteViews اعمال می‌کند. فراتر رفتن از این محدودیت‌ها باعث بروز خطای مهلک IllegalArgumentException و ازکارافتادن فرایند برنامه می‌شود.
برای اطلاعات بیشتر، UpdateAppWidget را ببینید.
عملکرد اصلی
Android 17 شامل تغییرات زیر است که قابلیت‌های اصلی مختلف سیستم Android را اصلاح یا گسترش می‌دهد.
پیاده‌سازی جدید بدون قفل MessageQueue
با شروع از اندروید ۱۷، برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، یک پیاده‌سازی جدید و بدون قفل از android.os.MessageQueue دریافت می‌کنند. این پیاده‌سازی جدید عملکرد را بهبود می‌بخشد و فریم‌های از دست رفته را کاهش می‌دهد، اما ممکن است کلاینت‌هایی را که روی فیلدها و متدهای خصوصی MessageQueue تأمل می‌کنند، خراب کند.
برای اطلاعات بیشتر، از جمله استراتژی‌های کاهش، به راهنمای تغییر رفتار MessageQueue مراجعه کنید.
فیلدهای نهایی ثابت اکنون غیرقابل تغییر هستند
برنامه‌هایی که روی اندروید ۱۷ یا بالاتر اجرا می‌شوند و اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، نمی‌توانند فیلدهای static final را تغییر دهند. اگر برنامه‌ای سعی کند با استفاده از reflection یک فیلد static final تغییر دهد، باعث ایجاد خطای IllegalAccessException می‌شود. تلاش برای تغییر یکی از این فیلدها از طریق APIهای JNI (مانند SetStaticLongField() ) باعث خرابی برنامه خواهد شد.
دسترس‌پذیری
Android 17 تغییرات زیر را برای بهبود دسترس‌پذیری ایجاد می‌کند.
پشتیبانی از دسترس‌پذیری برای تایپ کردن با صفحه‌کلید فیزیکی IME پیچیده
این ویژگی، APIهای AccessibilityEvent و TextAttribute جدیدی را برای بهبود بازخورد گفتاری صفحه‌خوان برای ورودی زبان CJKV معرفی می‌کند. برنامه‌های CJKV IME اکنون می‌توانند نشان دهند که آیا یک کاندید تبدیل متن در طول ترکیب متن انتخاب شده است یا خیر. برنامه‌های دارای فیلد ویرایش می‌توانند هنگام ارسال رویدادهای دسترسی تغییر متن، انواع تغییر متن را مشخص کنند. به عنوان مثال، برنامه‌ها می‌توانند مشخص کنند که تغییر متن در طول ترکیب متن رخ داده است یا اینکه تغییر متن ناشی از یک commit است. انجام این کار، سرویس‌های دسترسی مانند صفحه‌خوان‌ها را قادر می‌سازد تا بازخورد دقیق‌تری را بر اساس ماهیت تغییر متن ارائه دهند.
پذیرش برنامه
برنامه‌های IME: هنگام تنظیم متن نوشتاری در فیلدهای ویرایش، IMEها می‌توانند از
TextAttribute.Builder.setTextSuggestionSelected()برای نشان دادن اینکه آیا یک کاندید تبدیل خاص انتخاب شده است یا خیر، استفاده کنند.برنامه‌هایی با فیلدهای ویرایش: برنامه‌هایی که یک
InputConnectionسفارشی دارند می‌توانند داده‌های انتخاب کاندید را با فراخوانیTextAttribute.isTextSuggestionSelected()بازیابی کنند. این برنامه‌ها سپس بایدAccessibilityEvent.setTextChangeTypes()را هنگام ارسال رویدادهایTYPE_VIEW_TEXT_CHANGEDفراخوانی کنند. برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) را هدف قرار می‌دهند و ازTextViewاستاندارد استفاده می‌کنند، این ویژگی را به طور پیش‌فرض فعال خواهند داشت. (یعنی،TextViewهنگام ارسال رویدادها به سرویس‌های دسترسی، بازیابی داده‌ها از IME و تنظیم انواع تغییر متن را مدیریت خواهد کرد).سرویس‌های دسترسی‌پذیری: سرویس‌های دسترسی‌پذیری که رویدادهای
TYPE_VIEW_TEXT_CHANGEDرا پردازش می‌کنند، می‌توانندAccessibilityEvent.getTextChangeTypes()را فراخوانی کنند تا ماهیت تغییر را شناسایی کرده و استراتژی‌های بازخورد خود را بر اساس آن تنظیم کنند.
حریم خصوصی
Android 17 شامل تغییرات زیر برای بهبود حریم خصوصی کاربر است.
ECH (سلام کارخواه رمزگذاری‌شده) فعال شد
اندروید ۱۷ پشتیبانی پلتفرم از Encrypted Client Hello (ECH) را معرفی می‌کند، یک افزونه TLS که با رمزگذاری Server Name Indication (SNI) در TLS handshake، حریم خصوصی کاربر را افزایش می‌دهد. این رمزگذاری به ناظران شبکه کمک می‌کند تا به راحتی دامنه خاصی را که برنامه شما به آن متصل می‌شود، شناسایی نکنند.
برای برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، از ECH برای اتصالات TLS استفاده می‌شود. ECH فقط در صورتی فعال است که کتابخانه شبکه مورد استفاده برنامه (به عنوان مثال، HttpEngine، WebView یا OkHttp) از ECH پشتیبانی یکپارچه داشته باشد و سرور راه دور نیز از پروتکل ECH پشتیبانی کند. اگر ECH قابل مذاکره نباشد، کلاینت یک افزونه ECH با محتوای تصادفی ارسال می‌کند (مکانیسمی به نام ECH GREASE). برای جزئیات بیشتر در مورد نحوه عملکرد ECH GREASE به RFC 9849 مراجعه کنید.
برای اینکه برنامه‌ها بتوانند این رفتار را سفارشی کنند، اندروید ۱۷ یک عنصر جدید <domainEncryption> به فایل پیکربندی امنیت شبکه اضافه می‌کند. توسعه‌دهندگان می‌توانند از <domainEncryption> در تگ‌های <base-config> یا <domain-config> برای انتخاب حالت ECH (مثلاً "enabled" یا "disabled" ) به صورت سراسری یا برای هر دامنه استفاده کنند.
برای اطلاعات بیشتر، به مستندات Encrypted Client Hello مراجعه کنید.
اجازه شبکه محلی برای برنامه‌های هدف‌یابی Android 17 الزامی است
اندروید ۱۷ مجوز زمان اجرا ACCESS_LOCAL_NETWORK را برای محافظت از کاربران در برابر دسترسی غیرمجاز به شبکه محلی معرفی می‌کند. از آنجا که این مجوز تحت گروه مجوز NEARBY_DEVICES موجود قرار می‌گیرد، کاربرانی که قبلاً مجوزهای NEARBY_DEVICES دیگری را اعطا کرده‌اند، دوباره درخواست نمی‌شوند. این الزام جدید مانع از سوءاستفاده برنامه‌های مخرب از دسترسی نامحدود به شبکه محلی برای ردیابی و انگشت‌نگاری مخفیانه کاربر می‌شود. با اعلام و درخواست این مجوز، برنامه شما می‌تواند دستگاه‌های موجود در شبکه محلی (LAN)، مانند دستگاه‌های خانه هوشمند یا گیرنده‌های Casting را کشف و به آنها متصل شود.
برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، اکنون دو مسیر برای حفظ ارتباط با دستگاه‌های LAN دارند: اتخاذ انتخابگرهای دستگاه با حفظ حریم خصوصی و با واسطه سیستم برای رد کردن درخواست مجوز، یا درخواست صریح این مجوز جدید در زمان اجرا برای حفظ ارتباط شبکه محلی.
برای اطلاعات بیشتر، به مستندات مجوزهای شبکه محلی مراجعه کنید.
پنهان کردن گذرواژه‌ها از دستگاه‌های فیزیکی
اگر برنامه‌ای اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار دهد و کاربر از یک دستگاه ورودی فیزیکی (مثلاً یک صفحه‌کلید خارجی) استفاده کند، سیستم عامل اندروید تنظیم جدید show_passwords_physical را برای همه کاراکترهای فیلد رمز عبور اعمال می‌کند. به طور پیش‌فرض، این تنظیم همه کاراکترهای رمز عبور را پنهان می‌کند.
سیستم اندروید آخرین کاراکتر رمز عبور تایپ شده را نشان می‌دهد تا به کاربر کمک کند تا در صورت اشتباه تایپ کردن رمز عبور، آن را تشخیص دهد. با این حال، این کار با صفحه کلیدهای خارجی بزرگتر بسیار کمتر ضروری است. علاوه بر این، دستگاه‌های دارای صفحه کلیدهای خارجی اغلب نمایشگرهای بزرگتری دارند که خطر دیدن رمز عبور تایپ شده توسط دیگران را افزایش می‌دهد.
اگر کاربر از صفحه لمسی دستگاه استفاده کند، سیستم تنظیم جدید show_passwords_touch را اعمال می‌کند.
محافظت از رمزهای یک‌بارمصرف برای پیامک‌های استاندارد
با شروع اندروید ۱۷، اندروید محافظت از پیام‌های متنی OTP خود را گسترش می‌دهد تا برای پیام‌های متنی استاندارد (پیام‌های متنی حاوی OTP که از فرمت‌های WebOTP یا SMS Retriever استفاده نمی‌کنند) نیز اعمال شود. برای اکثر برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، این پیام‌های متنی تا سه ساعت پس از دریافت در دسترس قرار نمی‌گیرند. این تأخیر برای جلوگیری از ربودن OTP در نظر گرفته شده است. در طول این تأخیر سه ساعته، پخش SMS_RECEIVED_ACTION متوقف می‌شود و پرس‌وجوهای پایگاه داده ارائه دهنده پیامک فیلتر می‌شوند. پیام متنی پس از تأخیر برای این برنامه‌ها در دسترس است.
برخی از برنامه‌ها مانند برنامه دستیار پیامک پیش‌فرض، برنامه‌های همراه دستگاه‌های متصل و غیره، از این تأخیر معاف هستند. همه برنامه‌هایی که برای استخراج OTP به خواندن پیام‌های پیامکی متکی هستند، باید برای اطمینان از عملکرد مداوم، به استفاده از SMS Retriever یا APIهای رضایت کاربر SMS روی آورند.
امنیت
Android 17 بهبودهای زیر را در امنیت دستگاه و برنامه ایجاد می‌کند.
امنیت فعالیت
در اندروید ۱۷، این پلتفرم به سمت معماری «امن به طور پیش‌فرض» تغییر جهت داده و مجموعه‌ای از پیشرفت‌ها را معرفی می‌کند که برای کاهش سوءاستفاده‌های شدید مانند فیشینگ، ربودن تعامل و حملات تصادفی طراحی شده‌اند. این به‌روزرسانی از توسعه‌دهندگان می‌خواهد که به صراحت استانداردهای امنیتی جدید را برای حفظ سازگاری برنامه و حفاظت از کاربر بپذیرند.
تأثیرات کلیدی برای توسعه‌دهندگان شامل موارد زیر است:
- مقاوم‌سازی BAL و بهبود انتخاب: ما با گسترش محافظت‌ها به
IntentSender، محدودیت‌های راه‌اندازی فعالیت پس‌زمینه (BAL) را اصلاح می‌کنیم. توسعه‌دهندگان باید از ثابت قدیمیMODE_BACKGROUND_ACTIVITY_START_ALLOWEDفاصله بگیرند. در عوض، باید کنترل‌های جزئی‌تری مانندMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLEرا اتخاذ کنید که شروع فعالیت را به سناریوهایی محدود می‌کند که برنامه فراخوانی قابل مشاهده است و به طور قابل توجهی سطح حمله را کاهش می‌دهد. - ابزارهای پذیرش: توسعه‌دهندگان باید از حالت strict mode و بررسی‌های به‌روز شده‌ی lint برای شناسایی الگوهای قدیمی و اطمینان از آمادگی برای الزامات SDK هدف در آینده استفاده کنند.
فعال کردن «تبدیل ازطریق» به‌طور پیش‌فرض
اگر برنامه‌ای اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار دهد، شفافیت گواهی (CT) به طور پیش‌فرض فعال می‌شود. (در اندروید ۱۶، CT در دسترس است اما برنامه‌ها باید آن را انتخاب می‌کردند .)
Safer Native DCL—C
اگر برنامه شما اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهد، محافظت Safer Dynamic Code Loading (DCL) که در اندروید ۱۴ برای فایل‌های DEX و JAR معرفی شد، اکنون به کتابخانه‌های بومی نیز گسترش می‌یابد.
تمام فایل‌های بومی که با استفاده از System.load() بارگذاری می‌شوند، باید به صورت فقط خواندنی علامت‌گذاری شوند. در غیر این صورت، سیستم UnsatisfiedLinkError را نمایش می‌دهد.
ما توصیه می‌کنیم که برنامه‌ها تا حد امکان از بارگذاری پویای کد خودداری کنند، زیرا انجام این کار خطر به خطر افتادن برنامه با تزریق کد یا دستکاری کد را به شدت افزایش می‌دهد.
محدود کردن فیلدهای اطلاعات شخصی شناسایی‌پذیر در نمای داده CP2
برای برنامه‌هایی که Android 17 (سطح API 37) و بالاتر را هدف‌یابی می‌کنند، «ارائه‌دهنده مخاطبین ۲» (CP2) ستون‌های خاصی را که حاوی «اطلاعات شناساننده شخصی» (PII) است از نمای داده محدود می‌کند. وقتی این تغییر فعال شود، این ستون‌ها از نمای داده‌ها برداشته می‌شوند تا حریم خصوصی کاربر بهبود یابد. ستون‌های محدودشده شامل موارد زیر است:
برنامه‌هایی که از این ستون‌ها از ContactsContract.Data
استفاده می‌کنند می‌توانند آنها را از ContactsContract.RawContacts
استخراج کنند،
به‌جای آن، با پیوستن به RAW_CONTACT_ID.
اجرای بررسی‌های دقیق SQL در CP2
برای برنامه‌هایی که Android 17 (سطح API ۳۷) و بالاتر را هدف‌یابی می‌کنند، وقتی به جدول ContactsContract.Data بدون اجازه READ_CONTACTS دسترسی پیدا می‌شود، «ارائه‌دهنده مخاطبین ۲» (CP2) اعتبارسنجی دقیق پُرسمان SQL را اعمال می‌کند.
با این تغییر، اگر برنامه‌ای اجازه READ_CONTACTS
نداشته باشد، گزینه‌های StrictColumns و
StrictGrammar هنگام پُرسمان جدول ContactsContract.Data تنظیم می‌شوند. اگر پُرسمانی از الگویی استفاده کند که با این موارد سازگار نباشد، رد خواهد شد و باعث ایجاد استثنا خواهد شد.
هوش
Android 17 شامل تغییرات زیر در هوش سامانه است.
منسوخ شدن setContentCaptureEnabled
قابلیت ضبط محتوا (Content Capture) به طور پیش‌فرض در برخی دستگاه‌ها فعال است تا به ویژگی‌های هوش مصنوعی روی دستگاه اجازه دهد محتوای صفحه نمایش را برای تجربیات هوشمند تجزیه و تحلیل کنند.
از اندروید ۱۷ به بعد، متد API مربوط به ContentCaptureManager.setContentCaptureEnabled(boolean) منسوخ شده است. برای برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) یا بالاتر را هدف قرار می‌دهند، فراخوانی 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 شامل تغییرات زیر در رفتار رسانه است.
سخت‌سازی صدای پس‌زمینه
با شروع اندروید ۱۷، چارچوب صوتی محدودیت‌هایی را در تعاملات صوتی پس‌زمینه از جمله پخش صدا، درخواست‌های فوکوس صدا و APIهای تغییر صدا اعمال می‌کند تا اطمینان حاصل شود که این تغییرات عمداً توسط کاربر آغاز می‌شوند.
برخی محدودیت‌های صوتی برای همه برنامه‌ها اعمال می‌شود. با این حال، اگر برنامه‌ای اندروید ۱۷ (سطح API ۳۷) را هدف قرار دهد، این محدودیت‌ها سختگیرانه‌تر می‌شوند. اگر یکی از این برنامه‌ها در پس‌زمینه با صدا تعامل داشته باشد، باید یک سرویس پیش‌زمینه در حال اجرا داشته باشد. علاوه بر این، برنامه باید یک یا هر دوی این الزامات را برآورده کند:
- سرویس پیش‌زمینه باید قابلیت‌های «هنگام استفاده» (WIU) را داشته باشد.
- برنامه باید مجوز دقیق آلارم را داشته باشد و با جریان‌های صوتی
USAGE_ALARMدر تعامل باشد.
برای اطلاعات بیشتر، از جمله استراتژی‌های کاهش، به مقاوم‌سازی صدای پس‌زمینه مراجعه کنید.
ضریب‌های شکل دستگاه
Android 17 شامل تغییرات زیر برای بهبود تجربه کاربری در طیف وسیعی از اندازه‌های دستگاه و عوامل شکل است.
تغییرات «میانای برنامه‌سازی کاربردی پلاتفرم» برای نادیده گرفتن محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی در صفحه‌نمایش‌های بزرگ (sw>=600dp)
در Android 16، تغییراتی در «میانای برنامه‌سازی کاربردی پلاتفرم» ایجاد کردیم تا محدودیت‌های جهت، قابلیت تغییر اندازه، و نسبت ابعادی در صفحه‌نمایش‌های بزرگ (sw >= 600dp) برای برنامه‌هایی که سطح میانای برنامه‌سازی کاربردی ۳۶ یا بالاتر را هدف‌یابی می‌کنند نادیده گرفته شود. توسعه‌دهندگان با کیت توسعه نرم‌افزار ۳۶ این امکان را دارند که از این تغییرات انصراف دهند، اما این انصراف دیگر برای برنامه‌هایی که Android 17 (سطح میانای برنامه کاربردی ۳۷) یا بالاتر را هدف‌یابی می‌کنند دردسترس نخواهد بود.
برای اطلاعات بیشتر، محدودیت‌های مربوط به جهت و تغییر اندازه نادیده گرفته می‌شوند را ببینید.
اتصال‌پذیری
Android 17 تغییر زیر را برای بهبود سازگاری و
تطابق با عملکرد استاندارد Java InputStream برای سوکت‌های RFCOMM بلوتوث معرفی می‌کند.
عملکرد خواندن BluetoothSocket برای RFCOMM یکپارچه شد
برای برنامه‌هایی که اندروید ۱۷ (سطح API ۳۷) را هدف قرار می‌دهند، متد read() از InputStream که از یک BluetoothSocket مبتنی بر RFCOMM گرفته شده است، اکنون هنگام بسته شدن سوکت یا قطع اتصال، -1 را برمی‌گرداند.
این تغییر، رفتار سوکت RFCOMM را با سوکت‌های LE CoC سازگار می‌کند و با مستندات استاندارد InputStream.read() همسو می‌شود، که بیان می‌کند هنگام رسیدن به انتهای جریان، -1 بازگردانده می‌شود.
برنامه‌هایی که صرفاً برای خروج از حلقه خواندن به دریافت یک IOException متکی هستند، ممکن است تحت تأثیر این تغییر قرار گیرند و باید حلقه‌های خواندن BluetoothSocket را به‌روزرسانی کنند تا به طور صریح مقدار بازگشتی -1 را بررسی کنند. این امر تضمین می‌کند که حلقه هنگام قطع شدن دستگاه از راه دور یا بسته شدن سوکت، به درستی خاتمه می‌یابد. برای نمونه‌ای از پیاده‌سازی توصیه‌شده، به قطعه کد موجود در راهنمای انتقال داده‌های بلوتوث مراجعه کنید.