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 giúp 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 giới thiệu giới hạn bộ nhớ ứng dụng dựa trên tổng dung lượng RAM của thiết bị để tạo một môi trường ổn định và có thể xác định hơn cho các ứng dụng và người dùng Android. Trong Android 17, các giới hạn được đặt một cách thận trọng để thiết lập các đường cơ sở của hệ thống, nhắm đến tình trạng rò rỉ bộ nhớ nghiêm trọng và các giá trị ngoại lệ khác trước khi chúng gây ra tình trạng bất ổn trên toàn hệ thống, dẫn đến hiện tượng giật giao diện người dùng, mức tiêu hao pin cao hơn và ứng dụng bị tắt. Mặc dù dự đoán rằng tác động sẽ rất nhỏ đối với phần lớn các phiên hoạt động của ứng dụng, nhưng bạn nên làm theo các phương pháp hay nhất sau đây về bộ nhớ, bao gồm cả việc thiết lập đường cơ sở cho bộ nhớ.
Bạn có thể xác định xem phiên hoạt động của ứng dụng có bị ảnh hưởng hay không bằng cách gọi getDescription trong ApplicationExitInfo; nếu ứng dụng của bạn bị ảnh hưởng, lý do thoát sẽ là REASON_OTHER và nội dung mô tả sẽ chứa chuỗi "MemoryLimiter:AnonSwap" cùng với các thông tin khác. Bạn cũng có thể sử dụng hồ sơ dựa trên trình kích hoạt với TRIGGER_TYPE_ANOMALY để nhận các kết xuất heap được thu thập khi đạt đến giới hạn bộ nhớ.
Để giúp bạn tìm ra các lỗi rò rỉ bộ nhớ, Android Studio Panda bổ sung tính năng tích hợp LeakCanary ngay trong Trình phân tích tài nguyên Android Studio dưới dạng một tác vụ chuyên dụng, được ngữ cảnh hoá trong IDE và tích hợp đầy đủ với mã nguồn của bạn.
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 格式。对于大多数应用，包含短信检索器哈希的消息的传送延迟了 3 小时。不过，某些应用（例如默认 SMS 处理程序）不受此延迟限制，拥有哈希的应用也不受此限制。
从 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
我们计划在未来的版本中弃用 usesCleartextTraffic 元素。需要建立未加密 (HTTP) 连接的应用应迁移为使用网络安全配置文件，该文件可让您指定应用需要与哪些网域建立明文连接。
请注意，网络安全配置文件仅在 API 级别 24 及更高版本中受支持。如果您的应用的最低 API 级别低于 24，您应执行以下两项操作：
- 将
usesCleartextTraffic属性设置为true - 使用网络配置文件
如果应用的最低 API 级别为 24 或更高，您可以使用网络配置文件，而无需设置 usesCleartextTraffic。
Hạn chế các quyền ngầm định đối với URI
目前，如果应用使用具有 Send、
SendMultiple 或 ImageCapture 操作的 URI 启动 intent，系统会自动向目标应用授予读取和
写入 URI 权限。我们计划在
Android 18 中更改此行为。因此，我们建议应用显式授予相关 URI 权限，而不是依赖系统来授予这些权限。
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 vòng lặp 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:windowSoftInputModethànhstateAlwaysVisible. - 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ứconConfigurationChanged().
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 nền
从 Android 17 开始，音频框架会对后台音频互动（包括音频播放、音频焦点请求和音量更改 API）强制执行限制，以确保这些更改是由用户有意发起的。
如果应用尝试在应用未处于有效生命周期时调用音频 API，则音频播放和音量更改 API 会以静默方式失败，而不会抛出异常或提供失败消息。音频焦点 API 会失败，并返回结果代码 AUDIOFOCUS_REQUEST_FAILED。
如需了解详情（包括缓解措施），请参阅后台音频安全加固。
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 giới thiệu tính năng ghép nối lại tự động, một điểm cải tiến ở cấp hệ thống được thiết kế để tự động giải quyết tình trạng mất liên kết Bluetooth.
Trước đây, nếu mất liên kết, người dùng phải chuyển đến phần Cài đặt theo cách thủ công để huỷ liên kết rồi liên kết lại thiết bị ngoại vi. Tính năng này dựa trên việc cải thiện tính bảo mật của Android 16 bằng cách cho phép hệ thống thiết lập lại các mối liên kết ở chế độ nền mà không yêu cầu người dùng chuyển đến phần Cài đặt theo cách thủ công để hủy ghép nối và ghép nối lại các thiết bị ngoại vi.
Mặc dù hầu hết các ứng dụng sẽ không yêu cầu thay đổi mã, nhưng nhà phát triển cần lưu ý đến những thay đổi sau đây về hành vi trong ngăn xếp Bluetooth:
- Ngữ cảnh ghép nối mới:
ACTION_PAIRING_REQUESThiện bao gồm phần bổ sungEXTRA_PAIRING_CONTEXTcho phép các ứng dụng phân biệt giữa yêu cầu ghép nối tiêu chuẩn và nỗ lực ghép nối lại do hệ thống tự động khởi tạo. - Cập nhật khoá có điều kiện: Các khoá bảo mật hiện có sẽ chỉ được thay thế nếu quá trình ghép nối lại thành công và kết nối mới đáp ứng hoặc vượt quá mức bảo mật của mối liên kết trước đó.
- Đã sửa đổi thời gian dự định: Giờ đây, ý định
ACTION_KEY_MISSINGchỉ được truyền đi nếu không thể tự động ghép nối lại. Điều này giúp giảm việc xử lý lỗi không cần thiết trong ứng dụng nếu hệ thống khôi phục thành công mối liên kết ở chế độ nền. - Thông báo cho người dùng: Hệ thống quản lý việc ghép nối lại thông qua các thông báo và hộp thoại mới trên giao diện người dùng. Người dùng sẽ được nhắc xác nhận việc thử ghép nối lại để đảm bảo họ biết về việc kết nối lại.
Nhà sản xuất thiết bị ngoại vi và nhà phát triển ứng dụng đồng hành nên xác minh rằng phần cứng và ứng dụng xử lý các quá trình chuyển đổi liên kết một cách suôn sẻ. Để kiểm thử hành vi này, hãy mô phỏng tình trạng mất liên kết từ xa bằng một trong các phương thức sau:
- Xoá thông tin liên kết khỏi thiết bị ngoại vi theo cách thủ công
- Huỷ ghép nối thiết bị theo cách thủ công trong phần: Cài đặt > Thiết bị đã kết nối