साल 2026 से, हम अपने ट्रंक स्टेबल डेवलपमेंट मॉडल के साथ अलाइन होने के लिए, दूसरी और चौथी तिमाही में AOSP पर सोर्स कोड पब्लिश करेंगे. इससे यह पक्का किया जा सकेगा कि प्लैटफ़ॉर्म, पूरे सिस्टम के लिए स्थिर बना रहे. हमारा सुझाव है कि AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. android-latest-release मेनिफ़ेस्ट ब्रांच, हमेशा AOSP पर पुश की गई सबसे नई रिलीज़ का रेफ़रंस देगी. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

कैमरे के वर्शन के साथ काम करना

इस पेज पर, Camera HAL, एपीआई, और उनसे जुड़े Compatibility Test Suite (CTS) टेस्ट के वर्शन में अंतर के बारे में जानकारी दी गई है. इसमें Android 7.0 में कैमरा फ़्रेमवर्क को बेहतर और सुरक्षित बनाने के लिए किए गए कई आर्किटेक्चरल बदलावों के बारे में भी बताया गया है. साथ ही, Android 8.0 में Treble पर स्विच करने और इन बदलावों को लागू करने के लिए, वेंडर को अपने कैमरा फ़्रेमवर्क में कौनसे अपडेट करने होंगे, इसके बारे में भी बताया गया है.

शब्दावली

इस पेज पर इन शब्दों का इस्तेमाल किया गया है:

Camera API1: Android 4.4 और इससे पहले के वर्शन वाले डिवाइसों पर, ऐप्लिकेशन लेवल का कैमरा फ़्रेमवर्क. इसे android.hardware.Camera क्लास के ज़रिए ऐक्सेस किया जाता है.
Camera API2: Android 5.0 और इसके बाद के वर्शन वाले डिवाइसों पर, ऐप्लिकेशन-लेवल का कैमरा फ़्रेमवर्क. इसे android.hardware.camera2 पैकेज के ज़रिए ऐक्सेस किया जाता है.
कैमरा एचएएल: कैमरा मॉड्यूल लेयर, जिसे एसओसी वेंडर लागू करते हैं. ऐप्लिकेशन-लेवल के सार्वजनिक फ़्रेमवर्क, कैमरा एचएएल के ऊपर बनाए जाते हैं.
Camera HAL3.1: यह कैमरा डिवाइस एचएएल का वह वर्शन है जिसे Android 4.4 के साथ रिलीज़ किया गया था.
Camera HAL3.2: यह Android 5.0 के साथ रिलीज़ किए गए कैमरा डिवाइस एचएएल का वर्शन है.
Camera API1 CTS: कैमरे के लिए CTS टेस्ट का सेट, जो Camera API1 पर काम करता है.
Camera API2 CTS: कैमरे के लिए सीटीएस के अतिरिक्त टेस्ट का सेट, जो Camera API2 के ऊपर चलता है.
ट्रेबल: यह वेंडर के सेट किए गए सिस्टम (डिवाइस के हिसाब से, सिलिकॉन बनाने वाली कंपनियों का लिखा गया लोअर-लेवल सॉफ़्टवेयर) को Android OS फ़्रेमवर्क से अलग करता है. इसके लिए, यह नए वेंडर इंटरफ़ेस का इस्तेमाल करता है.
HIDL: एचएएल इंटरफ़ेस डेफ़िनिशन लैंग्वेज को Treble के साथ पेश किया गया था. इसका इस्तेमाल, एचएएल और उसके उपयोगकर्ताओं के बीच इंटरफ़ेस तय करने के लिए किया जाता है.
VTS: Vendor test suite को Treble के साथ लॉन्च किया गया था.

कैमरा एपीआई

Android में, कैमरे के ये एपीआई शामिल हैं.

Camera API1

Android 5.0 में Camera API1 का इस्तेमाल बंद कर दिया गया था. नए प्लैटफ़ॉर्म डेवलपमेंट में Camera API2 पर फ़ोकस किया जा रहा है. इसलिए, Camera API1 का इस्तेमाल धीरे-धीरे बंद किया जा रहा है. हालांकि, इस सुविधा को बंद होने में समय लगेगा. साथ ही, Android के नए वर्शन में कुछ समय तक Camera API1 वाले ऐप्लिकेशन काम करते रहेंगे. खास तौर पर, इनके लिए सहायता जारी रहेगी:

ऐप्लिकेशन के लिए Camera API1 इंटरफ़ेस. Camera API1 पर बनाए गए कैमरा ऐप्लिकेशन, Android के पुराने वर्शन पर काम करने वाले डिवाइसों की तरह ही काम करने चाहिए.
कैमरा एचएएल के वर्शन. इसमें Camera HAL1.0 के लिए सपोर्ट शामिल है.

Camera API2

Camera API2 फ़्रेमवर्क, ऐप्लिकेशन को कैमरे का लोअर-लेवल कंट्रोल देता है. इसमें ज़ीरो-कॉपी बर्स्ट/स्ट्रीमिंग फ़्लो और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, कलर कन्वर्ज़न, नॉइज़ कम करना, इमेज को ज़्यादा शार्प बनाना वगैरह के लिए, हर फ़्रेम के कंट्रोल शामिल हैं. ज़्यादा जानकारी के लिए, Google I/O के वीडियो की खास जानकारी देखें.

