تغییرات رفتار: همه برنامه‌ها

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

حتماً فهرست تغییرات رفتاری را که فقط بر برنامه‌هایی که Android 17 را هدف قرار می‌دهند تأثیر می‌گذارد نیز مرور کنید.

عملکرد اصلی

Android 17 (سطح API‏ ۳۷) شامل تغییرات زیر است که قابلیت‌های اصلی مختلف سیستم Android را اصلاح یا گسترش می‌دهد.

حدود حافظه برنامه

Android 17 محدودیت‌های حافظه برنامه را براساس کل RAM دستگاه معرفی می‌کند تا محیطی پایدارتر و قطعی‌تر برای برنامه‌های شما و کاربران Android ایجاد کند. این محدودیت‌ها بر نشت حافظه و سایر موارد پرت تمرکز دارند، پیش‌از اینکه باعث ناپایداری در سراسر سیستم شوند که منجر به لکنت واسط کاربر، تخلیه بیشتر باتری، و ازکار افتادن برنامه‌ها می‌شود. درحالی‌که انتظار داریم تأثیر حداقلی بر اکثریت وسیع جلسه‌های برنامه داشته باشد، روال‌های مطلوب حافظه زیر را توصیه می‌کنیم، ازجمله ایجاد خط مبنا برای حافظه.

با فراخوانی getDescription در ApplicationExitInfo می‌توانید تعیین کنید که آیا جلسه برنامه‌تان تحت تأثیر قرار گرفته است یا نه؛ اگر برنامه‌تان تحت تأثیر قرار گرفته باشد، دلیل خروج REASON_OTHER خواهد بود و شرح حاوی رشته "MemoryLimiter:AnonSwap" به‌همراه اطلاعات دیگر خواهد بود. همچنین می‌توانید از نمایه‌سازی مبتنی بر راه‌انداز با TRIGGER_TYPE_ANOMALY استفاده کنید تا رونوشت‌های پشته‌ای را که هنگام رسیدن به حد حافظه جمع‌آوری شده‌اند دریافت کنید.

سند مدیریت حافظه برنامه اطلاعاتی ارائه می‌دهد که به شما کمک می‌کند مشکلات حافظه برنامه را تشخیص دهید و مصرف منابع آن را بهینه‌سازی کنید.

رفتار برنامه‌تان را تحت محدودیت‌های حافظه آزمایش کنید

می‌توانید از Android Debug Bridge (adb) برای تنظیم یا غیرفعال کردن محدودیت‌های حافظه در هر دستگاهی که آن‌ها را اعمال می‌کند استفاده کنید. فرمان پوسته am سه فرمان فرعی برای تنظیم محدودیت‌های حافظه ارائه می‌دهد. (این فرمان‌ها بر دستگاهی که محدودیت حافظه اعمال نمی‌کند تأثیری ندارد.)

• am memory-limiter ignore <uid>|none|all
• am memory-limiter manual <pid> <limit>|max|none
• am memory-limiter status

ignore

به محدودکننده حافظه دستور می‌دهد برخی یا همه فرایندها را نادیده بگیرد. ارسال UID (شناسه کاربر Android) به محدودکننده حافظه دستور می‌دهد اجرا را در همه فرایندهای مرتبط با آن UID نادیده بگیرد. همچنین می‌توانید all (نادیده گرفتن همه برنامه‌ها) یا none (نادیده نگرفتن هیچ برنامه‌ای) را ارسال کنید. ارسال none هرگونه تماس قبلی با am memory-limiter ignore را لغو می‌کند.

اگر به محدودکننده حافظه دستور دهید که شناسه کاربری را نادیده بگیرد، همچنان می‌توانید با فراخوانی am memory-limiter manual، محدودیت حافظه دستی را برای فرایندی در برنامه اعمال کنید.

manual

به سیستم دستور می‌دهد تا محدودیت حافظه را بر فرایند با شناسه فرایند (PID) مشخص‌شده اعمال کند. محدودیت حافظه به‌صورت عدد صحیح مگابایت مشخص می‌شود؛ برای مثال، ارسال 30 مشخص می‌کند که فرایند به ۳۰ مگابایت حافظه محدود است. با رد شدن از max، همه محدودیت‌های حافظه در آن فرایند برداشته می‌شود. ارسال none هرگونه محدودیت دستی تنظیم‌شده در فرایند را برمی‌دارد و محدودیت پیش‌فرض سیستم (درصورت وجود) را بازیابی می‌کند.

