Hình dưới đây thể hiện 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 ngay phía trên và phía 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 có. Luồng điều khiển từ các ứng dụng xuống cảm biến và luồng dữ liệu từ cảm biến lên các ứng dụng.
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
SDK
Các ứng dụng truy cập vào cảm biến thông qua API SDK (Bộ phát triển phần mềm) của cảm biến. SDK này chứa các hàm để 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 sẽ chỉ định tần suất lấy mẫu ưu tiên và các yêu cầu về độ trễ.
- Ví dụ: một ứng dụng có thể đăng ký với gia tốc kế mặc định, yêu cầu sự kiện ở tần số 100 Hz và cho phép báo cáo sự kiện với độ trễ 1 giây.
- Ứng dụng sẽ nhận được các sự kiện từ gia tốc kế với tốc độ tối thiểu là 100 Hz và có thể bị trễ tối đa 1 giây.
Hãy xem tài liệu dành cho nhà phát triển để biết thêm thông tin về SDK này.
Khung
Khung này chịu trách nhiệm liên kết một số ứng dụng với HAL. Bản thân HAL là một ứng dụng khách. Nếu không có quá trình đaплекс hoá này diễn ra ở cấp khung, thì chỉ một ứng dụng duy nhất mới 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 ứng dụng đầu tiên đăng ký với một cảm biến, khung sẽ gửi một yêu cầu đến HAL để kích hoạt cảm biến.
- Khi các ứng dụng bổ sung đăng ký với cùng một cảm biến, khung này sẽ tính đến các yêu cầu của từng ứng dụng và gửi các thông số được yêu cầu đã cập nhật đến HAL.
- Tần suất lấy mẫu sẽ là tần suất lấy mẫu tối đa được yêu cầu, nghĩa là một số ứng dụng sẽ nhận được sự kiện ở tần suất cao hơn tần suất mà chúng yêu cầu.
- Độ trễ báo cáo tối đa sẽ là độ trễ tối thiểu trong số các độ trễ đượ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ả ứng dụng sẽ nhận được 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. Hãy xem phần Gói hàng để biết thêm thông tin chi tiết.
- Khi ứng dụng cuối cùng đã đăng ký với một cảm biến huỷ đăng ký khỏi cảm biến đó, khung sẽ gửi một yêu cầu đến HAL để vô hiệu hoá cảm biến để không tiêu thụ điện năng một cách không cần thiết.
Tác động của việc ghép kênh
Nhu cầu về lớp đa kênh trong khung này giải thích một số quyết định thiết kế.
- Khi một ứng dụng yêu cầu một 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 ở tốc độ nhanh hơn, thì ứng dụng đầu tiên cũng sẽ nhận được các cảm biến đó ở tốc độ nhanh.
- Tương tự như vậy, độ trễ báo cáo tối đa được yêu cầu cũng không được đảm bảo: ứng dụng có thể nhận được các sự kiện có độ trễ thấp hơn nhiều so với yêu cầu.
- Ngoài 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ể định cấu hình các tham 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à "mức tiêu thụ điện năng thấp".
- Bạn chỉ có thể sử dụng một trong hai chế độ đó 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 yêu cầu chế độ tiết kiệm pin; khung sẽ không thể đáp ứng cả hai ứng dụng. Khung phải luôn có thể đáp ứng tất cả các ứng dụng khách, 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ảm biến hoặc trình điều khiển của cảm biến. Điều này đảm bảo một ứng dụng không thể sửa đổi hành vi của cảm biến, làm hỏng các ứng dụng khác.
Tích hợp cảm biến
Khung Android cung cấp phương thức triển khai mặc định cho một số cảm biến tổng hợp. Khi một con quay hồi chuyển, một gia tốc kế và một máy đo từ trường có trên thiết bị, nhưng không có cảm biến vektor xoay, trọng lực và gia tốc tuyến tính, khung này sẽ triển khai các cảm biến đó để các ứng dụng vẫn có thể sử dụng.
Phương thức 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 phương thức triển khai khác có quyền truy cập và phương thức này phải chạy trên SoC, do đó, phương thức này không chính xác và không tiết kiệm điện năng như các phương thức triển khai khác. Nhà sản xuất thiết bị nên xác định cảm biến kết hợp của riêng họ (vectơ xoay, 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ơ xoay trò chơi) thay vì dựa vào phương thức triển khai mặc định này. Nhà sản xuất thiết bị cũng có thể yêu cầu nhà cung cấp chip cảm biến cung cấp cho họ cách triển khai.
Phương thứ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 phương thức này không vượt qua được CTS.
Tìm hiểu sâu
Phần này được cung cấp dưới dạng thông tin cơ bản cho những người duy trì mã khung Dự án nguồn mở Android (AOSP). Thông tin này không liên quan đến các nhà sản xuất phần cứng.
JNI
Khung này sử dụng Giao diện gốc Java (JNI) 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 gốc
Khung gốc được xác định trong frameworks/native/ và cung cấp một khung gốc tương đương với gói android.hardware. Khung gốc gọi proxy Binder IPC để có quyền truy cập vào các dịch vụ dành riêng cho cảm biến.
Binder IPC
Proxy IPC của Binder hỗ trợ 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à khung Android. Thư viện này bao gồm một giao diện HAL là sensors.h và một phương thức triển khai HAL mà chúng ta gọi là sensors.cpp.
Giao diện này do các cộng tác viên của Android và AOSP xác định, còn 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.
Hãy xem sensors.h để biết thêm thông tin.
Chu kỳ phát hành
Việc triển khai HAL chỉ định phiên bản giao diện HAL mà giao diện này 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 xác định trong sensors.h và chức năng được liên kết 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ả hành vi của phiên bản 1.3 mà tất cả thiết bị đều phải nâng cấp lên. Để biết thông tin chi tiết về cách nâng cấp lên phiên bản 1.3, hãy xem phần Ngừng sử dụng phiên bản HAL.
Trình điều khiển hạt nhân
Trình điều khiển cảm biến tương tác với các thiết bị thực. 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, trình tích hợp phần cứng yêu cầu nhà sản xuất chip cảm biến cung cấp trình điều khiển, nhưng họ là những người viết cách 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 nhà sản xuất phần cứng và Android không cung cấp phương pháp ưu tiên để viết các trình điều khiển này.
Trung tâm cảm biến
Ngăn xếp cảm biến của thiết bị có thể tuỳ ý bao gồm một trung tâm cảm biến, hữu ích để thực hiện một số phép tính cấp thấp ở mức năng lượng thấp trong khi SoC có thể ở chế độ tạm ngưng. Ví dụ: bạn có thể thực hiện tính năng đếm bước hoặc hợp nhất cảm biến trên các khối đó. Đây cũng là nơi thích hợp để triển khai tính năng xử lý hàng loạt cảm biến, thêm FIFO phần cứng cho các sự kiện cảm biến. Hãy xem phần Gộp nhóm để 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 kết nối với bảng phát triển Hikey hoặc Hikey960.
Cách triển khai trung tâm cảm biến phụ thuộc vào cấu trúc. Đôi khi, đây là một khối riêng biệt và đôi khi được đưa vào cùng một khối với SoC. Các đặc điểm quan trọng của cụm cảm biến là phải chứa đủ bộ nhớ để xử lý hàng loạt và tiêu thụ rất ít năng lượng để cho phép triển khai các cảm biến Android có công suất thấp. Một số trung tâm cảm biến chứa một bộ vi điều khiển để tính toán chung và trình tăng tốc phần cứng để cho phép tính toán ở mức năng lượng rất thấp cho các cảm biến tiêu thụ năng lượng thấp.
Android không chỉ định cách cấu trúc trung tâm cảm biến và cách trung tâm này giao tiếp với các cảm biến cũng như SoC (bus I2C, bus SPI, v.v.), nhưng trung tâm này phải nhằm mục đích giảm thiểu mức sử dụng năng lượng tổng thể.
Một lựa chọn có vẻ như có tác động đáng kể đến tính đơn giản của việc triển khai là có hai dòng ngắt từ trung tâm cảm biến đến SoC: một dòng cho các ngắt chế độ thức (dành cho cảm biến chế độ thức) và dòng còn lại cho các ngắt chế độ không thức (dành cho cảm biến chế độ không thức).
Cảm biến
Đó là các chip MEMs thực tế thực hiện việc đo lường. Trong nhiều trường hợp, có một số cảm biến vật lý trên cùng một khối. Ví dụ: một số khối có gia tốc kế, con quay hồi chuyển và máy đo từ trường. (Các khối như vậy thường được gọi là khối 9 trục, vì mỗi cảm biến cung cấp dữ liệu trên 3 trục.)
Một số trong số các khối đó 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à đề xuất về độ chính xác và công suất CDD nhắm đến cảm biến Android chứ không phải cảm biến thực, nhưng các yêu cầu đó ảnh hưởng đến lựa chọn cảm biến thực. Ví dụ: yêu cầu về độ chính xác của vectơ xoay trò chơi sẽ ảnh hưởng đến độ chính xác cần thiết của con quay hồi chuyển thực. Nhà sản xuất thiết bị có toàn quyền đưa ra các yêu cầu đối với cảm biến vật lý.