الإصدارات المتوافقة من الكاميرا

توضّح هذه الصفحة تفاصيل الاختلافات بين الإصدارات في طبقات تجريد أجهزة الكاميرا وواجهات برمجة التطبيقات واختبارات مجموعة أدوات اختبار التوافق (CTS) المرتبطة بها. ويشمل أيضًا العديد من التغييرات المعمارية التي تم إجراؤها لتعزيز أمان إطار عمل الكاميرا في Android 7.0، والانتقال إلى Treble في Android 8.0، والتحديثات التي يجب أن يجريها المورّدون لدعم هذه التغييرات في عمليات تنفيذ الكاميرا.

المصطلحات

تُستخدَم المصطلحات التالية في هذه الصفحة:

Camera API1
إطار عمل الكاميرا على مستوى التطبيق على الأجهزة التي تعمل بالإصدار 4.4 من نظام التشغيل Android والإصدارات الأقدم، والذي يتم عرضه من خلال الفئة android.hardware.Camera.
Camera API2
إطار عمل الكاميرا على مستوى التطبيق على أجهزة Android 5.0 والإصدارات الأحدث، والذي يتم عرضه من خلال حزمة android.hardware.camera2.
طبقة تجريد الأجهزة للكاميرا
طبقة وحدة الكاميرا التي يوفّرها مورّدو نظام التشغيل على الشريحة. تم إنشاء الأُطر العامة على مستوى التطبيق استنادًا إلى طبقة تجريد الأجهزة (HAL) للكاميرا.
Camera HAL3.1
إصدار طبقة تجريد الأجهزة (HAL) لجهاز الكاميرا الذي تم إصداره مع Android 4.4
Camera HAL3.2
إصدار طبقة تجريد الأجهزة (HAL) لجهاز الكاميرا الذي تم إصداره مع Android 5.0.
مجموعة اختبار التوافق لواجهة برمجة التطبيقات Camera API1
مجموعة من اختبارات CTS للكاميرا يتم تشغيلها فوق Camera API1.
مجموعة اختبار التوافق لواجهة برمجة التطبيقات Camera API2
مجموعة إضافية من اختبارات CTS للكاميرا يتم تنفيذها بالإضافة إلى Camera API2
صوت عالي الطبقة
يفصل هذا الإصدار بين التنفيذ الخاص بالمورّد (البرامج الخاصة بالجهاز والتي تعمل على مستوى أدنى وتكتبها الشركات المصنّعة لشرائح السيليكون) وإطار عمل نظام التشغيل Android من خلال واجهة مورّد جديدة.
HIDL
لغة تعريف واجهة HAL تم تقديمها مع Treble وتُستخدم لتحديد الواجهة بين طبقة تجريد الأجهزة (HAL) ومستخدميها.
VTS
تم طرح
مجموعة اختبارات المورّدين مع مشروع Treble.

واجهات برمجة تطبيقات الكاميرا

يتضمّن نظام التشغيل Android واجهات برمجة التطبيقات التالية للكاميرا.

Camera API1

أوقف الإصدار 5.0 من نظام التشغيل Android نهائيًا واجهة برمجة التطبيقات Camera API1، وسيتم إيقافها تدريجيًا مع تركيز التطوير الجديد للمنصة على واجهة برمجة التطبيقات Camera API2. ومع ذلك، ستكون فترة الإيقاف التدريجي طويلة، وستظل إصدارات Android تتيح استخدام تطبيقات Camera API1 لبعض الوقت. على وجه التحديد، سيستمر توفير الدعم لما يلي:

  • واجهات Camera API1 للتطبيقات يجب أن تعمل تطبيقات الكاميرا المستندة إلى Camera API1 بالطريقة نفسها التي تعمل بها على الأجهزة التي تعمل بإصدارات Android الأقدم.
  • إصدارات طبقة تجريد الأجهزة (HAL) للكاميرا يتضمّن دعمًا لطبقة تجريد الأجهزة (HAL) للكاميرا 1.0.

Camera API2

يتيح إطار عمل Camera API2 للتطبيق إمكانية التحكّم في الكاميرا على مستوى أدنى، بما في ذلك عمليات نقل البيانات الفعّالة بدون نسخ للقطات المتتالية أو البث، وعناصر التحكّم في كل إطار، مثل التعرّض للضوء، ومستوى الصوت، ومستويات توازن اللون الأبيض، وتحويل الألوان، وإزالة التشويش، والحدة، وغير ذلك. لمزيد من التفاصيل، شاهِد الفيديو الذي يقدّم نظرة عامة على مؤتمر Google I/O.

