Thay đổi về hành vi: tất cả ứng dụng

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 sau đây về hành vi sẽ áp dụng cho tất cả ứng dụng khi ứng dụng 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 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 quá mức

Trên các thiết bị chạy Android 12 trở lên, hành vi hình ảnh đối với 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ử hình ảnh phát ra ánh sáng; trên Android 12 trở lên, các phần tử hình ảnh kéo giãn và bật trở lại trên một sự kiện kéo, sau đó chúng hất và bật lên trong một sự kiện hất.

Để biết thêm thông tin, hãy xem hướng dẫn tạo ảnh động cho các cử chỉ cuộn.

Màn hình chờ của ứng dụng

Nếu đã triển khai màn hình chờ tuỳ chỉnh trong Android 11 trở xuống, bạn cần di chuyển ứng dụng sang API SplashScreen để đảm bảo màn hình chờ hiển thị chính xác kể từ Android 12. Việc không di chuyển ứng dụng sẽ dẫn đến trải nghiệm khởi chạy ứng dụng kém hiệu quả hoặc không chủ ý.

Để biết hướng dẫn, hãy xem nội dung Di chuyển phương thức triển khai màn hình chờ hiện tại 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 mặc định của hệ thống Android khi khởi động nguội 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, hãy xem hướng dẫn cho nhà phát triển màn hình chờ.

Giải pháp cho ý định trên web

Kể từ Android 12 (API cấp 31), ý định web chung sẽ chỉ chuyển thành một hoạt động trong ứng dụng nếu ứng dụng của bạn được phê duyệt cho miền cụ thể có trong ý định web đó. Nếu ứng dụng của bạn không được phê duyệt cho miền, thì ý định trên web sẽ được chuyển thành ứ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 quyết định phê duyệt này bằng một trong những cách sau:

Nếu ứng dụng của bạn gọi ý định web, hãy cân nhắc thêm lời nhắc hoặc hộp thoại yêu cầu người dùng xác nhận thao tác.

Cải thiện chế độ sống động cho thao tác bằng cử chỉ

Android 12 hợp nhất các hành vi hiện có để giúp người dùng thực hiện các lệnh thao tác bằng cử chỉ dễ dàng hơn khi ở chế độ hiển thị tối đa. Ngoài ra, Android 12 còn cung cấp hành vi tương thích ngược cho chế độ nhúng cố định.

Display#getRealSize và getRealMetrics: không dùng nữa và hạn chế

Các thiết bị Android được cung cấp ở nhiều kiểu dáng, chẳng hạn như thiết bị có 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 màn hình. 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:

Trên Android 12, chúng tôi tiếp tục đề xuất 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 dùng API Hiển thị để truy xuất giới hạn của ứng dụng, Android 12 ràng buộc các giá trị do API trả về đối với các ứng dụng không thể hoàn toàn thay đổi kích thước. Điều này có thể ảnh hưởng đến các ứng dụng đang sử dụng thông tin này với MediaProjection.

Ứng dụng nên dùng các API WindowMetrics để truy vấn các giới hạn của cửa sổ và Configuration.densityDpi để truy vấn mật độ hiện tại.

Để tương thích rộng hơn với các phiên bản Android cũ hơn, bạn có thể sử dụng thư viện Jetpack WindowManager, có chứa 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ể đổi kích thước hoàn toàn.

Một hoạt động nên 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 giới hạn phải được định kích thước chính xác vì hình chiếu sẽ chụp lại phân vùng hiển thị mà ứng dụng máy chiếu đang chạy.

