Nền tảng Android 12 có các thay đổi về hành vi mà có thể
ảnh hưởng đến ứng dụng của bạn. Những thay đổi sau đây về hành vi á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 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 trực quan khi cuộn quá mức (overscroll) sự kiện thay đổi.
Trên Android 11 trở xuống, một sự kiện cuộn quá mức khiến các phần tử hình ảnh có toả sáng; trên Android 12 trở lên, các thành phần hình ảnh kéo dài và bật trở lại một sự kiện kéo, trong đó chúng hất và bật trở 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 hiệu ứng di chuyển cho thao tác cuộn cử chỉ.
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 hoặc
thấp hơn, bạn sẽ cần chuyển ứng dụng của mình sang API SplashScreen
để đảm bảo rằng
nó hiển thị chính xác khi khởi động trong Android 12. Nếu bạn không di chuyển ứng dụng,
trong trải nghiệm khởi chạy ứng dụng kém chất lượng hoặc ngoài ý muốn.
Để biết hướng dẫn, hãy xem Di chuyển màn hình chờ hiện tại của bạn cho Android 12.
Ngoài ra, kể từ Android 12, hệ thống luôn áp dụng giao diện người dùng Android
màn hình chờ theo giá trị mặc định của hệ thống
lạnh và
khởi động ấm đối với mọi ứ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ờ.
Độ phân giải của ý định trên web
Kể từ Android 12 (API cấp 31), một ý định chung trên web sẽ phân giải thành một hoạt động trong ứng dụng của bạn chỉ khi ứng dụng đó đượ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ì thay vào đó, ý định trên web sẽ phân giải thành ứng dụng trình duyệt mặc định của người dùng.
Ứng dụng có thể yêu cầu phê duyệt này bằng một trong những cách sau:
Xác minh miền bằng Ứng dụng Android Đường liên kết.
Trên các ứng dụng nhắm đến Android 12 trở lên, hệ thống thay đổi cách tự động xác minh Đường liên kết trong ứng dụng Android của ứng dụng. Trong ý định (intent) của ứng dụng bộ lọc, kiểm tra để chắc chắn rằng bạn đã bao gồm danh mục
BROWSABLE
và hỗ trợhttps
hệ thống.Trên Android 12 trở lên, bạn có thể theo cách thủ công xác minh Đường liên kết trong ứng dụng Android của ứng dụng để kiểm tra xem logic cập nhật này ảnh hưởng như thế nào đến .
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 ra ý định trên web, hãy cân nhắc việ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 hành động.
Các điểm cải tiến về chế độ sống động cho thao tác bằng cử chỉ
Android 12 hợp nhất hành vi hiện có để giúp 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 chế độ xem. Trong Ngoài ra, Android 12 cung cấp hành vi tương thích ngược đối với trải nghiệm chế độ xem.
Display#getRealSize và getRealMetrics: không dùng nữa và các ràng buộc
Các thiết bị Android có nhiều kiểu dáng, chẳng hạn như
màn hình, 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 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 WindowMetrics
API và không dùng các phương thức này nữa:
Trên Android 12, chúng tôi tiếp tục khuyến nghị sử dụng WindowMetrics
và
ngừng sử dụng các phương thức này:
Để 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 ràng buộc các giá trị mà API trả về
cho các ứng dụng không thể đổi kích thước hoàn toàn. Đ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ổ của họ 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ũ hơn, bạn có thể sử dụng
Thư viện Jetpack WindowManager
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ể đổi kích thước hoàn toàn.
Một hoạt động phải dựa vào WindowMetrics
từ ngữ cảnh hoạt động cho bất kỳ
Công việc liên quan đến giao diện người dùng, đặc biệt là
WindowManager.getCurrentWindowMetrics()
hoặc Jetpack
WindowMetricsCalculator.computeCurrentWindowMetrics()
.
Nếu ứng dụng của bạn tạo một MediaProjection
, các giới hạn phải có kích thước chính xác
vì phép chiếu chụp phân vùng hiển thị mà ứng dụng máy chiếu trong đó
đang chạy.
Nếu ứng dụng có thể đổi kích thước hoàn toàn, ngữ cảnh hoạt động sẽ trả về giới hạn chính xác như thế:
Kotlin
val projectionMetrics: WindowMetrics = activityContext .getSystemService(WindowManager::class.java).maximumWindowMetrics
Java
WindowMetrics projectionMetrics = activityContext .getSystemService(WindowManager.class).getMaximumWindowMetrics();
Nếu không thể đổi kích thước hoàn toàn, ứng dụng phải truy vấn từ WindowContext
thực thể 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 >= 600 dp), nền tảng hỗ trợ tất cả các ứng dụng ở chế độ nhiều cửa sổ
bất kể cấu hình ứng dụng là gì. Nếu
resizeableActivity="false"
!
ứng dụng được đưa vào chế độ tương thích khi cần thiết để phù hợp với màn hình
thứ nguyên.
Trên màn hình nhỏ (sw < 600dp), hệ thống sẽ kiểm tra
minWidth
và
minHeight
để 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 không được chạy ở chế độ nhiều cửa sổ bất kể giá trị tối thiểu
chiều rộng và chiều cao.
Để 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, 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ị như nhiều cửa sổ và đa màn hình, thách thức giả định đó.
Trên Android 12, các ứng dụng máy ảnh yêu cầu một màn hình cụ thể
và không tự động đổi kích thước (resizeableActivity="false"
)
nhập chế độ dọc có phần lồng ghép để đảm bảo hướng và khung hình phù hợp
tỷ lệ bản xem trước của máy ảnh. Trên thiết bị có thể gập lại và các thiết bị khác có camera
tầng trừu tượng phần cứng (HAL),
chế độ xoay bổ sung được áp dụng cho đầu ra của máy ảnh để bù cho máy ảnh
hướng cảm biến và đầu ra của máy ảnh bị cắt để phù hợp với tỷ lệ khung hình
bản xem trước của ứng dụng trên máy ảnh. Việc cắt và xoay thêm đảm bảo
bản trình bày bản xem trước của máy ảnh bất kể hướng của thiết bị và trạng thái gập
hoặc trạng thái mở của thiết bị.
Độ trễ của 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 đến trải nghiệm đơn giản cho nền trước chạy trong thời gian ngắn dịch vụ, những thiết bị chạy Android 12 trở lên có thể trì hoãn việc hiển thị dịch vụ trên nền trước 10 giây, với một vài thông báo ngoại lệ. Chiến dịch này khi thay đổi, các tác vụ ngắn hạn có thể hoàn tất trước khi được 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) đã giới thiệu chế độ bị hạn chế bộ chứa làm Chế độ chờ ứng dụng Xô. 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 số tất cả các nhóm. Các nhóm 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 sử dụng thường xuyên.
- Thường xuyên: Ứng dụng được dùng thường xuyên, nhưng không phải mỗi ngày.
- Hiếm: Ứng dụng không được dùng thường xuyên.
- 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ể cho thấy hành vi không mong muốn.
Ngoài thói quen 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 mình 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ế 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ử xem ứng dụng của bạn hoạt động như thế nào khi hệ thống đặt ứng dụng vào phần bị hạn chế nhóm, bạn có thể di chuyển ứng dụng sang nhóm đó theo cách thủ công. Để thực hiện việc này, hãy chạy lệnh sau đây trong cửa sổ dòng lệnh:
adb shell am set-standby-bucket PACKAGE_NAME restricted
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 mà ứng dụng của bạn có chỉ truy cập vào vị trí ước chừng của bạn.
Nếu ứng dụng của bạn yêu cầu
ACCESS_FINE_LOCATION
khi bắt đầu chạy, bạn cũng nên yêu cầu
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
cho ứng dụng của bạn. Bạn phải đưa cả hai quyền vào trong một thời gian 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ư trong hình 1:
- Chính xác: Cho phép 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í ước chừng.
Bật/tắt micrô và máy ảnh
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à vô hiệu hoá 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 các tuỳ chọn bật/tắt từ 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ề
bật/tắt và cách kiểm tra
ứng dụng của bạn tuân theo các phương pháp hay nhất liên quan đến
CAMERA
và
RECORD_AUDIO
quyền truy cập.
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ề
chỉ báo 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 liên quan đến
CAMERA
và
RECORD_AUDIO
quyền truy cập.
Chế độ hiển thị gói quyền
Trên những 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 nhận được tập hợp kết quả đã lọc, dựa trên gói chế độ hiển thị vào các ứng dụng khác:
Đã xoá cách triển khai của BouncyCastle
Android 12 loại bỏ nhiều Triển khai BouncyCastle của các thuật toán mật mã không được dùng nữa, bao gồm tất cả thuật toán AES các thuật toán. Thay vào đó, hệ thống này sẽ sử dụng 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 các khoá có kích thước 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ệ với
KeyGenerator
. Triển khai của ConscryptKeyGenerator
thực hiện thêm 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 đó không hoạt động nếu các khoá này được dùng với
Cipher
. Conscrypt bị lỗi trước đó.Bạn khởi tạo thuật toán mật mã Galois/Chế độ bộ đếm (GCM) bằng cách sử dụng kích thước khác 12 byte. Triển khai của Conscrypt
GcmParameterSpec
yêu cầu một khởi tạo 12 byte theo khuyến nghị 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 vào dữ liệu đoạn video từ
app lần đầu tiên, một thông báo ngắn
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ả của đoạn video
Trên Android 12 trở lên, getPrimaryClipDescription()
có thể
phát hiện các chi tiết sau:
- Văn bản cách điệu, sử dụng
isStyledText()
. - Các cách phân loại văn bản khác nhau, chẳng hạn như URL, sử dụng
getConfidenceScore()
.
Ứng dụng không thể đóng hộp thoại hệ thống
Để cải thiện quyền kiểm soát của người dùng khi tương tác với ứng dụng và hệ thống,
ACTION_CLOSE_SYSTEM_DIALOGS
Kể từ Android 12, thao tác theo ý định sẽ không được dùng nữa. Ngoại trừ một vài
các trường hợp đặc biệt, khi ứng dụng của bạn cố gắng gọi
một ý định chứa thao tác này,
hệ thống 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,
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 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 công cụ đo lường thử nghiệm.
Ứ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ổ ở phía trên thông báo ngăn ké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 thông báo, có thể sử dụng hành động của thông báo các nút và ứng dụng của bạn xử lý một dịch vụ hoặc thông báo truyền tin 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ó dịch vụ hỗ trợ tiếp cận. Nếu ứng dụng của bạn nhắm mục tiêu đến Android 12 và muốn đóng thanh thông báo, hãy sử dụng thời gian
GLOBAL_ACTION_DISMISS_NOTIFICATION_SHADE
hành động hỗ trợ tiếp cận.
Đã chặn các sự kiện chạm không đáng tin cậy
Để duy trì tính bảo mật của hệ thống và mang đến trải nghiệm tốt cho người dùng, Android 12 ngăn các ứng dụng sử dụng thao tác chạm sự kiện có 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 đ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 những ứng dụng chọn cho phép thao tác chạm di chuyển qua cửa sổ,
Ví dụ: bằng cách sử dụng
FLAG_NOT_TOUCHABLE
cờ. Dưới đây là một số ví dụ bao gồm, nhưng không giới hạn:
- Lớp phủ yêu cầu
SYSTEM_ALERT_WINDOW
chẳng hạn như các cửa sổ sử dụngTYPE_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, "chuyển qua" được phép chạm:
- Hoạt động tương tác trong ứng dụng. Ứng dụng của bạn cho thấy lớp phủ và lớp phủ 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ổ tin cậy. Các cửa sổ này bao gồm (nhưng không giới hạn ở) sau:
Cửa sổ ẩn. Chế độ xem gốc của cửa sổ là
GONE
hoặcINVISIBLE
.Cửa sổ hoàn toàn trong suốt. Chiến lược phát hành đĩa đơn Thuộc tính
alpha
là 0,0 cho cửa sổ.Cửa sổ cảnh báo hệ thống trong suốt đủ độ sáng. Hệ thống coi một tập hợp cửa sổ cảnh báo hệ thống phải đủ trong suốt khi độ mờ kết hợp nhỏ hơn hoặc bằng độ mờ tối đa che khuất tối đa của hệ thống đối với 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 khi nào thao tác chạm không đáng tin cậy bị chặn
Nếu một thao tác chạm bị hệ thống chặn, Logcat ghi lại thông báo sau:
Untrusted touch due to occlusion by PACKAGE_NAME
Kiểm tra sự 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 những thiết bị chạy Android 12 trở lên. Để cho phép 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
Để đảo ngược hành vi về mặc định (các thao tác chạm không đáng tin cậy bị chặn), hãy chạy sau đây:
# 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
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 của thao tác nhấn Quay lại trên trình chạy của hệ thống các hoạt động là gốc rễ của nhiệm 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 di chuyển hoạt động và tác vụ của hoạt động đó chuyển 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 điều hướng ra 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 các ứng dụng, thay đổi này có nghĩa là những người dùng sử dụng tính năng Quay lại để điều hướng ra khỏi có thể tiếp tục ứng dụng của bạn nhanh hơn từ trạng thái ấm, thay vì phải khởi động lại hoàn toàn ứng dụng từ một trạng thái nguội.
Bạn nên kiểm thử ứng dụng của mình dựa trên thay đổi này. Nếu ứng dụng của bạn đang ghi đè
onBackPressed()
để xử lý
Quay lại điều hướng và hoàn tất Activity
, cập nhật phương thức triển khai để gọi
đến super.onBackPressed()
thay vì kết thúc. Gọi điện
super.onBackPressed()
chuyển hoạt động và tác vụ của hoạt động đó sang chế độ nền khi
phù hợp và cung cấp 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 cho
cung cấp tính năng điều hướng quay lại tuỳ chỉnh,
thay vì ghi đè onBackPressed()
. AndroidX Activity API
tự động trì hoãn hành vi thích hợp của hệ thống nếu không có
các thành phần chặn 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, các thay đổi về tốc độ làm mớ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; chuyển đổi liền mạch là quá trình không có bất kỳ hình ảnh trực quan nào
gián đoạn, 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ông thường nó sẽ tiếp tục sử dụng
có cùng tốc độ làm mới sau khi gọi setFrameRate()
. Bạn có thể xác định trong
liệu quá trình chuyển đổi sang quy trình làm mới mới có thể diễn ra suôn sẻ hay không bằng cách
đang gọi getAlternativeRefreshRates()
.
Nói 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 với một số
màn hình được kết nối với bên ngoài, nó được gọi trong quá trình chuyển đổi không liền mạch.
Sau đâ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à Khoá truy cập cho phép triển khai mạng để thay thế các trang xác thực không an toàn, Mạng này sử dụng mạng mở với mạng Passpoint bảo mật. Một thông báo là hiển thị cho người dùng khi người dùng cần chấp nhận các điều khoản và điều kiện. Ứng dụng đề xuất các mạng Passpoint chịu sự kiểm soát của 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ếu thiết bị 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, đồng thời 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 bằng trang trí tiền tố, hình ảnh tiền tố danh tính cho phép nhà cung cấp dịch vụ mạng cập nhật Quyền truy cập mạng Định danh (NAI) để thực hiện định tuyến rõ ràng thông qua nhiều proxy bên trong của một mạng AAA (xem RFC 7542 cho về vấn đề này).Android 12 triển khai tính năng này theo quy cách của WBA về PPS-MO tiện ích. Ứng dụng đề xuất mạng Passpoint cần phải có danh tính được trang trí phải hãy gọi API này trước để đảm bảo rằng thiết bị hỗ trợ tính năng đó. 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à việc xác thực mạng có thể không thành công.
Để tạo đề xuất Passpoint, ứng dụng phải sử dụng
PasspointConfiguration
!
Credential
và
HomeSp
lớp học. Các
các lớp mô tả cấu hình Passpoint được định nghĩa trong Wi-Fi Alliance
Passpoint (Khoá truy cập)
.
Để 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ề 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 .