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

कैमरा संस्करण समर्थन

यह पृष्ठ कैमरा एचएएल, एपीआई और संबंधित संगतता परीक्षण सूट (सीटीएस) परीक्षणों में संस्करण अंतर का विवरण देता है। इसमें एंड्रॉइड 7.0 में कैमरा फ्रेमवर्क को सख्त और सुरक्षित करने के लिए किए गए कई वास्तुशिल्प परिवर्तन, एंड्रॉइड 8.0 में ट्रेबल पर स्विच और विक्रेताओं को अपने कैमरा कार्यान्वयन में इन परिवर्तनों का समर्थन करने के लिए किए जाने वाले अपडेट भी शामिल हैं।

शब्दावली

इस पृष्ठ पर निम्नलिखित शब्दों का उपयोग किया गया है:

कैमरा API1: एंड्रॉइड 4.4 और उससे नीचे के डिवाइस पर ऐप-स्तरीय कैमरा फ्रेमवर्क, android.hardware.Camera क्लास के माध्यम से प्रदर्शित किया गया।
कैमरा API2: एंड्रॉइड 5.0 और उच्चतर उपकरणों पर ऐप-स्तरीय कैमरा ढांचा, android.hardware.camera2 पैकेज के माध्यम से प्रदर्शित किया गया है।
कैमरा एचएएल: SoC विक्रेताओं द्वारा कार्यान्वित कैमरा मॉड्यूल परत। ऐप-स्तरीय सार्वजनिक फ़्रेमवर्क कैमरा HAL के शीर्ष पर बनाए गए हैं।
कैमरा HAL3.1: कैमरा डिवाइस HAL का संस्करण Android 4.4 के साथ जारी किया गया।
कैमरा HAL3.2: कैमरा डिवाइस HAL का संस्करण Android 5.0 के साथ जारी किया गया।
कैमरा एपीआई1 सीटीएस: कैमरा सीटीएस परीक्षणों का सेट जो कैमरा एपीआई1 के शीर्ष पर चलता है।
कैमरा API2 CTS: कैमरा CTS परीक्षणों का अतिरिक्त सेट जो कैमरा API2 के शीर्ष पर चलता है।
तिहरा: एक नए विक्रेता इंटरफ़ेस के माध्यम से विक्रेता कार्यान्वयन (सिलिकॉन निर्माताओं द्वारा लिखित डिवाइस-विशिष्ट, निचले स्तर का सॉफ़्टवेयर) को एंड्रॉइड ओएस ढांचे से अलग करता है।
छिपाना: एचएएल इंटरफ़ेस परिभाषा भाषा को ट्रेबल के साथ पेश किया गया और इसका उपयोग एचएएल और उसके उपयोगकर्ताओं के बीच इंटरफ़ेस को निर्दिष्ट करने के लिए किया गया।
वीटीएस: ट्रेबल के साथ विक्रेता परीक्षण सूट पेश किया गया।

कैमरा एपीआई

एंड्रॉइड में निम्नलिखित कैमरा एपीआई शामिल हैं।

कैमरा API1

एंड्रॉइड 5.0 ने कैमरा एपीआई1 को बंद कर दिया है, जिसे धीरे-धीरे हटाया जा रहा है क्योंकि नए प्लेटफॉर्म का विकास कैमरा एपीआई2 पर केंद्रित है। हालाँकि, चरण-आउट अवधि लंबी होगी, और एंड्रॉइड रिलीज़ कुछ समय तक कैमरा एपीआई1 ऐप्स का समर्थन करना जारी रखेंगे। विशेष रूप से, इनके लिए समर्थन जारी है:

ऐप्स के लिए कैमरा API1 इंटरफ़ेस। कैमरा एपीआई1 के शीर्ष पर बने कैमरा ऐप्स को वैसे ही काम करना चाहिए जैसे वे निचले एंड्रॉइड रिलीज़ संस्करण चलाने वाले उपकरणों पर करते हैं।
कैमरा एचएएल संस्करण। कैमरा HAL1.0 के लिए समर्थन शामिल है।

कैमरा API2

