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

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 nêu 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 và sửa đổi ứng dụng để 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 hỗ trợ thêm các thay đổi. Hãy 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 được liệt kê trên trang này, Android 10 còn đưa ra một số thay đổi và hạn chế lớn dựa trên quyền riêng tư, bao gồm:

  • 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 sẽ ảnh hưởng đến tất cả ứng dụng và nâng cao 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 trang 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ế các giao diện không phải SDK mà ứng dụng của bạn có thể sử 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ác giải pháp thay thế công khai sẽ có sẵn trước khi 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ể 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, hãy xem bài viết Thông tin cập nhật về những quy tắc 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 thao tác bằng cử chỉ trên thiết bị. Nếu người dùng bật thao tác bằng cử chỉ, thì 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 đến API cấp 29 hay không. Ví dụ: nếu người dùng vuốt từ cạnh màn hình, thì hệ thống sẽ diễn giải cử chỉ đó là thao tác Quay lại, trừ phi ứng dụng ghi đè cử chỉ đó đối với 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 nên mở rộng nội dung ứng dụng từ từng cạnh 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 tài liệu về Thao tác bằng cử chỉ.

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 tính năng 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 sửa đổi. 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 các ứng dụng nhắm mục tiêu Android 10 trở lên. Nếu các ứng dụng này tiếp tục dùng các đối tượng dùng chung có chứa chức năng chuyển vị trí văn bản, thì chúng sẽ có nguy cơ cao bị lỗi.

Các 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. Các ứng dụng đang dựa vào đường dẫn là các tệp thông thường có thể gặp lỗi:

  • /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, trong đó lib/ được thay thế 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à một đường liên kết tượng trưng đến /apex/com.android.runtime/lib/bionic/libc.so. Vì vậy, dlopen(“/system/lib/libc.so”) sẽ tiếp tục hoạt động, nhưng các ứng dụng sẽ thấy sự khác biệt khi 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ự. Điều này không bình thường nhưng chúng tôi nhận 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 nên thêm đường dẫn /apex/… dưới dạng đườ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 có thể thực thi của tệp nhị phân và thư viện hệ thống sẽ được ánh xạ vào bộ nhớ chỉ thực thi (không đọc được) như một kỹ thuật củng cố chống lại các cuộc tấn công sử dụng lại mã. Nếu ứng dụng của bạn thực hiện thao tác đọc trong các phân đoạn bộ nhớ được đánh dấu là chỉ thực thi – dù là từ lỗi, lỗ hổng bảo mật hoặc việc kiểm tra bộ nhớ có chủ đích – 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 có liên quan trong /data/tombstones/. Sự cố chỉ liên quan đến việc 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ớ, bạn 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, sau đó, bạn nên quay lại chế độ chỉ thực thi, vì chế độ cài đặt quyền truy cập này giúp bảo vệ ứng dụng và người dùng hiệu quả 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 mọi kết nối TLS. Dưới đây là một số thông tin quan trọng về việc triển khai TLS 1.3:

  • Bộ thuật toán mật mã TLS 1.3 không tuỳ chỉnh được. Bộ thuật toán mật mã TLS 1.3 được hỗ trợ luôn được bật khi TLS 1.3 được bật. Mọi nỗ lực tắt chúng bằng cách gọi 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 khác trước đó, các đối tượng này được gọi sau khi các phiên được thêm vào bộ nhớ đệm của phiên.)
  • Trong một số trường hợp trên các phiên bản Android trước đó, các thực thể SSLEngine sẽ gửi một SSLHandshakeException, thì trên Android 10 trở lên, các thực thể này sẽ gửi một SSLProtocolException.
  • 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 gọi setEnabledProtocols() trên một đố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 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 đưa ra chứng chỉ sử dụ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 chứng chỉ khi máy chủ TLS gửi một thông báo yêu cầu chứng chỉ trong quá trình bắt tay TLS. Kể từ Android 10, các đối tượng KeyChain sẽ 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() để cho người dùng thấy lời nhắc lựa chọn chứng chỉ. Cụ thể, lời nhắc này không chứa các 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 các 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

