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

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

پلتفرم 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، موقعیت مکانی پیش‌زمینه (از جمله از سرویس پیش‌زمینه) می‌تواند در زمانی که بهینه‌سازی باتری فعال است، حتی زمانی که صفحه نمایش خاموش است، تحویل داده شود.

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

برنامه هایی که از طریق سرویس پیش زمینه درخواست مکان می کنند باید مراحل زیر را انجام دهند:

1. با getLocationPowerSaverMode() تماس بگیرید تا نحوه عملکرد ویژگی‌های موقعیت مکانی دستگاه را هنگام فعال بودن Battery Saver بررسی کنید.
2. اگر LOCATION_MODE_FOREGROUND_ONLY را برگرداند، برنامه شما همچنان به دریافت به‌روزرسانی‌های مکان در پیش‌زمینه یا اجرای یک سرویس پیش‌زمینه در حالی که بهینه‌سازی باتری روشن است و صفحه‌نمایش خاموش است، ادامه می‌دهد.

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

مکان تقریبی

در دستگاه‌هایی که 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 مراجعه کنید.

پلتفرم 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، موقعیت مکانی پیش‌زمینه (از جمله از سرویس پیش‌زمینه) می‌تواند در زمانی که بهینه‌سازی باتری فعال است، حتی زمانی که صفحه نمایش خاموش است، تحویل داده شود.

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

برنامه هایی که از طریق یک سرویس پیش زمینه محل را درخواست می کنند باید مراحل زیر را انجام دهند:

1. برای بررسی نحوه عملکرد مکان دستگاه هنگام فعال بودن باتری ، با getLocationPowerSaverMode() تماس بگیرید.
2. اگر این مکان را بازگرداند_ LOCATION_MODE_FOREGROUND_ONLY ، برنامه شما به روزرسانی های مکان را در حالی که در پیش زمینه یا اجرای یک سرویس پیش زمینه در حالی که Saver Saver روشن است و صفحه خاموش است ، دریافت می کند.

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

مکان تقریبی

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

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

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

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

میکروفون و دوربین

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

در مورد این ضامن ها بیشتر بدانید ، و چگونه بررسی کنید که برنامه شما بهترین شیوه های مربوط به CAMERA و مجوزهای RECORD_AUDIO را دنبال می کند.

شاخص های میکروفون و دوربین

در دستگاه هایی که Android 12 یا بالاتر را اجرا می کنند ، هنگامی که یک برنامه به میکروفون یا دوربین دسترسی پیدا می کند ، یک نماد در نوار وضعیت ظاهر می شود.

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

دیدگاه بسته اجازه

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

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

اجرای Bouncycastle حذف شد

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

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

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

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

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

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

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

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

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

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

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

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

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

برای بهبود کنترل کاربر در هنگام تعامل با برنامه ها و سیستم ، اقدامات قصد ACTION_CLOSE_SYSTEM_DIALOGS از نظر Android 12 کاهش می یابد.

• اگر برنامه شما 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 یا پایین را هدف قرار می دهد و پنجره ای را نشان می دهد که در بالای کشو اعلان قرار دارد.

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

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

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

برای حفظ امنیت سیستم و یک تجربه کاربری خوب ، Android 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

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

لمس های غیرقابل اعتماد به طور پیش فرض در دستگاه هایی که Android 12 یا بالاتر را اجرا می کنند مسدود می شوند. برای اجازه لمس های غیرقابل اعتماد ، دستور 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 عملکرد پیش فرض سیستم را در فعالیت های پرتاب که در ریشه وظایف آنها قرار دارد ، تغییر می دهد. در نسخه های قبلی ، این سیستم این فعالیت ها را در مطبوعات پشتی به پایان می رساند. در Android 12 ، سیستم اکنون به جای اتمام فعالیت ، فعالیت و کار خود را به پس زمینه منتقل می کند. رفتار جدید هنگام حرکت از یک برنامه با استفاده از دکمه خانه یا ژست ، با رفتار فعلی مطابقت دارد.

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

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

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

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