कैमरा एपीआई2 फ्रेमवर्क ऐप में निचले स्तर के कैमरा नियंत्रण को उजागर करता है, जिसमें कुशल शून्य-कॉपी बर्स्ट/स्ट्रीमिंग प्रवाह और एक्सपोज़र, गेन, व्हाइट बैलेंस गेन, रंग रूपांतरण, डीनोइज़िंग, शार्पनिंग और बहुत कुछ के प्रति-फ़्रेम नियंत्रण शामिल हैं। विवरण के लिए, Google I/O वीडियो अवलोकन देखें।

Android 5.0 और उच्चतर में कैमरा API2 शामिल है; हालाँकि, Android 5.0 और उच्चतर संस्करण चलाने वाले डिवाइस सभी कैमरा API2 सुविधाओं का समर्थन नहीं कर सकते हैं। android.info.supportedHardwareLevel प्रॉपर्टी, जिसे ऐप्स कैमरा API2 इंटरफ़ेस के माध्यम से क्वेरी कर सकते हैं, निम्न समर्थन स्तरों में से एक की रिपोर्ट करती है:

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

कैमरा एपीआई2 इंटरफेस में android.request.availableCapabilities प्रॉपर्टी के माध्यम से व्यक्तिगत क्षमताओं को उजागर किया जाता है। FULL उपकरणों के लिए MANUAL_SENSOR और MANUAL_POST_PROCESSING क्षमताओं की आवश्यकता होती है। RAW क्षमता FULL उपकरणों के लिए भी वैकल्पिक है। LIMITED उपकरण इन क्षमताओं के किसी भी उपसमूह का विज्ञापन कर सकते हैं, इनमें से कोई भी शामिल नहीं है। हालाँकि, BACKWARD_COMPATIBLE क्षमता को हमेशा परिभाषित किया जाना चाहिए।

डिवाइस का समर्थित हार्डवेयर स्तर, साथ ही इसके द्वारा समर्थित विशिष्ट कैमरा एपीआई2 क्षमताएं, कैमरा एपीआई2 कैमरा ऐप्स के Google Play फ़िल्टरिंग की अनुमति देने के लिए निम्नलिखित फीचर फ़्लैग के रूप में उपलब्ध हैं।

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 और उच्चतर संस्करण चलाने वाले उपकरणों को कैमरा API1 CTS, कैमरा API2 CTS और CTS सत्यापनकर्ता कैमरा परीक्षण पास करना होगा।

जिन डिवाइसों में कैमरा HAL3.2 कार्यान्वयन की सुविधा नहीं है और वे पूर्ण कैमरा API2 इंटरफेस का समर्थन करने में सक्षम नहीं हैं, उन्हें अभी भी कैमरा API2 CTS परीक्षण पास करना होगा। हालाँकि, डिवाइस कैमरा एपीआई2 LEGACY मोड में चलता है (जिसमें कैमरा एपीआई2 कॉल को संकल्पनात्मक रूप से कैमरा एपीआई1 कॉल में मैप किया जाता है) इसलिए कैमरा एपीआई1 से परे सुविधाओं या क्षमताओं से संबंधित कोई भी कैमरा एपीआई2 सीटीएस परीक्षण स्वचालित रूप से छोड़ दिया जाता है।

पुराने उपकरणों पर, चलाए जाने वाले कैमरा एपीआई2 सीटीएस परीक्षण बिना किसी नई आवश्यकता के मौजूदा सार्वजनिक कैमरा एपीआई1 इंटरफेस और क्षमताओं का उपयोग करते हैं। जो बग सामने आए हैं (और जो कैमरा एपीआई2 सीटीएस विफलता का कारण बनते हैं) वे डिवाइस के मौजूदा कैमरा एचएएल में पहले से मौजूद बग हैं, और इस प्रकार मौजूदा कैमरा एपीआई1 ऐप्स द्वारा ढूंढ लिए जाएंगे। हम इस प्रकृति के कई बग की उम्मीद नहीं करते हैं (हालांकि, कैमरा एपीआई2 सीटीएस परीक्षण पास करने के लिए ऐसे किसी भी बग को ठीक किया जाना चाहिए)।

वीटीएस आवश्यकताएँ

बाइंडराइज्ड एचएएल कार्यान्वयन के साथ एंड्रॉइड 8.0 और उच्चतर संस्करण चलाने वाले उपकरणों को कैमरा वीटीएस परीक्षण पास करना होगा।

कैमरा ढाँचा सख्त हो रहा है

