The Android 15 Beta is now available. Try it out today and let us know what you think!

Trang này được dịch bởi Cloud Translation API.

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

Giống như các bản phát hành trước, Android 13 có các thay đổi về hành vi có thể ảnh hưởng đến . Những thay đổi sau đây về hành vi chỉ áp dụng cho các ứng dụng nhắm đến Android 13 trở lên. Nếu ứng dụng của bạn nhắm đến Android 13 trở lên, bạn nên sửa đổi ứng dụng để hỗ trợ những hành vi này cho phù hợp (nếu có).

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 13.

Quyền riêng tư

Quyền gửi thông báo ảnh hưởng đến giao diện của dịch vụ trên nền trước

Nếu người dùng từ chối quyền gửi thông báo, họ sẽ không thấy thông báo liên quan đến các dịch vụ trên nền trước trong ngăn thông báo. Tuy nhiên, người dùng vẫn thấy các thông báo liên quan đến các dịch vụ trên nền trước trong Task Manager (Trình quản lý tác vụ), bất kể có cấp quyền gửi thông báo hay không.

Quyền mới khi bắt đầu chạy cho các thiết bị Wi-Fi ở gần

Trên các phiên bản Android trước đây, người dùng cần cấp cho ứng dụng của bạn quyền ACCESS_FINE_LOCATION quyền hoàn tất một số trường hợp sử dụng Wi-Fi phổ biến.

Do người dùng khó liên kết quyền truy cập thông tin vị trí với Wi-Fi Android 13 (API cấp 33) giới thiệu quyền khi bắt đầu chạy trong NEARBY_DEVICES nhóm quyền dành cho các ứng dụng quản lý việc kết nối của một thiết bị với quyền truy cập ở gần điểm phát sóng qua Wi-Fi. Quyền này, NEARBY_WIFI_DEVICES! đáp ứng các trường hợp sử dụng Wi-Fi như sau:

Tìm hoặc kết nối với các thiết bị ở gần, chẳng hạn như máy in hoặc thiết bị truyền nội dung nghe nhìn. Quy trình công việc này cho phép ứng dụng của bạn thực hiện những loại nhiệm vụ sau:
- Nhận thông tin AP ngoài băng tần, chẳng hạn như qua BLE.
- Khám phá và kết nối với các thiết bị qua tính năng Nhận biết Wi-Fi và kết nối bằng điểm phát sóng chỉ trong cục bộ.
- Khám phá và kết nối với các thiết bị qua Wi-Fi Direct.
Bắt đầu kết nối với một SSID đã biết, chẳng hạn như ô tô hoặc thiết bị nhà thông minh.
Bắt đầu một điểm phát sóng chỉ trong cục bộ.
Phạm vi đến các thiết bị Nhận biết Wi-Fi ở gần.

Miễn là ứng dụng của bạn không lấy được thông tin vị trí thực tế qua Wi-Fi API, hãy yêu cầu NEARBY_WIFI_DEVICES thay vì ACCESS_FINE_LOCATION khi bạn nhắm đến Android 13 trở lên và sử dụng API Wi-Fi. Khi bạn khai báo quyền NEARBY_WIFI_DEVICES, hãy chắc chắn rằng ứng dụng của bạn không bao giờ lấy thông tin vị trí thực từ API Wi-Fi. Để làm như vậy, hãy đặt Thuộc tính android:usesPermissionFlags cho neverForLocation. Quá trình này tương tự như yêu cầu bạn thực hiện trong Android 12 (API cấp 31) trở lên, khi xác nhận rằng thông tin thiết bị Bluetooth sẽ không bao giờ được dùng để vị trí.

Tìm hiểu thêm về cách yêu cầu quyền truy cập vào các thiết bị Wi-Fi ở gần.

Quyền phương tiện chi tiết

2 nút của hộp thoại, từ trên xuống dưới là Cho phép và Không
cho phép — **Hình 1.** Hộp thoại cấp quyền của hệ thống mà người dùng sẽ thấy khi bạn yêu cầu quyền `READ_MEDIA_AUDIO`.

Nếu ứng dụng của bạn nhắm đến Android 13 trở lên và cần truy cập vào các tệp nội dung nghe nhìn mà các ứng dụng khác có đã tạo, bạn phải yêu cầu một hoặc nhiều quyền truy cập nội dung nghe nhìn chi tiết sau đây thay vì READ_EXTERNAL_STORAGE quyền:

Loại nội dung nghe nhìn	Quyền yêu cầu
Hình ảnh và ảnh	`READ_MEDIA_IMAGES`
Video	`READ_MEDIA_VIDEO`
Tệp âm thanh	`READ_MEDIA_AUDIO`

Trước khi bạn truy cập vào tệp nội dung nghe nhìn của một ứng dụng khác, hãy xác minh rằng người dùng đã cấp quyền các quyền truy cập nội dung nghe nhìn chi tiết thích hợp cho ứng dụng của mình.

Hình 1 cho thấy một ứng dụng yêu cầu quyền READ_MEDIA_AUDIO.