سوئیچینگ نرخ تازه سازی بهبود یافته

در Android 12 ، تغییر نرخ تجدید با استفاده از setFrameRate() بدون در نظر گرفتن اینکه آیا صفحه نمایش از انتقال یکپارچه به نرخ تازه سازی جدید پشتیبانی می کند ، می تواند اتفاق بیفتد. یک انتقال یکپارچه یکی از مواردی است که هیچگونه وقفه بصری ندارد ، مانند صفحه سیاه برای یک یا دو ثانیه. پیش از این ، اگر صفحه نمایش از انتقال یکپارچه پشتیبانی نمی کرد ، به طور معمول با استفاده از همان نرخ تازه سازی پس از فراخوانی setFrameRate() ادامه می یابد. شما می توانید از قبل تعیین کنید که آیا انتقال به تازه کردن جدید با فراخوانی getAlternativeRefreshRates() احتمالاً یکپارچه خواهد بود. به طور کلی ، پس از اتمام سوئیچ نرخ تازه سازی ، 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 های زیر در Android 12 اضافه می شوند:

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

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

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

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

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

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

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

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

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

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

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

حتماً لیست تغییرات رفتاری را که فقط برنامه های هدفمند اندروید 12 را تحت تأثیر قرار می دهد ، مرور کنید.

تجربه کاربری

اثر بیش از حد کشش

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

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

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

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

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

برای دستورالعمل ، به اجرای صفحه نمایش Splash Screen خود به Android 12 مراجعه کنید .

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

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

وضوح هدف وب

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

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

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

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

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

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

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

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

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

نمایش#getRealSize و getRealMetrics: استهلاک و محدودیت ها

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

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

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

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

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

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

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

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

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

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

اگر برنامه شما یک MediaProjection ایجاد کند ، مرزها باید به درستی اندازه بگیرند زیرا طرح ریزی پارتیشن صفحه نمایش را که برنامه پروژکتور در آن اجرا می شود ، ضبط می کند.

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

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

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

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

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();

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

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

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

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

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

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

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

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

تأخیر UX برای اعلان های خدمات پیش زمینه

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

عملکرد

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

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

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

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

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

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

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

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

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

adb shell am set-standby-bucket PACKAGE_NAME restricted

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

با شروع با Android 12 ، مکان پیش زمینه (از جمله از یک سرویس پیش زمینه) می تواند در حالی که محافظ باتری فعال است ، حتی در حالی که صفحه خاموش است ، تحویل داده شود.

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

برنامه هایی که از طریق یک سرویس پیش زمینه محل را درخواست می کنند باید مراحل زیر را انجام دهند:

1. برای بررسی نحوه عملکرد مکان دستگاه هنگام فعال بودن باتری ، با getLocationPowerSaverMode() تماس بگیرید.
2. اگر این مکان را بازگرداند_ LOCATION_MODE_FOREGROUND_ONLY ، برنامه شما به روزرسانی های مکان را در حالی که در پیش زمینه یا اجرای یک سرویس پیش زمینه در حالی که Saver Saver روشن است و صفحه خاموش است ، دریافت می کند.

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

مکان تقریبی

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

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

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

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

میکروفون و دوربین

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

در مورد این ضامن ها بیشتر بدانید ، و چگونه بررسی کنید که برنامه شما بهترین شیوه های مربوط به CAMERA و مجوزهای RECORD_AUDIO را دنبال می کند.

شاخص های میکروفون و دوربین

در دستگاه هایی که Android 12 یا بالاتر را اجرا می کنند ، هنگامی که یک برنامه به میکروفون یا دوربین دسترسی پیدا می کند ، یک نماد در نوار وضعیت ظاهر می شود.

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

دیدگاه بسته اجازه

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

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

اجرای Bouncycastle حذف شد

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

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

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

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

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

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

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

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

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

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

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

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

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

برای بهبود کنترل کاربر در هنگام تعامل با برنامه ها و سیستم ، اقدامات قصد ACTION_CLOSE_SYSTEM_DIALOGS از نظر Android 12 کاهش می یابد.

