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

इस पेज पर, Camera HALs, एपीआई, और उनसे जुड़े 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 HAL
सोसी (सिस्टम ऑन चिप) वेंडर की ओर से लागू की गई कैमरा मॉड्यूल लेयर. ऐप्लिकेशन-लेवल के सार्वजनिक फ़्रेमवर्क, कैमरा एचएएल के ऊपर बनाए जाते हैं.
Camera HAL3.1
Android 4.4 के साथ रिलीज़ किया गया, कैमरा डिवाइस एचएएल का वर्शन.
Camera HAL3.2
Android 5.0 के साथ रिलीज़ किया गया, कैमरा डिवाइस के एचएएल का वर्शन.
Camera API1 CTS
Camera API1 के साथ काम करने वाले कैमरे के सीटीएस टेस्ट का सेट.
Camera API2 CTS
Camera API2 के साथ काम करने वाले कैमरे के सीटीएस टेस्ट का अतिरिक्त सेट.
ट्रेबल
यह वेंडर इंटरफ़ेस के ज़रिए, वेंडर के लागू किए गए वर्शन (डिवाइस के हिसाब से, सिलिकॉन मैन्युफ़ैक्चरर के लिखे गए लोअर-लेवल सॉफ़्टवेयर) को Android OS फ़्रेमवर्क से अलग करता है.
HIDL
HAL इंटरफ़ेस डेफ़िनिशन लैंग्वेज को Treble के साथ लॉन्च किया गया था. इसका इस्तेमाल, HAL और उसके उपयोगकर्ताओं के बीच के इंटरफ़ेस के बारे में बताने के लिए किया जाता है.
VTS
Treble के साथ वेंडर टेस्ट सुइट को भी लॉन्च किया गया.

Camera APIs

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

Camera API1

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

  • ऐप्लिकेशन के लिए Camera API1 इंटरफ़ेस. Camera API1 पर आधारित कैमरा ऐप्लिकेशन, Android के पुराने वर्शन पर चलने वाले डिवाइसों पर ठीक उसी तरह काम करते हैं जिस तरह नए वर्शन पर.
  • Camera HAL के वर्शन. इसमें 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 जैसी सुविधाएं ज़रूरी हैं. 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 API1 के अलावा, किसी भी सुविधा या क्षमता से जुड़े Camera API2 CTS टेस्ट अपने-आप स्किप हो जाते हैं.

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

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

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

कैमरे के फ़्रेमवर्क को बेहतर बनाना

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

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

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

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

    HAL3 पर API1 में Android 7.0 कैमरा और मीडिया स्टैक

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

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

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

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

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

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

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

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

    तीसरा चित्र. 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 को एक बफ़र हैंडल पता A मिलता है, जो बफ़र हैंडल A को सेव करता है. HAL के बफ़र हैंडल A को वापस करने के बाद, बफ़र हैंडल पते A में अगली बार बफ़र हैंडल B सेव हो सकता है, जब HAL को वह मिलता है.
  • cameraserver के लिए SELinux की नीतियां अपडेट करें. अगर डिवाइस के हिसाब से बनी SELinux की नीतियां, मीडिया सर्वर को कैमरा चलाने की अनुमतियां देती हैं, तो आपको SELinux की नीतियां अपडेट करनी होंगी, ताकि मीडिया सर्वर को सही अनुमतियां दी जा सकें. हम cameraserver के लिए, mediaserver की SELinux नीतियों को दोहराने का सुझाव नहीं देते. ऐसा इसलिए, क्योंकि आम तौर पर mediaserver और cameraserver को सिस्टम में अलग-अलग संसाधनों की ज़रूरत होती है. Cameraserver में सिर्फ़ कैमरे की सुविधाओं को इस्तेमाल करने के लिए ज़रूरी अनुमतियां होनी चाहिए. साथ ही, mediaserver में कैमरे से जुड़ी ऐसी सभी अनुमतियां हटा दी जानी चाहिए जो ज़रूरी नहीं हैं.
  • Camera HAL और cameraserver को अलग करना. Android 8.0 और इसके बाद के वर्शन में, कैमरा सर्वर से अलग प्रोसेस में, बाइंडर वाले Camera HAL को अलग किया जाता है. आईपीसी, एचआईडीएल के तय किए गए इंटरफ़ेस से गुज़रता है.

पुष्टि करें

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

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

Camera HAL के वर्शन का इतिहास

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

Android 10

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

Camera API

Camera HAL

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

3.5

ICameraDevice

ICameraDeviceSession

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

ICameraDeviceCallback के बारे में अपडेट:

  • requestStreamBuffers: सिंक्रोनस कॉलबैक, जिसे कैमरा एचएएल, कैमरा सर्वर से बफ़र के लिए कहने के लिए कॉल करता है. requestStreamBuffers देखें.
  • returnStreamBuffers: कैमरा एचएएल के लिए सिंक्रोनस कॉलबैक, ताकि कैमरा सर्वर को आउटपुट बफ़र दिखाए जा सकें. 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 तरीका जोड़ता है, ताकि फ़ोल्ड करने जैसे फ़िज़िकल बदलावों से कैमरे और रूटिंग पर असर पड़ने पर, कैमरा एचएएल को सूचना दी जा सके.

2.4

  • एपीआई लेवल 29 या उसके बाद के वर्शन वाले डिवाइसों को isTorchModeSupported के लिए, true की जानकारी देनी ज़रूरी है.

Android 9

Android 9 रिलीज़ में, Camera2 API और 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 देखें.

Camera HAL

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 को लागू करने के लिए, बाइंडर का इस्तेमाल करना ज़रूरी है. Android 8.0 में, कैमरा सेवा को बेहतर बनाने के लिए ये अहम अपडेट भी शामिल हैं:

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

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

शेयर किए गए प्लैटफ़ॉर्म

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

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

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

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

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

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

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

onCaptureQueueEmpty

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

Camera HIDL इंटरफ़ेस

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

3.4

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

  • अगर RAW_OPAQUE फ़ॉर्मैट काम करता है, तो ANDROID_SENSOR_OPAQUE_RAW_SIZE स्टैटिक मेटाडेटा को ज़रूरी के तौर पर जोड़ें.
  • अगर RAW फ़ॉर्मैट इस्तेमाल किया जा सकता है, तो 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

ज़्यादा सुविधाओं वाले एचएएल में मामूली बदलाव:

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

3.2

ज़्यादा सुविधाओं वाले एचएएल में मामूली बदलाव:

  • 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

ज़्यादा सुविधाओं वाले एचएएल में मामूली बदलाव:

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

3.0

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

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

2.0

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

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

1.0

शुरुआती Android कैमरा एचएएल (Android 4.0) [camera.h]:

  • C++ CameraHardwareInterface ऐब्स्ट्रैक्शन लेयर से बदला गया.
  • android.hardware.Camera API के साथ काम करता है.

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

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

2.4

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

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

2.3

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

2.2

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

2.1

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