2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main 대신 android-latest-release를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
보고 모드
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
센서는 보고 모드라 불리는 다양한 방식으로 이벤트를 생성할 수 있으며 각 센서 유형에는 단 하나의 보고 모드만 연결됩니다.
4가지의 보고 모드가 존재합니다.
연속
이벤트가 batch 함수에 전달된 sampling_period_ns 매개변수에 의해 정의된 일정한 속도로 생성됩니다. 연속 보고 모드를 사용하는 센서의 예로는 가속도계와 자이로스코프가 있습니다.
변경 시
측정된 값이 변경된 경우에만 이벤트가 생성됩니다.
HAL 수준에서 activate(..., enable=1)을 호출하여 센서를 활성화해도 이벤트가 트리거됩니다. 즉, 변경 시 센서가 활성화되면 HAL이 즉시 이벤트를 반환해야 합니다. 변경 시 보고 모드를 사용하는 센서의 예로는 걸음 수, 근접, 심박수 센서 유형이 있습니다.
batch 함수로 전달된 sampling_period_ns 매개변수는 연속 이벤트 간에 소요되는 최소 시간을 설정하는 데 사용됩니다. 즉, 마지막 이벤트 이후로 sampling_period_ns나노초가 경과될 때까지 이벤트가 생성되면 안 됩니다. 이는 해당 시점 이후에 값이 변경된 경우도 마찬가지입니다. 값이 변경된 경우에는 마지막 이벤트 이후로 sampling_period_ns가 경과되는 즉시 이벤트가 생성되어야 합니다.
예를 들어 다음과 같이 가정해 보세요.
sampling_period_ns = 10 * 10^9(10초)로 걸음 수를 활성화합니다.- 55초 동안 걷다가 1분 동안 가만히 서 있습니다.
- 최초 1분(센서 활성화에 따른 시간
t=0 및 t=60초 포함) 동안 10초마다 이벤트가 생성됩니다(총 7개의 이벤트). 걸음 수의 값이 t=60초 후에 변경되지 않았으므로 2분에는 이벤트가 생성되지 않습니다.
원샷
이벤트가 감지되면 센서는 자체적으로 비활성화된 다음 HAL을 통해 단일 이벤트를 전송합니다. 경합 상태를 피하려면 순서가 중요합니다.
센서는 이벤트가 HAL을 통해 보고되기 전에 비활성화되어야 합니다. 센서가 재활성화될 때까지 다른 이벤트가 전송되지 않습니다.
중요한 모션은 이러한 센서 유형의 한 예입니다.
원샷 센서는 트리거 센서라고도 부릅니다.
batch 함수에 전달된 sampling_period_ns 및 max_report_latency_ns 매개변수는 무시됩니다. 원샷 이벤트의 이벤트는 하드웨어 FIFO에 저장할 수 없습니다. 이벤트는 생성되는 즉시 보고해야 합니다.
특수
이벤트 생성 시기에 관한 자세한 내용은 개별 센서 유형 설명을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-27(UTC)"],[],[],null,["# Reporting modes\n\nSensors can generate events in different ways called reporting modes;\neach sensor type has one and only one reporting mode associated with it.\nFour reporting modes exist.\n\nContinuous\n----------\n\nEvents are generated at a constant rate defined by the\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function. Example sensors\nusing the continuous reporting mode are\n[accelerometers](/docs/core/interaction/sensors/sensor-types#accelerometer)\nand [gyroscopes](/docs/core/interaction/sensors/sensor-types#gyroscope).\n\nOn-change\n---------\n\nEvents are generated only if the measured values have changed.\nActivating the sensor at the HAL level (calling\n`activate(..., enable=1)` on it) also triggers an event,\nmeaning the HAL must return an event immediately when an on-change sensor\nis activated. Example sensors using the on-change reporting mode are the\nstep counter, proximity, and heart rate sensor types.\n\nThe\n[sampling_period_ns](/docs/core/interaction/sensors/batching#sampling_period_ns)\nparameter passed to the `batch` function is used to set the\nminimum time between consecutive events, meaning an event shouldn't be\ngenerated until `sampling_period_ns` nanoseconds elapsed since\nthe last event, even if the value changed since then. If the value changed,\nan event must be generated as soon as `sampling_period_ns` has\nelapsed since the last event.\n\nFor example, suppose:\n\n- We activate the step counter with `sampling_period_ns = 10 * 10^9` (10 seconds).\n- We walk for 55 seconds, then stand still for one minute.\n- The events are generated about every 10 seconds during the first minute (including at time `t=0` because of the activation of the sensor, and `t=60` seconds), for a total of seven events. No event is generated in the second minute because the value of the step count didn't change after `t=60` seconds.\n\nOne-shot\n--------\n\nUpon detection of an event, the sensor deactivates itself and then sends\na single event through the HAL. Order matters to avoid race conditions.\n(The sensor must be deactivated before the event is reported through the\nHAL). No other event is sent until the sensor is reactivated.\n[Significant\nmotion](/docs/core/interaction/sensors/sensor-types#significant_motion) is an example of this kind of sensor.\n\nOne-shot sensors are sometimes referred to as trigger sensors.\n\nThe `sampling_period_ns` and `max_report_latency_ns`\nparameters passed to the `batch` function are ignored. Events\nfrom one-shot events cannot be stored in hardware FIFOs; the events must\nbe reported as soon as they are generated.\n\nSpecial\n-------\n\nSee the individual [sensor type\ndescriptions](/docs/core/interaction/sensors/sensor-types) for details on when the events are generated."]]
