Thay đổi về hành vi: Ứng dụng nhắm đến Android 17 trở lên

Giống như các bản phát hành trước, Android 17 có các thay đổi về hành vi có thể ảnh hưởng đến ứng dụng của bạn. Những thay đổi về hành vi sau đây chỉ áp dụng cho ứng dụng nhắm đến Android 17 trở lên. Nếu ứng dụng của bạn nhắm đến Android 17 trở lên, bạn nên điều chỉnh ứng dụng để hỗ trợ những hành vi này (nếu cần).

Ngoài ra, hãy nhớ tham khảo danh sách các thay đổi về hành vi ảnh hưởng đến tất cả ứng dụng chạy trên Android 17 bất kể targetSdkVersion của ứng dụng.

Trải nghiệm người dùng và giao diện người dùng hệ thống

Android 17 có những thay đổi sau đây nhằm mang đến trải nghiệm người dùng nhất quán và trực quan hơn.

Tiện ích giới hạn bộ nhớ

Beginning with Android 17, for apps targeting Android 17 (API level 37) or higher, the system enforces a strict memory limit (1.5 * screen width * screen height * 4) against the combined memory usage of both Bitmaps and Icons present in the RemoteViews parcel. Exceeding these limits throws a fatal IllegalArgumentException and crashes the app's process.

For more information, see UpdateAppWidget.

Chức năng cốt lõi

Android 17 có những thay đổi sau đây giúp sửa đổi hoặc mở rộng nhiều chức năng cốt lõi của hệ thống Android.

Cách triển khai MessageQueue mới không khoá

Beginning with Android 17, apps targeting Android 17 (API level 37) or higher receive a new lock-free implementation of android.os.MessageQueue. The new implementation improves performance and reduces missed frames, but may break clients that reflect on MessageQueue private fields and methods.

For more information, including mitigation strategies, see MessageQueue behavior change guidance.

Các trường cuối cùng tĩnh hiện không thể sửa đổi

Apps running on Android 17 or higher that target Android 17 (API level 37) or higher cannot change static final fields. If an app attempts to change a static final field by using reflection, it will cause an IllegalAccessException. Attempting to modify one of these fields through JNI APIs (such as SetStaticLongField()) will cause the app to crash.

Hỗ trợ tiếp cận

Android 17 có những thay đổi sau đây để cải thiện khả năng hỗ trợ tiếp cận.

Hỗ trợ tiếp cận cho việc nhập bằng bàn phím vật lý của IME phức tạp

Tính năng này giới thiệu các API AccessibilityEvent và TextAttribute mới để cải thiện tính năng phản hồi bằng giọng nói của trình đọc màn hình cho nội dung nhập bằng ngôn ngữ CJKV. Giờ đây, các ứng dụng CJKV IME có thể báo hiệu liệu một đề xuất chuyển đổi văn bản đã được chọn trong quá trình soạn văn bản hay chưa. Các ứng dụng có trường chỉnh sửa có thể chỉ định các loại thay đổi văn bản khi gửi sự kiện hỗ trợ tiếp cận đã thay đổi văn bản. Ví dụ: các ứng dụng có thể chỉ định rằng một thay đổi về văn bản đã xảy ra trong quá trình soạn văn bản hoặc một thay đổi về văn bản là kết quả của một thao tác xác nhận. Việc này cho phép các dịch vụ hỗ trợ tiếp cận (chẳng hạn như trình đọc màn hình) đưa ra ý kiến phản hồi chính xác hơn dựa trên bản chất của nội dung sửa đổi văn bản.

Số ứng dụng sử dụng

• Ứng dụng IME: Khi đặt văn bản soạn thảo trong các trường chỉnh sửa, IME có thể dùng TextAttribute.Builder.setTextSuggestionSelected() để cho biết liệu một đề xuất chuyển đổi cụ thể có được chọn hay không.

• Ứng dụng có tính năng Chỉnh sửa trường: Ứng dụng duy trì InputConnection tuỳ chỉnh có thể truy xuất dữ liệu lựa chọn đề xuất bằng cách gọi TextAttribute.isTextSuggestionSelected(). Sau đó, các ứng dụng này sẽ gọi AccessibilityEvent.setTextChangeTypes() khi gửi các sự kiện TYPE_VIEW_TEXT_CHANGED. Theo mặc định, các ứng dụng nhắm đến Android 17 (API cấp 37) sử dụng TextView tiêu chuẩn sẽ bật tính năng này. (Tức là TextView sẽ xử lý việc truy xuất dữ liệu từ IME và thiết lập các loại thay đổi văn bản khi gửi sự kiện đến các dịch vụ hỗ trợ tiếp cận).