Android 5.0 और इसके बाद के वर्शन में Camera API2 शामिल है. हालांकि, Android 5.0 और इसके बाद के वर्शन पर काम करने वाले डिवाइसों में, Camera API2 की सभी सुविधाएं काम नहीं कर सकती हैं. ऐप्लिकेशन, Camera API2 इंटरफ़ेस के ज़रिए android.info.supportedHardwareLevel प्रॉपर्टी के बारे में क्वेरी कर सकते हैं. यह प्रॉपर्टी, सहायता के इन लेवल में से किसी एक के बारे में बताती है:

LEGACY: ये डिवाइस, Camera API2 इंटरफ़ेस के ज़रिए ऐप्लिकेशन को सुविधाएं उपलब्ध कराते हैं. ये सुविधाएं, Camera API1 इंटरफ़ेस के ज़रिए ऐप्लिकेशन को उपलब्ध कराई जाने वाली सुविधाओं के जैसी ही होती हैं. लेगसी फ़्रेमवर्क का कोड, Camera API2 कॉल को Camera API1 कॉल में बदलता है. लेगसी डिवाइसों पर, Camera API2 की सुविधाएं काम नहीं करती हैं. जैसे, हर फ़्रेम के लिए कंट्रोल.
LIMITED: इन डिवाइसों पर Camera API2 की कुछ सुविधाएं काम करती हैं, लेकिन सभी नहीं. साथ ही, इन पर Camera HAL 3.2 या इससे नया वर्शन इस्तेमाल किया जाना चाहिए.
FULL: इन डिवाइसों पर Camera API2 की सभी मुख्य सुविधाएं काम करती हैं. साथ ही, इनमें Camera HAL 3.2 या इसके बाद का वर्शन और Android 5.0 या इसके बाद का वर्शन इस्तेमाल किया जाना चाहिए.
LEVEL_3: इन डिवाइसों में, YUV रीप्रोसेसिंग और RAW इमेज कैप्चर करने की सुविधा होती है. साथ ही, इनमें आउटपुट स्ट्रीम के अतिरिक्त कॉन्फ़िगरेशन भी होते हैं.
EXTERNAL: ये डिवाइस, LIMITED डिवाइसों की तरह ही होते हैं. हालांकि, इनमें कुछ अपवाद होते हैं. उदाहरण के लिए, हो सकता है कि कुछ सेंसर या लेंस की जानकारी न दी गई हो या फ़्रेम रेट कम हो. इस लेवल का इस्तेमाल, यूएसबी वेबकैम जैसे बाहरी कैमरों के लिए किया जाता है.

अलग-अलग सुविधाओं को Camera API2 इंटरफ़ेस में मौजूद android.request.availableCapabilities प्रॉपर्टी के ज़रिए दिखाया जाता है. FULL डिवाइसों के लिए, MANUAL_SENSOR और MANUAL_POST_PROCESSING जैसी अन्य सुविधाएं ज़रूरी होती हैं. RAW की सुविधा, FULL डिवाइसों के लिए भी ज़रूरी नहीं है. LIMITED डिवाइस, इनमें से किसी भी सुविधा का विज्ञापन कर सकते हैं. इनमें से किसी भी सुविधा का विज्ञापन न करने का विकल्प भी उपलब्ध है. हालांकि, BACKWARD_COMPATIBLE की क्षमता हमेशा तय की जानी चाहिए.

डिवाइस के साथ काम करने वाले हार्डवेयर लेवल के साथ-साथ, Camera API2 की उन खास सुविधाओं के बारे में जानकारी यहां दी गई है जो डिवाइस पर काम करती हैं. ये सुविधाएं, फ़ीचर फ़्लैग के तौर पर उपलब्ध हैं. इनकी मदद से, Google Play पर Camera API2 वाले कैमरा ऐप्लिकेशन को फ़िल्टर किया जा सकता है.

android.hardware.camera.hardware_level.full
android.hardware.camera.capability.raw
android.hardware.camera.capability.manual_sensor
android.hardware.camera.capability.manual_post_processing

सीटीएस से जुड़ी ज़रूरी शर्तें

Android 5.0 और इसके बाद के वर्शन पर काम करने वाले डिवाइसों को Camera API1 CTS, Camera API2 CTS, और CTS Verifier कैमरा टेस्ट पास करने होंगे.

जिन डिवाइसों में Camera HAL3.2 लागू नहीं किया गया है और जो Camera API2 के सभी इंटरफ़ेस के साथ काम नहीं करते हैं उन्हें Camera API2 के सीटीएस टेस्ट पास करने होंगे. हालांकि, डिवाइस Camera API2 LEGACY मोड में काम करता है. इस मोड में, Camera API2 कॉल को Camera API1 कॉल पर मैप किया जाता है. इसलिए, Camera API2 के ऐसे सभी सीटीएस टेस्ट अपने-आप स्किप हो जाते हैं जो Camera API1 से अलग सुविधाओं या क्षमताओं से जुड़े होते हैं.

लेगसी डिवाइसों पर, Camera API2 के जो सीटीएस टेस्ट चलाए जाते हैं वे मौजूदा सार्वजनिक Camera API1 इंटरफ़ेस और क्षमताओं का इस्तेमाल करते हैं. इनके लिए, कोई नई ज़रूरी शर्तें नहीं हैं. ऐसे बग जो Camera API2 के सीटीएस टेस्ट में फ़ेल होने की वजह बनते हैं, वे डिवाइस के मौजूदा Camera HAL में पहले से मौजूद होते हैं. इसलिए, ये बग मौजूदा Camera API1 ऐप्लिकेशन में भी दिखते हैं. हमें इस तरह के ज़्यादा बग नहीं मिलते. हालांकि, Camera API2 के सीटीएस टेस्ट पास करने के लिए, इस तरह के सभी बग ठीक किए जाने चाहिए.

