Ngăn xếp cảm biến

Hình bên dưới đại diện cho ngăn xếp cảm biến Android. Mỗi thành phần chỉ giao tiếp với các thành phần trực tiếp bên trên và bên dưới nó, mặc dù một số cảm biến có thể bỏ qua trung tâm cảm biến khi nó có mặt. Luồng kiểm soát từ các ứng dụng xuống các cảm biến và dữ liệu chuyển từ các cảm biến đến các ứng dụng.

Các lớp và chủ sở hữu của ngăn xếp cảm biến Android

Hình 1. Các lớp của ngăn xếp cảm biến Android và chủ sở hữu tương ứng của chúng

SDK

Các ứng dụng truy cập cảm biến thông qua API cảm biến SDK (Bộ phát triển phần mềm) . SDK chứa các chức năng để liệt kê các cảm biến có sẵn và đăng ký với một cảm biến.

Khi đăng ký với một cảm biến, ứng dụng chỉ định tần số lấy mẫu ưa thích và các yêu cầu về độ trễ của nó.

  • Ví dụ: một ứng dụng có thể đăng ký với gia tốc kế mặc định, yêu cầu các sự kiện ở tần số 100Hz và cho phép các sự kiện được báo cáo với độ trễ 1 giây.
  • Ứng dụng sẽ nhận các sự kiện từ gia tốc kế với tốc độ ít nhất là 100Hz và có thể bị trễ đến 1 giây.

Xem tài liệu dành cho nhà phát triển để biết thêm thông tin về SDK.

Khuôn khổ

Khung phụ trách liên kết một số ứng dụng với HAL . Bản thân HAL là một khách hàng duy nhất. Nếu không có sự ghép kênh này xảy ra ở cấp khung, chỉ một ứng dụng duy nhất có thể truy cập vào từng cảm biến tại bất kỳ thời điểm nào.

  • Khi một ứng dụng đầu tiên đăng ký với một bộ cảm biến, khuôn khổ sẽ gửi một yêu cầu đến HAL để kích hoạt bộ cảm biến.
  • Khi các ứng dụng bổ sung đăng ký vào cùng một cảm biến, khuôn khổ sẽ tính đến các yêu cầu từ mỗi ứng dụng và gửi các thông số được yêu cầu cập nhật đến HAL.
    • Tần số lấy mẫu sẽ là tần số lấy mẫu tối đa được yêu cầu, có nghĩa là một số ứng dụng sẽ nhận được các sự kiện ở tần số cao hơn tần số mà họ yêu cầu.
    • Độ trễ báo cáo tối đa sẽ là độ trễ báo cáo tối thiểu được yêu cầu. Nếu một ứng dụng yêu cầu một cảm biến có độ trễ báo cáo tối đa là 0, thì tất cả các ứng dụng sẽ nhận các sự kiện từ cảm biến này ở chế độ liên tục ngay cả khi một số ứng dụng yêu cầu cảm biến có độ trễ báo cáo tối đa khác 0. Xem Batch để biết thêm chi tiết.
  • Khi ứng dụng cuối cùng được đăng ký với một cảm biến hủy đăng ký khỏi ứng dụng đó, các khuôn khổ sẽ gửi yêu cầu đến HAL để hủy kích hoạt cảm biến để điện năng không bị tiêu thụ một cách không cần thiết.

Tác động của ghép kênh