• Dịch vụ hỗ trợ tiếp cận: Các dịch vụ hỗ trợ tiếp cận xử lý sự kiện TYPE_VIEW_TEXT_CHANGED có thể gọi AccessibilityEvent.getTextChangeTypes() để xác định bản chất của nội dung sửa đổi và điều chỉnh chiến lược phản hồi cho phù hợp.

Quyền riêng tư

Android 17 có những thay đổi sau đây để cải thiện quyền riêng tư của người dùng.

Đã bật ECH (Encrypted Client Hello)

Android 17 giới thiệu tính năng hỗ trợ nền tảng cho Encrypted Client Hello (ECH), một tiện ích TLS giúp tăng cường quyền riêng tư của người dùng bằng cách mã hoá Chỉ báo tên máy chủ (SNI) trong quy trình bắt tay TLS. Quá trình mã hoá này giúp ngăn chặn những người quan sát mạng dễ dàng xác định miền cụ thể mà ứng dụng của bạn đang kết nối.

Đối với các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên, ECH được dùng cho các kết nối TLS. ECH chỉ hoạt động nếu thư viện mạng mà ứng dụng sử dụng (ví dụ: HttpEngine, WebView hoặc OkHttp) đã tích hợp tính năng hỗ trợ ECH và máy chủ từ xa cũng hỗ trợ giao thức ECH. Nếu không thương lượng được ECH, thì máy khách sẽ gửi một tiện ích ECH có nội dung ngẫu nhiên (một cơ chế gọi là ECH GREASE). Hãy xem RFC 9849 để biết thêm thông tin chi tiết về cách hoạt động của ECH GREASE.

Để cho phép các ứng dụng tuỳ chỉnh hành vi này, Android 17 sẽ thêm một phần tử <domainEncryption> mới vào tệp Cấu hình bảo mật mạng. Nhà phát triển có thể sử dụng <domainEncryption> trong thẻ <base-config> hoặc <domain-config> để chọn một chế độ ECH (ví dụ: "enabled" hoặc "disabled") trên cơ sở toàn cầu hoặc theo từng miền.

Để biết thêm thông tin, hãy xem tài liệu về Encrypted Client Hello.

Ứng dụng nhắm đến Android 17 cần có quyền truy cập vào mạng cục bộ

Android 17 giới thiệu quyền khi bắt đầu chạy ACCESS_LOCAL_NETWORK để bảo vệ người dùng khỏi hoạt động truy cập trái phép vào mạng cục bộ. Vì quyền này thuộc nhóm quyền NEARBY_DEVICES hiện có, nên những người dùng đã cấp các quyền NEARBY_DEVICES khác sẽ không được nhắc lại. Yêu cầu mới này ngăn các ứng dụng độc hại khai thác quyền truy cập mạng cục bộ không hạn chế để theo dõi người dùng và tạo vân tay số một cách bí mật. Bằng cách khai báo và yêu cầu quyền này, ứng dụng của bạn có thể khám phá và kết nối với các thiết bị trên mạng cục bộ (LAN), chẳng hạn như thiết bị nhà thông minh hoặc thiết bị nhận truyền nội dung.

Các ứng dụng nhắm đến Android 17 (API cấp 37) trở lên hiện có 2 cách để duy trì giao tiếp với các thiết bị LAN: Sử dụng bộ chọn thiết bị do hệ thống làm trung gian, bảo đảm quyền riêng tư để bỏ qua lời nhắc cấp quyền hoặc yêu cầu rõ ràng quyền mới này trong thời gian chạy để duy trì giao tiếp mạng cục bộ.

Để biết thêm thông tin, hãy xem tài liệu về Quyền truy cập vào mạng cục bộ.

Ẩn mật khẩu trên thiết bị thực

If an app targets Android 17 (API level 37) or higher and the user is using a physical input device (for example, an external keyboard), the Android operating system applies the new show_passwords_physical setting to all characters in the password field. By default, that setting hides all password characters.

The Android system shows the last-typed password character to help the user see if they mistyped the password. However, this is much less necessary with larger external keyboards. In addition, devices with external keyboards often have larger displays, which increases the danger of someone seeing the typed password.

If the user is using the device's touchscreen, the system applies the new show_passwords_touch setting.

Bảo vệ OTP cho tin nhắn SMS tiêu chuẩn