वीटीएस से जुड़ी ज़रूरी शर्तें

Android 8.0 और इसके बाद के वर्शन पर चलने वाले डिवाइसों में, बाइंडर वाले HAL लागू किए गए हों, तो उन्हें Camera VTS टेस्ट पास करने होंगे.

कैमरे के फ़्रेमवर्क को सुरक्षित बनाना

मीडिया और कैमरे के फ़्रेमवर्क की सुरक्षा को बेहतर बनाने के लिए, Android 7.0 में कैमरा सर्विस को mediaserver से अलग कर दिया गया है. Android 8.0 से, हर बाइंडर वाला Camera HAL, कैमरा सेवा से अलग प्रोसेस में चलता है. इस्तेमाल किए जा रहे एपीआई और एचएएल वर्शन के आधार पर, वेंडर को कैमरा एचएएल में बदलाव करने पड़ सकते हैं. यहां दिए गए सेक्शन में, HAL1 और HAL3 के लिए AP1 और AP2 में हुए आर्किटेक्चरल बदलावों के साथ-साथ सामान्य ज़रूरी शर्तों के बारे में बताया गया है.

API1 के आर्किटेक्चर में बदलाव

API1 की मदद से वीडियो रिकॉर्ड करने के लिए, यह माना जा सकता है कि कैमरा और वीडियो एन्कोडर एक ही प्रोसेस में लाइव हैं. API1 का इस्तेमाल इन पर किया जा सकता है:

HAL3 में, कैमरा सेवा BufferQueue का इस्तेमाल करके प्रोसेस के बीच बफ़र पास करती है. इसलिए, वेंडर के अपडेट की ज़रूरत नहीं होती.

पहली इमेज. Android 7.0 में कैमरा और मीडिया API1 में HAL3 स्टैक
HAL1, वीडियो बफ़र में मेटाडेटा पास करने की सुविधा देता है. वेंडर को kMetadataBufferTypeNativeHandleSource का इस्तेमाल करने के लिए, HAL को अपडेट करना होगा. (kMetadataBufferTypeCameraSource अब Android 7.0 में काम नहीं करता.)

दूसरी इमेज. HAL1 पर API1 में Android 7.0 का कैमरा और मीडिया स्टैक

API2 के आर्किटेक्चर में बदलाव

HAL1 या HAL3 पर API2 के लिए, BufferQueue बफ़र पास करता है, ताकि वे पाथ काम करते रहें. Android 7.0 पर API2 के लिए आर्किटेक्चर:

HAL1 पर, cameraservice को दूसरी जगह ले जाने का कोई असर नहीं पड़ता. साथ ही, किसी वेंडर को अपडेट करने की ज़रूरत नहीं है.
HAL3 पर असर पड़ा है, लेकिन वेंडर के अपडेट की ज़रूरत नहीं है:

तीसरी इमेज. HAL3 पर API2 में Android 7.0 का कैमरा और मीडिया स्टैक

अन्य ज़रूरी शर्तें

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

सामान्य. आईपीसी की वजह से, डिवाइसों को ज़्यादा बैंडविड्थ की ज़रूरत होती है. इससे, कैमरे के ऐसे इस्तेमाल पर असर पड़ सकता है जिनमें समय का ध्यान रखना ज़रूरी होता है. जैसे, हाई-स्पीड वीडियो रिकॉर्डिंग. वेंडर, 120/240 एफ़पीएस पर हाई-स्पीड वीडियो रिकॉर्डिंग के लिए, android.hardware.camera2.cts.PerformanceTest और Google Camera ऐप्लिकेशन का इस्तेमाल करके, परफ़ॉर्मेंस का आकलन कर सकते हैं. डिवाइसों को नई प्रोसेस बनाने के लिए, थोड़ी अतिरिक्त रैम की भी ज़रूरत होती है.
वीडियो बफ़र में मेटाडेटा पास करें (सिर्फ़ HAL1). अगर HAL1, वीडियो बफ़र में असली YUV फ़्रेम डेटा के बजाय मेटाडेटा सेव करता है, तो HAL को मेटाडेटा बफ़र टाइप के तौर पर kMetadataBufferTypeNativeHandleSource का इस्तेमाल करना होगा. साथ ही, वीडियो बफ़र में VideoNativeHandleMetadata पास करना होगा. (kMetadataBufferTypeCameraSource अब Android 7.0 पर काम नहीं करता.) VideoNativeHandleMetadata की मदद से, कैमरा और मीडिया फ़्रेमवर्क, प्रोसेस के बीच वीडियो बफ़र पास कर पाते हैं. इसके लिए, वे नेटिव हैंडल को सही तरीके से क्रमबद्ध और क्रम से हटाते हैं.
बफ़र हैंडल का पता हमेशा एक जैसा बफ़र सेव नहीं करता (सिर्फ़ HAL3). हर कैप्चर अनुरोध के लिए, HAL3 को बफ़र हैंडल के पते मिलते हैं. HAL, बफ़र की पहचान करने के लिए पतों का इस्तेमाल नहीं कर सकता, क्योंकि HAL के बफ़र वापस करने के बाद, पते किसी दूसरे बफ़र हैंडल को सेव कर सकते हैं. बफ़र की पहचान करने के लिए, बफ़र हैंडल का इस्तेमाल करने के लिए, आपको HAL को अपडेट करना होगा. उदाहरण के लिए, HAL को बफ़र हैंडल का पता A मिलता है, जो बफ़र हैंडल A को सेव करता है. HAL के बफ़र हैंडल A को वापस करने के बाद, बफ़र हैंडल A का पता, अगली बार HAL को मिलने पर बफ़र हैंडल B को सेव कर सकता है.
कैमरा सर्वर के लिए SELinux नीतियों को अपडेट करें. अगर डिवाइस के हिसाब से SELinux की नीतियां, mediaserver को कैमरा चलाने की अनुमतियां देती हैं, तो आपको SELinux की नीतियों को अपडेट करना होगा, ताकि cameraserver को सही अनुमतियां मिल सकें. हम mediaserver की SELinux नीतियों को cameraserver के लिए कॉपी करने का सुझाव नहीं देते. इसकी वजह यह है कि mediaserver और cameraserver को आम तौर पर सिस्टम में अलग-अलग संसाधनों की ज़रूरत होती है. Cameraserver के पास सिर्फ़ कैमरे से जुड़ी सुविधाओं को इस्तेमाल करने की अनुमतियां होनी चाहिए. साथ ही, mediaserver में कैमरे से जुड़ी गैर-ज़रूरी अनुमतियों को हटा दिया जाना चाहिए.
कैमरा HAL और cameraserver के बीच अलग-अलग प्रोसेस. Android 8.0 और इसके बाद के वर्शन में, बाइंडर वाले Camera HAL को cameraserver से अलग प्रोसेस में रखा जाता है. आईपीसी, एचआईडीएल के ज़रिए तय किए गए इंटरफ़ेस से होकर गुज़रता है.

