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

Nền tảng 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 áp dụng cho tất cả ứng dụng khi chạy trên Android 17, 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 các thay đổi về hành vi chỉ ảnh hưởng đến những ứng dụng nhắm đến Android 17.

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

Android 17 (cấp độ API 37) bao gồm những thay đổi sau đây nhằm sửa đổi hoặc mở rộng nhiều khả năng cốt lõi của hệ thống Android.

Giới hạn bộ nhớ của ứng dụng

Android 17 引入了基于设备总 RAM 的应用内存限制，旨在为您的应用和 Android 用户打造更稳定、更具确定性的环境。在 Android 17 中，限制设置得较为保守，目的是建立系统基准，在极端内存泄漏和其他异常情况触发系统范围的不稳定性（导致界面卡顿、耗电过快和应用被终止）之前，先针对这些情况。虽然我们预计对绝大多数 应用会话的影响很小，但我们建议遵循以下内存最佳实践， 包括建立内存基准。

您可以通过在 ApplicationExitInfo 中调用 getDescription 来确定应用会话是否受到影响；如果您的应用受到 影响，退出原因将为 REASON_OTHER 并且 说明将包含字符串 "MemoryLimiter:AnonSwap" 以及 其他信息。您还可以使用 基于触发器的分析（使用 TRIGGER_TYPE_ANOMALY）来获取在达到 内存限制时收集的堆转储。

Android Studio 性能分析器中的 LeakCanary 任务。

为了帮助您查找内存泄漏，Android Studio Panda 直接在 Android Studio 性能分析器中添加了 LeakCanary 集成，作为 IDE 中特定任务，并与您的源代码完全集成。

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ảo vệ mã OTP qua tin nhắn SMS

从 Android 17 开始，Android 将扩大对包含一次性密码 (OTP) 的短信的保护范围。

在之前的 Android 版本中，此保护主要侧重于 SMS Retriever 格式。对于大多数应用，包含 SMS Retriever 哈希的消息的递送延迟了 3 小时。不过，某些特定应用（例如默认短信处理程序）不受此延迟的影响，拥有哈希的应用也不受此延迟的影响。

从 Android 17 开始，此保护也适用于 WebOTP 格式的消息。如果应用有权读取短信，但不是 WebOTP 消息的预期接收者（由网域验证确定），则该应用在收到消息后 3 小时内无法访问该消息。此变更旨在提高用户安全性，确保只有与消息中提及的网域关联的应用才能以程序化方式读取验证码。

在这 3 小时的延迟期间，系统会保留 SMS_RECEIVED_ACTION 广播，并过滤 短信提供商 数据库查询。延迟结束后，这些应用即可使用短信。此变更适用于 所有应用，无论其目标 API 级别如何。

某些应用（例如默认短信辅助应用、已连接设备配套应用等）不受此延迟的影响。所有依赖于读取短信 来提取 动态密码 的应用都应过渡到使用 SMS Retriever 或 SMS User Consent API，以确保功能持续可用。

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.

kế hoạch ngừng sử dụng usesClearTraffic

Trong một bản phát hành trong tương lai, chúng tôi dự định sẽ ngừng sử dụng phần tử usesCleartextTraffic. Những ứng dụng cần thực hiện kết nối không được mã hoá (HTTP) nên di chuyển sang sử dụng tệp cấu hình bảo mật mạng. Tệp này cho phép bạn chỉ định những miền mà ứng dụng cần kết nối văn bản thô.

Xin lưu ý rằng tệp cấu hình bảo mật mạng chỉ được hỗ trợ trên API cấp 24 trở lên. Nếu ứng dụng của bạn có cấp độ API tối thiểu thấp hơn 24, bạn nên thực hiện cả hai việc sau:

  • Đặt thuộc tính usesCleartextTraffic thành true
  • Sử dụng tệp cấu hình mạng

Nếu cấp độ API tối thiểu của ứng dụng là 24 trở lên, bạn có thể sử dụng tệp cấu hình mạng và không cần đặt usesCleartextTraffic.

Hạn chế các quyền ngầm định đối với URI