Nếu ứng dụng hoàn toàn có thể đổi kích thước, ngữ 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 hoàn toàn không thể đổi kích thước, ứng dụng phải truy vấn từ một thực thể WindowContext và truy xuất WindowMetrics của giới hạn hoạt động bằng cách sử dụ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 biến chế độ nhiều cửa sổ thành chế độ 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 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 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 của máy ảnh. Tuy nhiên, các hệ số hình dạng màn hình lớn (chẳng hạn như thiết bị có thể gập lại) và chế độ hiển thị như nhiều cửa sổ và nhiều màn hình cũng 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 lồng ghép, nhằm đảm bảo hướng và tỷ lệ khung hình phù hợp của bản xem trước của máy ảnh. 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) cho máy ảnh, chế độ xoay bổ sung sẽ được áp dụng cho đầu ra máy ảnh để bù cho hướng cảm biến của máy ảnh và đầu ra máy ảnh sẽ bị cắt để phù hợp với tỷ lệ khung hình của bản xem trước máy ảnh trong ứng dụng. Việc cắt và xoay bổ sung giúp đảm bảo bản xem trước của máy ảnh hiển thị chính xác bất kể hướng của thiết bị cũng như trạng thái gập hoặc mở của thiết bị.

Độ trễ trải nghiệm người dùng đối với thông báo dịch vụ trên nền trước

Để mang lại trải nghiệm đơn giản cho 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 về dịch vụ trên nền trước 10 giây, với một vài trường hợp ngoại lệ. Thay đổi này giúp các công việc ngắn hạn có cơ hội hoàn tất trước khi thông báo của chúng 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 bộ chứa bị hạn chế làm Bộ chứa chế độ chờ ứng dụng. Kể từ Android 12, bộ 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 nhóm theo thứ tự ưu tiên từ cao xuống thấp là:

  1. Đang hoạt động: Ứng dụng đang được dùng hoặc đã được dùng gần đây.
  2. Bộ hoạt động: Ứng dụng đang được sử dụng thường xuyên.
  3. Thường xuyên: Ứng dụng được dùng thường xuyên, nhưng không phải mỗi ngày.
  4. Hiếm: Ứng dụng không được dùng thường xuyên.
  5. Bị hạn chế: Ứng dụng tiêu tốn rất nhiều tài nguyên 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ó đặ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 đã đặt ứng dụng của bạn vào bộ chứa bị hạn chế hay chưa, 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 đang ở 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 sang 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

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

Vị trí ước chừng

Hộp thoại có hai tập hợp tuỳ chọn, một tập hợp nằm phía trên các tuỳ chọn còn lại
Hình 1. Hộp thoại cấp quyền của hệ thống cho phép người dùng cấp thông tin 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 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í ước chừng vào ứng dụng. 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 bao gồm các tuỳ chọn sau đây cho người dùng, như minh hoạ trong hình 1:

  • Chính xác: Cấp quyền truy cập vào thông tin vị trí chính xác.
  • Gần đúng: Chỉ cấp quyền truy cập vào thông tin vị trí ước chừng.

Bật/tắt micrô và máy ảnh

Với các thiết bị được hỗ trợ chạy Android 12 trở lên, người dùng có thể bật và tắt quyền truy cập vào máy ảnh và micrô đối với 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ừ phầ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 cũng như 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 về quyền CAMERA và RECORD_AUDIO.

Chỉ báo micrô và máy ảnh

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ề các chỉ báo này và cách kiểm tra để đảm bảo rằng ứng dụng của bạn tuân thủ các phương pháp hay nhất về quyền CAMERA và RECORD_AUDIO.

Các ô trong trình đơn Cài đặt nhanh được gắn nhãn &quot;Quyền truy cập vào máy ảnh&quot; và &quot;Quyền truy cập vào micrô&quot;
Hình 2. Tuỳ chọn bật/tắt micrô và máy ảnh trong trình đơn Cài đặt nhanh.
Một hình chữ nhật góc tròn ở góc trên bên phải, trong đó có biểu tượng máy ảnh và biểu tượng micrô
Hình 3. Các chỉ báo máy ảnh và micrô, cho biết hoạt động truy cập dữ liệu gần đây.

Chế độ hiển thị gói quyền

Trên các thiết bị chạy Android 12 trở lên, các ứ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 chế độ hiển thị gói của ứng dụng trong các ứng dụng khác:

Đã xoá phương thức triển khai BouncyCastle