सत्यापन

कैमरे की सुविधा वाले और Android 7.0 पर काम करने वाले सभी डिवाइसों के लिए, Android 7.0 CTS चलाकर पुष्टि करें कि सुविधा ठीक से काम कर रही है. Android 7.0 में, कैमरा सेवा में किए गए बदलावों की पुष्टि करने वाले नए सीटीएस टेस्ट शामिल नहीं हैं. हालांकि, अगर आपने ऊपर बताए गए अपडेट नहीं किए हैं, तो मौजूदा सीटीएस टेस्ट फ़ेल हो जाएंगे.

जिन डिवाइसों में कैमरा है और जो Android 8.0 और इसके बाद के वर्शन पर काम करते हैं उन सभी के लिए, VTS चलाकर वेंडर के लागू किए गए सिस्टम की पुष्टि करें.

कैमरा एचएएल का वर्शन इतिहास

Android Camera HAL का आकलन करने के लिए उपलब्ध टेस्ट की सूची देखने के लिए, Camera HAL टेस्टिंग की चेकलिस्ट देखें.

Android 10

Android 10 में ये अपडेट शामिल हैं.

Camera API

एक से ज़्यादा कैमरे की सुविधाओं को बेहतर बनाया गया है. इससे फ़िज़िकल कैमरों को अलग-अलग या उनसे जुड़े लॉजिकल कैमरों के ज़रिए इस्तेमाल किया जा सकता है. इसके लिए, फ़िज़िकल कैमरों के आईडी छिपाए जाते हैं. एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा देखें.
यह जांच करने की सुविधा कि किसी नए सेशन को बनाने में परफ़ॉर्मेंस पर पड़ने वाले असर के बिना, किसी सेशन के कॉन्फ़िगरेशन का इस्तेमाल किया जा सकता है या नहीं. CameraDevice देखें.
किसी इस्तेमाल के उदाहरण के लिए, स्ट्रीम के सुझाए गए कॉन्फ़िगरेशन को वापस पाने की सुविधा. इससे क्लाइंट को ज़्यादा पावर मिलती है और वह बेहतर परफ़ॉर्म कर पाता है. getRecommendedStreamConfigurationMap देखें.
डेप्थ JPEG इमेज फ़ॉर्मैट के लिए सहायता. ज़्यादा जानकारी के लिए, डाइनैमिक डेप्थ स्पेसिफ़िकेशन देखें.
HEIC इमेज फ़ॉर्मैट के लिए सहायता. HEIF फ़ॉर्मैट में फ़ोटो खींचने की सुविधा देखें.
निजता से जुड़े सुधार. क्लाइंट को कुछ कुंजियों के लिए CAMERA अनुमतियों की ज़रूरत होती है. इसके बाद ही, उन्हें CameraCharacteristics से वापस पाया जा सकता है. getKeysNeedingPermission देखें.

कैमरा एचएएल

Android 10 में, Camera HAL के इन वर्शन को अपडेट किया गया है.

3.5

ICameraDevice

getPhysicalCameraCharacteristics: यह किसी लॉजिकल कैमरा डिवाइस को सपोर्ट करने वाले फ़िज़िकल कैमरा आईडी की स्टैटिक जानकारी होती है. एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा देखें.
isStreamCombinationSupported: यह तरीका, सार्वजनिक एपीआई के साथ काम करता है. इससे क्लाइंट यह क्वेरी कर सकते हैं कि सेशन कॉन्फ़िगरेशन काम करता है या नहीं. स्ट्रीम के कॉम्बिनेशन के बारे में क्वेरी करने के लिए एपीआई देखें.

