सेंसर HAL 1.0

ध्यान दें: इस पेज पर, Sensors HAL 1.0 के बारे में बताया गया है. Android 10 और इसके बाद के वर्शन पर, Sensors HAL 2.0 लागू करने के बारे में जानने के लिए, Sensors HAL 2.0 देखें.

sensors.h में बताया गया सेंसर एचएएल इंटरफ़ेस, Android फ़्रेमवर्क और हार्डवेयर के हिसाब से बने सॉफ़्टवेयर के बीच के इंटरफ़ेस को दिखाता है. HAL लागू करने के लिए, sensors.h में बताए गए हर फ़ंक्शन को तय करना ज़रूरी है. मुख्य फ़ंक्शन ये हैं:

• get_sensors_list - सभी सेंसर की सूची दिखाता है.
• activate - किसी सेंसर को चालू या बंद करता है.
• batch - सेंसर के पैरामीटर सेट करता है. जैसे, सैंपलिंग फ़्रीक्वेंसी और रिपोर्टिंग में लगने वाला ज़्यादा से ज़्यादा समय.
• setDelay - सिर्फ़ HAL वर्शन 1.0 में इस्तेमाल किया जाता है. किसी सेंसर के लिए, सैंपलिंग की फ़्रीक्वेंसी सेट करता है.
• flush - ऐसा किए जाने पर, इस सेंसर के एफ़आईएफ़ओ को फ़्लश करता है और फ़्लश पूरा होने की सूचना देता है.
• poll - सेंसर से मिलने वाले उपलब्ध इवेंट दिखाता है.

लागू करने का तरीका थ्रेड सेफ़ होना चाहिए. साथ ही, इन फ़ंक्शन को अलग-अलग थ्रेड से कॉल करने की अनुमति होनी चाहिए.

इंटरफ़ेस में उन फ़ंक्शन के इस्तेमाल किए जाने वाले कई टाइप भी बताए जाते हैं. मुख्य टाइप ये हैं:

• sensors_module_t
• sensors_poll_device_t
• sensor_t
• sensors_event_t

इन सेक्शन के अलावा, इन टाइप के बारे में ज़्यादा जानकारी के लिए sensors.h देखें.

get_sensors_list(list)

int (*get_sensors_list)(struct sensors_module_t* module, struct sensor_t
  const** list);

एचएएल की मदद से लागू किए गए सेंसर की सूची दिखाता है. सेंसर की परिभाषा तय करने के तरीके के बारे में जानने के लिए, sensor_t देखें.

सूची में सेंसर जिस क्रम में दिखते हैं उसी क्रम में, ऐप्लिकेशन को सेंसर की जानकारी दी जाएगी. आम तौर पर, सबसे पहले बेस सेंसर दिखते हैं और इसके बाद कंपोजिट सेंसर दिखते हैं.

अगर कई सेंसर के सेंसर टाइप और स्क्रीन चालू करने की प्रॉपर्टी एक जैसी होती है, तो सूची में मौजूद पहले सेंसर को “डिफ़ॉल्ट” सेंसर कहा जाता है. यह वही है जो getDefaultSensor(int sensorType, bool wakeUp) ने वापस किया है.

यह फ़ंक्शन, सूची में सेंसर की संख्या दिखाता है.

activate(sensor, true/false)

int (*activate)(struct sensors_poll_device_t *dev, int sensor_handle, int
  enabled);

इससे सेंसर को चालू या बंद किया जाता है.

sensor_handle, सेंसर को चालू/बंद करने का हैंडल है. सेंसर का हैंडल, उसकी sensor_t संरचना के handle फ़ील्ड से तय होता है.

सेंसर को चालू करने के लिए, enabled को 1 पर सेट करें. सेंसर को बंद करने के लिए, enabled को 0 पर सेट करें.