يتضمّن الإصدار 5.0 من نظام التشغيل Android والإصدارات الأحدث واجهة برمجة التطبيقات Camera API2، ولكن قد لا تتوافق الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android والإصدارات الأحدث مع جميع ميزات واجهة برمجة التطبيقات 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 مع بعض الاستثناءات، مثلاً، قد لا يتم تسجيل بعض معلومات أجهزة الاستشعار أو العدسات أو قد تكون معدلات عرض اللقطات أقل ثباتًا. يتم استخدام هذا المستوى للكاميرات الخارجية، مثل كاميرات الويب USB.

يتم عرض الإمكانات الفردية من خلال السمة android.request.availableCapabilities في واجهات Camera API2. تتطلّب أجهزة FULL توفُّر إمكانات MANUAL_SENSOR وMANUAL_POST_PROCESSING وغيرها. تكون إمكانية استخدام RAW اختيارية حتى لأجهزة FULL. يمكن لأجهزة LIMITED الإعلان عن أي مجموعة فرعية من هذه الإمكانات، بما في ذلك عدم الإعلان عن أي منها. ومع ذلك، يجب تحديد إذن BACKWARD_COMPATIBLE دائمًا.

يتوفّر مستوى الأجهزة المتوافق مع الجهاز، بالإضافة إلى إمكانات Camera API2 المحدّدة التي يتوافق معها، كعلامات الميزات التالية للسماح لـ Google Play بفلترة تطبيقات الكاميرا التي تستخدم Camera API2.

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

متطلبات مجموعة أدوات اختبار التوافق (CTS)

يجب أن تجتاز الأجهزة التي تعمل بالإصدار 5.0 من نظام التشغيل Android والإصدارات الأحدث اختبارات الكاميرا في "مجموعة أدوات اختبار التوافق" (CTS) لواجهة برمجة التطبيقات Camera API1 وواجهة برمجة التطبيقات Camera API2 وCTS Verifier.

يجب أن تجتاز الأجهزة التي لا تتضمّن تنفيذًا لـ Camera HAL3.2 ولا يمكنها توفير واجهات Camera API2 الكاملة اختبارات Camera API2 في مجموعة أدوات اختبار التوافق (CTS). ومع ذلك، يعمل الجهاز في وضع Camera API2 LEGACY (الذي يتم فيه ربط طلبات Camera API2 بشكل مفهومي بطلبات Camera API1)، لذا يتم تلقائيًا تخطّي أي اختبارات CTS متعلقة بميزات أو إمكانات تتجاوز Camera API1.

على الأجهزة القديمة، تستخدم اختبارات CTS لواجهة برمجة التطبيقات Camera API2 التي يتم تنفيذها واجهات وإمكانات Camera API1 الحالية المتاحة للجميع بدون أي متطلبات جديدة. إنّ الأخطاء التي يتم الكشف عنها (والتي تتسبّب في تعذُّر اجتياز مجموعة اختبار التوافق (CTS) لواجهة Camera API2) هي أخطاء موجودة في طبقة تجريد الأجهزة (HAL) الحالية للكاميرا على الجهاز، وبالتالي يمكن أن ترصدها تطبيقات واجهة Camera API1 الحالية. ولا نتوقّع حدوث العديد من الأخطاء من هذا النوع (ومع ذلك، يجب إصلاح أي أخطاء من هذا النوع لاجتياز اختبارات مجموعة أدوات اختبار التوافق (CTS) لواجهة برمجة التطبيقات Camera API2).

متطلبات VTS

يجب أن تجتاز الأجهزة التي تعمل بالإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث مع عمليات تنفيذ HAL المستندة إلى Binder اختبارات VTS الخاصة بالكاميرا.

تعزيز أمان إطار عمل الكاميرا

لتعزيز أمان إطار عمل الوسائط والكاميرا، ينقل نظام التشغيل Android 7.0 خدمة الكاميرا إلى خارج mediaserver. بدءًا من الإصدار 8.0 من نظام التشغيل Android، يتم تشغيل كل طبقة تجريد أجهزة (HAL) مرتبطة ببرنامج ربط في عملية منفصلة عن خدمة الكاميرا. قد يحتاج المورّدون إلى إجراء تغييرات في طبقة تجريد الأجهزة (HAL) للكاميرا استنادًا إلى إصدارَي واجهة برمجة التطبيقات وطبقة تجريد الأجهزة المستخدَمَين. توضّح الأقسام التالية بالتفصيل التغييرات المعمارية في AP1 وAP2 لكل من HAL1 وHAL3، بالإضافة إلى المتطلبات العامة.