• اگر برنامه شما 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 یا پایین را هدف قرار می دهد و پنجره ای را نشان می دهد که در بالای کشو اعلان قرار دارد.

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

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

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

برای حفظ امنیت سیستم و یک تجربه کاربری خوب ، Android 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

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

لمس های غیرقابل اعتماد به طور پیش فرض در دستگاه هایی که Android 12 یا بالاتر را اجرا می کنند مسدود می شوند. برای اجازه لمس های غیرقابل اعتماد ، دستور 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 changes the default handling of the system Back press on launcher activities that are at the root of their tasks. In previous versions, the system would finish these activities on Back press. In Android 12, the system now moves the activity and its task to the background instead of finishing the activity. The new behavior matches the current behavior when navigating out of an app using the Home button or gesture.

For most apps, this change means that users who use Back to navigate out of your app are able to more quickly resume your app from a warm state , instead of having to completely restart the app from a cold state .

We recommend testing your apps with this change. If your app currently overrides onBackPressed() to handle Back navigation and finish the Activity , update your implementation to call through to super.onBackPressed() instead of finishing. Calling super.onBackPressed() moves the activity and its task to the background when appropriate and provides a more consistent navigation experience for users across apps.

Also note that, in general, we recommend using the AndroidX Activity APIs for providing custom back navigation , rather than overriding onBackPressed() . The AndroidX Activity APIs automatically defer to the appropriate system behavior if there are no components intercepting the system Back press.

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

Improved refresh rate switching

In Android 12, refresh rate changes using setFrameRate() can happen regardless of whether the display supports a seamless transition to the new refresh rate; a seamless transition is one that doesn't have any visual interruptions, such as a black screen for a second or two. Previously, if the display did not support a seamless transition, it would typically continue using the same refresh rate after setFrameRate() is called. You can determine in advance whether the transition to the new refresh will likely be seamless by calling getAlternativeRefreshRates() . Generally, the callback onDisplayChanged() is called after the refresh rate switch completes, but for some externally-connected displays, it is called during a non-seamless transition.

Here's an example of how you might implement this:

// 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 updates

The following APIs are added in Android 12:

• isPasspointTermsAndConditionsSupported() : Terms and conditions is a Passpoint feature that allows network deployments to replace insecure captive portals, which use open networks, with a secure Passpoint network. A notification is displayed to the user when terms and conditions are required to be accepted. Apps that suggest Passpoint networks that are gated by terms and conditions must call this API first to make sure that the device supports the capability. If the device does not support the capability, it won't be able to connect to this network, and an alternative or legacy network must be suggested.

• isDecoratedIdentitySupported() : When authenticating to networks with a prefix decoration, the decorated identity prefix allows network operators to update the Network Access Identifier (NAI) to perform explicit routing through multiple proxies inside of an AAA network (see RFC 7542 for more on this).

  Android 12 implements this feature to conform with the WBA specification for PPS-MO extensions . Apps that suggest Passpoint networks that require a decorated identity must call this API first to make sure that the device supports the capability. If the device does not support the capability, the identity won't be decorated and the authentication to the network might fail.

To create a Passpoint suggestion, apps must use the PasspointConfiguration , Credential , and HomeSp classes. These classes describe the Passpoint profile, which is defined in the Wi-Fi Alliance Passpoint specification .

For more information, see Wi-Fi suggestion API for internet connectivity .

Updated non-SDK interface restrictions

