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

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

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

تجربه کاربری

کشش افکت overscroll

در دستگاه‌های دارای Android 12 و بالاتر، رفتار بصری رویدادهای overscroll تغییر می‌کند.

در Android 11 و پایین‌تر، یک رویداد overscroll باعث می‌شود عناصر بصری درخشش داشته باشند. در اندروید 12 و بالاتر، عناصر بصری در یک رویداد درگ کشیده شده و باز می گردند و در یک رویداد پرتاب به عقب باز می گردند.

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

صفحه نمایش اسپلش برنامه

اگر قبلاً صفحه نمایش سفارشی را در Android 11 یا پایین‌تر پیاده‌سازی کرده‌اید، باید برنامه خود را به SplashScreen API منتقل کنید تا مطمئن شوید که با شروع در Android 12 به درستی نمایش داده می‌شود. انتقال ندادن برنامه شما منجر به تخریب یا ناخواسته برنامه می‌شود. تجربه راه اندازی

برای دستورالعمل‌ها، به انتقال پیاده‌سازی Splash Screen موجود خود به Android 12 مراجعه کنید.

علاوه بر این، با شروع اندروید 12، سیستم همیشه صفحه نمایش اسپلش پیش فرض سیستم اندروید جدید را در شروع سرد و گرم برای همه برنامه ها اعمال می کند. به طور پیش‌فرض، این صفحه نمایش پیش‌فرض سیستم با استفاده از عنصر نماد راه‌انداز برنامه و windowBackground زمینه شما (اگر تک رنگ باشد) ساخته می‌شود.

برای جزئیات بیشتر، به راهنمای برنامه‌نویس splash screens مراجعه کنید.

وضوح هدف وب

با شروع در Android 12 (سطح API 31)، یک هدف وب عمومی تنها در صورتی به یک فعالیت در برنامه شما تبدیل می‌شود که برنامه شما برای دامنه خاص موجود در آن هدف وب تأیید شده باشد. اگر برنامه شما برای دامنه تأیید نشده باشد، هدف وب به برنامه مرورگر پیش‌فرض کاربر حل می‌شود.

برنامه ها می توانند با انجام یکی از موارد زیر این تأیید را دریافت کنند:

• دامنه را با استفاده از پیوندهای برنامه Android تأیید کنید.

  در برنامه‌هایی که Android 12 یا بالاتر را هدف قرار می‌دهند، سیستم نحوه تأیید خودکار پیوندهای برنامه Android برنامه شما را تغییر می‌دهد. در فیلترهای هدف برنامه خود، بررسی کنید که دسته بندی BROWSABLE را شامل شده و از طرح https پشتیبانی می کنید.

  در Android 12 یا بالاتر، می‌توانید به صورت دستی پیوندهای برنامه Android برنامه خود را تأیید کنید تا بررسی کنید که این منطق به‌روزرسانی شده چگونه بر برنامه شما تأثیر می‌گذارد.

• از کاربر بخواهید که برنامه شما را با دامنه در تنظیمات سیستم مرتبط کند .

اگر برنامه شما اهداف وب را فراخوانی می‌کند، یک پیام یا گفتگو اضافه کنید که از کاربر می‌خواهد عمل را تأیید کند.

بهبود حالت همهجانبه برای ناوبری ژست

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

Display#getRealSize و getRealMetrics: منسوخ شدن و محدودیت‌ها

دستگاه های اندرویدی به شکل های مختلفی در دسترس هستند، مانند صفحه نمایش های بزرگ، تبلت ها و تاشوها. برای ارائه مناسب محتوا برای هر دستگاه، برنامه شما باید اندازه صفحه یا نمایشگر را تعیین کند. با گذشت زمان، اندروید API های مختلفی برای بازیابی این اطلاعات ارائه کرده است. در اندروید 11، WindowMetrics API را معرفی کردیم و این روش ها را منسوخ کردیم:

• Display.getSize()
• Display.getMetrics()

در Android 12 ما همچنان استفاده از WindowMetrics را توصیه می کنیم و این روش ها را منسوخ می کنیم:

• Display.getRealSize()
• Display.getRealMetrics()

برای کاهش رفتار برنامه‌هایی که از Display API برای بازیابی محدودیت‌های برنامه استفاده می‌کنند، Android 12 مقادیر بازگردانده شده توسط APIها را برای برنامه‌هایی که به طور کامل قابل تغییر اندازه نیستند، محدود می‌کند. این می تواند بر برنامه هایی که از این اطلاعات با MediaProjection استفاده می کنند تأثیر بگذارد.

