Lớp trừu tượng nền tảng HAR

Sử dụng trình kết xuất có độ tin cậy cao (HAR) để hiển thị thông tin về xe mà Android không thể hiển thị. Điều này có thể xảy ra do các vấn đề như khởi động, tính khả dụng, an toàn hoặc quy định. HAR là một ứng dụng di động, tích hợp sẵn được viết bằng Rust.

HAR (còn gọi là khung HAR) bao gồm mã mà bạn dùng để xây dựng ứng dụng. Ứng dụng được xây dựng bằng HAR là ứng dụng dựa trên HAR. Khung HAR có các phần mã cho nhiều nền tảng. Ví dụ: trên hệ thống Linux, bạn dùng các thư viện như tinyalsa cho âm thanh. QNX có các thư viện âm thanh riêng.

Một nền tảng bao gồm phần cứng, hệ điều hành, thư viện hệ thống và các yếu tố khác. Mã dành riêng cho nền tảng có các phần được gọi là hệ thống con. Mỗi hệ thống con xử lý một tính năng của nền tảng, chẳng hạn như âm thanh, camera EVS hoặc dữ liệu trên xe. Để hỗ trợ một nền tảng, khung HAR cần triển khai tất cả các hệ thống con.

Mã hệ thống con dành riêng cho nền tảng có thể chạy trong cùng một quy trình với ứng dụng dựa trên HAR hoặc trong một quy trình riêng. Khi tách biệt, mã này xử lý giao tiếp giữa các quy trình (IPC) để giúp xác minh rằng nền tảng hỗ trợ ứng dụng. Các cơ chế IPC phức tạp phải là một phần của mã dành riêng cho nền tảng.

Bộ kiểm thử HAR chạy các bài kiểm thử trên tất cả hệ thống con được triển khai cho một nền tảng. Hãy dùng bộ thử nghiệm này để kiểm tra xem các nền tảng có đáp ứng yêu cầu của HAR hay không và tìm mọi vấn đề mới.

Thuật ngữ

Các thuật ngữ này có trên trang này:

Ứng dụng dựa trên HAR
Ứng dụng dành riêng cho OEM hoặc chức năng được xây dựng bằng khung HAR. Các ứng dụng khác nhau theo trạng thái ứng dụng và các khía cạnh có thể tuỳ chỉnh khác.
Khung HAR
Cung cấp một tập hợp công cụ cốt lõi dùng để xây dựng ứng dụng.
Tính trừu tượng của nền tảng HAR
Một phần của khung HAR cung cấp một API đã biết mà tất cả các nền tảng mục tiêu phải triển khai.
Bộ kiểm thử HAR
Một loạt bài kiểm thử đã biết về việc triển khai nền tảng, giúp xác minh rằng việc triển khai nền tảng hỗ trợ khung HAR trên một nền tảng nhất định.

Ngoài phạm vi

HAR không giải quyết:

  • Triển khai riêng cho tất cả mục tiêu nền tảng: Triển khai cho các nền tảng mục tiêu. Thay vào đó, trang này mô tả các giao diện mà việc triển khai nền tảng phải đáp ứng và bộ kiểm thử phải thoả mãn.

  • Trường hợp kiểm thử: Các trường hợp kiểm thử cụ thể cho tất cả giao diện. Thay vào đó, trang này mô tả các hàm riêng cho giao diện, bao gồm cả đối số, giá trị trả về, hành vi dự kiến và tác dụng phụ dự kiến. Trang này mô tả bộ kiểm thử mà bạn có thể triển khai và chạy các trường hợp kiểm thử.

Cấu trúc thùng chứa cấp cao của tính trừu tượng của nền tảng

Các dự án Rust bao gồm các thùng chứa. Hình 1 cho thấy cấu trúc thùng chứa cho lớp trừu tượng của nền tảng HAR. Lớp trừu tượng của nền tảng ảnh hưởng đến 2 hoặc nhiều thùng chứa Rust:

  • Các lớp trừu tượng (mô tả trait Rust) nằm trong thùng chứa khung HAR.

  • Việc triển khai cho một nền tảng là do một thùng chứa har-platform-x riêng biệt. Ví dụ: har-platform-linux hoặc har-platform-android.

Bạn không thể xây dựng hoặc kiểm thử thùng chứa HAR nếu không có hoạt động triển khai nền tảng được chỉ định. Đây là ý định vì khung HAR là một khung.

Ứng dụng chỉ định một nền tảng phải được xây dựng bằng khung này để hoạt động và được kiểm thử. Các kết nối giữa khung HAR và nền tảng nằm trong sơ đồ này:

Thùng HAR

Hình 1. Thùng chứa HAR.

Cấu trúc chung trong display-safety

Thiết kế này thêm một loạt thùng chứa mới vào kho lưu trữ display_safety, như minh hoạ trong Hình 2:

HAR crate, framework và ứng dụng

Hình 2. Mô-đun trừu tượng.

Bộ kiểm thử có cấu trúc tương tự như ứng dụng, nhưng chỉ dựa vào một thùng chứa triển khai nền tảng nhất định. Bộ kiểm thử phải tham chiếu đến các đặc điểm và cấu trúc được xác định trong khung HAR, nhưng không được tham chiếu đến các hoạt động triển khai phức tạp hơn.

Mô tả cấp cao về lớp trừu tượng của nền tảng

Bảng này mô tả các hệ thống con dành riêng cho nền tảng do lớp trừu tượng của nền tảng HAR xác định.