Android 12 loại bỏ 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 đây, bao gồm cả mọi 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 sẽ ảnh hưởng đến ứng dụng của bạn nếu bất kỳ trường hợp nào sau đây xảy ra:

  • Ứng dụng của bạn 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ã hoá của ứng dụng để sử dụng nhiều kích thước khoá.

  • Ứng dụng của bạn sử dụng kích thước khoá không hợp lệ khi dùng KeyGenerator. Hoạt động triển khai KeyGenerator của Conscrypt thực hiện thêm việc xác thực các tham số chính, 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ợ các 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 bạn sử dụng các khoá này với Cipher. Conscrypt sẽ thất bại trước đó.

  • Bạn khởi chạy thuật toán mật mã Galois/Counter Mode (GCM) bằng cách sử dụng kích thước không quá 12 byte. Quá trình triển khai GcmParameterSpec của Conscrypt yêu cầu khởi chạy 12 byte theo khuyến nghị của NIST.

Thông báo truy cập bảng nhớ tạm

Trên Android 12 trở lên, khi một ứng dụng gọi getPrimaryClip() lần đầu tiên để truy cập vào dữ liệu đoạn video từ một ứng dụng khác, một thông báo ngắn 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 ngắn có định dạng sau: APP pasted from your clipboard.

Thông tin về văn bản trong phần mô tả đoạn video

Trên Android 12 trở lên, getPrimaryClipDescription() có thể phát hiện các thông tin chi tiết sau:

Ứ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 theo ý định ACTION_CLOSE_SYSTEM_DIALOGS sẽ không được dùng nữa kể từ Android 12. Ngoại trừ một vài trường hợp đặc biệt, khi ứng dụng 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 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, thì SecurityException sẽ xuất hiện.

  • Nếu ứng dụng của bạn nhắm đến Android 11 (API cấp 30) trở xuống, thì ý định đó sẽ không được 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 các 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 kiểm thử đo lường.

  • Ứng dụng của bạn nhắm mục tiêu đến Android 11 trở xuống và hiển thị một cửa sổ ở đầu 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ể 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 thao tác đó 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 đã bị chặn

Để duy trì trải nghiệm tốt cho người dùng và bảo mật hệ thống, Android 12 ngăn không cho các ứng dụng sử dụng các sự kiện chạm, trong đó 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 chặn các thao tác chạm đi qua một số cửa sổ nhất định, với một vài ngoại lệ.

Các ứng dụng bị ảnh hưởng

Thay đổi này ảnh hưởng đến các ứng dụng chọn cho phép thao tác chạm đi qua cửa sổ, chẳng hạn như bằng cách sử dụng cờ FLAG_NOT_TOUCHABLE. Một số ví dụ bao gồm, nhưng không giới hạn ở các ví dụ sau:

  • Các lớp phủ yêu cầu quyền SYSTEM_ALERT_WINDOW, chẳng hạn như các cửa sổ sử dụng TYPE_APPLICATION_OVERLAY và sử dụng cờ FLAG_NOT_TOUCHABLE.
  • Cửa sổ hoạt động sử dụng cờ FLAG_NOT_TOUCHABLE.

Ngoại lệ

Trong các trường hợp sau đây, các thao tác chạm "chuyển tiếp" được cho phép:

  • Các hoạt động tương tác trong ứng dụng. Ứng dụng cho thấy 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 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. Chế độ xem gốc của cửa sổ là GONE hoặc INVISIBLE.

  • Cửa sổ hoàn toàn trong suốt. Thuộc tính alpha là 0.0 đối với cửa sổ.

  • Cửa sổ cảnh báo hệ thống đủ mờ. Hệ thống sẽ coi một tập hợp các cửa sổ cảnh báo của hệ thống là đủ trong khi độ mờ kết hợp nhỏ hơn hoặc bằng độ mờ tối đa của hệ thống đối với các lần chạm. Trong Android 12, độ mờ tối đa này là 0,8 theo mặc định.

Phát hiện khi một 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 thao tác chạm không đáng tin cậy sẽ bị chặn trên các thiết bị chạy Android 12 trở lên. Để 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 một 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

