پشتیبانی از نسخه دوربین

این صفحه تفاوت‌های نسخه در دوربین‌های HAL، API و تست‌های مجموعه تست سازگاری (CTS) مرتبط را توضیح می‌دهد. همچنین چندین تغییر معماری ایجاد شده برای سخت‌تر کردن و ایمن‌سازی چارچوب دوربین در اندروید 7.0، تغییر به Treble در اندروید 8.0، و به‌روزرسانی‌هایی را که فروشندگان باید برای پشتیبانی از این تغییرات در اجرای دوربین خود انجام دهند، پوشش می‌دهد.

اصطلاحات

در این صفحه از اصطلاحات زیر استفاده می شود:

دوربین API1

چارچوب دوربین در سطح برنامه در دستگاه‌های Android نسخه ۴.۴ و پایین‌تر، از طریق کلاس android.hardware.Camera در معرض دید قرار می‌گیرد.

دوربین API2

چارچوب دوربین سطح برنامه در دستگاه‌های Android نسخه 5.0 و بالاتر، از طریق بسته android.hardware.camera2 در معرض دید قرار می‌گیرد.

دوربین HAL

لایه ماژول دوربین که توسط فروشندگان SoC پیاده سازی شده است. چارچوب های عمومی در سطح برنامه در بالای دوربین HAL ساخته شده اند.

دوربین HAL3.1

نسخه دوربین دستگاه HAL با اندروید 4.4 منتشر شد.

دوربین HAL3.2

نسخه دوربین دستگاه HAL با اندروید 5.0 منتشر شد.

دوربین API1 CTS

مجموعه ای از تست های CTS دوربین که در بالای دوربین API1 اجرا می شوند.

دوربین API2 CTS

مجموعه دیگری از تست‌های CTS دوربین که در بالای دوربین API2 اجرا می‌شوند.

سه گانه

پیاده‌سازی فروشنده (نرم‌افزار سطح پایین‌تر و ویژه دستگاه را که توسط سازندگان سیلیکون نوشته شده است) از چارچوب سیستم عامل Android از طریق یک رابط فروشنده جدید جدا می‌کند.

HIDL

زبان تعریف رابط HAL با Treble معرفی شد و برای مشخص کردن رابط بین HAL و کاربران آن استفاده شد.

VTS

مجموعه تست فروشنده در کنار Treble معرفی شد.

API های دوربین

اندروید شامل API های دوربین زیر است.

دوربین API1

Android 5.0 Camera API1 منسوخ شده است، که با تمرکز توسعه پلتفرم جدید بر Camera API2، به تدریج حذف می شود. با این حال، دوره حذف تدریجی طولانی خواهد بود و نسخه‌های اندرویدی تا مدتی از برنامه‌های Camera API1 پشتیبانی خواهند کرد. به طور خاص، پشتیبانی برای موارد زیر ادامه دارد:

• رابط های دوربین API1 برای برنامه ها. برنامه‌های دوربین ساخته‌شده در بالای Camera API1 باید مانند دستگاه‌هایی که نسخه‌های پایین‌تر اندروید دارند کار کنند.
• نسخه های دوربین HAL. شامل پشتیبانی از دوربین HAL1.0.

دوربین API2

چارچوب Camera API2 کنترل دوربین سطح پایین‌تری را در اختیار برنامه قرار می‌دهد، از جمله جریان‌های پیاپی/جریان‌گذاری کارآمد صفر کپی و کنترل‌های نوردهی، افزایش، افزایش تعادل رنگ سفید، تبدیل رنگ، حذف نویز، شفاف‌سازی و موارد دیگر. برای جزئیات، نمای کلی ویدیوی Google I/O را تماشا کنید.