التغييرات في بنية API1

قد يفترض تسجيل الفيديو باستخدام واجهة برمجة التطبيقات API1 أنّ الكاميرا وبرنامج ترميز الفيديو يعملان في العملية نفسها. عند استخدام API1 على:

  • في HAL3، حيث تستخدم خدمة الكاميرا BufferQueue لتمرير المخازن المؤقتة بين العمليات، لا يلزم إجراء أي تحديث من المورّد.

    حزمة الوسائط والكاميرا في Android 7.0 في API1 على HAL3

    الشكل 1. حزمة الكاميرا والوسائط في نظام التشغيل Android 7.0 في واجهة برمجة التطبيقات API1 على HAL3

  • يجب أن يتيح HAL1 تمرير البيانات الوصفية في مخازن الفيديو المؤقتة، وعلى المورّدين تعديل HAL لاستخدام kMetadataBufferTypeNativeHandleSource. (لم يعُد kMetadataBufferTypeCameraSource متاحًا في الإصدار 7.0 من نظام التشغيل Android.)

    حزمة الكاميرا والوسائط في Android 7.0
في API1 على HAL1

    الشكل 2. حزمة الكاميرا والوسائط في الإصدار 7.0 من نظام التشغيل Android في واجهة برمجة التطبيقات API1 على طبقة تجريد الأجهزة HAL1

التغييرات في بنية API2

بالنسبة إلى API2 على HAL1 أو HAL3، يمرِّر BufferQueue المخازن المؤقتة حتى تظل هذه المسارات تعمل. بنية Android 7.0 لواجهة برمجة التطبيقات API2 على:

  • لا يتأثر HAL1 بنقل خدمة الكاميرا، ولا يلزم إجراء أي تحديث من المورّد.
  • يتأثّر HAL3 بذلك، ولكن لا يلزم إجراء أي تعديل على المورّد:

    حزمة الكاميرا والوسائط في الإصدار 7.0 من نظام التشغيل Android في واجهة برمجة التطبيقات 2 على HAL3

    الشكل 3. حزمة الكاميرا والوسائط في الإصدار 7.0 من نظام التشغيل Android في واجهة برمجة التطبيقات 2 على HAL3

متطلبات إضافية

تشمل التغييرات المعمارية التي تم إجراؤها لتعزيز أمان إطار عمل الوسائط والكاميرا متطلبات الأجهزة الإضافية التالية.

  • أحكام عامة: تتطلّب الأجهزة معدل نقل بيانات إضافيًا بسبب عملية الاتصال بين العمليات (IPC)، ما قد يؤثّر في حالات استخدام الكاميرا التي تتطلّب سرعة عالية، مثل تسجيل الفيديو عالي السرعة. يمكن للمورّدين قياس التأثير الفعلي من خلال تشغيل android.hardware.camera2.cts.PerformanceTest وتطبيق "كاميرا Google" لتسجيل فيديو عالي السرعة بمعدّل 120 أو 240 لقطة في الثانية. تتطلّب الأجهزة أيضًا مقدارًا صغيرًا من ذاكرة الوصول العشوائي الإضافية لإنشاء العملية الجديدة.
  • تمرير البيانات الوصفية في مخازن الفيديو المؤقتة (HAL1 فقط) إذا كان الإصدار 1 من طبقة تجريد الأجهزة (HAL) يخزّن البيانات الوصفية بدلاً من بيانات إطار YUV الحقيقية في مخازن الفيديو المؤقتة، يجب أن تستخدم طبقة HAL النوع kMetadataBufferTypeNativeHandleSource كمخزن مؤقت للبيانات الوصفية وأن تمرّر VideoNativeHandleMetadata في مخازن الفيديو المؤقتة. (لم يعُد الرمز kMetadataBufferTypeCameraSource متاحًا على الإصدار 7.0 من نظام التشغيل Android.) باستخدام VideoNativeHandleMetadata، يمكن لأُطر عمل الكاميرا والوسائط تمرير مخازن الفيديو المؤقتة بين العمليات من خلال تسلسل المقابض الأصلية وإلغاء تسلسلها بشكل صحيح.
  • لا يخزِّن عنوان معرّف المخزن المؤقت المخزن المؤقت نفسه دائمًا(في الإصدار 3 من طبقة تجريد الأجهزة فقط). بالنسبة إلى كل طلب التقاط، يحصل HAL3 على عناوين مقابض المخزن المؤقت. لا يمكن أن تستخدم طبقة HAL العناوين لتحديد المخازن المؤقتة لأنّ العناوين قد تخزّن معرّف مخزن مؤقت آخر بعد أن تعرض طبقة HAL المخزن المؤقت. يجب تعديل طبقة HAL لاستخدام معرّفات المخزن المؤقت من أجل تحديد المخازن المؤقتة. على سبيل المثال، يتلقّى HAL عنوان معرّف المخزن المؤقت A، الذي يخزِّن معرّف المخزن المؤقت A. بعد أن تعرض طبقة HAL معرّف المخزن المؤقت A، قد يخزّن عنوان معرّف المخزن المؤقت A معرّف المخزن المؤقت B في المرة التالية التي تتلقّى فيها طبقة HAL هذا المعرّف.
  • تعديل سياسات SELinux الخاصة بـ cameraserver إذا كانت سياسات SELinux الخاصة بالجهاز تمنح mediaserver أذونات لتشغيل الكاميرا، عليك تعديل سياسات SELinux لمنح cameraserver الأذونات المناسبة. ننصح بعدم تكرار سياسات SELinux الخاصة بـ mediaserver في cameraserver (لأنّ mediaserver وcameraserver تتطلّبان عادةً موارد مختلفة في النظام). يجب أن يحصل Cameraserver على الأذونات اللازمة فقط لتنفيذ وظائف الكاميرا، ويجب إزالة أي أذونات غير ضرورية متعلقة بالكاميرا في mediaserver.
  • الفصل بين طبقة تجريد الأجهزة (HAL) الخاصة بالكاميرا وخدمة الكاميرا: بالإضافة إلى ذلك، يفصل نظام التشغيل Android 8.0 والإصدارات الأحدث Camera HAL المرتبط بـ Binder في عملية مختلفة عن عملية cameraserver. تتم معالجة عمليات الاتصال بين العمليات من خلال واجهات محدّدة في HIDL.