मीडिया और कैमरा फ्रेमवर्क सुरक्षा को सख्त करने के लिए, एंड्रॉइड 7.0 कैमरा सेवा को मीडियासर्वर से बाहर ले जाता है। एंड्रॉइड 8.0 से शुरू होकर, प्रत्येक बाइंडराइज्ड कैमरा एचएएल कैमरा सेवा से अलग प्रक्रिया में चलता है। विक्रेताओं को उपयोग में आने वाले एपीआई और एचएएल संस्करणों के आधार पर कैमरा एचएएल में बदलाव करने की आवश्यकता हो सकती है। निम्नलिखित अनुभाग HAL1 और HAL3 के लिए AP1 और AP2 में वास्तुशिल्प परिवर्तनों के साथ-साथ सामान्य आवश्यकताओं का विवरण देते हैं।

API1 के लिए वास्तुशिल्प परिवर्तन

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

HAL3, जहां कैमरा सेवा प्रक्रियाओं के बीच बफ़र्स को पास करने के लिए बफ़रक्यू का उपयोग करती है, कोई विक्रेता अद्यतन आवश्यक नहीं है।
चित्र 1. HAL3 पर API1 में Android 7.0 कैमरा और मीडिया स्टैक
HAL1, जो वीडियो बफ़र्स में मेटाडेटा पास करने का समर्थन करता है, विक्रेताओं को kMetadataBufferTypeNativeHandleSource का उपयोग करने के लिए HAL को अपडेट करना होगा। ( kMetadataBufferTypeCameraSource अब Android 7.0 में समर्थित नहीं है।)
चित्र 2. HAL1 पर API1 में Android 7.0 कैमरा और मीडिया स्टैक

API2 के लिए वास्तुशिल्प परिवर्तन

HAL1 या HAL3 पर API2 के लिए, बफ़रक्यू बफ़र्स पास करता है ताकि वे पथ काम करना जारी रखें। API2 के लिए Android 7.0 आर्किटेक्चर:

HAL1 कैमरा सेवा के स्थानांतरण से प्रभावित नहीं है, और कोई विक्रेता अद्यतन आवश्यक नहीं है।
HAL3 प्रभावित है , लेकिन कोई विक्रेता अद्यतन आवश्यक नहीं है:
चित्र 3. HAL3 पर API2 में Android 7.0 कैमरा और मीडिया स्टैक

अतिरिक्त जरूरतें

मीडिया और कैमरा फ्रेमवर्क सुरक्षा को मजबूत करने के लिए किए गए वास्तुशिल्प परिवर्तनों में निम्नलिखित अतिरिक्त डिवाइस आवश्यकताएं शामिल हैं।

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

मान्यकरण

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

उन सभी उपकरणों के लिए जिनमें कैमरा शामिल है और जो एंड्रॉइड 8.0 और उच्चतर पर चलते हैं, वीटीएस चलाकर विक्रेता कार्यान्वयन को सत्यापित करें।

कैमरा एचएएल संस्करण इतिहास

एंड्रॉइड कैमरा एचएएल के मूल्यांकन के लिए उपलब्ध परीक्षणों की सूची के लिए, कैमरा एचएएल परीक्षण चेकलिस्ट देखें।

एंड्रॉइड 10

एंड्रॉइड 10 निम्नलिखित अपडेट पेश करता है।

कैमरा एपीआई

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

कैमरा एचएएल

निम्नलिखित कैमरा HAL संस्करण Android 10 में अपडेट किए गए हैं।

3.5

ICameraDevice

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

ICameraDeviceSession

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

ICameraDeviceCallback में अपडेट:

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

3.4

एंड्रॉइड 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

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

निम्नलिखित कैमरा मॉड्यूल संस्करण एंड्रॉइड 10 में अपडेट किए गए हैं।

2.5

जब भौतिक परिवर्तन, जैसे फ़ोल्डिंग, कैमरा और रूटिंग को प्रभावित करते हैं, तो कैमरा HAL को सूचित करने के लिए उपकरणों के लिए notifyDeviceStateChange विधि जोड़ता है।

2.4

एपीआई स्तर 29 या उच्चतर के साथ लॉन्च होने वाले उपकरणों को isTorchModeSupported के लिए true रिपोर्ट करना होगा।

एंड्रॉइड 9

एंड्रॉइड 9 रिलीज़ कैमरा एपीआई2 और एचएएल इंटरफ़ेस में निम्नलिखित अपडेट पेश करता है।

कैमरा एपीआई

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

