تغییرات رفتار: برنامه هایی که API 29+ را هدف قرار می دهند

Android 10 شامل تغییرات رفتار سیستم به روز شده ای است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات فهرست شده در این صفحه منحصراً برای برنامه هایی اعمال می شود که API 29 یا بالاتر را هدف قرار می دهند. اگر برنامه شما targetSdkVersion روی "29" یا بالاتر تنظیم می کند، باید برنامه خود را تغییر دهید تا در صورت لزوم از این رفتارها به درستی پشتیبانی کند.

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

توجه: علاوه بر تغییرات ذکر شده در این صفحه، اندروید 10 تعداد زیادی تغییرات و محدودیت‌های مبتنی بر حریم خصوصی را معرفی می‌کند، از جمله موارد زیر:

• فضای ذخیره سازی محدوده
• دسترسی به شماره سریال دستگاه USB
• امکان فعال کردن، غیرفعال کردن و پیکربندی Wi-Fi
• مجوزهای مکان برای APIهای اتصال

این تغییرات که بر برنامه هایی که سطح API 29 یا بالاتر را هدف قرار می دهند تأثیر می گذارد، حریم خصوصی کاربر را افزایش می دهد. برای کسب اطلاعات بیشتر در مورد نحوه پشتیبانی از این تغییرات، به صفحه تغییرات حریم خصوصی مراجعه کنید.

به روز رسانی محدودیت های رابط غیر SDK

برای کمک به اطمینان از ثبات و سازگاری برنامه، پلتفرم شروع به محدود کردن رابط‌های غیر SDK کرد که برنامه شما می‌تواند در Android 9 استفاده کند (سطح API 28). Android 10 شامل لیست های به روز شده از رابط های غیر SDK محدود شده بر اساس همکاری با توسعه دهندگان اندروید و آخرین آزمایش داخلی است. هدف ما این است که قبل از اینکه رابط‌های غیر SDK را محدود کنیم، مطمئن شویم که جایگزین‌های عمومی در دسترس هستند.

اگر اندروید 10 (سطح API 29) را هدف قرار نمی دهید، ممکن است برخی از این تغییرات فوراً روی شما تأثیر نگذارند. با این حال، در حالی که در حال حاضر می‌توانید از برخی رابط‌های غیر SDK ( بسته به سطح API هدف برنامه‌تان ) استفاده کنید، استفاده از هر روش یا فیلد غیر SDK همیشه خطر شکستن برنامه شما را بالا می‌برد.

اگر مطمئن نیستید که برنامه شما از رابط های غیر SDK استفاده می کند، می توانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابط‌های غیر SDK متکی است، باید برنامه‌ریزی برای انتقال به جایگزین‌های SDK را شروع کنید. با این وجود، می‌دانیم که برخی از برنامه‌ها دارای موارد استفاده معتبر برای استفاده از رابط‌های غیر SDK هستند. اگر نمی توانید جایگزینی برای استفاده از یک رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .

برای کسب اطلاعات بیشتر، به به‌روزرسانی‌های محدودیت‌های رابط غیر SDK در Android 10 و محدودیت‌های رابط‌های غیر SDK را ببینید.

حافظه مشترک

Ashmem فرمت نقشه های دالویک را در /proc/<pid>/maps تغییر داده است و بر برنامه هایی که مستقیماً فایل نقشه ها را تجزیه می کنند تأثیر می گذارد. توسعه دهندگان برنامه باید فرمت /proc/<pid>/maps را روی دستگاه‌هایی که اندروید 10 یا بالاتر را اجرا می‌کنند، آزمایش کنند و اگر برنامه به قالب‌های نقشه dalvik وابسته است، آن را تجزیه و تحلیل کنند.

برنامه‌هایی که Android 10 را هدف قرار می‌دهند نمی‌توانند مستقیماً از ashmem (/dev/ashmem) استفاده کنند و در عوض باید از طریق کلاس ASharedMemory NDK به حافظه مشترک دسترسی داشته باشند. علاوه بر این، برنامه‌ها نمی‌توانند IOCTLهای مستقیم را به توصیف‌کننده‌های فایل ashmem موجود بسازند و در عوض باید از کلاس ASharedMemory NDK یا APIهای Android Java برای ایجاد مناطق حافظه مشترک استفاده کنند. این تغییر هنگام کار با حافظه مشترک، امنیت و استحکام را افزایش می دهد و عملکرد و امنیت اندروید را به طور کلی بهبود می بخشد.

مجوز اجرا برای فهرست اصلی برنامه حذف شد

اجرای فایل‌ها از فهرست اصلی برنامه قابل نوشتن، نقض W^X است. برنامه ها باید فقط کد باینری را که در فایل APK برنامه جاسازی شده است بارگیری کنند.

برنامه‌های غیرقابل اعتمادی که اندروید 10 را هدف قرار می‌دهند، نمی‌توانند execve() مستقیماً روی فایل‌های داخل فهرست اصلی برنامه فراخوانی کنند.

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

زمان اجرا اندروید فقط فایل های OAT تولید شده توسط سیستم را می پذیرد

