مانند نسخه های قبلی، Android 15 شامل تغییرات رفتاری است که ممکن است بر برنامه شما تأثیر بگذارد. تغییرات رفتاری زیر منحصراً برای برنامههایی اعمال میشود که Android 15 یا بالاتر را هدف قرار میدهند. اگر برنامه شما اندروید 15 یا بالاتر را هدف قرار می دهد، باید برنامه خود را تغییر دهید تا در صورت لزوم از این رفتارها به درستی پشتیبانی کند.
حتماً فهرستی از تغییرات رفتاری را نیز مرور کنید که بر همه برنامههای در حال اجرا در Android 15 بدون توجه به targetSdkVersion
برنامه شما تأثیر میگذارد.
عملکرد اصلی
اندروید 15 قابلیت های اصلی مختلف سیستم اندروید را اصلاح یا گسترش می دهد.
تغییرات در خدمات پیش زمینه
ما در حال انجام تغییرات زیر در سرویس های پیش زمینه با اندروید 15 هستیم.
- رفتار درنگ سرویس پیش زمینه همگام سازی داده ها
- نوع سرویس پیش زمینه پردازش رسانه جدید
- محدودیت در گیرنده های پخش
BOOT_COMPLETED
که خدمات پیش زمینه را راه اندازی می کنند - محدودیتهایی برای شروع سرویسهای پیشزمینه در زمانی که برنامه دارای مجوز
SYSTEM_ALERT_WINDOW
است
رفتار درنگ سرویس پیش زمینه همگام سازی داده ها
Android 15 introduces a new timeout behavior to dataSync
for apps targeting
Android 15 (API level 35) or higher. This behavior also applies to the new
mediaProcessing
foreground service type.
The system permits an app's dataSync
services to run for a total of 6 hours
in a 24-hour period, after which the system calls the running service's
Service.onTimeout(int, int)
method (introduced in Android
15). At this time, the service has a few seconds to call
Service.stopSelf()
. When Service.onTimeout()
is called, the
service is no longer considered a foreground service. If the service does not
call Service.stopSelf()
, the system throws an internal exception. The
exception is logged in Logcat with the following message:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"
To avoid problems with this behavior change, you can do one or more of the following:
- Have your service implement the new
Service.onTimeout(int, int)
method. When your app receives the callback, make sure to callstopSelf()
within a few seconds. (If you don't stop the app right away, the system generates a failure.) - Make sure your app's
dataSync
services don't run for more than a total of 6 hours in any 24-hour period (unless the user interacts with the app, resetting the timer). - Only start
dataSync
foreground services as a result of direct user interaction; since your app is in the foreground when the service starts, your service has the full six hours after the app goes to the background. - Instead of using a
dataSync
foreground service, use an alternative API.
If your app's dataSync
foreground services have run for 6 hours in the last
24, you cannot start another dataSync
foreground service unless the user
has brought your app to the foreground (which resets the timer). If you try to
start another dataSync
foreground service, the system throws
ForegroundServiceStartNotAllowedException
with an error message like "Time limit already exhausted for foreground service
type dataSync".
Testing
To test your app's behavior, you can enable data sync timeouts even if your app
is not targeting Android 15 (as long as the app is running on an Android 15
device). To enable timeouts, run the following adb
command:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
You can also adjust the timeout period, to make it easier to test how your
app behaves when the limit is reached. To set a new timeout period, run the
following adb
command:
adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds
نوع سرویس پیش زمینه پردازش رسانه جدید
اندروید 15 یک نوع سرویس پیش زمینه جدید، mediaProcessing
را معرفی می کند. این نوع سرویس برای عملیاتی مانند رمزگذاری فایل های رسانه ای مناسب است. به عنوان مثال، یک برنامه رسانه ممکن است یک فایل صوتی را دانلود کند و قبل از پخش آن را به فرمت دیگری تبدیل کند. میتوانید از سرویس پیشزمینه mediaProcessing
استفاده کنید تا مطمئن شوید که تبدیل حتی زمانی که برنامه در پسزمینه است ادامه مییابد.
این سیستم به سرویسهای mediaProcessing
یک برنامه اجازه میدهد در مجموع 6 ساعت در یک دوره 24 ساعته اجرا شوند، پس از آن سیستم سرویس سرویس در حال اجرا را متد Service.onTimeout(int, int)
(معرفی شده در Android 15) فراخوانی میکند. در این زمان، سرویس چند ثانیه فرصت دارد تا Service.stopSelf()
را فراخوانی کند. اگر سرویس Service.stopSelf()
را فراخوانی نکند، سیستم یک استثنا داخلی ایجاد می کند. استثنا با پیام زیر در Logcat وارد شده است:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
برای جلوگیری از استثناء، می توانید یکی از موارد زیر را انجام دهید:
- از سرویس خود بخواهید روش جدید
Service.onTimeout(int, int)
را پیاده سازی کند. هنگامی که برنامه شما پاسخ تماس را دریافت کرد، مطمئن شوید که در عرض چند ثانیهstopSelf()
تماس بگیرید. (اگر برنامه را فوراً متوقف نکنید، سیستم یک خرابی ایجاد می کند.) - مطمئن شوید که سرویسهای
mediaProcessing
برنامه شما در هر دوره ۲۴ ساعته در مجموع بیش از ۶ ساعت اجرا نمیشوند (مگر اینکه کاربر با برنامه تعامل داشته باشد و تایمر را بازنشانی کند). - خدمات پیش زمینه
mediaProcessing
را فقط در نتیجه تعامل مستقیم کاربر شروع کنید. از آنجایی که هنگام شروع سرویس، برنامه شما در پیش زمینه است، سرویس شما شش ساعت کامل پس از رفتن برنامه به پسزمینه است. - به جای استفاده از سرویس پیش زمینه
mediaProcessing
، از یک API جایگزین مانند WorkManager استفاده کنید.
اگر سرویسهای پیشزمینه mediaProcessing
برنامهتان در 24 ساعت گذشته به مدت 6 ساعت اجرا شده است، نمیتوانید سرویس پیشزمینه mediaProcessing
دیگری را راهاندازی کنید ، مگر اینکه کاربر برنامه شما را به پیشزمینه آورده باشد (که تایمر را بازنشانی میکند). اگر بخواهید سرویس پیشزمینه mediaProcessing
دیگری را راهاندازی کنید، سیستم ForegroundServiceStartNotAllowedException
را با پیام خطایی مانند "محدودیت زمانی برای نوع سرویس پیشزمینه mediaProcessing تمام شده است" میفرستد.
برای اطلاعات بیشتر در مورد نوع سرویس mediaProcessing
، به تغییرات در انواع خدمات پیش زمینه برای Android 15 مراجعه کنید: پردازش رسانه .
تست کردن
برای آزمایش رفتار برنامهتان، میتوانید وقفههای زمانی پردازش رسانه را فعال کنید، حتی اگر برنامه شما Android 15 را هدف قرار ندهد (تا زمانی که برنامه روی دستگاه Android 15 اجرا شود). برای فعال کردن بازه زمانی، دستور adb
زیر را اجرا کنید:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
همچنین میتوانید مدت زمان وقفه را تنظیم کنید تا آزمایش نحوه عملکرد برنامهتان در زمان رسیدن به محدودیت آسانتر شود. برای تنظیم یک بازه زمانی جدید، دستور adb
زیر را اجرا کنید:
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
محدودیت در گیرنده های پخش BOOT_COMPLETED
که خدمات پیش زمینه را راه اندازی می کنند
محدودیت های جدیدی برای گیرنده های پخش BOOT_COMPLETED
وجود دارد که خدمات پیش زمینه را راه اندازی می کنند. گیرنده های BOOT_COMPLETED
مجاز به راه اندازی انواع خدمات پیش زمینه زیر نیستند :
-
dataSync
-
camera
-
mediaPlayback
-
phoneCall
-
mediaProjection
-
microphone
(این محدودیت از اندروید 14 برایmicrophone
اعمال شده است)
اگر یک گیرنده BOOT_COMPLETED
سعی کند هر یک از آن نوع خدمات پیش زمینه را راه اندازی کند، سیستم ForegroundServiceStartNotAllowedException
پرتاب می کند.
تست کردن
برای آزمایش رفتار برنامهتان، میتوانید این محدودیتهای جدید را فعال کنید، حتی اگر برنامه شما اندروید 15 را هدف قرار ندهد (تا زمانی که برنامه روی دستگاه Android 15 اجرا شود). دستور adb
زیر را اجرا کنید:
adb shell am compat enable FGS_BOOT_COMPLETED_RESTRICTIONS your-package-name
برای ارسال یک پخش BOOT_COMPLETED
بدون راه اندازی مجدد دستگاه، دستور adb
زیر را اجرا کنید:
adb shell am broadcast -a android.intent.action.BOOT_COMPLETED your-package-name
محدودیتهایی برای شروع سرویسهای پیشزمینه در زمانی که برنامه دارای مجوز SYSTEM_ALERT_WINDOW
است
以前,如果应用拥有 SYSTEM_ALERT_WINDOW
权限,即使应用当前在后台运行,也可以启动前台服务(如免于后台启动限制中所述)。
如果应用以 Android 15 为目标平台,则此豁免范围现在更窄。现在,应用需要具有 SYSTEM_ALERT_WINDOW
权限,并且还需要有一个可见的叠加窗口。也就是说,应用需要先启动 TYPE_APPLICATION_OVERLAY
窗口,并且该窗口需要处于可见状态,然后您才能启动前台服务。
如果您的应用尝试从后台启动前台服务,但不符合这些新要求(并且没有其他豁免情况),系统会抛出 ForegroundServiceStartNotAllowedException
。
如果您的应用声明了 SYSTEM_ALERT_WINDOW
权限并从后台启动前台服务,则可能会受到此变更的影响。如果您的应用获得了 ForegroundServiceStartNotAllowedException
,请检查应用的操作顺序,并确保应用在尝试从后台启动前台服务之前已具有有效的叠加层窗口。您可以通过调用 View.getWindowVisibility()
检查叠加层窗口当前是否可见,也可以替换 View.onWindowVisibilityChanged()
,以便在可见性发生变化时收到通知。
测试
如需测试应用的行为,您可以启用这些新限制,即使您的应用并未以 Android 15 为目标平台(只要应用在 Android 15 设备上运行)也是如此。如需针对从后台启动前台服务启用这些新限制,请运行以下 adb
命令:
adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name
زمانی که برنامهها میتوانند وضعیت جهانی حالت مزاحم نشوید را تغییر دهند
以 Android 15 为目标平台的应用无法再更改设备上的全局状态或勿扰 (DND) 政策(通过修改用户设置或关闭 DND 模式)。相反,应用必须提供一个 AutomaticZenRule
,系统会将后者合并到一个具有现有最严格的政策胜出方案的全局政策中。调用之前影响全局状态的现有 API(setInterruptionFilter
、setNotificationPolicy
)会导致创建或更新隐式 AutomaticZenRule
,该 AutomaticZenRule
根据这些 API 调用的调用周期而开启或关闭。
请注意,只有在应用调用 setInterruptionFilter(INTERRUPTION_FILTER_ALL)
且预期调用会停用之前由其所有者激活的 AutomaticZenRule
时,此变更才会影响可观察的行为。
OpenJDK API تغییر می کند
Android 15 将继续更新 Android 的核心库,以与最新 OpenJDK LTS 版本中的功能保持一致。
其中一些变更可能会影响以 Android 15(API 级别 35)为目标平台的应用的兼容性:
对字符串格式化 API 的更改:现在,使用以下
String.format()
和Formatter.format()
API 时,对参数索引、标志、宽度和精度的验证更为严格:String.format(String, Object[])
String.format(Locale, String, Object[])
Formatter.format(String, Object[])
Formatter.format(Locale, String, Object[])
例如,如果使用参数索引 0(格式字符串中的
%0
),系统会抛出以下异常:IllegalFormatArgumentIndexException: Illegal format argument index = 0
在这种情况下,可以通过使用参数编号 1(格式字符串中的
%1
)来解决此问题。Arrays.asList(...).toArray()
的组件类型变更:使用Arrays.asList(...).toArray()
时,生成数组的组件类型现在为Object
,而不是底层数组元素的类型。因此,以下代码会抛出ClassCastException
:String[] elements = (String[]) Arrays.asList("one", "two").toArray();
对于这种情况,如需将
String
保留为生成的数组中的组件类型,您可以改用Collection.toArray(Object[])
:String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
语言代码处理方式变更:使用
Locale
API 时,希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为已废弃的形式(希伯来语:iw
、意第绪语:ji
、印度尼西亚语:in
)。在为其中一种语言区域指定语言代码时,请改用 ISO 639-1 中的代码(希伯来语:he
、意第绪语:yi
、印度尼西亚语:id
)。对随机 int 序列的更改:在 https://bugs.openjdk.org/browse/JDK-8301574 中进行更改后,以下
Random.ints()
方法现在返回的数字序列与Random.nextInt()
方法返回的序列不同:通常,此更改不会导致应用出现破坏行为,但您的代码不应预期从
Random.ints()
方法生成的序列与Random.nextInt()
匹配。
在您更新应用 build 配置中的 compileSdk
以使用 Android 15(API 级别 35)后,新的 SequencedCollection
API 可能会影响应用的兼容性:
与
kotlin-stdlib
中的MutableList.removeFirst()
和MutableList.removeLast()
扩展函数发生冲突Java 中的
List
类型会映射到 Kotlin 中的MutableList
类型。由于List.removeFirst()
和List.removeLast()
API 已在 Android 15(API 级别 35)中引入,因此 Kotlin 编译器会将函数调用(例如list.removeFirst()
)静态解析为新的List
API,而不是kotlin-stdlib
中的扩展函数。如果将应用重新编译并将
compileSdk
设置为35
且将minSdk
设置为34
或更低级别,然后在 Android 14 及更低版本上运行该应用,系统会抛出运行时错误:java.lang.NoSuchMethodError: No virtual method removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
Android Gradle 插件中现有的
NewApi
lint 选项可以捕获这些新的 API 用法。./gradlew lint
MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi] list.removeFirst()如需修复运行时异常和 lint 错误,可以在 Kotlin 中将
removeFirst()
和removeLast()
函数调用分别替换为removeAt(0)
和removeAt(list.lastIndex)
。如果您使用的是 Android Studio Ladybug | 2024.1.3 或更高版本,则该版本还提供了针对这些错误的快速修复选项。如果 lint 选项已停用,请考虑移除
@SuppressLint("NewApi")
和lintOptions { disable 'NewApi' }
。与 Java 中的其他方法冲突
现有类型中添加了新方法,例如
List
和Deque
。这些新方法可能与其他接口和类中具有相同名称和参数类型的方法不兼容。如果方法签名发生冲突且不兼容,javac
编译器会输出构建时错误。例如:错误示例 1:
javac MyList.java
MyList.java:135: error: removeLast() in MyList cannot implement removeLast() in List public void removeLast() { ^ return type void is not compatible with Object where E is a type-variable: E extends Object declared in interface List错误示例 2:
javac MyList.java
MyList.java:7: error: types Deque<Object> and List<Object> are incompatible; public class MyList implements List<Object>, Deque<Object> { both define reversed(), but with unrelated return types 1 error错误示例 3:
javac MyList.java
MyList.java:43: error: types List<E#1> and MyInterface<E#2> are incompatible; public static class MyList implements List<Object>, MyInterface<Object> { class MyList inherits unrelated defaults for getFirst() from types List and MyInterface where E#1,E#2 are type-variables: E#1 extends Object declared in interface List E#2 extends Object declared in interface MyInterface 1 error如需修复这些构建错误,实现这些接口的类应使用兼容的返回类型替换该方法。例如:
@Override public Object getFirst() { return List.super.getFirst(); }
امنیت
اندروید 15 شامل تغییراتی است که امنیت سیستم را ارتقا میدهد تا از برنامهها و کاربران در برابر برنامههای مخرب محافظت کند.
فعالیت پس زمینه ایمن راه اندازی می شود
Android 15 可保护用户免受恶意应用的侵害,并让用户更好地控制 来防止恶意后台应用 将其他应用置于前台、提升其权限以及滥用 用户互动自以下时间以来,后台活动启动一直受到限制 Android 10(API 级别 29)。
禁止与堆栈中的顶部 UID 不匹配的应用启动 activity
恶意应用可以在同一任务中启动另一个应用的 activity,然后
叠加在上面,营造出像该应用一样的错觉。这个“任务”
劫持"攻击绕过了当前的后台启动限制,
会发生在同一个可见任务中。为了降低这种风险,Android 15 新增了
用于阻止与堆栈中的顶层 UID 不匹配的应用启动的标志
活动。如需选择启用应用的所有活动,请更新
allowCrossUidActivitySwitchFromBelow
属性:AndroidManifest.xml
<application android:allowCrossUidActivitySwitchFromBelow="false" >
如果满足以下所有条件,则启用新的安全措施:
- 执行启动的应用以 Android 15 为目标平台。
- 任务堆栈顶部的应用以 Android 15 为目标平台。
- 所有可见活动都已选择启用新保护措施
如果启用了安全措施,应用可能会返回主屏幕,而不是返回 最后一个可见应用(如果他们自行完成任务)。
其他变更
除了限制 UID 匹配之外,这些其他变更也 包括:
- 更改
PendingIntent
创作者,以阻止后台活动启动,具体方法是: 默认。这有助于防止应用意外创建 可能被恶意操作者滥用的PendingIntent
。 - 请勿将应用调到前台,除非
PendingIntent
发送者 允许它。此变更旨在防止恶意应用滥用 在后台启动 activity 的功能。默认情况下,应用 允许将任务堆栈转到前台,除非创建者允许 后台活动启动权限或发送者有后台活动 启动权限 - 控制任务堆栈的顶层 activity 完成其任务的方式。如果 顶层 activity 完成一项任务后,Android 会返回到之前执行的 上次活动时间。此外,如果非顶层 activity 完成其任务,Android 将 返回主屏幕;因此不会阻碍这个非顶层的 活动。
- 防止将其他应用中的任意 activity 启动到您自己的 activity 任务。这项变更旨在防止恶意应用 看起来像是来自其他应用的活动
- 禁止将不可见窗口视为后台活动 发布。这有助于防止恶意应用滥用后台 activity 来向用户显示不需要或恶意的内容。
مقاصد امن تر
اندروید 15 اقدامات امنیتی اختیاری جدیدی را برای ایمن تر و قوی تر کردن مقاصد معرفی می کند. این تغییرات با هدف جلوگیری از آسیب پذیری های احتمالی و سوء استفاده از اهدافی است که می تواند توسط برنامه های مخرب مورد سوء استفاده قرار گیرد. دو پیشرفت اصلی برای امنیت intent در اندروید 15 وجود دارد:
- Match target-intent-filters: مقاصدی که اجزای خاصی را هدف قرار می دهند باید دقیقاً با مشخصات فیلتر هدف هدف مطابقت داشته باشند. اگر قصدی برای راهاندازی فعالیت برنامه دیگری ارسال میکنید، مؤلفه هدف هدف باید با فیلترهای هدف اعلامشده فعالیت دریافتکننده هماهنگ شود.
- Intent ها باید دارای عملکرد باشند: Intent های بدون عمل دیگر با فیلترهای intent مطابقت ندارند. این بدان معناست که مقاصد مورد استفاده برای شروع فعالیت ها یا خدمات باید دارای یک کنش به وضوح تعریف شده باشند.
برای بررسی اینکه برنامه شما چگونه به این تغییرات پاسخ می دهد، از StrictMode
در برنامه خود استفاده کنید. برای مشاهده گزارشهای دقیق درباره نقض استفاده Intent
، روش زیر را اضافه کنید:
کاتلین
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
جاوا
public void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() .detectUnsafeIntentLaunch() .build()); }
تجربه کاربری و رابط کاربری سیستم
اندروید 15 شامل تغییراتی است که برای ایجاد یک تجربه کاربری سازگارتر و بصری در نظر گرفته شده است.
ورودی پنجره تغییر می کند
در اندروید 15 دو تغییر مربوط به ورودیهای پنجره وجود دارد: لبه به لبه بهطور پیشفرض اعمال میشود و همچنین تغییراتی در پیکربندی وجود دارد، مانند پیکربندی پیشفرض نوارهای سیستم.
اجرای لبه به لبه
默认情况下,如果应用以 Android 15(API 级别 35)为目标平台,在搭载 Android 15 的设备上,应用默认采用全屏。
这是一项可能会对应用的界面产生负面影响的破坏性更改。这些变更会影响以下界面区域:
- 手势处理程序导航栏
- 默认透明。
- 底部偏移量处于停用状态,因此除非应用边衬区,否则内容会在系统导航栏后面绘制。
setNavigationBarColor
和R.attr#navigationBarColor
已废弃,不会影响手势导航。setNavigationBarContrastEnforced
和R.attr#navigationBarContrastEnforced
对手势导航的影响仍然不变。
- “三按钮”导航
- 默认情况下,不透明度设置为 80%,颜色可能与窗口背景相匹配。
- 底部偏移量处于停用状态,因此除非应用了边衬区,否则内容会在系统导航栏后面绘制。
- 默认情况下,
setNavigationBarColor
和R.attr#navigationBarColor
会设置为与窗口背景相匹配。窗口背景必须是彩色可绘制对象,此默认值才能应用。此 API 已废弃,但仍会影响三按钮导航。 setNavigationBarContrastEnforced
和R.attr#navigationBarContrastEnforced
默认为 true,这会在“三按钮”导航中添加 80% 的不透明背景。
- 状态栏
- 默认透明。
- 顶部偏移量已停用,因此除非应用边衬区,否则内容绘制在状态栏后面。
setStatusBarColor
和R.attr#statusBarColor
已废弃,对 Android 15 没有任何影响。setStatusBarContrastEnforced
和R.attr#statusBarContrastEnforced
已废弃,但对 Android 15 仍有影响。
- 刘海屏
- 非浮动窗口的
layoutInDisplayCutoutMode
必须为LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
。SHORT_EDGES
、NEVER
和DEFAULT
会被解读为ALWAYS
,这样用户就不会看到由刘海屏导致的黑条,从而显示为无边框。
- 非浮动窗口的
以下示例展示了应用在以 Android 15(API 级别 35)为目标平台之前和之后,以及应用在应用内嵌之前和之后的效果。
如何检查应用是否已采用边到边设计
如果您的应用已采用边到边设计并应用了内边距,则除以下情况外,您大多不会受到影响。不过,即使您认为自己未受到影响,我们仍建议您测试自己的应用。
- 您有一个非浮动窗口,例如使用
SHORT_EDGES
、NEVER
或DEFAULT
(而非LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS
)的Activity
。如果您的应用在启动时崩溃,这可能是启动画面造成的。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本,也可以设置window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
。 - 可能会有流量较低的屏幕显示被遮挡的界面。验证这些访问次数较少的屏幕是否存在遮挡的界面。流量较低的屏幕包括:
- 初始配置或登录屏幕
- “设置”页面
如果您的应用尚未采用边到边设计,应检查哪些方面
如果您的应用尚未采用边到边设计,您很可能受到影响。除了已经采用边到边设计的应用的场景之外,您还应考虑以下情况:
- 如果您的应用在 Compose 中使用 Material 3 组件 (
androidx.compose.material3
),例如TopAppBar
、BottomAppBar
和NavigationBar
,这些组件可能不会受到影响,因为它们会自动处理边衬区。 - 如果应用使用的是 Compose 中的 Material 2 组件 (
androidx.compose.material
),这些组件本身并不会自动处理边衬区。不过,您可以获得边衬区的访问权限,然后手动应用边衬区。在 androidx.compose.material 1.6.0 及更高版本中,使用windowInsets
参数为BottomAppBar
、TopAppBar
、BottomNavigation
和NavigationRail
手动应用边衬区。同样,请为Scaffold
使用contentWindowInsets
参数。 - 如果应用使用了 View 和 Material 组件 (
com.google.android.material
),则大多数基于 View 的 Material 组件(例如BottomNavigationView
、BottomAppBar
、NavigationRailView
或NavigationView
)都会处理边衬区,因此不需要执行额外的操作。不过,如果使用AppBarLayout
,则需要添加android:fitsSystemWindows="true"
。 - 对于自定义可组合项,请手动将边衬区应用为内边距。如果您的内容位于
Scaffold
中,您可以使用Scaffold
内边距值使用内边距。否则,请使用WindowInsets
之一应用内边距。 - 如果应用使用的是 View 和
BottomSheet
、SideSheet
或自定义容器,请使用ViewCompat.setOnApplyWindowInsetsListener
应用内边距。对于RecyclerView
,请使用此监听器应用内边距,并添加clipToPadding="false"
。
如果您的应用必须提供自定义后台保护,应检查哪些方面
如果您的应用必须为三按钮导航栏或状态栏提供自定义背景保护,则应使用 WindowInsets.Type#tappableElement()
获取三按钮导航栏高度或 WindowInsets.Type#statusBars
,将可组合项或视图放置在系统栏后面。
其他端到端资源
如需了解有关应用内边距的其他注意事项,请参阅边到边视图和边到边 Compose 指南。
已弃用的 API
以下 API 已废弃,但并未停用:
R.attr#enforceStatusBarContrast
R.attr#navigationBarColor
(适用于三按钮导航,透明度为 80%)Window#isStatusBarContrastEnforced
Window#setNavigationBarColor
(适用于 80% Alpha 版的三按钮导航)Window#setStatusBarContrastEnforced
以下 API 已弃用和停用:
R.attr#navigationBarColor
(适用于手势导航)R.attr#navigationBarDividerColor
R.attr#statusBarColor
Window#setDecorFitsSystemWindows
Window#getNavigationBarColor
Window#getNavigationBarDividerColor
Window#getStatusBarColor
Window#setNavigationBarColor
(适用于手势导航)Window#setNavigationBarDividerColor
Window#setStatusBarColor
پیکربندی پایدار
如果您的应用以 Android 15(API 级别 35)或更高版本为目标平台,Configuration
不再排除系统栏。如果您使用 Configuration
类中的屏幕尺寸进行布局计算,应根据需要将其替换为合适的 ViewGroup
、WindowInsets
或 WindowMetricsCalculator
等更好的替代方案。
Configuration
从 API 1 开始提供。它通常从 Activity.onConfigurationChanged
中获取。它提供窗口密度、屏幕方向和尺寸等信息。从 Configuration
返回的窗口大小的一个重要特征是,它之前会排除系统栏。
配置大小通常用于资源选择(例如 /res/layout-h500dp
),这仍然是一个有效的用例。不过,我们一直不建议将其用于布局计算。如果确实如此,您应暂时放弃。您应根据自己的用例,将 Configuration
的使用替换为更合适的用法。
如果您使用它来计算布局,请使用适当的 ViewGroup
,例如 CoordinatorLayout
或 ConstraintLayout
。如果您使用它来确定系统侧边栏的高度,请使用 WindowInsets
。如果您想知道应用窗口的当前大小,请使用 computeCurrentWindowMetrics
。
以下列表介绍了受此变更影响的字段:
Configuration.screenWidthDp
和screenHeightDp
尺寸不再排除系统栏。Configuration.smallestScreenWidthDp
会间接受到对screenWidthDp
和screenHeightDp
的更改的影响。- 在接近方形的设备上,
Configuration.orientation
会间接受到对screenWidthDp
和screenHeightDp
所做的更改的影响。 Display.getSize(Point)
会间接受到Configuration
中更改的影响。从 API 级别 30 开始,此方法已被弃用。- 从 API 级别 33 开始,
Display.getMetrics()
就已经这样运作了。
صفت elegantTextHeight به طور پیش فرض درست است
برای برنامههایی که Android 15 (سطح API 35) را هدف قرار میدهند، ویژگی elegantTextHeight
TextView
بهطور پیشفرض true
میشود و فونت فشردهای را که بهطور پیشفرض استفاده میشود با برخی از اسکریپتهایی که معیارهای عمودی بزرگی دارند با فونتی که بسیار خواناتر است جایگزین میکند. فونت فشرده برای جلوگیری از شکستن طرحبندیها معرفی شد. Android 13 (سطح API 33) از بسیاری از این شکستگیها جلوگیری میکند و به طرح متن اجازه میدهد تا ارتفاع عمودی را با استفاده از ویژگی fallbackLineSpacing
کشیده شود.
در اندروید 15، فونت فشرده همچنان در سیستم باقی میماند، بنابراین برنامه شما میتواند elegantTextHeight
را روی false
تنظیم کند تا رفتار قبلی را داشته باشد، اما بعید است که در نسخههای آینده پشتیبانی شود. بنابراین، اگر برنامه شما از اسکریپت های زیر پشتیبانی می کند: عربی، لائوس، میانمار، تامیل، گجراتی، کانادا، مالایالام، اودیا، تلوگو یا تایلندی، برنامه خود را با تنظیم elegantTextHeight
روی true
تست کنید.
عرض TextView برای اشکال حروف پیچیده تغییر می کند
در نسخههای قبلی اندروید، برخی از فونتهای شکسته یا زبانهایی که شکل پیچیدهای دارند، ممکن است حروف را در ناحیه شخصیت قبلی یا بعدی بکشند. در برخی موارد، چنین حروفی در موقعیت آغاز یا پایان بریده می شدند. با شروع اندروید 15، یک TextView
عرض را برای ترسیم فضای کافی برای چنین حروفی اختصاص میدهد و به برنامهها اجازه میدهد تا برای جلوگیری از برش، بالشتکهای اضافی را در سمت چپ درخواست کنند.
از آنجایی که این تغییر بر نحوه تعیین عرض یک TextView
تأثیر میگذارد، اگر برنامه Android 15 (سطح API 35) یا بالاتر را هدف قرار دهد، TextView
به طور پیشفرض عرض بیشتری را اختصاص میدهد. می توانید این رفتار را با فراخوانی API setUseBoundsForWidth
در TextView
فعال یا غیرفعال کنید.
از آنجایی که افزودن پد سمت چپ ممکن است باعث ایجاد ناهماهنگی در طرحبندیهای موجود شود، این پد بهطور پیشفرض حتی برای برنامههایی که Android 15 یا بالاتر را هدف قرار میدهند، اضافه نمیشود. با این حال، میتوانید با فراخوانی setShiftDrawingOffsetForStartOverhang
، بالشتک اضافی برای جلوگیری از بریدن اضافه کنید.
مثالهای زیر نشان میدهند که چگونه این تغییرات میتوانند طرحبندی متن را برای برخی از فونتها و زبانها بهبود بخشند.
ارتفاع خط پیشفرض آگاه از محلی برای EditText
در نسخههای قبلی اندروید، طرحبندی متن، ارتفاع متن را به اندازه ارتفاع خط فونتی که با منطقه فعلی مطابقت دارد، افزایش میداد. به عنوان مثال، اگر محتوا به زبان ژاپنی بود، چون ارتفاع خط فونت ژاپنی کمی بزرگتر از فونت لاتین است، ارتفاع متن کمی بزرگتر می شد. با این حال، علیرغم این تفاوتها در ارتفاع خط، عنصر EditText
بدون توجه به منطقه مورد استفاده، همانطور که در تصویر زیر نشان داده شده است، اندازه یکسانی داشت:
برای برنامههایی که Android 15 (سطح API 35) را هدف قرار میدهند، اکنون یک حداقل ارتفاع خط برای EditText
محفوظ است تا با فونت مرجع برای Locale مشخصشده مطابقت داشته باشد، همانطور که در تصویر زیر نشان داده شده است:
در صورت نیاز، برنامه شما میتواند رفتار قبلی را با تعیین ویژگی useLocalePreferredLineHeightForMinimum
به false
بازیابی کند، و برنامه شما میتواند حداقل معیارهای عمودی سفارشی را با استفاده از setMinimumFontMetrics
API در Kotlin و Java تنظیم کند.
دوربین و رسانه
Android 15 تغییرات زیر را در رفتار دوربین و رسانه برای برنامه هایی که اندروید 15 یا بالاتر را هدف قرار می دهند، اعمال می کند.
محدودیت در درخواست فوکوس صوتی
以 Android 15 为目标平台的应用必须是顶级应用或运行前台服务,才能请求音频焦点。如果应用在不符合其中任何一项要求时尝试请求焦点,该调用将返回 AUDIOFOCUS_REQUEST_FAILED
。
您可以参阅管理音频焦点,详细了解音频焦点。
محدودیتهای غیر SDK بهروزرسانی شد
Android 15 شامل لیست های به روز شده از رابط های غیر SDK محدود شده بر اساس همکاری با توسعه دهندگان اندروید و آخرین آزمایش داخلی است. در صورت امکان، قبل از اینکه رابطهای غیر SDK را محدود کنیم، مطمئن میشویم که جایگزینهای عمومی در دسترس هستند.
اگر برنامه شما اندروید 15 را هدف قرار نمی دهد، برخی از این تغییرات ممکن است فوراً روی شما تأثیر نگذارند. با این حال، در حالی که بسته به سطح API هدف برنامه شما، ممکن است برنامه شما به برخی از رابطهای غیر SDK دسترسی داشته باشد، استفاده از هر روش یا فیلد غیر SDK همیشه خطر شکستن برنامه شما را بالا میبرد.
اگر مطمئن نیستید که برنامه شما از رابط های غیر SDK استفاده می کند، می توانید برنامه خود را آزمایش کنید تا متوجه شوید. اگر برنامه شما به رابطهای غیر SDK متکی است، باید برنامهریزی برای انتقال به جایگزینهای SDK را شروع کنید. با این وجود، میدانیم که برخی از برنامهها دارای موارد استفاده معتبر برای استفاده از رابطهای غیر SDK هستند. اگر نمی توانید جایگزینی برای استفاده از یک رابط غیر SDK برای یک ویژگی در برنامه خود پیدا کنید، باید یک API عمومی جدید درخواست کنید .
如需详细了解此 Android 版本中的变更,请参阅 Android 15 中有关限制非 SDK 接口的更新。如需全面了解有关非 SDK 接口的详细信息,请参阅对非 SDK 接口的限制。