برنامه‌ها باید از APIهای WindowMetrics برای پرس‌وجو کردن محدوده‌های پنجره خود و Configuration.densityDpi برای پرس‌وجو چگالی فعلی استفاده کنند.

برای سازگاری بیشتر با نسخه‌های قدیمی‌تر اندروید، می‌توانید از کتابخانه Jetpack WindowManager استفاده کنید که شامل یک کلاس WindowMetrics است که از اندروید 4.0 (سطح API 14) و بالاتر پشتیبانی می‌کند.

نمونه هایی از نحوه استفاده از WindowMetrics

ابتدا مطمئن شوید که فعالیت‌های برنامه شما کاملاً قابل تغییر اندازه هستند.

یک فعالیت باید به WindowMetrics از یک زمینه فعالیت برای هر کار مرتبط با UI، به ویژه WindowManager.getCurrentWindowMetrics() یا WindowMetricsCalculator.computeCurrentWindowMetrics() Jetpack متکی باشد.

اگر برنامه شما MediaProjection ایجاد می‌کند، کران‌ها باید به‌درستی اندازه‌گیری شوند، زیرا پارتیشن نمایشی که برنامه پروژکتور در آن اجرا می‌شود را نمایش می‌دهد.

اگر برنامه به طور کامل قابل تغییر اندازه باشد، زمینه فعالیت محدوده های صحیح را برمی گرداند مانند:

val projectionMetrics: WindowMetrics = activityContext
      .getSystemService(WindowManager::class.java).maximumWindowMetrics

WindowMetrics projectionMetrics = activityContext
      .getSystemService(WindowManager.class).getMaximumWindowMetrics();

اگر برنامه به طور کامل قابل تغییر اندازه نیست، باید از یک نمونه WindowContext پرس و جو کند و WindowMetrics محدوده فعالیت را با استفاده از WindowManager.getMaximumWindowMetrics() یا روش Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics() بازیابی کند.

val windowContext = context.createWindowContext(mContext.display!!,
      WindowManager.LayoutParams.TYPE_APPLICATION, null)
val projectionMetrics = windowContext.getSystemService(WindowManager::class.java)
      .maximumWindowMetrics

Context windowContext = context.createWindowContext(mContext.getDisplay(),
      WindowManager.LayoutParams.TYPE_APPLICATION, null);
WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class)
      .getMaximumWindowMetrics();

همه برنامه ها در حالت چند پنجره ای

اندروید 12 حالت چند پنجره ای را به حالت استاندارد تبدیل می کند.

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

در صفحه‌های کوچک (sw < 600dp)، سیستم minWidth و minHeight یک فعالیت را بررسی می‌کند تا مشخص کند آیا فعالیت می‌تواند در حالت چند پنجره‌ای اجرا شود یا خیر. اگر resizeableActivity="false" ، برنامه در حالت چند پنجره ای بدون در نظر گرفتن حداقل عرض و ارتفاع اجرا نمی شود.

برای اطلاعات بیشتر، به پشتیبانی چند پنجره ای مراجعه کنید.

پیش نمایش دوربین در صفحه نمایش های بزرگ

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

در اندروید 12، برنامه‌های دوربینی که جهت صفحه نمایش خاص را درخواست می‌کنند و قابل تغییر اندازه نیستند ( resizeableActivity="false" ) به طور خودکار وارد حالت عمودی داخلی می‌شوند که جهت گیری و نسبت تصویر پیش‌نمایش دوربین را تضمین می‌کند. در دستگاه‌های تاشو و سایر دستگاه‌هایی که دارای لایه انتزاعی سخت‌افزاری دوربین هستند ( HAL )، چرخش اضافی به خروجی دوربین برای جبران جهت سنسور دوربین اعمال می‌شود و خروجی دوربین برای مطابقت با نسبت تصویر پیش‌نمایش دوربین برنامه برش داده می‌شود. برش و چرخش اضافی، ارائه مناسب پیش‌نمایش دوربین را بدون توجه به جهت دستگاه و حالت تاشده یا بازشده دستگاه تضمین می‌کند.

تاخیر UX برای اعلان‌های سرویس پیش‌زمینه

برای ارائه یک تجربه کارآمد برای سرویس‌های پیش‌زمینه کوتاه مدت، دستگاه‌هایی که دارای Android 12 یا بالاتر هستند، می‌توانند نمایش اعلان‌های سرویس پیش‌زمینه را 10 ثانیه به تأخیر بیندازند، به استثنای چند مورد . این تغییر به وظایف کوتاه مدت فرصتی می دهد تا قبل از ظاهر شدن اعلان های آنها تکمیل شوند.