ICameraDeviceSession

isReconfigurationNeeded: यह एक ऐसा तरीका है जिससे कैमरा फ़्रेमवर्क को यह पता चलता है कि संभावित नए सेशन पैरामीटर की वैल्यू के लिए, पूरी स्ट्रीम को फिर से कॉन्फ़िगर करने की ज़रूरत है या नहीं. इससे कैमरे को फिर से कॉन्फ़िगर करने में बेवजह की देरी से बचा जा सकता है. सेशन को फिर से कॉन्फ़िगर करने के लिए क्वेरी देखें.
HAL बफ़र मैनेजमेंट एपीआई: इन एपीआई की मदद से, कैमरा HAL सिर्फ़ ज़रूरत पड़ने पर कैमरा फ़्रेमवर्क से बफ़र का अनुरोध कर सकता है. इसके बजाय, हर कैप्चर अनुरोध को कैमरा पाइपलाइन में उससे जुड़े बफ़र के साथ जोड़ा जाता है. इससे मेमोरी की काफ़ी बचत होती है.
- signalStreamFlush: यह HAL को सिग्नल देता है कि कैमरा सेवा configureStreams_3_5 करने वाली है. साथ ही, HAL को तय की गई स्ट्रीम के सभी बफ़र वापस भेजने होंगे.
- configureStreams_3_5: यह ICameraDevice3.4.configureStreams जैसा ही है. हालांकि, इसमें streamConfigCounter काउंटर भी दिया जाता है, ताकि configureStreams_3_5 और signalStreamFlush कॉल के बीच रेस कंडिशन की जांच की जा सके.

ICameraDeviceCallback से जुड़े अपडेट:

requestStreamBuffers: सिंक्रोनस कॉलबैक, जिसे कैमरा HAL, कैमरा सर्वर से बफ़र के लिए कॉल करता है. requestStreamBuffers देखें.
returnStreamBuffers: कैमरा HAL के लिए सिंक्रोनस कॉलबैक, ताकि कैमरा सर्वर को आउटपुट बफ़र वापस किए जा सकें. returnStreamBuffers देखें.

3.4

Android 10 में, कैमरे के मेटाडेटा में ये कुंजियां जोड़ी गई हैं.

इमेज फ़ॉर्मैट
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
- ANDROID_SCALER_AVAILABLE_FORMATS_Y8
कैमरे के मेटाडेटा टैग
- ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
- ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
- ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
- ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
- ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
- ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
- ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
- ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
- ANDROID_HEIC_INFO_SUPPORTED
- ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT कुंजी के लिए वैल्यू
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
डाइनैमिक डेप्थ स्ट्रीम के लिए उपलब्ध कॉन्फ़िगरेशन
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
HEIC स्ट्रीम के लिए उपलब्ध कॉन्फ़िगरेशन
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

कैमरा मॉड्यूल

Android 10 में, कैमरा मॉड्यूल के इन वर्शन को अपडेट किया गया है.

2.5

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

2.4

एपीआई लेवल 29 या इसके बाद के वर्शन के साथ लॉन्च किए गए डिवाइसों को, isTorchModeSupported के लिए true की जानकारी देनी होगी.

Android 9

Android 9 की रिलीज़ में, camera API2 और HAL इंटरफ़ेस में ये अपडेट किए गए हैं.

Camera API

इसमें मल्टी-कैमरा एपीआई की सुविधा जोड़ी गई है. इससे एक ही दिशा में फ़ोकस करने वाले कई कैमरों वाले डिवाइसों को बेहतर तरीके से इस्तेमाल किया जा सकता है. साथ ही, इससे बोके इफ़ेक्ट और आसानी से ज़ूम करने जैसी सुविधाएं मिलती हैं. इससे ऐप्लिकेशन, डिवाइस पर मौजूद कई कैमरों को एक लॉजिकल यूनिट (लॉजिकल कैमरा) के तौर पर देख पाते हैं. एक लॉजिकल कैमरे में शामिल अलग-अलग कैमरे वाले डिवाइसों को भी कैप्चर करने के अनुरोध भेजे जा सकते हैं. एक से ज़्यादा कैमरे इस्तेमाल करने की सुविधा देखें.
इस कुकी में सेशन पैरामीटर शामिल होते हैं. सेशन पैरामीटर, कैप्चर किए जा सकने वाले पैरामीटर का सबसेट होते हैं. इनमें बदलाव करने पर, प्रोसेसिंग में काफ़ी समय लग सकता है. अगर क्लाइंट, कैप्चर सेशन शुरू करते समय अपनी शुरुआती वैल्यू पास करते हैं, तो इन लागतों को कम किया जा सकता है. सेशन पैरामीटर देखें.
यह ऐप्लिकेशन-लेवल पर स्टेबलाइज़ेशन और इफ़ेक्ट के लिए, ऑप्टिकल स्टेबलाइज़ेशन (ओआईएस) डेटा कुंजियां जोड़ता है. STATISTICS_OIS_SAMPLES देखें.
इससे बाहरी फ़्लैश का इस्तेमाल किया जा सकता है. CONTROL_AE_MODE_ON_EXTERNAL_FLASH देखें.
CAPTURE_INTENT में मोशन ट्रैकिंग इंटेंट जोड़ता है. CONTROL_CAPTURE_INTENT_MOTION_TRACKING देखें.
LENS_RADIAL_DISTORTION को बंद कर दिया गया है और इसकी जगह LENS_DISTORTION को जोड़ दिया गया है.
CaptureRequest में डिस्टॉर्शन ठीक करने वाले मोड जोड़े गए. DISTORTION_CORRECTION_MODE देखें.
इससे, बाहरी यूएसबी/यूवीसी कैमरों को उन डिवाइसों पर इस्तेमाल किया जा सकता है जिन पर यह सुविधा काम करती है. INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL देखें.

