Thay đổi về hành vi: Ứng dụng nhắm đến Android 15 trở lên

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 các 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ụ trên 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

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:

  1. 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ọi stopSelf() 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.)
  2. Đảm bảo các dịch vụ dataSync củ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ờ).
  3. Chỉ bắt đầu dịch vụ trên nền trước dataSync do 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.
  4. 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:

  1. 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ọi stopSelf() 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.)
  2. Đảm bảo các dịch vụ mediaProcessing củ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ờ).
  3. Chỉ bắt đầu dịch vụ trên nền trước mediaProcessing do 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.
  4. 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 接收器能启动 以下类型的前台服务:

如果 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

以前,如果应用拥有 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

Những thay đổi về thời điểm các ứ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 đó.

Các thay đổi về API của OpenJDK

Android 15 tiếp tục công cuộc làm mới các thư viện cốt lõi của Android để phù hợp với các tính năng trong bản phát hành LTS OpenJDK mới nhất.

Một số thay đổi sau đây có thể ảnh hưởng đến khả năng tương thích của ứng dụng đối với những ứng dụng nhắm đến Android 15 (API cấp 35):

  • Thay đổi đối với các API định dạng chuỗi: Giờ đây, việc xác thực chỉ mục đối số, cờ, chiều rộng và độ chính xác sẽ nghiêm ngặt hơn khi bạn dùng các API String.format()Formatter.format() sau đây:

    Ví dụ: ngoại lệ sau sẽ được gửi khi chỉ mục đối số là 0 (%0 trong chuỗi định dạng):

    IllegalFormatArgumentIndexException: Illegal format argument index = 0
    

    Trong trường hợp này, bạn có thể khắc phục vấn đề bằng cách sử dụng chỉ mục đối số là 1 (%1 trong chuỗi định dạng).

  • Thay đổi đối với loại thành phần của Arrays.asList(...).toArray(): Khi sử dụng Arrays.asList(...).toArray(), loại thành phần của mảng kết quả hiện là Object, chứ không phải loại của các phần tử trong mảng cơ bản. Vì vậy, mã sau đây sẽ gửi một ClassCastException:

    String[] elements = (String[]) Arrays.asList("one", "two").toArray();
    

    Trong trường hợp này, để giữ String làm loại thành phần trong mảng kết quả, bạn có thể sử dụng Collection.toArray(Object[]):

    String[] elements = Arrays.asList("two", "one").toArray(new String[0]);
    
  • Các thay đổi đối với việc xử lý mã ngôn ngữ: Khi sử dụng API Locale, mã ngôn ngữ cho tiếng Do Thái, tiếng Yiddish và tiếng Indonesia sẽ không còn được chuyển đổi sang các dạng thức cũ (tiếng Do Thái: iw, tiếng Yiddish: ji và tiếng Indonesia: in). Khi chỉ định mã ngôn ngữ cho một trong các ngôn ngữ này, hãy sử dụng mã theo tiêu chuẩn ISO 639-1 (tiếng Do Thái: he, tiếng Yiddish: yi và tiếng Indonesia: id).

  • Các thay đổi đối với chuỗi số nguyên ngẫu nhiên: Sau các thay đổi được thực hiện trong https://bugs.openjdk.org/browse/JDK-8301574, các phương thức Random.ints() sau đây hiện trả về một chuỗi số khác với các phương thức Random.nextInt():

    Nhìn chung, thay đổi này sẽ không dẫn đến hành vi làm hỏng ứng dụng, nhưng mã của bạn không được mong đợi trình tự được tạo từ các phương thức Random.ints() khớp với Random.nextInt().