status

وضعیت فعلی محدودکننده حافظه را گزارش می‌کند. این وضعیت شامل محدودیت‌های حافظه اعمال‌شده بر فرایندهای نمایان و غیرنمایان است.

حریم خصوصی

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

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

از Android 17 به بعد، Android محافظت خود را برای پیامک‌های حاوی گذرواژه یک‌بارمصرف (OTP) گسترش می‌دهد.

در نسخه‌های قبلی Android، این محافظت عمدتاً بر قالب «بازیابی پیامک» متمرکز بود. تحویل پیام‌های حاوی درهم‌ساز بازیابی پیامک برای اکثر برنامه‌ها به‌مدت سه ساعت به‌تأخیر افتاد. بااین‌حال، برخی‌از برنامه‌ها (مانند کنترل‌کننده پیش‌فرض پیامک) از این تأخیر معاف بودند و برنامه‌ای که مالک درهم‌ساز بود نیز معاف بود.

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

درطول این تأخیر سه ساعته، همه‌فرستی SMS_RECEIVED_ACTION متوقف می‌شود و پُرسمان‌های پایگاه داده ارائه‌دهنده پیامک فیلتر می‌شود. پیامک پس‌از تأخیر برای این برنامه‌ها دردسترس است. این تغییر برای همه برنامه‌ها، صرف‌نظر از سطح میانای برنامه‌سازی کاربردی هدف آن‌ها، اعمال می‌شود.

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

امنیت

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

طرح منسوخ شدن usesClearTraffic

در نسخه پخش آتی، قصد داریم عنصر usesCleartextTraffic را منسوخ کنیم. برنامه‌هایی که باید اتصال‌های رمزگذاری‌نشده (HTTP) برقرار کنند باید به استفاده از فایل پیکربندی امنیتی شبکه منتقل شوند که به شما امکان می‌دهد مشخص کنید برنامه‌تان باید با کدام دامنه‌ها اتصال‌های متن ساده برقرار کند.

توجه داشته باشید که فایل‌های پیکربندی امنیت شبکه فقط در سطح‌های میانای برنامه‌سازی کاربردی ۲۴ و بالاتر پشتیبانی می‌شوند. اگر برنامه شما حداقل سطح API کمتر از ۲۴ دارد، باید هر دو مورد زیر را انجام دهید:

• مشخصه usesCleartextTraffic را روی true تنظیم کنید
• استفاده از فایل پیکربندی شبکه

اگر حداقل سطح میانای برنامه‌سازی کاربردی برنامه‌تان ۲۴ یا بالاتر است، می‌توانید از فایل پیکربندی شبکه استفاده کنید و نیازی به تنظیم usesCleartextTraffic ندارید.

محدود کردن اعطای URI ضمنی

درحال‌حاضر، اگر برنامه‌ای قصدی را با URI که دارای کنش ACTION_SEND،‏ ACTION_SEND_MULTIPLE، یا ACTION_IMAGE_CAPTURE است راه‌اندازی کند، سیستم به‌طور خودکار اجازه‌های خواندن و نوشتن URI را به برنامه هدف اعطا می‌کند. از Android 18، سیستم دیگر این اجازه‌ها را به‌طور خودکار اعطا نخواهد کرد. به همین دلیل، توصیه می‌کنیم برنامه‌ها به‌طور صریح اجازه‌های URI مربوطه را اعطا کنند به‌جای اینکه برای اعطای آن‌ها به سیستم متکی باشند.

برای شناسایی استفاده از این هدف‌ها در برنامه‌تان، از StrictMode با detectImplicitUriPermissionGrant() برای راه‌اندازی نقض استفاده کنید:

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

یا می‌توانید استثناهای ثبت‌شده حاوی پیام Please set the grant explicitly in the app را که هنگام تنظیم ضمنی اعطای دسترسی توسط سیستم ظاهر می‌شود پایش کنید. می‌توانید این گزارش‌ها را بااستفاده از فرمان adb زیر پایش کنید:

