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 12

Giống như các bản phát hành trước, Android 12 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 12 trở lên. Nếu ứng dụng của bạn nhắm đến Android 12, bạn nên sửa đổi ứng dụng để hỗ trợ những hành vi này đúng cách (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 12.

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

Thông báo tuỳ chỉnh

Android 12 thay đổi giao diện và hoạt động của thông báo tuỳ chỉnh hoàn toàn. Trước đây, các thông báo tuỳ chỉnh có thể sử dụng toàn bộ khu vực thông báo, đồng thời cung cấp bố cục và kiểu riêng. Điều này dẫn đến việc chống mẫu có thể khiến người dùng nhầm lẫn hoặc gây ra vấn đề về khả năng tương thích bố cục trên các thiết bị khác nhau.

Đối với các ứng dụng nhắm đến Android 12, thông báo có khung hiển thị nội dung tuỳ chỉnh sẽ không còn sử dụng khu vực thông báo đầy đủ; thay vào đó, hệ thống sẽ áp dụng một mẫu chuẩn. Mẫu này đảm bảo rằng thông báo tuỳ chỉnh có cách trang trí giống như các thông báo khác ở tất cả các trạng thái, chẳng hạn như các thành phần mở rộng và biểu tượng của thông báo (ở trạng thái thu gọn) và biểu tượng, tên ứng dụng và thành phần thu gọn của thông báo (ở trạng thái mở rộng). Hành vi này gần giống với hành vi của Notification.DecoratedCustomViewStyle.

Bằng cách này, Android 12 giúp tất cả thông báo trở nên nhất quán và dễ quét, đồng thời mở rộng phạm vi thông báo mà người dùng có thể tìm thấy và quen thuộc.

Hình minh hoạ sau đây cho thấy một thông báo tuỳ chỉnh trong mẫu chuẩn:

Các ví dụ sau đây cho thấy cách thông báo tuỳ chỉnh hiển thị ở trạng thái thu gọn và mở rộng:

Thay đổi này trong Android 12 ảnh hưởng đến những ứng dụng xác định các lớp con tuỳ chỉnh của Notification.Style hoặc những ứng dụng sử dụng các phương thức của Notification.Builder setCustomContentView(RemoteViews), setCustomBigContentView(RemoteViews) và setCustomHeadsUpContentView(RemoteViews).

Nếu ứng dụng của bạn đang sử dụng thông báo hoàn toàn tuỳ chỉnh, thì bạn nên kiểm thử bằng mẫu mới càng sớm càng tốt.

Bật thay đổi về thông báo tuỳ chỉnh:
1. Thay đổi targetSdkVersion của ứng dụng thành S để cho phép hành vi mới.
2. Biên dịch lại.
3. Cài đặt ứng dụng của bạn trên một thiết bị hoặc trình mô phỏng chạy Android 12.
Kiểm thử tất cả các thông báo sử dụng thành phần hiển thị tuỳ chỉnh để đảm bảo chúng trông giống như bạn mong đợi trong bóng đổ. Trong khi kiểm thử, hãy cân nhắc những điều sau và thực hiện các điều chỉnh cần thiết:
- Phương diện của chế độ xem tuỳ chỉnh đã thay đổi. Nhìn chung, chiều cao cho phép đối với thông báo tuỳ chỉnh thấp hơn trước đây. Ở trạng thái thu gọn, chiều cao tối đa của nội dung tuỳ chỉnh đã giảm từ 106dp xuống còn 48dp. Ngoài ra, không gian theo chiều ngang sẽ ít hơn.
- Tất cả thông báo đều có thể mở rộng cho các ứng dụng nhắm đến Android 12. Thông thường, điều này có nghĩa là nếu đang sử dụng setCustomContentView, bạn cũng nên sử dụng setBigCustomContentView để đảm bảo trạng thái thu gọn và mở rộng nhất quán.
- Để đảm bảo trạng thái "Quan sát xung quanh" đúng như bạn mong đợi, đừng quên tăng mức độ quan trọng của kênh thông báo lên "NHIỀU" (Hiển thị trên màn hình).

Các thay đổi đối với quy trình xác minh Đường liên kết trong ứng dụng Android

Trên các ứng dụng nhắm đến Android 12 trở lên, hệ thống sẽ thực hiện một số thay đổi đối với cách xác minh Đường liên kết trong ứng dụng Android. Những thay đổi này giúp cải thiện độ tin cậy của trải nghiệm liên kết ứng dụng, đồng thời mang lại nhiều quyền kiểm soát hơn cho nhà phát triển ứng dụng và người dùng cuối.

Nếu bạn dựa vào tính năng xác minh bằng Đường liên kết ứng dụng Android để mở các đường liên kết trang web trong ứng dụng của mình, hãy kiểm tra để đảm bảo bạn sử dụng đúng định dạng khi thêm bộ lọc ý định để xác minh Đường liên kết ứng dụng Android. Cụ thể, hãy đảm bảo rằng các bộ lọc ý định này bao gồm danh mục BROWSABLE và hỗ trợ lược đồ https.

Bạn cũng có thể xác minh theo cách thủ công các đường liên kết của ứng dụng để kiểm thử độ tin cậy của nội dung khai báo.

Cải thiện về hành vi của tính năng hình trong hình

Android 12 giới thiệu các điểm cải tiến về hành vi cho chế độ hình trong hình (PiP) và đề xuất các điểm cải tiến về mặt thẩm mỹ để chuyển đổi ảnh động cho cả thao tác bằng cử chỉ và thao tác dựa trên phần tử.

Hãy xem bài viết Cải thiện tính năng hình trong hình để biết thêm thông tin.

Thiết kế lại thông báo ngắn

Trong Android 12, thành phần hiển thị thông báo ngắn đã được thiết kế lại. Giờ đây, thông báo ngắn chỉ được giới hạn ở 2 dòng văn bản và hiện biểu tượng ứng dụng bên cạnh văn bản đó.

Hình ảnh thiết bị Android hiển thị cửa sổ bật lên hiển thị thông báo ngắn "Đang gửi tin nhắn" bên cạnh biểu tượng ứng dụng

Hãy xem bài viết Tổng quan về thông báo ngắn để biết thêm thông tin chi tiết.

Mức độ bảo mật và quyền riêng tư

Vị trí ước chừng

Trên các thiết bị chạy Android 12 trở lên, người dùng có thể yêu cầu độ chính xác của vị trí ước chừng cho ứng dụng của bạn.

Cookie SameSite hiện đại trong WebView

Thành phần WebView của Android dựa trên Chromium, một dự án nguồn mở hỗ trợ trình duyệt Chrome của Google. Chromium đã giới thiệu một số thay đổi đối với cách xử lý cookie của bên thứ ba để tăng cường tính bảo mật và quyền riêng tư, đồng thời mang lại cho người dùng nhiều quyền kiểm soát và tính minh bạch hơn. Kể từ Android 12, những thay đổi này cũng được đưa vào WebView khi các ứng dụng nhắm đến Android 12 (API cấp 31) trở lên.

Thuộc tính SameSite của một cookie kiểm soát việc có thể gửi cookie qua yêu cầu bất kỳ hay chỉ gửi qua các yêu cầu trên cùng một trang web. Những thay đổi bảo vệ quyền riêng tư sau đây giúp cải thiện cách xử lý mặc định đối với cookie của bên thứ ba và giúp ngăn chặn việc chia sẻ ngoài ý muốn trên nhiều trang web:

Những cookie không có thuộc tính SameSite được coi là SameSite=Lax.
Những cookie có SameSite=None cũng phải chỉ định thuộc tính Secure, nghĩa là các cookie này yêu cầu ngữ cảnh an toàn và phải được gửi qua HTTPS.
Các đường liên kết giữa phiên bản HTTP và HTTPS của một trang web hiện được coi là yêu cầu trên nhiều trang web. Vì vậy, cookie sẽ không được gửi trừ phi được đánh dấu thích hợp là SameSite=None; Secure.

Đối với các nhà phát triển, hướng dẫn chung là xác định các phần phụ thuộc cookie trên nhiều trang web trong các luồng người dùng trọng yếu và đảm bảo rằng thuộc tính SameSite được đặt rõ ràng với các giá trị thích hợp, nếu cần. Bạn phải chỉ định rõ ràng các cookie được phép hoạt động trên các trang web hoặc trên các thao tác điều hướng trên cùng một trang web chuyển từ HTTP sang HTTPS.

Để xem hướng dẫn đầy đủ cho các nhà phát triển web về những thay đổi này, hãy xem phần Cookie SameSiteed (Giải thích về cookie SameSite) và linh hoạt của SameSite.

Kiểm thử hành vi của SameSite trong ứng dụng

Nếu ứng dụng của bạn dùng WebView hoặc quản lý một trang web hay dịch vụ sử dụng cookie, thì bạn nên kiểm thử quy trình trên WebView cho Android 12. Nếu phát hiện lỗi, bạn có thể phải cập nhật cookie để hỗ trợ hành vi mới của SameSite.

Chú ý đến các vấn đề trong thông tin đăng nhập và nội dung được nhúng, cũng như quy trình đăng nhập, mua hàng và các quy trình xác thực khác khi người dùng bắt đầu trên một trang không an toàn và chuyển sang một trang bảo mật.

Để kiểm thử một ứng dụng bằng WebView, bạn phải bật các hành vi SameSite mới cho ứng dụng mà bạn muốn kiểm thử bằng cách hoàn thành một trong các bước sau:

Bật các hành vi SameSite trên thiết bị kiểm thử theo cách thủ công bằng cách cài đặt cờ giao diện người dùng webview-enable-existing-cookie-same-site trong WebView devtools.

Phương pháp này cho phép bạn kiểm thử trên mọi thiết bị chạy Android 5.0 (API cấp 21) trở lên (bao gồm cả Android 12) và WebView phiên bản 89.0.4385.0 trở lên.
Biên dịch ứng dụng để nhắm đến Android 12 (API cấp 31) muộn nhất vào ngày targetSdkVersion.

Nếu áp dụng phương pháp này, bạn phải sử dụng một thiết bị chạy Android 12.

Để biết thông tin về cách gỡ lỗi từ xa cho WebView trên Android, hãy xem phần Bắt đầu sử dụng tính năng Gỡ lỗi từ xa cho thiết bị Android.

Tài nguyên khác

Để biết thêm thông tin về hành vi hiện đại của SameSite cũng như triển khai cho Chrome và WebView, hãy truy cập vào trang Thông tin cập nhật về Chromium SameSite. Nếu tìm thấy lỗi trong WebView hoặc Chromium, bạn có thể báo cáo lỗi đó trong Công cụ theo dõi lỗi Chromium công khai.

Cảm biến chuyển động có giới hạn tốc độ

Để bảo vệ thông tin có thể nhạy cảm của người dùng, nếu ứng dụng của bạn nhắm đến Android 12 trở lên, hệ thống sẽ đặt giới hạn về tốc độ làm mới dữ liệu từ một số cảm biến chuyển động và cảm biến vị trí.

Tìm hiểu thêm về giới hạn tốc độ cảm biến.

Trạng thái ngủ đông của ứng dụng

Android 12 mở rộng dựa trên hành vi tự động đặt lại quyền đã ra mắt trong Android 11 (API cấp 30). Nếu ứng dụng của bạn nhắm đến Android 12 và người dùng không tương tác với ứng dụng đó trong vài tháng, thì hệ thống sẽ tự động đặt lại mọi quyền đã cấp và đặt ứng dụng ở trạng thái ngủ đông.

Tìm hiểu thêm trong hướng dẫn về trạng thái ngủ đông của ứng dụng.

Khai báo mô hình phân bổ trong hoạt động kiểm tra quyền truy cập dữ liệu

API kiểm tra quyền truy cập dữ liệu, ra mắt trong Android 11 (API cấp 30), cho phép bạn tạo thẻ phân bổ dựa trên các trường hợp sử dụng của ứng dụng. Các thẻ này giúp bạn dễ dàng xác định phần nào trong ứng dụng thực hiện một loại quyền truy cập dữ liệu cụ thể.

Nếu ứng dụng nhắm đến Android 12 trở lên, bạn phải khai báo các thẻ phân bổ này trong tệp kê khai của ứng dụng.

Hạn chế sao lưu ADB

Để giúp bảo vệ dữ liệu ứng dụng riêng tư, Android 12 thay đổi hành vi mặc định của lệnh adb backup. Đối với các ứng dụng nhắm đến Android 12 (API cấp 31) trở lên, khi người dùng chạy lệnh adb backup, dữ liệu ứng dụng sẽ bị loại trừ khỏi mọi dữ liệu hệ thống khác được xuất qua thiết bị này.

Nếu quy trình kiểm thử hoặc phát triển của bạn phụ thuộc vào dữ liệu ứng dụng bằng adb backup, thì giờ đây, bạn có thể chọn xuất dữ liệu của ứng dụng bằng cách đặt android:debuggable thành true trong tệp kê khai của ứng dụng.

Xuất thành phần an toàn hơn

Nếu ứng dụng của bạn nhắm mục tiêu đến Android 12 trở lên và có chứa hoạt động, dịch vụ hoặc broadcast receiver sử dụng bộ lọc ý định, bạn phải khai báo rõ ràng thuộc tính android:exported cho các thành phần ứng dụng này.

Nếu thành phần ứng dụng bao gồm danh mục LAUNCHER, hãy đặt android:exported thành true. Trong hầu hết các trường hợp khác, hãy đặt android:exported thành false.

Đoạn mã sau đây cho thấy ví dụ về dịch vụ chứa bộ lọc ý định có thuộc tính android:exported được đặt thành false:

<service android:name="com.example.app.backgroundService"
         android:exported="false">
    <intent-filter>
        <action android:name="com.example.app.START_BACKGROUND" />
    </intent-filter>
</service>

Tin nhắn trong Android Studio

Nếu ứng dụng của bạn chứa một hoạt động, dịch vụ hoặc broadcast receiver sử dụng bộ lọc ý định nhưng không khai báo android:exported, thì các thông báo cảnh báo sau đây sẽ xuất hiện, tuỳ thuộc vào phiên bản Android Studio bạn sử dụng:

Android Studio 2020.3.1 Canary 11 trở lên

Các thông báo sau đây sẽ xuất hiện:

Cảnh báo tìm lỗi mã nguồn sau đây sẽ xuất hiện trong tệp kê khai của bạn:
```
When using intent filters, please specify android:exported as well
```

Khi bạn cố gắng biên dịch ứng dụng, thông báo lỗi bản dựng sau đây sẽ xuất hiện:

Manifest merger failed : Apps targeting Android 12 and higher are required \
to specify an explicit value for android:exported when the corresponding \
component has an intent filter defined.

Các phiên bản Android Studio cũ hơn

Nếu bạn cố cài đặt ứng dụng, Logcat sẽ cho thấy thông báo lỗi sau:

Installation did not succeed.
The application could not be installed: INSTALL_FAILED_VERIFICATION_FAILURE
List of apks:
[0] '.../build/outputs/apk/debug/app-debug.apk'
Installation failed due to: 'null'

Khả năng thay đổi ý định đang chờ xử lý

Nếu ứng dụng của bạn nhắm đến Android 12, bạn phải chỉ định khả năng biến đổi của từng đối tượng PendingIntent mà ứng dụng tạo ra. Yêu cầu bổ sung này giúp cải thiện tính bảo mật của ứng dụng.

Kiểm thử thay đổi về khả năng biến đổi ý định đang chờ xử lý

Để xác định xem ứng dụng của bạn có thiếu nội dung khai báo về khả năng biến đổi hay không, hãy tìm cảnh báo tìm lỗi mã nguồn sau trong Android Studio:

Warning: Missing PendingIntent mutability flag [UnspecifiedImmutableFlag]

Chạy ý định không an toàn

Để cải thiện khả năng bảo mật của nền tảng, Android 12 trở lên cung cấp tính năng gỡ lỗi để phát hiện việc khởi chạy ý định một cách không an toàn. Khi hệ thống phát hiện một hoạt động khởi chạy không an toàn như vậy, lỗi vi phạm StrictMode sẽ xảy ra.

Hiệu suất

Các hạn chế khi khởi động dịch vụ trên nền trước

Các ứng dụng nhắm đến Android 12 trở lên không thể bắt đầu dịch vụ trên nền trước trong khi chạy ở chế độ nền, ngoại trừ một số trường hợp đặc biệt. Nếu một ứng dụng cố khởi động một dịch vụ trên nền trước trong khi chạy ở chế độ nền, thì sẽ có ngoại lệ (ngoại trừ một vài trường hợp đặc biệt).

Cân nhắc sử dụng WorkManager để lên lịch và bắt đầu công việc ưu tiên trong khi ứng dụng của bạn chạy ở chế độ nền. Để hoàn tất các thao tác cần chính xác về thời gian mà người dùng yêu cầu, hãy bắt đầu các dịch vụ trên nền trước trong một chuông báo chính xác.

Quyền thông báo chính xác

Để khuyến khích ứng dụng tiết kiệm tài nguyên hệ thống, các ứng dụng nhắm đến Android 12 trở lên và đặt chuông báo chính xác phải có quyền sử dụng tính năng "Chuông báo và lời nhắc" xuất hiện trên màn hình Quyền truy cập đặc biệt của ứng dụng trong phần cài đặt hệ thống.

Để có được quyền truy cập đặc biệt này của ứng dụng, hãy yêu cầu quyền SCHEDULE_EXACT_ALARM trong tệp kê khai.

Bạn chỉ nên sử dụng chuông báo chính xác cho các tính năng dành cho người dùng. Tìm hiểu thêm về các trường hợp sử dụng được chấp nhận để đặt chuông báo chính xác.

Tắt thay đổi về hành vi

Khi chuẩn bị ứng dụng để nhắm đến Android 12, bạn có thể tạm thời tắt thay đổi về hành vi trong biến thể bản dựng có thể gỡ lỗi cho mục đích kiểm thử. Để làm như vậy, hãy hoàn thành một trong những việc sau:

Trên màn hình cài đặt Tuỳ chọn cho nhà phát triển, hãy chọn Thay đổi về khả năng tương thích của ứng dụng. Trên màn hình hiện ra, hãy nhấn vào tên ứng dụng của bạn rồi tắt REQUIRE_EXACT_ALARM_PERMISSION.
Trong cửa sổ dòng lệnh trên máy phát triển của bạn, hãy chạy lệnh sau:
```
adb shell am compat disable REQUIRE_EXACT_ALARM_PERMISSION PACKAGE_NAME
```

Các hạn chế về thành phần phản hồi với thao tác nhấn vào thông báo

Khi người dùng tương tác với thông báo, một số ứng dụng sẽ phản hồi các lượt nhấn vào thông báo bằng cách chạy một thành phần ứng dụng mà sau cùng sẽ bắt đầu hoạt động mà người dùng nhìn thấy và tương tác sau cùng. Thành phần ứng dụng này được gọi là thành phần phản hồi với thao tác nhấn vào thông báo (notification trampoline).

Để cải thiện hiệu suất và trải nghiệm người dùng của ứng dụng, các ứng dụng nhắm đến Android 12 trở lên không thể bắt đầu hoạt động từ những dịch vụ hoặc broadcast receiver dùng làm thành phần phản hồi với thao tác nhấn vào thông báo. Nói cách khác, sau khi người dùng nhấn vào một thông báo hoặc nút hành động trong thông báo, ứng dụng của bạn không thể gọi startActivity() bên trong một dịch vụ hoặc broadcast receiver.

Khi ứng dụng của bạn cố gắng bắt đầu một hoạt động từ một dịch vụ hoặc broadcast receiver đóng vai trò là thành phần phản hồi với thao tác nhấn vào thông báo, hệ thống sẽ ngăn hoạt động đó bắt đầu và thông báo sau đây sẽ xuất hiện trong Logcat:

Indirect notification activity start (trampoline) from PACKAGE_NAME, \
this should be avoided for performance reasons.

Xác định thành phần ứng dụng nào đóng vai trò là thành phần phản hồi với thao tác nhấn vào thông báo

Khi kiểm thử ứng dụng, sau khi nhấn vào một thông báo, bạn có thể xác định dịch vụ hoặc broadcast receiver đóng vai trò là thành phần phản hồi với thao tác nhấn vào thông báo trong ứng dụng. Để làm vậy, hãy xem kết quả của lệnh trong cửa sổ dòng lệnh sau đây:

adb shell dumpsys activity service \
  com.android.systemui/.dump.SystemUIAuxiliaryDumpService

Một phần của kết quả bao gồm văn bản "Notif AnalyticsLog". Phần này chứa thông tin cần thiết để xác định thành phần bắt đầu bằng việc nhấn vào thông báo.

Cập nhật ứng dụng

Nếu ứng dụng của bạn bắt đầu một hoạt động từ một dịch vụ hoặc broadcast receiver đóng vai trò là thành phần phản hồi với thao tác nhấn vào thông báo, hãy hoàn tất các bước di chuyển sau:

Tạo một đối tượng PendingIntent được liên kết với hoạt động mà người dùng thấy sau khi nhấn vào thông báo.
Sử dụng đối tượng PendingIntent mà bạn đã tạo ở bước trước trong quá trình tạo thông báo.

Để xác định nguồn gốc của hoạt động, chẳng hạn như để thực hiện ghi nhật ký, hãy sử dụng các dữ liệu bổ sung khi đăng thông báo. Để ghi nhật ký tập trung, hãy sử dụng ActivityLifecycleCallbacks hoặc trình quan sát vòng đời của Jetpack.

Bật/tắt hành vi

Khi kiểm thử một phiên bản có thể gỡ lỗi của ứng dụng, bạn có thể bật và tắt hạn chế này bằng cách sử dụng cờ tương thích của ứng dụng NOTIFICATION_TRAMPOLINE_BLOCK.

Sao lưu và khôi phục

Có những thay đổi về cách hoạt động của tính năng sao lưu và khôi phục trong những ứng dụng chạy và nhắm đến Android 12 (API cấp 31). Dịch vụ sao lưu và khôi phục trên Android có 2 dạng:

Sao lưu trên đám mây: Dữ liệu người dùng được lưu trữ trong Google Drive của người dùng để sau này bạn có thể khôi phục trên thiết bị đó hoặc thiết bị mới.
Chuyển từ thiết bị này sang thiết bị khác (D2D): Dữ liệu người dùng được gửi trực tiếp đến thiết bị mới của người dùng từ thiết bị cũ, chẳng hạn như bằng cách sử dụng cáp.

Để biết thêm thông tin về cách sao lưu và khôi phục dữ liệu, hãy xem bài viết Sao lưu dữ liệu người dùng bằng tính năng Tự động sao lưu và Sao lưu các cặp khoá-giá trị bằng Android Backup Service.

Các thay đổi về chức năng chuyển D2D

Đối với ứng dụng chạy trên và nhắm đến Android 12 trở lên:

Việc chỉ định các quy tắc bao gồm và loại trừ bằng cơ chế cấu hình XML không ảnh hưởng đến quá trình chuyển D2D, mặc dù vẫn ảnh hưởng đến tính năng sao lưu và khôi phục trên đám mây (chẳng hạn như bản sao lưu trên Google Drive). Để chỉ định quy tắc chuyển D2D, bạn phải sử dụng cấu hình mới được đề cập trong phần tiếp theo.
Trên thiết bị của một số nhà sản xuất thiết bị, việc chỉ định android:allowBackup="false" sẽ tắt tính năng sao lưu vào Google Drive, nhưng không tắt tính năng chuyển D2D đối với ứng dụng.

Định dạng bao gồm và loại trừ mới

Các ứng dụng chạy trên và nhắm đến Android 12 trở lên sẽ sử dụng một định dạng khác cho cấu hình XML. Định dạng này giúp tạo ra sự khác biệt rõ ràng giữa tính năng sao lưu Google Drive và tính năng chuyển D2D bằng cách yêu cầu bạn chỉ định các quy tắc bao gồm và loại trừ một cách riêng biệt cho hoạt động sao lưu trên đám mây và chuyển D2D.

Bạn cũng có thể sử dụng cấu hình này để chỉ định các quy tắc sao lưu. Trong trường hợp đó, cấu hình đã dùng trước đó sẽ bị bỏ qua trên các thiết bị chạy Android 12 trở lên. Các thiết bị chạy Android 11 trở xuống vẫn phải có cấu hình cũ.

Các thay đổi về định dạng XML

Sau đây là định dạng dùng cho cấu hình sao lưu và khôi phục trong Android 11 trở xuống:

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root"] path="string" />
</full-backup-content>

Sau đây là những thay đổi về định dạng được in đậm.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                        "root"] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Để biết thêm thông tin, hãy xem phần tương ứng trong hướng dẫn sao lưu dữ liệu người dùng bằng tính năng Tự động sao lưu.

