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 sau đây về hành vi 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 là nhắm đến Android 12, bạn nên sửa đổi ứng dụng của mình để 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, 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ặp 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 ứng dụng nhắm đến Android 12, thông báo có lượt xem nội dung tuỳ chỉnh sẽ không sử dụng khu vực thông báo đầy đủ; thay vào đó, hệ thống sẽ áp dụng một tiêu chuẩn mẫu. Mẫu này đảm bảo rằng các thông báo tuỳ chỉnh có cùng trang trí như các thông báo khác ở tất cả các trạng thái, chẳng hạn như biểu tượng thông báo và các thành phần mở rộng (ở trạng thái thu gọn) cũng như biểu tượng của thông báo, tên ứng dụng và thành phần thu gọn (ở 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ề mặt hình ảnh và dễ dàng để người dùng dễ dàng nhận biết và mở rộng thông báo 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ị ở định dạng thu gọn và trạng thái mở rộng:

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

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

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

2. Thử nghiệm tất cả các thông báo sử dụng khung hiển thị tuỳ chỉnh để đảm bảo các thông báo đó hiển thị giống bạn trong bóng râm. Khi thử nghiệm, hãy tính đến những yếu tố 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 thấp hơn trước đây. Trong cửa sổ thu gọn trạng thái, chiều cao tối đa của nội dung tùy chỉnh đã giảm từ 106dp lên 48 dp. 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 bạn đang sử dụng setCustomContentView, bạn cũng cầ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 rằng nút "Quan sát xung quanh" trạng thái 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" (Bật lê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ẽ một số thay đổi về cách Đường liên kết trong ứng dụng Android đã xác minh. Các những thay đổi này sẽ giúp cải thiện độ tin cậy của trải nghiệm liên kết ứng dụng và cung cấp thêm nhiều lợi ích quyền kiểm soát cho nhà phát triển ứng dụng và người dùng cuối.

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

Bạn cũng có thể theo cách thủ công xác minh đường liên kết của ứng dụng để kiểm tra độ 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ải tiến về mặt thẩm mỹ để chuyển đổi ảnh động cho cả hai cử chỉ điều hướng và điều hướng dựa trên phần tử.

Xem phần Hình trong hình cải tiến để tìm hiểu thêm của bạn.

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 các công cụ mới. Thông báo ngắn hiện được giới hạn trong 2 dòng văn bản và cho thấy ứng dụng bên cạnh văn bản.

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.

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 vị trí ước chừng độ chính xác cho ứng dụng của mình.

Cookie SameSite hiện đại trong WebView

Thành phần WebView của Android dựa trên Chromium, dự án nguồn mở hỗ trợ trình duyệt Chrome của Google. Ra mắt Chromium những thay đổi đối với cách xử lý cookie của bên thứ ba nhằm 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 sự minh bạch và quyền kiểm soát nhiều hơn. Kể từ Android 12, những thay đổi này cũng được đưa vào WebView khi ứng dụng nhắm mục tiêu 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 này cùng với bất kỳ cookie nào hoặc chỉ với các yêu cầu cùng một trang web. Các biện pháp bảo vệ quyền riêng tư sau đây Những thay đổi nà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 bảo vệ 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à chúng cần có ngữ cảnh bảo mật và nên được gửi qua HTTPS.
• Hiện tại, các đường liên kết giữa phiên bản HTTP và HTTPS của một trang web được coi là nhiều trang web để cookie sẽ không được gửi trừ khi chúng được đánh dấu thích hợp là SameSite=None; Secure.

Đối với nhà phát triển, hướng dẫn chung là xác định cookie trên nhiều trang web các phần phụ thuộc trong luồng người dùng trọng yếu và đảm bảo rằng SameSite được đặt rõ ràng cù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 tham khảo phần Cookie SameSite Giải thích và Lịch sự 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 nếu bạn quản lý một trang web hoặc dịch vụ sử dụng cookie, bạn nên kiểm thử quy trình của mình trên WebView trên Android 12. Nếu gặp vấn đề, bạn có thể phải cập nhật cookie để hỗ trợ hành vi của SameSite.

Chú ý đến các vấn đề về việc đă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 bằng một lần truy cập không an toàn và chuyển đổi 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 hành vi SameSite mới cho ứng dụng mà bạn muốn kiểm thử bằng cách hoàn tất một trong các bước sau:

• Bật các hành vi SameSite trên thiết bị thử nghiệm theo cách thủ công bằng cách nhấp vào 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 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 bằng thiết bị Android Gỡ lỗi từ xa.

Tài nguyên khác

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

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

Để bảo vệ thông tin có thể mang tính nhạy cảm về người dùng, nếu ứng dụng của bạn nhắm đến Trên Android 12 trở lên, hệ thống sẽ đặt giới hạn về quá trình làm mới tốc độ 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ề cảm biến giới hạn số lượng yêu cầu.

Trạng thái ngủ đông của ứng dụng

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

Tìm hiểu thêm trong hướng dẫn về ứng dụng ngủ đô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 mô hình phân bổ dựa trên các trường hợp sử dụng của ứng dụng. Những thẻ này giúp bạn dễ dàng xác định phần nào của ứng dụng của bạn thực hiện một loại truy cập dữ liệu cụ thể.

Nếu ứng dụng của bạn nhắm đến Android 12 trở lên, bạn phải khai báo các thông tin này các thẻ phân bổ ở 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 ứ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 được xuất từ thiết bị đó.

Nếu quy trình kiểm thử hoặc phát triển của bạn dựa vào dữ liệu ứng dụng bằng adb backup, bạn hiện có thể chọn tham gia xuất dữ liệu ứng dụng của mình bằng cách cài đặt android:debuggable vào 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 đến Android 12 trở lên và chứa hoạt động, services hoặc broadcast những receiver sử dụng ý định , bạn phải thể hiện rõ khai báo 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, đã đặt android:exported đến 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 ý định bộ lọc 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, cảnh báo sau 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:

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

2. 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 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 này, Logcat sẽ hiện 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 mục tiêu đến Android 12, bạn phải chỉ định khả năng biến đổi của từng đối tượng PendingIntent mà 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 sau đây là cảnh báo tìm lỗi mã nguồn 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 giúp phát hiện hoạt động khởi chạy không an toàn ý định. Thời gian hệ thống phát hiện thấy một hoạt động khởi chạy không an toàn như vậy, Xảy ra lỗi vi phạm StrictMode.

Hiệu suất

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

Ứng dụng nhắm đến Android 12 trở lên không thể bắt đầu chạy trên nền trước trong khi chạy trong nền, ngoại trừ một vài điều đặc biệt trường hợp. 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 trong thì có một ngoại lệ sẽ xảy ra (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 ưu tiên cơ quan trong khi ứng dụng của bạn chạy ở chế độ nền. Để hoàn tất các hành động có giới hạn thời gian 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 phạm vi chính xác chuông báo.

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, hãy dùng những ứng dụng nhắm đến Android 12 trở lên và đặt chính xác báo thức phải có quyền truy cập vào phần "Báo thức và lời nhắc" chức năng xuất hiện trong màn hình Quyền truy cập đặc biệt trong phần cài đặt hệ thống.

Để có được quyền truy cập đặc biệt này vào ứng dụng, hãy yêu cầu SCHEDULE_EXACT_ALARM quyền 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ề chính sách trường hợp sử dụng có thể chấp nhận được khi đặt giá trị chính xác chuông báo.

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 bản dựng có thể gỡ lỗi của bạn biến thể cho mục đích thử nghiệm. Để làm như vậy, hãy hoàn tất một trong những nhiệm vụ sau:

• Trên màn hình cài đặt Tuỳ chọn cho nhà phát triển, hãy chọn Khả năng tương thích của ứng dụng Thay đổi. Trên màn hình xuất hiện, hãy nhấn vào tên của ứng dụng 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 nhấn vào thông báo bằng cách chạy một ứng dụng mà cuối cùng sẽ khởi động hoạt động mà người dùng nhìn thấy và tương tác cuối cùng. Thành phần ứng dụng này là đượ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, những ứng dụng nhắm đến Android 12 hoặc cao hơn không thể bắt đầu hoạt động từ dịch vụ hoặc broadcast receiver được 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 một 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 hoạt động như một 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 này bắt đầu và thông báo sau 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

Trong quá trình thử nghiệm ứ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 của bạn. Để thực hiện việc này, hãy xem kết quả của lệnh trong 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 do một lần 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:

1. 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 họ nhấn vào .
2. Sử dụng đối tượng PendingIntent mà bạn đã tạo ở bước trước làm một phần của xây dựng 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ý, sử dụng tiện ích 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 tính năng 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 đối với 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 trên và nhắm mục tiêu 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 để có thể được khôi phục trên thiết bị đó hoặc thiết bị mới sau này.
• 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ũ của họ, 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 người dùng dữ liệu bằng tính năng Tự động sao lưu và Sao lưu 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:

• Chỉ định các quy tắc bao gồm và loại trừ bằng XML cơ chế cấu hình không ảnh hưởng đến việc chuyển D2D, mặc dù cơ chế này 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). Người nhận 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 các thiết bị của một số nhà sản xuất thiết bị, việc chỉ định android:allowBackup="false" có 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 cho ứng dụng.

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

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

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

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 tới 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 của bạn . 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 của tệp kê khai:

<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 ra mắt BLUETOOTH_SCAN! BLUETOOTH_ADVERTISE, và BLUETOOTH_CONNECT quyền truy cập. Những quyền này giúp những ứng dụng nhắm đến Android 12 để tương tác với Bluetooth thiết bị, đặc biệt là đối với những ứ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ị cho việc 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 bộ Bluetooth cũ quyền truy cập, khai báo một nhóm Bluetooth hiện đại hơn quyền truy cập.

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

Đối với ứng dụng nhắm đến Android 12 (API cấp 31) trở lên, những thiết bị hỗ trợ đồng thời kết nối ngang hàng và kết nối Internet có thể duy trì kết nối Wi-Fi kết nối tới cả thiết bị ngang hàng và mạng cung cấp Internet chính, giúp người dùng có trải nghiệm liền mạch hơn. Nhắm mục tiêu theo ứng dụng 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 mạng ngang hàng thiết bị.

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

WifiManager.getConnectionInfo() có thể trả về WifiInfo cho chỉ một mạng. Do đó, hành vi của API đã thay đổi trong các 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 một kết nối ngang hàng, thì WifiInfo tương ứng với thiết bị ngang hàng sẽ là bị trả lại.
• Nếu có nhiều mạng Wi-Fi và ứng dụng gọi thì không hoạt động kích hoạt kết nối ngang hàng, dịch vụ cung cấp kết nối Internet chính Trả về WifiInfo.

Để 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ợ đồng thời kép Mạng Wi-Fi, bạn nên sử dụng tất cả các ứng dụng, đặc biệt là những ứng dụng kích hoạt kết nối ngang hàng – di chuyển khỏi tính năng gọi điện WifiManager.getConnectionInfo() và thay vào đó, hãy sử dụng NetworkCallback.onCapabilitiesChanged() để lấy tất cả đối tượng WifiInfo khớp với NetworkRequest dùng để đăng ký NetworkCallback. getConnectionInfo() không còn được dùng nữa kể từ Android 12.

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

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

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 mDNSNếu bạn. Trước đây, khi một ứng dụng đăng ký một dịch vụ trên mạng lưới và gọi getSystemService() , dịch vụ NSD của hệ thống đã khởi động trình nền mDNSResponder, ngay cả khi ứng dụng chưa gọi bất kỳ phương thức NsdManager nào. Sau đó, daemon đã đăng ký thiết bị sang các nhóm phát đa hướng tất cả các nút, khiến hệ thống bật nhiều hơn thường xuyên và sử dụng nguồn điện bổ sung. Để giảm thiểu mức sử dụng pin, trong Android 12 lên cao hơn, hệ thống giờ đây chỉ khởi động trình nền mDNSResponder khi cần cho các sự kiện NSD và dừng sau đó.

Do thay đổi này ảnh hưởng đến thời điểm trình nền mDNSResponder có sẵn, nên các ứng dụng giả định rằng daemon mDNSResponder sẽ được khởi động sau khi gọi lệnh Phương thức getSystemService() có thể nhận thông báo từ hệ thống cho biết rằng trình nền mDNSResponder không hoạt động. Ứng dụng sử dụng NsdManager và không sử dụng sử 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

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

Nếu ứng dụng nhắm đến Android 11 (API cấp 30) trở xuống, Không bắt buộc phải có thẻ <uses-native-library>. Trong trường hợp đó, bất kỳ quảng cáo gốc nào đã chia sẻ thư viện 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ề 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 12, 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), việc sử dụng phương thức hoặc trường không phải SDK nào cũng có nguy cơ cao làm hỏ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 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 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 .