adb logcat | grep "Please set the grant explicitly in the app"

برای اعطای صریح اجازه‌های لازم، پرچم FLAG_GRANT_READ_URI_PERMISSION را به هدف‌های ACTION_SEND و ACTION_SEND_MULTIPLE اضافه کنید:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

هر دو پرچم FLAG_GRANT_READ_URI_PERMISSION و FLAG_GRANT_WRITE_URI_PERMISSION را برای هدف‌های ACTION_IMAGE_CAPTURE اضافه کنید:

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

حدود keystore برای هر برنامه

برنامه‌ها باید از ایجاد تعداد بیش‌ازحد کلید در Android Keystore اجتناب کنند، زیرا این منبعی مشترک برای همه برنامه‌های موجود در دستگاه است. از Android 17، سیستم محدودیتی را برای تعداد کلیدهایی که یک برنامه می‌تواند داشته باشد اعمال می‌کند. این حد برای برنامه‌های غیرسیستمی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند ۵۰٬۰۰۰ کلید است و برای همه برنامه‌های دیگر ۲۰۰٬۰۰۰ کلید است. برنامه‌های سیستم، صرف‌نظر از اینکه کدام سطح میانای برنامه‌سازی کاربردی را هدف قرار می‌دهند، محدودیت ۲۰۰٬۰۰۰ کلید دارند.

اگر برنامه‌ای تلاش کند کلیدهایی فراتر از حد مجاز ایجاد کند، ایجاد کلید با KeyStoreException ناموفق خواهد بود. رشته پیام استثنا حاوی اطلاعاتی درباره حد کلید است. اگر برنامه getNumericErrorCode() را در استثنا فراخوانی کند، مقدار برگشتی به سطح میانای برنامه‌سازی کاربردی هدف برنامه بستگی دارد:

• برنامه‌هایی که Android 17 (سطح میانای برنامه‌سازی کاربردی ۳۷) یا بالاتر را هدف قرار می‌دهند: getNumericErrorCode() مقدار جدید ERROR_TOO_MANY_KEYS را برمی‌گرداند.
• همه برنامه‌های دیگر: getNumericErrorCode()، ERROR_INCORRECT_USAGE را برمی‌گرداند.

مسدود کردن ترافیک مسیریابی بازگشتی بین‌نمایه‌ای

از Android 17 به بعد، ترافیک برگشتی بین‌نمایه‌ای دیگر به‌طور پیش‌فرض مجاز نیست. ترافیک برگشتی در همان نمایه تحت تأثیر قرار نمی‌گیرد. این تغییر برای همه برنامه‌هایی که در Android 17 یا بالاتر اجرا می‌شوند اعمال می‌شود، صرف‌نظر از اینکه برنامه کدام سطح میانای برنامه‌سازی کاربردی را هدف قرار می‌دهد.

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

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

درحال بازیابی رؤیت‌پذیری پیش‌فرض IME پس‌از چرخش

از Android 17، وقتی پیکربندی دستگاه تغییر می‌کند (برای مثال، ازطریق چرخش) و این تغییر توسط خود برنامه مدیریت نمی‌شود، نمایان بودن IME قبلی بازیابی نمی‌شود.

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

• مشخصه android:windowSoftInputMode را روی stateAlwaysVisible تنظیم کنید.
• صفحه‌کلید نرم‌افزاری را به‌صورت برنامه‌نویسی‌شده در روش onCreate() فعالیتتان درخواست کنید، یا روش onConfigurationChanged() را اضافه کنید.

ورودی انسانی

Android 17 شامل تغییرات زیر است که بر نحوه تعامل برنامه‌ها با دستگاه‌های ورودی انسانی مانند صفحه‌کلید و صفحه لمسی تأثیر می‌گذارد.

صفحه‌های لمسی به‌طور پیش‌فرض رویدادهای نسبی را درطول ضبط اشاره‌گر ارائه می‌دهند

