Trong Android 10, ConfigStore HAL sử dụng cờ xây dựng để lưu trữ các giá trị cấu hình trong phân vùng vendor
và một dịch vụ trong phân vùng system
sẽ truy cập các giá trị đó bằng HIDL (điều này cũng đúng trong Android 9). Tuy nhiên, do mức tiêu thụ bộ nhớ cao và khó sử dụng nên ConfigStore HAL đã không còn được dùng nữa.
ConfigStore HAL vẫn còn trong AOSP để hỗ trợ các phân vùng cũ của nhà cung cấp. Trên các thiết bị chạy Android 10 trở lên, surfaceflinger
đọc thuộc tính hệ thống trước; nếu không có thuộc tính hệ thống nào được xác định cho mục cấu hình trong `SurfaceFlingerProperties.sysprop`, thì `surfaceflinger` sẽ quay trở lại ConfigStore HAL.
Android 8.0 chia hệ điều hành Android nguyên khối thành các phân vùng chung ( system.img
) và phần cứng dành riêng cho phần cứng ( vendor.img
và odm.img
). Do sự thay đổi này, việc biên dịch có điều kiện phải được loại bỏ khỏi các mô-đun được cài đặt vào phân vùng hệ thống và các mô-đun đó phải xác định cấu hình của hệ thống trong thời gian chạy (và hoạt động khác nhau tùy thuộc vào cấu hình đó).
ConfigStore HAL cung cấp một bộ API để truy cập các mục cấu hình chỉ đọc dùng để định cấu hình khung Android. Trang này mô tả thiết kế của ConfigStore HAL (và lý do tại sao các thuộc tính hệ thống không được sử dụng cho mục đích này); các trang khác trong phần này trình bày chi tiết về giao diện HAL , triển khai dịch vụ và cách sử dụng phía máy khách , tất cả đều sử dụng surfaceflinger
làm ví dụ. Để được trợ giúp về các lớp giao diện ConfigStore, hãy xem Thêm các lớp và mục giao diện .
Tại sao không sử dụng thuộc tính hệ thống?
Chúng tôi đã cân nhắc việc sử dụng các thuộc tính hệ thống nhưng nhận thấy một số vấn đề cơ bản, bao gồm:
- Giới hạn độ dài trên các giá trị. Thuộc tính hệ thống có giới hạn chặt chẽ về độ dài giá trị của chúng (92 byte). Ngoài ra, vì các giới hạn này đã được hiển thị trực tiếp cho các ứng dụng Android dưới dạng macro C nên việc tăng độ dài có thể gây ra các vấn đề về khả năng tương thích ngược.
- Không hỗ trợ loại. Tất cả các giá trị về cơ bản đều là chuỗi và API chỉ cần phân tích chuỗi thành
int
hoặcbool
. Các loại dữ liệu kết hợp khác (ví dụ: mảng và cấu trúc) phải được máy khách mã hóa/giải mã (ví dụ:"aaa,bbb,ccc"
có thể được mã hóa thành một mảng gồm ba chuỗi). - Ghi đè. Bởi vì các thuộc tính hệ thống chỉ đọc được triển khai dưới dạng thuộc tính ghi một lần, nên nhà cung cấp/ODM muốn ghi đè các giá trị chỉ đọc do AOSP xác định phải nhập các giá trị chỉ đọc của riêng họ trước các giá trị chỉ đọc do AOSP xác định. Ngược lại, điều này dẫn đến các giá trị có thể ghi lại do nhà cung cấp xác định bị ghi đè bởi các giá trị do AOSP xác định.
- Yêu cầu về không gian địa chỉ. Các thuộc tính hệ thống chiếm một lượng không gian địa chỉ tương đối lớn trong mỗi quy trình. Các thuộc tính hệ thống được nhóm thành các đơn vị
prop_area
với kích thước cố định là 128 KB, tất cả đều được phân bổ cho một không gian địa chỉ quy trình ngay cả khi chỉ một thuộc tính hệ thống duy nhất trong đó được truy cập. Điều này có thể gây ra sự cố trên các thiết bị 32 bit nơi không gian địa chỉ rất quý giá.
Chúng tôi đã cố gắng khắc phục những hạn chế này mà không làm mất đi khả năng tương thích nhưng vẫn tiếp tục lo ngại rằng các thuộc tính hệ thống không được thiết kế để hỗ trợ truy cập các mục cấu hình chỉ đọc. Cuối cùng, chúng tôi đã quyết định rằng các thuộc tính hệ thống phù hợp hơn để chia sẻ một số mục được cập nhật động trên toàn bộ Android trong thời gian thực và cần có một hệ thống mới dành riêng cho việc truy cập các mục cấu hình chỉ đọc.
Thiết kế ConfigStore HAL
Thiết kế cơ bản rất đơn giản:
Hình 1. Thiết kế ConfigStore HAL
- Mô tả các cờ xây dựng (hiện được sử dụng để biên dịch khung có điều kiện) trong HIDL.
- Nhà cung cấp và OEM cung cấp SoC và các giá trị dành riêng cho thiết bị cho cờ xây dựng bằng cách triển khai dịch vụ HAL.
- Sửa đổi khung để sử dụng dịch vụ HAL nhằm tìm giá trị của mục cấu hình khi chạy.
Các mục cấu hình hiện được khung tham chiếu được bao gồm trong gói HIDL được phiên bản ( android.hardware.configstore@1.0
). Nhà cung cấp/OEM cung cấp giá trị cho các mục cấu hình bằng cách triển khai các giao diện trong gói này và khung sử dụng các giao diện đó khi cần nhận giá trị cho một mục cấu hình.
Cân nhắc về Bảo mật
Cờ xây dựng được xác định trong cùng một giao diện bị ảnh hưởng bởi cùng một chính sách SELinux. Nếu một hoặc nhiều build flag có các chính sách SELinux khác nhau thì chúng phải được tách riêng sang một giao diện khác . Điều này có thể yêu cầu sửa đổi lớn android.hardware.configstore package
vì các giao diện riêng biệt không còn tương thích ngược nữa.