API SequencedCollection mới có thể ảnh hưởng đến khả năng tương thích của ứng dụng sau khi bạn cập nhật compileSdk trong cấu hình bản dựng của ứng dụng để sử dụng Android 15 (API cấp 35):

  • Xung đột với các hàm mở rộng MutableList.removeFirst()MutableList.removeLast() trong kotlin-stdlib

    Loại List trong Java được ánh xạ đến loại MutableList trong Kotlin. Vì các API List.removeFirst()List.removeLast() đã được ra mắt trong Android 15 (API cấp 35), nên trình biên dịch Kotlin sẽ giải quyết các lệnh gọi hàm (ví dụ: list.removeFirst()) một cách tĩnh đến các API List mới thay vì đến các hàm mở rộng trong kotlin-stdlib.

    Nếu một ứng dụng được biên dịch lại với compileSdk được đặt thành 35minSdk được đặt thành 34 trở xuống, rồi ứng dụng đó chạy trên Android 14 trở xuống, thì sẽ xảy ra lỗi thời gian chạy:

    java.lang.NoSuchMethodError: No virtual method
    removeFirst()Ljava/lang/Object; in class Ljava/util/ArrayList;
    

    Lựa chọn NewApi lint hiện có trong Trình bổ trợ Android cho Gradle có thể phát hiện những cách sử dụng API mới này.

    ./gradlew lint
    
    MainActivity.kt:41: Error: Call requires API level 35 (current min is 34): java.util.List#removeFirst [NewApi]
          list.removeFirst()
    

    Để khắc phục ngoại lệ thời gian chạy và lỗi lint, bạn có thể thay thế các lệnh gọi hàm removeFirst()removeLast() bằng removeAt(0)removeAt(list.lastIndex) tương ứng trong Kotlin. Nếu bạn đang sử dụng Android Studio Ladybug | 2024.1.3 trở lên, thì phiên bản này cũng cung cấp lựa chọn sửa nhanh cho những lỗi này.

    Hãy cân nhắc việc xoá @SuppressLint("NewApi")lintOptions { disable 'NewApi' } nếu bạn đã tắt lựa chọn lint.

  • Xung đột với các phương thức khác trong Java

    Các phương thức mới đã được thêm vào các loại hiện có, ví dụ: ListDeque. Những phương thức mới này có thể không tương thích với các phương thức có cùng tên và kiểu đối số trong các giao diện và lớp khác. Trong trường hợp xảy ra xung đột chữ ký phương thức với sự không tương thích, trình biên dịch javac sẽ xuất ra lỗi thời gian tạo. Ví dụ:

    Ví dụ về lỗi 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
    

    Ví dụ về lỗi 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
    

    Ví dụ về lỗi 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
    

    Để khắc phục những lỗi này khi tạo bản dựng, lớp triển khai các giao diện này phải ghi đè phương thức bằng một kiểu dữ liệu trả về tương thích. Ví dụ:

    @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 tính bảo mật của 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 trong 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 các thay đổi ngăn ứ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. Các hoạt động chạy trong nền đã bị hạn chế kể từ Android 10 (API cấp 29).

Các thay đổi khác

Ngoài quy định hạn chế về việc so khớp UID, còn có các thay đổi khác sau đây:

  • Thay đổi trình tạo PendingIntent để chặn các lần khởi chạy hoạt động trong nền theo mặc định. Điều này giúp ngăn các ứng dụng vô tình tạo một PendingIntent mà các đối tượng độc hại có thể lợi dụng.
  • Đừng đưa ứng dụng lên nền trước trừ phi trình gửi PendingIntent cho phép. Thay đổi này nhằm ngăn các ứng dụng độc hại lợi dụng khả năng bắt đầu 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 nhà sáng 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 trên cùng của ngăn xếp tác vụ có thể hoàn thành tác vụ đó. Nếu hoạt động trên cùng hoàn tất một tác vụ, Android sẽ quay lại bất kỳ tác vụ nào hoạt động gần đây nhất. Hơn nữa, nếu một hoạt động không ở trên cùng hoàn tất tác vụ của nó, Android sẽ quay lại màn hình chính; nó sẽ không chặn việc kết thúc quảng cáo không phải trên cùng này của bạn.
  • Ngă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 chặn các ứng dụng độc hại tấn công người dùng bằng cách tạo những hoạt động có vẻ như từ các ứng dụng khác.
  • Chặn để các cửa sổ không hiển thị không được xem xét về hoạt động ở chế độ nền . Điều này giúp ngăn các ứng dụng độc hại lợi dụng việc khởi chạy hoạt động ở 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 引入了新的可选安全措施,以提高 intent 的安全性 和更强大的模型。这些变更旨在防范潜在的漏洞, 可能会被恶意应用利用的 intent 滥用。Android 15 对 intent 的安全性进行了两项主要改进:

  • 匹配目标 intent 过滤器:针对特定组件的 intent 准确匹配目标的 intent 过滤器规范。如果您发送 intent 来启动另一个应用的 activity,则目标 intent 组件需要 与接收 activity 声明的 intent 过滤器保持一致。
  • intent 必须包含操作:不含操作的 intent 将不再与任何 intent 过滤器匹配。也就是说,用于启动 activity 或 服务都必须有明确定义的操作。