Cờ tệp kê khai cho ứng dụng

Trỏ ứng dụng của bạn đến cấu hình XML mới bằng cách sử dụng thuộc tính android:dataExtractionRules trong tệp kê khai. Khi bạn trỏ đến cấu hình XML mới, thuộc tính android:fullBackupContent trỏ đến cấu hình cũ sẽ bị bỏ qua trên các thiết bị chạy Android 12 trở lên. Mã mẫu sau đây cho thấy các mục nhập tệp kê khai mới:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>

Khả năng kết nối

Quyền truy cập Bluetooth

Android 12 giới thiệu các quyền BLUETOOTH_SCAN, BLUETOOTH_ADVERTISE và BLUETOOTH_CONNECT. Các quyền này giúp các ứng dụng nhắm đến Android 12 tương tác với thiết bị Bluetooth dễ dàng hơn, đặc biệt là đối với các ứng dụng không yêu cầu quyền truy cập vào thông tin vị trí của thiết bị.

Để chuẩn bị thiết bị nhắm đến Android 12 trở lên, hãy cập nhật logic của ứng dụng. Thay vì khai báo một nhóm quyền Bluetooth cũ, hãy khai báo nhóm quyền Bluetooth hiện đại hơn.

Kết nối Internet và ngang hàng đồng thời

