自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
传感器
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 传感器使应用可以访问移动设备的底层实体传感器。它们是负责提供数据的虚拟设备，由传感器硬件抽象层 (HAL) sensors.h 进行定义。
什么是 Android 传感器？
Android 传感器属于虚拟设备，可提供来自以下各种物理传感器的数据：加速度计、陀螺仪、磁力计、气压计、湿度传感器、压力传感器、光传感器、近程传感器和心率传感器。
提供数据的物理设备列表中不包括相机、指纹传感器、麦克风和触摸屏。这些设备有自己的报告机制；两类设备的区别并无绝对标准，但一般来说，Android 传感器提供较低带宽的数据。例如，加速度计为“100 hz x 3 个通道”、相机为“25 hz x 8 MP x 3 个通道”，而麦克风为“44 kHz x 1 个通道”。
Android 不定义不同物理传感器如何连接到系统芯片 (SoC)。
- 通常，传感器芯片通过传感器中枢连接到 SoC，这样可允许对数据进行一些低功耗的监控和处理。
- 通常，使用内部集成电路 (I2C) 或串行外设接口 (SPI) 作为传输机制。
- 为了降低功耗，一些架构具有层次性，在专用集成电路（简称 ASIC，如加速度计芯片上的移动侦测）中进行极少的处理，而在微控制器（如传感器中枢中的步数检测）中进行更多处理。
- 设备制造商会根据精确度、功率、价格和封装大小特性来选择架构。有关详情，请参阅传感器堆栈。
- 批处理功能是功率优化的重要考虑因素。有关详情，请参阅批处理。
每个 Android 传感器都有一个“类型”，表示传感器的行为及其提供的数据。
- 官方 Android 传感器类型在 sensors.h 中的 SENSOR_TYPE_ 名称下进行定义…
- 绝大多数传感器都具有官方传感器类型。
- 这些类型记录在 Android SDK 中。
- 这些类型的传感器的行为在 Android 兼容性测试套件 (CTS) 中进行测试。
- 如果制造商在 Android 设备上集成了一种新型传感器，则可以自行定义一个临时类型来引用它。
- 这些类型没有相关文档，因此应用开发者不太可能使用它们，因为开发者不了解它们，或者知道它们很少存在（仅在该特定制造商制造的某些设备上）。
- 它们不会经过 CTS 测试。
- 一旦 Android 为这种传感器定义了官方传感器类型，那么制造商必须停止使用自己的临时类型，并改为使用官方类型。这样，该传感器将可供更多应用开发者使用。
- 设备上存在的所有传感器的列表由 HAL 实现报告。
- 可以存在几个相同类型的传感器。例如，两个近程传感器或两个加速度计。
- 绝大多数应用仅会请求给定类型的单个传感器。例如，请求默认加速度计的应用将获得列表中的第一个加速度计。
- 传感器通常由唤醒和非唤醒对进行定义，两种传感器会共用同一类型，但其唤醒特性不同。
Android 传感器提供的数据是一系列传感器事件。
每个事件包含：
对所报告数据的解析取决于传感器类型。有关每种传感器类型会报告什么数据的详细信息，请参见传感器类型定义。
现有文档
面向开发者
- 概览
- SDK 参考文档
- Stack Overflow 和教程网站
- 由于有时缺少传感器文档，因此开发者会前往 Stack Overflow 等问答网站寻找答案。
- 此外还有一些教程网站，但通常不会涉及批处理、大幅度动作传感器和游戏旋转矢量传感器等最新功能。
- 这些网站的回答并不一定正确，这就显示出哪些方面需要更多的参考文档。
面向制造商
- 概览
- 硬件抽象层 (HAL)
- Android CDD（兼容性定义文档）
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-19。
[[["易于理解","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"]],["最后更新时间 (UTC)：2025-03-19。"],[],[],null,["# Sensors\n\nAndroid sensors give applications access to a mobile device's underlying\nphysical sensors. They are data-providing virtual devices defined by [sensors.h](https://android.googlesource.com/platform/hardware/libhardware/+/android16-release/include/hardware/sensors.h), the sensor Hardware Abstraction Layer (HAL).\n\nWhat are Android sensors?\n-------------------------\n\nAndroid sensors are virtual devices that provide data coming from a set of\nphysical sensors: accelerometers, gyroscopes, magnetometers, barometer, humidity,\npressure, light, proximity and heart rate sensors.\n\nNot included in the list of physical devices providing data are camera,\nfingerprint sensor, microphone, and touch screen. These devices have their own\nreporting mechanism; the separation is arbitrary, but in general, Android sensors\nprovide lower bandwidth data. For example, \"100hz x 3 channels\" for an\naccelerometer versus \"25hz x 8 MP x 3 channels\" for a camera or \"44kHz x 1\nchannel\" for a microphone.\n\nAndroid does not define how the different physical sensors are connected\nto the system on chip (SoC).\n\n- Often, sensor chips are connected to the SoC through a [sensor hub](/docs/core/interaction/sensors/sensor-stack#sensor_hub), allowing some low-power monitoring and processing of the data.\n- Often, Inter-Integrated Circuit (I2C) or Serial Peripheral Interface (SPI) is used as the transport mechanism.\n- To reduce power consumption, some architectures are hierarchical, with some minimal processing being done in the application-specific integrated circuit (ASIC - like motion detection on the accelerometer chip), and more is done in a microcontroller (like step detection in a sensor hub).\n- It is up to the device manufacturer to choose an architecture based on accuracy, power, price and package-size characteristics. See [Sensor stack](/docs/core/interaction/sensors/sensor-stack) for more information.\n- Batching capabilities are an important consideration for power optimization. See [Batching](/docs/core/interaction/sensors/batching) for more information.\n\nEach Android sensor has a \"type\" representing how the sensor behaves and\nwhat data it provides.\n\n- The official Android [Sensor\n types](/docs/core/interaction/sensors/sensor-types) are defined in [sensors.h](https://android.googlesource.com/platform/hardware/libhardware/+/android16-release/include/hardware/sensors.h) under the names SENSOR_TYPE_...\n - The vast majority of sensors have an official sensor type.\n - Those types are documented in the Android SDK.\n - Behavior of sensors with those types are tested in the Android Compatibility Test Suite (CTS).\n- If a manufacturer integrates a new kind of sensor on an Android device, the manufacturer can define its own temporary type to refer to it.\n - Those types are undocumented, so application developers are unlikely to use them, either because they don't know about them, or know that they are rarely present (only on some devices from this specific manufacturer).\n - They are not tested by CTS.\n - Once Android defines an official sensor type for this kind of sensor, manufacturers must stop using their own temporary type and use the official type instead. This way, the sensor will be used by more application developers.\n- The list of all sensors present on the device is reported by the HAL implementation.\n - There can be several sensors of the same type. For example, two proximity sensors or two accelerometers.\n - The vast majority of applications request only a single sensor of a given type. For example, an application requesting the default accelerometer will get the first accelerometer in the list.\n - Sensors are often defined by [wake-up](/docs/core/interaction/sensors/suspend-mode#wake-up_sensors) and [non-wake-up](/docs/core/interaction/sensors/suspend-mode#non-wake-up_sensors) pairs, both sensors sharing the same type, but differing by their wake-up characteristic.\n\nAndroid sensors provide data as a series of sensor events.\n\nEach [event](/docs/core/interaction/sensors/hal-interface#sensors_event_t)\ncontains:\n\n- a handle to the sensor that generated it\n- the timestamp at which the event was detected or measured, based on [`SystemClock.elapsedRealtimeNanos()`](https://developer.android.com/reference/android/os/SystemClock#elapsedRealtimeNanos())\n- and some data\n\nThe interpretation of the reported data depends on the sensor type. See\nthe [sensor type](/docs/core/interaction/sensors/sensor-types)\ndefinitions for details on what data is reported for each sensor type.\n\nExisting documentation\n----------------------\n\n### Targeted at developers\n\n- Overview\n - \u003chttps://developer.android.com/guide/topics/sensors/sensors_overview.html\u003e\n- SDK reference\n - \u003chttps://developer.android.com/reference/android/hardware/SensorManager\u003e\n - \u003chttps://developer.android.com/reference/android/hardware/SensorEventListener\u003e\n - \u003chttps://developer.android.com/reference/android/hardware/SensorEvent\u003e\n - \u003chttps://developer.android.com/reference/android/hardware/Sensor\u003e\n- Stack Overflow and tutorial websites\n - Because sensors documentation was sometimes lacking, developers resorted to Q\\&A websites like Stack Overflow to find answers.\n - Some tutorial websites exist as well, but do not cover the latest features like batching, significant motion and game rotation vectors.\n - The answers over there are not always right, and show where more documentation is needed.\n\n### Targeted at manufacturers\n\n- Overview\n - This [Sensors](/docs/core/interaction/sensors) page and its sub-pages.\n- Hardware abstraction layer (HAL)\n - [/platform/hardware/libhardware/+/android16-release/include/hardware/sensors.h](https://android.googlesource.com/platform/hardware/libhardware/+/android16-release/include/hardware/sensors.h)\n - Also known as \"sensors.h\"\n - The source of truth. First document to be updated when new features are developed.\n- Android CDD (Compatibility Definition Document)\n - [/compatibility/android-cdd.pdf](/static/docs/compatibility/android-cdd.pdf)\n - See sections relative to sensors.\n - The CDD is lenient, so satisfying the CDD requirements is not enough to ensure high quality sensors."]]