Android 12 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 12, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces ( depending on your app's target API level ), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API .

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 12 . To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces .

The Android 12 platform includes behavior changes that may affect your app. The following behavior changes apply to all apps when they run on Android 12, regardless of targetSdkVersion . You should test your app and then modify it as needed to support these properly, where applicable.

Make sure to also review the list of behavior changes that only affect apps targeting Android 12 .

تجربه کاربری

Stretch overscroll effect

On devices running Android 12 and higher, the visual behavior for overscroll events changes.

On Android 11 and lower, an overscroll event causes the visual elements to have a glow; on Android 12 and higher, the visual elements stretch and bounce back on a drag event and they fling and bounce back on a fling event.

For more information, see the guide to animating scroll gestures .

App splash screens

If you have previously implemented a custom splash screen in Android 11 or lower, you'll need to migrate your app to the SplashScreen API to ensure that it displays correctly starting in Android 12. Not migrating your app will result in a degraded or unintended app launch experience.

For instructions, see Migrate your existing splash screen implementation to Android 12 .

Additionally, starting in Android 12, the system always applies the new Android system default splash screen on cold and warm starts for all apps. By default, this system default splash screen is constructed using your app's launcher icon element and the windowBackground of your theme (if it's a single color).

For more details, see the splash screens developer guide .

Web intent resolution

Starting in Android 12 (API level 31), a generic web intent resolves to an activity in your app only if your app is approved for the specific domain contained in that web intent. If your app isn't approved for the domain, the web intent resolves to the user's default browser app instead.

Apps can get this approval by doing one of the following:

• Verify the domain using Android App Links .

  On apps that target Android 12 or higher, the system changes how it automatically verifies your app's Android App Links. In your app's intent filters , check that you include the BROWSABLE category and support the https scheme.

  On Android 12 or higher, you can manually verify your app's Android App Links, to test how this updated logic affects your app.

• Request the user to associate your app with the domain in system settings.

If your app invokes web intents, consider adding a prompt or dialog that asks the user to confirm the action.

Immersive mode improvements for gesture navigation

Android 12 consolidates existing behavior to make it easier for users to perform gesture navigation commands while in immersive mode . In addition, Android 12 provides backward compatibility behavior for sticky immersive mode .

Display#getRealSize and getRealMetrics: deprecation and constraints

Android devices are available in many different form factors, such as large screens, tablets, and foldables. To render content appropriately for each device, your app needs to determine the screen or display size. Over time, Android has provided different APIs for retrieving this information. In Android 11, we introduced the WindowMetrics API and deprecated these methods:

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

In Android 12 we're continuing to recommend using WindowMetrics , and are deprecating these methods:

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

To mitigate the behavior of applications using Display APIs to retrieve the application's bounds, Android 12 constrains the values returned by the APIs for apps that are not fully resizable. This could have an impact on apps that are using this information with MediaProjection .

Apps should use the WindowMetrics APIs to query the bounds of their window, and Configuration.densityDpi to query the current density.

For broader compatibility with older versions of Android, you can use the Jetpack WindowManager library, which includes a WindowMetrics class that supports Android 4.0 (API level 14) and higher.

Examples of how to use WindowMetrics

First, be sure your app's activities are fully resizable .

An activity should rely upon WindowMetrics from an activity context for any UI-related work, particularly WindowManager.getCurrentWindowMetrics() or Jetpack's WindowMetricsCalculator.computeCurrentWindowMetrics() .

If your app creates a MediaProjection , the bounds must be correctly sized since the projection captures the display partition in which the projector app is running.

If the app is fully resizable, the activity context returns the correct bounds like so:

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

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

If the app is not fully resizable, it must query from a WindowContext instance and retrieve the WindowMetrics of the activity bounds using WindowManager.getMaximumWindowMetrics() or the Jetpack method 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();

All apps in multi-window mode

Android 12 makes multi-window mode standard behavior.

On large screens (sw >= 600dp), the platform supports all apps in multi-window mode regardless of app configuration. If resizeableActivity="false" , the app is put into compatibility mode when necessary to accommodate display dimensions.

On small screens (sw < 600dp), the system checks an activity's minWidth and minHeight to determine whether the activity can run in multi-window mode. If resizeableActivity="false" , the app is prevented from running in multi‑window mode regardless of minimum width and height.

For more information, see Multi-window support .

Camera preview on large screens

Camera apps generally assume a fixed relationship between the orientation of the device and the aspect ratio of the camera preview. But large screen form factors, such as foldable devices, and display modes such as multi-window and multi-display, challenge that assumption.

