自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
感應器
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
Android 感應器可讓應用程式存取行動裝置的底層實體感應器。這些是資料提供虛擬裝置，由 sensors.h 定義，即感應器硬體抽象層 (HAL)。
什麼是 Android 感應器？
Android 感應器是虛擬裝置，可提供一組實體感應器的資料：加速計、陀螺儀、磁力計、氣壓計、濕度、壓力、光線、鄰近感應器和心率感應器。
相機、指紋感應器、麥克風和觸控螢幕不在提供資料的實體裝置清單中。這些裝置有各自的回報機制，分離方式不拘，但一般而言，Android 感應器會提供較低頻寬的資料。例如，加速計的格式為「100hz x 3 個通道」，相機的格式為「25hz x 8 MP x 3 個通道」，麥克風的格式為「44kHz x 1 個通道」。
Android 並未定義不同實體感應器如何連線至晶片系統 (SoC)。
- 通常，感應器晶片會透過感應器中樞連接至 SoC，以便進行一些低功耗的監控和資料處理作業。
- 通常會使用「積體電路間」(Inter-Integrated Circuit，I2C) 或「序列外圍介面」(Serial Peripheral Interface，SPI) 做為傳輸機制。
- 為減少耗電量，部分架構採用分層式架構，在特殊應用積體電路 (ASIC，例如加速計晶片上的動作偵測) 中執行部分最少的處理作業，並在微控制器中執行更多處理作業 (例如感應器中樞中的步數偵測)。
- 裝置製造商可根據精確度、效能、價格和封裝大小等特性，選擇所需架構。詳情請參閱「感應器堆疊」。
- 批次處理功能是電源最佳化的重要考量。詳情請參閱「批次處理」一節。
每個 Android 感應器都有一個「類型」，代表感應器的行為方式和提供的資料。
- 官方 Android 感應器類型已在 sensors.h 中定義，名稱為 SENSOR_TYPE_…
- 絕大多數感應器都有官方感應器類型。
- 這些類型已在 Android SDK 中記錄。
- 在 Android Compatibility Test Suite (CTS) 中測試這些類型的感應器行為。
- 如果製造商在 Android 裝置上整合新類型的感應器，製造商可以定義自己的暫時型別來參照該感應器。
- 這些類型沒有相關文件，因此應用程式開發人員不太可能使用這些類型，因為他們不瞭解這些類型，或是知道這些類型很少出現 (僅出現在特定製造商的部分裝置上)。
- 並未經過 CTS 測試。
- 一旦 Android 為這類感應器定義官方感應器類型，製造商就必須停止使用自己的臨時類型，改用官方類型。這樣一來，更多應用程式開發人員就能使用這項感應器。
- HAL 實作會回報裝置上所有感應器的清單。
- 同類型的感應器可能有好幾個。例如兩個接近感應器或兩個加速計。
- 大多數應用程式只會要求特定類型的單一感應器。舉例來說，要求預設加速計的應用程式會取得清單中的第一個加速計。
- 感應器通常會以喚醒和非喚醒組合定義，兩者都是同類型感應器，但喚醒特徵不同。
Android 感應器會以一系列感應器事件的形式提供資料。
每個 事件都包含：
回報資料的解讀方式取決於感應器類型。如要進一步瞭解每種感應器類型會回報哪些資料，請參閱感應器類型定義。
現有說明文件
鎖定開發人員
- 總覽
- SDK 參考資料
- Stack Overflow 和教學網站
- 由於感應器說明文件有時不夠完整，開發人員只好轉向 Stack Overflow 等問答網站尋找答案。
- 雖然也有一些教學網站，但不涵蓋最新功能，例如批次處理、重大動作和遊戲旋轉向量。
- 這些答案不一定正確，且會顯示需要更多文件的部分。
鎖定製造商
- 總覽
- 硬體抽象層 (HAL)
- Android CDD (相容性定義文件)
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]