कैमरा एचएएल

3.4

ICameraDeviceSession से जुड़े अपडेट

configureStreams_3_4: इसमें sessionParameters और लॉजिकल कैमरों के लिए सहायता जोड़ी गई है.
processCaptureRequest_3_4: स्ट्रीम के स्ट्रक्चर में फ़िज़िकल कैमरा आईडी शामिल करने की सुविधा जोड़ी गई है.

ICameraDeviceCallback से जुड़े अपडेट

processCaptureResult_3_4: इससे कैप्चर किए गए नतीजों में, फ़िज़िकल कैमरे का मेटाडेटा जुड़ जाता है.

3.3

Android 9 में, कैमरे के मेटाडेटा में ये कुंजियां जोड़ी गई हैं.

मिलने वाली अनुमतियां
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
कैमरे के मेटाडेटा टैग
- ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
- ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
- ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
- ANDROID_LENS_POSE_REFERENCE
- ANDROID_LENS_DISTORTION
- ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
- ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
- ANDROID_STATISTICS_OIS_DATA_MODE
- ANDROID_STATISTICS_OIS_TIMESTAMPS
- ANDROID_STATISTICS_OIS_X_SHIFTS
- ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

Android 8.0 की रिलीज़ में Treble को पेश किया गया है. Treble के साथ, वेंडर के Camera HAL को binderized किया जाना चाहिए. Android 8.0 में, कैमरा सेवा से जुड़े ये अहम सुधार भी किए गए हैं:

शेयर किए गए प्लैटफ़ॉर्म: एक ही OutputConfiguration को शेयर करने वाले कई प्लैटफ़ॉर्म चालू करें
कस्टम कैमरा मोड के लिए सिस्टम एपीआई
onCaptureQueueEmpty

इन सुविधाओं के बारे में ज़्यादा जानने के लिए, यहां दिए गए सेक्शन देखें.

शेयर की गई जगहें

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

ज़्यादा जानकारी के लिए, enableSurfaceSharing डेवलपर दस्तावेज़ देखें.

कस्टम कैमरा मोड के लिए सिस्टम एपीआई

सार्वजनिक कैमरा एपीआई में दो ऑपरेटिंग मोड होते हैं: सामान्य और सीमित हाई-स्पीड रिकॉर्डिंग. इनके सिमैंटिक काफ़ी अलग-अलग होते हैं. उदाहरण के लिए, हाई-स्पीड मोड में एक बार में ज़्यादा से ज़्यादा दो खास आउटपुट ही जनरेट किए जा सकते हैं. कई ओईएम ने, हार्डवेयर से जुड़ी सुविधाओं के लिए अन्य कस्टम मोड तय करने में दिलचस्पी दिखाई है. बारीकी से देखें, तो यह मोड सिर्फ़ एक पूर्णांक है, जिसे configure_streams को पास किया जाता है. यहां देखें: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

इस सुविधा में एक सिस्टम एपीआई कॉल शामिल है. ओईएम के कैमरा ऐप्लिकेशन, इसका इस्तेमाल कस्टम मोड चालू करने के लिए कर सकते हैं. ये मोड, पूर्णांक वैल्यू 0x8000 से शुरू होने चाहिए, ताकि सार्वजनिक एपीआई में जोड़े गए आने वाले समय के मोड के साथ कोई टकराव न हो.

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

इस तरीके का नाम android.hardware.camera2.CameraDevice#createCustomCaptureSession है. देखें: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

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

कैमरे का HIDL इंटरफ़ेस

कैमरा एचआईडीएल इंटरफ़ेस, कैमरा एचएएल इंटरफ़ेस का पूरी तरह से नया वर्शन है. यह एचआईडीएल के तय किए गए स्टेबल एपीआई का इस्तेमाल करता है. लेगसी वर्शन 3.4 और 2.4 (कैमरा मॉड्यूल के लिए) में पेश की गई सभी सुविधाएं और कैमरे की क्षमताएं, HIDL की परिभाषाओं का भी हिस्सा हैं.

3.4

मेटाडेटा के साथ काम करने वाली सुविधाओं में कुछ बदलाव किए गए हैं. साथ ही, data_space के साथ काम करने वाली सुविधाओं में भी बदलाव किए गए हैं:

अगर RAW_OPAQUE फ़ॉर्मैट काम करता है, तो ANDROID_SENSOR_OPAQUE_RAW_SIZE स्टैटिक मेटाडेटा को ज़रूरी के तौर पर जोड़ें.
अगर कोई रॉ फ़ॉर्मैट काम करता है, तो ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGEस्टैटिक मेटाडेटा को ज़रूरी तौर पर जोड़ें.
डेटास्पेस एन्कोडिंग की परिभाषा के वर्शन 0 का इस्तेमाल करके, camera3_stream_t data_space फ़ील्ड को ज़्यादा सुविधाजनक परिभाषा पर स्विच करें.
मेटाडेटा में सामान्य तौर पर जोड़ी गई ऐसी जानकारी जिसे HALv3.2 या इसके नए वर्शन के लिए इस्तेमाल किया जा सकता है:
- ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
- ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
- ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
- ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
- ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
- ANDROID_SENSOR_OPAQUE_RAW_SIZE
- ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

