कैमरा वर्शन की सुविधा

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

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

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

    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 बफ़र पास करता है, ताकि वे पाथ काम करते रहें. इन पर API2 के लिए Android 7.0 आर्किटेक्चर:

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

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

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

Android 10

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

Camera API

Camera HAL

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

3.5

ICameraDevice

ICameraDeviceSession

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

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 रिलीज़ में, Camera API2 और एचएएल इंटरफ़ेस के ये अपडेट शामिल किए गए हैं.

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

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

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

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

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

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

कस्टम कैमरा मोड के लिए System API

Public Camera API दो ऑपरेटिंग मोड के बारे में जानकारी देता है: सामान्य और सीमित हाई-स्पीड रिकॉर्डिंग. इनका सेमेंटेटिक्स काफ़ी अलग होता है. उदाहरण के लिए, एक बार में ज़्यादा से ज़्यादा दो खास आउटपुट के लिए, हाई-स्पीड मोड का इस्तेमाल किया जा सकता है. कई 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 इसके लिए एचएएल का इस्तेमाल करने की ज़रूरत नहीं होती. इसे पूरी तरह से फ़्रेमवर्क-साइड जोड़ा गया था. जिन ऐप्लिकेशन को इसका फ़ायदा लेना है उन्हें उस कॉलबैक में एक लिसनर जोड़ना होगा और सही जवाब देना होगा. आम तौर पर, कैमरे डिवाइस को फ़ोटो लेने का एक और अनुरोध भेजकर ऐसा किया जाता है.

Camera HIDL इंटरफ़ेस

Camera HIDL इंटरफ़ेस, कैमरे एचएएल इंटरफ़ेस का एक बेहतर वर्शन है. यह स्टेबल 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 reprocessing API के अपडेट.
  • डेप्थ आउटपुट बफ़र के लिए बुनियादी सहायता.
  • 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 कतार की अनुमति देता है.
  • मैन्युअल कैप्चर कंट्रोल, बेयर 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 फ़ील्ड हमेशा camera_info स्ट्रक्चर में सेट किए जाने चाहिए, जिसे get_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 एपीआई का इस्तेमाल किया जा सकता है.