مانند نسخههای قبلی، اندروید ۱۴ شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامههایی اعمال میشود که اندروید ۱۴ (سطح 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。在 Android 14 之前,如果作业运行时间过长,系统会停止作业并静默失败。如果您的应用以 Android 14(API 级别 34)或更高版本为目标平台,
超过在主线程上授予的时间,应用会触发 ANR
显示“没有响应 onStartJob”错误消息或
“onStopJob没有回复”。
此 ANR 可能是由以下 2 种情况造成的:
1.有工作阻塞主线程,阻止回调 onStartJob
或者onStopJob在预期时间内执行并完成。
2. 开发者在 JobScheduler 中运行阻塞工作
回调 onStartJob 或 onStopJob,阻止从
在预期的时限内完成
要解决第 1 个问题,您需要进一步调试阻塞主线程的因素
您可以使用以下代码
ApplicationExitInfo#getTraceInputStream(),用于获取 Tombstone
ANR 发生时的跟踪信息如果您能够手动重现 ANR 问题
您可以录制系统轨迹,并使用
Android Studio 或 Perfetto,以便更好地了解应用上运行的
在发生 ANR 时调用主线程
请注意,直接使用 JobScheduler API 或使用 androidx 库 WorkManager 时可能会发生这种情况。
如需解决问题 2,请考虑迁移到 WorkManager,它支持将 onStartJob 或 onStopJob 中的任何处理封装在异步线程中。
JobScheduler 还引入了一项要求,即如果使用 setRequiredNetworkType 或 setRequiredNetwork 约束条件,则必须声明 ACCESS_NETWORK_STATE 权限。如果您的应用未声明
ACCESS_NETWORK_STATE 权限
Android 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 برای ارسال اهداف تمام صفحه در حالی که گوشی قفل است وجود داشت. میتوانید با اعلام مجوز 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 برای راهاندازی صفحه تنظیمات استفاده کند که در آن کاربران میتوانند مجوز را صادر کنند.
امنیت
محدودیتهای مربوط به 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 路径遍历漏洞:如果 Zip 文件条目名称包含“..”或以“/”开头,ZipFile(String) 和 ZipInputStream.getNextEntry() 会抛出 ZipException。
应用可以通过调用 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 بهروزرسانی شدند
اندروید ۱۴ شامل فهرستهای بهروز شدهای از رابطهای کاربری محدود شده غیر SDK بر اساس همکاری با توسعهدهندگان اندروید و آخرین آزمایشهای داخلی است. در صورت امکان، قبل از محدود کردن رابطهای کاربری غیر SDK، مطمئن میشویم که جایگزینهای عمومی در دسترس هستند.
اگر برنامه شما اندروید ۱۴ را هدف قرار نمیدهد، ممکن است برخی از این تغییرات بلافاصله شما را تحت تأثیر قرار ندهند. با این حال، اگرچه در حال حاضر میتوانید از برخی رابطهای غیر SDK ( بسته به سطح API هدف برنامه خود ) استفاده کنید، استفاده از هر روش یا فیلد غیر SDK همیشه خطر بالای خرابی برنامه شما را به همراه دارد.
اگر مطمئن نیستید که برنامه شما از رابطهای غیر SDK استفاده میکند، میتوانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابطهای غیر SDK متکی است، باید برنامهریزی برای مهاجرت به جایگزینهای SDK را آغاز کنید. با این وجود، ما درک میکنیم که برخی از برنامهها موارد استفاده معتبری برای استفاده از رابطهای غیر SDK دارند. اگر نمیتوانید جایگزینی برای استفاده از رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .
如需详细了解此 Android 版本中的变更,请参阅 Android 14 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。