Sensors HAL 1.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 पर सेट करें. सेंसर को बंद करने के लिए, इसे 0 पर सेट करें.

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

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

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

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

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

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

batch(sensor, flags, sampling period, maximum report latency)

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 दिखाता है. इसके अलावा, गड़बड़ी होने पर यह गड़बड़ी की संख्या दिखाता है.

poll()

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

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

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

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

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

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

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

fifoMaxEventCount: इस सेंसर के लिए, FIFOs में सेव किए जा सकने वाले इवेंट की ज़्यादा से ज़्यादा संख्या. यह हमेशा fifoReservedEventCount से ज़्यादा या उसके बराबर होता है. इस वैल्यू का इस्तेमाल, यह अनुमान लगाने के लिए किया जाता है कि किसी खास दर पर सेंसर में डेटा रिकॉर्ड करने पर, FIFO कितनी तेज़ी से भर जाएगा. यह अनुमान इस आधार पर लगाया जाता है कि कोई दूसरा सेंसर चालू नहीं है. जिन सिस्टम में हार्डवेयर 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 को elapsedRealtimeNano घड़ी के साथ सिंक किया जाना चाहिए. साथ ही, लगातार काम करने वाले सेंसर के मामले में, जिटर कम होना चाहिए. सीडीडी की ज़रूरी शर्तों को पूरा करने के लिए, कभी-कभी टाइमस्टैंप फ़िल्टर करना ज़रूरी होता है. ऐसा इसलिए, क्योंकि टाइमस्टैंप सेट करने के लिए सिर्फ़ SoC के रुकावट के समय का इस्तेमाल करने से बहुत ज़्यादा गड़बड़ी होती है. साथ ही, टाइमस्टैंप सेट करने के लिए सिर्फ़ सेंसर चिप के समय का इस्तेमाल करने से, elapsedRealtimeNano घड़ी से डेटा सिंक नहीं हो पाता, क्योंकि सेंसर घड़ी में बदलाव होता रहता है.

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

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

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

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

टाइप: यह 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 फ़ंक्शन वाला सेक्शन देखें.