Dưới đây là 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ẽ trả về dung lượng bộ nhớ đệm chính xác hơn 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 bằng một giao thức tối đa là TLS 1.2 trở lên. Do hoạt động triển khai 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 được tuân thủ 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 tin sau đây liên quan đến Wi-Fi Direct không cố định:

Nếu ứng dụng của bạn dựa vào việc nhận các thông báo truyền tin này khi đăng ký vì các thông báo này là cố định, hãy sử dụng phương thức get() thích hợp khi khởi chạy để nhận thông tin.

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ổng TCP/UDP bằng đường dẫn dữ liệu Nhận biết Wi-Fi. Để tạo cổng TCP/UDP kết nối với ServerSocket, thiết bị khách cần biết địa chỉ IPv6 và cổng của máy chủ. Trước đây, việc này cần được truyền ra ngoài băng tần, chẳng hạn như bằng cách sử dụng thông báo lớp 2 của BT hoặc Wi-Fi Aware 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. Với 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 về mạng Nhận biết Wi-Fi.

Mã mẫu sau đây cho biết 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

Các ứng dụng chạy trên thiết bị Android 10 (phiên bản Go) không được cấp quyền SYSTEM_ALERT_WINDOW. Nguyên nhân là do việc vẽ các cửa sổ lớp phủ sẽ tốn quá nhiều bộ nhớ, đặc biệt có hại cho hiệu suất của các thiết bị Android có bộ nhớ thấp.

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 quyền SYSTEM_ALERT_WINDOW, thì ứng dụng đó sẽ giữ lại quyền này ngay cả khi thiết bị được nâng cấp lên Android 10. Tuy nhiên, bạn sẽ không thể cấp quyền đó cho các ứng dụng chưa có quyền đó 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, thì hệ thống sẽ 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ì 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 này sẽ luôn trả về false. Xin nhắc lại, các quy định hạn chế này không áp dụng cho những ứ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 đối với ứng dụng nhắm đến 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 trong 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 các quyền của ứng dụng trước khi ứng dụng được phép chạy lần đầu tiên.

Do các yêu cầu về 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 chạy một ứng dụng chưa được cập nhật gần đây. Đối với ứng dụng được phân phối 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ề những yêu cầu này, hãy xem bài viết Mở rộng các 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

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ã tương tự 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 các bộ thuật toán mật mã này hoặc không hỗ trợ cả hai bộ thuật toán mật mã này.

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 Thống kê sử dụng - trong. Ngoài ra, Android 10 theo dõi chính xác mức sử dụng ứng dụng tức thì.

  • Thang độ xám trên mỗi ứng dụng -

  • Tạm ngưng và phát lại - 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ì IllegalArgumentException sẽ xảy ra. Trong các phiên bản trước, việc chuyển null vào setSSLSocketFactory() có cùng kết quả như khi truyền vào factory mặc định hiện tại.

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 lựa chọn ưu tiên AndroidX, một phần của Android Jetpack. Để có thêm tài nguyên hỗ trợ quá trình di chuyển và phát triển, hãy xem Hướng dẫn cài đặt (đã cập nhật) cùng với ứng dụng mẫu công khai và tài liệu tham khảo của chúng tôi.

Thay đổi thư viện tiện ích của tệp ZIP

Android 10 đưa ra những thay đổi sau cho các lớp trong gói java.util.zip, có chức năng xử lý tệp ZIP. Những thay đổi này giúp hành vi của thư viện nhất quán hơ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 IllegalStateException nếu các phương thức đó được gọi sau lệnh gọi đến end(). Trong Android 10, các phương thức này sẽ gửi một NullPointerException.

Tệp nén

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 tệp nào.

ZipOutputStream