Tên lớp trừu tượng Hàm liên quan Mô tả Ghi chú
OpenGL Kết xuất 2D Cung cấp các tính năng kết xuất OpenGLES 2.0/3.0 cho thùng chứa khung HAR.
Audio Kết xuất âm thanh Cung cấp giao diện như Android SoundPool để quản lý và phát âm thanh hệ thống.
Camera Màn hình camera trên xe Cung cấp giao diện như EVS HAL để quản lý và hiển thị thông tin camera trên xe.
Looper Vòng lặp chính của ứng dụng và cấu hình màn hình Cung cấp giao diện như Android Looper để quản lý vòng lặp chính của ứng dụng dành riêng cho nền tảng và cấu hình màn hình.
UserInput Cảm ứng, bàn phím, vô lăng hoặc núm vặn điều khiển và các phương thức nhập khác dành riêng cho nền tảng Cung cấp giao diện để cung cấp cho các ứng dụng dựa trên HAR phương thức nhập bằng cảm ứng và bàn phím input. Triển khai tham chiếu dựa trên Linux evdev trong har-user-input-evdev.
VehicleData Phương thức nhập trạng thái xe Cung cấp giao diện để cung cấp cho các ứng dụng dựa trên HAR một luồng dữ liệu tuỳ ý trên xe, chẳng hạn như do Android VHAL hoặc a CAN bus cung cấp.
ResourceManager Tài liệu thiết kế được lưu vào bộ nhớ đệm dành riêng cho ứng dụng Cung cấp bộ nhớ đệm trong bộ nhớ của các tài nguyên cần thiết để khởi động HAR, chẳng hạn như hình ảnh được lưu vào bộ nhớ đệm và tài liệu thiết kế. Chưa triển khai bộ nhớ đệm của ổ đĩa.
Logging Ghi nhật ký hệ thống và đo từ xa Cung cấp tính năng hỗ trợ ghi nhật ký dành riêng cho nền tảng bằng hệ thống theo dõi. Điều này cho phép thu thập dữ liệu đo từ xa theo yêu cầu của nền tảng.
Tracing Theo dõi hệ thống Cung cấp một lớp trừu tượng để tích hợp với hệ thống theo dõi và lập hồ sơ.
Monitoring Giám sát hệ thống Bộ công cụ để giám sát hiệu suất và độ trễ trong khung HAR.
Commlib Dữ liệu trên xe Hoạt động triển khai tham chiếu bằng cách sử dụng quá trình chuyển đổi tuần tự protobuf. Không dùng nữa: Sử dụng các API được xác định trong reference/harry-control-api và các hoạt động triển khai harry-grpcio-serverharry-tonic-server (triển khai tham chiếu).
TestSupport Các hook hỗ trợ kiểm thử Hỗ trợ quá trình xây dựng và loại bỏ các trường hợp kiểm thử, tạo sự kiện kiểm thử và tạo cấu phần kiểm thử. Ví dụ: tạo các sự kiện cảm ứng mô phỏng để kiểm thử UserInput và tạo ảnh chụp màn hình để phân tích. Tính năng này bị Rust khoá để ngăn việc đưa vào các bản dựng sản xuất builds.

Quy ước đặt tên và cấu trúc khung

Bảng này trình bày các tên và cấu trúc sau:

  • Các thực thể trait hệ thống con dự kiến do khung HAR cung cấp. Mỗi trait đại diện cho một hệ thống con dành riêng cho nền tảng phải được triển khai.

  • Tên dự kiến của các hoạt động triển khai hệ thống con dành riêng cho nền tảng trong mọi thùng chứa nền tảng. Các ứng dụng dựa trên HAR mong muốn triển khai các tên cụ thể này.

  • Các thực thể enumstruct khung HAR liên quan thường được dùng để truyền thông tin từ các hoạt động triển khai liên quan đến nền tảng đến khung HAR.

Tên đặc điểm Tên hoạt động triển khai Enum và cấu trúc khung HAR
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (Cấu trúc) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing Không áp dụng
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Lỗi và cách xử lý lỗi

Các API được đề xuất sử dụng loại Result<> Rust. Rust yêu cầu bạn kiểm tra các loại Result có lỗi. Nếu không, trình biên dịch sẽ tạo cảnh báo hoặc lỗi. Quá trình kiểm tra thời gian xây dựng sẽ thực thi việc kiểm tra lỗi từ mã dành riêng cho nền tảng.

Các lỗi do hoạt động triển khai nền tảng trả về thuộc loại harry::error::Error. Để xác minh rằng các loại lỗi nền tảng không bị rò rỉ vào mã ứng dụng, hãy sử dụng loại lỗi tiêu chuẩn do khung HAR cung cấp.

Loại harry::error::Error mở rộng để bao gồm các lỗi cụ thể cho tất cả hệ thống con:

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Các lỗi không thể khôi phục chủ yếu được trả về thông qua các giao diện và lệnh gọi lại đã xác định.

Thiết kế chi tiết của bộ kiểm thử

Phần này mô tả thiết kế của bộ kiểm thử, xác minh các hoạt động triển khai trừu tượng dành riêng cho nền tảng.

Xây dựng các bài kiểm thử của bộ thử nghiệm

Đối với các bản dựng Soong (được xác định bằng tệp Android.bp), các bài kiểm thử được biên dịch như một phần của hệ thống xây dựng nền tảng Android và quá trình thực thi được atest quản lý.

Chạy bộ kiểm thử

Cách kiểm thử một nền tảng riêng lẻ:

Sử dụng lệnh atest với mục tiêu kiểm thử có liên quan (ví dụ: atest <module_name>). Lệnh này triển khai và chạy các bài kiểm thử trên thiết bị hoặc trình mô phỏng Android.