Android 10 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 được liệt kê trên trang này áp dụng cho ứng dụng của bạn khi chạy
trên Android 10, bất kể targetSdkVersion
của ứng dụng là gì. Bạn nên kiểm thử
ứng dụng của bạn và sửa đổi nếu cần để hỗ trợ những thay đổi này cho phù hợp.
Nếu targetSdkVersion của ứng dụng là 29
trở lên, bạn cũng cần phải
hỗ trợ các thay đổi bổ sung. Nhớ đọc các thay đổi về hành vi đối với ứng dụng
nhắm mục tiêu 29 để biết thông tin chi tiết.
Lưu ý: Ngoài những thay đổi nêu trên trang này, Android 10 đưa ra một số lượng lớn các thay đổi và hạn chế dựa trên quyền riêng tư, bao gồm như sau:
- Quyền truy cập thông tin vị trí của thiết bị khi ở nền sau
- Bắt đầu hoạt động trong nền
- Thông tin về đối tượng chung sở thích liên hệ
- Sắp xếp ngẫu nhiên địa chỉ MAC
- Siêu dữ liệu của camera
- Mô hình quản lý quyền
Những thay đổi này ảnh hưởng đến tất cả ứng dụng và giúp tăng cường quyền riêng tư của người dùng. Để tìm hiểu thêm về cách hỗ trợ những thay đổi này, hãy xem Các thay đổi về quyền riêng tư.
Các hạn chế đối với giao diện không phải SDK
Để giúp đảm bảo độ ổn định và khả năng tương thích của ứng dụng, nền tảng này đã bắt đầu hạn chế giao diện không phải SDK ứng dụng của bạn có thể dùng trong Android 9 (API cấp 28). Android 10 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. Mục tiêu của chúng tôi là đảm bảo rằng có sẵn các giải pháp thay thế trước khi chúng tôi hạn chế giao diện không phải SDK.
Nếu bạn không nhắm đến Android 10 (API cấp 29), 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), 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 thử ứ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, hãy xem bài viết Thông tin cập nhật về những hạn chế đối với giao diện không phải SDK trên Android 10 và xem Quy định hạn chế đối với giao diện không phải SDK.
Thao tác bằng cử chỉ
Kể từ Android 10, người dùng có thể bật tính năng điều hướng bằng cử chỉ trên thiết bị. Nếu người dùng bật thao tác bằng cử chỉ, thao tác này sẽ ảnh hưởng đến tất cả các ứng dụng trên thiết bị, cho dù ứng dụng có nhắm mục tiêu API cấp 29 hay không. Ví dụ: nếu người dùng vuốt từ cạnh màn hình, hệ thống sẽ diễn giải cử chỉ đó là thao tác Quay lại, trừ phi một ứng dụng cụ thể ghi đè cử chỉ đó cho các phần của màn hình.
Để ứng dụng của bạn tương thích với thao tác bằng cử chỉ, bạn sẽ muốn mở rộng nội dung ứng dụng từ mép này sang mép kia và xử lý các cử chỉ xung đột một cách thích hợp. Để biết thông tin, hãy xem phần Thao tác bằng cử chỉ tài liệu.
NDK
Android 10 có các thay đổi sau về NDK.
Đối tượng dùng chung không được chứa chức năng chuyển vị trí văn bản
Android 6.0 (API cấp 23) không cho phép sử dụng vị trí chuyển vị trí văn bản trong các đối tượng dùng chung. Mã phải được tải nguyên trạng và không được chỉnh sửa. Thay đổi này giúp cải thiện thời gian tải và độ bảo mật của ứng dụng.
SELinux thực thi quy định hạn chế này trên những ứng dụng nhắm đến Android 10 trở lên. Nếu các ứng dụng này tiếp tục sử dụng đối tượng dùng chung có chứa văn bản đều có nguy cơ cao bị hỏng.
Thay đổi đối với thư viện Bionic và đường dẫn trình liên kết động
Kể từ Android 10, một số đường dẫn là đường liên kết tượng trưng thay vì tệp thông thường. Ứng dụng đã dựa vào đường dẫn là các tệp thông thường có thể bị hỏng:
/system/lib/libc.so
->/apex/com.android.runtime/lib/bionic/libc.so
/system/lib/libm.so
->/apex/com.android.runtime/lib/bionic/libm.so
/system/lib/libdl.so
->/apex/com.android.runtime/lib/bionic/libdl.so
/system/bin/linker
->/apex/com.android.runtime/bin/linker
Những thay đổi này cũng áp dụng cho các biến thể 64 bit của tệp, với
Đã thay thế lib/
bằng lib64/
.
Để tương thích, các đường liên kết tượng trưng được cung cấp tại các đường dẫn cũ. Ví dụ: /system/lib/libc.so
là đường liên kết tượng trưng đến /apex/com.android.runtime/lib/bionic/libc.so
. Loại đối thủ sau lượt đánh bóng
dlopen(“/system/lib/libc.so”)
vẫn tiếp tục hoạt động nhưng các ứng dụng sẽ tìm thấy
sự khác biệt khi họ thực sự cố gắng kiểm tra các thư viện đã tải bằng cách đọc
/proc/self/maps
hoặc tương tự. Đây không phải là điều bình thường nhưng chúng tôi thấy rằng
một số ứng dụng làm như vậy trong quá trình chống xâm nhập. Nếu có,
Bạn phải thêm đường dẫn /apex/…
làm đường dẫn hợp lệ cho các tệp Bionic.
Tệp nhị phân/thư viện của hệ thống được ánh xạ tới bộ nhớ chỉ thực thi
Kể từ Android 10, các phân đoạn thực thi của tệp nhị phân và thư viện hệ thống được liên kết vào bộ nhớ chỉ thực thi (không đọc được) dưới dạng một kỹ thuật tăng cường chống lại các cuộc tấn công tái sử dụng mã. Nếu ứng dụng của bạn thực hiện các thao tác đọc vào các phân đoạn bộ nhớ được đánh dấu là chỉ thực thi – cho dù là do lỗi, lỗ hổng bảo mật hay kiểm tra bộ nhớ có chủ ý – thì hệ thống sẽ gửi tín hiệu SIGSEGV
đến ứng dụng của bạn.
Bạn có thể xác định xem hành vi này có gây ra sự cố hay không bằng cách kiểm tra tệp tombstone liên quan trong /data/tombstones/
. Sự cố chỉ liên quan đến chế độ thực thi
chứa thông báo huỷ sau đây:
Cause: execute-only (no-read) memory access error; likely due to data in .text.
Để giải quyết vấn đề này nhằm thực hiện các thao tác như kiểm tra bộ nhớ,
có thể đánh dấu các phân đoạn chỉ thực thi là đọc và thực thi bằng cách gọi
mprotect()
. Tuy nhiên, bạn nên đặt lại chế độ này về chỉ thực thi sau đó, vì chế độ cài đặt quyền truy cập này sẽ bảo vệ ứng dụng và người dùng tốt hơn.
Bảo mật
Android 10 có các thay đổi về bảo mật sau.
TLS 1.3 được bật theo mặc định
Trên Android 10 trở lên, TLS 1.3 được bật theo mặc định cho tất cả Kết nối TLS. Dưới đây là một số thông tin quan trọng về hoạt động triển khai TLS 1.3 của chúng tôi:
- Bộ thuật toán mật mã TLS 1.3 không tuỳ chỉnh được. Thuật toán mật mã TLS 1.3 được hỗ trợ
bộ công cụ luôn được bật khi TLS 1.3 được bật. Mọi nỗ lực tắt
bằng cách gọi điện
setEnabledCipherSuites()
sẽ bị bỏ qua. - Khi thương lượng TLS 1.3, các đối tượng
HandshakeCompletedListener
sẽ được gọi trước khi các phiên được thêm vào bộ nhớ đệm của phiên. (Trong TLS 1.2 và các phiên bản trước khác, các đối tượng này được gọi sau khi phiên được thêm vào bộ nhớ đệm của phiên). - Trong một số trường hợp, khi thực thể
SSLEngine
gửiSSLHandshakeException
bật các phiên bản trước của Android, các phiên bản này sẽ gửi một Thay vào đó,SSLProtocolException
trên Android 10 trở lên. - Không hỗ trợ chế độ 0-RTT.
Nếu muốn, bạn có thể lấy một SSLContext
đã tắt TLS 1.3 bằng cách gọi
SSLContext.getInstance("TLSv1.2")
.
Bạn cũng có thể kích hoạt hoặc vô hiệu hoá các phiên bản giao thức trên cơ sở từng kết nối bằng cách
đang gọi setEnabledProtocols()
trên đối tượng thích hợp.
Các chứng chỉ được ký bằng SHA-1 không đáng tin cậy trong TLS
Trong Android 10, các chứng chỉ sử dụng thuật toán băm SHA-1 không đáng tin cậy trong kết nối TLS. Các CA gốc không phát hành những chứng chỉ như vậy kể từ năm 2016 và chúng không còn đáng tin cậy trong Chrome hoặc các trình duyệt lớn khác.
Mọi nỗ lực kết nối đều không thành công nếu kết nối đến một trang web hiển thị chứng chỉ bằng SHA-1.
Các thay đổi và điểm cải thiện trong hành vi của KeyChain
Một số trình duyệt, chẳng hạn như Google Chrome, cho phép người dùng chọn một chứng chỉ khi
Máy chủ TLS gửi thông báo yêu cầu chứng chỉ trong quá trình bắt tay TLS. Tính đến
Android 10,
Các đối tượng KeyChain
tôn trọng nhà phát hành và
các thông số kỹ thuật chính khi gọi KeyChain.choosePrivateKeyAlias()
đến
hiển thị cho người dùng lời nhắc chọn chứng chỉ. Cụ thể, câu lệnh này không
chứa lựa chọn không tuân thủ thông số kỹ thuật của máy chủ.
Nếu không có chứng chỉ nào mà người dùng có thể chọn, chẳng hạn như khi không có chứng chỉ nào khớp với thông số kỹ thuật của máy chủ hoặc thiết bị không cài đặt bất kỳ chứng chỉ nào, thì lời nhắc chọn chứng chỉ sẽ không xuất hiện.
Ngoài ra, trên Android 10 trở lên, bạn không nhất thiết phải có
phương thức khoá màn hình thiết bị để nhập khoá hoặc chứng chỉ CA vào đối tượng KeyChain
.
Những thay đổi khác về TLS và mật mã học
Có một số thay đổi nhỏ trong thư viện TLS và mật mã học có hiệu lực trên Android 10:
- Các thuật toán mật mã AES/GCM/NoPadding và ChaCha20/Poly1305/NoPadding sẽ hoạt động trở lại nhiều hơn
chính xác kích thước bộ nhớ đệm từ
getOutputSize()
. - Bộ thuật toán mật mã
TLS_FALLBACK_SCSV
bị loại bỏ khỏi các nỗ lực kết nối với giao thức max TLS 1.2 trở lên. Do máy chủ TLS đã được cải thiện , bạn không nên thử phương thức dự phòng TLS bên ngoài. Thay vào đó, bạn nên dựa vào quá trình thương lượng phiên bản TLS. - ChaCha20-Poly1305 là bí danh của ChaCha20/Poly1305/NoPadding.
- Tên máy chủ có dấu chấm theo sau không được xem là tên máy chủ SNI hợp lệ.
- Phần mở rộng supported_signature_algorithms trong
CertificateRequest
là khi chọn khoá ký cho các phản hồi chứng chỉ. - Bạn có thể dùng các khoá ký mờ (chẳng hạn như các khoá trong Kho khoá Android) với Chữ ký RSA-PSS trong TLS.
Truyền phát trực tiếp qua Wi-Fi
Trên Android 10, các thông báo truyền phát sau đây liên quan đến Wi-Fi Trực tiếp không cố định:
Nếu ứng dụng của bạn dựa vào việc nhận những thông báo truyền phát này khi đăng ký do
chúng cố định, hãy sử dụng phương thức get()
thích hợp khi khởi chạy để
lấy thông tin thay thế.
Các chức năng Nhận biết Wi-Fi
Android 10 bổ sung tính năng hỗ trợ để dễ dàng tạo ổ cắm TCP/UDP bằng tính năng Nhận biết Wi-Fi
đường dẫn dữ liệu. Để tạo cổng TCP/UDP kết nối với ServerSocket
, ứng dụng
thiết bị cần biết địa chỉ IPv6 và cổng của máy chủ. Điều này trước đây
cần được truyền ngoài băng tần, chẳng hạn như bằng cách sử dụng lớp BT hoặc Wi-Fi Aware
2 hoặc được phát hiện trong băng tần bằng các giao thức khác, chẳng hạn như mDNS. Bằng
Trên Android 10, thông tin có thể được truyền đạt trong quá trình thiết lập mạng.
Máy chủ có thể thực hiện một trong những việc sau:
- Khởi động
ServerSocket
rồi đặt hoặc lấy cổng sẽ được sử dụng. - Chỉ định thông tin cổng trong yêu cầu mạng Wi-Fi Aware.
Mã mẫu sau đây trình bày cách chỉ định thông tin cổng trong yêu cầu mạng:
Kotlin
val ss = ServerSocket() val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle) .setPskPassphrase("some-password") .setPort(ss.localPort) .build() val myNetworkRequest = NetworkRequest.Builder() .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE) .setNetworkSpecifier(ns) .build()
Java
ServerSocket ss = new ServerSocket(); WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier .Builder(discoverySession, peerHandle) .setPskPassphrase(“some-password”) .setPort(ss.getLocalPort()) .build(); NetworkRequest myNetworkRequest = new NetworkRequest.Builder() .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE) .setNetworkSpecifier(ns) .build();
Sau đó, máy khách thực hiện yêu cầu mạng Nhận biết Wi-Fi để lấy IPv6 và cổng do máy chủ cung cấp:
Kotlin
val callback = object : ConnectivityManager.NetworkCallback() { override fun onAvailable(network: Network) { ... } override fun onLinkPropertiesChanged(network: Network, linkProperties: LinkProperties) { ... } override fun onCapabilitiesChanged(network: Network, networkCapabilities: NetworkCapabilities) { ... val ti = networkCapabilities.transportInfo if (ti is WifiAwareNetworkInfo) { val peerAddress = ti.peerIpv6Addr val peerPort = ti.port } } override fun onLost(network: Network) { ... } }; connMgr.requestNetwork(networkRequest, callback)
Java
callback = new ConnectivityManager.NetworkCallback() { @Override public void onAvailable(Network network) { ... } @Override public void onLinkPropertiesChanged(Network network, LinkProperties linkProperties) { ... } @Override public void onCapabilitiesChanged(Network network, NetworkCapabilities networkCapabilities) { ... TransportInfo ti = networkCapabilities.getTransportInfo(); if (ti instanceof WifiAwareNetworkInfo) { WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti; Inet6Address peerAddress = info.getPeerIpv6Addr(); int peerPort = info.getPort(); } } @Override public void onLost(Network network) { ... } }; connMgr.requestNetwork(networkRequest, callback);
SYSTEM_ALERT_WINDOW trên các thiết bị Go
Ứng dụng chạy trên thiết bị Android 10 (phiên bản Go) không thể nhận được
SYSTEM_ALERT_WINDOW
quyền. Nguyên nhân là do việc vẽ cửa sổ lớp phủ sử dụng quá nhiều bộ nhớ
điều này đặc biệt có hại đối với hiệu suất của Android có bộ nhớ thấp
thiết bị.
Nếu một ứng dụng chạy trên thiết bị phiên bản Go chạy Android 9 trở xuống nhận được
SYSTEM_ALERT_WINDOW
, ứng dụng sẽ giữ lại quyền ngay cả khi
thiết bị của bạn được nâng cấp lên Android 10. Tuy nhiên, ứng dụng chưa có
sẽ không thể cấp quyền này sau khi nâng cấp thiết bị.
Nếu một ứng dụng trên thiết bị Go gửi một ý định bằng thao tác
ACTION_MANAGE_OVERLAY_PERMISSION
!
hệ thống tự động từ chối yêu cầu và đưa người dùng đến
Màn hình Cài đặt cho biết quyền này không được cho phép vì
sẽ làm chậm thiết bị. Nếu một ứng dụng trên thiết bị Go gọi
Settings.canDrawOverlays()
!
thì phương thức sẽ luôn trả về false. Xin nhắc lại rằng những hạn chế này không áp dụng cho các ứng dụng
đã nhận được quyền SYSTEM_ALERT_WINDOW
trước khi thiết bị được
đã nâng cấp lên Android 10.
Cảnh báo cho ứng dụng nhắm đến các phiên bản Android cũ
Các thiết bị chạy Android 10 trở lên sẽ cảnh báo cho người dùng lần đầu tiên họ chạy bất kỳ ứng dụng nào nhắm đến Android 5.1 (API cấp 22) trở xuống. Nếu ứng dụng yêu cầu người dùng cấp quyền, thì người dùng cũng có cơ hội để điều chỉnh quyền của ứng dụng trước khi ứng dụng được phép chạy lần đầu tiên bất cứ lúc nào.
Do API mục tiêu của Google Play , người dùng chỉ thấy những cảnh báo này khi họ chạy một ứng dụng chưa được cập nhật gần đây. Đối với các ứng dụng được phân phối thông qua các cửa hàng khác, các yêu cầu tương tự về API mục tiêu sẽ có hiệu lực trong năm 2019. Để biết thêm thông tin về hãy xem phần Mở rộng yêu cầu về cấp độ API mục tiêu trong năm 2019.
Đã xoá bộ thuật toán mật mã SHA-2 CBC
Bộ thuật toán mật mã SHA-2 CBC sau đây đã bị xoá khỏi nền tảng:
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Các bộ thuật toán mật mã này kém an toàn hơn so với các bộ thuật toán mật mã sử dụng GCM, và hầu hết các máy chủ đều hỗ trợ cả biến thể GCM và CBC của thuật toán mật mã này hoặc không hỗ trợ cả hai.
Sử dụng ứng dụng
Android 10 ra mắt các thay đổi sau đây về hành vi liên quan đến việc sử dụng ứng dụng:
Cải thiện mức sử dụng ứng dụng UsageStats – Android 10 theo dõi chính xác việc dùng ứng dụng bằng UsageStats khi ứng dụng được dùng ở chế độ chia đôi màn hình hoặc chế độ hình trong hình. Ngoài ra, Android 10 theo dõi chính xác việc sử dụng ứng dụng tức thì.
Thang độ xám trên mỗi ứng dụng – Android 10 có thể đặt chế độ hiển thị thang màu xám cho từng ứng dụng.
Trạng thái phân tâm theo ứng dụng – Android 10 có thể đặt một số ứng dụng ở một "trạng thái mất tập trung" một cách có chọn lọc ở đâu thông báo của họ sẽ bị chặn và không xuất hiện dưới dạng ứng dụng được đề xuất.
Tạm ngưng và phát – Trong Android 10, các ứng dụng bị tạm ngưng sẽ không thể phát âm thanh.
Các thay đổi về kết nối HTTPS
Nếu một ứng dụng chạy Android 10 truyền null
vào
setSSLSocketFactory()
thân mến!
IllegalArgumentException
xảy ra. Trong các phiên bản trước, việc truyền null
vào setSSLSocketFactory()
có tác dụng tương tự như khi truyền vào thuộc tính mặc định hiện tại
nhà máy.
Thư viện android.preference không còn được dùng nữa
Kể từ Android 10, thư viện android.preference
sẽ không được dùng nữa.
Thay vào đó, nhà phát triển nên sử dụng thư viện tuỳ chọn AndroidX, một phần của Android
Jetpack. Để có thêm tài nguyên hỗ trợ cho quá trình di chuyển và
trong quá trình phát triển, hãy xem phần Cài đặt
Hướng dẫn cùng với mẫu công khai của chúng tôi
ứng dụng
và tài liệu tham khảo.
Thay đổi đối với thư viện tiện ích tệp ZIP
Android 10 ra mắt những thay đổi sau đây cho các lớp trong java.util.zip
xử lý tệp ZIP. Những thay đổi này làm cho hành vi của thư viện nhiều hơn
nhất quán giữa Android và các nền tảng khác sử dụng java.util.zip
.
Dụng cụ bơm
Trong các phiên bản trước, một số phương thức trong lớp Inflater
đã gửi một
IllegalStateException
nếu được
được gọi sau khi gọi đến end()
.
Trong Android 10, các phương thức này sẽ gửi một
NullPointerException
.
ZipFile
Trong Android 10 trở lên, hàm khởi tạo cho
ZipFile
nhận các đối số thuộc loại File
, int
và Charset
sẽ không gửi
ZipException
nếu tệp ZIP đã cung cấp
không chứa bất kỳ tệp nào.
ZipOutputStream
Trong Android 10 trở lên,
Phương thức finish()
trong
ZipOutputStream
không gửi
ZipException
nếu ứng dụng cố gắng ghi
luồng đầu ra cho tệp ZIP không chứa bất kỳ tệp nào.
Các thay đổi về camera
Nhiều ứng dụng sử dụng máy ảnh giả định rằng nếu thiết bị ở cấu hình dọc, thì thiết bị thực cũng nằm theo hướng dọc, như được mô tả trong Hướng máy ảnh. Trước đây, đây là một giả định an toàn, nhưng giờ thay đổi cùng với việc mở rộng các kiểu dáng hiện có, chẳng hạn như thiết bị có thể gập lại. Đó giả định trên các thiết bị này có thể dẫn đến việc xoay hoặc điều chỉnh tỷ lệ không chính xác (hoặc cả hai) hiển thị kính ngắm của máy ảnh.
Ứng dụng nhắm đến API cấp 24 trở lên phải được đặt rõ ràng
android:resizeableActivity
và cung cấp chức năng cần thiết để xử lý
nhiều cửa sổ.
Theo dõi mức sử dụng pin
Kể từ Android 10,
SystemHealthManager
lượt đặt lại
số liệu thống kê về mức sử dụng pin bất cứ khi nào thiết bị không rút phích cắm sau một sự cố
sự kiện sạc. Nói chung, một sự kiện sạc lớn là: Thiết bị
đã được sạc đầy hoặc thiết bị gần như đã gần hết pin
đã sạc.
Trước Android 10, số liệu thống kê về mức sử dụng pin sẽ được đặt lại bất cứ khi nào thiết bị rút phích cắm, bất kể có ít thay đổi đến mức pin như thế nào.
Ngừng sử dụng Android Beam
Trên Android 10, chúng tôi sẽ chính thức ngừng sử dụng Android Beam, một tính năng cũ hơn dành cho bắt đầu chia sẻ dữ liệu giữa các thiết bị qua Giao tiếp phạm vi gần (NFC). Chúng tôi cũng sẽ ngừng sử dụng một số API NFC có liên quan. Vẫn còn Android Beam có sẵn cho các đối tác nhà sản xuất thiết bị muốn sử dụng công cụ này, nhưng không thể trong quá trình phát triển tích cực. Android sẽ tiếp tục hỗ trợ NFC khác tuy nhiên, các chức năng và API cũng như các trường hợp sử dụng như đọc từ thẻ và sẽ tiếp tục hoạt động như dự kiến.
Thay đổi về hành vi của java.math.BigDecimal.stripTrailingZeros()
BigDecimal.stripTrailingZeros()
không còn lưu giữ các số 0 ở cuối dưới dạng
trường hợp đặc biệt nếu giá trị đầu vào bằng 0.
Các thay đổi về hành vi của java.util.regex.Matcher và Mẫu
Kết quả của split()
đã được thay đổi để không còn bắt đầu bằng String
trống
("") khi có kết quả khớp có độ rộng bằng 0 ở đầu mục nhập. Việc này cũng
ảnh hưởng đến String.split()
. Ví dụ: "x".split("")
hiện trả về {"x"}
trong khi nó dùng để trả về {"", "x"}
trên các phiên bản Android cũ hơn.
"aardvark".split("(?=a)"
hiện trả về {"a", "ardv", "ark"}
thay vì
{"", "a", "ardv", "ark"}
.
Hành vi ngoại lệ cho các đối số không hợp lệ cũng đã được cải thiện:
appendReplacement(StringBuffer, String)
hiện sẽ gửi mộtIllegalArgumentException
thay vìIndexOutOfBoundsException
nếuString
thay thế kết thúc bằng một dấu gạch chéo ngược (không hợp lệ). Chiến lược phát hành đĩa đơn ngoại lệ tương tự hiện sẽ được gửi nếuString
thay thế kết thúc bằng$
. Trước đó, không có ngoại lệ nào được gửi trong trường hợp này.replaceFirst(null)
không còn gọireset()
trênMatcher
nữa nếu nó trả về mộtNullPointerException
.NullPointerException
hiện cũng được gửi khi ở đó không khớp. Trước đây, lệnh này chỉ được gửi khi có kết quả trùng khớp.start(int group)
,end(int group)
vàgroup(int group)
giờ đã ném nữaIndexOutOfBoundsException
tổng quát nếu chỉ mục nhóm nằm ngoài giới hạn. Trước đây, các phương thức này gửiArrayIndexOutOfBoundsException
.
Góc mặc định cho GradientDrawable hiện là TOP_BOTTOM
Trong Android 10, nếu bạn xác định
GradientDrawable
trong XML và không cung cấp số đo góc, hướng chuyển màu
mặc định thành
TOP_BOTTOM
.
Đây là một thay đổi so với các phiên bản Android trước đó, trong đó chế độ mặc định là
LEFT_RIGHT
.
Để khắc phục vấn đề này, nếu bạn cập nhật lên phiên bản mới nhất của AAPT2, công cụ đặt số đo góc bằng 0 cho các ứng dụng cũ nếu không có góc đo lường cụ thể.
Ghi nhật ký cho các đối tượng được chuyển đổi tuần tự bằng SUID mặc định
Kể từ Android 7.0 (API cấp 24), nền tảng này đã sửa lỗi
thành serialVersionUID
mặc định để chuyển đổi tuần tự
đối tượng. Bản sửa lỗi này
không ảnh hưởng đến những ứng dụng nhắm đến API cấp 23 trở xuống.
Kể từ Android 10, nếu một ứng dụng nhắm đến API cấp 23 trở xuống
và dựa vào serialVersionUID
cũ, không chính xác, mặc định, nhật ký hệ thống
một cảnh báo và đề xuất cách sửa mã.
Cụ thể, hệ thống sẽ ghi lại cảnh báo nếu tất cả các điều sau đều xảy ra:
- Ứng dụng nhắm đến API cấp 23 trở xuống.
- Một lớp được chuyển đổi tuần tự.
- Lớp được chuyển đổi tuần tự sử dụng
serialVersionUID
mặc định, thay vì thiết lậpserialVersionUID
một cách rõ ràng. serialVersionUID
mặc định khác vớiserialVersionUID
sẽ là nếu ứng dụng nhắm đến API cấp 24 trở lên.
Cảnh báo này được ghi lại một lần cho mỗi lớp bị ảnh hưởng.
Thông báo cảnh báo này có bao gồm cách khắc phục được đề xuất, tức là đặt rõ ràng
serialVersionUID
thành giá trị mặc định sẽ được tính nếu
ứng dụng nhắm đến API cấp 24 trở lên. Bằng cách sử dụng bản sửa lỗi đó, bạn có thể đảm bảo rằng
nếu một đối tượng từ lớp đó được chuyển đổi tuần tự trên một ứng dụng nhắm mục tiêu cấp độ API
23 trở xuống thì đối tượng sẽ được đọc chính xác bởi các ứng dụng nhắm mục tiêu 24 trở lên,
và ngược lại.
Thay đổi java.io.FileChannel.map()
Kể từ Android 10, FileChannel.map()
không được hỗ trợ cho
các tệp không chuẩn, như /dev/zero
, có kích thước không thể thay đổi bằng cách sử dụng
truncate()
. Các phiên bản Android trước đó đã nuốt errno do truncate()
trả về, nhưng Android 10 sẽ gửi một IOException. Nếu bạn cần hành vi cũ,
bạn phải sử dụng mã gốc.