Android 10 có các thay đổi về hành vi hệ thống mới cập nhật có thể ảnh hưởng đến ứng dụng của bạn. Các thay đổi được liệt kê trên trang này chỉ áp dụng cho các ứng dụng nhắm đến API 29 trở lên. Nếu ứng dụng của bạn đặt targetSdkVersion thành "29" trở lên, bạn nên sửa đổi ứng dụng để hỗ trợ những hành vi này cho phù hợp (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 10.
Lưu ý: Ngoài các thay đổi được liệt kê trên trang này, Android 10 còn giới thiệu một số lượng lớn các thay đổi và quy định hạn chế dựa trên quyền riêng tư, bao gồm cả những thay đổi sau:
- Bộ nhớ có giới hạn
- Quyền truy cập vào số sê-ri của thiết bị USB
- Có thể bật, tắt và định cấu hình Wi-Fi
- Quyền truy cập thông tin vị trí cho API kết nối
Những thay đổi này ảnh hưởng đến các ứng dụng nhắm đến API cấp 29 trở lên, giúp tăng cường 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 Thay đổi về quyền riêng tư.
Nội dung cập nhật về 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 việc cung cấp các phương án thay thế công khai 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 thử ứ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ề các hạn chế đối với giao diện không phải SDK trong Android 10 và bài viết Các hạn chế đối với giao diện không phải SDK.
Bộ nhớ dùng chung
Ashmem đã thay đổi định dạng của bản đồ dalvik trong /proc/<pid>/maps, ảnh hưởng đến các ứng dụng trực tiếp phân tích cú pháp tệp bản đồ. Nhà phát triển ứng dụng nên kiểm thử định dạng /proc/<pid>/maps trên các thiết bị chạy Android 10 trở lên và phân tích cú pháp cho phù hợp nếu ứng dụng phụ thuộc vào định dạng bản đồ dalvik.
Các ứng dụng nhắm đến Android 10 không thể trực tiếp sử dụng ashmem (/dev/ashmem) mà phải truy cập vào bộ nhớ dùng chung thông qua lớp ASharedMemory của NDK.
Ngoài ra, các ứng dụng không thể tạo IOCTL trực tiếp đến các chỉ số mô tả tệp ashmem hiện có mà phải sử dụng lớp ASharedMemory của NDK hoặc API Java của Android để tạo vùng bộ nhớ dùng chung. Thay đổi này giúp tăng cường bảo mật và độ mạnh mẽ khi làm việc với bộ nhớ dùng chung, cải thiện hiệu suất và độ bảo mật của Android nói chung.
Xoá quyền thực thi cho thư mục gốc của ứng dụng
Việc thực thi các tệp trong thư mục gốc của ứng dụng có thể coi là một lỗi vi phạm W^X. Các ứng dụng chỉ nên tải mã nhị phân được nhúng trong tệp APK của ứng dụng.
Các ứng dụng không đáng tin cậy nhắm đến Android 10 không thể gọi execve() trực tiếp trên các tệp trong thư mục gốc của ứng dụng.
Ngoài ra, những ứng dụng nhắm đến Android 10 không thể sửa đổi mã thực thi trong bộ nhớ của những tệp đã mở bằng dlopen() và dự kiến các thay đổi đó sẽ được ghi vào ổ đĩa, vì thư viện không thể ánh xạ PROT_EXEC thông qua chỉ số mô tả tệp có thể ghi. Điều này bao gồm mọi tệp đối tượng được chia sẻ (.so) có hình thức chuyển vị trí văn bản.
Môi trường thời gian chạy Android chỉ chấp nhận các tệp OAT do hệ thống tạo
Môi trường thời gian chạy Android (ART) không còn gọi dex2oat từ quy trình ứng dụng nữa. Thay đổi này có nghĩa là ART sẽ chỉ chấp nhận các tệp OAT mà hệ thống đã tạo.
Thực thi tính chính xác của AOT trong ART
Trước đây, quá trình biên dịch trước (AOT) do Android Runtime (ART) thực hiện có thể gây ra sự cố thời gian chạy nếu môi trường đường dẫn lớp không giống nhau tại thời điểm biên dịch và thời gian chạy. Android 10 trở lên luôn yêu cầu các ngữ cảnh môi trường này phải giống nhau, dẫn đến các thay đổi sau đây về hành vi:
- Trình tải lớp tuỳ chỉnh (tức là trình tải lớp do ứng dụng viết, không giống như trình tải lớp từ gói
dalvik.system) không được biên dịch AOT. Điều này là do ART không thể biết về việc triển khai tính năng tra cứu lớp tuỳ chỉnh trong thời gian chạy. - Các tệp dex phụ (tức là các tệp dex được các ứng dụng không có trong tệp APK chính tải theo cách thủ công) được biên dịch AOT ở chế độ nền. Điều này là do quá trình biên dịch sử dụng lần đầu có thể quá tốn kém, dẫn đến độ trễ không mong muốn trước khi thực thi. Xin lưu ý rằng đối với ứng dụng, bạn nên sử dụng tính năng phân tách và loại bỏ các tệp dex phụ.
- Thư viện dùng chung trong Android (các mục <library> và <uses-library> trong tệp kê khai Android) được triển khai bằng hệ phân cấp trình tải lớp khác với hệ phân cấp được dùng trong các phiên bản trước của nền tảng.
Thay đổi về quyền đối với ý định toàn màn hình
Các ứng dụng nhắm đến Android 10 trở lên và sử dụng thông báo có ý định toàn màn hình phải yêu cầu quyền USE_FULL_SCREEN_INTENT trong tệp kê khai của ứng dụng. Đây là một quyền thông thường, vì vậy hệ thống sẽ tự động cấp quyền này cho ứng dụng yêu cầu.
Nếu một ứng dụng nhắm đến Android 10 trở lên cố gắng tạo thông báo có ý định toàn màn hình mà không yêu cầu quyền cần thiết, thì hệ thống sẽ bỏ qua ý định toàn màn hình và xuất ra thông điệp nhật ký sau:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Hỗ trợ thiết bị có thể gập lại
Android 10 có các thay đổi hỗ trợ thiết bị có thể gập lại và thiết bị màn hình lớn.
Khi một ứng dụng chạy trên Android 10, các phương thức onResume() và onPause() sẽ hoạt động theo cách khác nhau. Khi nhiều ứng dụng xuất hiện cùng lúc ở chế độ nhiều cửa sổ hoặc nhiều màn hình, tất cả các hoạt động trên cùng có thể lấy tiêu điểm trong ngăn xếp hiển thị đều ở trạng thái tiếp tục, nhưng chỉ một trong số đó, hoạt động "đã tiếp tục ở trên cùng", mới thực sự có tiêu điểm. Khi chạy trên các phiên bản cũ hơn Android 10, mỗi lần chỉ có thể tiếp tục một hoạt động trong hệ thống, tất cả các hoạt động hiển thị khác sẽ bị tạm dừng.
Đừng nhầm lẫn "tiêu điểm" với hoạt động "đã tiếp tục ở trên cùng". Hệ thống chỉ định mức độ ưu tiên cho các hoạt động dựa trên thứ tự z để ưu tiên cao hơn cho các hoạt động mà người dùng tương tác gần đây nhất. Một hoạt động có thể được tiếp tục ở trên cùng nhưng không có tiêu điểm (ví dụ: nếu ngăn thông báo được mở rộng).
Trong Android 10 (API cấp 29) trở lên, bạn có thể đăng ký lệnh gọi lại onTopResumedActivityChanged() để được thông báo khi hoạt động của bạn nhận được hoặc mất đi vị trí tiếp tục hàng đầu. Trạng thái này tương đương với trạng thái tiếp tục trước Android 10 và có thể hữu ích làm gợi ý nếu ứng dụng của bạn đang sử dụng các tài nguyên độc quyền hoặc singleton có thể cần được chia sẻ với các ứng dụng khác.
Hành vi của thuộc tính tệp kê khai resizeableActivity cũng đã thay đổi. Nếu một ứng dụng đặt resizeableActivity=false trong Android 10 (API cấp 29) trở lên, thì ứng dụng đó có thể được đặt ở chế độ tương thích khi kích thước màn hình hiện có thay đổi hoặc nếu ứng dụng di chuyển từ màn hình này sang màn hình khác.
Các ứng dụng có thể sử dụng thuộc tính android:minAspectRatio được giới thiệu trong Android 10 để cho biết tỷ lệ màn hình mà ứng dụng của bạn hỗ trợ.
Kể từ phiên bản 3.5, công cụ trình mô phỏng của Android Studio bao gồm các thiết bị ảo 7,3" và 8" để kiểm thử mã của bạn trên màn hình lớn hơn.
Để biết thêm thông tin, hãy xem bài viết Thiết kế ứng dụng cho thiết bị có thể gập lại.