Để chuyển hành vi về giá trị mặc định (các thao tác chạm không đáng tin cậy 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 Quay lại

Android 12 thay đổi cách xử lý mặc định cho thao tác Nhấn quay lại của hệ thống đối với các hoạt động của trình chạy ở gốc tác vụ. Trong các phiên bản trước, hệ thống sẽ hoàn tất các hoạt động này khi nhấn Quay lại. Trong Android 12, hệ thống hiện sẽ di chuyển hoạt động và tác vụ của hoạt động đó sang chế độ nền thay vì hoàn tất hoạt động. Hành vi mới khớp với hành vi hiện tại khi thoát khỏi một ứng dụng bằng cử chỉ hoặc nút Màn hình chính.

Đối với hầu hết ứng dụng, thay đổi này có nghĩa là người dùng sử dụng nút Quay lại để rời khỏi ứng dụng có thể tiếp tục ứng dụng của bạn từ trạng thái ấm nhanh hơn, thay vì phải khởi động lại hoàn toàn ứng dụng từ trạng thái nguội.

Bạn nên kiểm thử ứng dụng của mình bằng sự thay đổi này. Nếu ứng dụng của bạn hiện đang ghi đè onBackPressed() để xử lý tính năng Điều hướng quay lại và hoàn tất Activity, hãy cập nhật phương thức triển khai để gọi đến super.onBackPressed() thay vì hoàn tất. Khi gọi super.onBackPressed(), hoạt động và tác vụ của hoạt động đó sẽ chuyển sang chế độ nền khi thích hợp và mang lại trải nghiệm thao tác 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 tính năng điều hướng quay lại tuỳ chỉnh, thay vì ghi đè onBackPressed(). AndroidX Activity API sẽ tự động trì hoãn hành vi thích hợp của hệ thống nếu không có thành phần nào chặn thao tác nhấn 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

Trên Android 12, các thay đổi về tốc độ làm mới bằng cách sử dụng setFrameRate() có thể xảy ra bất kể màn hình có hỗ trợ chuyển đổi liền mạch sang tốc độ làm mới hay không; chuyển đổi liền mạch là quá trình không bị gián đoạn 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ợ chuyển đổi liền mạch, thì thông thường, màn hình sẽ tiếp tục sử dụng cùng một 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 làm mới mới có suôn sẻ hay không bằng cách gọi getAlternativeRefreshRates(). Nhìn chung, 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 kết nối bên ngoài, lệnh gọi lại này sẽ được gọi trong quá trình chuyển đổi không liền mạch.

Dưới đây là ví dụ về cách bạn có thể triển khai việ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à tính năng Điểm truy cập cho phép triển khai mạng thay cho các trang xác thực không an toàn (sử dụng mạng mở) bằng mạng Passpoint bảo mật. Người dùng sẽ thấy một thông báo khi họ phải chấp nhận các điều khoản và điều kiện. Trước tiên, các ứng dụng đề xuất mạng Passpoint bị kiểm soát theo các điều khoản và điều kiện phải gọi API này để đảm bảo rằng thiết bị hỗ trợ tính năng đó. Nếu không hỗ trợ tính năng đó, thiết bị sẽ không thể kết nối với mạng này. 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ó trang trí tiền tố, tiền tố nhận dạng được trang trí sẽ cho phép các nhà khai thác mạng cập nhật Giá trị nhận dạng truy cập mạng (NAI) để thực hiện việc định tuyến rõ ràng qua nhiều proxy bên trong mạng AAA (xem RFC 7542 để biết thêm thông tin về điều này).

    Android 12 triển khai tính năng này để tuân thủ quy cách WBA cho tiện ích PPS-MO. Các ứng dụng đề xuất mạng Passpoint yêu cầu 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ợ tính 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 đề xuất Passpoint, các ứng dụng phải 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 bài viết API đề xuất Wi-Fi để kết nối Internet.

Các quy tắ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 tổng quan thêm về giao diện không phải SDK, hãy xem Hạn chế đối với giao diện không phải SDK.