Hiện tại, nếu một ứng dụng khởi chạy một ý định có URI với thao tác ACTION_SEND, ACTION_SEND_MULTIPLE hoặc ACTION_IMAGE_CAPTURE, thì hệ thống sẽ tự động cấp quyền đọc và ghi URI cho ứng dụng đích. Kể từ Android 18, hệ thống sẽ không tự động cấp các quyền này nữa. Vì lý do này, bạn nên cấp quyền URI có liên quan một cách rõ ràng cho các ứng dụng thay vì dựa vào hệ thống để cấp quyền.

Để phát hiện việc sử dụng các ý định này trong ứng dụng, hãy dùng StrictMode với detectImplicitUriPermissionGrant() để kích hoạt lỗi vi phạm:

Kotlin

val policy = StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build()
StrictMode.setVmPolicy(policy)

Java

StrictMode.VmPolicy policy = new StrictMode.VmPolicy.Builder()
    .detectImplicitUriPermissionGrant()
    .penaltyLog()
    .build();
StrictMode.setVmPolicy(policy);

Ngoài ra, bạn có thể theo dõi các ngoại lệ đã ghi nhật ký có chứa thông báo Please set the grant explicitly in the app xuất hiện khi hệ thống ngầm đặt quyền truy cập. Bạn có thể theo dõi các nhật ký này bằng lệnh adb sau:

adb logcat | grep "Please set the grant explicitly in the app"

Để cấp các quyền cần thiết một cách rõ ràng, hãy thêm cờ FLAG_GRANT_READ_URI_PERMISSION vào ý định ACTION_SEND và ACTION_SEND_MULTIPLE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION);

Thêm cả cờ FLAG_GRANT_READ_URI_PERMISSION và FLAG_GRANT_WRITE_URI_PERMISSION cho các ý định ACTION_IMAGE_CAPTURE:

Kotlin

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION)

Java

intent.addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION | Intent.FLAG_GRANT_WRITE_URI_PERMISSION);

Hạn mức kho khoá cho mỗi ứng dụng

应用应避免在 Android 密钥库中创建过多的密钥，因为它是设备上所有应用的共享资源。从 Android 17 开始，系统会强制限制应用可拥有的密钥数量。对于以 Android 17（API 级别 37）或更高版本为目标平台的非系统应用，密钥数量上限为 50,000 个；对于所有其他应用，密钥数量上限为 200,000 个。无论系统应用以哪个 API 级别为目标，其密钥数量上限均为 20 万。

如果应用尝试创建超出限制的密钥，则创建会失败并显示 KeyStoreException。异常的消息字符串包含有关密钥限制的信息。如果应用针对异常调用 getNumericErrorCode()，则返回值取决于应用的目标 API 级别：

  • 如果应用以 Android 17（API 级别 37）或更高版本为目标平台，getNumericErrorCode() 会返回新的 ERROR_TOO_MANY_KEYS 值。
  • 所有其他应用：getNumericErrorCode() 返回 ERROR_INCORRECT_USAGE。

Chặn lưu lượng truy cập loopback trong hồ sơ

Kể từ Android 17, lưu lượng truy cập vòng lặp liên hồ sơ không còn được phép theo mặc định. Lưu lượng truy cập vòng lặp trong cùng một hồ sơ sẽ không bị ảnh hưởng. Thay đổi này áp dụng cho tất cả ứng dụng chạy trên Android 17 trở lên, bất kể ứng dụng nhắm đến cấp độ API nào.

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 lại trải nghiệm nhất quán và trực quan hơn cho người dùng.

Khôi phục chế độ hiển thị IME mặc định sau khi xoay

Kể từ Android 17, khi cấu hình của thiết bị thay đổi (ví dụ: thông qua thao tác xoay) và ứng dụng không tự xử lý việc này, thì chế độ hiển thị IME trước đó sẽ không được khôi phục.

Nếu ứng dụng của bạn trải qua một thay đổi về cấu hình mà ứng dụng không xử lý và ứng dụng cần bàn phím hiển thị sau khi thay đổi, thì bạn phải yêu cầu rõ ràng điều này. Bạn có thể gửi yêu cầu này theo một trong những cách sau:

  • Đặt thuộc tính android:windowSoftInputMode thành stateAlwaysVisible.
  • Yêu cầu bàn phím mềm theo phương thức lập trình trong phương thức onCreate() của hoạt động hoặc thêm phương thức onConfigurationChanged().

Hoạt động đầu vào của người dùng