कोई इवेंट मिलने के बाद, एक शॉट वाले सेंसर अपने-आप काम करना बंद कर देते हैं. इसके बावजूद, उन्हें activate(..., enabled=0) पर कॉल करके, अपने-आप बंद होने के अनुरोध को स्वीकार करना होगा.

ऐसे सेंसर जो डिवाइस को चालू नहीं करते, वे कभी भी SoC को निलंबित मोड में जाने से नहीं रोकते. इसका मतलब है कि एचएएल, ऐप्लिकेशन के लिए कुछ समय के लिए डिवाइस को चालू नहीं रखेगा.

लगातार इवेंट डिलीवर करने पर, वेक-अप सेंसर, SoC को स्लीप मोड में जाने से रोक सकते हैं. हालांकि, अगर किसी इवेंट को डिलीवर करने की ज़रूरत नहीं है, तो आंशिक वेक-लॉक को रिलीज़ करना होगा.

अगर enabled की वैल्यू 1 है और सेंसर पहले से चालू है, तो यह फ़ंक्शन काम नहीं करता और इसे पूरा नहीं किया जाता.

अगर enabled 0 है और सेंसर पहले से बंद है, तो यह फ़ंक्शन काम नहीं करता और इसे पूरा नहीं किया जाता.

यह फ़ंक्शन सही होने पर 0 और गलत होने पर गड़बड़ी की संख्या दिखाता है.

बैच(सेंसर, फ़्लैग, सैंपलिंग की अवधि, रिपोर्ट में ज़्यादा से ज़्यादा इंतज़ार का समय)

int (*batch)(
     struct sensors_poll_device_1* dev,
     int sensor_handle,
     int flags,
     int64_t sampling_period_ns,
     int64_t max_report_latency_ns);

सेंसर के पैरामीटर सेट करता है. इनमें सैंपलिंग फ़्रीक्वेंसी और रिपोर्ट के लिए ज़्यादा से ज़्यादा इंतज़ार का समय शामिल है. इस फ़ंक्शन को सेंसर के चालू होने के दौरान कॉल किया जा सकता है. ऐसा करने पर, सेंसर से मिलने वाले डेटा में कोई बदलाव नहीं होगा: एक सैंपलिंग रेट से दूसरे सैंपलिंग रेट पर स्विच करने पर, इवेंट मिटने की संभावना नहीं होती. साथ ही, ज़्यादा से ज़्यादा रिपोर्ट में लगने वाले समय से कम से कम रिपोर्ट में लगने वाले समय पर स्विच करने पर भी, इवेंट मिटने की संभावना नहीं होती.

sensor_handle, कॉन्फ़िगर किए जाने वाले सेंसर का हैंडल है.

फ़िलहाल, flags का इस्तेमाल नहीं किया जाता.

sampling_period_ns, सैंपलिंग की वह अवधि है जिस दौरान सेंसर को नैनोसेकंड में चलाया जाना चाहिए. ज़्यादा जानकारी के लिए, sampling_period_ns देखें.

max_report_latency_ns, वह ज़्यादा से ज़्यादा समय है जिसके बाद इवेंट को एचएएल के ज़रिए रिपोर्ट किया जा सकता है. इसे नैनोसेकंड में दिखाया जाता है. ज़्यादा जानकारी के लिए, max_report_latency_ns पैराग्राफ़ देखें.

यह फ़ंक्शन सक्सेस (सफलता) होने पर 0 दिखाता है और नेगेटिव गड़बड़ी संख्या दिखाता है.

setDelay(sensor, sampling period)

int (*setDelay)(
     struct sensors_poll_device_t *dev,
     int sensor_handle,
     int64_t sampling_period_ns);

HAL वर्शन 1.0 के बाद, इस फ़ंक्शन का इस्तेमाल नहीं किया जा सकता और इसे कभी कॉल नहीं किया जाता. इसके बजाय, sampling_period_ns पैरामीटर को सेट करने के लिए, batch फ़ंक्शन को कॉल किया जाता है.