عملکرد

سطل آماده به کار محدود برنامه

اندروید 11 (سطح API 30) سطل محدود شده را به عنوان یک App Standby Bucket معرفی کرد. با شروع اندروید 12، این سطل به طور پیش فرض فعال است. سطل محدود شده دارای کمترین اولویت (و بیشترین محدودیت) در بین تمام سطل ها است. سطل ها به ترتیب اولویت از زیاد به پایین عبارتند از:

1. فعال: برنامه در حال حاضر در حال استفاده است یا اخیراً استفاده شده است.
2. مجموعه کاری: برنامه در حال استفاده منظم است.
3. مکرر: برنامه اغلب استفاده می شود، اما نه هر روز.
4. نادر: برنامه اغلب استفاده نمی شود.
5. محدود: برنامه مقدار زیادی از منابع سیستم را مصرف می کند یا ممکن است رفتار نامطلوبی از خود نشان دهد.

این سیستم علاوه بر الگوهای استفاده، رفتار برنامه شما را در نظر می گیرد تا تصمیم بگیرد که آیا برنامه شما را در سطل محدود قرار دهد یا خیر.

اگر برنامه شما مسئولانه‌تر از منابع سیستم استفاده کند، احتمال کمتری وجود دارد که برنامه شما در سطل محدود قرار گیرد. همچنین، اگر کاربر مستقیماً با برنامه شما تعامل داشته باشد، سیستم برنامه شما را در یک سطل با محدودیت کمتر قرار می دهد.

بررسی کنید که آیا برنامه شما در سطل محدود شده است یا خیر

برای بررسی اینکه آیا سیستم برنامه شما را در سطل محدود شده قرار داده است، getAppStandbyBucket() را فراخوانی کنید. اگر مقدار برگشتی این روش STANDBY_BUCKET_RESTRICTED باشد، برنامه شما در سطل محدود قرار دارد.

رفتار سطل محدود را تست کنید

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

امنیت و حریم خصوصی

مکان تقریبی

در دستگاه‌هایی که Android 12 یا بالاتر دارند، کاربران می‌توانند درخواست کنند که برنامه شما فقط به اطلاعات موقعیت مکانی تقریبی دسترسی داشته باشد.

اگر برنامه شما مجوز زمان اجرا ACCESS_FINE_LOCATION درخواست می کند، باید مجوز ACCESS_COARSE_LOCATION را نیز برای رسیدگی به مواردی که کاربر به برنامه شما دسترسی تقریبی موقعیت مکانی می دهد درخواست کنید. شما باید هر دو مجوز را در یک درخواست زمان اجرا قرار دهید.

کادر گفتگوی مجوزهای سیستم شامل گزینه های زیر برای کاربر است، همانطور که در شکل 1 نشان داده شده است:

• دقیق : دسترسی به اطلاعات دقیق مکان را فراهم می کند.
• تقریبی : فقط به اطلاعات موقعیت مکانی تقریبی دسترسی می دهد.

کلیدهای میکروفون و دوربین

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

درباره این جابه‌جایی‌ها و نحوه بررسی اینکه برنامه شما از بهترین شیوه‌های مربوط به مجوزهای CAMERA و RECORD_AUDIO پیروی می‌کند بیشتر بیاموزید.

نشانگر میکروفون و دوربین

در دستگاه‌هایی که اندروید ۱۲ یا بالاتر دارند، وقتی برنامه‌ای به میکروفون یا دوربین دسترسی پیدا می‌کند، نمادی در نوار وضعیت ظاهر می‌شود.

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

قابلیت مشاهده بسته مجوز

در دستگاه‌هایی که Android 12 یا بالاتر را اجرا می‌کنند، برنامه‌هایی که Android 11 (سطح API 30) یا بالاتر را هدف قرار می‌دهند و یکی از روش‌های زیر را فراخوانی می‌کنند، مجموعه‌ای از نتایج فیلتر شده را براساس قابلیت مشاهده بسته برنامه در برنامه‌های دیگر دریافت می‌کنند:

• getAllPermissionGroups()
• getPermissionGroupInfo()
• getPermissionInfo()
• queryPermissionsByGroup()

اجرای BouncyCastle حذف شد

