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 ứ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 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 đ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 13.
Quyền riêng tư
Quyền 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 thông báo liên quan đến các dịch vụ trên nền trước trong Trình quản lý tác vụ, bất kể quyền gửi thông báo có được cấp 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, người dùng cần cấp cho ứng dụng của bạn quyền ACCESS_FINE_LOCATION để hoàn tất một số trường hợp sử dụng Wi-Fi phổ biến.
Vì người dùng khó liên kết quyền truy cập thông tin vị trí với chức năng Wi-Fi, nên Android 13 (API cấp 33) ra mắt một quyền khi bắt đầu chạy trong nhóm quyền NEARBY_DEVICES cho các ứng dụng quản lý kết nối của thiết bị với các điểm truy cập lân cận qua Wi-Fi. Quyền này, NEARBY_WIFI_DEVICES, thực hiện 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 phát nội dung đa phương tiện.
Quy trình công việc này cho phép ứng dụng của bạn hoàn thành các loại tác vụ sau:
- Nhận thông tin AP ngoài băng tần, chẳng hạn như thông qua BLE.
- Khám phá và kết nối với các thiết bị qua Wi-Fi Aware 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 của các thiết bị Wi-Fi Aware ở gần.
Miễn là ứng dụng của bạn không lấy thông tin vị trí thực tế từ API Wi-Fi, 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 xác nhận 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ế từ API Wi-Fi. Để làm như vậy, hãy đặt thuộc tính android:usesPermissionFlags thành neverForLocation. Quy trình này tương tự như quy trình bạn thực hiện trong Android 12 (API cấp 31) trở lên khi bạn xác nhận rằng thông tin thiết bị Bluetooth không bao giờ được dùng để xác định vị trí.
Tìm hiểu thêm về cách yêu cầu cấp 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
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 đã tạo, thì 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 ở cấp độ chi tiết sau đây thay vì quyền READ_EXTERNAL_STORAGE:
| 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 cho ứng dụng của bạn các quyền chi tiết thích hợp đối với nội dung nghe nhìn.
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 lẫn quyền READ_MEDIA_VIDEO cùng lúc, thì chỉ có một hộp thoại cấp quyền của hệ thống xuất hiện.
Nếu trước đây ứng dụng của bạn đã được cấp quyền 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ể sử dụng lệnh ADB sau đây để xem lại các quyền đã nâng cấp:
adb shell cmd appops get --uid PACKAGE_NAME
Việc sử dụng cảm biến cơ thể ở chế độ nền yêu cầu quyền mới
Android 13 giới thiệu khái niệm quyền truy cập "khi đang sử dụng" cho các 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. Mô hình truy cập này rất giống với mô hình mà hệ thống đã giới thiệu cho thông tin vị trí trong Android 10 (API cấp 29).
Nếu ứng dụng của bạn nhắm đến Android 13 và yêu cầu quyền truy cập vào thông tin của cảm biến cơ thể khi chạy ở chế độ nền, thì bạn phải khai báo quyền BODY_SENSORS_BACKGROUND mới ngoài quyền BODY_SENSORS hiện có.
Hiệu suất và pin
Mức sử dụng tài nguyên pin
Nếu người dùng đặt ứng dụng của bạn ở trạng thái "bị hạn chế" đối với việc sử dụng pin trong nền trong khi ứng dụng của bạn nhắm đến Android 13, thì hệ thống sẽ không phân phối thông báo BOOT_COMPLETED hoặc thông báo LOCKED_BOOT_COMPLETED cho đến khi ứng dụng đó được khởi động vì lý do khác.
Trải nghiệm người dùng
Các chế độ điều khiển nội dung nghe nhìn bắt nguồn từ PlaybackState
Đối với các ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, hệ thống sẽ lấy các chế độ điều khiển nội dung nghe nhìn từ các thao tác PlaybackState. Điều này cho phép hệ thống hiển thị một bộ điều khiển phong phú hơn, nhất quán về mặt kỹ thuật giữa các thiết bị điện thoại và máy tính bảng, đồng thời phù hợp với cách hiển thị các nút điều khiển nội dung nghe nhìn trên các nền tảng Android khác như Android Auto và Android TV.
Hình 2 cho thấy ví dụ về giao diện này trên điện thoại và máy tính bảng tương ứng.
Trước Android 13, hệ thống hiển thị tối đa 5 thao tác từ thông báo MediaStyle theo thứ tự thêm các thao tác đó.
Ở chế độ thu gọn (ví dụ: trong phần cài đặt nhanh thu gọn), tối đa là 3 thao tác được chỉ định bằng setShowActionsInCompactView() sẽ 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 PlaybackState như mô tả trong bảng sau. Ở chế độ thu gọn, chỉ 3 khe hành động đầu tiên mới hiển thị. Đối với các ứng dụng không nhắm đến Android 13 hoặc các ứng dụng không bao gồm PlaybackState, hệ thống sẽ hiển thị các chế độ điều khiển dựa trên danh sách Action được thêm vào thông báo MediaStyle như mô tả trong đoạn trước.
| Khe | Thao tác | 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:
|
| 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:
|
|
| Tạm dừng | Trạng thái hiện tại của PlaybackState không phải là trạng thái nào nêu trên. |
|
| 2 | Nút trước | Thao tác PlaybackState bao gồm ACTION_SKIP_TO_PREVIOUS. |
| Tuỳ chỉnh | Thao tác PlaybackState không bao gồm ACTION_SKIP_TO_PREVIOUS và Thao tác tuỳ chỉnh PlaybackState bao gồm một thao tác tuỳ chỉnh chưa được đặt. |
|
| Trống | PlaybackState thông tin bổ sung bao gồm giá trị boolean true cho khoá SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_PREV. |
|
| 3 | Tiếp theo | Thao tác PlaybackState bao gồm ACTION_SKIP_TO_NEXT. |
| Tuỳ chỉnh | Thao tác PlaybackState không bao gồm ACTION_SKIP_TO_NEXT và Thao tác tuỳ chỉnh PlaybackState bao gồm một thao tác tuỳ chỉnh chưa được đặt. |
|
| Trống | PlaybackState thông tin bổ sung bao gồm giá trị boolean true cho khoá SESSION_EXTRAS_KEY_SLOT_RESERVATION_SKIP_TO_NEXT. |
|
| 4 | Tuỳ chỉnh | Hành động tuỳ chỉnh PlaybackState bao gồm một hành động tuỳ chỉnh chưa được đặt. |
| 5 | Tuỳ chỉnh | Hành động tuỳ chỉnh PlaybackState bao gồm một hành động tuỳ chỉnh chưa được đặt. |
Các thao tác tuỳ chỉnh được đặt theo thứ tự đượ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 các ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, phương thức setForceDark() không còn được dùng nữa, dẫn đến việc không thực hiện được thao tác nào nếu phương thức này được gọi.
Thay vào đó, WebView hiện luôn đặt truy vấn nội dung nghe nhìn prefers-color-scheme theo thuộc tính giao diện của ứng dụng, isLightTheme. Nói cách khác, nếu isLightTheme là true hoặc không được chỉ định, prefers-color-scheme sẽ là light; nếu không, giá trị này sẽ là dark. Hành vi này có nghĩa là kiểu sáng hoặc tối của nội dung web sẽ tự động được áp dụng để phù hợp với giao diện của ứng dụng nếu nội dung hỗ trợ giao diện đó.
Đối với hầu hết ứng dụng, hành vi mới sẽ tự động áp dụng các kiểu ứng dụng phù hợp. Tuy nhiên, bạn nên kiểm thử ứng dụng để kiểm tra mọi trường hợp có thể bạn đã kiểm soát chế độ cài đặt 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 giao diện màu của ứng dụng, hãy sử dụng phương thức setAlgorithmicDarkeningAllowed(). Để tương thích ngược với các phiên bản Android trước, bạn nên sử dụng phương thức setAlgorithmicDarkeningAllowed() tương đương trong AndroidX.
Hãy xem tài liệu về phương thức đó để tìm hiểu thêm về hành vi mà bạn có thể dự kiến trong ứng dụng tuỳ thuộc vào chế độ cài đặt giao diện và targetSdkVersion của ứng dụng.
Khả năng kết nối
Ngừng sử dụng BluetoothAdapter#enable() và BluetoothAdapter#disable()
Đối với các ứng dụng nhắm đến Android 13 (API cấp 33) trở lên, các phương thức BluetoothAdapter#enable() và BluetoothAdapter#disable() không còn được dùng nữa và luôn trả về false.
Các loại ứng dụng sau đây được miễn trừ 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 sử dụng mã nhận dạng cho quảng cáo
Những ứng dụng sử dụng mã nhận dạng cho quảng cáo của Dịch vụ Google Play và nhắm đến Android 13 (API cấp 33) trở lên phải khai báo quyền thông thường AD_ID trong tệp kê khai của ứng dụng 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 trở lên, thì mã nhận dạng cho quảng cáo sẽ tự động bị xoá và được thay thế bằng một chuỗi số 0.
Nếu ứng dụng của bạn sử dụng các SDK khai báo quyền AD_ID trong tệp kê khai của thư viện, thì quyền này sẽ được hợp nhất với tệp kê khai của ứng dụng theo mặc định. Trong trường hợp này, bạn không cần khai báo quyền trong tệp kê khai của ứng dụng.
Để tìm hiểu thêm, hãy xem phần Mã nhận dạng cho quảng cáo trong Trung tâm trợ giúp của 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ề 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 13, thì một số thay đổi này có thể sẽ không ảnh hưởng ngay. 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, 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 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.