التحقُّق

بالنسبة إلى جميع الأجهزة التي تتضمّن كاميرا وتعمل بالإصدار 7.0 من نظام التشغيل Android، تحقَّق من عملية التنفيذ من خلال تشغيل حزمة اختبار التوافق (CTS) لنظام التشغيل Android 7.0. على الرغم من أنّ الإصدار 7.0 من نظام Android لا يتضمّن اختبارات جديدة في مجموعة أدوات اختبار التوافق (CTS) للتحقّق من تغييرات خدمة الكاميرا، ستتعذّر اختبارات CTS الحالية إذا لم تُجرِ التحديثات الموضّحة أعلاه.

بالنسبة إلى جميع الأجهزة التي تتضمّن كاميرا وتعمل بالإصدار 8.0 من نظام التشغيل Android والإصدارات الأحدث، تحقَّق من تنفيذ المورّد من خلال تشغيل اختبار توافق المورّد (VTS).

سجلّ إصدارات طبقة تجريد الأجهزة (HAL) للكاميرا

للاطّلاع على قائمة بالاختبارات المتاحة لتقييم طبقة تجريد أجهزة الكاميرا في Android، يُرجى الاطّلاع على قائمة التحقّق من اختبار طبقة تجريد أجهزة الكاميرا.

Android 10

يتضمّن الإصدار 10 من نظام التشغيل Android التحديثات التالية.

Camera API

طبقة تجريد الأجهزة للكاميرا

تم تعديل إصدارات Camera HAL التالية في نظام التشغيل Android 10.

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: طريقة تحدّد لإطار عمل الكاميرا ما إذا كانت إعادة ضبط البث بالكامل مطلوبة لقيم مَعلمات الجلسة الجديدة المحتملة. يساعد ذلك في تجنُّب التأخيرات غير الضرورية في إعادة ضبط إعدادات الكاميرا. راجِع طلب إعادة ضبط الجلسة.
  • واجهات برمجة التطبيقات الخاصة بإدارة المخزن المؤقت في طبقة تجريد الأجهزة (HAL): تتيح هذه الواجهات لطبقة تجريد الأجهزة الخاصة بالكاميرا طلب مخازن مؤقتة من إطار عمل الكاميرا عند الحاجة فقط بدلاً من ربط كل طلب التقاط بالمخازن المؤقتة المرتبطة به في جميع مراحل عمل الكاميرا، ما يؤدي إلى توفير كبير في الذاكرة.
    • signalStreamFlush: تشير إلى HAL بأنّ خدمة الكاميرا ستنفّذ configureStreams_3_5 وأنّ HAL يجب أن تعرض جميع المخازن المؤقتة لعمليات البث المحدّدة.
    • configureStreams_3_5: تشبه ICameraDevice3.4.configureStreams، ولكن بالإضافة إلى ذلك، يتم توفير عدّاد streamConfigCounter للتحقّق من حالة التزامن بين طلبات configureStreams_3_5 وsignalStreamFlush.