एंड्रॉइड 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

एंड्रॉइड 8.0

एंड्रॉइड 8.0 रिलीज़ ट्रेबल पेश करता है। ट्रेबल के साथ, विक्रेता कैमरा एचएएल कार्यान्वयन को बाइंडराइज़ किया जाना चाहिए। एंड्रॉइड 8.0 में कैमरा सेवा में ये प्रमुख संवर्द्धन भी शामिल हैं:

साझा सतहें: समान OutputConfiguration साझा करने वाली एकाधिक सतहों को सक्षम करें
कस्टम कैमरा मोड के लिए सिस्टम एपीआई
onCaptureQueueEmpty

इन सुविधाओं पर अधिक जानकारी के लिए नीचे दिए गए अनुभाग देखें।

साझा सतहें

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

अतिरिक्त विवरण के लिए enableSurfaceSharing डेवलपर दस्तावेज़ देखें।

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

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

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

इस सुविधा का समर्थन करने के लिए, OEM को केवल अपने HAL में नया मोड जोड़ने की आवश्यकता है, जो config_streams पर HAL को दिए गए इस पूर्णांक द्वारा ट्रिगर होता है, और फिर उनके कस्टम कैमरा ऐप को सिस्टम API का उपयोग करना होता है।

विधि का नाम android.hardware.camera2.CameraDevice#createCustomCaptureSession है। देखें: frameworks/base/core/java/android/hardware/camera2/CameraDevice

onCaptureQueueEmpty

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

कैमरा एचआईडीएल इंटरफ़ेस

कैमरा एचआईडीएल इंटरफ़ेस कैमरा एचएएल इंटरफ़ेस का एक पूर्ण ओवरहाल है जो स्थिर एचआईडीएल-परिभाषित एपीआई का उपयोग करता है। सबसे हालिया विरासत संस्करण 3.4 और 2.4 (कैमरा मॉड्यूल के लिए) में पेश की गई सभी सुविधाएं और कैमरा क्षमताएं भी एचआईडीएल परिभाषाओं का हिस्सा हैं।

3.4

समर्थित मेटाडेटा में मामूली परिवर्धन और डेटा_स्पेस समर्थन में परिवर्तन:

यदि 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 रीप्रोसेसिंग API अपडेट।
गहराई आउटपुट बफ़र्स के लिए बुनियादी समर्थन।
camera3_stream_t में data_space फ़ील्ड जोड़ना।
camera3_stream_t में रोटेशन फ़ील्ड को जोड़ना।
कैमरा3 स्ट्रीम कॉन्फ़िगरेशन ऑपरेशन मोड को camera3_stream_configuration_t में जोड़ना।

3.2

विस्तारित क्षमता वाले एचएएल का मामूली संशोधन:

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

3.1

विस्तारित क्षमता वाले एचएएल का मामूली संशोधन:

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

3.0

विस्तारित क्षमता वाले एचएएल का पहला संशोधन:

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

2.0

विस्तारित-क्षमता वाले HAL (Android 4.2) की आरंभिक रिलीज़ [camera2.h]:

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

1.0

प्रारंभिक एंड्रॉइड कैमरा एचएएल (एंड्रॉइड 4.0) [कैमरा.एच]:

C++ कैमराहार्डवेयरइंटरफ़ेस एब्स्ट्रैक्शन परत से परिवर्तित।
android.hardware.Camera API को सपोर्ट करता है।

कैमरा मॉड्यूल संस्करण इतिहास

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

2.4

यह कैमरा मॉड्यूल संस्करण निम्नलिखित एपीआई परिवर्तन जोड़ता है:

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

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 का समर्थन कर सकते हैं। कैमरा_इन्फो का device_version फ़ील्ड हमेशा मान्य होता है; यदि device_version फ़ील्ड 2.0 या उच्चतर है, तो camera_info का static_camera_characteristics फ़ील्ड मान्य है।

1.0

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

शब्दावली

इस पृष्ठ पर निम्नलिखित शब्दों का उपयोग किया गया है:

कैमरा API1: एंड्रॉइड 4.4 और उससे नीचे के डिवाइस पर ऐप-स्तरीय कैमरा फ्रेमवर्क, android.hardware.Camera क्लास के माध्यम से प्रदर्शित किया गया।
कैमरा API2: एंड्रॉइड 5.0 और उच्चतर उपकरणों पर ऐप-स्तरीय कैमरा ढांचा, android.hardware.camera2 पैकेज के माध्यम से प्रदर्शित किया गया है।
कैमरा एचएएल: SoC विक्रेताओं द्वारा कार्यान्वित कैमरा मॉड्यूल परत। ऐप-स्तरीय सार्वजनिक फ़्रेमवर्क कैमरा HAL के शीर्ष पर बनाए गए हैं।
कैमरा HAL3.1: कैमरा डिवाइस HAL का संस्करण Android 4.4 के साथ जारी किया गया।
कैमरा HAL3.2: कैमरा डिवाइस HAL का संस्करण Android 5.0 के साथ जारी किया गया।
कैमरा एपीआई1 सीटीएस: कैमरा सीटीएस परीक्षणों का सेट जो कैमरा एपीआई1 के शीर्ष पर चलता है।
कैमरा API2 CTS: कैमरा CTS परीक्षणों का अतिरिक्त सेट जो कैमरा API2 के शीर्ष पर चलता है।
तिहरा: एक नए विक्रेता इंटरफ़ेस के माध्यम से विक्रेता कार्यान्वयन (सिलिकॉन निर्माताओं द्वारा लिखित डिवाइस-विशिष्ट, निचले स्तर का सॉफ़्टवेयर) को एंड्रॉइड ओएस ढांचे से अलग करता है।
छिपाना: एचएएल इंटरफ़ेस परिभाषा भाषा को ट्रेबल के साथ पेश किया गया और इसका उपयोग एचएएल और उसके उपयोगकर्ताओं के बीच इंटरफ़ेस को निर्दिष्ट करने के लिए किया गया।
वीटीएस: ट्रेबल के साथ विक्रेता परीक्षण सूट पेश किया गया।

कैमरा एपीआई

एंड्रॉइड में निम्नलिखित कैमरा एपीआई शामिल हैं।

कैमरा API1

ऐप्स के लिए कैमरा API1 इंटरफ़ेस। कैमरा एपीआई1 के शीर्ष पर बने कैमरा ऐप्स को वैसे ही काम करना चाहिए जैसे वे निचले एंड्रॉइड रिलीज़ संस्करण चलाने वाले उपकरणों पर करते हैं।
कैमरा एचएएल संस्करण। कैमरा HAL1.0 के लिए समर्थन शामिल है।

कैमरा API2

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

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

सीटीएस आवश्यकताएँ

वीटीएस आवश्यकताएँ

कैमरा ढाँचा सख्त हो रहा है

API1 के लिए वास्तुशिल्प परिवर्तन

HAL3, जहां कैमरा सेवा प्रक्रियाओं के बीच बफ़र्स को पास करने के लिए बफ़रक्यू का उपयोग करती है, कोई विक्रेता अद्यतन आवश्यक नहीं है।
चित्र 1. HAL3 पर API1 में Android 7.0 कैमरा और मीडिया स्टैक
HAL1, जो वीडियो बफ़र्स में मेटाडेटा पास करने का समर्थन करता है, विक्रेताओं को kMetadataBufferTypeNativeHandleSource का उपयोग करने के लिए HAL को अपडेट करना होगा। ( kMetadataBufferTypeCameraSource अब Android 7.0 में समर्थित नहीं है।)
चित्र 2. HAL1 पर API1 में Android 7.0 कैमरा और मीडिया स्टैक

API2 के लिए वास्तुशिल्प परिवर्तन

HAL1 कैमरा सेवा के स्थानांतरण से प्रभावित नहीं है, और कोई विक्रेता अद्यतन आवश्यक नहीं है।
HAL3 प्रभावित है , लेकिन कोई विक्रेता अद्यतन आवश्यक नहीं है:
चित्र 3. HAL3 पर API2 में Android 7.0 कैमरा और मीडिया स्टैक

अतिरिक्त जरूरतें