On Android 12, camera apps that request a specific screen orientation and are not resizable ( resizeableActivity="false" ) automatically enter inset portrait mode, which ensures the proper orientation and aspect ratio of the camera preview. On foldables and other devices that have a camera hardware abstraction layer ( HAL ), additional rotation is applied to the camera output to compensate for camera sensor orientation, and the camera output is cropped to match the aspect ratio of the app's camera preview. The cropping and extra rotation ensure proper presentation of the camera preview regardless of device orientation and folded or unfolded state of the device.

UX delay for foreground service notifications

To provide a streamlined experience for short-running foreground services , devices that run Android 12 or higher can delay the display of foreground service notifications by 10 seconds, with a few exceptions . This change gives short-lived tasks a chance to complete before their notifications appear.

عملکرد

Restricted App Standby Bucket

Android 11 (API level 30) introduced the restricted bucket as an App Standby Bucket. Starting in Android 12, this bucket is active by default. The restricted bucket has the lowest priority (and the highest restrictions) of all the buckets. The buckets in order of priority from high to low are:

1. Active: App is currently being used or was very recently used.
2. Working set: App is in regular use.
3. Frequent: App is often used, but not every day.
4. Rare: App is not frequently used.
5. Restricted: App consumes a great deal of system resources, or may exhibit undesirable behavior.

The system considers your app's behavior, in addition to usage patterns, to decide whether to place your app in the restricted bucket.

Your app is less likely to be placed in the restricted bucket if your app uses system resources more responsibly. Also, the system places your app in a less restrictive bucket if the user interacts directly with your app.

Check whether your app is in the restricted bucket

To check whether the system has placed your app in the restricted bucket, call getAppStandbyBucket() . If the return value of this method is STANDBY_BUCKET_RESTRICTED , then your app is in the restricted bucket.

Test the restricted bucket behavior

To test how your app behaves when the system places your app into the restricted bucket, you can manually move your app to that bucket. To do so, run the following command in a terminal window:

adb shell am set-standby-bucket PACKAGE_NAME restricted

Foreground location and Battery Saver

Starting with Android 12, foreground location (including from a foreground service) can continue to be delivered while Battery Saver is active, even while the screen is off.

Previously, Battery Saver mode stopped location updates when the screen was off. This change enables better battery life for users, and means that developers can refrain from asking users to disable Battery Saver in order to ensure location deliveries.

Apps that request location through a foreground service should take the following steps:

1. Call getLocationPowerSaverMode() to check how the device's location features behave when Battery Saver is active.
2. If this returns LOCATION_MODE_FOREGROUND_ONLY , your app will continue to receive location updates while in the foreground or running a foreground service while Battery Saver is on and the screen is off.

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

Approximate location

On devices that run Android 12 or higher, users can request that your app have access to only approximate location information.

If your app requests the ACCESS_FINE_LOCATION runtime permission, you should also request the ACCESS_COARSE_LOCATION permission to handle the case where the user grants approximate location access to your app. You should include both permissions in a single runtime request .

The system permissions dialog includes the following options for the user, as shown in figure 1:

• Precise : Provides access to precise location information.
• Approximate : Provides access only to approximate location information.

Microphone and camera toggles

Supported devices that run Android 12 or higher allow users to enable and disable camera and microphone access for all apps on the device, by pressing a single toggle option. Users can access the toggleable options from Quick Settings , as shown in figure 1, or from the Privacy screen in system settings.

Learn more about these toggles , and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

Microphone and camera indicators

On devices that run Android 12 or higher, when an app accesses the microphone or camera, an icon appears in the status bar.

Learn more about these indicators and how to check that your app follows best practices regarding the CAMERA and RECORD_AUDIO permissions.

Permission package visibility

On devices that run Android 12 or higher, apps that target Android 11 (API level 30) or higher and that call one of following methods receive a filtered set of results, based on the app's package visibility into other apps:

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

BouncyCastle implementation removed