تعديلات على ICameraDeviceCallback:

  • requestStreamBuffers: هي دالة رد نداء متزامنة تستدعيها طبقة تجريد الأجهزة (HAL) الخاصة بالكاميرا لطلب المخازن المؤقتة من خادم الكاميرا. يمكنك الاطّلاع على requestStreamBuffers.
  • returnStreamBuffers: عملية ردّ اتصال متزامنة لطبقة HAL الخاصة بالكاميرا من أجل إرجاع مخازن مؤقتة للناتج إلى خادم الكاميرا. يمكنك الاطّلاع على returnStreamBuffers.

3.4

تتم إضافة المفاتيح التالية إلى البيانات الوصفية للكاميرا في نظام التشغيل Android 10.

  • تنسيقات الصور
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • علامات البيانات الوصفية للكاميرا
    • ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
    • ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
    • ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
    • ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
    • ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
    • ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
    • ANDROID_HEIC_INFO_SUPPORTED
    • ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
  • الإمكانات
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • قيم المفتاح ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • إعدادات بث العمق الديناميكي المتاحة
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • إعدادات البث المباشر المتوفّرة بتنسيق HEIC
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

وحدة الكاميرا

يتم تعديل إصدارات وحدة الكاميرا التالية في نظام التشغيل Android 10.

2.5

  • تضيف هذه السمة الطريقة notifyDeviceStateChange التي تتيح للأجهزة إرسال إشعار إلى طبقة تجريد الأجهزة (HAL) الخاصة بالكاميرا عند حدوث تغييرات مادية، مثل الطي، تؤثر في الكاميرا والتوجيه.

2.4

  • يجب أن تعرض الأجهزة التي تعمل بالمستوى 29 أو أعلى لواجهة برمجة التطبيقات القيمة true لـ isTorchModeSupported.

Android 9

يتضمّن إصدار Android 9 التحديثات التالية على واجهة برمجة التطبيقات 2 للكاميرا وواجهة HAL.

Camera 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.

طبقة تجريد الأجهزة للكاميرا

3.4

تعديلات على ICameraDeviceSession

  • configureStreams_3_4: تضيف هذه السمة إمكانية استخدام sessionParameters والكاميرات المنطقية.
  • processCaptureRequest_3_4: تضيف هذه السمة إمكانية تضمين أرقام تعريف الكاميرات المادية في بنية البث.

تعديلات على ICameraDeviceCallback

  • processCaptureResult_3_4: تضيف هذه السمة البيانات الوصفية للكاميرا المادية في نتائج الالتقاط.

3.3

تتم إضافة المفاتيح التالية إلى البيانات الوصفية للكاميرا في Android 9.

  • الإمكانات
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • علامات البيانات الوصفية للكاميرا
    • ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
    • ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
    • ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
    • ANDROID_LENS_POSE_REFERENCE
    • ANDROID_LENS_DISTORTION
    • ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
    • ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
    • ANDROID_STATISTICS_OIS_DATA_MODE
    • ANDROID_STATISTICS_OIS_TIMESTAMPS
    • ANDROID_STATISTICS_OIS_X_SHIFTS
    • ANDROID_STATISTICS_OIS_Y_SHIFTS

Android 8.0

يتضمّن إصدار Android 8.0 بنية Treble. باستخدام Treble، يجب أن تكون عمليات تنفيذ Camera HAL الخاصة بالمورّد مرتبطة. يتضمّن الإصدار 8.0 من نظام التشغيل Android أيضًا التحسينات الرئيسية التالية على خدمة "الكاميرا":

  • الأسطح المشترَكة: تفعيل أسطح متعدّدة تشارك OutputConfiguration نفسه
  • واجهة برمجة تطبيقات النظام لأوضاع الكاميرا المخصّصة
  • onCaptureQueueEmpty

يُرجى الاطّلاع على الأقسام أدناه لمعرفة المزيد من المعلومات عن هذه الميزات.

الأسطح المشترَكة

