Hình dưới đây minh hoạ 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ó mặt. Luồng điều khiển từ các ứng dụng xuống các cảm biến và luồng dữ liệu từ các 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 Sensors SDK (Bộ phát triển phần mềm). SDK này chứa các hàm liệt kê các cảm biến hiện có 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 các sự kiện ở tần số 100 Hz 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ác sự kiện từ gia tốc kế với tốc độ ít nhất 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.
Framework
Khung này chịu trách nhiệm liên kết một số ứng dụng với HAL. HAL là một ứng dụng duy nhất. Nếu không có hoạt động ghép kênh này ở 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 cảm biến, khung sẽ gửi yêu cầu đến HAL để kích hoạt cảm biến.
- Khi các ứng dụng khác đăng ký cùng một cảm biến, khung 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, tức là một số ứng dụng sẽ nhận được cá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ả cá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 Xử lý theo lô để biết thêm thông tin.
- 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 yêu cầu đến HAL để huỷ kích hoạt 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ề một lớp ghép kênh trong khung 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, thì ứng dụng đầu tiên cũng sẽ nhận được các yêu cầu đó với tốc độ nhanh.
- Cũng không có gì đảm bảo về độ 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ễ thấp hơn nhiều so với độ trễ mà chúng 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à "công suất 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ế độ có độ chính xác cao và một ứng dụng khác yêu cầu chế độ tiêu thụ ít điện năng; khung sẽ không thể đáp ứng cả hai ứng dụng. Khung này phải luôn đáp ứng được mọi máy khách của mình, 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 rằng một ứng dụng không thể sửa đổi hành vi của các cảm biến, làm hỏng các ứng dụng khác.
Kết hợp cảm biến
Khung Android cung cấp một phương thức triển khai mặc định cho một số cảm biến kết hợp. Khi một con quay hồi chuyển, một gia tốc kế và một từ kế có trên thiết bị, nhưng không có cảm biến vectơ xoay, trọng lực và gia tốc tuyến tính, 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.
Quá trình 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 quá trình triển khai khác có quyền truy cập và quá trình này phải chạy trên SoC, do đó, quá trình này không chính xác cũng như không tiết kiệm điện năng như các quá trình triển khai khác. Trong phạm vi có thể, các nhà sản xuất thiết bị nên xác định các 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 kết hợp mới hơn như vectơ xoay trò chơi) thay vì dựa vào chế độ 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ọ một quy trình 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 của 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 của 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 gốc
Khung gốc được xác định trong frameworks/native/ và cung cấp một phiên bản gốc tương đương với gói android.hardware. Khung gốc gọi các proxy IPC của Binder để có quyền truy cập vào các dịch vụ dành riêng cho cảm biến.
IPC của Binder
Các proxy IPC của Binder tạo điều kiện giao tiếp qua ranh giới quy trình.
HAL
API Lớp trừu tượng phần cứng (HAL) của cảm biến là giao diện giữa trình điều khiển phần cứng và khung Android. Nó bao gồm một giao diện HAL 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 Android và những người đóng góp cho AOSP xác định, còn việc triển khai là 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 chi tiết.
Chu kỳ phát hành
Việc triển khai HAL chỉ định phiên bản 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 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ả các thiết bị đều phải nâng cấp. Để biết thông tin chi tiết về cách nâng cấp lên 1.3, hãy xem phần Ngừng sử dụng phiên bản HAL.
Trình điều khiển kernel
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, đơn vị 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 quy trình triển khai HAL.
Trong mọi trường hợp, việc triển khai HAL và trình điều khiển nhân là trách nhiệm của các nhà sản xuất phần cứng, đồng thời Android không cung cấp các phương pháp ưu tiên để ghi chúng.
Trung tâm cảm biến
Bạn có thể tuỳ ý thêm một trung tâm cảm biến vào ngăn xếp cảm biến của thiết bị. Trung tâm này hữu ích khi thực hiện một số phép tính cấp thấp ở mức tiêu thụ điện năng thấp trong khi SoC có thể ở chế độ tạm ngưng. Ví dụ: bạn có thể thực hiện việc đếm bước hoặc kết hợp cảm biến trên các chip đó. Đây cũng là nơi phù hợp để triển khai tính năng nhóm 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 Xử lý theo lô để biết thêm thông tin.
Lưu ý: Để phát triển các tính năng mới của ContextHub 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.
Cách hiện thực hoá trung tâm cảm biến phụ thuộc vào cấu trúc. Đôi khi, đây là một chip riêng biệt và đôi khi được đưa vào cùng một chip với SoC. Đặc điểm quan trọng của trung tâm cảm biến là phải có đủ bộ nhớ để xử lý hàng loạt và tiêu thụ rất ít điện năng để cho phép triển khai các cảm biến Android có mức tiêu thụ điện năng thấp. Một số trung tâm cảm biến chứa một vi điều khiển để tính toán chung và các bộ tăng tốc phần cứng để cho phép tính toán tiêu thụ rất ít năng lượng cho các cảm biến tiêu thụ ít năng lượng.
Android không chỉ định cách trung tâm cảm biến được thiết kế và cách trung tâm này giao tiếp với các cảm biến và SoC (bus I2C, bus SPI,...) nhưng mục tiêu là giảm thiểu mức tiêu thụ điện tổng thể.
Một lựa chọn có vẻ ảnh hưởng đáng kể đến tính đơn giản của việc triển khai là có 2 đường truyền tín hiệu ngắt từ trung tâm cảm biến đến SoC: một đường truyền cho tín hiệu ngắt đánh thức (cho cảm biến đánh thức) và đường truyền còn lại cho tín hiệu ngắt không đánh thức (cho 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 việc đo lường. Trong nhiều trường hợp, một số cảm biến thực tế có trên cùng một chip. Ví dụ: một số chip có gia tốc kế, con quay hồi chuyển và từ kế. (Những 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 trên 3 trục.)
Một số chip trong số đó cũng chứa một số logic để thực hiện các phép tính thông thường, chẳng hạn như phát hiện chuyển động, phát hiện bước và kết hợp 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 của CDD nhắm đến 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 đó ảnh hưởng đến 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ơ xoay của trò chơi có ảnh hưởng đến độ chính xác cần thiết cho con quay hồi chuyển vật lý. Nhà sản xuất thiết bị có trách nhiệm đưa ra các yêu cầu đối với cảm biến thực.