아래 그림은 Android 센서 스택을 나타냅니다. 각 구성요소는 바로 위와 아래의 구성요소와 통신하는 데 그치지만 일부 센서는(존재하는 경우) 센서 허브를 우회할 수 있습니다. 제어는 애플리케이션에서 센서까지 아래로 흐르고 센서에서 애플리케이션까지 위로 흐릅니다.
그림 1. Android 센서 스택 계층 및 각각의 소유자
SDK
애플리케이션은 Sensors SDK(Software Development Kit) API를 통해 센서에 액세스합니다. SDK에는 가용한 센서를 나열하고 센서에 등록하기 위한 함수가 포함되어 있습니다.
센서에 등록할 때 애플리케이션은 선호하는 샘플링 주파수와 지연 시간 요구사항을 지정합니다.
- 예를 들어 애플리케이션은 100Hz에서 이벤트를 요청하는 기본 가속도계에 등록할 수 있으며, 이벤트가 1초 지연 시간으로 보고되도록 허용할 수 있습니다.
- 애플리케이션은 가속도계에서 최소 100Hz의 속도로 이벤트를 수신하며, 최대 1초까지 지연될 수 있습니다.
SDK에 관한 자세한 내용은 개발자 문서를 참고하세요.
프레임워크
프레임워크는 여러 애플리케이션을 HAL에 연결하는 역할을 합니다. HAL 자체는 단일 클라이언트입니다. 이러한 다중화가 프레임워크 수준에서 발생하지 않으면 한 번에 하나의 애플리케이션만 각 센서에 액세스할 수 있습니다.
- 첫 번째 애플리케이션이 센서에 등록되면 프레임워크는 HAL에 요청을 전송하여 센서를 활성화합니다.
- 추가 애플리케이션이 같은 센서에 등록되면 프레임워크는 각 애플리케이션의 요구사항을 고려하여 업데이트 요청된 매개변수를 HAL로 전송합니다.
- 샘플링 주파수는 요청된 샘플링 추파수의 최댓값입니다. 즉, 일부 애플리케이션이 요청한 것보다 훨씬 높은 주파수에서 이벤트를 수신하게 됩니다.
- 최대 보고 지연 시간은 요청된 항목의 최솟값입니다. 1개의 애플리케이션이 최대 보고 지연 시간이 0인 1개의 센서를 요청하면 요청된 일부 센서의 최대 보고 지연 시간이 0이 아닌 경우에도 모든 애플리케이션이 연속 모드에서 이 센서의 이벤트를 수신하게 됩니다. 자세한 내용은 일괄 처리를 참고하세요.
- 1개의 센서에 등록된 마지막 애플리케이션이 센서에서 등록 취소되면 프레임워크는 HAL에 요청을 전송하여 전력이 불필요하게 소모되지 않도록 센서를 비활성화합니다.
다중화의 영향
프레임워크의 다중화 계층에 관한 이러한 요구는 몇 가지 설계적 결정을 설명합니다.
- 애플리케이션이 특정한 샘플링 주파수를 요청하면 이벤트가 더 빠른 속도로 도착하리란 보장이 없습니다. 또 다른 애플리케이션이 더 빠른 속도에서 같은 센서를 요청한 경우 첫 번째 애플리케이션도 더 빠른 속도에서 이를 수신합니다.
- 동일한 보장성의 결여가 요청된 최대 보고 지연 시간에도 적용됩니다. 애플리케이션은 요청된 지연 시간보다 훨씬 적은 지연 시간으로 이벤트를 수신할 수 있습니다.
- 샘플링 주파수 및 최대 보고 지연 시간 외에, 애플리케이션은 센서 매개변수를 구성할 수 없습니다.
- 예를 들어 '높은 정확도' 및 '저전력' 모드에서 작동할 수 있는 실제 센서가 있다고 가정해 보세요.
- 두 모드 중에서 하나만 Android 기기에 사용할 수 있습니다. 그렇지 않으면 한 애플리케이션은 높은 정확도 모드를 요청하고 나머지 하나는 저전력 모드를 요청할 수 있기 때문입니다. 프레임워크가 두 애플리케이션을 모두 만족시킬 수 있는 방법은 없습니다. 프레임워크는 항상 모든 클라이언트를 만족시킬 수 있어야 하므로 이는 고려할 만한 옵션이 아닙니다.
- 애플리케이션에서 센서 또는 드라이버로 데이터를 하향 전송할 수 있는 메커니즘은 없습니다. 이렇게 하면 한 개의 애플리케이션이 센서 동작을 수정할 수 없으므로 다른 애플리케이션이 중지됩니다.
센서 융합
Android 프레임워크는 일부 복합 센서를 위한 기본 구현을 제공합니다. 기기에 자이로스코프, 가속도계, 자기계는 있지만 회전 벡터, 중력, 선형 가속 센서는 없는 경우, 프레임워크는 애플리케이션이 계속해서 사용할 수 있도록 이러한 센서를 구현합니다.
기본 구현은 다른 구현으로 액세스 가능한 모든 데이터의 일부에만 액세스할 수 있으며, SoC에서 실행되어야 합니다. 따라서 다른 구현만큼 정확하거나 전력 효율적이지는 않습니다. 기기 제조업체는 이러한 기본 구현에 의존하기보다는 최대한 자체 융합된 센서(회전 벡터, 중력, 선형 가속뿐 아니라 게임 회전 벡터와 같은 새로운 복합 센서)를 정의해야 합니다. 또한 기기 제조업체는 구현을 제공하도록 센서 칩 공급업체에 요청할 수도 있습니다.
기본 센서 융합 구현은 유지되지 않고 있으며, 이러한 구현에 의존하는 기기가 CTS에 불합격하는 결과로 이어질 수 있습니다.
고급설정
이 섹션은 Android 오픈소스 프로젝트(AOSP) 프레임워크 코드를 유지 중인 사용자를 위한 배경 정보로 기능하며, 하드웨어 제조업체와는 관련이 없습니다.
JNI
프레임워크는 android.hardware에 연결된 자바 네이티브 인터페이스(JNI)를 사용하며 이 인터페이스는 frameworks/base/core/jni/ 디렉터리에 있습니다. 이 코드는 하위 수준의 네이티브 코드를 호출하여 센서 하드웨어 액세스 권한을 획득합니다.
네이티브 프레임워크
네이티브 프레임워크는 frameworks/native/에 정의되어 있으며 android.hardware 패키지와 동등한 네이티브를 제공합니다. 네이티브 프레임워크는 바인더 IPC 프록시를 호출하여 센서별 서비스에 액세스합니다.
바인더 IPC
바인더 IPC 프록시는 프로세스 경계를 통한 통신을 용이하게 합니다.
HAL
Sensors Hardware Abstraction Layer (HAL) API는 하드웨어 드라이버와 Android 프레임워크 사이의 인터페이스이며, HAL 인터페이스 sensors.h, 그리고 Google에서 sensors.cpp라고 부르는 한 개의 HAL 구현으로 구성됩니다.
인터페이스는 Android 및 AOSP 기여자에 의해 정의되며, 구현은 기기 제조업체에서 제공합니다.
센서 HAL 인터페이스는 hardware/libhardware/include/hardware에 있습니다.
자세한 내용은 sensors.h를 참고하세요.
출시 주기
HAL 구현은 your_poll_device.common.version을 설정하여 어떤 HAL 인터페이스 버전을 구현할지 지정합니다. 기존 HAL 인터페이스 버전은 sensors.h에서 정의되며, 기능이 이러한 버전에 연결됩니다.
Android 프레임워크는 현재 버전 1.0 및 1.3을 지원하지만 1.0은 조만간 더 이상 지원되지 않을 예정입니다. 이 문서는 모든 기기가 업그레이드되어야 하는 버전 1.3의 동작을 설명합니다. 1.3으로 업그레이드하는 방법은 HAL 버전 지원 중단을 참고하세요.
커널 드라이버
센서 드라이버는 실제 기기와 상호작용합니다. 경우에 따라서는 HAL 구현과 드라이버가 같은 소프트웨어 개체일 때도 있는가 하면 하드웨어 통합자가 센서 칩 제조업체에 드라이버를 제공해 달라고 요청하지만 정작 HAL 구현을 작성하는 주체는 자신인 경우도 있습니다.
어떠한 경우든 HAL 구현 및 커널 드라이버는 하드웨어 제조업체의 책임이며, Android는 HAL 작성을 위한 선호되는 접근 방식을 제공하지 않습니다.
센서 허브
기기의 센서 스택은 SoC가 정지 모드로 전환 가능한 동안에 저전력으로 낮은 수준의 계산을 실행하는 데 유용한 센서 허브를 선택적으로 포함할 수 있습니다. 예를 들어 걸음 수 계산 또는 센서 융합은 이러한 칩에서 실행할 수 있습니다. 또한 센서 일괄 처리를 구현하여 센서 이벤트에 하드웨어 FIFO를 추가하기에도 좋은 위치입니다. 자세한 내용은 일괄 처리를 참고하세요.
참고: 새로운 센서나 LED를 사용하는 새로운 ContextHub 기능을 개발하려는 경우에도 Hikey 또는 Hikey960 개발 보드에 연결된 Neonkey SensorHub를 사용할 수 있습니다.
센서 허브가 구체화되는 방식은 아키텍처에 따라 다르며, 경우에 따라 별도의 칩이거나 SoC와 같은 칩에 포함될 수도 있습니다. 센서 허브의 중요한 특성은 일괄 처리를 위한 충분한 메모리를 포함해야 하고 저전력 Android 센서의 구현 지원을 위해 매우 소량의 전력을 소모해야 한다는 것입니다. 일부 센서 허브에는 일반 계산을 위한 마이크로 컨트롤러, 그리고 저전력 센서와 관련된 극저전력 계산 지원을 위한 하드웨어 가속기가 포함됩니다.
센서 허브가 아키텍처화되고 센서 및 SoC(I2C 버스, SPI 버스 등)와 통신하는 방식은 Android에서 명시하지 않지만 전체 전력 사용을 최소화하는 데 목표를 두어야 합니다.
구현 단순성에 상당한 영향을 미치는 것으로 보이는 한 가지 방법은 센서 허브에서 SoC로 이어지는 두 개의 인터럽트 회선을 보유하는 것입니다. 여기서 한 회선은 wake-up 센서를 위한 wake-up 인터럽트에 사용되고 나머지 하나는 non-wake-up 센서를 위한 non-wake-up 인터럽트에 사용됩니다.
센서
측정을 수행하는 실제 MEM 칩입니다. 다수의 경우 같은 칩에 여러 개의 실제 센서가 존재합니다. 예를 들어 일부 칩에는 가속도계, 자이로스코프와 자기계가 포함됩니다. 이러한 칩은 9축 칩으로 불릴 때가 많으며 이는 각 센서가 3축에 걸쳐 데이터를 제공하기 때문입니다.
이러한 칩 중 일부에는 모션 감지, 걸음 수 감지 및 9축 센서 융합과 같은 일반적인 계산을 실행하기 위한 어느 정도의 논리도 포함됩니다.
CDD 전력 및 정확도 요구사항 및 권장사항은 실제 센서가 아닌 Android 센서를 대상으로 하지만, 이러한 요구사항이 실제 센서의 선택에 영향을 미칠 수 있습니다. 예를 들어 게임 회전 벡터의 정확도 요구사항은 실제 자이로스코프에 필요한 정확도에 영향을 미칩니다. 실제 센서의 요구사항을 가져올지는 기기 제조업체가 결정합니다.