مانند نسخههای قبلی، اندروید ۱۴ شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامههایی اعمال میشود که اندروید ۱۴ (سطح API ۳۴) یا بالاتر را هدف قرار میدهند. اگر برنامه شما اندروید ۱۴ یا بالاتر را هدف قرار میدهد، باید برنامه خود را اصلاح کنید تا در صورت لزوم، از این رفتارها به درستی پشتیبانی کند.
حتماً فهرست تغییرات رفتاری که بر همه برنامههای در حال اجرا در اندروید ۱۴ تأثیر میگذارند را صرف نظر از targetSdkVersion برنامه، بررسی کنید.
عملکرد اصلی
انواع خدمات پیشزمینه الزامی هستند
اگر برنامه شما Android 14 (سطح API 34) یا بالاتر را هدف قرار می دهد، باید حداقل یک نوع سرویس پیش زمینه را برای هر سرویس پیش زمینه در برنامه شما مشخص کند. شما باید یک نوع سرویس پیش زمینه را انتخاب کنید که نشان دهنده مورد استفاده برنامه شما باشد. این سیستم انتظار دارد که خدمات پیش زمینه ای که نوع خاصی دارند، مورد استفاده خاص را برآورده کنند.
اگر مورد استفاده در برنامه شما با هیچ یک از این انواع مرتبط نیست، اکیداً توصیه میشود که منطق خود را برای استفاده از WorkManager یا کارهای انتقال داده توسط کاربر تغییر دهید.
اعمال مجوز BLUETOOTH_CONNECT در BluetoothAdapter
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) راهاندازی Tiles
برای برنامههایی که نسخه ۱۴ و بالاتر را هدف قرار میدهند، TileService#startActivityAndCollapse(Intent) منسوخ شده است و اکنون هنگام فراخوانی یک استثنا ایجاد میکند. اگر برنامه شما فعالیت ها را از کاشی ها راه اندازی می کند، به جای آن از TileService#startActivityAndCollapse(PendingIntent) استفاده کنید.
حریم خصوصی
دسترسی جزئی به عکسها و ویدیوها
Android 14 引入了“已选照片访问权限”,让用户可以向应用授予对其媒体库中特定图片和视频的访问权限,而不是授予对给定类型的所有媒体的访问权限。
只有当您的应用以 Android 14(API 级别 34)或更高版本为目标平台时,此更改才会启用。如果您尚未使用照片选择器,我们建议您在应用中实现照片选择器,以提供一致的图片和视频选择体验,同时增强用户隐私保护,而无需请求任何存储权限。
如果您使用存储权限维护自己的图库选择器,并且需要对实现保持完全控制,请调整实现以使用新的 READ_MEDIA_VISUAL_USER_SELECTED 权限。如果您的应用不使用新权限,系统会以兼容模式运行您的应用。
تجربه کاربری
اعلانهای هدفمند تمامصفحه امن
在 Android 11(API 级别 30)中,任何应用都可以在手机处于锁定状态时使用 Notification.Builder.setFullScreenIntent 发送全屏 intent。您可以通过在 AndroidManifest 中声明 USE_FULL_SCREEN_INTENT 权限,在应用安装时自动授予此权限。
全屏 intent 通知适用于需要用户立即注意的极高优先级通知,例如用户来电或用户配置的闹钟设置。对于以 Android 14(API 级别 34)或更高版本为目标平台的应用,获准使用此权限的应用仅限于提供通话和闹钟的应用。对于不适合此情况的任何应用,Google Play 商店会撤消其默认的 USE_FULL_SCREEN_INTENT 权限。这些政策变更的截止日期为 2024 年 5 月 31 日。
在用户更新到 Android 14 之前,在手机上安装的应用仍拥有此权限。用户可以开启和关闭此权限。
您可以使用新 API NotificationManager.canUseFullScreenIntent 检查应用是否具有该权限;如果没有,应用可以使用新 intent ACTION_MANAGE_APP_USE_FULL_SCREEN_INTENT 启动设置页面,在该页面中,用户可以授予权限。
امنیت
محدودیتهای مربوط به intentهای ضمنی و در حال انتظار
برای برنامههایی که 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())针对系统广播注册接收器,那么它在注册接收器时不应指定标志。
بارگذاری کد پویای امنتر
اگر برنامه شما 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()方法绑定其他在后台应用的服务时,如果可见应用想要授予自己的后台 activity 对绑定服务的启动特权,则必须选择启用。如需选择启用,应用应在调用bindService()方法时包含BIND_ALLOW_ACTIVITY_STARTS标志。
这些更改扩大了一组现有限制条件的范围,目的是防止恶意应用滥用 API 以在后台启动干扰性活动,从而保护用户。
پیمایش مسیر زیپ
برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، Android از آسیبپذیری Zip Path Traversal به روش زیر جلوگیری میکند: ZipFile(String) و ZipInputStream.getNextEntry() در صورتی که نام ورودی فایل فشرده حاوی ".." یا start باشد، یک ZipException ایجاد میکند. با "/".
برنامهها میتوانند با فراخوانی dalvik.system.ZipPathValidator.clearCallback() از این تأیید انصراف دهند.
رضایت کاربر برای هر جلسه ضبط MediaProjection الزامی است
برای برنامههایی که Android 14 (سطح API 34) یا بالاتر را هدف قرار میدهند، یک SecurityException توسط MediaProjection#createVirtualDisplay در یکی از سناریوهای زیر ایجاد میشود:
- برنامه شما
Intentکه ازMediaProjectionManager#createScreenCaptureIntentبرگردانده میشود در حافظه پنهان ذخیره میکند و چندین بار آن را بهMediaProjectionManager#getMediaProjectionارسال میکند. - برنامه شما چندین بار
MediaProjection#createVirtualDisplayرا در یک نمونهMediaProjectionفراخوانی می کند.
برنامه شما باید قبل از هر جلسه عکسبرداری از کاربر بخواهد رضایت بدهد. یک جلسه ضبط یک فراخوانی واحد در MediaProjection#createVirtualDisplay است و هر نمونه MediaProjection باید فقط یک بار استفاده شود.
کنترل تغییرات پیکربندی
اگر برنامه شما نیاز به فراخوانی MediaProjection#createVirtualDisplay برای مدیریت تغییرات پیکربندی دارد (مانند تغییر جهت صفحه یا اندازه صفحه)، میتوانید این مراحل را برای بهروزرسانی VirtualDisplay برای نمونه MediaProjection موجود دنبال کنید:
-
VirtualDisplay#resizeکنید. - یک
Surfaceجدید با عرض و ارتفاع جدیدVirtualDisplay#setSurfaceارائه دهید.
پاسخ تماس را ثبت کنید
برنامه شما باید برای رسیدگی به مواردی که کاربر برای ادامه جلسه ضبط رضایت نمی دهد، یک تماس پاسخ ثبت کند. برای انجام این کار، Callback#onStop را پیاده سازی کنید و از برنامه خود بخواهید منابع مرتبط (مانند VirtualDisplay و Surface ) را منتشر کند.
اگر برنامه شما این پاسخ تماس را ثبت نکند، MediaProjection#createVirtualDisplay هنگامی که برنامه شما آن را فراخوانی می کند، یک IllegalStateException ایجاد می کند.
محدودیتهای غیر SDK بهروزرسانی شدند
اندروید ۱۴ شامل فهرستهای بهروز شدهای از رابطهای کاربری محدود شده غیر SDK بر اساس همکاری با توسعهدهندگان اندروید و آخرین آزمایشهای داخلی است. در صورت امکان، قبل از محدود کردن رابطهای کاربری غیر SDK، مطمئن میشویم که جایگزینهای عمومی در دسترس هستند.
اگر برنامه شما اندروید ۱۴ را هدف قرار نمیدهد، ممکن است برخی از این تغییرات بلافاصله شما را تحت تأثیر قرار ندهند. با این حال، اگرچه در حال حاضر میتوانید از برخی رابطهای غیر SDK ( بسته به سطح API هدف برنامه خود ) استفاده کنید، استفاده از هر روش یا فیلد غیر SDK همیشه خطر بالای خرابی برنامه شما را به همراه دارد.
اگر مطمئن نیستید که برنامه شما از رابطهای غیر SDK استفاده میکند، میتوانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابطهای غیر SDK متکی است، باید برنامهریزی برای مهاجرت به جایگزینهای SDK را آغاز کنید. با این وجود، ما درک میکنیم که برخی از برنامهها موارد استفاده معتبری برای استفاده از رابطهای غیر SDK دارند. اگر نمیتوانید جایگزینی برای استفاده از رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .
如需详细了解此 Android 版本中的变更,请参阅 Android 14 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。