החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
מצבי דיווח
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
חיישנים יכולים ליצור אירועים בדרכים שונות שנקראות מצבי דיווח. לכל סוג חיישן משויך רק מצב דיווח אחד.
יש ארבעה מצבי דיווח.
רציף
האירועים נוצרים בקצב קבוע שמוגדר על ידי הפרמטר sampling_period_ns שמוענק לפונקציה batch. דוגמאות לחיישנים שמשתמשים במצב דיווח רציף הן מדי תאוצה וג'ירוסקופים.
בעת שינוי
האירועים נוצרים רק אם הערכים שנמדדים השתנו.
הפעלת החיישן ברמת ה-HAL (קריאה ל-activate(..., enable=1) עליו) גם מפעילה אירוע, כלומר ה-HAL חייב להחזיר אירוע באופן מיידי כשחיישן שמופעל בעת שינוי מופעל. דוגמאות לחיישנים שמשתמשים במצב דיווח על שינוי הן סוגי החיישנים הבאים: ספירת צעדים, חיישן קרבה וחישן דופק.
הפרמטר sampling_period_ns שמעבירים לפונקציה batch משמש להגדרת הזמן המינימלי בין אירועים רצופים. כלומר, אסור ליצור אירוע עד שיחלפו sampling_period_ns ננושניות מהאירוע האחרון, גם אם הערך השתנה מאז. אם הערך השתנה, צריך ליצור אירוע ברגע שחולף פרק הזמן sampling_period_ns מהאירוע הקודם.
לדוגמה, נניח:
- אנחנו מפעילים את ספירת הצעדים באמצעות
sampling_period_ns = 10 * 10^9
(10 שניות).
- אנחנו הולכים במשך 55 שניות ואז עומדים ללא תנועה במשך דקה אחת.
- האירועים נוצרים בערך כל 10 שניות במהלך הדקה הראשונה (כולל בשעה
t=0 בגלל הפעלת החיישן, ובשעה t=60), בסך הכל שבעה אירועים. לא נוצר אירוע בדקה השנייה כי הערך של מספר הצעדים לא השתנה אחרי t=60 שניות.
קליפ אחד
כשחיישן מזהה אירוע, הוא משבית את עצמו ואז שולח אירוע אחד דרך HAL. חשוב לשמור על הסדר כדי למנוע מרוץ תהליכים.
(חייב להשבית את החיישן לפני שמדווחים על האירוע דרך HAL). לא נשלח אירוע אחר עד שהחיישן מופעל מחדש.
תנועה משמעותית היא דוגמה לחיישן מהסוג הזה.
חיישנים מסוג 'קליק אחד' נקראים לפעמים חיישנים מפעילים.
המערכת מתעלמת מהפרמטרים sampling_period_ns ו-max_report_latency_ns שמועברים לפונקציה batch. לא ניתן לאחסן אירועים מאירועים חד-פעמיים ב-FIFO של חומרה. צריך לדווח על האירועים ברגע שהם נוצרים.
מיוחד
פרטים על מועד היצירה של האירועים מופיעים בתיאורים של סוגי החיישנים.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. Java ו-OpenJDK הם סימנים מסחריים או סימנים מסחריים רשומים של חברת 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."]]