اندروید 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 (اما نه همه) پشتیبانی می‌کنند و باید از دوربین HAL 3.2 یا بالاتر استفاده کنند.
• FULL : این دستگاه‌ها از تمام قابلیت‌های اصلی Camera API2 پشتیبانی می‌کنند و باید از دوربین HAL 3.2 یا بالاتر و اندروید 5.0 یا بالاتر استفاده کنند.
• LEVEL_3 : این دستگاه‌ها از پردازش مجدد YUV و ضبط تصویر RAW به همراه تنظیمات جریان خروجی اضافی پشتیبانی می‌کنند.
• EXTERNAL : این دستگاه ها مشابه دستگاه های LIMITED با برخی استثناها هستند. به عنوان مثال، برخی از اطلاعات حسگر یا لنز ممکن است گزارش نشوند یا نرخ فریم پایدار کمتری داشته باشند. این سطح برای دوربین های خارجی مانند وب کم USB استفاده می شود.

قابلیت‌های فردی از طریق ویژگی android.request.availableCapabilities در رابط‌های Camera API2 آشکار می‌شوند. دستگاه‌های FULL به قابلیت‌های MANUAL_SENSOR و MANUAL_POST_PROCESSING از جمله موارد دیگر نیاز دارند. قابلیت RAW حتی برای دستگاه های FULL اختیاری است. دستگاه های LIMITED می توانند هر زیر مجموعه ای از این قابلیت ها را تبلیغ کنند، از جمله هیچ کدام. با این حال، قابلیت BACKWARD_COMPATIBLE همیشه باید تعریف شود.

سطح سخت‌افزار پشتیبانی‌شده دستگاه، و همچنین قابلیت‌های خاص Camera API2 که از آن پشتیبانی می‌کند، به‌عنوان پرچم‌های ویژگی زیر در دسترس هستند تا به Google Play اجازه فیلتر کردن برنامه‌های دوربین دوربین 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

الزامات CTS

دستگاه‌هایی که Android نسخه 5.0 و بالاتر دارند باید آزمایش‌های دوربین API1 CTS، Camera API2 CTS و CTS Verifier را پشت سر بگذارند.

دستگاه‌هایی که فاقد اجرای Camera HAL3.2 هستند و قادر به پشتیبانی از رابط‌های کامل Camera API2 نیستند، همچنان باید تست‌های Camera API2 CTS را پشت سر بگذارند. با این حال، دستگاه در حالت Camera API2 LEGACY اجرا می‌شود (که در آن تماس‌های Camera API2 به صورت مفهومی با تماس‌های Camera API1 نگاشت می‌شوند) بنابراین هر آزمایش CTS دوربین API2 مربوط به ویژگی‌ها یا قابلیت‌های فراتر از Camera API1 به‌طور خودکار نادیده گرفته می‌شود.

در دستگاه‌های قدیمی، آزمایش‌های Camera API2 CTS که اجرا می‌شوند از رابط‌ها و قابلیت‌های عمومی Camera API1 بدون نیاز جدید استفاده می‌کنند. اشکالاتی که در معرض دید قرار می‌گیرند (و باعث خرابی دوربین API2 CTS می‌شوند) اشکالاتی هستند که از قبل در دوربین HAL موجود دستگاه وجود دارند و بنابراین توسط برنامه‌های Camera API1 موجود پیدا می‌شوند. ما انتظار بسیاری از باگ‌های این ماهیت را نداریم (با این حال، برای گذراندن تست‌های Camera API2 CTS باید چنین اشکالاتی برطرف شود).

الزامات VTS

دستگاه‌های دارای Android نسخه ۸.۰ و بالاتر با اجرای HAL binderized باید تست‌های Camera VTS را پشت سر بگذارند.

سخت شدن چارچوب دوربین

برای سخت‌تر کردن رسانه و امنیت چارچوب دوربین، Android 7.0 سرویس دوربین را از سرور رسانه خارج می‌کند. با شروع Android 8.0، هر دوربین HAL بایندر شده در فرآیندی جدا از سرویس دوربین اجرا می‌شود. ممکن است فروشندگان بسته به نسخه های API و HAL در حال استفاده، نیاز به تغییر در HAL دوربین داشته باشند. بخش‌های زیر تغییرات معماری در AP1 و AP2 برای HAL1 و HAL3 و همچنین الزامات کلی را شرح می‌دهد.

تغییرات معماری برای API1