اندروید 12 بسیاری از پیاده سازی های BouncyCastle از الگوریتم های رمزنگاری را که قبلاً منسوخ شده بودند، از جمله همه الگوریتم های AES حذف می کند. سیستم در عوض از پیاده سازی Conscrypt این الگوریتم ها استفاده می کند.

اگر هر یک از موارد زیر درست باشد، این تغییر بر برنامه شما تأثیر می گذارد:

• برنامه شما از اندازه های کلید 512 بیتی استفاده می کند. Conscrypt این اندازه کلید را پشتیبانی نمی کند. در صورت لزوم، منطق رمزنگاری برنامه خود را برای استفاده از اندازه های مختلف کلید به روز کنید.

• برنامه شما با KeyGenerator از اندازه های کلید نامعتبر استفاده می کند. اجرای KeyGenerator توسط Conscrypt در مقایسه با BouncyCastle، اعتبار سنجی بیشتری را روی پارامترهای کلیدی انجام می دهد. به عنوان مثال، Conscrypt به برنامه شما اجازه تولید یک کلید AES 64 بیتی را نمی دهد زیرا AES فقط از کلیدهای 128، 192 و 256 بیتی پشتیبانی می کند.

  BouncyCastle اجازه می‌دهد تا کلیدهایی با اندازه‌های نامعتبر تولید شوند، اما اگر این کلیدها با Cipher استفاده شوند، بعداً با شکست مواجه می‌شوند. Conscrypt زودتر شکست می خورد.

• شما رمزهای Galois/Counter Mode (GCM) خود را با استفاده از اندازه ای غیر از 12 بایت مقداردهی اولیه می کنید. اجرای GcmParameterSpec توسط Conscrypt نیاز به مقدار دهی اولیه 12 بایت دارد که NIST توصیه می کند.

اعلان های دسترسی به کلیپ بورد

در اندروید 12 و بالاتر، وقتی برنامه‌ای برای اولین بار getPrimaryClip() را برای دسترسی به داده‌های کلیپ از یک برنامه دیگر فراخوانی می‌کند، یک پیام نان تست کاربر را از دسترسی به این کلیپ‌بورد مطلع می‌کند.

متن داخل پیام نان تست حاوی فرمت زیر است: APP pasted from your clipboard.

اطلاعات در مورد متن در توضیحات کلیپ

در اندروید 12 و بالاتر، getPrimaryClipDescription() می تواند جزئیات زیر را تشخیص دهد:

• متن سبک شده، با استفاده از isStyledText() .
• طبقه بندی های مختلف متن، مانند URL ها، با استفاده از getConfidenceScore() .

برنامه ها نمی توانند گفتگوهای سیستم را ببندند

برای بهبود کنترل کاربر هنگام تعامل با برنامه‌ها و سیستم، اقدام ACTION_CLOSE_SYSTEM_DIALOGS از Android 12 منسوخ شده است. به جز چند مورد خاص ، زمانی که برنامه شما سعی می‌کند هدفی را که حاوی این کنش است فراخوانی کند ، سیستم یکی از موارد زیر را انجام می‌دهد. بر اساس نسخه SDK هدف برنامه شما:

• اگر برنامه شما Android 12 یا بالاتر را هدف قرار دهد، یک SecurityException رخ می دهد.

• اگر برنامه شما Android 11 (سطح API 30) یا پایین‌تر را هدف قرار دهد، هدف اجرا نمی‌شود و پیام زیر در Logcat ظاهر می‌شود:

  E ActivityTaskManager Permission Denial: \
  android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \
  com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \
  dropping broadcast.
  

استثنائات

در موارد زیر، یک برنامه همچنان می‌تواند گفتگوهای سیستم را در Android 12 یا بالاتر ببندد:

• برنامه شما در حال اجرای آزمایش ابزار دقیق است.

• برنامه شما Android 11 یا پایین‌تر را هدف قرار می‌دهد و پنجره‌ای را در بالای کشوی اعلان نشان می‌دهد.

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

• برنامه شما Android 11 یا پایین‌تر را هدف قرار می‌دهد و یک سرویس دسترس‌پذیری فعال دارد. اگر برنامه شما Android 12 را هدف قرار می دهد و می خواهد نوار اعلان را ببندد، به جای آن از عملکرد دسترسی GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE استفاده کنید.

رویدادهای لمسی غیرقابل اعتماد مسدود شده اند

برای حفظ امنیت سیستم و تجربه کاربری خوب، اندروید 12 از مصرف رویدادهای لمسی در برنامه‌ها جلوگیری می‌کند که در آن یک پوشش، برنامه را به روشی ناامن پنهان می‌کند. به عبارت دیگر، سیستم لمس هایی را که از پنجره های خاصی عبور می کنند، با چند استثنا مسدود می کند.