Nếu bạn yêu cầu cả quyền READ_MEDIA_IMAGES và Quyền READ_MEDIA_VIDEO cùng một lúc, chỉ có một quyền hệ thống xuất hiện.

Nếu trước đây ứng dụng của bạn đã được cấp READ_EXTERNAL_STORAGE thì mọi quyền READ_MEDIA_* được yêu cầu sẽ được cấp tự động khi nâng cấp. Bạn có thể dùng lệnh ADB sau đây để xem lại quyền đã nâng cấp:

adb shell cmd appops get --uid PACKAGE_NAME

Cần có quyền mới để sử dụng cảm biến cơ thể ở chế độ nền

Android 13 ra mắt khái niệm "trong khi sử dụng" quyền truy cập cho cảm biến cơ thể, chẳng hạn như nhịp tim, nhiệt độ và tỷ lệ phần trăm oxy trong máu. Chiến dịch này mô hình truy cập rất giống với mô hình mà hệ thống đã giới thiệu cho vị trí trong Android 10 (API cấp 29).

Nếu ứng dụng của bạn nhắm đến Android 13 và cần quyền truy cập vào cảm biến cơ thể trong khi chạy ở chế độ nền, bạn phải khai báo BODY_SENSORS_BACKGROUND bên cạnh quyền hiện có, BODY_SENSORS quyền.

Hiệu suất và pin

Sử dụng tài nguyên pin

Nếu người dùng đặt ứng dụng của bạn trong "bị hạn chế" trạng thái cho mức sử dụng pin ở chế độ nền trong khi ứng dụng của bạn nhắm đến Android 13, nhưng hệ thống sẽ không cung cấp truyền phát BOOT_COMPLETED hoặc LOCKED_BOOT_COMPLETED cho đến ứng dụng của bạn khởi động vì những lý do khác.

Trải nghiệm người dùng

Các nút điều khiển nội dung nghe nhìn bắt nguồn từ `PlaybackState`

Đối với ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, hệ thống lấy kết quả các nút điều khiển nội dung nghe nhìn từ Hành động PlaybackState. Chiến dịch này cho phép hệ thống hiển thị một loạt các chức năng kiểm soát phong phú hơn về mặt kỹ thuật nhất quán giữa điện thoại và thiết bị máy tính bảng, đồng thời cũng phù hợp với cách phương tiện truyền thông hiển thị trên các nền tảng Android khác như Android Auto và Android TV.

Hình 2 minh hoạ một ví dụ về giao diện trên điện thoại và máy tính bảng. .

Các điều khiển nội dung nghe nhìn về cách chúng xuất hiện trên thiết bị điện thoại và máy tính bảng,
sử dụng ví dụ về kênh mẫu cho thấy cách các nút có thể xuất hiện — **Hình 2:** Các chế độ điều khiển nội dung nghe nhìn trên thiết bị điện thoại và máy tính bảng

Trước Android 13, hệ thống hiển thị tối đa 5 thao tác trên MediaStyle thông báo theo thứ tự được thêm. Ở chế độ thu gọn (ví dụ: trong chế độ cài đặt nhanh đã thu gọn), tối đa ba hành động được chỉ định bằng setShowActionsInCompactView() được hiển thị.

Kể từ Android 13, hệ thống sẽ hiển thị tối đa 5 nút hành động dựa trên trên PlaybackState như mô tả trong bảng sau. Ở chế độ thu gọn, chỉ 3 tổ hợp phím đầu tiên vùng hành động sẽ được hiển thị. Đối với ứng dụng không nhắm đến Android 13 hoặc không bao gồm PlaybackState, hệ thống sẽ hiển thị các điều khiển dựa trên danh sách Action được thêm vào thông báo MediaStyle như được mô tả trong đoạn trước.

Khe	Hành động	Tiêu chí
1	Phát	Trạng thái hiện tại của `PlaybackState` là một trong những trạng thái sau: `STATE_NONE` `STATE_STOPPED` `STATE_PAUSED` `STATE_ERROR`
	Vòng quay đang tải	Trạng thái hiện tại của `PlaybackState` là một trong những trạng thái sau: `STATE_CONNECTING` `STATE_BUFFERING`
	Tạm dừng	Trạng thái hiện tại của `PlaybackState` không phải trạng thái nào ở trên.
2	Trước	Các hành động `PlaybackState` bao gồm `ACTION_SKIP_TO_PREVIOUS`.
	Điều chỉnh	Thao tác `PlaybackState` không bao gồm một thao tác tuỳ chỉnh `ACTION_SKIP_TO_PREVIOUS` và `PlaybackState` thao tác tuỳ chỉnh bao gồm một thao tác tuỳ chỉnh chưa được thực hiện.
	Trống	Thông tin bổ sung `PlaybackState` bao gồm giá trị boolean `true` cho khoá `SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV`.