Beginning with Android 17, Android is extending its SMS OTP protection to apply to standard SMS messages (SMS messages containing an OTP that do not use the WebOTP or SMS Retriever formats). For most apps targeting Android 17 (API level 37) or higher, these SMS messages do not become available until three hours after receipt. This delay is intended to help prevent OTP hijacking. During this three hour delay, the SMS_RECEIVED_ACTION broadcast is withheld and SMS provider database queries are filtered. The SMS message is available to these apps after the delay.

Certain apps such as the default SMS assistant app, connected device companion apps, etc., are exempted from this delay. All apps that rely on reading SMS messages for OTP extraction should transition to using SMS Retriever or SMS User Consent APIs to ensure continued functionality.

Bảo mật

Android 17 có những điểm cải tiến sau đây về tính bảo mật của thiết bị và ứng dụng.

Bảo mật hoạt động

Trong Android 17, nền tảng này tiếp tục chuyển sang cấu trúc "bảo mật theo mặc định", giới thiệu một loạt các điểm cải tiến được thiết kế để giảm thiểu các hành vi khai thác có mức độ nghiêm trọng cao, chẳng hạn như tấn công giả mạo, chiếm đoạt tương tác và tấn công nhầm lẫn. Bản cập nhật này yêu cầu nhà phát triển phải chọn áp dụng các tiêu chuẩn bảo mật mới một cách rõ ràng để duy trì khả năng tương thích của ứng dụng và bảo vệ người dùng.

Sau đây là những tác động chính đối với nhà phát triển:

• Tăng cường BAL và cải thiện lựa chọn tham gia: Chúng tôi đang tinh chỉnh các quy tắc hạn chế về Hoạt động khởi chạy ở chế độ nền (BAL) bằng cách mở rộng các biện pháp bảo vệ cho IntentSender. Nhà phát triển phải di chuyển khỏi hằng số MODE_BACKGROUND_ACTIVITY_START_ALLOWED cũ. Thay vào đó, bạn nên áp dụng các chế độ kiểm soát chi tiết như MODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE. Chế độ này hạn chế hoạt động bắt đầu trong các trường hợp ứng dụng gọi có thể nhìn thấy, giúp giảm đáng kể phạm vi tấn công.
• Công cụ áp dụng: Nhà phát triển nên sử dụng chế độ nghiêm ngặt và các chế độ kiểm tra lint mới nhất để xác định các mẫu cũ và đảm bảo đáp ứng các yêu cầu về SDK mục tiêu trong tương lai.

Bật CT theo mặc định

Nếu một ứng dụng nhắm đến Android 17 (API cấp 37) trở lên, thì tính minh bạch của chứng chỉ (CT) sẽ được bật theo mặc định. (Trên Android 16, CT có sẵn nhưng các ứng dụng phải chọn sử dụng.)

DCL gốc an toàn hơn – C

Nếu ứng dụng của bạn nhắm đến Android 17 (API cấp 37) trở lên, thì tính năng bảo vệ Tải mã động (DCL) an toàn hơn được giới thiệu trong Android 14 cho các tệp DEX và JAR hiện đã mở rộng sang các thư viện gốc.

Tất cả các tệp gốc được tải bằng System.load() đều phải được đánh dấu là chỉ đọc. Nếu không, hệ thống sẽ gửi ra UnsatisfiedLinkError.

Bất cứ khi nào có thể thì bạn nên tránh tải mã động, vì làm như vậy sẽ làm tăng đáng kể nguy cơ ứng dụng có thể bị xâm phạm do bị chèn mã hoặc can thiệp vào mã.

Hạn chế các trường PII trong chế độ xem dữ liệu CP2

Đối với các ứng dụng nhắm đến Android 17 (cấp độ API Android 17 (cấp độ API 37)) trở lên, Trình cung cấp danh bạ 2 (CP2) sẽ hạn chế một số cột chứa thông tin nhận dạng cá nhân (PII) trong chế độ xem dữ liệu. Khi bạn bật thay đổi này, các cột này sẽ bị xoá khỏi chế độ xem dữ liệu để tăng cường quyền riêng tư của người dùng. Các cột bị hạn chế bao gồm:

• ACCOUNT_NAME
• ACCOUNT_TYPE
• ACCOUNT_TYPE_AND_DATA_SET

Các ứng dụng đang sử dụng những cột này từ ContactsContract.Data có thể trích xuất những cột này từ ContactsContract.RawContacts thay vì vậy, bằng cách kết hợp với RAW_CONTACT_ID.

Thực thi các bước kiểm tra SQL nghiêm ngặt trong CP2

