Trình kích hoạt âm thanh

Tính năng Trình kích hoạt âm thanh cung cấp cho các ứng dụng khả năng theo dõi một số sự kiện âm thanh nhất định (như cụm từ kích hoạt) với mức công suất thấp và nhạy cảm về quyền riêng tư. Ví dụ về các trường hợp sử dụng của điều kiện kích hoạt bằng âm thanh là Trợ lý và Now Playing.

Trang này cung cấp thông tin tổng quan về cấu trúc của Trình kích hoạt âm thanh và giao diện HAL (Lớp trừu tượng phần cứng) của trình kích hoạt đó.

Ngăn xếp điều kiện kích hoạt âm thanh

Hệ thống con Kích hoạt âm thanh được xây dựng theo lớp như trong Hình 1:

Hình 1: Ngăn xếp Trình kích hoạt âm thanh

Danh sách sau đây mô tả chi tiết hơn về từng lớp được hiển thị trong Hình 1:

• Lớp HAL (màu xanh lục) chứa mã dành riêng cho nhà cung cấp triển khai giao diện Sound Trigger HAL (STHAL).

  Lưu ý: Bạn nên triển khai trực tiếp giao diện STHAL thay vì làm trình chuyển đổi xung quanh việc triển khai HAL cũ.

• SoundTriggerMiddleware (màu vàng) nằm phía trên giao diện HAL. Lớp này giao tiếp với HAL và chịu trách nhiệm về các chức năng như chia sẻ HAL giữa các ứng dụng, ghi nhật ký, thực thi quyền và xử lý khả năng tương thích với các phiên bản HAL cũ.

• Hệ thống SoundTriggerService (màu xanh dương) nằm phía trên phần mềm trung gian. Thư viện này hỗ trợ tích hợp với các tính năng hệ thống khác, chẳng hạn như điện thoại và sự kiện pin. Thư viện này cũng duy trì cơ sở dữ liệu về các mô hình âm thanh, được lập chỉ mục theo mã nhận dạng duy nhất.

• Phía trên lớp SoundTriggerService, ngăn xếp (màu nâu) xử lý các tính năng dành riêng cho Trợ lý và ứng dụng chung.

Chức năng của ngăn xếp Sound Trigger (Kích hoạt âm thanh) là phân phối các sự kiện riêng biệt đại diện cho các sự kiện kích hoạt âm thanh. Trong hầu hết các trường hợp, ngăn xếp Sound Trigger không xử lý âm thanh. Khi nhận được sự kiện kích hoạt, ứng dụng sẽ có quyền truy cập vào luồng âm thanh thực tế, xung quanh thời gian của sự kiện, bằng cách mở đối tượng AudioRecord thông qua Khung âm thanh. API HAL Trình kích hoạt âm thanh cung cấp tay xử lý sự kiện đã kích hoạt được sử dụng với Khung âm thanh. Do đó, vì HAL của Trình kích hoạt âm thanh và HAL âm thanh được kết nối nâng cao, nên chúng thường dùng chung một quy trình.

Lưu ý: Vì các mô hình và loại dữ liệu không rõ ràng đối với khung trong hệ thống con Kích hoạt âm thanh, nên dự kiến các ứng dụng và việc triển khai HAL sẽ duy trì một "hợp đồng ẩn", tức là nội dung, định dạng và ngữ nghĩa thực tế của các loại dữ liệu đó được thoả thuận. Do đó, các ứng dụng sử dụng tính năng Kích hoạt bằng âm thanh sẽ do nhà cung cấp cung cấp thay vì nhà phát triển độc lập.

Giao diện HAL của trình kích hoạt âm thanh

Giao diện HAL của Bộ kích hoạt âm thanh (STHAL) là phần dành riêng cho nhà cung cấp trong ngăn xếp Trình kích hoạt âm thanh, đồng thời xử lý hoạt động nhận dạng phần cứng đối với cụm từ kích hoạt và các âm thanh khác. STHAL cung cấp một hoặc nhiều công cụ, mỗi công cụ chạy một thuật toán khác nhau được thiết kế để phát hiện một loại âm thanh cụ thể. Khi phát hiện một điều kiện kích hoạt, STHAL sẽ gửi một sự kiện đến khung và sau đó dừng quá trình phát hiện.