要检查应用如何响应这些更改,请使用 StrictMode。要查看详细的 关于 Intent 使用违规行为的日志,请添加以下方法:

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 mang đến trải nghiệm người dùng nhất quán và trực quan hơn.

Thay đổi phần 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

如果应用以 Android 15(API 级别 35)为目标平台,则在搭载 Android 15 的设备上默认以无边框显示。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。


以 Android 15(API 级别 35)为目标平台且在 Android 15 设备上实现全屏显示的应用。此应用主要使用会自动应用边衬区的 Material 3 Compose 组件。此屏幕不受 Android 15 强制执行的无边框措施的负面影响。

这是一项重大变更,可能会对应用的界面产生负面影响。这些更改会影响以下界面区域:

  • 手势柄导航栏
    • 默认透明。
    • 底部偏移量处于停用状态,因此内容会绘制在系统导航栏后面,除非应用了边衬区。
    • setNavigationBarColorR.attr#navigationBarColor 已被弃用,不会影响手势导航。
    • setNavigationBarContrastEnforcedR.attr#navigationBarContrastEnforced 继续对基于手势的导航没有任何影响。
  • “三按钮”导航
    • 默认情况下,不透明度设置为 80%,颜色可能与窗口背景颜色一致。
    • 底部偏移量处于停用状态,因此内容会绘制在系统导航栏后面,除非应用了边衬区。
    • 默认情况下,setNavigationBarColorR.attr#navigationBarColor 设置为与窗口背景相匹配。窗口背景必须是颜色可绘制对象,才能应用此默认值。此 API 已弃用,但仍会影响三按钮导航。
    • setNavigationBarContrastEnforcedR.attr#navigationBarContrastEnforced 默认值为 true,这会在三按钮导航栏中添加 80% 不透明度的背景。
  • 状态栏
    • 默认透明。
    • 顶部偏移量处于停用状态,因此内容会绘制在状态栏后面,除非应用了边衬区。
    • setStatusBarColorR.attr#statusBarColor 已被废弃,在 Android 15 上不起作用。
    • setStatusBarContrastEnforcedR.attr#statusBarContrastEnforced 已废弃,但仍会对 Android 15 产生影响。
  • 刘海屏
    • 非浮动窗口的 layoutInDisplayCutoutMode 必须为 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYSSHORT_EDGESNEVERDEFAULT 会被解读为 ALWAYS,这样用户就不会看到因刘海屏而产生的黑条,并且应用会显示在屏幕边缘。

以下示例展示了应用在以 Android 15(API 级别 35)为目标平台之前和之后,以及在应用边衬区之前和之后的效果。此示例并不全面,在 Android Auto 上可能会显示不同的内容。

以 Android 14 为目标平台且在 Android 15 设备上不是全屏显示的应用。
以 Android 15(API 级别 35)为目标平台且在 Android 15 设备上实现全屏显示的应用。不过,由于 Android 15 强制执行边缘到边缘显示,许多元素现在会被状态栏、三按钮导航栏或刘海屏遮挡。隐藏界面包括 Material 2 顶部应用栏、悬浮操作按钮和列表项。
以 Android 15(API 级别 35)为目标平台的应用在 Android 15 设备上是全屏显示,并应用了边衬区,因此界面不会被隐藏。
如果应用已实现全屏显示,需要检查哪些方面

