از 27 مارس 2025، توصیه می کنیم از android-latest-release
به جای aosp-main
برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
حسگرها
با مجموعهها، منظم بمانید
ذخیره و طبقهبندی محتوا براساس اولویتهای شما.

حسگرهای اندروید به برنامهها امکان دسترسی به حسگرهای فیزیکی زیرین دستگاه تلفن همراه را میدهند. آنها دستگاه های مجازی ارائه دهنده داده هستند که توسط sensors.h ، لایه انتزاعی سخت افزاری حسگر (HAL) تعریف شده اند.
سنسورهای اندروید چیست؟
حسگرهای اندرویدی دستگاههای مجازی هستند که دادههایی را از مجموعهای از حسگرهای فیزیکی ارائه میدهند: شتابسنج، ژیروسکوپ، مغناطیسسنج، فشارسنج، رطوبت، فشار، نور، مجاورت و سنسورهای ضربان قلب.
دوربین، حسگر اثرانگشت، میکروفون و صفحه نمایش لمسی در لیست دستگاههای فیزیکی ارائهدهنده داده وجود ندارد. این دستگاه ها مکانیزم گزارش دهی خاص خود را دارند. جداسازی دلخواه است، اما به طور کلی، سنسورهای اندروید داده های پهنای باند کمتری را ارائه می دهند. برای مثال، «100hz x 3 channels» برای شتابسنج در مقابل «25hz x 8 MP x 3 channels» برای دوربین یا «44kHz x 1 channel» برای میکروفون.
اندروید نحوه اتصال حسگرهای فیزیکی مختلف به سیستم روی تراشه (SoC) را تعریف نمی کند.
- اغلب، تراشههای حسگر از طریق یک مرکز حسگر به SoC متصل میشوند که امکان نظارت و پردازش کم مصرف دادهها را فراهم میکند.
- اغلب از مدار یکپارچه (I2C) یا رابط محیطی سریال (SPI) به عنوان مکانیسم انتقال استفاده می شود.
- برای کاهش مصرف انرژی، برخی از معماریها سلسله مراتبی هستند، با حداقل پردازش در مدار مجتمع خاص برنامه (مانند تشخیص حرکت ASIC در تراشه شتابسنج)، و کارهای بیشتری در میکروکنترلر انجام میشود (مانند تشخیص مرحله در هاب سنسور).
- این به سازنده دستگاه بستگی دارد که معماری را بر اساس دقت، قدرت، قیمت و ویژگی های اندازه بسته انتخاب کند. برای اطلاعات بیشتر به پشته سنسور مراجعه کنید.
- قابلیتهای دستهبندی یک ملاحظات مهم برای بهینهسازی قدرت هستند. برای اطلاعات بیشتر به Batching مراجعه کنید.
هر سنسور اندروید دارای یک "نوع" است که نشان دهنده نحوه رفتار سنسور و داده هایی است که ارائه می دهد.
- انواع رسمی سنسور اندروید در sensors.h با نامهای SENSOR_TYPE_…
- اکثریت قریب به اتفاق سنسورها دارای سنسور رسمی هستند.
- این انواع در Android SDK مستند شده اند.
- رفتار سنسورها با این نوع در مجموعه تست سازگاری Android (CTS) آزمایش شده است.
- اگر یک سازنده نوع جدیدی از سنسور را در دستگاه اندرویدی ادغام کند، سازنده می تواند نوع موقت خود را برای ارجاع به آن تعریف کند.
- این انواع غیرمستند هستند، بنابراین توسعه دهندگان برنامه بعید به نظر میرسند که از آنها استفاده کنند، یا به این دلیل که در مورد آنها اطلاعاتی ندارند، یا میدانند که به ندرت وجود دارند (فقط در برخی از دستگاههای این سازنده خاص).
- آنها توسط CTS آزمایش نمی شوند.
- هنگامی که اندروید یک نوع سنسور رسمی را برای این نوع سنسور تعریف کرد، سازندگان باید استفاده از نوع موقت خود را متوقف کنند و به جای آن از نوع رسمی استفاده کنند. به این ترتیب، این سنسور توسط توسعه دهندگان برنامه های کاربردی بیشتری استفاده خواهد شد.
- لیست تمام سنسورهای موجود در دستگاه توسط اجرای HAL گزارش شده است.
- ممکن است چندین سنسور از یک نوع وجود داشته باشد. به عنوان مثال، دو سنسور مجاورت یا دو شتاب سنج.
- اکثریت قریب به اتفاق برنامه ها فقط یک سنسور از یک نوع خاص درخواست می کنند. به عنوان مثال، برنامه ای که شتاب سنج پیش فرض را درخواست می کند، اولین شتاب سنج را در لیست دریافت می کند.
- سنسورها اغلب با جفتهای بیدار و غیر بیدار تعریف میشوند، هر دو سنسور از یک نوع مشترک هستند، اما با ویژگی بیدار شدنشان متفاوت هستند.
حسگرهای اندروید داده ها را به صورت مجموعه ای از رویدادهای حسگر ارائه می کنند.
هر رویداد شامل:
تفسیر داده های گزارش شده به نوع حسگر بستگی دارد. برای جزئیات بیشتر در مورد اینکه چه داده هایی برای هر نوع سنسور گزارش می شود، به تعاریف نوع حسگر مراجعه کنید.
اسناد موجود
توسعه دهندگان را هدف قرار داده است
- نمای کلی
- مرجع SDK
- پشته سرریز و وب سایت های آموزشی
- از آنجا که اسناد حسگرها گاهی اوقات کمبود داشتند، توسعه دهندگان برای یافتن پاسخ به وب سایت های پرسش و پاسخ مانند Stack Overflow متوسل شدند.
- برخی از وبسایتهای آموزشی نیز وجود دارند، اما آخرین ویژگیها مانند بردارهای دستهبندی، حرکت قابل توجه و چرخش بازی را پوشش نمیدهند.
- پاسخهای موجود در آنجا همیشه درست نیستند و نشان میدهند کجا به اسناد بیشتری نیاز است.
تولید کنندگان را هدف گرفته است
- نمای کلی
- این صفحه حسگرها و صفحات فرعی آن.
- لایه انتزاعی سخت افزاری (HAL)
- Android CDD (سند تعریف سازگاری)
- /compatibility/android-cdd.pdf
- بخش های مربوط به حسگرها را ببینید.
- CDD ملایم است، بنابراین برآوردن الزامات CDD برای اطمینان از کیفیت بالای حسگرها کافی نیست.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],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."]]