Trong Android 10 trở lên, phương thức finish() trong ZipOutputStream sẽ không gửi ZipException nếu phương thức này cố gắng ghi một luồng đầu ra cho một 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 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 ở hướng dọc, như mô tả trong phần Hướng máy ảnh. Đây là một giả định an toàn trước đây, nhưng đã thay đổi cùng với việc mở rộng các kiểu dáng có sẵn, 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ể khiến kính ngắm của máy ảnh bị xoay không chính xác hoặc điều chỉnh theo tỷ lệ (hoặc cả hai).

Các ứng dụng nhắm đến API cấp 24 trở lên phải đặt android:resizeableActivity một cách rõ ràng và cung cấp chức năng cần thiết để xử lý hoạt động nhiều cửa sổ.

Theo dõi mức sử dụng pin

Kể từ Android 10, SystemHealthManager sẽ đặ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ị rút phích cắm sau một sự kiện sạc chính. 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ư đã hết pin rồi chuyển sang trạng thái đã sạc gần hết.

Trước Android 10, số liệu thống kê về mức sử dụng pin sẽ được đặt lại mỗi khi thiết bị bị rút phích cắm, bất kể mức pin có thay đổi như thế nào.

Ngừng sử dụng Android Beam

Trên Android 10, chúng tôi chính thức ngừng sử dụng Android Beam, một tính năng cũ hơn để bắt đầu chia sẻ dữ liệu giữa các thiết bị thông 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. Các đối tác nhà sản xuất thiết bị muốn sử dụng tính năng này vẫn có thể tuỳ ý sử dụng Android Beam, nhưng tính năng này hiện không còn trong quá trình phát triển nữa. Tuy nhiên, Android sẽ tiếp tục hỗ trợ các API và tính năng NFC khác. Những trường hợp sử dụng như đọc thẻ và thanh toán 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 giữ lại các số 0 ở cuối dưới dạng trường hợp đặc biệt nếu giá trị đầu vào là 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ó một giá trị khớp với độ rộng bằng 0 ở đầu giá trị nhập. Điều này cũng ảnh hưởng đến String.split(). Ví dụ: "x".split("") hiện trả về {"x"} trong khi nó được 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ột IllegalArgumentException thay vì IndexOutOfBoundsException nếu String thay thế kết thúc bằng một dấu gạch chéo ngược (một dấu gạch chéo ngược). Điều này là bất hợp pháp. Hiện tại, trường hợp ngoại lệ tương tự sẽ được gửi nếu String 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ọi reset() trên Matcher nữa nếu gửi ra NullPointerException. NullPointerException hiện cũng được gửi khi không có kết quả phù hợ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) hiện sẽ gửi một IndexOutOfBoundsException tổng quát hơn 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ửi ArrayIndexOutOfBoundsException.

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 phép đo góc, hướng chuyển màu sẽ mặc định là 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.

Để giải quyết 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, thì công cụ này sẽ đặt số đo góc bằng 0 cho các ứng dụng cũ nếu không chỉ định phép đo góc.

Ghi nhật ký 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 cho serialVersionUID mặc định đối với các đối tượng có thể chuyển đổi tuần tự. 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 mặc định cũ, không chính xác, thì hệ thống sẽ ghi lại cảnh báo và đề xuất bản sửa lỗi bằng 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ập serialVersionUID một cách rõ ràng.
  • serialVersionUID mặc định khác với serialVersionUID 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ó đề xuất một bản sửa lỗi được đề xuất, đó là đặt 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 đến API cấp 23 trở xuống, thì các ứng dụng nhắm mục tiêu cấp 24 trở lên sẽ đọc đối tượng đó chính xác và ngược lại.

Các 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, chẳng hạn như /dev/zero, có kích thước không thể thay đổi bằng truncate(). Các phiên bản Android trước đây chấp nhận lỗi errno do truncate() trả về, nhưng Android 10 lại trả về IOException. Nếu cần hành vi cũ, bạn phải sử dụng mã gốc.