如果您的应用已实现全屏显示并应用边衬区,则在大多数情况下不会受到影响,但以下情形除外。不过,即使您认为自己不受影响,我们仍建议您测试应用。

  • 您有一个非浮动窗口,例如使用 SHORT_EDGESNEVERDEFAULT 而不是 LAYOUT_IN_DISPLAY_CUTOUT_MODE_ALWAYSActivity。如果您的应用在启动时崩溃,这可能是由启动画面引起的。您可以将核心启动画面依赖项升级到 1.2.0-alpha01 或更高版本,也可以设置 window.attributes.layoutInDisplayCutoutMode = WindowManager.LayoutInDisplayCutoutMode.always
  • 可能存在流量较低且界面被遮挡的屏幕。验证这些访问频率较低的界面是否没有被遮挡的界面。低流量界面包括:
    • 初始配置或登录界面
    • “设置”页面
如果您的应用尚未实现全屏显示,需要检查哪些方面

如果您的应用尚未实现全屏显示,则很可能会受到影响。除了已经实现全屏显示的 app 的场景之外,您还应考虑以下事项:

  • 如果您的应用在 Compose 中使用 Material 3 组件 (androidx.compose.material3),例如 TopAppBarBottomAppBarNavigationBar,这些组件很可能不会受到影响,因为它们会自动处理边衬区。
  • 如果您的应用使用的是 Compose 中的 Material 2 组件 (androidx.compose.material),这些组件不会自动处理边衬区。不过,您可以获得边衬区的访问权限,然后手动应用边衬区。在 androidx.compose.material 1.6.0 及更高版本中,使用 windowInsets 参数可为 BottomAppBarTopAppBarBottomNavigationNavigationRail 手动应用边衬区。 同样,请为 Scaffold 使用 contentWindowInsets 参数。
  • 如果您的应用使用视图和 Material 组件 (com.google.android.material),则大多数基于视图的 Material 组件(例如 BottomNavigationViewBottomAppBarNavigationRailViewNavigationView)都会处理边衬区,因此不需要执行额外的操作。不过,如果使用的是 AppBarLayout,则需要添加 android:fitsSystemWindows="true"
  • 对于自定义可组合项,请手动应用边衬区作为内边距。如果您的内容位于 Scaffold 内,则可以使用 Scaffold 内边距值来使用插边。否则,请使用 WindowInsets 之一应用内边距。
  • 如果应用使用的是视图和 BottomSheetSideSheet 或自定义容器,请使用 ViewCompat.setOnApplyWindowInsetsListener 应用内边距。对于 RecyclerView,请使用此监听器应用内边距,同时添加 clipToPadding="false"
如果应用必须提供自定义后台保护,需要检查哪些方面

如果您的应用必须为三按钮导航或状态栏提供自定义背景保护,则应使用 WindowInsets.Type#tappableElement()WindowInsets.Type#statusBars 将可组合项或视图放置在系统栏后面,以获取三按钮导航栏高度。

其他全屏显示资源

如需了解有关应用边衬区的其他注意事项,请参阅全屏视图全屏 Compose 指南。

已弃用的 API

以下 API 已弃用,但未停用:

以下 API 已弃用并停用:

Cấu hình ổn định

如果您的应用以 Android 15(API 级别 35)或更高版本为目标平台,Configuration 不再排除系统栏。如果您在 Configuration 类中使用屏幕尺寸进行布局计算,则应根据需要将其替换为更好的替代方案,例如适当的 ViewGroupWindowInsetsWindowMetricsCalculator

Configuration 自 API 1 起便已开始提供。它通常从 Activity.onConfigurationChanged 中获取。它提供窗口密度、方向和大小等信息。从 Configuration 返回的窗口大小的一个重要特征是,它之前排除了系统栏。

配置大小通常用于资源选择,例如 /res/layout-h500dp,这仍然是一个有效的使用情形。不过,我们一直不建议使用它进行布局计算。如果您正在这样做,请立即远离该设备。您应根据自己的使用场景,将 Configuration 的使用替换为更合适的用法。

