हमारा सुझाव है कि 27 मार्च, 2025 से AOSP को बनाने और उसमें योगदान देने के लिए, aosp-main के बजाय android-latest-release का इस्तेमाल करें. ज़्यादा जानकारी के लिए, AOSP में हुए बदलाव लेख पढ़ें.

इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

इस पेज पर, 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 के साथ रिलीज़ किया गया कैमरा डिवाइस HAL का वर्शन.
Camera API1 CTS: कैमरे के लिए सीटीएस टेस्ट का सेट, जो Camera API1 के ऊपर चलता है.
Camera API2 CTS: कैमरे के लिए, CTS टेस्ट का एक अतिरिक्त सेट. ये टेस्ट, Camera API2 के ऊपर काम करते हैं.
ट्रेबल: यह वेंडर के सेट किए गए सिस्टम (डिवाइस के हिसाब से, सिलिकॉन बनाने वाली कंपनियों का लिखा गया लोअर-लेवल सॉफ़्टवेयर) को नए वेंडर इंटरफ़ेस की मदद से, Android OS फ़्रेमवर्क से अलग करता है.
HIDL: एचएएल इंटरफ़ेस डेफ़िनिशन लैंग्वेज को Treble के साथ पेश किया गया था. इसका इस्तेमाल, एचएएल और उसके उपयोगकर्ताओं के बीच इंटरफ़ेस तय करने के लिए किया जाता है.
VTS: Vendor test suite को Treble के साथ लॉन्च किया गया था.

कैमरा एपीआई

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

Camera API1

Android 5.0 में Camera API1 को बंद कर दिया गया था. नए प्लैटफ़ॉर्म डेवलपमेंट में Camera API2 पर फ़ोकस किया जा रहा है. इसलिए, इसे धीरे-धीरे बंद किया जा रहा है. हालांकि, इस सुविधा को बंद होने में समय लगेगा. साथ ही, 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 की सभी सुविधाएं काम नहीं कर सकती हैं. android.info.supportedHardwareLevel प्रॉपर्टी के लिए, ऐप्लिकेशन Camera API2 इंटरफ़ेस के ज़रिए क्वेरी कर सकते हैं. यह प्रॉपर्टी, सहायता के इन लेवल में से किसी एक के बारे में बताती है:

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 जैसी अन्य सुविधाएं ज़रूरी होती हैं. FULL डिवाइसों के लिए भी, RAW की सुविधा उपलब्ध कराना ज़रूरी नहीं है. 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 CTS की जांच में सामने आते हैं (और जिनकी वजह से यह जांच पूरी नहीं हो पाती), वे डिवाइस के मौजूदा Camera HAL में पहले से मौजूद होते हैं. इसलिए, ये बग मौजूदा Camera API1 ऐप्लिकेशन को भी दिखते हैं. हमें इस तरह के ज़्यादा बग नहीं मिलते. हालांकि, Camera API2 के सीटीएस टेस्ट पास करने के लिए, इस तरह के सभी बग ठीक किए जाने चाहिए.

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

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

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

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

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

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

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

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

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

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

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

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

Validation

जिन डिवाइसों में कैमरा है और जो 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
मिलने वाली अनुमतियां
- 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 से शुरू होना चाहिए, ताकि सार्वजनिक एपीआई में जोड़े गए आने वाले समय के मोड के साथ कोई टकराव न हो.

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

इस तरीके का नाम है.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

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

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

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

इस सेक्शन में, 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 एपीआई के साथ काम कर सकते हैं.