Điều này cần cho một lớp ghép kênh trong khuôn khổ giải thích một số quyết định thiết kế.

  • Khi một ứng dụng yêu cầu tần suất lấy mẫu cụ thể, không có gì đảm bảo rằng các sự kiện sẽ không đến với tốc độ nhanh hơn. Nếu một ứng dụng khác yêu cầu cùng một cảm biến với tốc độ nhanh hơn, ứng dụng đầu tiên cũng sẽ nhận chúng với tốc độ nhanh.
  • Sự thiếu đảm bảo tương tự cũng áp dụng cho độ trễ báo cáo tối đa được yêu cầu: các ứng dụng có thể nhận được các sự kiện với độ trễ ít hơn nhiều so với yêu cầu.
  • Bên cạnh tần suất lấy mẫu và độ trễ báo cáo tối đa, các ứng dụng không thể cấu hình các thông số cảm biến.
    • Ví dụ: hãy tưởng tượng một cảm biến vật lý có thể hoạt động ở cả chế độ “độ chính xác cao” và “công suất thấp”.
    • Chỉ một trong hai chế độ đó có thể được sử dụng trên thiết bị Android, vì nếu không, một ứng dụng có thể yêu cầu chế độ chính xác cao và một ứng dụng khác là chế độ năng lượng thấp; sẽ không có cách nào để khuôn khổ đáp ứng cả hai ứng dụng. Khung công tác phải luôn có thể đáp ứng tất cả các khách hàng của nó, vì vậy đây không phải là một lựa chọn.
  • Không có cơ chế nào để gửi dữ liệu từ các ứng dụng xuống các cảm biến hoặc trình điều khiển của chúng. Điều này đảm bảo một ứng dụng không thể sửa đổi hành vi của các cảm biến, phá vỡ các ứng dụng khác.

Cảm biến nhiệt hạch

Khung công tác Android cung cấp triển khai mặc định cho một số cảm biến tổng hợp. Khi con quay hồi chuyển , gia tốc kếtừ kế có mặt trên một thiết bị nhưng không có véc tơ quay , trọng lực và cảm biến gia tốc tuyến tính , thì khung sẽ triển khai các cảm biến đó để các ứng dụng vẫn có thể sử dụng chúng.

Triển khai mặc định không có quyền truy cập vào tất cả dữ liệu mà các triển khai khác có quyền truy cập và nó phải chạy trên SoC, do đó, nó không chính xác cũng như không hiệu quả về điện năng như các triển khai khác. Càng nhiều càng tốt, các nhà sản xuất thiết bị nên xác định các cảm biến hợp nhất của riêng họ (vectơ quay, trọng lực và gia tốc tuyến tính, cũng như các cảm biến tổng hợp mới hơn như vectơ quay trò chơi ) thay vì dựa vào triển khai mặc định này. Các nhà sản xuất thiết bị cũng có thể yêu cầu các nhà cung cấp chip cảm biến cung cấp cho họ một bản triển khai.

Việc triển khai hợp nhất cảm biến mặc định không được duy trì và có thể khiến các thiết bị dựa vào nó bị lỗi CTS.

Dưới mui xe

Phần này được cung cấp làm thông tin cơ bản cho những người duy trì mã khung Dự án nguồn mở Android (AOSP). Nó không liên quan đến các nhà sản xuất phần cứng.

JNI

Khung sử dụng Giao diện gốc Java (JNI) được liên kết với android.hardware và nằm trong thư mục frameworks/base/core/jni/ . Mã này gọi mã gốc cấp thấp hơn để có quyền truy cập vào phần cứng cảm biến.

Khung bản địa

Khuôn khổ gốc được định nghĩa trong frameworks/native/ và cung cấp một bản gốc tương đương với gói android.hardware . Khuôn khổ gốc gọi các proxy IPC Binder để có quyền truy cập vào các dịch vụ dành riêng cho cảm biến.

Binder IPC

Các proxy IPC của Binder tạo điều kiện giao tiếp qua các ranh giới quy trình.

HAL

API lớp trừu tượng phần cứng cảm biến (HAL) là giao diện giữa trình điều khiển phần cứng và khuôn khổ Android. Nó bao gồm một cảm biến giao diện HAL.h và một triển khai HAL mà chúng tôi gọi là cảm biến.cpp.

Giao diện được xác định bởi những người đóng góp cho Android và AOSP và việc triển khai do nhà sản xuất thiết bị cung cấp.

Giao diện HAL cảm biến nằm trong hardware/libhardware/include/hardware . Xem sensor.h để biết thêm chi tiết.

Chu kỳ phát hành

Việc triển khai HAL chỉ định phiên bản của giao diện HAL mà nó triển khai bằng cách đặt your_poll_device.common.version . Các phiên bản giao diện HAL hiện có được định nghĩa trong sensor.h và chức năng được gắn với các phiên bản đó.