برنامه های تحت تأثیر

این تغییر بر برنامه‌هایی تأثیر می‌گذارد که به عنوان مثال با استفاده از پرچم FLAG_NOT_TOUCHABLE ، اجازه می‌دهند لمس از پنجره‌هایشان عبور کند. چندین مثال شامل موارد زیر است، اما به آنها محدود نمی شود:

• پوشش هایی که به مجوز SYSTEM_ALERT_WINDOW نیاز دارند، مانند ویندوزهایی که از TYPE_APPLICATION_OVERLAY استفاده می کنند و از پرچم FLAG_NOT_TOUCHABLE استفاده می کنند.
• پنجره‌های فعالیتی که از پرچم FLAG_NOT_TOUCHABLE استفاده می‌کنند.

استثنائات

در موارد زیر، لمس "عبور" مجاز است:

• تعاملات درون برنامه شما برنامه شما همپوشانی را نشان می‌دهد و روکش فقط زمانی ظاهر می‌شود که کاربر با برنامه شما تعامل داشته باشد.

• ویندوزهای قابل اعتماد این پنجره ها شامل (اما نه محدود به) موارد زیر است:

  • پنجره های دسترسی
  • پنجره های ویرایشگر روش ورودی (IME).
  • ویندوز دستیار

• پنجره های نامرئی نمای ریشه پنجره GONE یا INVISIBLE است.

• پنجره های کاملا شفاف خاصیت alpha برای پنجره 0.0 است.

• پنجره های هشدار سیستم به اندازه کافی شفاف سیستم مجموعه ای از پنجره های هشدار سیستم را به اندازه کافی شفاف در نظر می گیرد که کدورت ترکیبی کمتر یا برابر با حداکثر کدورت مبهم سیستم برای لمس باشد. در اندروید 12، این حداکثر شفافیت به طور پیش فرض 0.8 است.

تشخیص اینکه یک لمس غیرقابل اعتماد مسدود شده است

اگر یک عملکرد لمسی توسط سیستم مسدود شود، Logcat پیام زیر را ثبت می کند:

Untrusted touch due to occlusion by PACKAGE_NAME

تغییر را آزمایش کنید

لمس‌های غیرقابل اعتماد به‌طور پیش‌فرض در دستگاه‌هایی که اندروید ۱۲ یا بالاتر دارند مسدود می‌شوند. برای اجازه دادن به لمس های غیرقابل اعتماد، دستور ADB زیر را در پنجره ترمینال اجرا کنید:

# A specific app
adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
# If you'd still like to see a Logcat message warning when a touch would be
# blocked, use 1 instead of 0.
adb shell settings put global block_untrusted_touches 0

برای برگرداندن رفتار به حالت پیش فرض (لمس های غیرقابل اعتماد مسدود می شوند)، دستور زیر را اجرا کنید:

# A specific app
adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app

# All apps
adb shell settings put global block_untrusted_touches 2

چرخه حیات فعالیت

فعالیت‌های روت لانچر دیگر با فشار برگشت به پایان نمی‌رسد

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

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

توصیه می کنیم برنامه های خود را با این تغییر آزمایش کنید. اگر برنامه شما در حال حاضر روی onBackPressed() لغو می‌شود تا پیمایش برگشت را مدیریت کند و Activity به پایان برساند، پیاده‌سازی خود را به‌روزرسانی کنید تا به‌جای اتمام، به super.onBackPressed() فراخوانی شود. فراخوانی super.onBackPressed() فعالیت و وظیفه آن را در صورت لزوم به پس‌زمینه منتقل می‌کند و تجربه پیمایش ثابت‌تری را برای کاربران در سراسر برنامه‌ها فراهم می‌کند.

همچنین توجه داشته باشید که به‌طور کلی، توصیه می‌کنیم از APIهای AndroidX Activity برای ارائه پیمایش سفارشی به عقب استفاده کنید، به‌جای اینکه onBackPressed() لغو کنید. APIهای AndroidX Activity به طور خودکار به رفتار مناسب سیستم تعویق می‌یابند اگر هیچ مؤلفه‌ای وجود نداشته باشد که فشار سیستم را قطع کند.

گرافیک و تصاویر

تغییر نرخ تازه سازی بهبود یافته