Đối với các ứng dụng nhắm đến Android 12 (API cấp 31) trở lên, những thiết bị hỗ trợ kết nối Internet và kết nối ngang hàng đồng thời có thể duy trì kết nối Wi-Fi đồng thời cho cả thiết bị ngang hàng và mạng cung cấp Internet chính, giúp trải nghiệm người dùng liền mạch hơn. Các ứng dụng nhắm đến Android 11 (API cấp 30) trở xuống vẫn gặp phải hành vi cũ, trong đó mạng Wi-Fi chính bị ngắt kết nối trước khi kết nối với thiết bị ngang hàng.

Khả năng tương thích

WifiManager.getConnectionInfo() có thể chỉ trả về WifiInfo cho một mạng duy nhất. Do đó, hành vi của API đã được thay đổi theo những cách sau trong Android 12 trở lên:

Nếu chỉ có một mạng Wi-Fi duy nhất, thì WifiInfo của mạng đó sẽ được trả về.
Nếu có nhiều mạng Wi-Fi và ứng dụng gọi đã kích hoạt kết nối ngang hàng, thì WifiInfo tương ứng với thiết bị ngang hàng sẽ được trả về.
Nếu có nhiều mạng Wi-Fi và ứng dụng gọi không kích hoạt kết nối ngang hàng, thì WifiInfo của thiết bị cung cấp kết nối Internet chính sẽ được trả về.