Khung Android hiện hỗ trợ phiên bản 1.0 và 1.3, nhưng phiên bản 1.0 sẽ sớm không được hỗ trợ nữa. Tài liệu này mô tả hoạt động của phiên bản 1.3, mà tất cả các thiết bị nên nâng cấp lên. Để biết chi tiết về cách nâng cấp lên 1.3, hãy xem phiên bản HAL không dùng nữa .

Trình điều khiển nhân

Các trình điều khiển cảm biến tương tác với các thiết bị vật lý. Trong một số trường hợp, việc triển khai HAL và trình điều khiển là cùng một thực thể phần mềm. Trong các trường hợp khác, nhà tích hợp phần cứng yêu cầu các nhà sản xuất chip cảm biến cung cấp trình điều khiển, nhưng họ lại là những người viết ra việc triển khai HAL.

Trong mọi trường hợp, việc triển khai HAL và trình điều khiển hạt nhân là trách nhiệm của các nhà sản xuất phần cứng và Android không cung cấp các phương pháp ưu tiên để viết chúng.

Trung tâm cảm biến

Ngăn xếp cảm biến của một thiết bị có thể tùy chọn bao gồm một trung tâm cảm biến, hữu ích để thực hiện một số tính toán mức thấp ở mức công suất thấp trong khi SoC có thể ở chế độ tạm ngừng. Ví dụ, đếm bước hoặc hợp nhất cảm biến có thể được thực hiện trên các chip đó. Nó cũng là một nơi tốt để thực hiện phân phối cảm biến, thêm FIFO phần cứng cho các sự kiện cảm biến. Xem Batch để biết thêm thông tin.

Lưu ý: Để phát triển các tính năng ContextHub mới sử dụng cảm biến hoặc đèn LED mới, bạn cũng có thể sử dụng Neonkey SensorHub được kết nối với bảng phát triển Hikey hoặc Hikey960.

Làm thế nào trung tâm cảm biến được thực hiện tùy thuộc vào kiến ​​trúc. Nó đôi khi là một chip riêng biệt và đôi khi được bao gồm trên cùng một chip với SoC. Đặc điểm quan trọng của trung tâm cảm biến là nó phải chứa đủ bộ nhớ để phân chia và tiêu thụ rất ít năng lượng để có thể triển khai các cảm biến Android công suất thấp. Một số trung tâm cảm biến có chứa bộ vi điều khiển để tính toán chung và bộ tăng tốc phần cứng để cho phép tính toán công suất rất thấp cho các cảm biến công suất thấp.

Cách cấu trúc của trung tâm cảm biến và cách nó giao tiếp với các cảm biến và SoC (bus I2C, bus SPI,…) không được Android chỉ định, nhưng nó phải nhằm mục đích giảm thiểu việc sử dụng điện năng tổng thể.

Một tùy chọn dường như có tác động đáng kể đến sự đơn giản khi triển khai là có hai đường ngắt đi từ trung tâm cảm biến đến SoC: một đường dành cho ngắt đánh thức (dành cho cảm biến đánh thức) và đường còn lại dành cho ngắt không đánh thức (đối với cảm biến không đánh thức).

Cảm biến

Đó là các chip MEMs vật lý thực hiện các phép đo. Trong nhiều trường hợp, một số cảm biến vật lý có mặt trên cùng một con chip. Ví dụ, một số chip bao gồm một gia tốc kế, một con quay hồi chuyển và một từ kế. (Các chip như vậy thường được gọi là chip 9 trục, vì mỗi cảm biến cung cấp dữ liệu qua 3 trục.)

Một số chip đó cũng chứa một số logic để thực hiện các phép tính thông thường như phát hiện chuyển động, phát hiện bước và hợp nhất cảm biến 9 trục.

Mặc dù các yêu cầu và khuyến nghị về công suất và độ chính xác của CDD nhắm mục tiêu vào cảm biến Android chứ không phải cảm biến vật lý, nhưng những yêu cầu đó sẽ ảnh hưởng đến việc lựa chọn cảm biến vật lý. Ví dụ: yêu cầu về độ chính xác đối với vectơ quay trò chơi có liên quan đến độ chính xác cần thiết đối với con quay hồi chuyển vật lý. Tùy thuộc vào nhà sản xuất thiết bị để xác định các yêu cầu đối với cảm biến vật lý.