3	Tiếp theo	Các hành động `PlaybackState` bao gồm `ACTION_SKIP_TO_NEXT`.
	Điều chỉnh	Thao tác `PlaybackState` không bao gồm một thao tác tuỳ chỉnh `ACTION_SKIP_TO_NEXT` và `PlaybackState` thao tác tuỳ chỉnh bao gồm một thao tác tuỳ chỉnh chưa được thực hiện.
	Trống	Thông tin bổ sung `PlaybackState` bao gồm giá trị boolean `true` cho khoá `SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT`.
4	Điều chỉnh	`PlaybackState` hành động tuỳ chỉnh bao gồm một hành động tuỳ chỉnh chưa được đặt.
5	Điều chỉnh	`PlaybackState` hành động tuỳ chỉnh bao gồm một hành động tuỳ chỉnh chưa được đặt.

Các hành động tuỳ chỉnh được đặt theo thứ tự mà chúng được thêm vào PlaybackState.

Giao diện màu của ứng dụng được tự động áp dụng cho nội dung WebView

Đối với ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, setForceDark() không được dùng nữa, dẫn đến việc không hoạt động nếu phương thức này được gọi.

Thay vào đó, giờ đây WebView luôn đặt truy vấn phương tiện prefers-color-scheme theo thuộc tính giao diện của ứng dụng, isLightTheme. Trong khu vực khác các từ, nếu isLightTheme là true hoặc không được chỉ định, prefers-color-scheme là light; nếu không thì sẽ là dark. Hành vi này có nghĩa là phần mở rộng về kiểu sáng hoặc tối được áp dụng tự động cho phù hợp với giao diện của ứng dụng nếu nội dung nào hỗ trợ công cụ đó.

Đối với hầu hết ứng dụng, hành vi mới sẽ áp dụng kiểu ứng dụng thích hợp tự động, tuy nhiên, bạn nên kiểm thử ứng dụng để xem có bất kỳ trường hợp nào mà bạn có thể đã kiểm soát các chế độ tối theo cách thủ công.

Nếu bạn vẫn cần tuỳ chỉnh hành vi của chủ đề màu sắc, hãy sử dụng setAlgorithmicDarkeningAllowed() thay thế. Để tương thích ngược với các phiên bản Android trước, chúng tôi bạn nên sử dụng hàm tương đương setAlgorithmicDarkeningAllowed() trong AndroidX.

Hãy xem tài liệu về phương thức đó để tìm hiểu thêm về hành vi bạn có thể thực hiện mong đợi trong ứng dụng của bạn, tuỳ thuộc vào targetSdkVersion và giao diện phần cài đặt.

Khả năng kết nối

Ngừng sử dụng BluetoothAdapter#enable() và BluetoothAdapter#disable()

Đối với ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, BluetoothAdapter#enable() và Các phương thức BluetoothAdapter#disable() không được dùng nữa và luôn được sử dụng trả về false.

Sau đây là những loại ứng dụng được miễn khỏi những thay đổi này:

Ứng dụng của chủ sở hữu thiết bị
Ứng dụng của chủ sở hữu hồ sơ
Ứng dụng hệ thống

Dịch vụ Google Play

Cần có quyền để dùng mã nhận dạng cho quảng cáo

Ứng dụng sử dụng dịch vụ quảng cáo của Dịch vụ Google Play Mã nhận dạng và nhắm mục tiêu đến Android 13 (API cấp 33) trở lên phải khai báo quyền thông thường AD_ID trong ứng dụng tệp kê khai như sau:

<manifest ...>
    <!-- Required only if your app targets Android 13 or higher. -->
    <uses-permission android:name="com.google.android.gms.permission.AD_ID"/>

    <application ...>
        ...
    </application>
</manifest>

Nếu ứng dụng của bạn không khai báo quyền này khi nhắm đến Android 13 hoặc thì mã nhận dạng cho quảng cáo sẽ tự động bị xoá và thay thế bằng một chuỗi là 0.

Nếu ứng dụng của bạn dùng các SDK khai báo quyền AD_ID trong tệp kê khai, sau đó quyền sẽ được hợp nhất với tệp kê khai của ứng dụng bằng cách mặc định. Trong trường hợp này, bạn không cần khai báo quyền trong phần tệp manfiest nhất.

Để tìm hiểu thêm, hãy xem bài viết Quảng cáo Mã nhận dạng ở phần Trợ giúp về Play Console.

Các quy tắc hạn chế mới cập nhật đối với yếu tố ngoài SDK

Android 13 cung cấp danh sách mới cập nhật về những nội dung không phải SDK bị hạn chế dựa trên sự cộng tác với các nhà phát triển Android và thử nghiệm nội bộ. 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 13, thì một số thay đổi này có thể không ảnh hưởng ngay đến bạn. Tuy nhiên, mặc dù hiện tại bạn có thể sử dụng 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 cho một tính năng trong ứng dụng, thì 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 nội dung Thông tin cập nhật đối với các hạn chế đối với giao diện không phải SDK trên Android 13. Để tìm hiểu tổng quan thêm về giao diện không phải SDK, hãy xem Hạn chế đối với giao diện không phải SDK .