HAL के वर्शन 1.0 में, sampling_period_ns सेट करने के लिए, batch के बजाय setDelay का इस्तेमाल किया गया था.

flush(sensor)

int (*flush)(struct sensors_poll_device_1* dev, int sensor_handle);

चुने गए सेंसर के लिए, हार्डवेयर एफ़आईएफ़ओ के आखिर में एक फ़्लश पूरा इवेंट जोड़ें और एफ़आईएफ़ओ को फ़्लश करता है; वे इवेंट हमेशा की तरह डिलीवर किए जाते हैं (जैसे कि अगर रिपोर्ट करने में लगने वाला ज़्यादा से ज़्यादा समय खत्म हो गया हो) और एफ़आईएफ़ओ से हटा दिया गया है.

फ़्लश असाइनॉनिमस तौर पर होता है. इसका मतलब है कि यह फ़ंक्शन तुरंत रिटर्न होना चाहिए. अगर लागू करने के लिए, कई सेंसर के लिए एक FIFO का इस्तेमाल किया जाता है, तो उस FIFO को फ़्लश किया जाता है और फ़्लश पूरा होने का इवेंट सिर्फ़ तय किए गए सेंसर के लिए जोड़ा जाता है.

अगर चुने गए सेंसर में कोई FIFO (बफ़रिंग नहीं की जा सकती) नहीं है या कॉल के समय FIFO खाली था, तो भी flush को काम करना चाहिए और उस सेंसर के लिए 'फ़्लश पूरा हो गया' इवेंट भेजना चाहिए. यह बात, एक शॉट वाले सेंसर के अलावा बाकी सभी सेंसर पर लागू होती है.

flush को कॉल करने पर, भले ही उस सेंसर के लिए पहले से ही FIFO में कोई फ़्लश इवेंट मौजूद हो, फिर भी एक और इवेंट बनाया जाना चाहिए और उसे FIFO के आखिर में जोड़ा जाना चाहिए. साथ ही, FIFO को फ़्लश किया जाना चाहिए. flush कॉल की संख्या, बनाए गए फ़्लश पूरे होने वाले इवेंट की संख्या के बराबर होनी चाहिए.

flush, वन-शॉट सेंसर पर लागू नहीं होता; अगर sensor_handle से वन-शॉट सेंसर का रेफ़रंस मिलता है, तो flush को -EINVAL दिखाना चाहिए और पूरा मेटाडेटा फ़्लश करने वाला कोई इवेंट जनरेट नहीं करना चाहिए.

अगर सेंसर चालू है, तो यह फ़ंक्शन 0 दिखाता है. अगर सेंसर एक बार में डेटा इकट्ठा करने वाला है या चालू नहीं है, तो यह -EINVAL दिखाता है. इसके अलावा, गड़बड़ी होने पर यह गड़बड़ी की संख्या दिखाता है.

पोल()

int (*poll)(struct sensors_poll_device_t *dev, sensors_event_t* data, int
  count);

data आर्ग्युमेंट को भरकर, सेंसर डेटा का ऐरे दिखाता है. जब तक इवेंट उपलब्ध नहीं होते, तब तक इस फ़ंक्शन को ब्लॉक करना चाहिए. यह फ़ंक्शन, पढ़े गए इवेंट की संख्या दिखाएगा. अगर कोई गड़बड़ी होती है, तो यह गड़बड़ी की संख्या दिखाएगा.

data में दिखाए गए इवेंट की संख्या, count ऑर्ग्यूमेंट से कम या उसके बराबर होनी चाहिए. यह फ़ंक्शन कभी भी 0 (कोई इवेंट नहीं) नहीं दिखाएगा.

कॉल का क्रम

डिवाइस के चालू होने पर, get_sensors_list को कॉल किया जाता है.

सेंसर के चालू होने पर, batch फ़ंक्शन को अनुरोध किए गए पैरामीटर के साथ कॉल किया जाएगा और इसके बाद, activate(..., enable=1) को कॉल किया जाएगा.

