Sensors HAL 1.0

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

• get_sensors_list - इससे सभी सेंसर की सूची मिलती है.
• activate - इससे सेंसर को चालू या बंद किया जाता है.
• batch - यह सेंसर के पैरामीटर सेट करता है. जैसे, सैंपलिंग फ़्रीक्वेंसी और रिपोर्टिंग में लगने वाला ज़्यादा से ज़्यादा समय.
• setDelay - इसका इस्तेमाल सिर्फ़ एचएएल वर्शन 1.0 में किया जाता है. इस फ़ंक्शन का इस्तेमाल करके, किसी सेंसर के लिए सैंपलिंग फ़्रीक्वेंसी सेट की जाती है.
• flush - यह विकल्प, तय किए गए सेंसर के FIFO को फ़्लश करता है. साथ ही, फ़्लश पूरा होने पर इवेंट की सूचना देता है.
• poll - Returns available sensor events.

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

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

• 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);

HAL की ओर से लागू किए गए सेंसर की सूची देता है. सेंसर के बारे में जानकारी पाने के लिए, 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 पर सेट करें.

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

नॉन-वेक-अप सेंसर, एसओसी को कभी भी सस्पेंड मोड में जाने से नहीं रोकते. इसका मतलब है कि HAL, ऐप्लिकेशन की ओर से पार्शियल वेक-लॉक को होल्ड नहीं करेगा.

अगर वेक-अप सेंसर लगातार इवेंट डिलीवर करते हैं, तो वे 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 वह ज़्यादा से ज़्यादा समय है जब इवेंट को HAL के ज़रिए रिपोर्ट करने से पहले, नैनोसेकंड में देरी की जा सकती है. ज़्यादा जानकारी के लिए, 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 को सेट करने के लिए, बैच के बजाय setDelay का इस्तेमाल किया जाता था.

flush(sensor)

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

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

फ़्लश एसिंक्रोनस तरीके से होता है. इसका मतलब है कि इस फ़ंक्शन को तुरंत जवाब देना होगा. अगर कई सेंसर के लिए एक ही 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 को लागू करने के लिए, इस टाइप का 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 टाइप का) HAL के वर्शन नंबर के बारे में बताता है.

sensor_t

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

name: यह एक ऐसी स्ट्रिंग है जिसे उपयोगकर्ता देख सकता है. यह सेंसर को दिखाती है. इस स्ट्रिंग में अक्सर, सेंसर के पार्ट का नाम, सेंसर का टाइप, और यह जानकारी शामिल होती है कि यह वेक-अप सेंसर है या नहीं. उदाहरण के लिए, “LIS2HH12 Accelerometer”, “MAX21000 Uncalibrated Gyroscope”, “BMP280 Wake-up Barometer”, “MPU6515 Game Rotation Vector”

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

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 होगा. फ़्लैग के जिन बिट का इस्तेमाल HAL के मौजूदा वर्शन में नहीं किया जाता उन्हें 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 के उस हिस्से का साइज़ होता है जिसे उस सेंसर के लिए रिज़र्व किया गया है. ज़्यादातर शेयर किए गए FIFO सिस्टम और ऐसे सिस्टम जिनमें हार्डवेयर 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 ने तय किया है.

type: यह उस सेंसर का टाइप है जिसने इवेंट जनरेट किया है. इसे sensor_t.type ने तय किया है.

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

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

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

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

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

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

sensor, reserved, और timestamp: इनकी वैल्यू 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 फ़ंक्शन वाला सेक्शन देखें.