ज़्यादा सुविधाओं वाले HAL में मामूली बदलाव किया गया है:

OPAQUE और YUV रीप्रोसेसिंग एपीआई से जुड़े अपडेट.
डेप्थ आउटपुट बफ़र के लिए बुनियादी सहायता.
data_space फ़ील्ड को camera3_stream_t में जोड़ा गया.
camera3_stream_t में रोटेशन फ़ील्ड जोड़ा गया.
camera3_stream_configuration_t में camera3 स्ट्रीम कॉन्फ़िगरेशन ऑपरेशन मोड जोड़ा गया.

3.2

ज़्यादा सुविधाओं वाले HAL में मामूली बदलाव किया गया है:

get_metadata_vendor_tag_ops को बंद कर दिया गया है. इसके बजाय, camera_common.h में get_vendor_tag_ops का इस्तेमाल करें.
register_stream_buffers को बंद कर दिया गया है. process_capture_request में HAL को फ़्रेमवर्क की ओर से दिए गए सभी gralloc बफ़र, किसी भी समय नए हो सकते हैं.
कुछ हद तक नतीजे दिखाने की सुविधा जोड़ी गई. process_capture_result को, पूरा नतीजा उपलब्ध होने से पहले, उपलब्ध नतीजों के सबसेट के साथ कई बार कॉल किया जा सकता है.
camera3_request_template में मैन्युअल टेंप्लेट जोड़ें. ऐप्लिकेशन, सीधे तौर पर कैप्चर करने की सेटिंग को कंट्रोल करने के लिए इस टेंप्लेट का इस्तेमाल कर सकते हैं.
द्विदिश और इनपुट स्ट्रीम की खास बातों में बदलाव किया गया है.
इनपुट बफ़र के रिटर्न पाथ को बदलें. बफ़र को process_capture_request के बजाय process_capture_result में दिखाया जाता है.

3.1

ज़्यादा सुविधाओं वाले HAL में मामूली बदलाव किया गया है:

configure_streams, HAL को उपभोक्ता के इस्तेमाल से जुड़े फ़्लैग पास करता है.
फ़्लश कॉल, सभी इन-फ़्लाइट अनुरोधों/बफ़र को जल्द से जल्द ड्रॉप करने के लिए होता है.

3.0

ज़्यादा सुविधाओं वाले HAL का पहला वर्शन:

एबीआई पूरी तरह से अलग होने की वजह से, मेजर वर्शन में बदलाव किया गया है. 2.0 वर्शन के मुकाबले, हार्डवेयर की ज़रूरी क्षमताओं या ऑपरेशनल मॉडल में कोई बदलाव नहीं हुआ है.
इनपुट के अनुरोध और स्ट्रीम की कतार के इंटरफ़ेस को फिर से बनाया गया है: फ़्रेमवर्क, अगले अनुरोध के साथ एचएएल को कॉल करता है और स्ट्रीम बफ़र पहले से ही कतार से हटा दिए जाते हैं. इसमें सिंक फ़्रेमवर्क की सुविधा शामिल है, जो बेहतर तरीके से लागू करने के लिए ज़रूरी है.
ट्रिगर को अनुरोधों में और ज़्यादातर सूचनाओं को नतीजों में ले जाया गया.
सभी कॉलबैक को एक स्ट्रक्चर में फ़्रेमवर्क में शामिल किया गया है. साथ ही, सेटअप के सभी तरीकों को एक ही initialize() कॉल में शामिल किया गया है.
स्ट्रीम कॉन्फ़िगरेशन को एक ही कॉल में किया जा सकता है, ताकि स्ट्रीम को मैनेज करना आसान हो. द्विदिश स्ट्रीम, STREAM_FROM_STREAM कंस्ट्रक्ट की जगह इस्तेमाल की जाती हैं.
पुराने/सीमित हार्डवेयर डिवाइसों के लिए, सीमित मोड के सिमैंटिक.

2.0

ज़्यादा सुविधाओं वाले एचएएल की शुरुआती रिलीज़ (Android 4.2) [camera2.h]:

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

1.0

Android 4.0 के लिए, Android कैमरा एचएएल [camera.h]:

इसे C++ CameraHardwareInterface ऐब्स्ट्रैक्शन लेयर से बदला गया है.
android.hardware.Camera एपीआई के साथ काम करता है.

कैमरा मॉड्यूल का वर्शन इतिहास

इस सेक्शन में, camera_module_t.common.module_api_version के आधार पर, कैमरा हार्डवेयर मॉड्यूल के मॉड्यूल वर्शन की जानकारी दी गई है. सबसे अहम दो हेक्स अंक, मेजर वर्शन को दिखाते हैं. वहीं, सबसे कम अहम दो हेक्स अंक, माइनर वर्शन को दिखाते हैं.

2.4

कैमरा मॉड्यूल के इस वर्शन में, एपीआई में ये बदलाव किए गए हैं:

