Giống như các bản phát hành trước, Android 15 có các thay đổi về hành vi có thể ảnh hưởng đến ứng dụng của bạn. Những thay đổi về hành vi sau đây chỉ áp dụng cho ứng dụng nhắm đến Android 15 trở lên. Nếu ứng dụng của bạn nhắm đến Android 15 trở lên, bạn nên điều chỉnh ứng dụng để hỗ trợ những hành vi này cho phù hợp (nếu cần).
Ngoài ra, hãy nhớ tham khảo danh sách thay đổi về hành vi ảnh hưởng đến tất cả ứng dụng chạy trên Android 15 bất kể targetSdkVersion của ứng dụng.
Chức năng cốt lõi
Android 15 sửa đổi hoặc mở rộng nhiều chức năng cốt lõi của hệ thống Android.
Thay đổi đối với dịch vụ nền trước
Chúng tôi sẽ thực hiện những thay đổi sau đây đối với các dịch vụ trên nền trước trong Android 15.
- Hành vi hết thời gian chờ của dịch vụ đồng bộ hoá dữ liệu trên nền trước
- Loại dịch vụ trên nền trước mới để xử lý nội dung nghe nhìn
- Các hạn chế đối với bộ thu phát sóng
BOOT_COMPLETEDkhởi chạy dịch vụ trên nền trước - Các hạn chế khi khởi động dịch vụ trên nền trước trong khi ứng dụng có quyền
SYSTEM_ALERT_WINDOW
Hành vi hết thời gian chờ của dịch vụ đồng bộ hoá dữ liệu trên nền trước
Android 15 giới thiệu một hành vi hết thời gian chờ mới cho dataSync đối với các ứng dụng nhắm đến Android 15 (API cấp 35) trở lên. Hành vi này cũng áp dụng cho loại dịch vụ trên nền trước mediaProcessing mới.
Hệ thống cho phép các dịch vụ dataSync của ứng dụng chạy tổng cộng 6 giờ trong khoảng thời gian 24 giờ. Sau đó, hệ thống sẽ gọi phương thức Service.onTimeout(int, int) của dịch vụ đang chạy (được giới thiệu trong Android 15). Tại thời điểm này, dịch vụ có vài giây để gọi Service.stopSelf(). Khi Service.onTimeout() được gọi, dịch vụ này không còn được coi là dịch vụ trên nền trước. Nếu dịch vụ không gọi Service.stopSelf(), hệ thống sẽ gửi một ngoại lệ nội bộ. Ngoại lệ được ghi lại trong Logcat với thông báo sau:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type dataSync did not stop within its timeout: [component name]"
Để tránh các vấn đề liên quan đến thay đổi về hành vi này, bạn có thể làm một hoặc nhiều việc sau:
- Yêu cầu dịch vụ triển khai phương thức
Service.onTimeout(int, int)mới. Khi ứng dụng của bạn nhận được lệnh gọi lại, hãy nhớ gọistopSelf()trong vài giây. (Nếu bạn không dừng ứng dụng ngay lập tức, hệ thống sẽ tạo lỗi.) - Đảm bảo các dịch vụ
dataSynccủa ứng dụng không chạy quá tổng cộng 6 giờ trong khoảng thời gian 24 giờ bất kỳ (trừ phi người dùng tương tác với ứng dụng, đặt lại bộ tính giờ). - Chỉ bắt đầu dịch vụ trên nền trước
dataSyncdo người dùng tương tác trực tiếp; vì ứng dụng của bạn đang ở nền trước khi dịch vụ bắt đầu, nên dịch vụ của bạn có đủ 6 giờ sau khi ứng dụng chuyển sang chế độ nền. - Thay vì sử dụng dịch vụ trên nền trước
dataSync, hãy sử dụng API thay thế.
Nếu các dịch vụ trên nền trước dataSync của ứng dụng đã chạy trong 6 giờ trong 24 giờ qua, thì bạn không thể bắt đầu một dịch vụ trên nền trước dataSync khác trừ phi người dùng đã đưa ứng dụng của bạn lên nền trước (điều này sẽ đặt lại bộ hẹn giờ). Nếu bạn cố gắng khởi động một dịch vụ trên nền trước dataSync khác, hệ thống sẽ gửi ForegroundServiceStartNotAllowedException kèm theo thông báo lỗi như "Đã hết thời gian giới hạn cho loại dịch vụ trên nền trước dataSync".
Thử nghiệm
Để kiểm thử hành vi của ứng dụng, bạn có thể bật thời gian chờ đồng bộ hoá dữ liệu ngay cả khi ứng dụng không nhắm đến Android 15 (miễn là ứng dụng đang chạy trên thiết bị Android 15). Để bật thời gian chờ, hãy chạy lệnh adb sau:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
Bạn cũng có thể điều chỉnh khoảng thời gian chờ để dễ dàng kiểm thử cách ứng dụng của bạn hoạt động khi đạt đến giới hạn. Để đặt khoảng thời gian chờ mới, hãy chạy lệnh adb sau:
adb shell device_config put activity_manager data_sync_fgs_timeout_duration duration-in-milliseconds
Loại dịch vụ trên nền trước mới để xử lý nội dung nghe nhìn
Android 15 giới thiệu một loại dịch vụ trên nền trước mới, mediaProcessing. Loại dịch vụ này phù hợp với các thao tác như chuyển mã tệp phương tiện. Ví dụ: một ứng dụng đa phương tiện có thể tải tệp âm thanh xuống và cần chuyển đổi tệp đó sang một định dạng khác trước khi phát. Bạn có thể sử dụng dịch vụ trên nền trước mediaProcessing để đảm bảo quá trình chuyển đổi sẽ tiếp tục ngay cả khi ứng dụng đang chạy trong nền.
Hệ thống cho phép các dịch vụ mediaProcessing của ứng dụng chạy tổng cộng 6 giờ trong khoảng thời gian 24 giờ, sau đó hệ thống sẽ gọi phương thức Service.onTimeout(int, int) của dịch vụ đang chạy (được giới thiệu trong Android 15). Tại thời điểm này, dịch vụ có vài giây để gọi Service.stopSelf(). Nếu dịch vụ không gọi Service.stopSelf(), hệ thống sẽ gửi một ngoại lệ nội bộ. Ngoại lệ được ghi lại trong Logcat với thông báo sau:
Fatal Exception: android.app.RemoteServiceException: "A foreground service of
type mediaProcessing did not stop within its timeout: [component name]"
Để tránh trường hợp ngoại lệ này, bạn có thể làm theo một trong những cách sau:
- Yêu cầu dịch vụ của bạn triển khai phương thức
Service.onTimeout(int, int)mới. Khi ứng dụng của bạn nhận được lệnh gọi lại, hãy nhớ gọistopSelf()trong vòng vài giây. (Nếu bạn không dừng ứng dụng ngay lập tức, hệ thống sẽ tạo lỗi.) - Đảm bảo các dịch vụ
mediaProcessingcủa ứng dụng không chạy quá tổng cộng 6 giờ trong khoảng thời gian 24 giờ bất kỳ (trừ phi người dùng tương tác với ứng dụng, đặt lại bộ tính giờ). - Chỉ bắt đầu dịch vụ trên nền trước
mediaProcessingdo người dùng tương tác trực tiếp; vì ứng dụng của bạn đang ở nền trước khi dịch vụ bắt đầu, nên dịch vụ của bạn có đủ 6 giờ sau khi ứng dụng chuyển sang chế độ nền. - Thay vì dùng dịch vụ trên nền trước
mediaProcessing, hãy dùng một API thay thế, chẳng hạn như WorkManager.
Nếu các dịch vụ trên nền trước mediaProcessing của ứng dụng đã chạy được 6 giờ trong 24 ngày qua, thì bạn không thể bắt đầu một dịch vụ trên nền trước mediaProcessing khác trừ phi người dùng đã đưa ứng dụng của bạn lên nền trước (việc này đặt lại bộ tính giờ). Nếu bạn cố gắng bắt đầu một dịch vụ trên nền trước mediaProcessing khác, hệ thống sẽ gửi ForegroundServiceStartNotAllowedException kèm theo thông báo lỗi như "Hết thời gian giới hạn cho loại dịch vụ trên nền trước mediaProcessing".
Để biết thêm thông tin về loại dịch vụ mediaProcessing, hãy xem phần Thay đổi đối với loại dịch vụ trên nền trước cho Android 15: Xử lý nội dung nghe nhìn.
Thử nghiệm
Để kiểm thử hành vi của ứng dụng, bạn có thể bật thời gian chờ xử lý nội dung nghe nhìn ngay cả khi ứng dụng của bạn không nhắm đến Android 15 (miễn là ứng dụng đang chạy trên thiết bị Android 15). Để bật tính năng thời gian chờ, hãy chạy lệnh adb sau:
adb shell am compat enable FGS_INTRODUCE_TIME_LIMITS your-package-name
Bạn cũng có thể điều chỉnh khoảng thời gian chờ để dễ dàng kiểm thử cách ứng dụng của bạn hoạt động khi đạt đến giới hạn. Để đặt khoảng thời gian chờ mới, hãy chạy lệnh adb sau:
adb shell device_config put activity_manager media_processing_fgs_timeout_duration duration-in-milliseconds
Các hạn chế đối với bộ nhận thông báo truyền tin BOOT_COMPLETED khởi chạy dịch vụ trên nền trước
在启动 BOOT_COMPLETED 广播接收器方面存在新限制
前台服务。BOOT_COMPLETED 接收器不能启动
以下类型的前台服务：
dataSynccameramediaPlaybackphoneCallmediaProjectionmicrophone（自 Android 14 起，microphone就受到此限制）
如果 BOOT_COMPLETED 接收器尝试启动任何上述类型的前台
服务，系统会抛出 ForegroundServiceStartNotAllowedException。
测试
如需测试应用的行为，您可以启用这些新限制，即使您的应用并未以 Android 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
Các hạn chế về việc khởi động dịch vụ trên nền trước khi ứng dụng có quyền SYSTEM_ALERT_WINDOW
Trước đây, nếu có quyền SYSTEM_ALERT_WINDOW, ứng dụng có thể chạy một dịch vụ trên nền trước ngay cả khi ứng dụng đó đang chạy ở chế độ nền (như đã thảo luận trong phần các trường hợp miễn trừ khỏi các quy định hạn chế về việc bắt đầu ở chế độ nền).
Nếu một ứng dụng nhắm đến Android 15, thì trường hợp miễn trừ này hiện sẽ hẹp hơn. Ứng dụng hiện cần có quyền SYSTEM_ALERT_WINDOW và cũng có một cửa sổ lớp phủ hiển thị. Tức là trước tiên, ứng dụng cần khởi chạy cửa sổ TYPE_APPLICATION_OVERLAY và cửa sổ đó cần hiển thị trước khi bạn bắt đầu dịch vụ trên nền trước.
Nếu ứng dụng của bạn cố gắng bắt đầu một dịch vụ trên nền trước từ chế độ nền mà không đáp ứng các yêu cầu mới này (và không có một số trường hợp ngoại lệ khác), thì hệ thống sẽ gửi ForegroundServiceStartNotAllowedException.
Nếu ứng dụng của bạn khai báo quyền SYSTEM_ALERT_WINDOW và chạy các dịch vụ trên nền trước từ chế độ nền, thì ứng dụng đó có thể bị ảnh hưởng bởi thay đổi này. Nếu ứng dụng của bạn nhận được ForegroundServiceStartNotAllowedException, hãy kiểm tra thứ tự hoạt động của ứng dụng và đảm bảo ứng dụng đã có cửa sổ lớp phủ đang hoạt động trước khi ứng dụng đó cố gắng bắt đầu một dịch vụ trên nền trước từ chế độ nền. Bạn có thể kiểm tra xem cửa sổ lớp phủ của mình hiện có hiển thị hay không bằng cách gọi View.getWindowVisibility() hoặc bạn có thể ghi đè View.onWindowVisibilityChanged() để nhận thông báo bất cứ khi nào chế độ hiển thị thay đổi.
Thử nghiệm
Để kiểm thử hành vi của ứng dụng, bạn có thể bật các quy định hạn chế mới này ngay cả khi ứng dụng của bạn không nhắm đến Android 15 (miễn là ứng dụng đang chạy trên thiết bị Android 15). Để bật các hạn chế mới này khi khởi động dịch vụ trên nền trước từ chế độ nền, hãy chạy lệnh adb sau:
adb shell am compat enable FGS_SAW_RESTRICTIONS your-package-name
Thay đổi về thời điểm ứng dụng có thể sửa đổi trạng thái chung của chế độ Không làm phiền
Các ứng dụng nhắm đến Android 15 (API cấp 35) trở lên không thể thay đổi trạng thái hoặc chính sách chung của chế độ Không làm phiền (DND) trên thiết bị nữa (bằng cách sửa đổi chế độ cài đặt của người dùng hoặc tắt chế độ DND). Thay vào đó, ứng dụng phải đóng góp một AutomaticZenRule. Hệ thống sẽ kết hợp chính sách này vào một chính sách chung với lược đồ hiện có là chính sách hạn chế nhất sẽ thắng. Các lệnh gọi đến các API hiện có từng ảnh hưởng đến trạng thái toàn cục (setInterruptionFilter, setNotificationPolicy) sẽ dẫn đến việc tạo hoặc cập nhật một AutomaticZenRule ngầm ẩn. Lệnh gọi này được bật và tắt tuỳ thuộc vào chu kỳ gọi của các lệnh gọi API đó.
Xin lưu ý rằng thay đổi này chỉ ảnh hưởng đến hành vi có thể quan sát được nếu ứng dụng đang gọi setInterruptionFilter(INTERRUPTION_FILTER_ALL) và dự kiến lệnh gọi đó sẽ huỷ kích hoạt AutomaticZenRule mà chủ sở hữu của ứng dụng đã kích hoạt trước đó.
Thay đổi về API OpenJDK
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]);语言代码处理方式变更：使用
LocaleAPI 时，希伯来语、意第绪语和印度尼西亚语的语言代码不再转换为其过时形式（希伯来语：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()）静态解析为新的ListAPI，而不是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 插件中的现有
NewApilint 选项可以捕获这些新的 API 用法。./gradlew lintMainActivity.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.javaMyList.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.javaMyList.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.javaMyList.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(); }
Bảo mật
Android 15 có những thay đổi giúp tăng cường bảo mật hệ thống để bảo vệ ứng dụng và người dùng khỏi các ứng dụng độc hại.
Các phiên bản TLS bị hạn chế
Android 15 hạn chế việc sử dụng TLS phiên bản 1.0 và 1.1. Các phiên bản này trước đây đã ngừng hoạt động trong Android, nhưng hiện không được phép sử dụng cho các ứng dụng nhắm đến Android 15.
Khởi chạy hoạt động ở chế độ nền một cách an toàn
Android 15 bảo vệ người dùng khỏi các ứng dụng độc hại và giúp họ kiểm soát thiết bị của mình tốt hơn bằng cách thêm những thay đổi ngăn các ứng dụng độc hại ở chế độ nền đưa các ứng dụng khác lên nền trước, nâng cao đặc quyền và lợi dụng hoạt động tương tác của người dùng. Hoạt động khởi chạy ở chế độ nền đã bị hạn chế kể từ Android 10 (API cấp 29).
Các thay đổi khác
- Thay đổi để theo mặc định,
PendingIntentngười tạo sẽ chặn hoạt động khởi chạy trong nền. Điều này giúp ngăn các ứng dụng vô tình tạo ra mộtPendingIntentmà đối tượng xấu có thể lợi dụng. - Không đưa ứng dụng lên nền trước, trừ phi người gửi
PendingIntentcho phép. Thay đổi này nhằm mục đích ngăn các ứng dụng độc hại lợi dụng khả năng bắt đầu các hoạt động ở chế độ nền. Theo mặc định, các ứng dụng không được phép đưa ngăn xếp tác vụ lên nền trước, trừ phi người tạo cho phép đặc quyền khởi chạy hoạt động ở chế độ nền hoặc người gửi có đặc quyền khởi chạy hoạt động ở chế độ nền. - Kiểm soát cách hoạt động hàng đầu của ngăn xếp tác vụ có thể hoàn thành tác vụ của mình. Nếu hoạt động hàng đầu hoàn tất một tác vụ, Android sẽ quay lại tác vụ hoạt động gần đây nhất. Ngoài ra, nếu một hoạt động không phải là hoạt động hàng đầu hoàn tất tác vụ của mình, thì Android sẽ quay lại màn hình chính; hệ thống sẽ không chặn quá trình hoàn tất của hoạt động không phải là hoạt động hàng đầu này.
- Ngăn chặn việc chạy các hoạt động tuỳ ý từ các ứng dụng khác vào tác vụ của riêng bạn. Thay đổi này ngăn các ứng dụng độc hại lừa đảo người dùng bằng cách tạo các hoạt động có vẻ như đến từ các ứng dụng khác.
- Chặn các cửa sổ không hiển thị được xem xét để khởi chạy hoạt động trong nền. Điều này giúp ngăn chặn các ứng dụng độc hại lợi dụng hoạt động khởi chạy ở chế độ nền để hiển thị nội dung không mong muốn hoặc độc hại cho người dùng.
Ý định an toàn hơn
Android 15 giới thiệu StrictMode cho các ý định.
Để xem nhật ký chi tiết về các lỗi vi phạm khi sử dụng Intent, hãy sử dụng phương thức sau:
Kotlin
fun onCreate() { StrictMode.setVmPolicy(VmPolicy.Builder() .detectUnsafeIntentLaunch() .build() ) }
Java
public void onCreate() { StrictMode.setVmPolicy(new VmPolicy.Builder() .detectUnsafeIntentLaunch() .build()); }
Trải nghiệm người dùng và giao diện người dùng hệ thống
Android 15 có một số thay đổi nhằm tạo ra trải nghiệm người dùng nhất quán và trực quan hơn.
Thay đổi lồng ghép cửa sổ
Có hai thay đổi liên quan đến phần lồng ghép cửa sổ trong Android 15: chế độ tràn viền được thực thi theo mặc định và cũng có các thay đổi về cấu hình, chẳng hạn như cấu hình mặc định của các thanh hệ thống.
Thực thi chi tiết
Theo mặc định, ứng dụng sẽ hiển thị tràn viền trên các thiết bị chạy Android 15 nếu ứng dụng đó nhắm đến Android 15 (cấp độ API 35).
Đây là một thay đổi có thể gây lỗi và ảnh hưởng tiêu cực đến giao diện người dùng của ứng dụng. Những thay đổi này ảnh hưởng đến các khu vực giao diện người dùng sau:
- Thanh điều hướng bằng cử chỉ
- Trong suốt theo mặc định.
- Phần bù trừ dưới cùng bị tắt nên nội dung sẽ nằm phía sau thanh điều hướng của hệ thống, trừ phi áp dụng phần lồng ghép.
setNavigationBarColorvàR.attr#navigationBarColorkhông còn được dùng nữa và không ảnh hưởng đến điều hướng bằng cử chỉ.setNavigationBarContrastEnforcedvàR.attr#navigationBarContrastEnforcedtiếp tục không ảnh hưởng đến điều hướng bằng cử chỉ.
- Thao tác bằng 3 nút
- Độ mờ được đặt thành 80% theo mặc định, với màu có thể khớp với nền cửa sổ.
- Đã tắt độ lệch dưới cùng để nội dung nằm phía sau thanh điều hướng hệ thống, trừ phi áp dụng phần lồng ghép.
setNavigationBarColorvàR.attr#navigationBarColorđược đặt để khớp với nền cửa sổ theo mặc định. Nền cửa sổ phải là một đối tượng có thể vẽ màu để áp dụng giá trị mặc định này. API này không còn được dùng nữa nhưng vẫn ảnh hưởng đến chế độ thao tác bằng 3 nút.setNavigationBarContrastEnforcedvàR.attr#navigationBarContrastEnforcedlà true theo mặc định, giúp thêm một nền mờ 80% trên chế độ thao tác bằng 3 nút.
- Thanh trạng thái
- Trong suốt theo mặc định.
- Phần bù trừ trên cùng bị tắt nên nội dung sẽ nằm phía sau thanh trạng thái, trừ phi áp dụng phần lồng ghép.
setStatusBarColorvàR.attr#statusBarColorkhông còn được dùng nữa và không có hiệu lực trên Android 15.setStatusBarContrastEnforcedvàR.attr#statusBarContrastEnforcedkhông còn được dùng nữa nhưng vẫn có hiệu lực trên Android 15.
- Vết cắt trên màn hình
layoutInDisplayCutoutModecủa cửa sổ không nổi phải làLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS.SHORT_EDGES,NEVERvàDEFAULTđược diễn giải làALWAYSđể người dùng không thấy thanh màu đen do vết cắt trên màn hình gây ra và xuất hiện tràn viền.
Ví dụ sau đây cho thấy một ứng dụng trước và sau khi nhắm đến Android 15 (cấp độ API 35), cũng như trước và sau khi áp dụng các phần lồng ghép. Ví dụ này không đầy đủ, có thể xuất hiện khác trên Android Auto.
Những điều cần kiểm tra nếu ứng dụng của bạn đã tràn viền
Nếu ứng dụng của bạn đã tràn viền và áp dụng các phần lồng ghép, thì bạn hầu như không bị ảnh hưởng, ngoại trừ trong các trường hợp sau. Tuy nhiên, ngay cả khi bạn cho rằng mình không bị ảnh hưởng, bạn vẫn nên kiểm thử ứng dụng.
- Bạn có một cửa sổ không nổi, chẳng hạn như
Activitysử dụngSHORT_EDGES,NEVERhoặcDEFAULTthay vìLAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYS. Nếu ứng dụng của bạn gặp sự cố khi khởi chạy, thì có thể là do màn hình chờ. Bạn có thể nâng cấp phần phụ thuộc core splashscreen lên phiên bản 1.2.0-alpha01 trở lên hoặc đặtwindow.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always. - Có thể có những màn hình có lưu lượng truy cập thấp hơn với giao diện người dùng bị che khuất. Xác minh rằng những màn hình ít được truy cập này không có giao diện người dùng bị che khuất. Các màn hình có lưu lượng truy cập thấp hơn bao gồm:
- Màn hình giới thiệu hoặc màn hình đăng nhập
- Trang cài đặt
Những điều cần kiểm tra nếu ứng dụng của bạn chưa tràn viền
Nếu ứng dụng của bạn chưa tràn viền, thì rất có thể ứng dụng đó sẽ bị ảnh hưởng. Ngoài các trường hợp dành cho ứng dụng đã tràn viền, bạn nên cân nhắc những điều sau:
- Nếu ứng dụng của bạn dùng các thành phần Material 3 (
androidx.compose.material3) trong Compose, chẳng hạn nhưTopAppBar,BottomAppBarvàNavigationBar, thì các thành phần này có thể không bị ảnh hưởng vì chúng tự động xử lý phần lồng ghép. - Nếu ứng dụng của bạn dùng các Thành phần Material 2 (
androidx.compose.material) trong Compose, thì các thành phần này sẽ không tự động xử lý phần lồng ghép. Tuy nhiên, bạn có thể truy cập vào những phần lồng ghép này và áp dụng chúng theo cách thủ công. Trong androidx.compose.material 1.6.0 trở lên, hãy dùng tham sốwindowInsetsđể áp dụng phần lồng ghép theo cách thủ công choBottomAppBar,TopAppBar,BottomNavigationvàNavigationRail. Tương tự, hãy dùng tham sốcontentWindowInsetschoScaffold. - Nếu ứng dụng của bạn dùng các thành phần Khung hiển thị và Material (
com.google.android.material), thì hầu hết thành phần Material dựa trên Khung hiển thị (chẳng hạn nhưBottomNavigationView,BottomAppBar,NavigationRailViewhoặcNavigationView) sẽ xử lý phần lồng ghép nên bạn không cần phải làm gì thêm. Tuy nhiên, bạn cần phải thêmandroid:fitsSystemWindows="true"nếu dùngAppBarLayout. - Đối với các thành phần kết hợp tuỳ chỉnh, hãy áp dụng phần lồng ghép theo cách thủ công như khoảng đệm. Nếu nội dung của bạn nằm trong
Scaffold, bạn có thể sử dụng các phần lồng ghép bằng cách dùng giá trị khoảng đệmScaffold. Nếu không, hãy áp dụng khoảng đệm bằng một trong cácWindowInsets. - Nếu ứng dụng của bạn dùng khung hiển thị
BottomSheet,SideSheethoặc các vùng chứa tuỳ chỉnh, hãy áp dụng khoảng đệm bằngViewCompat.setOnApplyWindowInsetsListener. Đối vớiRecyclerView, hãy áp dụng khoảng đệm bằng trình nghe này, đồng thời thêmclipToPadding="false".
Những điều cần kiểm tra nếu ứng dụng của bạn phải cung cấp biện pháp bảo vệ tuỳ chỉnh ở chế độ nền
Nếu ứng dụng của bạn phải cung cấp tính năng bảo vệ nền tuỳ chỉnh cho thao tác bằng 3 nút hoặc thanh trạng thái, thì ứng dụng đó phải đặt một composable hoặc khung hiển thị phía sau thanh hệ thống bằng cách sử dụng WindowInsets.Type#tappableElement() để lấy chiều cao của thanh điều hướng 3 nút hoặc WindowInsets.Type#statusBars.
Tài nguyên bổ sung về chế độ tràn viền
Hãy xem hướng dẫn về Chế độ xem tràn viền và Thành phần kết hợp tràn viền để biết thêm các điểm cần cân nhắc khi áp dụng phần lồng ghép.
API không dùng nữa
Các API sau đây không còn được dùng nữa nhưng chưa bị vô hiệu hoá:
R.attr#enforceStatusBarContrastR.attr#navigationBarColor(đối với thao tác bằng 3 nút, có độ trong suốt 80%)Window#isStatusBarContrastEnforcedWindow#setNavigationBarColor(đối với thao tác bằng 3 nút, có độ mờ 80%)Window#setStatusBarContrastEnforced
Các API sau đây không còn được dùng nữa và đã bị vô hiệu hoá:
R.attr#navigationBarColor(để điều hướng bằng cử chỉ)R.attr#navigationBarDividerColorR.attr#statusBarColorWindow#setDecorFitsSystemWindowsWindow#getNavigationBarColorWindow#getNavigationBarDividerColorWindow#getStatusBarColorWindow#setNavigationBarColor(để điều hướng bằng cử chỉ)Window#setNavigationBarDividerColorWindow#setStatusBarColor
Cấu hình ổn định
如果您的应用以 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()就已经采用这种工作方式。
thuộc tính elegantTextHeight mặc định là true
Đối với các ứng dụng nhắm đến Android 15 (API cấp 35), thuộc tính elegantTextHeight TextView sẽ trở thành true theo mặc định, thay thế phông chữ thu gọn được sử dụng theo mặc định bằng một số tập lệnh có các chỉ số dọc lớn bằng một tập lệnh dễ đọc hơn nhiều.
Phông chữ nhỏ gọn được giới thiệu để ngăn các bố cục bị phá vỡ; Android 13 (API cấp 33) ngăn chặn nhiều sự cố này bằng cách cho phép bố cục văn bản kéo giãn chiều cao theo chiều dọc bằng cách sử dụng thuộc tính fallbackLineSpacing.
Trong Android 15, phông chữ thu gọn vẫn còn trong hệ thống, vì vậy, ứng dụng của bạn có thể đặt elegantTextHeight thành false để có cùng hành vi như trước, nhưng có thể sẽ không được hỗ trợ trong các bản phát hành sắp tới. Vì vậy, nếu ứng dụng của bạn hỗ trợ các tập lệnh sau: tiếng Ả Rập, tiếng Lào, tiếng Myanmar, tiếng Tamil, tiếng Gujarati, tiếng Kannada, tiếng Malayalam, tiếng Odia, tiếng Telugu hoặc tiếng Thái, hãy kiểm thử ứng dụng bằng cách đặt elegantTextHeight thành true.
elegantTextHeight của 
đối với các ứng dụng nhắm đến Android 14 (API cấp 34) trở xuống.
elegantTextHeight hành vi cho các ứng dụng nhắm đến Android 15.Chiều rộng TextView thay đổi đối với các hình dạng chữ cái phức tạp
在以前的 Android 版本中，某些具有复杂形状的手写字体或语言可能会在上一个或下一个字符的区域绘制字母。在某些情况下，此类字母会在开头或结尾处被剪裁。从 Android 15 开始，TextView 会分配宽度，以便为此类字母绘制足够的空间，并允许应用请求向左额外添加内边距以防止剪裁。
由于此更改会影响 TextView 确定宽度的方式，因此如果应用以 Android 15（API 级别 35）或更高版本为目标平台，TextView 会默认分配更多宽度。您可以通过对 TextView 调用 setUseBoundsForWidth API 来启用或停用此行为。
由于添加左内边距可能会导致现有布局未对齐，因此默认情况下不会添加内边距，即使以 Android 15 或更高版本为目标平台的应用也是如此。不过，您可以通过调用 setShiftDrawingOffsetForStartOverhang 添加额外的内边距以防止剪裁。
以下示例展示了这些更改如何改进某些字体和语言的文本布局。
<TextView android:fontFamily="cursive" android:text="java" />
<TextView android:fontFamily="cursive" android:text="java" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
<TextView android:text="คอมพิวเตอร์" />
<TextView android:text="คอมพิวเตอร์" android:useBoundsForWidth="true" android:shiftDrawingOffsetForStartOverhang="true" />
Chiều cao dòng mặc định theo ngôn ngữ cho EditText
Trong các phiên bản Android trước, bố cục văn bản đã kéo giãn chiều cao của văn bản để đáp ứng chiều cao dòng của phông chữ khớp với ngôn ngữ hiện tại. Ví dụ: nếu nội dung bằng tiếng Nhật, thì chiều cao dòng của phông chữ tiếng Nhật sẽ lớn hơn một chút so với chiều cao dòng của phông chữ Latinh, do đó chiều cao của văn bản sẽ lớn hơn một chút. Tuy nhiên, mặc dù có sự khác biệt về chiều cao dòng, nhưng phần tử EditText được định cỡ đồng nhất, bất kể ngôn ngữ đang được sử dụng, như minh hoạ trong hình sau:
EditText có thể chứa văn bản bằng tiếng Anh (en), tiếng Nhật (ja) và tiếng Miến Điện (my). Chiều cao của EditText là như nhau, mặc dù các ngôn ngữ này có chiều cao dòng khác nhau.Đối với các ứng dụng nhắm đến Android 15 (API cấp 35), chiều cao dòng tối thiểu hiện được dành riêng cho EditText để khớp với phông chữ tham chiếu cho Ngôn ngữ được chỉ định, như minh hoạ trong hình sau:
EditText có thể chứa văn bản bằng tiếng Anh (en), tiếng Nhật (ja) và tiếng Miến Điện (my). Chiều cao của EditText hiện bao gồm khoảng trống để phù hợp với chiều cao dòng mặc định cho phông chữ của các ngôn ngữ này.Nếu cần, ứng dụng của bạn có thể khôi phục hành vi trước đó bằng cách chỉ định thuộc tính useLocalePreferredLineHeightForMinimum thành false và ứng dụng có thể đặt các chỉ số dọc tối thiểu tuỳ chỉnh bằng API setMinimumFontMetrics trong Kotlin và Java.
Camera và nội dung nghe nhìn
Android 15 có những thay đổi sau đây đối với hành vi của camera và nội dung nghe nhìn cho các ứng dụng nhắm đến Android 15 trở lên.
Các quy định hạn chế về việc yêu cầu quyền phát âm thanh
Các ứng dụng nhắm đến Android 15 (API cấp 35) phải là ứng dụng hàng đầu hoặc đang chạy một dịch vụ trên nền trước để yêu cầu quyền phát âm thanh. Nếu một ứng dụng cố gắng yêu cầu tiêu điểm khi không đáp ứng một trong các yêu cầu này, thì lệnh gọi sẽ trả về AUDIOFOCUS_REQUEST_FAILED.
Bạn có thể tìm hiểu thêm về quyền phát âm thanh tại phần Quản lý quyền phát âm thanh.
Các quy tắc hạn chế mới cập nhật đối với yếu tố ngoài SDK
Android 15 cung cấp danh sách mới cập nhật về các giao diện không phải SDK bị hạn chế dựa trên khả năng cộng tác với nhà phát triển Android và kiểm thử nội bộ mới nhất. Bất cứ khi nào có thể, chúng tôi phải đảm bảo việc cung cấp các phương án thay thế công khai trước khi hạn chế giao diện không phải SDK.
Nếu ứng dụng của bạn không nhắm đến Android 15, thì một số thay đổi này có thể sẽ không ảnh hưởng ngay. Tuy nhiên, mặc dù ứng dụng của bạn có thể truy cập vào một số giao diện không phải SDK tuỳ thuộc vào cấp độ API mục tiêu của ứng dụng, nhưng việc sử dụng phương thức hoặc trường không phải SDK luôn có nguy cơ cao làm hỏng ứng dụng.
Nếu không chắc ứng dụng của mình có sử dụng giao diện không phải SDK hay không, bạn có thể kiểm tra ứng dụng để tìm hiểu. Nếu ứng dụng của bạn dựa vào giao diện không phải SDK, thì bạn nên bắt đầu lập kế hoạch di chuyển sang SDK làm giải pháp thay thế. Tuy nhiên, chúng tôi hiểu rằng vẫn có một số trường hợp sử dụng hợp lệ cho việc ứng dụng sử dụng giao diện không phải SDK. Nếu không tìm được giải pháp thay thế cho việc sử dụng giao diện không phải SDK đối với một tính năng trong ứng dụng, thì bạn nên yêu cầu một API công khai mới.
Để tìm hiểu thêm về những thay đổi trong bản phát hành Android này, hãy xem bài viết Thông tin cập nhật đối với những hạn chế về giao diện không phải SDK trong Android 15. Để tìm hiểu thêm về giao diện không phải SDK, hãy xem bài viết Các hạn chế đối với giao diện không phải SDK.