Android 12 removes many BouncyCastle implementations of cryptographic algorithms that were previously deprecated, including all AES algorithms. The system instead uses the Conscrypt implementations of these algorithms.

This change affects your app if any of the following are true:

• Your app uses 512-bit key sizes. Conscrypt doesn't support this key size. If necessary, update your app's cryptography logic to use different key sizes.

• Your app uses invalid key sizes with KeyGenerator . Conscrypt's implementation of KeyGenerator performs additional validation on key parameters, compared to BouncyCastle. For example, Conscrypt doesn't allow your app to generate a 64-bit AES key because AES only supports 128-, 192-, and 256-bit keys.

  BouncyCastle allows keys of invalid sizes to be generated, but later fails if these keys are used with a Cipher . Conscrypt fails earlier.

• You initialize your Galois/Counter Mode (GCM) ciphers using a size other than 12 bytes. Conscrypt's implementation of GcmParameterSpec requires an initialization of 12 bytes, which NIST recommends.

Clipboard access notifications

On Android 12 and higher, when an app calls getPrimaryClip() to access clip data from a different app for the first time, a toast message notifies the user of this clipboard access.

The text inside the toast message contains the following format: APP pasted from your clipboard.

Information about text in clip description

On Android 12 and higher, getPrimaryClipDescription() can detect the following details:

• Stylized text, using isStyledText() .
• Different classifications of text, such as URLs, using getConfidenceScore() .

Apps can't close system dialogs

To improve user control when interacting with apps and the system, the ACTION_CLOSE_SYSTEM_DIALOGS intent action is deprecated as of Android 12. Except for a few special cases , when your app tries to invoke an intent that contains this action, the system does one of the following based on your app's target SDK version:

• If your app targets Android 12 or higher, a SecurityException occurs.

• If your app targets Android 11 (API level 30) or lower, the intent doesn't execute, and the following message appears in 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.
  

استثنائات

In the following cases, an app can still close system dialogs on Android 12 or higher:

• Your app is running an instrumentation test .

• Your app targets Android 11 or lower and is showing a window that is on top of the notification drawer .

• Your app targets Android 11 or lower. In addition, the user has interacted with a notification, possibly using the notification's action buttons , and your app is processing a service or broadcast receiver in response to that user action.

• Your app targets Android 11 or lower and has an active accessibility service . If your app targets Android 12 and wants to close the notification bar, use the GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE accessibility action instead.

Untrusted touch events are blocked

To preserve system security and a good user experience, Android 12 prevents apps from consuming touch events where an overlay obscures the app in an unsafe way. In other words, the system blocks touches that pass through certain windows, with a few exceptions .

Affected apps

This change affects apps that choose to let touches pass through their windows, for example by using the FLAG_NOT_TOUCHABLE flag. Several examples include, but aren't limited to, the following:

• Overlays that require the SYSTEM_ALERT_WINDOW permission, such as windows that use TYPE_APPLICATION_OVERLAY , and use the FLAG_NOT_TOUCHABLE flag.
• Activity windows that use the FLAG_NOT_TOUCHABLE flag.

استثنائات

In the following cases, "pass-through" touches are allowed:

• Interactions within your app. Your app shows the overlay, and the overlay appears only when the user is interacting with your app.

