مانند نسخه های قبلی، 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 تمام صفحه را ایمن کنید
با Android 11 (سطح API 30)، برای هر برنامه ای امکان استفاده از Notification.Builder.setFullScreenIntent
برای ارسال اهداف تمام صفحه در حالی که گوشی قفل است وجود داشت. میتوانید با اعلام مجوز USE_FULL_SCREEN_INTENT
در AndroidManifest، این را در نصب برنامه به طور خودکار اعطا کنید.
اعلانهای تمام صفحه برای اعلانهای با اولویت بسیار طراحی شدهاند که توجه فوری کاربر را میطلبد، مانند تماس تلفنی دریافتی یا تنظیمات ساعت زنگ دار که توسط کاربر پیکربندی شده است. برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، برنامههایی که مجاز به استفاده از این مجوز هستند محدود به برنامههایی هستند که فقط تماس و زنگ هشدار ارائه میکنند. فروشگاه Google Play مجوزهای USE_FULL_SCREEN_INTENT
پیشفرض را برای هر برنامهای که با این نمایه مطابقت ندارد لغو میکند. مهلت این تغییرات خط مشی 31 مه 2024 است.
این مجوز برای برنامههای نصبشده روی تلفن قبل از بهروزرسانی کاربر به Android 14 فعال باقی میماند. کاربران میتوانند این مجوز را روشن و خاموش کنند.
می توانید از API جدید NotificationManager.canUseFullScreenIntent
استفاده کنید تا بررسی کنید که آیا برنامه شما مجوز دارد یا خیر. در غیر این صورت، برنامه شما میتواند از هدف جدید ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT
برای راهاندازی صفحه تنظیمات استفاده کند که در آن کاربران میتوانند مجوز را صادر کنند.
امنیت
محدودیت برای مقاصد ضمنی و معلق
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,Android 会通过以下方式限制应用向内部应用组件发送隐式 intent:
- 隐式 intent 只能传送到导出的组件。应用必须使用显式 intent 传送到未导出的组件,或将该组件标记为已导出。
- 如果应用通过未指定组件或软件包的 intent 创建可变待处理 intent,系统会抛出异常。
这些变更可防止恶意应用拦截意在供应用内部组件使用的隐式 intent。
例如,下面是可以在应用的清单文件中声明的 intent 过滤器:
<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>
如果应用尝试使用隐式 intent 启动此 activity,则系统会抛出 ActivityNotFoundException
异常:
Kotlin
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(Intent("com.example.action.APP_ACTION"))
Java
// Throws an ActivityNotFoundException exception when targeting Android 14. context.startActivity(new Intent("com.example.action.APP_ACTION"));
如需启动非导出的 activity,应用应改用显式 intent:
Kotlin
// This makes the intent explicit. val explicitIntent = Intent("com.example.action.APP_ACTION") explicitIntent.apply { package = context.packageName } context.startActivity(explicitIntent)
Java
// 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()
)为系统广播注册接收器,那么在注册接收器时不应指定标志。
بارگیری کد پویا ایمن تر
اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهد و از بارگذاری کد پویا (DCL) استفاده میکند، همه فایلهای بارگذاری شده پویا باید بهعنوان فقط خواندنی علامتگذاری شوند. در غیر این صورت، سیستم یک استثنا ایجاد می کند. توصیه میکنیم برنامهها تا حد امکان از بارگذاری پویا کد خودداری کنند ، زیرا انجام این کار خطر آسیبدیدگی یک برنامه با تزریق کد یا دستکاری کد را به شدت افزایش میدهد.
اگر باید کد را به صورت پویا بارگیری کنید، از روش زیر استفاده کنید تا فایل بارگذاری شده پویا (مانند فایل DEX، JAR، یا APK) را بهمحض باز شدن فایل و قبل از نوشتن هر محتوایی فقط خواندنی تنظیم کنید:
کاتلین
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)
جاوا
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);
مدیریت فایلهای بارگذاری شده پویا که از قبل وجود دارند
برای جلوگیری از ایجاد استثنا برای فایلهای موجود که به صورت پویا بارگذاری شدهاند، توصیه میکنیم قبل از بارگیری مجدد آنها به صورت پویا در برنامه خود، فایلها را حذف و دوباره ایجاد کنید. همانطور که فایل ها را دوباره ایجاد می کنید، دستورالعمل های قبلی را برای علامت گذاری فایل ها به صورت فقط خواندنی در زمان نوشتن دنبال کنید. همچنین، میتوانید فایلهای موجود را دوباره بهعنوان فقط خواندنی برچسبگذاری کنید، اما در این مورد، اکیداً توصیه میکنیم که ابتدا یکپارچگی فایلها را تأیید کنید (مثلاً با بررسی امضای فایل در برابر یک مقدار قابل اعتماد)، برای کمک به محافظت برنامه شما از اقدامات مخرب
محدودیت های اضافی برای شروع فعالیت ها از پس زمینه
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,系统会进一步限制允许应用在后台启动 activity 的时间:
- 现在,当应用使用
PendingIntent#send()
或类似方法发送PendingIntent
时,如果它想要授予自己的后台 activity 启动待处理 intent 的启动特权,则必须选择启用。如需选择启用,应用应通过setPendingIntentBackgroundActivityStartMode(MODE_BACKGROUND_ACTIVITY_START_ALLOWED)
传递ActivityOptions
软件包。 - 当可见应用绑定了另一个后台应用的服务时
bindService()
方法,可见应用现在必须 如果它想要将自己的后台活动 绑定服务。要选择启用,应用应包含BIND_ALLOW_ACTIVITY_STARTS
标志,在调用bindService()
方法。
这些更改扩大了一组现有限制条件的范围,目的是防止恶意应用滥用 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 لازم است
对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,在以下任一情况下,MediaProjection#createVirtualDisplay
会抛出 SecurityException
:
- 您的应用会缓存从
MediaProjectionManager#createScreenCaptureIntent
返回的Intent
,并将其多次传递给MediaProjectionManager#getMediaProjection
。 - 您的应用在同一
MediaProjection
实例上多次调用MediaProjection#createVirtualDisplay
。
您的应用必须在每次捕获会话之前征求用户同意。单次拍摄会话是指对 MediaProjection#createVirtualDisplay
的单次调用,且每个 MediaProjection
实例只能使用一次。
处理配置变更
如果您的应用需要调用 MediaProjection#createVirtualDisplay
来处理配置更改(例如屏幕方向或屏幕尺寸更改),您可以按照以下步骤更新现有 MediaProjection
实例的 VirtualDisplay
:
- 使用新的宽度和高度调用
VirtualDisplay#resize
。 - 为
VirtualDisplay#setSurface
提供具有新宽度和高度的新Surface
。
注册回调
您的应用应注册一个回调,以处理用户不同意继续拍摄会话的情况。为此,请实现 Callback#onStop
并让您的应用发布所有相关资源(例如 VirtualDisplay
和 Surface
)。
如果您的应用未注册此回调,MediaProjection#createVirtualDisplay
会在应用调用此回调时抛出 IllegalStateException
。
محدودیتهای غیر SDK بهروزرسانی شد
Android 14 包含更新后的受限非 SDK 接口列表(基于与 Android 开发者之间的协作以及最新的内部测试)。在限制使用非 SDK 接口之前,我们会尽可能确保有可用的公开替代方案。
如果您的应用并非以 Android 14 为目标平台,其中一些变更可能不会立即对您产生影响。然而,虽然您目前仍可以使用一些非 SDK 接口(具体取决于应用的目标 API 级别),但只要您使用任何非 SDK 方法或字段,终归存在导致应用出问题的显著风险。
如果您不确定自己的应用是否使用了非 SDK 接口,则可以测试您的应用来进行确认。如果您的应用依赖于非 SDK 接口,您应该开始计划迁移到 SDK 替代方案。然而,我们知道某些应用具有使用非 SDK 接口的有效用例。如果您无法为应用中的某项功能找到使用非 SDK 接口的替代方案,应请求新的公共 API。
برای کسب اطلاعات بیشتر در مورد تغییرات این نسخه از اندروید، بهروزرسانیهای محدودیتهای رابط غیر SDK در Android 14 را ببینید. برای کسب اطلاعات بیشتر در مورد رابط های غیر SDK به طور کلی، به محدودیت ها در رابط های غیر SDK مراجعه کنید.