Đối với các ứng dụng nhắm đến Android 17 (API cấp Android 17 (API cấp 37)) trở lên, Contacts Provider 2 (CP2) sẽ thực thi quy trình xác thực nghiêm ngặt đối với truy vấn SQL khi bảng ContactsContract.Data được truy cập mà không có quyền READ_CONTACTS.

Với thay đổi này, nếu một ứng dụng không có quyền READ_CONTACTS, thì các lựa chọn StrictColumns và StrictGrammar sẽ được đặt khi truy vấn bảng ContactsContract.Data. Nếu một truy vấn sử dụng một mẫu không tương thích với các mẫu này, thì truy vấn đó sẽ bị từ chối và gây ra một ngoại lệ.

Phân tích thông tin

Android 17 có những thay đổi sau đây đối với tính năng thông minh trên hệ thống.

Ngừng sử dụng setContentCaptureEnabled

Tính năng Chụp nội dung được bật theo mặc định trên một số thiết bị để cho phép các tính năng AI trên thiết bị phân tích nội dung trên màn hình nhằm mang đến trải nghiệm thông minh.

Kể từ Android 17, phương thức API ContentCaptureManager.setContentCaptureEnabled(boolean) không còn được dùng nữa. Đối với các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên, việc gọi setContentCaptureEnabled(false) sẽ không còn vô hiệu hoá tính năng Ghi lại nội dung nữa.

Nếu ứng dụng của bạn cần tiếp tục tắt tính năng Chụp nội dung hoặc hạn chế hệ thống chụp nội dung trên màn hình, thì bạn phải chuyển sang sử dụng tham số bố cục cửa sổ FLAG_SECURE.

Để tắt tính năng Chụp nội dung, hãy đặt cờ FLAG_SECURE trên cửa sổ của bạn như minh hoạ trong ví dụ sau:

window.setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
)

getWindow().setFlags(
    WindowManager.LayoutParams.FLAG_SECURE,
    WindowManager.LayoutParams.FLAG_SECURE
);

Để biết thêm thông tin chi tiết, hãy xem tài liệu tham khảo về WindowManager.LayoutParams.FLAG_SECURE.

Nội dung nghe nhìn

Android 17 có những thay đổi sau đây về hành vi của nội dung nghe nhìn.

Tăng cường bảo mật âm thanh nền

Beginning with Android 17, the audio framework enforces restrictions on background audio interactions including audio playback, audio focus requests, and volume change APIs to ensure that these changes are started intentionally by the user.

Some audio restrictions apply to all apps. However, the restrictions are more stringent if an app targets Android 17 (API level 37). If one of these apps interacts with audio while it is in the background, it must have a foreground service running. In addition, the app must meet one or both of these requirements:

• The foreground service must have while-in-use (WIU) capabilities.
• The app must have the exact alarm permission and be interacting with USAGE_ALARM audio streams.

For more information, including mitigation strategies, see Background audio hardening.

Kiểu dáng thiết bị

Android 17 có những thay đổi sau đây để cải thiện trải nghiệm người dùng trên nhiều kích thước thiết bị và kiểu dáng.

Các thay đổi về Platform API để bỏ qua các quy tắc hạn chế về hướng, khả năng đổi kích thước và tỷ lệ khung hình trên màn hình lớn (sw>=600dp)

We introduced Platform API changes in Android 16 to ignore orientation, aspect ratio, and resizability restrictions on large screens (sw >= 600dp) for apps targeting API level 36 or higher. Developers have the option to opt out of these changes with SDK 36, but this opt-out will no longer be available for apps that target Android 17 (API level 37) or higher.

For more information, see Restrictions on orientation and resizability are ignored.

Khả năng kết nối

Android 17 có thay đổi sau đây để cải thiện tính nhất quán và điều chỉnh theo hành vi InputStream tiêu chuẩn của Java cho các điểm kết nối Bluetooth RFCOMM.

Hành vi nhất quán của BluetoothSocket read() đối với RFCOMM

For apps targeting Android 17 (API level 37), the read() method of the InputStream obtained from an RFCOMM-based BluetoothSocket now returns -1 when the socket is closed or the connection is dropped.

This change makes RFCOMM socket behavior consistent with LE CoC sockets and aligns with the standard InputStream.read() documentation, which states that -1 is returned when the end of the stream is reached.

Apps that rely solely on catching an IOException to break out of a read loop may be impacted by this change and should update the BluetoothSocket read loops to explicitly check for a return value of -1. This ensures the loop terminates correctly when the remote device disconnects or the socket is closed. For an example of the recommended implementation, see the code snippet in the Transfer Bluetooth data guide.