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) ने वापस किया है.

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

चालू करें(सेंसर, सही/गलत)

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

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

sensor_handle सेंसर का हैंडल है, ताकि इसे चालू या बंद किया जा सके. सेंसर हैंडल को इसके sensor_t स्ट्रक्चर के handle फ़ील्ड से तय किया जाता है.

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

कोई इवेंट मिलने पर, वन-शॉट सेंसर अपने-आप काम करना बंद कर देता है, और उन्हें 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 के बाद, इस फ़ंक्शन का इस्तेमाल नहीं किया जा सकता और इसे कभी कॉल नहीं किया जाता. इसके बजाय, batch फ़ंक्शन को sampling_period_ns पैरामीटर.

HAL के वर्शन 1.0 में, sampling_period_ns को सेट करने के लिए बैच के बजाय set delay का इस्तेमाल किया गया.

flush(sensor)

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

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

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

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

flush को कॉल किए जाने पर, भले ही कोई फ़्लश इवेंट पहले से इस सेंसर के लिए एफ़आईएफ़ओ. एक और सेंसर बनाना और आखिर में जोड़ना ज़रूरी है और 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 का इस्तेमाल, सेंसर के लिए Android हार्डवेयर मॉड्यूल बनाने के लिए किया जाता है. एचएएल को लागू करने के लिए एक ऑब्जेक्ट तय करना ज़रूरी है get_sensors_list फ़ंक्शन को प्रदर्शित करने के लिए इस प्रकार का HAL_MODULE_INFO_SYM. देखें sensors.h में sensors_module_t की परिभाषा और hw_module_t की परिभाषा हमारा वीडियो देखें.

सेंसर_poll_device_t / सेंसर_poll_device_1_t

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

सेंसर_t

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sensors_event_t

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

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

सेंसर: सेंसर का वह हैंडल जिससे इवेंट जनरेट हुआ. इसकी जानकारी sensor_t.handle.

type: इवेंट जनरेट करने वाले सेंसर का टाइप, जैसा कि 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 को कॉल किया जाता है. सेक्शन देखें flsh फ़ंक्शन का इस्तेमाल करें.