Android 10 cập nhật các thay đổi về hành vi hệ thống có thể ảnh hưởng đến ứng dụng của bạn. Những thay đổi nêu trên trang này chỉ áp dụng cho ứng dụng nhắm đến API cấp 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ó).
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 những thay đổi nêu trên trang này, Android 10 còn đưa ra nhiều thay đổi và hạn chế dựa trên quyền riêng tư, bao gồm:
- Bộ nhớ có giới hạn
- Quyền truy cập vào số sê-ri của thiết bị USB
- Khả năng bật, tắt và định cấu hình Wi-Fi
- Quyền truy cập thông tin vị trí đối với API khả năng 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 nâng cao 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 Các 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 đã bắt đầu hạn chế 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 rằng có sẵn các giải pháp 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ề những hạn chế đối với giao diện không phải SDK trên Android 10 và xem Quy định hạn chế đối với giao diện không phải SDK.
Kỷ niệm được chia sẻ
Ashmem đã thay đổi định dạng của bản đồ dalvik trong /proc/<pid>/maps, việc này ả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 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 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 IOTL trực tiếp cho phần mô tả tệp ashmem hiện có, mà phải sử dụng lớp ASharedMemory của NDK hoặc API Android Java để tạo vùng bộ nhớ dùng chung. Thay đổi này làm tăng tính bảo mật và tính mạnh mẽ khi làm việc với bộ nhớ dùng chung, cải thiện hiệu suất và tính bảo mật của Android nói chung.
Đã xoá quyền thực thi đối với 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ó thể ghi của ứng dụng bị coi là lỗi vi phạm W^X. Ứ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, các ứng dụng nhắm mục tiêu đến Android 10 trong bộ nhớ không thể sửa đổi mã thực thi từ các tệp đã mở bằng dlopen() và dự kiến những thay đổi đó sẽ được ghi vào ổ đĩa, vì thư viện không thể được ánh xạ PROT_EXEC thông qua một 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.
Android Runtime 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 ký 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 AOT trong ART
Trước đây, tính năng biên dịch trước khi chạy (AOT) do Android Runtime (ART) thực hiện có thể gây ra sự cố trong thời gian chạy nếu môi trường classpath 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 giống nhau, dẫn đến các thay đổi sau 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ề cách triển khai 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 tải thủ công bởi các ứng dụng không có trong APK chính – được biên dịch AOT trong nền. Nguyên nhân là do quá trình biên dịch trong lần sử dụng đầu tiên có thể quá tốn kém, dẫn đến độ trễ không mong muốn trước khi thực thi. Lưu ý đối với các ứng dụng, bạn nên sử dụng phần phân tách và di chuyển khỏi các tệp dex phụ.
- Thư viện dùng chung trong Android (các mục nhập <library> và <uses-library> trong tệp kê khai Android) được triển khai bằng một hệ phân cấp trình tải lớp khác với hệ phân cấp 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à quyền thông thường, do đó, hệ thống sẽ tự động cấp quyền đó 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 với ý đị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à đưa ra thông báo 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ó những thay đổi hỗ trợ thiết bị có thể gập lại và thiết bị có 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ả hoạt động trên cùng có thể làm tâm điểm trong các 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" thực sự có tâm điểm). Khi chạy trên các phiên bản trước Android 10, bạn chỉ có thể tiếp tục một hoạt động duy nhất trong hệ thống tại một thời điểm và mọi hoạt động hiển thị khác đều bị tạm dừng.
Đừng nhầm lẫn "tập trung" 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 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 từ trên cùng nhưng không có tâm đ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() để nhận thông báo khi hoạt động của bạn có được hoặc mất vị trí được tiếp tục trên cùng. Trạng thái này tương đương với trạng thái tiếp tục trước Android 10. Trạng thái này có thể hữu ích như một gợi ý nếu ứng dụng của bạn đang dùng tài nguyên độc quyền hoặc tài nguyên 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 có sẵn 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ể dùng thuộc tính android:minAspectRatio (ra mắt 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 sẽ bao gồm các thiết bị ảo 7,3" và 8" để kiểm thử mã trên màn hình lớn hơn.
Để biết thêm thông tin, hãy xem nội dung Thiết kế ứng dụng cho thiết bị có thể gập lại.