در اندروید 12، تغییرات نرخ تازه‌سازی با استفاده از setFrameRate() می‌تواند بدون در نظر گرفتن اینکه نمایشگر از انتقال یکپارچه به نرخ تازه‌سازی جدید پشتیبانی می‌کند یا خیر اتفاق بیفتد. انتقال بدون درز، انتقالی است که هیچ گونه وقفه بصری نداشته باشد، مانند صفحه سیاه برای یک یا دو ثانیه. قبلاً، اگر نمایشگر از انتقال یکپارچه پشتیبانی نمی کرد، معمولاً پس از فراخوانی setFrameRate() از همان نرخ تازه سازی استفاده می کرد. با فراخوانی getAlternativeRefreshRates() می‌توانید از قبل تعیین کنید که آیا انتقال به تازه‌سازی جدید احتمالاً بدون مشکل خواهد بود. به طور کلی، callback onDisplayChanged() پس از تکمیل سوئیچ نرخ تازه‌سازی فراخوانی می‌شود، اما برای برخی از نمایشگرهای متصل به خارج، در طول یک انتقال بدون درز فراخوانی می‌شود.

در اینجا مثالی از نحوه اجرای این کار آورده شده است:

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
val refreshRates = this.display?.mode?.alternativeRefreshRates
val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate)

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)

// Determine whether the transition will be seamless.
// Non-seamless transitions may cause a 1-2 second black screen.
Display display = context.getDisplay(); // API 30+
Display.Mode mode = display.getMode();
float[] refreshRates = mode.getAlternativeRefreshRates();
boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate);

// Set the frame rate even if the transition will not be seamless.
surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);

قابلیت اتصال

به روز رسانی Passpoint

API های زیر در اندروید 12 اضافه شده اند:

• isPasspointTermsAndConditionsSupported() : شرایط و ضوابط یک ویژگی Passpoint است که به استقرار شبکه اجازه می‌دهد تا پورتال‌های محصور ناامنی را که از شبکه‌های باز استفاده می‌کنند، با شبکه ایمن Passpoint جایگزین کنند. زمانی که شرایط و ضوابط برای پذیرش الزامی است، یک اعلان به کاربر نمایش داده می شود. برنامه‌هایی که شبکه‌های Passpoint را پیشنهاد می‌کنند که با شرایط و ضوابط بسته شده‌اند، باید ابتدا با این API تماس بگیرند تا مطمئن شوند که دستگاه از این قابلیت پشتیبانی می‌کند. اگر دستگاه از این قابلیت پشتیبانی نمی‌کند، نمی‌تواند به این شبکه متصل شود و باید یک شبکه جایگزین یا قدیمی پیشنهاد شود.

• isDecoratedIdentitySupported() : هنگام احراز هویت در شبکه هایی با تزئین پیشوند، پیشوند هویت تزئین شده به اپراتورهای شبکه اجازه می دهد شناسه دسترسی شبکه (NAI) را برای انجام مسیریابی صریح از طریق چندین پراکسی در داخل یک شبکه AAA به روز کنند (برای اطلاعات بیشتر در این مورد به RFC 7542 مراجعه کنید). .

  Android 12 این ویژگی را برای مطابقت با مشخصات WBA برای برنامه‌های افزودنی PPS-MO پیاده‌سازی می‌کند. برنامه‌هایی که شبکه‌های Passpoint را پیشنهاد می‌کنند که به هویت تزئینی نیاز دارند، ابتدا باید با این API تماس بگیرند تا مطمئن شوند که دستگاه از این قابلیت پشتیبانی می‌کند. اگر دستگاه از این قابلیت پشتیبانی نمی‌کند، هویت تزئین نمی‌شود و ممکن است احراز هویت در شبکه با شکست مواجه شود.

برای ایجاد یک پیشنهاد Passpoint، برنامه‌ها باید از کلاس‌های PasspointConfiguration ، Credential و HomeSp استفاده کنند. این کلاس‌ها نمایه Passpoint را توصیف می‌کنند که در مشخصات Wi-Fi Alliance Passpoint تعریف شده است.

برای اطلاعات بیشتر، به API پیشنهادی Wi-Fi برای اتصال به اینترنت مراجعه کنید.

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

Android 12 شامل لیست های به روز شده از رابط های غیر SDK محدود شده بر اساس همکاری با توسعه دهندگان اندروید و آخرین آزمایش داخلی است. در صورت امکان، قبل از اینکه رابط‌های غیر SDK را محدود کنیم، مطمئن می‌شویم که جایگزین‌های عمومی در دسترس هستند.

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

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

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