ध्यान दें कि HAL के वर्शन 1_0 में, ऑर्डर उलटा था: activate को पहले और set_delay को बाद में कॉल किया गया था.

जब किसी सेंसर के चालू होने के दौरान, उससे जुड़ी अनुरोध की गई विशेषताएं बदल रही हों, तो batch फ़ंक्शन को कॉल किया जाता है.

flush को कभी भी कॉल किया जा सकता है. ऐसा तब भी किया जा सकता है, जब सेंसर चालू न हों. इस स्थिति में, यह -EINVAL ही दिखेगा

जब कोई सेंसर बंद हो जाता है, तो activate(..., enable=0) को कॉल किया जाएगा.

उन कॉल के साथ-साथ, डेटा का अनुरोध करने के लिए poll फ़ंक्शन को बार-बार कॉल किया जाएगा. poll को तब भी कॉल किया जा सकता है, जब कोई सेंसर चालू न हो.

sensors_module_t

sensors_module_t का इस्तेमाल, सेंसर के लिए Android हार्डवेयर मॉड्यूल बनाने के लिए किया जाता है. एचएएल को लागू करने के लिए इस तरह का HAL_MODULE_INFO_SYM ऑब्जेक्ट तय करना ज़रूरी है, ताकि get_sensors_list फ़ंक्शन को दिखाया जा सके. ज़्यादा जानकारी के लिए, sensors.h में sensors_module_t की परिभाषा और hw_module_t की परिभाषा देखें.

sensors_poll_device_t / sensors_poll_device_1_t

sensors_poll_device_1_t में ऊपर बताए गए बाकी तरीके शामिल हैं: activate, batch, flush, और poll. इसका common फ़ील्ड (hw_device_t टाइप का) एचएएल के वर्शन नंबर की जानकारी देता है.

sensor_t

sensor_t, Android सेंसर के बारे में बताता है. यहां इसके कुछ अहम फ़ील्ड दिए गए हैं:

name: सेंसर की जानकारी देने वाली ऐसी स्ट्रिंग जिसे उपयोगकर्ता देख सकता है. इस स्ट्रिंग में अक्सर सेंसर का नाम, सेंसर का टाइप, और यह जानकारी होती है कि यह वॉकी-अप सेंसर है या नहीं. उदाहरण के लिए, “LIS2HH12 एक्सेलेरोमीटर”, “MAX21000 अनकैलिब्रेटेड गायरोस्कोप”, “BMP280 वेक-अप बैरोमीटर”, “MPU6515 गेम रोटेशन वेक्टर”

हैंडल: सेंसर को रजिस्टर करते समय या उससे इवेंट जनरेट करते समय, सेंसर को रेफ़र करने के लिए इस्तेमाल किया जाने वाला पूर्णांक.

type: सेंसर का टाइप. ज़्यादा जानकारी के लिए, Android सेंसर क्या हैं? में सेंसर टाइप के बारे में दी गई जानकारी देखें. साथ ही, सेंसर के आधिकारिक टाइप के बारे में जानने के लिए, सेंसर टाइप देखें. आधिकारिक सेंसर टाइप के लिए, type को SENSOR_TYPE_DEVICE_PRIVATE_BASE से शुरू करना ज़रूरी है

stringType: स्ट्रिंग के रूप में सेंसर का टाइप. जब सेंसर का टाइप आधिकारिक हो, तो उसे SENSOR_STRING_TYPE_* पर सेट करें. अगर सेंसर का टाइप, मैन्युफ़ैक्चरर के हिसाब से है, तो stringType को मैन्युफ़ैक्चरर के रिवर्स डोमेन नेम से शुरू होना चाहिए. उदाहरण के लिए, Cool-product टीम ने Fictional-Company के लिए एक सेंसर (उदाहरण के लिए, यूनीकॉर्न डिटेक्टर) तय किया है. इस सेंसर के लिए, stringType=”com.fictional_company.cool_product.unicorn_detector” का इस्तेमाल किया जा सकता है. stringType का इस्तेमाल, खास तरह के गैर-आधिकारिक सेंसर की पहचान करने के लिए किया जाता है. टाइप और स्ट्रिंग के टाइप के बारे में ज़्यादा जानकारी के लिए, sensors.h देखें.