如果您使用它来计算布局,请使用适当的 ViewGroup,例如 CoordinatorLayoutConstraintLayout。如果您使用它来确定系统导航栏的高度,请使用 WindowInsets。如果您想知道应用窗口的当前大小,请使用 computeCurrentWindowMetrics

以下列表介绍了受此变更影响的字段:

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.

Hành vi
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

Trong các phiên bản Android trước, một số phông chữ hoặc ngôn ngữ viết tay có hình dạng phức tạp có thể vẽ các chữ cái trong vùng của ký tự trước hoặc sau. Trong một số trường hợp, các chữ cái như vậy bị cắt ở vị trí đầu hoặc cuối. Kể từ Android 15, TextView sẽ phân bổ chiều rộng để vẽ đủ không gian cho các chữ cái đó và cho phép ứng dụng yêu cầu khoảng đệm bổ sung ở bên trái để tránh bị cắt bớt.

Vì thay đổi này ảnh hưởng đến cách TextView quyết định chiều rộng, nên theo mặc định, TextView sẽ phân bổ nhiều chiều rộng hơn nếu ứng dụng nhắm đến Android 15 (API cấp 35) trở lên. Bạn có thể bật hoặc tắt hành vi này bằng cách gọi API setUseBoundsForWidth trên TextView.

Vì việc thêm khoảng đệm bên trái có thể khiến các bố cục hiện có bị lệch, nên khoảng đệm không được thêm theo mặc định ngay cả đối với các ứng dụng nhắm đến Android 15 trở lên. Tuy nhiên, bạn có thể thêm khoảng đệm bổ sung để ngăn chặn việc cắt bớt bằng cách gọi setShiftDrawingOffsetForStartOverhang.

Các ví dụ sau đây cho thấy những thay đổi này có thể cải thiện bố cục văn bản cho một số phông chữ và ngôn ngữ.

Bố cục chuẩn cho văn bản tiếng Anh bằng phông chữ chữ thảo. Một số chữ cái bị cắt bớt. Sau đây là XML tương ứng:

<TextView
    android:fontFamily="cursive"
    android:text="java" />
Bố cục cho cùng một văn bản tiếng Anh có thêm chiều rộng và khoảng đệm. Dưới đây là mã XML tương ứng:

<TextView
    android:fontFamily="cursive"
    android:text="java"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />
Bố cục chuẩn cho văn bản tiếng Thái. Một số chữ cái bị cắt bớt. Sau đây là XML tương ứng:

<TextView
    android:text="คอมพิวเตอร์" />
Bố cục cho cùng một văn bản tiếng Thái có thêm chiều rộng và khoảng đệm. Dưới đây là XML tương ứng:

<TextView
    android:text="คอมพิวเตอร์"
    android:useBoundsForWidth="true"
    android:shiftDrawingOffsetForStartOverhang="true" />

Chiều cao dòng mặc định theo ngôn ngữ cho EditText

在较低版本的 Android 中,文本布局会拉伸文本的高度,以满足与当前语言区域匹配的字体的行高。例如,如果内容是日语,由于日语字体的行高略高于拉丁字体,因此文本的高度会略高。不过,尽管行高存在这些差异,但无论使用的是哪种语言区域,EditText 元素的大小都是统一的,如下图所示:

三个框,表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度相同,即使这些语言的行高各不相同。

对于以 Android 15(API 级别 35)为目标平台的应用,现在为 EditText 预留了最小行高,以匹配指定语言区域的参考字体,如下图所示:

三个框,表示可以包含英语 (en)、日语 (ja) 和缅甸语 (my) 文本的 EditText 元素。EditText 的高度现在包含足够的空间来容纳这些语言字体的默认行高。

如有需要,您的应用可以将 useLocalePreferredLineHeightForMinimum 属性指定为 false,以恢复之前的行为;您的应用还可以在 Kotlin 和 Java 中使用 setMinimumFontMetrics API 设置自定义最小垂直指标。

Camera và nội dung nghe nhìn

Android 15 thực hiện những thay đổi sau đố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.

Quy định hạn chế đối với 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 thử ứ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.