زمان اجرا اندروید (ART) دیگر dex2oat از فرآیند برنامه فراخوانی نمی کند. این تغییر به این معنی است که ART فقط فایل‌های OAT را می‌پذیرد که سیستم تولید کرده است.

اعمال درستی AOT در ART

در گذشته، کامپایل پیش از زمان (AOT) که توسط Android Runtime (ART) انجام می‌شد، در صورتی که محیط classpath در زمان کامپایل و زمان اجرا یکسان نبود، باعث خرابی زمان اجرا می‌شد. اندروید 10 و بالاتر همیشه نیاز دارد که این زمینه‌های محیطی یکسان باشند، که منجر به تغییرات زیر در رفتار می‌شود:

• بارکننده های کلاس سفارشی - یعنی بارکننده های کلاس نوشته شده توسط برنامه ها، بر خلاف کلاس لودرهای بسته dalvik.system - AOT کامپایل نمی شوند. این به این دلیل است که ART نمی تواند در مورد پیاده سازی جستجوی کلاس سفارشی در زمان اجرا بداند.
• فایل‌های dex ثانویه - یعنی فایل‌های dex که به‌طور دستی توسط برنامه‌هایی که در APK اولیه نیستند بارگیری می‌شوند - در پس‌زمینه با AOT کامپایل می‌شوند. این به این دلیل است که کامپایل برای اولین بار ممکن است بسیار گران باشد و منجر به تأخیر ناخواسته قبل از اجرا شود. توجه داشته باشید که برای برنامه‌ها، استفاده از تقسیم‌بندی و دور شدن از فایل‌های dex ثانویه توصیه می‌شود.
• کتابخانه‌های اشتراک‌گذاری شده در Android (مدخل‌های <library> و <uses-library> در مانیفست اندروید) با استفاده از سلسله‌مراتب بارگیری کلاس متفاوت از آنچه در نسخه‌های قبلی پلتفرم استفاده می‌شد، پیاده‌سازی می‌شوند.

مجوزها برای اهداف تمام صفحه تغییر می کند

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

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

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

پشتیبانی از تاشوها

اندروید 10 تغییراتی دارد که از دستگاه های تاشو و صفحه نمایش بزرگ پشتیبانی می کند.

هنگامی که یک برنامه در اندروید 10 اجرا می شود، روش های onResume() و onPause() متفاوت عمل می کنند. هنگامی که چندین برنامه به طور همزمان در حالت چند پنجره ای یا چند صفحه نمایش ظاهر می شوند، تمام فعالیت های قابل تمرکز بالا در پشته های قابل مشاهده در حالت ازسرگیری قرار دارند، اما تنها یکی از آنها، "بالاترین فعالیت از سر گرفته شده"، در واقع فوکوس دارد. هنگامی که در نسخه‌های زودتر از اندروید 10 اجرا می‌شود، تنها یک فعالیت در سیستم می‌تواند در یک زمان از سر گرفته شود، همه فعالیت‌های قابل مشاهده دیگر متوقف می‌شوند.

«تمرکز» را با «بالاترین فعالیت از سر گرفته شده» اشتباه نگیرید. این سیستم اولویت‌هایی را به فعالیت‌ها بر اساس ترتیب z اختصاص می‌دهد تا اولویت بیشتری را به فعالیت‌هایی که کاربر در گذشته با آن‌ها تعامل داشته است، بدهد. یک فعالیت می تواند از سر گرفته شود، اما فوکوس نداشته باشد (به عنوان مثال، اگر سایه اعلان بزرگ شود).

در Android 10 (سطح API 29) و نسخه‌های جدیدتر، می‌توانید در onTopResumedActivityChanged() مشترک شوید تا در صورت کسب یا از دست دادن فعالیت شما بالاترین موقعیت از سر گرفته‌شده را دریافت کنید. این معادل حالت از سرگیری قبل از Android 10 است و اگر برنامه شما از منابع انحصاری یا تکی استفاده می کند که ممکن است نیاز به اشتراک گذاری با سایر برنامه ها داشته باشد، می تواند به عنوان یک اشاره مفید باشد.

رفتار ویژگی resizeableActivity manifest نیز تغییر کرده است. اگر برنامه ای resizeableActivity=false در Android 10 (سطح API 29) یا جدیدتر تنظیم کند، ممکن است زمانی که اندازه صفحه موجود تغییر می کند یا اگر برنامه از یک صفحه به صفحه دیگر منتقل شود، در حالت سازگاری قرار گیرد.

برنامه‌ها می‌توانند از ویژگی android:minAspectRatio که در Android 10 معرفی شده است، برای نشان دادن نسبت‌های صفحه‌نمایش مورد پشتیبانی برنامه شما استفاده کنند.

با شروع نسخه 3.5، ابزار شبیه ساز اندروید استودیو شامل دستگاه های مجازی 7.3 و 8 اینچی برای آزمایش کد شما با صفحه نمایش بزرگتر است.

برای اطلاعات بیشتر، به طراحی برنامه‌های خود برای تاشوها مراجعه کنید.