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 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 lại 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ớ
Kể từ Android 17, đối với các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên, hệ thống sẽ thực thi giới hạn bộ nhớ nghiêm ngặt (1,5 * chiều rộng màn hình * chiều cao màn hình * 4) đối với mức sử dụng bộ nhớ kết hợp của cả Bitmap và Biểu tượng có trong gói RemoteViews. Nếu vượt quá các giới hạn này, ứng dụng sẽ gặp lỗi nghiêm trọng IllegalArgumentException và quy trình của ứng dụng sẽ gặp sự cố.
Để biết thêm thông tin, hãy xem UpdateAppWidget.
Chức năng cốt lõi
Android 17 có những thay đổi sau đây nhằm 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 cần khoá
Kể từ Android 17, các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên sẽ nhận được một phương thức triển khai mới không khoá của android.os.MessageQueue. Cách triển khai mới giúp cải thiện hiệu suất và giảm số khung hình bị bỏ lỡ, nhưng có thể làm hỏng các ứng dụng khách phản ánh trên các trường và phương thức riêng tư của MessageQueue.
Để biết thêm thông tin, bao gồm cả các chiến lược giảm thiểu, hãy xem Hướng dẫn về thay đổi hành vi của MessageQueue.
Các trường cuối cùng tĩnh hiện không thể sửa đổi
Ứng dụng chạy trên Android 17 trở lên nhắm đến Android 17 (cấp độ API 37) trở lên không thể thay đổi các trường static final. Nếu một ứng dụng cố gắng thay đổi trường static final bằng cách sử dụng phản chiếu, thì việc này sẽ gây ra IllegalAccessException. Nếu bạn cố gắng sửa đổi một trong các trường này thông qua API JNI (chẳng hạn như SetStaticLongField()), thì ứng dụng sẽ gặp sự cố.
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 thao tác nhập phức tạp bằng bàn phím vật lý IME
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 phương thức nhập ngôn ngữ CJKV. Giờ đây, các ứng dụng IME CJKV 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. Ứng dụng có trường chỉnh sửa có thể chỉ định 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ụ: ứng dụng có thể chỉ định rằng thay đổi văn bản đã xảy ra trong quá trình soạn văn bản hoặc thay đổi văn bản là kết quả của một thay đổi.
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) cung cấp ý kiến phản hồi chính xác hơn dựa trên bản chất của việc 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ể sử dụng
TextAttribute.Builder.setTextSuggestionSelected()để cho biết liệu một đề xuất chuyển đổi cụ thể đã được chọn hay chưa.Ứng dụng có trường chỉnh sửa: Ứng dụng duy trì
InputConnectiontuỳ chỉnh có thể truy xuất dữ liệu lựa chọn đề xuất bằng cách gọiTextAttribute.isTextSuggestionSelected(). Sau đó, các ứng dụng này sẽ gọiAccessibilityEvent.setTextChangeTypes()khi gửi sự kiệnTYPE_VIEW_TEXT_CHANGED. Những ứng dụng nhắm đến Android 17 (API cấp 37) sử dụngTextViewtiêu chuẩn sẽ được bật tính năng này theo mặc định. (Tức làTextViewsẽ xử lý việc truy xuất dữ liệu từ IME và đặt các loại thay đổi văn bản khi gửi sự kiện đến 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_CHANGEDcó thể gọiAccessibilityEvent.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 ra mắt tính năng hỗ trợ nền tảng cho Client Hello được mã hoá (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 quá trình bắt tay TLS. Việc 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ể thương lượng ECH, ứng dụng khách sẽ gửi một tiện ích ECH có nội dung ngẫu nhiên (một cơ chế có tên 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 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 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.
Cần có quyền truy cập vào mạng cục bộ đối với các ứng dụng nhắm đến Android 17
Android 17 ra mắt quyền khi bắt đầu chạy ACCESS_LOCAL_NETWORK để bảo vệ người dùng khỏi hành vi 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 không hạn chế vào mạng cục bộ để theo dõi người dùng và thu thập vân tay số một cách lén lú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.
Các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên hiện có hai cách để duy trì hoạt động giao tiếp với các thiết bị LAN: Sử dụng bộ chọn thiết bị do hệ thống điều phối, đảm bảo 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ì hoạt động giao tiếp trong 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 khỏi thiết bị thực
Nếu một ứng dụng nhắm đến Android 17 (API cấp 37) trở lên và người dùng đang sử dụng
một thiết bị đầu vào thực (ví dụ: bàn phím ngoài), thì hệ điều hành Android
sẽ áp dụng chế độ cài đặt show_passwords_physical mới cho tất cả
ký tự trong trường mật khẩu. Theo mặc định, chế độ cài đặt đó sẽ ẩn tất cả ký tự mật khẩu.
Hệ thống Android hiển thị ký tự mật khẩu được nhập gần đây nhất để giúp người dùng biết liệu họ có nhập sai mật khẩu hay không. Tuy nhiên, điều này ít cần thiết hơn nhiều đối với bàn phím ngoài lớn hơn. Ngoài ra, các thiết bị có bàn phím ngoài thường có màn hình lớn hơn, làm tăng nguy cơ người khác nhìn thấy mật khẩu đã nhập.
Nếu người dùng đang sử dụng màn hình cảm ứng của thiết bị, thì hệ thống sẽ áp dụng chế độ cài đặt show_passwords_touch mới.
Bảo vệ OTP cho tin nhắn SMS thông thường
Kể từ Android 17, Android sẽ mở rộng tính năng bảo vệ OTP qua SMS để áp dụng cho các tin nhắn SMS tiêu chuẩn (tin nhắn SMS chứa OTP không sử dụng định dạng WebOTP hoặc Trình truy xuất SMS). Đối với hầu hết ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên, các tin nhắn SMS này sẽ không xuất hiện cho đến 3 giờ sau khi nhận được. Khoảng thời gian trễ này nhằm giúp
ngăn chặn hành vi chiếm đoạt OTP. Trong thời gian trì hoãn 3 giờ này, thông báo truyền tin SMS_RECEIVED_ACTION sẽ bị giữ lại và các truy vấn cơ sở dữ liệu của nhà cung cấp dịch vụ SMS sẽ được lọc. Tin nhắn SMS sẽ được gửi đến các ứng dụng này sau khoảng thời gian trễ.
Một số ứng dụng nhất định như ứng dụng trợ lý SMS mặc định, ứng dụng đồng hành của thiết bị thông minh, v.v. được miễn áp dụng độ trễ này. Tất cả ứng dụng dựa vào việc đọc tin nhắn SMS để trích xuất OTP nên chuyển sang sử dụng API Trình truy xuất SMS hoặc Sự đồng ý của người dùng SMS để đảm bảo chức năng tiếp tục hoạt động.
Bảo mật
Android 17 mang đến những điểm cải tiến sau đây về khả năng 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 kiến trúc "bảo mật theo mặc định", giới thiệu một bộ tính năng nâng cao đượ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ư lừa đảo, chiếm đoạt hoạt động tương tác và tấn công uỷ quyền 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 sử 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 tính năng chọn sử dụng: Chúng tôi đang tinh chỉnh các quy định hạn chế về việc Chạy hoạt động ở 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 ngừng sử dụng hằng sốMODE_BACKGROUND_ACTIVITY_START_ALLOWEDcũ. Thay vào đó, bạn nên sử dụng các chế độ kiểm soát chi tiết nhưMODE_BACKGROUND_ACTIVITY_START_ALLOW_IF_VISIBLE, giúp hạn chế việc bắt đầu hoạt động trong các trường hợp ứng dụng gọi điện hiển thị, nhờ đó giảm đáng kể bề mặt 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 quy trình kiểm tra tìm lỗi mã nguồn mới nhất để xác định các mẫu cũ và đảm bảo sẵn sàng đá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 ứng dụng phải chọn sử dụng.)
Safer Native DCL – C
Nếu ứng dụng của bạn nhắm đến Android 17 (cấp độ API 37) trở lên, thì biện pháp bảo vệ Tải mã động an toàn hơn (DCL) được giới thiệu trong Android 14 cho các tệp DEX và JAR hiện sẽ áp dụng cho cả thư viện gốc.
Tất cả tệp gốc được tải bằng System.load() 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 thông tin nhận dạng cá nhân (PII) trong chế độ xem dữ liệu CP2
Đối với các ứng dụng nhắm đến 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 thay đổi này được áp dụng, 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:
Các ứng dụng đang sử dụng những cột này từ ContactsContract.Data có thể trích xuất các cột đó từ ContactsContract.RawContacts bằng cách kết hợp với RAW_CONTACT_ID.
Thực thi các quy trình 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 37) trở lên, Trình cung cấp danh bạ 2 (CP2) thực thi quy trình xác thực truy vấn SQL nghiêm ngặt 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 tuỳ 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ẫ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 ngoại lệ.
Phân tích thông tin
Android 17 có những thay đổi sau đây đối với hệ thống thông minh.
Ngừng sử dụng setContentCaptureEnabled
Tính năng Ghi lại 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 tắt tính năng Chụp 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 Ghi lại nội dung, hãy đặt cờ FLAG_SECURE trên cửa sổ của bạn như trong ví dụ sau:
Kotlin
window.setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
)
Java
getWindow().setFlags(
WindowManager.LayoutParams.FLAG_SECURE,
WindowManager.LayoutParams.FLAG_SECURE
);
Để biết thêm thông tin, 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 đối với hành vi của nội dung nghe nhìn.
Tăng cường bảo mật âm thanh nền
Kể từ Android 17, khung âm thanh sẽ thực thi các quy định hạn chế đối với các hoạt động tương tác âm thanh trong nền, bao gồm cả việc phát âm thanh, yêu cầu lấy tiêu điểm âm thanh và các API thay đổi âm lượng để đảm bảo rằng những thay đổi này được bắt đầu một cách có chủ đích bởi người dùng.
Một số quy định hạn chế về âm thanh áp dụng cho tất cả ứng dụng. Tuy nhiên, các quy định hạn chế sẽ nghiêm ngặt hơn nếu ứng dụng nhắm đến Android 17 (cấp độ API 37). Nếu một trong các ứng dụng này tương tác với âm thanh khi đang chạy ở chế độ nền, thì ứng dụng đó phải có một dịch vụ trên nền trước đang chạy. Ngoài ra, ứng dụng phải đáp ứng một hoặc cả hai yêu cầu sau:
- Dịch vụ nền trước phải có các chức năng khi đang sử dụng (WIU).
- Ứng dụng phải có quyền chuông báo chính xác và đang tương tác với các luồng âm thanh
USAGE_ALARM.
Để biết thêm thông tin, bao gồm cả các chiến lược giảm thiểu, hãy xem phần Tăng cường bảo mật âm thanh nền.
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 và kiểu dáng thiết bị.
Các thay đổi về API nền tảng để 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)
Chúng tôi đã giới thiệu các thay đổi đối với API nền tảng trong Android 16 để 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) cho các ứng dụng nhắm đến API cấp 36 trở lên. Nhà phát triển có thể chọn không tham gia những thay đổi này bằng SDK 36, nhưng lựa chọn này sẽ không còn áp dụng cho các ứng dụng nhắm đến Android 17 (cấp độ API 37) trở lên.
Để biết thêm thông tin, hãy xem phần Bỏ qua các quy định hạn chế về hướng và khả năng đổi kích thước.
Khả năng kết nối
Android 17 ra mắt thay đổi sau đây để cải thiện tính nhất quán và
phù hợp với hành vi InputStream chuẩn của Java cho các cổng Bluetooth RFCOMM.
Hành vi read() nhất quán của BluetoothSocket cho RFCOMM
Đối với các ứng dụng nhắm đến Android 17 (API cấp 37), phương thức read() của InputStream thu được từ BluetoothSocket dựa trên RFCOMM hiện sẽ trả về -1 khi ổ cắm bị đóng hoặc kết nối bị ngắt.
Thay đổi này giúp hành vi của ổ cắm RFCOMM nhất quán với ổ cắm LE CoC và phù hợp với tài liệu InputStream.read() tiêu chuẩn, trong đó nêu rõ rằng -1 được trả về khi đạt đến cuối luồng.
Những ứng dụng chỉ dựa vào việc bắt ngoại lệ IOException để thoát khỏi vòng lặp đọc dữ liệu có thể chịu ảnh hưởng của thay đổi này và nên cập nhật vòng lặp đọc dữ liệu BluetoothSocket để kiểm tra rõ ràng giá trị trả về là -1. Điều này đảm bảo vòng lặp kết thúc chính xác khi thiết bị từ xa ngắt kết nối hoặc ổ cắm bị đóng. Để xem ví dụ về cách triển khai được đề xuất, hãy xem đoạn mã trong hướng dẫn Chuyển dữ liệu Bluetooth.