requiredPermission: यह एक स्ट्रिंग है, जिसमें उस अनुमति के बारे में जानकारी होती है जो सेंसर को देखने, उसमें रजिस्टर करने, और उसका डेटा पाने के लिए, ऐप्लिकेशन के पास होनी चाहिए. खाली स्ट्रिंग का मतलब है कि ऐप्लिकेशन को इस सेंसर को ऐक्सेस करने के लिए, किसी अनुमति की ज़रूरत नहीं है. हार्ट रेट मॉनिटर जैसे कुछ सेंसर के लिए, requiredPermission ज़रूरी है. उपयोगकर्ता की संवेदनशील जानकारी (जैसे, दिल की धड़कन) देने वाले सभी सेंसर को अनुमति की मदद से सुरक्षित किया जाना चाहिए.

फ़्लैग: इस सेंसर के लिए फ़्लैग, सेंसर के रिपोर्टिंग मोड को तय करने वाला और यह कि सेंसर एक वेक-अप सेंसर है या नहीं. उदाहरण के लिए, एक बार में डिवाइस को चालू करने वाला सेंसर flags = SENSOR_FLAG_ONE_SHOT_MODE | SENSOR_FLAG_WAKE_UP होगा. फ़्लैग के उन बिट को 0 पर सेट करना ज़रूरी है जिनका इस्तेमाल, एचएएल के मौजूदा वर्शन में नहीं किया जाता.

maxRange: सेंसर की ज़्यादा से ज़्यादा वैल्यू, जिस यूनिट में बताई गई वैल्यू बताई गई है उसी यूनिट में. सेंसर, [-maxRange; maxRange] के अंदर वैल्यू को संतृप्त किए बिना रिपोर्ट कर सकता है. ध्यान दें कि इसका मतलब है कि सामान्य तौर पर, सेंसर की कुल रेंज 2*maxRange है. जब सेंसर कई ऐक्सिस पर वैल्यू की रिपोर्ट करता है, तो वह रेंज हर ऐक्सिस पर लागू होती है. उदाहरण के लिए, “+/- 2g” वाला एक्सलरोमीटर maxRange = 2*9.81 = 2g की रिपोर्ट करेगा.

रिज़ॉल्यूशन: सेंसर से मापी जा सकने वाली वैल्यू में, सबसे छोटा अंतर. आम तौर पर, maxRange और मेज़रमेंट में बिट की संख्या के आधार पर कैलकुलेट किया जाता है.

पावर: सेंसर को चालू करने के लिए, मिलीऐंप में खर्च होने वाली ऊर्जा. यह आंकड़ा, आम तौर पर उस सेंसर की डेटाशीट में बताई गई ऊर्जा की खपत से ज़्यादा होता है. ज़्यादा जानकारी के लिए, बेस सेंसर != फ़िज़िकल सेंसर देखें. साथ ही, सेंसर की खपत को मेज़र करने के तरीके के बारे में जानने के लिए, पावर मेज़रमेंट प्रोसेस देखें. अगर सेंसर में ऊर्जा की खपत इस बात पर निर्भर करती है कि डिवाइस चल रहा है या नहीं, तो चलने के दौरान ऊर्जा की खपत वह होगी जो power फ़ील्ड में बताई गई है.

