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:
![](https://developer.android.com/static/images/about/versions/12/custom-collapsed-view.png?authuser=19&hl=vi)
![](https://developer.android.com/static/images/about/versions/12/custom-expanded-view.png?authuser=19&hl=vi)
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.
Bật thay đổi về thông báo tuỳ chỉnh:
- Thay đổi
targetSdkVersion
của ứng dụng thànhS
để cho phép hành vi mới. - Biên dịch lại.
- 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.
- Thay đổi
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ụngsetBigCustomContentView
để đả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ì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](https://developer.android.com/static/images/toast.png?authuser=19&hl=vi)
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ínhSecure
, 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:
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 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:
- 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 . - 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
:
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 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 .