ضبط ویدیوی API1 ممکن است دوربین و رمزگذار ویدیو را در یک فرآیند زنده فرض کند. هنگام استفاده از API1 در:

• HAL3، جایی که سرویس دوربین از BufferQueue برای عبور بافرها بین فرآیندها استفاده می کند، به روز رسانی فروشنده لازم نیست .

  

  شکل 1. دوربین اندروید 7.0 و پشته رسانه در API1 در HAL3

• HAL1 که از ارسال ابرداده در بافرهای ویدیویی پشتیبانی می‌کند، فروشندگان باید HAL را برای استفاده از kMetadataBufferTypeNativeHandleSource به‌روزرسانی کنند. ( kMetadataBufferTypeCameraSource دیگر در Android 7.0 پشتیبانی نمی‌شود.)

  

  شکل 2. دوربین اندروید 7.0 و پشته رسانه در API1 در HAL1

تغییرات معماری برای API2

برای API2 در HAL1 یا HAL3، BufferQueue بافرها را پاس می‌کند تا این مسیرها به کار خود ادامه دهند. معماری Android 7.0 برای API2 در:

• HAL1 تحت تأثیر حرکت دوربین سرویس قرار نمی گیرد و به روز رسانی فروشنده لازم نیست .
• HAL3 تحت تأثیر قرار گرفته است ، اما به‌روزرسانی فروشنده لازم نیست :

  

  شکل 3. دوربین اندروید 7.0 و پشته رسانه در API2 در HAL3

الزامات اضافی

تغییرات معماری ایجاد شده برای سخت شدن رسانه و امنیت چارچوب دوربین شامل الزامات دستگاه اضافی زیر است.

• ژنرال دستگاه ها به دلیل IPC به پهنای باند اضافی نیاز دارند، که ممکن است بر موارد استفاده از دوربین حساس به زمان مانند ضبط ویدیوی با سرعت بالا تأثیر بگذارد. فروشندگان می توانند تأثیر واقعی را با اجرای android.hardware.camera2.cts.PerformanceTest و برنامه دوربین Google برای ضبط ویدیوی پرسرعت 120/240 FPS اندازه گیری کنند. دستگاه ها همچنین به مقدار کمی رم اضافی برای ایجاد فرآیند جدید نیاز دارند.
• ارسال فراداده در بافرهای ویدیویی ( فقط HAL1 ). اگر HAL1 متادیتا را به جای داده‌های فریم YUV واقعی در بافرهای ویدیو ذخیره می‌کند، HAL باید از kMetadataBufferTypeNativeHandleSource به‌عنوان نوع بافر فراداده استفاده کند و VideoNativeHandleMetadata در بافرهای ویدیویی ارسال کند. ( kMetadataBufferTypeCameraSource دیگر در Android 7.0 پشتیبانی نمی‌شود.) با VideoNativeHandleMetadata ، چارچوب‌های دوربین و رسانه می‌توانند با سریال‌سازی و سریال‌زدایی صحیح دسته‌های اصلی، بافرهای ویدیویی را بین فرآیندها منتقل کنند.
• آدرس دسته بافر همیشه یک بافر را ذخیره نمی کند ( فقط HAL3 ). برای هر درخواست ضبط، HAL3 آدرس دسته‌های بافر را دریافت می‌کند. HAL نمی‌تواند از آدرس‌ها برای شناسایی بافرها استفاده کند، زیرا آدرس‌ها ممکن است دسته بافر دیگری را پس از بازگشت HAL بافر ذخیره کنند. شما باید HAL را به روز کنید تا از دسته های بافر برای شناسایی بافرها استفاده کنید. به عنوان مثال، HAL یک آدرس دسته بافر A را دریافت می کند، که دسته بافر A را ذخیره می کند. پس از اینکه HAL دسته بافر A را برگرداند، آدرس دسته بافر A ممکن است دسته بافر B را دفعه بعد که HAL آن را دریافت کند، ذخیره کند.
• سیاست های SELinux را برای سرور دوربین به روز کنید. اگر خط‌مشی‌های SELinux مخصوص دستگاه، مجوزهای سرور مدیا را برای اجرای دوربین می‌دهند، باید خط‌مشی‌های SELinux را به‌روزرسانی کنید تا به سرور دوربین مجوزهای مناسب بدهید. ما از تکرار خط‌مشی‌های SELinux سرور رسانه برای سرور دوربین خودداری می‌کنیم (زیرا سرور رسانه و سرور دوربین معمولاً به منابع مختلفی در سیستم نیاز دارند). سرور دوربین باید فقط مجوزهای لازم برای انجام عملکردهای دوربین را داشته باشد و هر گونه مجوز غیر ضروری مربوط به دوربین در سرور رسانه باید حذف شود.
• جداسازی دوربین HAL و سرور دوربین. Android 8.0 و بالاتر علاوه بر این، دوربین HAL را در فرآیندی متفاوت از سرور دوربین جدا می کند. IPC از طریق رابط های تعریف شده توسط HIDL می رود.