सामान्य। Devices require additional bandwidth due to IPC, which may affect time-sensitive camera use cases such as high-speed video recording. Vendors can measure actual impact by running android.hardware.camera2.cts.PerformanceTest and the Google Camera app for 120/240 FPS high-speed video recording. Devices also require a small amount of additional RAM to create the new process.
Pass metadata in video buffers ( HAL1 only ). If HAL1 stores metadata instead of real YUV frame data in video buffers, the HAL must use kMetadataBufferTypeNativeHandleSource as the metadata buffer type and pass VideoNativeHandleMetadata in video buffers. ( kMetadataBufferTypeCameraSource is no longer supported on Android 7.0.) With VideoNativeHandleMetadata , camera and media frameworks are able to pass the video buffers between processes by serializing and deserializing the native handles properly.
Buffer handle address doesn't always store the same buffer ( HAL3 only ). For each capture request, HAL3 gets addresses of buffer handles. HAL can't use the addresses to identify buffers because the addresses may store another buffer handle after HAL returns the buffer. You must update the HAL to use buffer handles to identify the buffers. For example, HAL receives a buffer handle address A, which stores buffer handle A. After HAL returns buffer handle A, buffer handle address A may store buffer handle B next time the HAL receives it.
Update SELinux policies for cameraserver. If device-specific SELinux policies give mediaserver permissions to run the camera, you must update the SELinux policies to give cameraserver proper permissions. We discourage replicating the mediaserver's SELinux policies for cameraserver (as mediaserver and cameraserver generally require different resources in the system). Cameraserver should have only the permissions needed to perform camera functionalities and any unnecessary camera-related permissions in mediaserver should be removed.
Separation between Camera HAL and cameraserver. Android 8.0 and higher additionally separate the binderized Camera HAL in a process different from cameraserver. IPC goes through HIDL-defined interfaces.

मान्यकरण

For all devices that include a camera and run Android 7.0, verify the implementation by running Android 7.0 CTS. Although Android 7.0 doesn't include new CTS tests that verify camera service changes, existing CTS tests fail if you haven't made the updates indicated above.

For all devices that include a camera and run Android 8.0 and higher, verify the vendor implementation by running VTS.

Camera HAL version history

For a list of tests available for evaluating the Android Camera HAL, see the Camera HAL Testing Checklist .

Android 10

Android 10 introduces the following updates.

Camera API

Multi-camera improvements that allow physical cameras to be used individually or through corresponding logical cameras by hiding physical camera IDs. See Multi-Camera Support .
Ability to check whether a particular session configuration is supported without the performance overhead of creating a new session. See CameraDevice .
Ability to retrieve recommended stream configurations for a given use case to make the client more power efficient and performant. See getRecommendedStreamConfigurationMap .
Support for the depth JPEG image format . For further details, see the Dynamic Depth specification .
Support for the HEIC Image format . See HEIF Imaging .
Privacy improvements. Certain keys are required for the client to have CAMERA permissions before they can be retrieved from CameraCharacteristics . See getKeysNeedingPermission .

Camera HAL

The following Camera HAL versions are updated in Android 10.

3.5

ICameraDevice

getPhysicalCameraCharacteristics : The static camera information for a physical camera ID backing a logical camera device. See Multi-Camera Support .
isStreamCombinationSupported : This method supports a public API that helps clients query if a session configuration is supported. See API to query stream combinations .

ICameraDeviceSession

isReconfigurationNeeded : Method that tells the camera framework whether complete stream reconfiguration is required for possible new session parameter values. This helps avoid unnecessary camera reconfiguration delays. See Session reconfiguration query .
HAL buffer management APIs : These APIs allow the camera HAL to request buffers from the camera framework only when required instead of coupling each capture request with its associated buffers throughout the camera pipeline, resulting in potentially significant memory savings.
- signalStreamFlush : Signals to the HAL that the camera service is about to perform configureStreams_3_5 and that the HAL must return all buffers of designated streams.
- configureStreams_3_5 : Similar to ICameraDevice3.4.configureStreams , but in addition, the streamConfigCounter counter is provided to check for a race condition between the configureStreams_3_5 and signalStreamFlush calls.

Updates to ICameraDeviceCallback :

requestStreamBuffers : Synchronous callback that the camera HAL calls to ask the camera server for buffers. See requestStreamBuffers .
returnStreamBuffers : Synchronous callback for the camera HAL to return output buffers to the camera server. See returnStreamBuffers .

3.4

The following keys are added to camera metadata in Android 10.

Image formats
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
- ANDROID_SCALER_AVAILABLE_FORMATS_Y8
Camera metadata tags
- 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
Values for the ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT key
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
Available dynamic depth stream configurations
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
Available HEIC stream configurations
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Camera module

The following camera module versions are updated in Android 10.

2.5