تتيح هذه الميزة استخدام مجموعة واحدة فقط من المخازن المؤقتة لتشغيل نتيجتَين، مثل المعاينة وتشفير الفيديو، ما يؤدي إلى خفض استهلاك الطاقة والذاكرة. ولإتاحة هذه الميزة، على مصنّعي الأجهزة التأكّد من أنّ عمليات تنفيذ طبقة HAL للكاميرا وطبقة HAL لـ gralloc يمكنها إنشاء مخازن مؤقتة لـ gralloc تستخدمها جهات متعددة مختلفة (مثل أداة إنشاء الصور على الأجهزة/وحدة معالجة الرسومات وبرنامج ترميز الفيديو)، بدلاً من جهة واحدة فقط. تمرّر خدمة الكاميرا علامات استخدام المستهلك إلى طبقة تجريد الأجهزة (HAL) الخاصة بالكاميرا وطبقة تجريد الأجهزة (HAL) الخاصة بـ gralloc، ويجب أن تعمل إما على تخصيص أنواع المخازن المؤقتة المناسبة، أو أن تعرض طبقة تجريد الأجهزة (HAL) الخاصة بالكاميرا خطأً يفيد بأنّ هذه المجموعة من المستهلكين غير متوافقة.

يمكنك الاطّلاع على enableSurfaceSharing مستندات المطوّرين للحصول على تفاصيل إضافية.

واجهة برمجة تطبيقات النظام لأوضاع الكاميرا المخصّصة

تحدّد واجهة برمجة التطبيقات العامة للكاميرا وضعَي تشغيل، وهما: التسجيل العادي والتسجيل السريع المقيّد. تختلف دلالاتها إلى حدّ كبير، فمثلاً، يقتصر وضع السرعة العالية على نتيجتَين محدّدتين على الأكثر في المرة الواحدة. أبدت العديد من الشركات المصنّعة الأصلية للأجهزة اهتمامًا بتحديد أوضاع مخصّصة أخرى تتوافق مع إمكانات الأجهزة المحدّدة. في الخلفية، يكون الوضع مجرد عدد صحيح يتم تمريره إلى configure_streams. يمكنك الاطّلاع على: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

تتضمّن هذه الميزة طلبًا من واجهة برمجة تطبيقات النظام يمكن أن تستخدمه تطبيقات الكاميرا الخاصة بمصنّعي المعدات الأصلية لتفعيل وضع مخصّص. يجب أن تبدأ هذه الأوضاع بالقيمة الصحيحة 0x8000 لتجنُّب التعارض مع الأوضاع المستقبلية التي ستتم إضافتها إلى واجهة برمجة التطبيقات العامة.

لتوفير هذه الميزة، ما على الشركات المصنّعة للأجهزة الأصلية سوى إضافة الوضع الجديد إلى طبقة تجريد الأجهزة (HAL)، ويتم تفعيل الوضع الجديد من خلال العدد الصحيح الذي يتم تمريره إلى طبقة تجريد الأجهزة عند استدعاء configure_streams، ثم تطلب من تطبيق الكاميرا المخصّص استخدام واجهة برمجة التطبيقات الخاصة بالنظام.

اسم الطريقة هو android.hardware.camera2.CameraDevice#createCustomCaptureSession. يمكنك الاطّلاع على: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

الغرض من واجهة برمجة التطبيقات هذه هو تقليل وقت الاستجابة للتغييرات في عناصر التحكّم، مثل التكبير/التصغير، من خلال إبقاء قائمة انتظار الطلبات فارغة قدر الإمكان. onCaptureQueueEmpty لا يتطلّب أي عمل في طبقة تجريد الأجهزة (HAL)، بل كان مجرد إضافة من جهة إطار العمل. على التطبيقات التي تريد الاستفادة من هذه الميزة إضافة مستمع إلى دالة رد الاتصال هذه والرد بشكل مناسب. ويتم ذلك عادةً عن طريق إرسال طلب التقاط آخر إلى جهاز الكاميرا.

واجهة HIDL للكاميرا

واجهة Camera HIDL هي عملية إصلاح شامل لواجهة Camera HAL التي تستخدم واجهات برمجة تطبيقات ثابتة محدّدة في HIDL. تتضمّن تعريفات HIDL أيضًا جميع الميزات وإمكانات الكاميرا التي تم تقديمها في أحدث الإصدارات القديمة 3.4 و2.4 (لوحدة الكاميرا).

3.4

إضافات بسيطة إلى البيانات الوصفية المتوافقة وتغييرات على توافق data_space:

  • أضِف ANDROID_SENSOR_OPAQUE_RAW_SIZE بيانات وصفية ثابتة كبيانات إلزامية إذا كان تنسيق RAW_OPAQUE متوافقًا.
  • أضِف البيانات الوصفية ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE الثابتة كبيانات إلزامية إذا كان أي تنسيق RAW متوافقًا.
  • تغيير حقل camera3_stream_t data_space إلى تعريف أكثر مرونة، باستخدام تعريف الإصدار 0 لترميز مساحة البيانات
  • إضافات البيانات الوصفية العامة المتاحة للاستخدام في HALv3.2 أو الإصدارات الأحدث:
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