Để mang lại trải nghiệm tốt hơn cho người dùng trên các thiết bị hỗ trợ mạng Wi-Fi đồng thời kép, tất cả ứng dụng (đặc biệt là những ứng dụng kích hoạt kết nối ngang hàng) không nên gọi WifiManager.getConnectionInfo() và chuyển sang sử dụng NetworkCallback.onCapabilitiesChanged() để nhận tất cả đối tượng WifiInfo khớp với NetworkRequest dùng để đăng ký NetworkCallback. Kể từ Android 12, getConnectionInfo() sẽ không được dùng nữa.

Mã mẫu sau đây cho biết cách lấy WifiInfo trong NetworkCallback:

Kotlin

val networkCallback = object : ConnectivityManager.NetworkCallback() {
  ...
  override fun onCapabilitiesChanged(
           network : Network,
           networkCapabilities : NetworkCapabilities) {
    val transportInfo = networkCapabilities.getTransportInfo()
    if (transportInfo !is WifiInfo) return
    val wifiInfo : WifiInfo = transportInfo
    ...
  }
}

Java

final NetworkCallback networkCallback = new NetworkCallback() {
  ...
  @Override
  public void onCapabilitiesChanged(
         Network network,
         NetworkCapabilities networkCapabilities) {
    final TransportInfo transportInfo = networkCapabilities.getTransportInfo();
    if (!(transportInfo instanceof WifiInfo)) return;
    final WifiInfo wifiInfo = (WifiInfo) transportInfo;
    ...
  }
  ...
};