اعتبار سنجی

برای همه دستگاه‌هایی که دارای دوربین هستند و Android 7.0 را اجرا می‌کنند، با اجرای Android 7.0 CTS اجرای آن را تأیید کنید. اگرچه Android 7.0 شامل تست‌های CTS جدید برای تأیید تغییرات سرویس دوربین نمی‌شود، اما اگر به‌روزرسانی‌های ذکر شده در بالا را انجام نداده باشید، آزمایش‌های CTS موجود با شکست مواجه می‌شوند.

برای همه دستگاه‌هایی که دارای دوربین هستند و اندروید 8.0 و بالاتر دارند، با اجرای VTS، اجرای فروشنده را تأیید کنید.

تاریخچه نسخه دوربین HAL

برای لیستی از تست‌های موجود برای ارزیابی دوربین Android HAL، به چک لیست تست دوربین HAL مراجعه کنید.

اندروید 10

اندروید 10 به روز رسانی های زیر را معرفی می کند.

دوربین API

• بهبودهای چند دوربینی که امکان استفاده از دوربین های فیزیکی را به صورت جداگانه یا از طریق دوربین های منطقی مربوطه با پنهان کردن شناسه های فیزیکی دوربین فراهم می کند. به پشتیبانی از چند دوربین مراجعه کنید.
• امکان بررسی اینکه آیا یک پیکربندی جلسه خاص بدون سربار عملکرد ایجاد یک جلسه جدید پشتیبانی می شود یا خیر. CameraDevice را ببینید.
• امکان بازیابی تنظیمات جریان توصیه شده برای یک مورد خاص برای افزایش کارایی و کارایی مشتری. getRecommendedStreamConfigurationMap ببینید.
• پشتیبانی از فرمت تصویر با عمق JPEG برای جزئیات بیشتر، مشخصات دینامیک عمق را ببینید.
• پشتیبانی از فرمت تصویر HEIC به تصویربرداری HEIF مراجعه کنید.
• بهبود حریم خصوصی کلیدهای خاصی برای برخورداری مشتری از مجوزهای CAMERA قبل از بازیابی از CameraCharacteristics لازم است. به getKeysNeedingPermission مراجعه کنید.

دوربین HAL

نسخه های دوربین HAL زیر در اندروید 10 به روز شده اند.

3.5

ICameraDevice

• getPhysicalCameraCharacteristics : اطلاعات ثابت دوربین برای شناسه دوربین فیزیکی که پشتیبان یک دستگاه دوربین منطقی است. به پشتیبانی از چند دوربین مراجعه کنید.
• isStreamCombinationSupported : این روش از یک API عمومی پشتیبانی می‌کند که به مشتریان کمک می‌کند در صورت پشتیبانی از پیکربندی جلسه، پرس و جو کنند. به API برای پرس و جو از ترکیبات جریان مراجعه کنید.

ICameraDeviceSession