مراجعة ثانوية لطبقة تجريد الأجهزة (HAL) ذات الإمكانات الموسّعة:

  • تعديلات على واجهة برمجة التطبيقات الخاصة بإعادة معالجة تنسيقات OPAQUE وYUV
  • توفير دعم أساسي لمخازن الإخراج الخاصة بالعمق
  • إضافة الحقل data_space إلى camera3_stream_t
  • إضافة حقل التدوير إلى camera3_stream_t
  • إضافة وضع تشغيل إعدادات بث camera3 إلى 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_result بدلاً من process_capture_request.

‫3.1

مراجعة ثانوية لطبقة تجريد الأجهزة (HAL) ذات الإمكانات الموسّعة:

  • تعرض configure_streams علامات استخدام المستهلكين إلى طبقة HAL.
  • يتم استدعاء الدالة flush لإيقاف جميع الطلبات/المخازن المؤقتة الجارية بأسرع ما يمكن.

3

المراجعة الأولى لطبقة تجريد الأجهزة (HAL) ذات الإمكانات الموسّعة:

  • تغيير الإصدار الرئيسي لأنّ واجهة التطبيق الثنائية (ABI) مختلفة تمامًا لم يطرأ أي تغيير على إمكانات الأجهزة المطلوبة أو نموذج التشغيل مقارنةً بالإصدار 2.0.
  • تمت إعادة تصميم واجهات طلب الإدخال وقائمة انتظار البث: يتم استدعاء إطار العمل إلى طبقة HAL مع إلغاء تسلسل الطلب التالي ومخازن البث المؤقتة. يتم تضمين إمكانية استخدام إطار عمل المزامنة، وهو أمر ضروري لتنفيذ عمليات المزامنة بكفاءة.
  • نقلنا المشغّلات إلى الطلبات، ومعظم الإشعارات إلى النتائج.
  • تم دمج جميع عمليات معاودة الاتصال في إطار عمل واحد، وجميع طرق الإعداد في عملية استدعاء initialize() واحدة.
  • تم دمج عملية ضبط إعدادات البث في طلب واحد لتسهيل إدارة البث. تحلّ عمليات البث الثنائية الاتجاه محلّ البنية STREAM_FROM_STREAM.
  • دلالات الوضع المحدود للأجهزة القديمة أو ذات الموارد المحدودة

2.0

الإصدار الأولي من طبقة تجريد الأجهزة (HAL) ذات الإمكانات الموسّعة (Android 4.2) [camera2.h]:

  • كافٍ لتنفيذ واجهة برمجة التطبيقات الحالية android.hardware.Camera
  • يسمح بوضع قائمة انتظار ZSL في طبقة خدمة الكاميرا.
  • لم يتم اختبار أي ميزات جديدة، مثل التحكّم اليدوي في التقاط الصور، والتقاط الصور بتنسيق Bayer RAW، وإعادة معالجة بيانات RAW، وما إلى ذلك.

1

إصدار HAL الأوّلي للكاميرا في Android (الإصدار 4.0) [camera.h]:

  • تم تحويلها من طبقة تجريد CameraHardwareInterface في C++.
  • يتوافق مع واجهة برمجة التطبيقات android.hardware.Camera.

سجلّ إصدارات وحدة الكاميرا

يحتوي هذا القسم على معلومات حول إصدارات وحدة Camera hardware، استنادًا إلى camera_module_t.common.module_api_version. يمثّل رقما السداسي العشري الأكثر أهمية الإصدار الرئيسي، ويمثّل رقما السداسي العشري الأقل أهمية الإصدار الثانوي.

2.4