कम से कम देरी: लगातार सेंसर के लिए, सैंपल लेने की अवधि, माइक्रोसेकंड में. होती है. यह अवधि सेंसर की इस्तेमाल की जा सकने वाली सबसे तेज़ दर के हिसाब से होती है. इस वैल्यू का इस्तेमाल कैसे किया जाता है, इस बारे में जानकारी के लिए sampling_period_ns देखें. ध्यान रखें कि minDelay को माइक्रोसेकंड में और sampling_period_ns को नैनोसेकंड में दिखाया जाता है. बदलाव होने पर और खास रिपोर्टिंग मोड वाले सेंसर के लिए, minDelay की वैल्यू 0 होनी चाहिए. हालांकि, अगर वैल्यू के लिए कोई और वैल्यू तय की गई है, तो वह वैल्यू ही इस्तेमाल की जाएगी. एक बार में डेटा इकट्ठा करने वाले सेंसर के लिए, यह वैल्यू -1 होनी चाहिए.

maxDelay: लगातार और बदलाव होने पर डेटा इकट्ठा करने वाले सेंसर के लिए, सैंपलिंग पीरियड को माइक्रोसेकंड में दिखाया जाता है. यह सेंसर के सबसे कम रेट से मेल खाता है. इस वैल्यू का इस्तेमाल कैसे किया जाता है, इस बारे में जानने के लिए sampling_period_ns देखें. ध्यान रखें कि maxDelay को माइक्रोसेकंड में और sampling_period_ns को नैनोसेकंड में दिखाया जाता है. खास और एक बार में काम करने वाले सेंसर के लिए, maxDelay का वैल्यू 0 होना चाहिए.

fifo ReservedEventCount: हार्डवेयर एफ़आईएफ़ओ में इस सेंसर के लिए रिज़र्व किए गए इवेंट की संख्या. अगर इस सेंसर के लिए कोई खास FIFO है, तो fifoReservedEventCount इस खास FIFO का साइज़ है. अगर FIFO को अन्य सेंसर के साथ शेयर किया जाता है, तो fifoReservedEventCount उस सेंसर के लिए रिज़र्व किए गए FIFO के हिस्से का साइज़ होता है. ज़्यादातर शेयर किए गए एफ़आईओ सिस्टम और उन सिस्टम में यह वैल्यू 0 होती है जिनमें हार्डवेयर एफ़आईओ नहीं होता.

fifoMaxEventCount: इस सेंसर के लिए, FIFOs में सेव किए जा सकने वाले इवेंट की ज़्यादा से ज़्यादा संख्या. यह हमेशा fifoReservedEventCount के बराबर या ज़्यादा होता है. इस वैल्यू का इस्तेमाल यह अनुमान लगाने के लिए किया जाता है कि किसी खास दर पर सेंसर में रजिस्टर करने पर, एफ़आईएफ़ओ कितनी जल्दी भर जाएगा. ऐसा माना जाता है कि कोई दूसरा सेंसर चालू नहीं है. जिन सिस्टम में हार्डवेयर FIFO नहीं है, उन पर fifoMaxEventCount की वैल्यू 0 होती है. ज़्यादा जानकारी के लिए बैच करना देखें.

आधिकारिक सेंसर टाइप वाले सेंसर के लिए, फ़्रेमवर्क कुछ फ़ील्ड को ओवरराइट कर देता है. उदाहरण के लिए, एक्सलरोमीटर सेंसर के लिए, लगातार रिपोर्टिंग मोड का इस्तेमाल करना ज़रूरी है. साथ ही, दिल की धड़कन मॉनिटर के लिए, SENSOR_PERMISSION_BODY_SENSORS अनुमति की मदद से डेटा को सुरक्षित रखना ज़रूरी है.

sensors_event_t

Android सेंसर से जनरेट होने वाले और poll फ़ंक्शन की मदद से रिपोर्ट किए जाने वाले सेंसर इवेंट, type sensors_event_t के होते हैं. यहां sensors_event_t के कुछ अहम फ़ील्ड दिए गए हैं:

version: यह sizeof(struct sensors_event_t) होना चाहिए