Giao diện STHAL được chỉ định trong /hardware/interfaces/soundtrigger/.

Giao diện ISoundTriggerHw hỗ trợ khả năng chạy một hoặc nhiều phiên phát hiện tại một thời điểm nhất định và nghe các sự kiện âm thanh. Lệnh gọi đến ISoundTriggerHw.getProperties() sẽ trả về một cấu trúc Properties chứa nội dung mô tả và chức năng triển khai.

Quy trình cơ bản để thiết lập một phiên được giải thích như sau trong Hình 2:

Hình 2: Sơ đồ trạng thái STHAL

Các bước sau đây mô tả chi tiết hơn về từng trạng thái:

1. Ứng dụng HAL tải một mô hình bằng loadSoundModel() hoặc loadPhraseSoundModel(). Đối tượng mô hình được cung cấp cho biết nên sử dụng thuật toán (công cụ) phát hiện dành riêng cho phương thức triển khai nào, cũng như các tham số áp dụng cho thuật toán này. Khi thành công, các phương thức này sẽ trả về một handle dùng để tham chiếu mô hình này trong các lệnh gọi tiếp theo.

2. Sau khi tải thành công mô hình, ứng dụng HAL sẽ gọi startRecognition() để bắt đầu phát hiện. Tính năng nhận dạng sẽ tiếp tục chạy ở chế độ nền cho đến khi một trong các sự kiện sau xảy ra:

   1. stopRecognition() đã được gọi trên mô hình này.
   2. Đã phát hiện được hành vi.
   3. Quá trình phát hiện bị huỷ do các hạn chế về tài nguyên, ví dụ: khi một trường hợp sử dụng có mức độ ưu tiên cao hơn đã được bắt đầu.

   Trong hai trường hợp sau, sự kiện nhận dạng được gửi qua giao diện gọi lại do ứng dụng HAL đăng ký khi tải. Trong mọi trường hợp, sau khi bất kỳ sự kiện nào trong số này xảy ra, tính năng phát hiện sẽ không hoạt động và không cho phép lệnh gọi lại nhận dạng nữa.

   Bạn có thể khởi động lại cùng một mô hình vào lúc khác và lặp lại quá trình này bao nhiêu lần tuỳ ý.

3. Cuối cùng, ứng dụng HAL sẽ huỷ tải một mô hình không hoạt động không còn cần thiết thông qua unloadModel().

Lưu ý: Khi một mô hình được khởi động, ứng dụng HAL có thể gọi forceRecognitionEvent() để tạo sự kiện nhận dạng bắt buộc. Sự kiện được trả về tương tự như sự kiện nhận dạng thông thường, nhưng trường trạng thái được đặt thành FORCED. Các sự kiện nhận dạng như vậy không tự động dừng quá trình nhận dạng. Thay vào đó, trạng thái mô hình vẫn chạy ngay cả sau khi sự kiện được phân phối.

Xử lý lỗi HAL

Để đảm bảo hành vi đáng tin cậy và nhất quán giữa các hoạt động triển khai trình điều khiển, trong Android 11, mọi mã lỗi không thành công được trả về từ HAL đều được coi là lỗi lập trình, việc khôi phục từ đó yêu cầu khởi động lại quy trình HAL. Đây là chiến lược khôi phục cuối cùng và dự kiến các trường hợp như vậy sẽ không xảy ra trong một hệ thống hoạt động đúng cách.

Lưu ý: Mặc dù các lỗi này được gọi là hợp lệ trong tài liệu API HAL, nhưng vẫn có sự mơ hồ về thời điểm và trạng thái trả về các mã lỗi này cũng như quy trình khôi phục lỗi dự kiến. Do đó, Android 11 yêu cầu tuân thủ nghiêm ngặt hơn việc triển khai HAL của Trình kích hoạt âm thanh trong thời gian chạy so với các phiên bản Android thấp hơn.