• Trusted windows. These windows include (but aren't limited to) the following:

  • Accessibility windows
  • Input method editor (IME) windows
  • Assistant windows

• Invisible windows. The window's root view is GONE or INVISIBLE .

• Completely transparent windows. The alpha property is 0.0 for the window.

• Sufficiently translucent system alert windows. The system considers a set of system alert windows to be sufficiently translucent when the combined opacity is less than or equal to the system's maximum obscuring opacity for touches. In Android 12, this maximum opacity is 0.8 by default.

Detect when an untrusted touch is blocked

If a touch action is blocked by the system, Logcat logs the following message:

Untrusted touch due to occlusion by PACKAGE_NAME

Test the change

Untrusted touches are blocked by default on devices that run Android 12 or higher. To allow untrusted touches, run the following ADB command in a terminal window:

# 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

To revert the behavior to the default (untrusted touches are blocked), run the following command:

# 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

Activity lifecycle

Root launcher activities are no longer finished on Back press

Android 12 changes the default handling of the system Back press on launcher activities that are at the root of their tasks. In previous versions, the system would finish these activities on Back press. In Android 12, the system now moves the activity and its task to the background instead of finishing the activity. The new behavior matches the current behavior when navigating out of an app using the Home button or gesture.

For most apps, this change means that users who use Back to navigate out of your app are able to more quickly resume your app from a warm state , instead of having to completely restart the app from a cold state .

We recommend testing your apps with this change. If your app currently overrides onBackPressed() to handle Back navigation and finish the Activity , update your implementation to call through to super.onBackPressed() instead of finishing. Calling super.onBackPressed() moves the activity and its task to the background when appropriate and provides a more consistent navigation experience for users across apps.

Also note that, in general, we recommend using the AndroidX Activity APIs for providing custom back navigation , rather than overriding onBackPressed() . The AndroidX Activity APIs automatically defer to the appropriate system behavior if there are no components intercepting the system Back press.

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

Improved refresh rate switching

In Android 12, refresh rate changes using setFrameRate() can happen regardless of whether the display supports a seamless transition to the new refresh rate; a seamless transition is one that doesn't have any visual interruptions, such as a black screen for a second or two. Previously, if the display did not support a seamless transition, it would typically continue using the same refresh rate after setFrameRate() is called. You can determine in advance whether the transition to the new refresh will likely be seamless by calling getAlternativeRefreshRates() . Generally, the callback onDisplayChanged() is called after the refresh rate switch completes, but for some externally-connected displays, it is called during a non-seamless transition.

Here's an example of how you might implement this:

// 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 updates

The following APIs are added in Android 12:

• isPasspointTermsAndConditionsSupported() : Terms and conditions is a Passpoint feature that allows network deployments to replace insecure captive portals, which use open networks, with a secure Passpoint network. A notification is displayed to the user when terms and conditions are required to be accepted. Apps that suggest Passpoint networks that are gated by terms and conditions must call this API first to make sure that the device supports the capability. If the device does not support the capability, it won't be able to connect to this network, and an alternative or legacy network must be suggested.

• isDecoratedIdentitySupported() : When authenticating to networks with a prefix decoration, the decorated identity prefix allows network operators to update the Network Access Identifier (NAI) to perform explicit routing through multiple proxies inside of an AAA network (see RFC 7542 for more on this).

  Android 12 implements this feature to conform with the WBA specification for PPS-MO extensions . Apps that suggest Passpoint networks that require a decorated identity must call this API first to make sure that the device supports the capability. If the device does not support the capability, the identity won't be decorated and the authentication to the network might fail.

To create a Passpoint suggestion, apps must use the PasspointConfiguration , Credential , and HomeSp classes. These classes describe the Passpoint profile, which is defined in the Wi-Fi Alliance Passpoint specification .

For more information, see Wi-Fi suggestion API for internet connectivity .

Updated non-SDK interface restrictions

Android 12 includes updated lists of restricted non-SDK interfaces based on collaboration with Android developers and the latest internal testing. Whenever possible, we make sure that public alternatives are available before we restrict non-SDK interfaces.

If your app does not target Android 12, some of these changes might not immediately affect you. However, while you can currently use some non-SDK interfaces ( depending on your app's target API level ), using any non-SDK method or field always carries a high risk of breaking your app.

If you are unsure if your app uses non-SDK interfaces, you can test your app to find out. If your app relies on non-SDK interfaces, you should begin planning a migration to SDK alternatives. Nevertheless, we understand that some apps have valid use cases for using non-SDK interfaces. If you cannot find an alternative to using a non-SDK interface for a feature in your app, you should request a new public API .

To learn more about the changes in this release of Android, see Updates to non-SDK interface restrictions in Android 12 . To learn more about non-SDK interfaces generally, see Restrictions on non-SDK interfaces .