sensor: इवेंट जनरेट करने वाले सेंसर का हैंडल, जैसा कि sensor_t.handle में बताया गया है.

टाइप: इवेंट जनरेट करने वाले सेंसर का टाइप, जैसा कि sensor_t.type में बताया गया है.

timestamp: नैनोसेकंड में इवेंट का टाइमस्टैंप. यह वह समय होता है जब इवेंट हुआ था (एक कदम उठाया गया था या ऐक्सीलेरोमीटर से मेज़रमेंट किया गया था), न कि इवेंट की रिपोर्ट करने का समय. timestamp को elapsedRealtimeNano घड़ी के साथ सिंक किया जाना चाहिए. साथ ही, लगातार काम करने वाले सेंसर के मामले में, जिटर कम होना चाहिए. सीडीडी की ज़रूरी शर्तों को पूरा करने के लिए, कभी-कभी टाइमस्टैंप फ़िल्टर करना ज़रूरी होता है. ऐसा इसलिए, क्योंकि टाइमस्टैंप सेट करने के लिए सिर्फ़ SoC के रुकावट के समय का इस्तेमाल करने से बहुत ज़्यादा गड़बड़ी होती है. साथ ही, टाइमस्टैंप सेट करने के लिए सिर्फ़ सेंसर चिप के समय का इस्तेमाल करने से, elapsedRealtimeNano घड़ी से डेटा सिंक नहीं हो पाता, क्योंकि सेंसर घड़ी में बदलाव होता रहता है.

डेटा और ओवरलैप होने वाले फ़ील्ड: सेंसर से मेज़र की गई वैल्यू. उन फ़ील्ड का मतलब और यूनिट, हर सेंसर टाइप के हिसाब से अलग-अलग होती हैं. डेटा फ़ील्ड के बारे में जानकारी पाने के लिए, sensors.h और अलग-अलग सेंसर टाइप की परिभाषा देखें. कुछ सेंसर के लिए, status फ़ील्ड की मदद से, डेटा के हिस्से के तौर पर, रीडिंग की सटीक जानकारी भी दी जाती है. यह फ़ील्ड सिर्फ़ उन चुनिंदा सेंसर टाइप के लिए पाइप किया जाता है जो SDK लेयर पर सटीक वैल्यू के तौर पर दिखते हैं. उन सेंसर के लिए, सेंसर टाइप की परिभाषा में बताया गया है कि स्टेटस फ़ील्ड को सेट करना ज़रूरी है.

मेटाडेटा फ़्लश करने के बाद होने वाले इवेंट

मेटाडेटा इवेंट का टाइप, सामान्य सेंसर इवेंट जैसा ही होता है: sensors_event_meta_data_t = sensors_event_t. ये इवेंट, पोल के ज़रिए अन्य सेंसर इवेंट के साथ मिलकर दिखाए जाते हैं. इनमें ये फ़ील्ड होते हैं:

version: META_DATA_VERSION होना चाहिए

type: यह SENSOR_TYPE_META_DATA होना चाहिए

सेंसर, रिज़र्व किया गया, और टाइमस्टैंप: इनकी वैल्यू 0 होनी चाहिए

meta_data.what: इसमें इस इवेंट का मेटाडेटा टाइप शामिल होता है. फ़िलहाल, सिर्फ़ एक तरह का मान्य मेटाडेटा है: META_DATA_FLUSH_COMPLETE.

META_DATA_FLUSH_COMPLETE इवेंट, सेंसर FIFO के फ़्लश के पूरा होने की जानकारी देते हैं. meta_data.what=META_DATA_FLUSH_COMPLETE होने पर, meta_data.sensor को उस सेंसर के हैंडल पर सेट किया जाना चाहिए जिसे फ़्लश किया गया है. ये तब जनरेट होते हैं, जब किसी सेंसर पर flush को कॉल किया जाता है. ज़्यादा जानकारी के लिए, flush फ़ंक्शन वाला सेक्शन देखें.