API gốc mDNSResponder

Android 12 thay đổi thời điểm các ứng dụng có thể tương tác với trình nền mDNSResponseer bằng API gốc mDNSResponder. Trước đây, khi một ứng dụng đăng ký một dịch vụ trên mạng và gọi phương thức getSystemService(), dịch vụ NSD của hệ thống đã khởi động trình nền mDNS Responseer, ngay cả khi ứng dụng chưa gọi phương thức NsdManager nào. Sau đó, trình nền đã đăng ký thiết bị với các nhóm phát đa hướng tất cả các nút, khiến hệ thống bật thường xuyên hơn và sử dụng thêm nguồn điện. Để giảm thiểu mức sử dụng pin, trong Android 12 trở lên, hệ thống hiện chỉ khởi động trình nền mDNSResponder khi cần thiết cho các sự kiện NSD và sẽ dừng sau đó.

Do thay đổi này ảnh hưởng đến thời điểm trình nền mDNS Responseer có thể hoạt động, nên những ứng dụng giả định rằng trình nền mDNSResponder sẽ khởi động sau khi gọi phương thức getSystemService() có thể nhận được thông báo từ hệ thống cho biết rằng trình nền mDNSResolveer không hoạt động. Những ứng dụng dùng NsdManager và không dùng API gốc mDNSResponder sẽ không chịu ảnh hưởng của thay đổi này.

Thư viện nhà cung cấp

Thư viện dùng chung gốc do nhà cung cấp cung cấp

Không thể truy cập theo mặc định thư viện gốc dùng chung không phải NDK do nhà cung cấp silicon hoặc nhà sản xuất thiết bị cung cấp nếu ứng dụng đang nhắm mục tiêu Android 12 (API cấp 31) trở lên. Bạn chỉ có thể truy cập vào thư viện khi chúng được yêu cầu rõ ràng sử dụng thẻ <uses-native-library>.

Nếu ứng dụng nhắm đến Android 11 (API cấp 30) trở xuống, thì bạn không bắt buộc phải sử dụng thẻ <uses-native-library>. Trong trường hợp đó, mọi thư viện gốc dùng chung đều có thể truy cập được, bất kể đó là thư viện NDK.

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

Android 12 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 12, 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, 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 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 12. Để tìm hiểu thêm về giao diện không phải SDK nói chung, hãy xem Hạn chế đối với giao diện không phải SDK.