Android 17 có những thay đổi sau đây ảnh hưởng đến cách ứng dụng tương tác với các thiết bị đầu vào của con người, chẳng hạn như bàn phím và bàn di chuột.

Theo mặc định, bàn di chuột sẽ gửi các sự kiện tương đối trong quá trình ghi lại con trỏ

Kể từ Android 17, nếu một ứng dụng yêu cầu tính năng ghi lại con trỏ bằng View.requestPointerCapture() và người dùng sử dụng bàn di chuột, thì hệ thống sẽ nhận ra chuyển động của con trỏ và cử chỉ cuộn từ thao tác chạm của người dùng, đồng thời báo cáo các cử chỉ đó cho ứng dụng theo cách tương tự như chuyển động của con trỏ và bánh xe cuộn từ chuột đã ghi lại. Trong hầu hết các trường hợp, điều này giúp các ứng dụng hỗ trợ chuột đã ghi lại không cần thêm logic xử lý đặc biệt cho bàn di chuột. Để biết thêm thông tin chi tiết, hãy xem tài liệu về View.POINTER_CAPTURE_MODE_RELATIVE.

Trước đây, hệ thống không cố gắng nhận ra cử chỉ từ bàn di chuột mà thay vào đó, cung cấp vị trí ngón tay tuyệt đối, thô cho ứng dụng ở định dạng tương tự như thao tác chạm trên màn hình cảm ứng. Nếu một ứng dụng vẫn yêu cầu dữ liệu tuyệt đối này, thì ứng dụng đó nên gọi phương thức mới bằng thay vì.View.requestPointerCapture(int)View.POINTER_CAPTURE_MODE_ABSOLUTE

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 ở chế độ nền

Kể từ Android 17, khung âm thanh sẽ thực thi các hạn chế đối với hoạt động tương tác âm thanh ở chế độ nền, bao gồm cả việc phát âm thanh, yêu cầu lấy quyền phát âm thanh và API thay đổi âm lượng để đảm bảo rằng người dùng chủ động bắt đầu những thay đổi này.

Nếu ứng dụng cố gắng gọi API âm thanh trong khi ứng dụng không ở trong một vòng đời hợp lệ, thì API phát âm thanh và API thay đổi âm lượng sẽ âm thầm không thành công mà không đưa ra một ngoại lệ hoặc cung cấp thông báo lỗi. API quyền phát âm thanh không thành công với mã kết quả AUDIOFOCUS_REQUEST_FAILED.

Để biết thêm thông tin, bao gồm cả các chiến lược giảm thiểu, hãy xem bài viết Tăng cường bảo mật âm thanh ở chế độ nền.

Khả năng kết nối

Android 17 có những thay đổi sau đây để tăng cường khả năng kết nối của thiết bị.

Tự động ghép nối lại khi mất liên kết Bluetooth

Android 17 引入了自主重新配对功能，这是一项系统级增强功能，旨在自动解决蓝牙配对信息丢失问题。

以前，如果配对信息丢失，用户必须手动前往“设置”取消配对，然后重新配对外围设备。此功能以 Android 16 的安全改进为基础，允许系统在后台重新建立配对信息，而无需用户手动前往“设置”取消配对并重新配对外围设备。

虽然大多数应用不需要更改代码，但开发者应注意蓝牙堆栈中的以下行为变更：

  • 新的配对上下文： ACTION_PAIRING_REQUEST 现在包含 EXTRA_PAIRING_CONTEXT extra，允许应用区分 标准配对请求和自主系统发起的重新配对尝试。
  • 有条件的密钥更新：只有在重新配对成功且新连接达到或超过之前配对信息的安全级别时，才会替换现有安全密钥。
  • 修改后的 intent 时间：现在，只有在自主重新配对尝试失败时，才会广播 ACTION_KEY_MISSING intent。如果系统在后台成功恢复配对信息，则可以减少应用中不必要的错误处理。
  • 用户通知：系统通过新的界面通知和对话框管理重新配对。系统会提示用户确认重新配对尝试，以确保用户了解重新连接。

外围设备制造商和配套应用开发者应验证硬件和应用是否能妥善处理配对信息转换。如需测试此行为，请使用以下任一方法模拟远程配对信息丢失：

  • 从外围设备中手动移除配对信息
  • 在“设置”>“已连接的设备”中手动取消配对设备