• isReconfigurationNeeded : روشی که به چارچوب دوربین می گوید که آیا پیکربندی مجدد جریان برای مقادیر پارامترهای جدید جلسه احتمالی لازم است یا خیر. این به جلوگیری از تاخیرهای غیرضروری پیکربندی مجدد دوربین کمک می کند. به جستجوی پیکربندی مجدد جلسه مراجعه کنید.
• APIهای مدیریت بافر HAL : این APIها به HAL دوربین اجازه می‌دهند که به جای جفت کردن هر درخواست ضبط با بافرهای مرتبط در سراسر خط لوله دوربین، بافرهایی را از چارچوب دوربین درخواست کند، که منجر به صرفه‌جویی قابل توجهی در حافظه می‌شود.
  • signalStreamFlush : به HAL سیگنال می دهد که سرویس دوربین در شرف انجام configureStreams_3_5 است و اینکه HAL باید تمام بافرهای جریان های تعیین شده را برگرداند.
  • configureStreams_3_5 : مشابه ICameraDevice3.4.configureStreams ، اما علاوه بر این، شمارنده streamConfigCounter برای بررسی شرایط مسابقه بین تماس‌های configureStreams_3_5 و signalStreamFlush ارائه شده است.

به‌روزرسانی‌های ICameraDeviceCallback :

• requestStreamBuffers : پاسخ به تماس همزمانی که دوربین HAL برای درخواست بافر از سرور دوربین فراخوانی می کند. به requestStreamBuffers مراجعه کنید.
• returnStreamBuffers : پاسخ به تماس همزمان برای دوربین HAL برای بازگرداندن بافرهای خروجی به سرور دوربین. returnStreamBuffers را ببینید.

3.4

کلیدهای زیر به ابرداده دوربین در اندروید 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

• روش notifyDeviceStateChange را برای دستگاه‌ها اضافه می‌کند تا زمانی که تغییرات فیزیکی، مانند تا شدن، دوربین و مسیریابی را تحت تأثیر قرار می‌دهد، HAL دوربین را مطلع کند.

2.4

• دستگاه‌هایی که با سطح API 29 یا بالاتر راه‌اندازی می‌شوند، باید برای isTorchModeSupported true گزارش دهند.

اندروید 9

نسخه اندروید 9 به روز رسانی های زیر را برای دوربین API2 و رابط HAL معرفی می کند.

دوربین API