از Android 17 به بعد، اگر برنامه‌ای بااستفاده از View.requestPointerCapture() درخواست ضبط اشاره‌گر کند و کاربر از صفحه لمسی استفاده کند، سیستم حرکت اشاره‌گر و اشاره‌های پیمایش را از لمس‌های کاربر تشخیص می‌دهد و آن‌ها را به همان روشی که حرکات اشاره‌گر و چرخ پیمایش از موشواره ضبط‌شده گزارش می‌شوند، به برنامه گزارش می‌دهد. در بیشتر موارد، این کار نیاز به برنامه‌هایی را که از موشواره‌های ضبط‌شده پشتیبانی می‌کنند برای افزودن منطق مدیریت ویژه برای صفحه‌های لمسی برطرف می‌کند. برای جزئیات بیشتر، به مستندات View.POINTER_CAPTURE_MODE_RELATIVE مراجعه کنید.

قبلاً سیستم تلاشی برای تشخیص اشاره‌ها از صفحه لمسی نمی‌کرد و درعوض مکان‌های مطلق و خام انگشت را در قالبی مشابه با لمس‌های نمایشگر لمسی به برنامه ارائه می‌کرد. اگر برنامه‌ای همچنان به این داده‌های مطلق نیاز دارد، باید روش جدید View.requestPointerCapture(int) را با View.POINTER_CAPTURE_MODE_ABSOLUTE فراخوانی کند.

رسانه

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

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

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

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

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

اتصال‌پذیری

Android 17 شامل تغییرات زیر برای بهبود اتصال‌پذیری دستگاه است.

جفت‌سازی مجدد خودکار برای قطع شدن اتصال بلوتوث

‫Android 17 جفت‌سازی مجدد خودکار را معرفی می‌کند، که یک بهبود در سطح سیستم است و برای حل خودکار مشکل قطع شدن اتصال بلوتوث طراحی شده است.

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

درحالی‌که اکثر برنامه‌ها به تغییر کد نیاز ندارند، توسعه‌دهندگان باید از تغییرات رفتاری زیر در پشته بلوتوث مطلع باشند:

• بافت جفت‌سازی جدید: ACTION_PAIRING_REQUEST اکنون شامل EXTRA_PAIRING_CONTEXT اضافی است که به برنامه‌ها امکان می‌دهد بین درخواست جفت‌سازی استاندارد و تلاش برای جفت‌سازی مجدد که به‌طور خودکار توسط سیستم آغاز شده است تمایز قائل شوند.
• به‌روزرسانی‌های کلید شرطی: کلیدهای امنیتی موجود فقط درصورتی جایگزین خواهند شد که جفت‌سازی مجدد موفقیت‌آمیز باشد و اتصال جدید با سطح امنیتی پیوند قبلی مطابقت داشته باشد یا از آن فراتر رود.
• زمان‌بندی هدف اصلاح‌شده: هدف ACTION_KEY_MISSING اکنون فقط درصورتی همه‌فرستی می‌شود که تلاش برای جفت‌سازی مجدد خودکار ناموفق باشد. این کار باعث کاهش رسیدگی به خطاهای غیرضروری در برنامه می‌شود، اگر سیستم با موفقیت پیوند را در پس‌زمینه بازیابی کند.
• اعلان کاربر: سیستم جفت‌سازی مجدد را ازطریق اعلان‌های واسط کاربر جدید و کادرهای گفتگو مدیریت می‌کند. از کاربران خواسته می‌شود تلاش برای جفت‌سازی مجدد را تأیید کنند تا اطمینان حاصل شود از اتصال مجدد مطلع هستند.

سازندگان دستگاه‌های جانبی و توسعه‌دهندگان برنامه‌های همراه باید درستی‌سنجی کنند که سخت‌افزار و برنامه به‌درستی انتقال‌های پیوند را مدیریت می‌کنند. برای آزمایش این رفتار، بااستفاده از یکی از روش‌های زیر، ازدست رفتن پیوند ازراه‌دور را شبیه‌سازی کنید:

• اطلاعات پیوند را به‌طور دستی از دستگاه جانبی بردارید
• جفت‌سازی دستگاه را به‌صورت دستی در این مسیر لغو کنید: تنظیمات > دستگاه‌های متصل