टॉर्च मोड की सुविधा उपलब्ध है. फ़्रेमवर्क, फ़्लैश यूनिट वाले किसी भी कैमरा डिवाइस के लिए टॉर्च मोड चालू कर सकता है. इसके लिए, कैमरा डिवाइस को खोलने की ज़रूरत नहीं होती. कैमरा डिवाइस को, कैमरा मॉड्यूल की तुलना में फ़्लैश यूनिट को ऐक्सेस करने की ज़्यादा प्राथमिकता मिलती है. कैमरा डिवाइस खोलने पर, अगर टॉर्च को मॉड्यूल इंटरफ़ेस के ज़रिए चालू किया गया था, तो वह बंद हो जाती है. जब संसाधनों के इस्तेमाल में कोई टकराव होता है, जैसे कि कैमरा डिवाइस खोलने के लिए open() को कॉल किया जाता है, तो कैमरा एचएएल मॉड्यूल को टॉर्च मोड की स्थिति के बारे में जानकारी देने वाले कॉलबैक के ज़रिए फ़्रेमवर्क को यह सूचना देनी चाहिए कि टॉर्च मोड बंद कर दिया गया है.
बाहरी कैमरे (जैसे, यूएसबी हॉट-प्लग कैमरा) के लिए सहायता. एपीआई अपडेट में बताया गया है कि कैमरे की स्टैटिक जानकारी सिर्फ़ तब उपलब्ध होती है, जब कैमरा कनेक्ट हो और बाहरी हॉट-प्लग कैमरों के लिए इस्तेमाल करने के लिए तैयार हो. कैमरे की स्थिति CAMERA_DEVICE_STATUS_PRESENT न होने पर, स्टैटिक जानकारी पाने के लिए की गई कॉल अमान्य कॉल होती हैं. यह फ़्रेमवर्क, उपलब्ध बाहरी कैमरे की सूची को मैनेज करने के लिए, सिर्फ़ डिवाइस के स्टेटस में बदलाव होने पर कॉल किए जाने वाले फ़ंक्शन पर निर्भर करता है.
कैमरा आर्बिट्रेशन के बारे में सुझाव. इससे, एक साथ खोले और इस्तेमाल किए जा सकने वाले कैमरा डिवाइसों की संख्या के बारे में साफ़ तौर पर बताने की सुविधा जोड़ी जाती है. डिवाइसों के मान्य कॉम्बिनेशन तय करने के लिए, resource_cost और conflicting_devices फ़ील्ड को हमेशा camera_info स्ट्रक्चर में सेट किया जाना चाहिए. यह स्ट्रक्चर, get_camera_info कॉल से मिलता है.
मॉड्यूल शुरू करने का तरीका. कैमरा सेवा इस फ़ंक्शन को तब कॉल करती है, जब एचएएल मॉड्यूल लोड हो जाता है. इससे एचएएल को एक बार शुरू किया जा सकता है. इसे किसी अन्य मॉड्यूल के तरीकों को लागू करने से पहले कॉल किया जाता है.

2.3

कैमरा मॉड्यूल के इस वर्शन में, ओपन लेगसी कैमरा एचएएल डिवाइस के साथ काम करने की सुविधा जोड़ी गई है. अगर एक ही डिवाइस पर, डिवाइस के एपीआई के कई वर्शन काम कर सकते हैं, तो फ़्रेमवर्क इसका इस्तेमाल करके कैमरा डिवाइस को डिवाइस के HAL वर्शन HAL डिवाइस के तौर पर खोल सकता है. स्टैंडर्ड हार्डवेयर मॉड्यूल ओपन कॉल (common.methods->open) से, कैमरा डिवाइस को साथ काम करने वाले सबसे नए वर्शन के साथ खोला जाता है. यह वर्शन, camera_info_t.device_version में भी दिखता है.

2.2

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

2.1

कैमरा HAL मॉड्यूल से फ़्रेमवर्क में एसिंक्रोनस कॉलबैक के लिए, कैमरा मॉड्यूल के इस वर्शन में सहायता जोड़ी गई है. इसका इस्तेमाल, फ़्रेमवर्क को कैमरा मॉड्यूल की स्थिति में हुए बदलावों के बारे में सूचना देने के लिए किया जाता है. मान्य set_callbacks() तरीका उपलब्ध कराने वाले मॉड्यूल को कम से कम यह वर्शन नंबर रिपोर्ट करना होगा.

2.0

इस वर्शन नंबर की जानकारी देने वाले कैमरा मॉड्यूल, कैमरा मॉड्यूल एचएएल इंटरफ़ेस का दूसरा वर्शन लागू करते हैं. इस मॉड्यूल के ज़रिए खोले जा सकने वाले कैमरा डिवाइसों में, कैमरा डिवाइस एचएएल इंटरफ़ेस का वर्शन 1.0 या वर्शन 2.0 काम कर सकता है. camera_info का device_version फ़ील्ड हमेशा मान्य होता है. camera_info का static_camera_characteristics फ़ील्ड तब मान्य होता है, जब device_version फ़ील्ड 2.0 या इससे ज़्यादा हो.

1.0

इन वर्शन नंबर की जानकारी देने वाले कैमरा मॉड्यूल, कैमरा मॉड्यूल एचएएल इंटरफ़ेस का शुरुआती वर्शन लागू करते हैं. इस मॉड्यूल से खोले जा सकने वाले सभी कैमरा डिवाइस, सिर्फ़ कैमरा डिवाइस एचएएल के वर्शन 1 के साथ काम करते हैं. camera_info फ़ील्ड के device_version और static_camera_characteristics फ़ील्ड मान्य नहीं हैं. यह मॉड्यूल और इससे जुड़े डिवाइस, सिर्फ़ android.hardware.Camera एपीआई के साथ काम कर सकते हैं.