• API چند دوربینی را برای پشتیبانی بهتر از دستگاه‌هایی که چندین دوربین در یک جهت دارند، معرفی می‌کند و ویژگی‌هایی مانند بوکه و زوم بدون درز را فعال می‌کند. این به برنامه ها اجازه می دهد تا چندین دوربین را در یک دستگاه به عنوان یک واحد منطقی (دوربین منطقی) مشاهده کنند. درخواست‌های عکسبرداری همچنین می‌توانند به دستگاه‌های دوربین جداگانه که توسط یک دوربین منطقی احاطه شده‌اند ارسال شوند. به پشتیبانی از چند دوربین مراجعه کنید.
• پارامترهای جلسه را معرفی می کند. پارامترهای جلسه زیرمجموعه‌ای از پارامترهای ضبط موجود هستند که در صورت تغییر می‌توانند باعث تأخیر شدید پردازش شوند. این هزینه ها را می توان کاهش داد اگر کلاینت ها مقادیر اولیه خود را در طول اولیه سازی جلسه ضبط ارسال کنند. به پارامترهای جلسه مراجعه کنید.
• کلیدهای داده تثبیت کننده نوری (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 را ببینید.
• پشتیبانی از دوربین های خارجی USB/UVC را در دستگاه های پشتیبانی شده اضافه می کند. INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL را ببینید.

دوربین HAL

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 Treble را معرفی می کند. با Treble، پیاده‌سازی‌های دوربین HAL فروشنده باید بایندر شوند. Android 8.0 همچنین شامل این پیشرفت‌های کلیدی در سرویس دوربین است:

• سطوح مشترک: چندین سطح را فعال کنید که OutputConfiguration یکسان را به اشتراک بگذارند
• API سیستم برای حالت های دوربین سفارشی
• onCaptureQueueEmpty

برای اطلاعات بیشتر در مورد این ویژگی ها به بخش های زیر مراجعه کنید.

سطوح مشترک

این ویژگی تنها یک مجموعه از بافرها را قادر می‌سازد تا دو خروجی مانند پیش‌نمایش و کدگذاری ویدیو را هدایت کند که مصرف انرژی و حافظه را کاهش می‌دهد. برای پشتیبانی از این ویژگی، سازندگان دستگاه باید اطمینان حاصل کنند که پیاده‌سازی HAL و gralloc HAL دوربین آنها می‌توانند به جای یک مصرف‌کننده، بافرهای gralloc را ایجاد کنند که توسط چندین مصرف‌کننده مختلف (مانند آهنگساز/GPU و رمزگذار ویدیو) استفاده می‌شود. سرویس دوربین پرچم های استفاده مصرف کننده را به دوربین HAL و gralloc HAL ارسال می کند. آنها باید یا نوع مناسبی از بافرها را تخصیص دهند، یا دوربین HAL باید خطایی را نشان دهد که این ترکیب از مصرف کنندگان پشتیبانی نمی شود.

برای جزئیات بیشتر به مستندات توسعه دهنده enableSurfaceSharing مراجعه کنید.

API سیستم برای حالت های دوربین سفارشی

API دوربین عمومی دو حالت عملیاتی را تعریف می کند: ضبط معمولی و محدود با سرعت بالا. آنها معنای نسبتاً متفاوتی دارند. به عنوان مثال، حالت پرسرعت حداکثر به دو خروجی خاص در یک زمان محدود می شود. OEM های مختلف به تعریف حالت های سفارشی دیگر برای قابلیت های سخت افزاری خاص ابراز علاقه کرده اند. در زیر هود، حالت فقط یک عدد صحیح است که به configure_streams منتقل می شود. ببینید: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

این ویژگی شامل یک تماس API سیستم است که برنامه‌های دوربین OEM می‌توانند از آن برای فعال کردن حالت سفارشی استفاده کنند. این حالت‌ها باید با مقدار صحیح 0x8000 شروع شوند تا از تداخل با حالت‌های آینده اضافه شده به API عمومی جلوگیری شود.

برای پشتیبانی از این ویژگی، OEM ها فقط باید حالت جدید را به HAL خود اضافه کنند، که توسط این عدد صحیح به HAL در configure_streams ارسال می شود، و سپس برنامه دوربین سفارشی آنها از API سیستم استفاده کند.

نام روش android.hardware.camera2.CameraDevice#createCustomCaptureSession است. ببینید: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

توجه: در نسخه اندروید 8.1، برای دسترسی به این API، برنامه ها باید از قبل روی تصویر سیستم نصب شده باشند.

onCaptureQueueEmpty

هدف این API کاهش تأخیر تغییرات کنترل مانند زوم با خالی نگه داشتن صف درخواست تا حد امکان است. onCaptureQueueEmpty به هیچ کار HAL نیاز ندارد. این صرفاً یک افزودنی در سمت چارچوب بود. برنامه‌هایی که می‌خواهند از آن بهره ببرند، باید شنونده‌ای به آن تماس اضافه کنند و به طور مناسب پاسخ دهند. معمولاً با ارسال یک درخواست عکسبرداری دیگر به دستگاه دوربین است.

رابط HIDL دوربین

رابط دوربین HIDL یک بازسازی کامل از رابط دوربین HAL است که از API های تعریف شده با 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

بازبینی جزئی HAL با قابلیت توسعه یافته:

• به روز رسانی OPAQUE و YUV پردازش مجدد API.
• پشتیبانی اولیه از بافرهای خروجی عمق.
• افزودن فیلد data_space به camera3_stream_t .
• افزودن فیلد چرخش به camera3_stream_t .
• اضافه شدن حالت عملیات پیکربندی جریان camera3 به camera3_stream_configuration_t .

3.2

بازبینی جزئی HAL با قابلیت توسعه یافته:

• get_metadata_vendor_tag_ops را منسوخ می کند. به جای آن از get_vendor_tag_ops در camera_common.h استفاده کنید.
• register_stream_buffers را منسوخ می کند. همه بافرهای gralloc ارائه شده توسط فریمورک به HAL در process_capture_request ممکن است در هر زمانی جدید باشند.
• پشتیبانی از نتیجه جزئی را اضافه کنید. process_capture_result ممکن است چندین بار با زیرمجموعه ای از نتایج موجود قبل از اینکه نتیجه کامل در دسترس باشد فراخوانی شود.
• قالب دستی را به camera3_request_template اضافه کنید. برنامه‌ها ممکن است از این الگو برای کنترل مستقیم تنظیمات ضبط استفاده کنند.
• مشخصات دو طرفه و جریان ورودی را دوباره کار کنید.
• مسیر بازگشت بافر ورودی را تغییر دهید. بافر به جای process_capture_request در process_capture_result برگردانده می شود.

3.1

بازبینی جزئی HAL با قابلیت توسعه یافته:

• configure_streams پرچم های استفاده مصرف کننده را به HAL ارسال می کند.
• برای رها کردن تمام درخواست‌ها/بافرهای حین پرواز در سریع‌ترین زمان ممکن، تماس را هموار کنید.

3.0

اولین بازبینی HAL با قابلیت توسعه یافته:

• تغییرات عمده نسخه از ABI کاملا متفاوت است. هیچ تغییری در قابلیت های سخت افزاری یا مدل عملیاتی مورد نیاز از 2.0 وجود ندارد.
• درخواست ورودی مجدد و واسط‌های صف جریان: فراخوانی چارچوب به HAL با درخواست بعدی و بافرهای جریانی که قبلاً از صف خارج شده‌اند. پشتیبانی از چارچوب همگام‌سازی گنجانده شده است که برای اجرای کارآمد ضروری است.
• محرک‌ها به درخواست‌ها، بیشتر اعلان‌ها به نتایج منتقل شدند.
• تمام callbackها را در چارچوب در یک ساختار، و تمام متدهای راه اندازی را در یک فراخوانی initialize() ادغام کرد.
• پیکربندی جریان را در یک تماس واحد انجام داد تا مدیریت جریان را ساده کند. جریان های دو جهته جایگزین ساختار STREAM_FROM_STREAM می شوند.
• معناشناسی حالت محدود برای دستگاه های سخت افزاری قدیمی/محدود.

2.0

انتشار اولیه HAL با قابلیت توسعه یافته (Android 4.2) [camera2.h]:

• برای پیاده سازی android.hardware.Camera API موجود کافی است.
• صف ZSL را در لایه سرویس دوربین اجازه می دهد.
• برای هیچ ویژگی جدیدی مانند کنترل ضبط دستی، ضبط RAW Bayer، پردازش مجدد داده‌های RAW و غیره آزمایش نشده است.

1.0

دوربین اولیه Android HAL (Android 4.0) [camera.h]:

• از لایه انتزاعی CameraHardwareInterface C++ تبدیل شده است.
• از android.hardware.Camera API پشتیبانی می کند.

تاریخچه نسخه ماژول دوربین

این بخش حاوی اطلاعات نسخه‌سازی ماژول برای ماژول سخت‌افزار دوربین، بر اساس camera_module_t.common.module_api_version است. دو رقم شش ضلعی که بیشترین اهمیت را دارند نشان دهنده نسخه اصلی و دو رقم کم اهمیت نشان دهنده نسخه کوچک هستند.

2.4

این نسخه ماژول دوربین تغییرات API زیر را اضافه می کند:

1. پشتیبانی از حالت مشعل این چارچوب می‌تواند حالت مشعل را برای هر دستگاه دوربینی که واحد فلاش دارد، بدون باز کردن دستگاه دوربین روشن کند. دستگاه دوربین برای دسترسی به واحد فلاش اولویت بیشتری نسبت به ماژول دوربین دارد. باز کردن یک دستگاه دوربین، مشعل را خاموش می کند اگر از طریق رابط ماژول فعال شده بود. هنگامی که هر گونه تداخل منابع وجود دارد، مانند open() برای باز کردن یک دستگاه دوربین، ماژول دوربین HAL باید چارچوب را از طریق پاسخ تماس وضعیت حالت مشعل اعلام کند که حالت مشعل خاموش شده است.
2. دوربین خارجی (به عنوان مثال، دوربین USB hot-plug) پشتیبانی می کند. به‌روزرسانی‌های API مشخص می‌کنند که اطلاعات استاتیک دوربین فقط زمانی در دسترس است که دوربین متصل باشد و برای دوربین‌های خارجی با اتصال داغ آماده استفاده باشد. وقتی وضعیت دوربین CAMERA_DEVICE_STATUS_PRESENT نباشد، تماس‌ها برای دریافت اطلاعات ثابت، تماس‌های نامعتبر هستند. این چارچوب برای مدیریت لیست دوربین خارجی موجود، تنها بر روی تماس‌های تغییر وضعیت دستگاه حساب می‌کند.
3. نکات داوری دوربین پشتیبانی برای نشان دادن صریح تعداد دستگاه‌های دوربینی که می‌توان به طور همزمان باز و استفاده کرد اضافه می‌کند. برای تعیین ترکیب‌های معتبر از دستگاه‌ها، فیلدهای resource_cost و conflicting_devices باید همیشه در ساختار camera_info که با تماس get_camera_info بازگردانده شده است، تنظیم شوند.
4. روش اولیه سازی ماژول پس از بارگیری ماژول HAL توسط سرویس دوربین فراخوانی می شود تا امکان راه اندازی یک بار HAL فراهم شود. قبل از فراخوانی هر روش ماژول دیگری فراخوانی می شود.

2.3

این نسخه ماژول دوربین پشتیبانی از دستگاه HAL دوربین قدیمی را اضافه می کند. اگر همان دستگاه بتواند از چندین نسخه API دستگاه پشتیبانی کند، چارچوب می‌تواند از آن برای باز کردن دستگاه دوربین به عنوان دستگاه HAL نسخه پایین‌تر استفاده کند. فراخوانی باز ماژول سخت افزاری استاندارد ( common.methods->open ) همچنان دستگاه دوربین را با آخرین نسخه پشتیبانی شده باز می کند، که همچنین نسخه فهرست شده در camera_info_t.device_version است.

2.2

این نسخه ماژول دوربین، پشتیبانی از برچسب فروشنده را از ماژول اضافه می‌کند و vendor_tag_query_ops قدیمی را که قبلاً فقط با دستگاه باز قابل دسترسی بودند، منسوخ می‌کند.

2.1

این نسخه ماژول دوربین از ماژول دوربین HAL پشتیبانی از تماس های ناهمزمان را به چارچوب اضافه می کند، که برای اطلاع رسانی به چارچوب در مورد تغییرات وضعیت ماژول دوربین استفاده می شود. ماژول هایی که یک متد set_callbacks() معتبر ارائه می کنند باید حداقل این شماره نسخه را گزارش کنند.

2.0

ماژول‌های دوربینی که این شماره نسخه را گزارش می‌کنند، نسخه دوم رابط ماژول دوربین HAL را اجرا می‌کنند. دستگاه‌های دوربین قابل باز شدن از طریق این ماژول ممکن است از نسخه 1.0 یا 2.0 رابط HAL دستگاه دوربین پشتیبانی کنند. قسمت device_version دوربین_info همیشه معتبر است. قسمت static_camera_characteristics camera_info در صورتی معتبر است که قسمت device_version 2.0 یا بالاتر باشد.

1.0

ماژول‌های دوربین که این شماره‌های نسخه را گزارش می‌کنند، رابط HAL ماژول دوربین اولیه را پیاده‌سازی می‌کنند. تمام دستگاه های دوربین قابل باز شدن از طریق این ماژول فقط از نسخه 1 دستگاه دوربین HAL پشتیبانی می کنند. فیلدهای device_version و static_camera_characteristics camera_info معتبر نیستند. فقط android.hardware.Camera API می تواند توسط این ماژول و دستگاه های آن پشتیبانی شود.