مانند نسخه های قبلی، Android 14 شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامههایی اعمال میشود که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند. اگر برنامه شما اندروید 14 یا بالاتر را هدف قرار می دهد، باید برنامه خود را تغییر دهید تا در صورت لزوم از این رفتارها به درستی پشتیبانی کند.
حتماً فهرستی از تغییرات رفتاری را نیز مرور کنید که بر همه برنامههای در حال اجرا در Android 14 بدون توجه به targetSdkVersion
برنامه تأثیر میگذارد.
عملکرد اصلی
انواع خدمات پیش زمینه مورد نیاز است
اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار می دهد، باید حداقل یک نوع سرویس پیش زمینه را برای هر سرویس پیش زمینه در برنامه شما مشخص کند. شما باید یک نوع سرویس پیش زمینه را انتخاب کنید که نشان دهنده مورد استفاده برنامه شما باشد. این سیستم انتظار دارد که خدمات پیش زمینه ای که نوع خاصی دارند، مورد استفاده خاص را برآورده کنند.
اگر مورد استفاده در برنامه شما با هیچ یک از این انواع مرتبط نیست، اکیداً توصیه میشود که منطق خود را برای استفاده از WorkManager یا کارهای انتقال داده توسط کاربر تغییر دهید.
اجرای مجوز BLUETOOTH_CONNECT در آداپتور بلوتوث
Android 14 مجوز BLUETOOTH_CONNECT
را هنگام فراخوانی روش BluetoothAdapter
getProfileConnectionState()
برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، اعمال میکند.
این روش قبلاً به مجوز BLUETOOTH_CONNECT
نیاز داشت، اما اجرا نشد. مطمئن شوید که برنامه شما BLUETOOTH_CONNECT
را در فایل AndroidManifest.xml
برنامه شما همانطور که در قطعه زیر نشان داده شده است، اعلام کرده و بررسی کنید که یک کاربر قبل از تماس با getProfileConnectionState
مجوز را داده است .
<uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />
به روز رسانی OpenJDK 17
Android 14 به کار تازه کردن کتابخانههای اصلی Android ادامه میدهد تا با ویژگیهای جدیدترین نسخه OpenJDK LTS، از جمله بهروزرسانیهای کتابخانه و پشتیبانی از زبان جاوا 17 برای توسعهدهندگان برنامهها و پلتفرمها، هماهنگ شود.
تعدادی از این تغییرات می تواند بر سازگاری برنامه تأثیر بگذارد:
- تغییرات در عبارات منظم : ارجاعات گروه نامعتبر اکنون مجاز نیستند تا معنایی OpenJDK را با دقت بیشتری دنبال کنند. ممکن است موارد جدیدی را مشاهده کنید که در آن یک
IllegalArgumentException
توسط کلاسjava.util.regex.Matcher
پرتاب می شود، بنابراین مطمئن شوید که برنامه خود را برای مناطقی که از عبارات منظم استفاده می کنند آزمایش کنید. برای فعال یا غیرفعال کردن این تغییر در حین آزمایش، پرچمDISALLOW_INVALID_GROUP_REFERENCE
را با استفاده از ابزارهای چارچوب سازگاری تغییر دهید. - مدیریت UUID : متد
java.util.UUID.fromString()
اکنون بررسی های دقیق تری را هنگام تأیید آرگومان ورودی انجام می دهد، بنابراین ممکن است در حین deserialization یکIllegalArgumentException
را مشاهده کنید. برای فعال یا غیرفعال کردن این تغییر در حین آزمایش، پرچمENABLE_STRICT_VALIDATION
را با استفاده از ابزارهای چارچوب سازگاری تغییر دهید. - مشکلات ProGuard : در برخی موارد، افزودن کلاس
java.lang.ClassValue
باعث ایجاد مشکل می شود اگر بخواهید برنامه خود را با استفاده از ProGuard کوچک کنید، مبهم کنید و بهینه کنید. مشکل از یک کتابخانه Kotlin سرچشمه می گیرد که رفتار زمان اجرا را بر اساس اینکهClass.forName("java.lang.ClassValue")
یک کلاس را برمی گرداند یا نه، تغییر می دهد. اگر برنامه شما بر اساس نسخه قدیمیتری از زمان اجرا بدون کلاسjava.lang.ClassValue
در دسترس است، این بهینهسازیها ممکن است متدcomputeValue
را از کلاسهای مشتقشده ازjava.lang.ClassValue
حذف کنند.
JobScheduler رفتار برگشت به تماس و شبکه را تقویت می کند
از زمان معرفی، JobScheduler انتظار دارد برنامه شما در عرض چند ثانیه از onStartJob
یا onStopJob
بازگردد. قبل از اندروید 14، اگر یک کار بیش از حد طولانی شود، کار متوقف شده و بیصدا از کار میافتد. اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار دهد و از زمان اعطا شده در رشته اصلی فراتر رود، برنامه یک ANR با پیام خطای «بدون پاسخ به onStartJob
» یا «بدون پاسخ به onStopJob
» راهاندازی میکند.
این ANR ممکن است نتیجه 2 سناریو باشد: 1. کاری وجود دارد که رشته اصلی را مسدود می کند، مانع از اجرا و تکمیل تماس های onStartJob
یا onStopJob
در محدوده زمانی مورد انتظار می شود. 2. برنامهنویس در حال اجرای کار مسدودسازی در پاسخ به تماس JobScheduler onStartJob
یا onStopJob
است و از تکمیل تماس در محدوده زمانی مورد انتظار جلوگیری میکند.
برای آدرس شماره 1، باید مواردی را که در زمان وقوع ANR، رشته اصلی را مسدود میکند، بیشتر اشکال زدایی کنید، میتوانید این کار را با استفاده از ApplicationExitInfo#getTraceInputStream()
انجام دهید تا ردیابی سنگ قبر را هنگام وقوع ANR دریافت کنید. اگر میتوانید ANR را به صورت دستی بازتولید کنید، میتوانید یک ردیابی سیستم را ضبط کنید و با استفاده از Android Studio یا Perfetto ردیابی را بررسی کنید تا بهتر بفهمید که چه چیزی در رشته اصلی در هنگام وقوع ANR اجرا میشود. توجه داشته باشید که این اتفاق میتواند هنگام استفاده مستقیم از JobScheduler API یا استفاده از کتابخانه Androidx WorkManager رخ دهد.
برای پرداختن به شماره 2، مهاجرت به WorkManager را در نظر بگیرید، که از بسته بندی هر پردازش در onStartJob
یا onStopJob
در یک رشته ناهمزمان پشتیبانی می کند.
JobScheduler
همچنین الزامی را برای اعلام مجوز ACCESS_NETWORK_STATE
در صورت استفاده از محدودیت setRequiredNetworkType
یا setRequiredNetwork
معرفی می کند. اگر برنامه شما مجوز ACCESS_NETWORK_STATE
را هنگام زمانبندی کار اعلام نکند و اندروید 14 یا بالاتر را هدف قرار دهد، منجر به یک SecurityException
میشود.
از زمان معرفی، JobScheduler انتظار دارد برنامه شما در عرض چند ثانیه از onStartJob
یا onStopJob
بازگردد. قبل از اندروید 14، اگر یک کار بیش از حد طولانی شود، کار متوقف شده و بیصدا از کار میافتد. اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار دهد و از زمان اعطا شده در رشته اصلی فراتر رود، برنامه یک ANR با پیام خطای «بدون پاسخ به onStartJob
» یا «بدون پاسخ به onStopJob
» راهاندازی میکند.
این ANR ممکن است نتیجه 2 سناریو باشد: 1. کاری وجود دارد که رشته اصلی را مسدود می کند، مانع از اجرا و تکمیل تماس های onStartJob
یا onStopJob
در محدوده زمانی مورد انتظار می شود. 2. برنامهنویس در حال اجرای کار مسدودسازی در پاسخ به تماس JobScheduler onStartJob
یا onStopJob
است و از تکمیل تماس در محدوده زمانی مورد انتظار جلوگیری میکند.
برای آدرس شماره 1، باید مواردی را که در زمان وقوع ANR، رشته اصلی را مسدود میکند، بیشتر اشکال زدایی کنید، میتوانید این کار را با استفاده از ApplicationExitInfo#getTraceInputStream()
انجام دهید تا ردیابی سنگ قبر را هنگام وقوع ANR دریافت کنید. اگر میتوانید ANR را به صورت دستی بازتولید کنید، میتوانید یک ردیابی سیستم را ضبط کنید و با استفاده از Android Studio یا Perfetto ردیابی را بررسی کنید تا بهتر بفهمید که چه چیزی در رشته اصلی در هنگام وقوع ANR اجرا میشود. توجه داشته باشید که این اتفاق میتواند هنگام استفاده مستقیم از JobScheduler API یا استفاده از کتابخانه Androidx WorkManager رخ دهد.
برای پرداختن به شماره 2، مهاجرت به WorkManager را در نظر بگیرید، که از بسته بندی هر پردازش در onStartJob
یا onStopJob
در یک رشته ناهمزمان پشتیبانی می کند.
JobScheduler
همچنین الزامی را برای اعلام مجوز ACCESS_NETWORK_STATE
در صورت استفاده از محدودیت setRequiredNetworkType
یا setRequiredNetwork
معرفی می کند. اگر برنامه شما مجوز ACCESS_NETWORK_STATE
را هنگام زمانبندی کار اعلام نکند و اندروید 14 یا بالاتر را هدف قرار دهد، منجر به یک SecurityException
میشود.
از زمان معرفی، JobScheduler انتظار دارد برنامه شما در عرض چند ثانیه از onStartJob
یا onStopJob
بازگردد. قبل از اندروید 14، اگر یک کار بیش از حد طولانی شود، کار متوقف شده و بیصدا از کار میافتد. اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار دهد و از زمان اعطا شده در رشته اصلی فراتر رود، برنامه یک ANR با پیام خطای «بدون پاسخ به onStartJob
» یا «بدون پاسخ به onStopJob
» راهاندازی میکند.
این ANR ممکن است نتیجه 2 سناریو باشد: 1. کاری وجود دارد که رشته اصلی را مسدود می کند، مانع از اجرا و تکمیل تماس های onStartJob
یا onStopJob
در محدوده زمانی مورد انتظار می شود. 2. برنامهنویس در حال اجرای کار مسدودسازی در پاسخ به تماس JobScheduler onStartJob
یا onStopJob
است و از تکمیل تماس در محدوده زمانی مورد انتظار جلوگیری میکند.
برای آدرس شماره 1، باید مواردی را که در زمان وقوع ANR، رشته اصلی را مسدود میکند، بیشتر اشکال زدایی کنید، میتوانید این کار را با استفاده از ApplicationExitInfo#getTraceInputStream()
انجام دهید تا ردیابی سنگ قبر را هنگام وقوع ANR دریافت کنید. اگر میتوانید ANR را به صورت دستی بازتولید کنید، میتوانید یک ردیابی سیستم را ضبط کنید و با استفاده از Android Studio یا Perfetto ردیابی را بررسی کنید تا بهتر بفهمید که چه چیزی در رشته اصلی در هنگام وقوع ANR اجرا میشود. توجه داشته باشید که این اتفاق میتواند هنگام استفاده مستقیم از JobScheduler API یا استفاده از کتابخانه Androidx WorkManager رخ دهد.
برای پرداختن به شماره 2، مهاجرت به WorkManager را در نظر بگیرید، که از بسته بندی هر پردازش در onStartJob
یا onStopJob
در یک رشته ناهمزمان پشتیبانی می کند.
JobScheduler
همچنین الزامی را برای اعلام مجوز ACCESS_NETWORK_STATE
در صورت استفاده از محدودیت setRequiredNetworkType
یا setRequiredNetwork
معرفی می کند. اگر برنامه شما مجوز ACCESS_NETWORK_STATE
را هنگام زمانبندی کار اعلام نکند و اندروید 14 یا بالاتر را هدف قرار دهد، منجر به یک SecurityException
میشود.
از زمان معرفی، JobScheduler انتظار دارد برنامه شما در عرض چند ثانیه از onStartJob
یا onStopJob
بازگردد. قبل از اندروید 14، اگر یک کار بیش از حد طولانی شود، کار متوقف شده و بیصدا از کار میافتد. اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار دهد و از زمان اعطا شده در رشته اصلی فراتر رود، برنامه یک ANR با پیام خطای «بدون پاسخ به onStartJob
» یا «بدون پاسخ به onStopJob
» راهاندازی میکند.
این ANR ممکن است نتیجه 2 سناریو باشد: 1. کاری وجود دارد که رشته اصلی را مسدود می کند، مانع از اجرا و تکمیل تماس های onStartJob
یا onStopJob
در محدوده زمانی مورد انتظار می شود. 2. برنامهنویس در حال اجرای کار مسدودسازی در پاسخ به تماس JobScheduler onStartJob
یا onStopJob
است و از تکمیل تماس در محدوده زمانی مورد انتظار جلوگیری میکند.
برای آدرس شماره 1، باید مواردی را که در زمان وقوع ANR، رشته اصلی را مسدود میکند، بیشتر اشکال زدایی کنید، میتوانید این کار را با استفاده از ApplicationExitInfo#getTraceInputStream()
انجام دهید تا ردیابی سنگ قبر را هنگام وقوع ANR دریافت کنید. اگر میتوانید ANR را به صورت دستی بازتولید کنید، میتوانید یک ردیابی سیستم را ضبط کنید و با استفاده از Android Studio یا Perfetto ردیابی را بررسی کنید تا بهتر بفهمید که چه چیزی در رشته اصلی در هنگام وقوع ANR اجرا میشود. توجه داشته باشید که این اتفاق میتواند هنگام استفاده مستقیم از JobScheduler API یا استفاده از کتابخانه Androidx WorkManager رخ دهد.
برای پرداختن به شماره 2، مهاجرت به WorkManager را در نظر بگیرید، که از بسته بندی هر پردازش در onStartJob
یا onStopJob
در یک رشته ناهمزمان پشتیبانی می کند.
JobScheduler
همچنین الزامی را برای اعلام مجوز ACCESS_NETWORK_STATE
در صورت استفاده از محدودیت setRequiredNetworkType
یا setRequiredNetwork
معرفی می کند. اگر برنامه شما مجوز ACCESS_NETWORK_STATE
را هنگام زمانبندی کار اعلام نکند و اندروید 14 یا بالاتر را هدف قرار دهد، منجر به یک SecurityException
میشود.
کاشیها API را راهاندازی میکنند
For apps targeting 14 and higher,
TileService#startActivityAndCollapse(Intent)
is deprecated and now throws
an exception when called. If your app launches activities from tiles, use
TileService#startActivityAndCollapse(PendingIntent)
instead.
حریم خصوصی
دسترسی جزئی به عکس ها و فیلم ها
Android 14 دسترسی به عکسهای انتخاب شده را معرفی میکند، که به کاربران اجازه میدهد به برنامهها اجازه دسترسی به تصاویر و ویدیوهای خاص موجود در کتابخانه خود را بدهند، نه اینکه به همه رسانههای یک نوع خاص دسترسی داشته باشند.
این تغییر تنها در صورتی فعال میشود که برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار دهد. اگر هنوز از انتخابگر عکس استفاده نکردهاید، توصیه میکنیم آن را در برنامه خود پیادهسازی کنید تا تجربهای ثابت برای انتخاب تصاویر و ویدیوها ارائه دهید که همچنین حریم خصوصی کاربر را بدون نیاز به درخواست مجوز ذخیرهسازی افزایش میدهد.
اگر انتخابگر گالری خود را با استفاده از مجوزهای ذخیره سازی حفظ می کنید و نیاز دارید که کنترل کامل بر پیاده سازی خود داشته باشید، پیاده سازی خود را با استفاده از مجوز جدید READ_MEDIA_VISUAL_USER_SELECTED
تطبیق دهید. اگر برنامه شما از مجوز جدید استفاده نمی کند، سیستم برنامه شما را در حالت سازگاری اجرا می کند.
تجربه کاربری
اعلانهای Intent تمام صفحه را ایمن کنید
With Android 11 (API level 30), it was possible for any app to use
Notification.Builder.setFullScreenIntent
to send full-screen
intents while the phone is locked. You could auto-grant this on app install by
declaring USE_FULL_SCREEN_INTENT
permission in the
AndroidManifest.
Full-screen intent notifications are designed for extremely high-priority
notifications demanding the user's immediate attention, such as an incoming
phone call or alarm clock settings configured by the user. For apps targeting
Android 14 (API level 34) or higher, apps that are allowed to use this
permission are limited to those that provide calling and alarms only. The Google
Play Store revokes default USE_FULL_SCREEN_INTENT
permissions for any apps
that don't fit this profile. The deadline for these policy changes is May 31,
2024.
This permission remains enabled for apps installed on the phone before the user updates to Android 14. Users can turn this permission on and off.
You can use the new API
NotificationManager.canUseFullScreenIntent
to check if your app
has the permission; if not, your app can use the new intent
ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT
to launch the settings
page where users can grant the permission.
امنیت
محدودیت برای مقاصد ضمنی و معلق
برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، Android برنامهها را از ارسال مقاصد ضمنی به اجزای داخلی برنامه به روشهای زیر محدود میکند:
- مقاصد ضمنی فقط به اجزای صادر شده تحویل داده می شوند. برنامهها یا باید از یک قصد صریح برای تحویل به اجزای صادر نشده استفاده کنند یا مؤلفه را بهعنوان صادرشده علامتگذاری کنند.
- اگر یک برنامه یک هدف معلق قابل تغییر ایجاد کند که یک جزء یا بسته را مشخص نمی کند، سیستم یک استثنا ایجاد می کند.
این تغییرات مانع از رهگیری برنامه های مخرب در مقاصد ضمنی می شود که برای استفاده توسط اجزای داخلی برنامه در نظر گرفته شده است.
به عنوان مثال، در اینجا یک فیلتر قصد وجود دارد که می تواند در فایل مانیفست برنامه شما اعلام شود:
<activity
android:name=".AppActivity"
android:exported="false">
<intent-filter>
<action android:name="com.example.action.APP_ACTION" />
<category android:name="android.intent.category.DEFAULT" />
</intent-filter>
</activity>
اگر برنامه شما سعی کند این فعالیت را با استفاده از یک هدف ضمنی راه اندازی کند، یک استثنا ActivityNotFoundException
ایجاد می شود:
کاتلین
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
جاوا
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
برای راه اندازی فعالیت غیرصادراتی، برنامه شما باید به جای آن از یک هدف صریح استفاده کند:
کاتلین
// This makes the intent explicit. val explicitIntent = Intent("com.example.action.APP_ACTION") explicitIntent.apply { package = context.packageName } context.startActivity(explicitIntent)
جاوا
// This makes the intent explicit. Intent explicitIntent = new Intent("com.example.action.APP_ACTION") explicitIntent.setPackage(context.getPackageName()); context.startActivity(explicitIntent);
گیرنده های پخش ثبت شده در زمان اجرا باید رفتار صادراتی را مشخص کنند
برنامهها و سرویسهایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند و از گیرندههای ثبت شده در زمینه استفاده میکنند، باید پرچمی را مشخص کنند تا نشان دهد گیرنده باید به همه برنامههای دیگر دستگاه صادر شود یا نه: به ترتیب RECEIVER_EXPORTED
یا RECEIVER_NOT_EXPORTED
. . این نیاز به محافظت از برنامهها در برابر آسیبپذیریهای امنیتی با استفاده از ویژگیهای این گیرندههای معرفیشده در Android 13 کمک میکند.
استثنا برای گیرنده هایی که فقط پخش سیستم را دریافت می کنند
اگر برنامه شما فقط برای پخشهای سیستمی از طریق روشهای Context#registerReceiver
، مانند Context#registerReceiver()
یک گیرنده را ثبت میکند، پس نباید هنگام ثبت گیرنده پرچمی را مشخص کند.
بارگیری کد پویا ایمن تر
If your app targets Android 14 (API level 34) or higher and uses Dynamic Code Loading (DCL), all dynamically-loaded files must be marked as read-only. Otherwise, the system throws an exception. We recommend that apps avoid dynamically loading code whenever possible, as doing so greatly increases the risk that an app can be compromised by code injection or code tampering.
If you must dynamically load code, use the following approach to set the dynamically-loaded file (such as a DEX, JAR, or APK file) as read-only as soon as the file is opened and before any content is written:
Kotlin
val jar = File("DYNAMICALLY_LOADED_FILE.jar") val os = FileOutputStream(jar) os.use { // Set the file to read-only first to prevent race conditions jar.setReadOnly() // Then write the actual file content } val cl = PathClassLoader(jar, parentClassLoader)
Java
File jar = new File("DYNAMICALLY_LOADED_FILE.jar"); try (FileOutputStream os = new FileOutputStream(jar)) { // Set the file to read-only first to prevent race conditions jar.setReadOnly(); // Then write the actual file content } catch (IOException e) { ... } PathClassLoader cl = new PathClassLoader(jar, parentClassLoader);
Handle dynamically-loaded files that already exist
To prevent exceptions from being thrown for existing dynamically-loaded files, we recommend deleting and recreating the files before you try to dynamically load them again in your app. As you recreate the files, follow the preceding guidance for marking the files read-only at write time. Alternatively, you can re-label the existing files as read-only, but in this case, we strongly recommend that you verify the integrity of the files first (for example, by checking the file's signature against a trusted value), to help protect your app from malicious actions.
محدودیت های اضافی برای شروع فعالیت ها از پس زمینه
برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، سیستم زمانی را محدود میکند که برنامهها مجاز به شروع فعالیتها از پسزمینه باشند:
- وقتی یک برنامه با استفاده از
PendingIntent#send()
یا روشهای مشابه، یکPendingIntent
ارسال میکند، اگر برنامه میخواهد امتیازات راهاندازی فعالیت پسزمینه خود را برای شروع هدف معلق اعطا کند، باید آن را انتخاب کند. برای شرکت کردن، برنامه باید یک بستهActivityOptions
باsetPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
ارسال کند. - هنگامی که یک برنامه قابل مشاهده، سرویس برنامه دیگری را که در پسزمینه است با استفاده از روش
bindService()
متصل میکند، برنامه قابل مشاهده اگر میخواهد امتیازات راهاندازی فعالیت پسزمینه خود را به سرویس محدود اعطا کند، اکنون باید شرکت کند. برای شرکت کردن، برنامه باید هنگام فراخوانی متدbindService()
پرچمBIND_ALLOW_ACTIVITY_STARTS
را داشته باشد.
این تغییرات مجموعه محدودیتهای موجود را گسترش میدهد تا با جلوگیری از سوء استفاده برنامههای مخرب از APIها برای شروع فعالیتهای مخرب از پسزمینه، از کاربران محافظت کند.
پیمایش مسیر زیپ
For apps targeting Android 14 (API level 34) or higher, Android prevents the Zip
Path Traversal Vulnerability in the following way:
ZipFile(String)
and
ZipInputStream.getNextEntry()
throws a
ZipException
if zip file entry names contain ".." or start
with "/".
Apps can opt-out from this validation by calling
dalvik.system.ZipPathValidator.clearCallback()
.
رضایت کاربر برای هر جلسه ضبط MediaProjection لازم است
For apps targeting Android 14 (API level 34) or higher, a SecurityException
is
thrown by MediaProjection#createVirtualDisplay
in either of the following
scenarios:
- Your app caches the
Intent
that is returned fromMediaProjectionManager#createScreenCaptureIntent
, and passes it multiple times toMediaProjectionManager#getMediaProjection
. - Your app invokes
MediaProjection#createVirtualDisplay
multiple times on the sameMediaProjection
instance.
Your app must ask the user to give consent before each capture session. A single
capture session is a single invocation on
MediaProjection#createVirtualDisplay
, and each MediaProjection
instance must
be used only once.
Handle configuration changes
If your app needs to invoke MediaProjection#createVirtualDisplay
to handle
configuration changes (such as the screen orientation or screen size changing),
you can follow these steps to update the VirtualDisplay
for the existing
MediaProjection
instance:
- Invoke
VirtualDisplay#resize
with the new width and height. - Provide a new
Surface
with the new width and height toVirtualDisplay#setSurface
.
Register a callback
Your app should register a callback to handle cases where the user doesn't grant
consent to continue a capture session. To do this, implement
Callback#onStop
and have your app release any related resources (such as
the VirtualDisplay
and Surface
).
If your app doesn't register this callback,
MediaProjection#createVirtualDisplay
throws an IllegalStateException
when your app invokes it.
محدودیتهای غیر SDK بهروزرسانی شد
Android 14 شامل لیست های به روز شده از رابط های غیر SDK محدود شده بر اساس همکاری با توسعه دهندگان اندروید و آخرین آزمایش داخلی است. در صورت امکان، قبل از اینکه رابطهای غیر SDK را محدود کنیم، مطمئن میشویم که جایگزینهای عمومی در دسترس هستند.
اگر برنامه شما اندروید 14 را هدف قرار نمی دهد، برخی از این تغییرات ممکن است فوراً روی شما تأثیر نگذارند. با این حال، در حالی که در حال حاضر میتوانید از برخی رابطهای غیر SDK ( بسته به سطح API هدف برنامهتان ) استفاده کنید، استفاده از هر روش یا فیلد غیر SDK همیشه خطر شکستن برنامه شما را بالا میبرد.
اگر مطمئن نیستید که برنامه شما از رابط های غیر SDK استفاده می کند، می توانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابطهای غیر SDK متکی است، باید برنامهریزی برای انتقال به جایگزینهای SDK را شروع کنید. با این وجود، میدانیم که برخی از برنامهها دارای موارد استفاده معتبر برای استفاده از رابطهای غیر SDK هستند. اگر نمی توانید جایگزینی برای استفاده از یک رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .
برای کسب اطلاعات بیشتر در مورد تغییرات این نسخه از اندروید، بهروزرسانیهای محدودیتهای رابط غیر SDK در Android 14 را ببینید. برای کسب اطلاعات بیشتر در مورد رابط های غیر SDK به طور کلی، به محدودیت ها در رابط های غیر SDK مراجعه کنید.