Adds the notifyDeviceStateChange method for devices to notify the camera HAL when physical changes, such as folding, affect camera and routing.

2.4

Devices launching with API level 29 or higher MUST report true for isTorchModeSupported .

Android 9

The Android 9 release introduces the following updates to the camera API2 and HAL interface.

Camera API

Introduces the multi-camera API to better support devices with multiple cameras facing in the same direction, enabling features such as bokeh and seamless zoom. This allows apps to view multiple cameras on a device as one logical unit (logical camera). Capture requests can also be sent to individual camera devices encompassed by one logical camera. See Multi-Camera Support .
Introduces session parameters. Session parameters are a subset of the available capture parameters that can cause severe processing delays when modified. These costs can be mitigated if clients pass their initial values during capture session initialization. See Session Parameters .
Adds optical stabilization (OIS) data keys for app-level stabilization and effects. See STATISTICS_OIS_SAMPLES .
Adds external flash support. See CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
Adds a motion tracking intent in CAPTURE_INTENT . See CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
Deprecates LENS_RADIAL_DISTORTION and adds LENS_DISTORTION in its place.
Adds distortion correction modes in CaptureRequest . See DISTORTION_CORRECTION_MODE .
Adds support for external USB/UVC cameras on supported devices. See INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Camera HAL

3.4

Updates to ICameraDeviceSession

configureStreams_3_4 : Adds support for sessionParameters and logical cameras.
processCaptureRequest_3_4 : Adds support for including physical camera IDs in stream structure.

Updates to ICameraDeviceCallback

processCaptureResult_3_4 : Adds physical camera metadata in capture results.

3.3

The following keys are added to camera metadata in Android 9.

Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
Camera metadata tags
- 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

The Android 8.0 release introduces Treble. With Treble, vendor Camera HAL implementations must be binderized . Android 8.0 also contains these key enhancements to the Camera service:

Shared surfaces: Enable multiple surfaces sharing the same OutputConfiguration
System API for custom camera modes
onCaptureQueueEmpty

See the sections below for more information on these features.

Shared surfaces

This feature enables only one set of buffers to drive two outputs, such as preview and video encoding, which lowers power and memory consumption. To support this feature, device manufacturers need to ensure their camera HAL and gralloc HAL implementations can create gralloc buffers that are used by multiple different consumers (such as the hardware composer/GPU and the video encoder), instead of just one consumer. The camera service passes the consumer usage flags to the camera HAL and the gralloc HAL; they need to either allocate the right kinds of buffers, or the camera HAL needs to return an error that this combination of consumers isn't supported.

See the enableSurfaceSharing developer documentation for additional details.

System API for custom camera modes

The public camera API defines two operating modes: normal and constrained high-speed recording. They have fairly different semantics; for example, high-speed mode is limited to at most two specific outputs at once. Various OEMs have expressed interest in defining other custom modes for hardware-specific capabilities. Under the hood, the mode is just an integer passed to configure_streams . See: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

This feature includes a system API call that OEM camera apps can use to enable a custom mode. These modes must start at integer value 0x8000 to avoid conflicting with future modes added to the public API.

To support this feature, OEMs merely need to add the new mode to their HAL, triggered by this integer passed to the HAL on configure_streams, and then have their custom camera app use the system API.

The method name is android.hardware.camera2.CameraDevice#createCustomCaptureSession . See: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

The purpose of this API is to reduce the latency of control changes like zoom by keeping the request queue as empty as possible. onCaptureQueueEmpty requires no HAL work; it was purely a framework-side addition. Applications that want to take advantage of it need to add a listener to that callback and respond appropriately. Generally that's by sending another capture request to the camera device.

Camera HIDL interface

The Camera HIDL interface is a complete overhaul of the Camera HAL interface that uses stable HIDL-defined APIs. All features and camera capabilities introduced in the most recent legacy versions 3.4 and 2.4 (for the camera module) are also part of the HIDL definitions.

3.4

Minor additions to supported metadata and changes to data_space support:

Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if RAW_OPAQUE format is supported.
Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as mandatory if any RAW format is supported.
Switch camera3_stream_t data_space field to a more flexible definition, using the version 0 definition of dataspace encoding.
General metadata additions which are available to use for HALv3.2 or newer:
- 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

Minor revision of expanded-capability HAL:

OPAQUE and YUV reprocessing API updates.
Basic support for depth output buffers.
Addition of data_space field to camera3_stream_t .
Addition of rotation field to camera3_stream_t .
Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t .

3.2

Minor revision of expanded-capability HAL:

Deprecates get_metadata_vendor_tag_ops . Use get_vendor_tag_ops in camera_common.h instead.
Deprecates register_stream_buffers . All gralloc buffers provided by framework to HAL in process_capture_request may be new at any time.
Add partial result support. process_capture_result may be called multiple times with a subset of the available results before the full result is available.
Add manual template to camera3_request_template . Applications may use this template to control the capture settings directly.
Rework the bidirectional and input stream specifications.
Change the input buffer return path. The buffer is returned in process_capture_result instead of process_capture_request .

3.1

Minor revision of expanded-capability HAL:

configure_streams passes consumer usage flags to the HAL.
flush call to drop all in-flight requests/buffers as fast as possible.

3.0

First revision of expanded-capability HAL:

Major version change since the ABI is completely different. No change to the required hardware capabilities or operational model from 2.0.
Reworked input request and stream queue interfaces: Framework calls into HAL with next request and stream buffers already dequeued. Sync framework support is included, necessary for efficient implementations.
Moved triggers into requests, most notifications into results.
Consolidated all callbacks into framework into one structure, and all setup methods into a single initialize() call.
Made stream configuration into a single call to simplify stream management. Bidirectional streams replace the STREAM_FROM_STREAM construct.
Limited mode semantics for older/limited hardware devices.

2.0

Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:

Sufficient for implementing existing android.hardware.Camera API.
Allows for ZSL queue in camera service layer.
Not tested for any new features such as manual capture control, Bayer RAW capture, reprocessing of RAW data, etc.

1.0

Initial Android camera HAL (Android 4.0) [camera.h]:

Converted from C++ CameraHardwareInterface abstraction layer.
Supports android.hardware.Camera API.

Camera module version history

This section contains module versioning information for the Camera hardware module, based on camera_module_t.common.module_api_version . The two most significant hex digits represent the major version, and the two least significant represent the minor version.

2.4

This camera module version adds the following API changes:

Torch mode support. The framework can turn on torch mode for any camera device that has a flash unit, without opening a camera device. The camera device has a higher priority accessing the flash unit than the camera module; opening a camera device turns off the torch if it had been enabled through the module interface. When there are any resource conflicts, such as open() is called to open a camera device, the camera HAL module must notify the framework through the torch mode status callback that the torch mode has been turned off.
External camera (for example, USB hot-plug camera) support. The API updates specify the camera static info is available only when camera is connected and ready to use for external hot-plug cameras. Calls to get static info are invalid calls when camera status isn't CAMERA_DEVICE_STATUS_PRESENT . The framework counts solely on device status change callbacks to manage the available external camera list.
Camera arbitration hints. Adds support for explicitly indicating the number of camera devices that can be simultaneously opened and used. To specify valid combinations of devices, the resource_cost and conflicting_devices fields should always be set in the camera_info structure returned by the get_camera_info call.
Module initialization method. Called by the camera service after the HAL module is loaded to allow for one-time initialization of the HAL. It is called before any other module methods are invoked.

2.3

This camera module version adds open legacy camera HAL device support. The framework can use it to open the camera device as lower device HAL version HAL device if the same device can support multiple device API versions. The standard hardware module open call ( common.methods->open ) continues to open the camera device with the latest supported version, which is also the version listed in camera_info_t.device_version .

2.2

This camera module version adds vendor tag support from the module, and deprecates the old vendor_tag_query_ops that were previously only accessible with a device open.

2.1

This camera module version adds support for asynchronous callbacks to the framework from the camera HAL module, which is used to notify the framework about changes to the camera module state. Modules that provide a valid set_callbacks() method must report at least this version number.

2.0

Camera modules that report this version number implement the second version of the camera module HAL interface. Camera devices openable through this module may support either version 1.0 or version 2.0 of the camera device HAL interface. The device_version field of camera_info is always valid; the static_camera_characteristics field of camera_info is valid if the device_version field is 2.0 or higher.

1.0

Camera modules that report these version numbers implement the initial camera module HAL interface. All camera devices openable through this module support only version 1 of the camera device HAL. The device_version and static_camera_characteristics fields of camera_info aren't valid. Only the android.hardware.Camera API can be supported by this module and its devices.