يضيف إصدار وحدة الكاميرا هذا تغييرات واجهة برمجة التطبيقات التالية:

  1. التوافق مع وضع المصباح اليدوي: يمكن للإطار تفعيل وضع المصباح لأي جهاز كاميرا مزوّد بفلاش، بدون فتح جهاز الكاميرا. يتمتع جهاز الكاميرا بأولوية أعلى في الوصول إلى وحدة الفلاش مقارنةً بوحدة الكاميرا، لذا يؤدي فتح جهاز الكاميرا إلى إيقاف المصباح اليدوي إذا كان مفعَّلاً من خلال واجهة الوحدة. عند حدوث أي تعارضات في الموارد، مثل استدعاء open() لفتح جهاز كاميرا، يجب أن تُعلم وحدة HAL الخاصة بالكاميرا إطار العمل من خلال معاودة الاتصال بحالة وضع المصباح اليدوي بأنّه تم إيقاف وضع المصباح اليدوي.
  2. إتاحة استخدام كاميرا خارجية (مثل كاميرا USB يمكن توصيلها وفصلها أثناء التشغيل) تحدّد تعديلات واجهة برمجة التطبيقات أنّ المعلومات الثابتة للكاميرا لا تتوفّر إلا عندما تكون الكاميرا متصلة وجاهزة للاستخدام مع الكاميرات الخارجية التي يمكن توصيلها وفصلها أثناء التشغيل. تكون طلبات الحصول على معلومات ثابتة غير صالحة عندما لا تكون حالة الكاميرا CAMERA_DEVICE_STATUS_PRESENT. يعتمد إطار العمل بشكل كامل على عمليات معاودة الاتصال عند تغيير حالة الجهاز لإدارة قائمة الكاميرات الخارجية المتاحة.
  3. تلميحات حول التحكّم في الكاميرا تضيف هذه السمة إمكانية تحديد عدد أجهزة الكاميرا التي يمكن فتحها واستخدامها في الوقت نفسه. لتحديد مجموعات صالحة من الأجهزة، يجب دائمًا ضبط الحقلَين resource_cost وconflicting_devices في بنية camera_info التي تعرضها استدعاءات get_camera_info.
  4. طريقة تهيئة الوحدة يتم استدعاؤها من خلال خدمة الكاميرا بعد تحميل وحدة طبقة تجريد الأجهزة (HAL) للسماح بتهيئة طبقة تجريد الأجهزة لمرة واحدة. يتم استدعاؤها قبل استدعاء أي طرق أخرى للوحدة.

‫2.3

يضيف إصدار وحدة الكاميرا هذا إمكانية فتح جهاز HAL القديم للكاميرا. يمكن أن يستخدم إطار العمل هذا المعرّف لفتح جهاز الكاميرا كجهاز HAL بإصدار أقل إذا كان الجهاز نفسه يتوافق مع إصدارات متعددة من واجهة برمجة التطبيقات. يستمر طلب فتح وحدة الأجهزة العادية (common.methods->open) في فتح جهاز الكاميرا باستخدام أحدث إصدار متوافق، وهو أيضًا الإصدار المُدرَج في camera_info_t.device_version.

2.2

يضيف إصدار وحدة الكاميرا هذا إمكانية استخدام علامات المورّدين من الوحدة، ويوقف نهائيًا استخدام vendor_tag_query_ops القديمة التي كان يمكن الوصول إليها في السابق فقط عند فتح الجهاز.

2.1

يضيف إصدار وحدة الكاميرا هذا إمكانية استخدام عمليات رد الاتصال غير المتزامنة في إطار العمل من وحدة HAL الخاصة بالكاميرا، والتي تُستخدَم لإعلام إطار العمل بالتغييرات التي تطرأ على حالة وحدة الكاميرا. يجب أن تعرض الوحدات التي توفّر طريقة set_callbacks() صالحة رقم الإصدار هذا على الأقل.

2.0

تنفّذ وحدات الكاميرا التي تعرض رقم الإصدار هذا الإصدار الثاني من واجهة طبقة تجريد الأجهزة (HAL) لوحدة الكاميرا. قد تتوافق أجهزة الكاميرا التي يمكن فتحها من خلال هذه الوحدة مع الإصدار 1.0 أو الإصدار 2.0 من واجهة HAL الخاصة بجهاز الكاميرا. يكون الحقل device_version في camera_info صالحًا دائمًا، ويكون الحقل static_camera_characteristics في camera_info صالحًا إذا كان الحقل device_version 2.0 أو إصدارًا أحدث.

1

تتضمّن وحدات الكاميرا التي تعرض أرقام الإصدارات هذه واجهة HAL الأولية لوحدة الكاميرا. تتيح جميع أجهزة الكاميرا التي يمكن فتحها من خلال هذه الوحدة النمطية استخدام الإصدار 1 فقط من طبقة تجريد الأجهزة (HAL) الخاصة بجهاز الكاميرا. الحقلان device_version وstatic_camera_characteristics في camera_info غير صالحَين. يمكن أن تتوافق هذه الوحدة والأجهزة التابعة لها مع واجهة برمجة التطبيقات android.hardware.Camera فقط.