Nền tảng 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 áp dụng cho tất cả ứng dụng khi chạy trên Android 12, bất kể targetSdkVersion. Bạn nên kiểm thử ứng dụng rồi sửa đổi để hỗ trợ những thay đổi này cho phù hợp (nếu cần).
Ngoài ra, hãy nhớ tham khảo danh sách các thay đổi về hành vi chỉ ảnh hưởng đến những ứng dụng nhắm đến Android 12.
Trải nghiệm người dùng
Hiệu ứng kéo giãn khi cuộn xuống cuối cùng
Trên các thiết bị chạy Android 12 trở lên, hành vi trực quan cho các sự kiện cuộn quá mức sẽ thay đổi.
Trên Android 11 trở xuống, sự kiện cuộn quá mức khiến các phần tử trực quan phát sáng; trên Android 12 trở lên, các phần tử trực quan sẽ kéo giãn và bật lại trong sự kiện kéo, đồng thời chúng sẽ hất và bật lại trong sự kiện hất.
Để biết thêm thông tin, hãy xem hướng dẫn về cách tạo ảnh động cho cử chỉ cuộn.
Màn hình chờ của ứng dụng
Nếu trước đây bạn đã triển khai màn hình chờ tuỳ chỉnh trong Android 11 trở xuống, thì bạn cần di chuyển ứng dụng của mình sang API SplashScreen để đảm bảo màn hình chờ hiển thị chính xác từ Android 12 trở đi. Nếu không di chuyển ứng dụng, bạn sẽ có trải nghiệm khởi chạy ứng dụng kém chất lượng hoặc không mong muốn.
Để biết hướng dẫn, hãy xem bài viết Di chuyển hoạt động triển khai màn hình chờ hiện có sang Android 12.
Ngoài ra, kể từ Android 12, hệ thống luôn áp dụng màn hình chờ mới theo mặc định của hệ thống Android khi khởi động lạnh và khởi động ấm cho tất cả ứng dụng.
Theo mặc định, màn hình chờ mặc định của hệ thống được tạo bằng phần tử biểu tượng trình chạy
của ứng dụng và
windowBackground của giao diện (nếu là màu đơn).
Để biết thêm thông tin chi tiết, hãy xem hướng dẫn dành cho nhà phát triển về màn hình chờ.
Phân giải ý định trên web
Kể từ Android 12 (API cấp 31), ý định chung trên web chỉ phân giải thành một hoạt động trong ứng dụng của bạn nếu ứng dụng đó được phê duyệt cho miền cụ thể có trong ý định đó trên web. Nếu ứng dụng của bạn không được phê duyệt cho miền này, thì ý định trên web sẽ chuyển sang ứng dụng trình duyệt mặc định của người dùng.
Các ứng dụng có thể nhận được sự phê duyệt này bằng cách thực hiện một trong những cách sau:
Xác minh miền bằng Đườ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ẽ thay đổi cách tự động xác minh Android App Links của ứng dụng. Trong bộ lọc ý định của ứng dụng, hãy kiểm tra để đảm bảo rằng bạn thêm danh mục
BROWSABLEvà hỗ trợ lược đồhttps.Trên Android 12 trở lên, bạn có thể xác minh theo cách thủ công Android App Links của ứng dụng để kiểm thử xem logic mới cập nhật này ảnh hưởng đến ứng dụng của bạn như thế nào.
Yêu cầu người dùng liên kết ứng dụng của bạn với miền trong phần cài đặt hệ thống.
Nếu ứng dụng của bạn gọi ý định trên web, hãy cân nhắc việc thêm một lời nhắc hoặc hộp thoại yêu cầu người dùng xác nhận hành động.
Cải tiến chế độ sống động cho chế độ thao tác bằng cử chỉ
Android 12 hợp nhất hành vi hiện có để người dùng dễ dàng thực hiện các lệnh thao tác bằng cử chỉ khi ở chế độ sống động. Ngoài ra, Android 12 còn cung cấp hành vi tương thích ngược cho chế độ hiển thị toàn màn hình cố định.
Display#getRealSize và getRealMetrics: ngừng sử dụng và các ràng buộc
Thiết bị Android có nhiều kiểu dáng, chẳng hạn như màn hình lớn, máy tính bảng và thiết bị có thể gập lại. Để hiển thị nội dung phù hợp cho từng thiết bị, ứng dụng của bạn cần xác định kích thước màn hình hoặc kích thước hiển thị. Theo thời gian, Android đã cung cấp nhiều API để truy xuất thông tin này. Trong Android 11, chúng tôi đã ra mắt API WindowMetrics và ngừng sử dụng các phương thức sau:
Trong Android 12, chúng tôi vẫn khuyến khích bạn sử dụng WindowMetrics và sẽ ngừng sử dụng các phương thức sau:
Để giảm thiểu hành vi của các ứng dụng sử dụng Display API để truy xuất giới hạn của ứng dụng, Android 12 sẽ hạn chế các giá trị mà API trả về cho những ứng dụng không thể thay đổi kích thước hoàn toàn. Điều này có thể ảnh hưởng đến những ứng dụng đang sử dụng thông tin này với MediaProjection.
Các ứng dụng nên sử dụng API WindowMetrics để truy vấn ranh giới của cửa sổ và Configuration.densityDpi để truy vấn mật độ hiện tại.
Để có khả năng tương thích rộng hơn với các phiên bản Android cũ, bạn có thể sử dụng thư viện Jetpack WindowManager. Thư viện này bao gồm một lớp WindowMetrics hỗ trợ Android 4.0 (API cấp 14) trở lên.
Ví dụ về cách sử dụng WindowMetrics
Trước tiên, hãy đảm bảo các hoạt động của ứng dụng có thể thay đổi kích thước hoàn toàn.
Hoạt động phải dựa vào WindowMetrics từ ngữ cảnh hoạt động cho mọi công việc liên quan đến giao diện người dùng, đặc biệt là WindowManager.getCurrentWindowMetrics() hoặc WindowMetricsCalculator.computeCurrentWindowMetrics() của Jetpack.
Nếu ứng dụng của bạn tạo một MediaProjection, thì các ranh giới phải có kích thước chính xác vì hình chiếu sẽ ghi lại phân vùng màn hình mà ứng dụng máy chiếu đang chạy.
Nếu ứng dụng có thể thay đổi kích thước hoàn toàn, thì bối cảnh hoạt động sẽ trả về ranh giới chính xác như sau:
Kotlin
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
Nếu không thể thay đổi kích thước hoàn toàn, ứng dụng phải truy vấn từ một thực thể WindowContext và truy xuất WindowMetrics của ranh giới hoạt động bằng WindowManager.getMaximumWindowMetrics() hoặc phương thức Jetpack WindowMetricsCalculator.computeMaximumWindowMetrics().
Kotlin
val windowContext = context.createWindowContext(mContext.display!!, WindowManager.LayoutParams.TYPE_APPLICATION, null) val projectionMetrics = windowContext.getSystemService(WindowManager::class.java) .maximumWindowMetrics
Java
Context windowContext = context.createWindowContext(mContext.getDisplay(), WindowManager.LayoutParams.TYPE_APPLICATION, null); WindowMetrics projectionMetrics = windowContext.getSystemService(WindowManager.class) .getMaximumWindowMetrics();
Tất cả ứng dụng ở chế độ nhiều cửa sổ
Android 12 đưa chế độ nhiều cửa sổ trở thành hành vi tiêu chuẩn.
Trên màn hình lớn (sw >= 600dp), nền tảng hỗ trợ chế độ nhiều cửa sổ đối với tất cả các ứng dụng, bất kể cấu hình ứng dụng là gì. Nếu là resizeableActivity="false", ứng dụng sẽ được đưa vào chế độ tương thích khi cần thiết để phù hợp với kích thước màn hình.
Trên màn hình nhỏ (sw < 600dp), hệ thống sẽ kiểm tra minWidth và minHeight của một hoạt động để xác định xem hoạt động đó có thể chạy ở chế độ nhiều cửa sổ hay không. Nếu resizeableActivity="false", ứng dụng sẽ không thể chạy ở chế độ nhiều cửa sổ, bất kể chiều rộng và chiều cao tối thiểu.
Để biết thêm thông tin, hãy xem bài viết Hỗ trợ nhiều cửa sổ.
Bản xem trước máy ảnh trên màn hình lớn
Các ứng dụng máy ảnh thường giả định mối quan hệ cố định giữa hướng của thiết bị và tỷ lệ khung hình của bản xem trước máy ảnh. Tuy nhiên, các kiểu dáng màn hình lớn (chẳng hạn như thiết bị có thể gập lại) và các chế độ hiển thị (chẳng hạn như nhiều cửa sổ và nhiều màn hình) lại thách thức giả định đó.
Trên Android 12, các ứng dụng máy ảnh yêu cầu một hướng màn hình cụ thể và không thể đổi kích thước (resizeableActivity="false") sẽ tự động chuyển sang chế độ dọc có phần lồng ghép. Chế độ này đảm bảo hướng và tỷ lệ khung hình phù hợp của bản xem trước camera. Trên các thiết bị có thể gập lại và các thiết bị khác có lớp trừu tượng phần cứng (HAL) của camera, chế độ xoay bổ sung sẽ được áp dụng cho đầu ra của camera để bù cho hướng cảm biến của camera và đầu ra của camera sẽ bị cắt để phù hợp với tỷ lệ khung hình của bản xem trước camera của ứng dụng. Việc cắt và xoay thêm đảm bảo bản xem trước của camera được trình bày đúng cách, bất kể hướng thiết bị và trạng thái gập hoặc mở của thiết bị.
Độ trễ UX cho thông báo về dịch vụ trên nền trước
Để mang lại trải nghiệm tinh giản cho các dịch vụ trên nền trước chạy trong thời gian ngắn, các thiết bị chạy Android 12 trở lên có thể trì hoãn việc hiển thị thông báo dịch vụ trên nền trước trong 10 giây, với một số trường hợp ngoại lệ. Thay đổi này giúp các tác vụ tồn tại trong thời gian ngắn có cơ hội hoàn tất trước khi thông báo xuất hiện.
Hiệu suất
Nhóm chế độ chờ cho ứng dụng bị hạn chế
Android 11 (API cấp 30) đã ra mắt nhóm bị hạn chế dưới dạng một Nhóm chế độ chờ ứng dụng. Kể từ Android 12, vùng chứa này sẽ hoạt động theo mặc định. Bộ chứa bị hạn chế có mức độ ưu tiên thấp nhất (và các hạn chế cao nhất) trong tất cả các bộ chứa. Các bộ chứa theo thứ tự ưu tiên từ cao đến thấp là:
- Đang hoạt động: Ứng dụng hiện đang được sử dụng hoặc đã được sử dụng gần đây.
- Nhóm hoạt động: Ứng dụng được dùng thường xuyên.
- Thường xuyên: Ứng dụng thường được sử dụng, nhưng không phải mỗi ngày.
- Hiếm gặp: Ứng dụng không được sử dụng thường xuyên.
- Bị hạn chế: Ứng dụng tiêu tốn nhiều tài nguyên của hệ thống, hoặc có thể có hành vi không mong muốn.
Ngoài kiểu sử dụng, hệ thống sẽ xem xét hành vi của ứng dụng để quyết định xem có nên đặt ứng dụng của bạn vào bộ chứa bị hạn chế hay không.
Ứng dụng của bạn ít có khả năng được đưa vào bộ chứa bị hạn chế nếu nó sử dụng tài nguyên hệ thống có trách nhiệm hơn. Ngoài ra, hệ thống sẽ đặt ứng dụng của bạn vào một bộ chứa ít hạn chế hơn nếu người dùng tương tác trực tiếp với ứng dụng của bạn.
Kiểm tra xem ứng dụng của bạn có nằm trong bộ chứa bị hạn chế hay không
Để kiểm tra xem hệ thống có đặt ứng dụng của bạn vào bộ chứa bị hạn chế hay không, hãy gọi getAppStandbyBucket().
Nếu giá trị trả về của phương thức này là STANDBY_BUCKET_RESTRICTED, thì ứng dụng của bạn nằm trong bộ chứa bị hạn chế.
Kiểm thử hành vi của bộ chứa bị hạn chế
Để kiểm thử cách ứng dụng của bạn hoạt động khi hệ thống đặt ứng dụng của bạn vào bộ chứa bị hạn chế, bạn có thể di chuyển ứng dụng của mình vào bộ chứa đó theo cách thủ công. Để thực hiện việc này, hãy chạy lệnh sau trong cửa sổ dòng lệnh:
adb shell am set-standby-bucket PACKAGE_NAME restricted
Quyền truy cập thông tin vị trí ở chế độ nền trước và Trình tiết kiệm pin
Kể từ Android 12, thông tin vị trí ở nền trước (kể cả thông tin vị trí từ một dịch vụ ở nền trước) có thể tiếp tục được cung cấp trong khi Trình tiết kiệm pin đang hoạt động, ngay cả khi màn hình tắt.
Trước đây, chế độ Trình tiết kiệm pin sẽ dừng cập nhật vị trí khi màn hình tắt. Thay đổi này giúp người dùng tiết kiệm pin hơn và có nghĩa là nhà phát triển có thể không cần yêu cầu người dùng tắt Trình tiết kiệm pin để đảm bảo việc cung cấp vị trí.
Những ứng dụng yêu cầu thông tin vị trí thông qua một dịch vụ trên nền trước phải thực hiện các bước sau:
- Gọi
getLocationPowerSaverMode()để kiểm tra cách các tính năng vị trí của thiết bị hoạt động khi Trình tiết kiệm pin đang hoạt động. - Nếu phương thức này trả về
LOCATION_MODE_FOREGROUND_ONLY, ứng dụng của bạn sẽ tiếp tục nhận được thông tin cập nhật vị trí khi ở nền trước hoặc chạy một dịch vụ trên nền trước trong khi Chế độ tiết kiệm pin đang bật và màn hình đang tắ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 ứng dụng của bạn chỉ có quyền truy cập vào thông tin vị trí ước chừng.
Nếu ứng dụng của bạn yêu cầu quyền khi bắt đầu chạy ACCESS_FINE_LOCATION, bạn cũng nên yêu cầu quyền ACCESS_COARSE_LOCATION để xử lý trường hợp người dùng cấp quyền truy cập thông tin vị trí gần đúng cho ứng dụng của bạn. Bạn nên đưa cả hai quyền này vào một yêu cầu khi bắt đầu chạy.
Hộp thoại cấp quyền của hệ thống có các lựa chọn sau đây cho người dùng, như minh hoạ trong hình 1:
- Chính xác: Cung cấp quyền truy cập vào thông tin vị trí chính xác.
- Gần đúng: Chỉ cung cấp quyền truy cập vào thông tin vị trí gần đúng.
Nút bật/tắt micrô và camera
Các thiết bị được hỗ trợ chạy Android 12 trở lên cho phép người dùng bật và tắt quyền truy cập vào máy ảnh và micrô của tất cả ứng dụng trên thiết bị bằng cách nhấn vào một tuỳ chọn bật/tắt. Người dùng có thể truy cập vào các tuỳ chọn bật/tắt từ trình đơn Cài đặt nhanh (như minh hoạ trong hình 1) hoặc từ màn hình Quyền riêng tư trong phần cài đặt hệ thống.
Tìm hiểu thêm về các nút bật/tắt này và cách kiểm tra để đảm bảo ứng dụng của bạn tuân thủ các phương pháp hay nhất liên quan đến quyền CAMERA và RECORD_AUDIO.
Chỉ báo camera và micrô
Trên các thiết bị chạy Android 12 trở lên, khi một ứng dụng truy cập vào micrô hoặc máy ảnh, một biểu tượng sẽ xuất hiện trên thanh trạng thái.
Tìm hiểu thêm về những chỉ báo này và cách kiểm tra để đảm bảo ứng dụng của bạn tuân thủ các phương pháp hay nhất liên quan đến quyền CAMERA và RECORD_AUDIO.
Quyền xem dữ liệu ứng dụng theo gói
Trên các thiết bị chạy Android 12 trở lên, những ứng dụng nhắm đến Android 11 (API cấp 30) trở lên và gọi một trong các phương thức sau sẽ nhận được một tập hợp kết quả đã lọc, dựa trên khả năng hiển thị gói của ứng dụng đối với các ứng dụng khác:
Đã xoá việc triển khai BouncyCastle
Android 12 xoá nhiều phương thức triển khai BouncyCastle của các thuật toán mật mã đã ngừng hoạt động trước đó, bao gồm cả tất cả các thuật toán AES. Thay vào đó, hệ thống sẽ sử dụng các phương thức triển khai Conscrypt của các thuật toán này.
Thay đổi này ảnh hưởng đến ứng dụng của bạn nếu có bất kỳ trường hợp nào sau đây:
- Ứng dụng của bạn sử dụng kích thước khoá 512 bit. Conscrypt không hỗ trợ kích thước khoá này. Nếu cần, hãy cập nhật logic mật mã của ứng dụng để sử dụng các kích thước khoá khác nhau.
Ứng dụng của bạn sử dụng kích thước khoá không hợp lệ với
KeyGenerator. Việc triển khaiKeyGeneratorcủa Conscrypt sẽ thực hiện thêm bước xác thực đối với các thông số khoá, so với BouncyCastle. Ví dụ: Conscrypt không cho phép ứng dụng của bạn tạo khoá AES 64 bit vì AES chỉ hỗ trợ khoá 128, 192 và 256 bit.BouncyCastle cho phép tạo các khoá có kích thước không hợp lệ, nhưng sau đó sẽ không thành công nếu các khoá này được dùng với
Cipher. Conscrypt thất bại sớm hơn.Bạn khởi động các mật mã Chế độ Galois/Bộ đếm (GCM) bằng một kích thước khác 12 byte. Việc triển khai
GcmParameterSpeccủa Conscrypt yêu cầu khởi tạo 12 byte (theo đề xuất của NIST).
Thông báo về quyền truy cập vào bảng nhớ tạm
Trên Android 12 trở lên, khi một ứng dụng gọi getPrimaryClip() để truy cập dữ liệu đã sao chép từ một ứng dụng khác lần đầu tiên, một thông báo dạng toast sẽ thông báo cho người dùng về quyền truy cập vào bảng nhớ tạm này.
Văn bản bên trong thông báo tạm thời có định dạng sau:
APP pasted from your clipboard.
Thông tin về văn bản trong nội dung mô tả đoạn trích
Trên Android 12 trở lên, getPrimaryClipDescription() có thể phát hiện những thông tin chi tiết sau:
- Văn bản được cách điệu bằng cách dùng
isStyledText(). - Các phân loại văn bản khác nhau, chẳng hạn như URL, bằng cách sử dụng
getConfidenceScore().
Ứng dụng không thể đóng hộp thoại hệ thống
Để cải thiện khả năng kiểm soát của người dùng khi tương tác với các ứng dụng và hệ thống, thao tác bằng ý định ACTION_CLOSE_SYSTEM_DIALOGS không được dùng nữa kể từ Android 12. Ngoại trừ một số trường hợp đặc biệt, khi ứng dụng của bạn cố gắng gọi một ý định có chứa thao tác này, hệ thống sẽ thực hiện một trong những thao tác sau đây dựa trên phiên bản SDK mục tiêu của ứng dụng:
- Nếu ứng dụng của bạn nhắm đến Android 12 trở lên, lỗi
SecurityExceptionsẽ xảy ra. Nếu ứng dụng của bạn nhắm đến Android 11 (API cấp 30) trở xuống, ý định sẽ không thực thi và thông báo sau sẽ xuất hiện trong Logcat:
E ActivityTaskManager Permission Denial: \ android.intent.action.CLOSE_SYSTEM_DIALOGS broadcast from \ com.package.name requires android.permission.BROADCAST_CLOSE_SYSTEM_DIALOGS, \ dropping broadcast.
Ngoại lệ
Trong những trường hợp sau, ứng dụng vẫn có thể đóng hộp thoại hệ thống trên Android 12 trở lên:
- Ứng dụng của bạn đang chạy một thử nghiệm đo lường.
Ứng dụng của bạn nhắm đến Android 11 trở xuống và đang hiển thị một cửa sổ nằm trên cùng của ngăn thông báo.
Ứng dụng của bạn nhắm đến Android 11 trở xuống. Ngoài ra, người dùng đã tương tác với một thông báo, có thể là bằng cách sử dụng các nút hành động của thông báo và ứng dụng của bạn đang xử lý một dịch vụ hoặc broadcast receiver để phản hồi hành động đó của người dùng.
Ứng dụng của bạn nhắm đến Android 11 trở xuống và có một dịch vụ hỗ trợ tiếp cận đang hoạt động. Nếu ứng dụng của bạn nhắm đến Android 12 và muốn đóng thanh thông báo, hãy sử dụng thao tác hỗ trợ tiếp cận
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE.
Các sự kiện chạm không đáng tin cậy sẽ bị chặn
Để duy trì tính bảo mật của hệ thống và trải nghiệm tốt cho người dùng, Android 12 ngăn các ứng dụng sử dụng sự kiện chạm khi một lớp phủ che khuất ứng dụng theo cách không an toàn. Nói cách khác, hệ thống sẽ chặn các thao tác chạm xuyên qua một số cửa sổ, ngoại trừ một số trường hợp.
Các ứng dụng bị ảnh hưởng
Thay đổi này ảnh hưởng đến những ứng dụng chọn cho phép các thao tác chạm truyền qua cửa sổ của chúng, chẳng hạn như bằng cách sử dụng cờ FLAG_NOT_TOUCHABLE. Sau đây là một số ví dụ (chưa đầy đủ):
- Lớp phủ yêu cầu quyền
SYSTEM_ALERT_WINDOW, chẳng hạn như các cửa sổ sử dụngTYPE_APPLICATION_OVERLAYvà sử dụng cờFLAG_NOT_TOUCHABLE. - Cửa sổ hoạt động sử dụng cờ
FLAG_NOT_TOUCHABLE.
Ngoại lệ
Trong những trường hợp sau, bạn được phép sử dụng thao tác chạm "truyền qua":
- Tương tác trong ứng dụng của bạn. Ứng dụng của bạn sẽ hiển thị lớp phủ và lớp phủ này chỉ xuất hiện khi người dùng đang tương tác với ứng dụng của bạn.
Cửa sổ đáng tin cậy. Những cửa sổ này bao gồm (nhưng không giới hạn ở) những cửa sổ sau:
Cửa sổ ẩn. Khung hiển thị gốc của cửa sổ là
GONEhoặcINVISIBLE.Cửa sổ hoàn toàn trong suốt. Thuộc tính
alphalà 0,0 đối với cửa sổ.Cửa sổ cảnh báo hệ thống đủ trong suốt. Hệ thống coi một nhóm cửa sổ cảnh báo hệ thống là đủ trong suốt khi độ mờ kết hợp nhỏ hơn hoặc bằng độ mờ tối đa của hệ thống để che khuất các thao tác chạm. Trong Android 12, độ mờ tối đa này là 0,8 theo mặc định.
Phát hiện thời điểm thao tác chạm không đáng tin cậy bị chặn
Nếu hệ thống chặn một thao tác chạm, Logcat sẽ ghi lại thông báo sau:
Untrusted touch due to occlusion by PACKAGE_NAME
Kiểm thử thay đổi
Theo mặc định, các thiết bị chạy Android 12 trở lên sẽ chặn những thao tác chạm không đáng tin cậy. Để cho phép các thao tác chạm không đáng tin cậy, hãy chạy lệnh ADB sau đây trong cửa sổ dòng lệnh:
# A specific app adb shell am compat disable BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps # If you'd still like to see a Logcat message warning when a touch would be # blocked, use 1 instead of 0. adb shell settings put global block_untrusted_touches 0
Để khôi phục hành vi về mặc định (các thao tác chạm không đáng tin cậy sẽ bị chặn), hãy chạy lệnh sau:
# A specific app adb shell am compat reset BLOCK_UNTRUSTED_TOUCHES com.example.app # All apps adb shell settings put global block_untrusted_touches 2
Vòng đời hoạt động
Các hoạt động của trình chạy gốc không còn hoàn tất khi nhấn nút Quay lại
Android 12 thay đổi cách xử lý mặc định của thao tác nhấn nút Quay lại trên hệ thống đối với các hoạt động của trình chạy nằm ở gốc của các tác vụ. Trong các phiên bản trước, hệ thống sẽ hoàn tất những hoạt động này khi người dùng nhấn nút Quay lại. Trong Android 12, hệ thống hiện di chuyển hoạt động và tác vụ của hoạt động đó xuống nền thay vì hoàn tất hoạt động. Hành vi mới này giống với hành vi hiện tại khi điều hướng ra khỏi một ứng dụng bằng nút Màn hình chính hoặc cử chỉ.
Đối với hầu hết các ứng dụng, thay đổi này có nghĩa là những người dùng sử dụng nút Quay lại để thoát khỏi ứng dụng của bạn có thể nhanh chóng tiếp tục sử dụng ứng dụng ở trạng thái ấm, thay vì phải khởi động lại hoàn toàn ứng dụng ở trạng thái nguội.
Bạn nên kiểm thử ứng dụng của mình khi có thay đổi này. Nếu ứng dụng của bạn hiện đang ghi đè onBackPressed() để xử lý thao tác Điều hướng về trang trước và hoàn tất Activity, hãy cập nhật quá trình triển khai để gọi qua super.onBackPressed() thay vì hoàn tất. Việc gọi super.onBackPressed() sẽ di chuyển hoạt động và tác vụ của hoạt động đó xuống nền khi thích hợp, đồng thời mang đến trải nghiệm điều hướng nhất quán hơn cho người dùng trên các ứng dụng.
Ngoài ra, xin lưu ý rằng nhìn chung, bạn nên sử dụng AndroidX Activity API để cung cấp thao tác điều hướng quay lại tuỳ chỉnh thay vì ghi đè onBackPressed(). Các API Hoạt động AndroidX sẽ tự động chuyển sang hành vi hệ thống thích hợp nếu không có thành phần nào chặn thao tác nhấn nút Quay lại của hệ thống.
Đồ hoạ và hình ảnh
Cải thiện khả năng chuyển đổi tốc độ làm mới
Trong Android 12, tốc độ làm mới thay đổi bằng cách sử dụng setFrameRate() bất kể màn hình có hỗ trợ chuyển đổi liền mạch sang tốc độ làm mới mới hay không; chuyển đổi liền mạch là chuyển đổi không có bất kỳ gián đoạn nào về hình ảnh, chẳng hạn như màn hình đen trong một hoặc hai giây. Trước đây, nếu màn hình không hỗ trợ quá trình chuyển đổi liền mạch, thì màn hình thường sẽ tiếp tục sử dụng cùng tốc độ làm mới sau khi setFrameRate() được gọi. Bạn có thể xác định trước xem quá trình chuyển đổi sang chế độ làm mới mới có diễn ra suôn sẻ hay không bằng cách gọi getAlternativeRefreshRates().
Thông thường, lệnh gọi lại onDisplayChanged() được gọi sau khi quá trình chuyển đổi tốc độ làm mới hoàn tất, nhưng đối với một số màn hình được kết nối bên ngoài, lệnh gọi lại này được gọi trong quá trình chuyển đổi không liền mạch.
Sau đây là một ví dụ về cách bạn có thể triển khai phương thức này:
Kotlin
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. val refreshRates = this.display?.mode?.alternativeRefreshRates val willBeSeamless = Arrays.asList<FloatArray>(refreshRates).contains(newRefreshRate) // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS)
Java
// Determine whether the transition will be seamless. // Non-seamless transitions may cause a 1-2 second black screen. Display display = context.getDisplay(); // API 30+ Display.Mode mode = display.getMode(); float[] refreshRates = mode.getAlternativeRefreshRates(); boolean willBeSeamless = Arrays.asList(refreshRates).contains(newRefreshRate); // Set the frame rate even if the transition will not be seamless. surface.setFrameRate(newRefreshRate, FRAME_RATE_COMPATIBILITY_FIXED_SOURCE, CHANGE_FRAME_RATE_ALWAYS);
Khả năng kết nối
Thông tin cập nhật về Passpoint
Các API sau đây được thêm vào Android 12:
isPasspointTermsAndConditionsSupported(): Điều khoản và điều kiện là một tính năng của Passpoint. Tính năng này cho phép các hoạt động triển khai mạng thay thế các trang xác thực không an toàn (sử dụng mạng mở) bằng một mạng Passpoint an toàn. Thông báo sẽ xuất hiện cho người dùng khi họ phải chấp nhận các điều khoản và điều kiện. Những ứng dụng đề xuất các mạng Passpoint bị giới hạn bởi các điều khoản và điều kiện phải gọi API này trước để đảm bảo rằng thiết bị hỗ trợ chức năng này. Nếu không hỗ trợ tính năng này, thiết bị sẽ không thể kết nối với mạng này và bạn phải đề xuất một mạng thay thế hoặc mạng cũ.isDecoratedIdentitySupported(): Khi xác thực với các mạng có tiền tố trang trí, tiền tố nhận dạng được trang trí cho phép nhà khai thác mạng cập nhật Mã nhận dạng truy cập mạng (NAI) để thực hiện định tuyến rõ ràng thông qua nhiều proxy bên trong mạng AAA (xem RFC 7542 để biết thêm về vấn đề này).Android 12 triển khai tính năng này để tuân thủ quy cách WBA cho các tiện ích PPS-MO. Những ứng dụng đề xuất các mạng Passpoint yêu cầu một danh tính được trang trí trước tiên phải gọi API này để đảm bảo rằng thiết bị hỗ trợ khả năng này. Nếu thiết bị không hỗ trợ tính năng này, danh tính sẽ không được trang trí và quá trình xác thực với mạng có thể không thành công.
Để tạo một đề xuất Passpoint, các ứng dụng phải sử dụng các lớp PasspointConfiguration, Credential và HomeSp. Các lớp này mô tả hồ sơ Passpoint, được xác định trong quy cách Passpoint của Liên minh Wi-Fi.
Để biết thêm thông tin, hãy xem phần API đề xuất Wi-Fi để kết nối Internet.
Các hạn chế mới cập nhật đối với giao diện không phả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, 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 12. Để tìm hiểu thêm về giao diện không phải SDK nói chung, hãy xem Các hạn chế đối với giao diện không phải SDK.