Obsługa wersji aparatu

Na tej stronie znajdziesz szczegółowe informacje o różnicach między wersjami interfejsów HAL aparatu, interfejsów API i powiązanych testów Compatibility Test Suite (CTS). Obejmuje ona również kilka zmian architektonicznych wprowadzonych w ramach wzmacniania i zabezpieczania interfejsu aparatu w Androidzie 7.0, przejścia na Treble w Androidzie 8.0 oraz aktualizacji, które producenci muszą wprowadzić w swoich implementacjach aparatu, aby uwzględnić te zmiany.

Terminologia

Na tej stronie używamy tych terminów:

interfejs Camera API1,
Usługa aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 lub starszym, udostępniana przez klasę android.hardware.Camera.
Camera API2
Usługa aparatu na poziomie aplikacji na urządzeniach z Androidem 5.0 lub nowszym, udostępniona za pomocą pakietu android.hardware.camera2.
Interfejs HAL aparatu
Warstwę modułu aparatu implementują dostawcy układów SoC. Publiczne frameworki na poziomie aplikacji są tworzone na podstawie interfejsu HAL aparatu.
Aparat HAL3.1
Wersja interfejsu HAL aparatu wydana w ramach Androida 4.4.
Aparat HAL3.2
Wersja interfejsu HAL aparatu, która została wydana wraz z Androidem 5.0.
Camera API1 CTS
Zestaw testów CTS aparatu, które są wykonywane na podstawie interfejsu Camera API 1.
Camera API2 CTS
Dodatkowy zestaw testów CTS aparatu, które są wykonywane na interfejsie Camera API2.
Sopran
Oddziela implementację dostawcy (oprogramowanie na niższym poziomie związane z danym urządzeniem, napisane przez producentów układów scalonych) od platformy Androida za pomocą nowego interfejsu dostawcy.
HIDL
Język definicji interfejsu HAL wprowadzony w Treble, służący do określania interfejsu między HAL a użytkownikami.
VTS
Pakiet testów dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android zawiera te interfejsy API aparatu.

interfejs Camera API1,

W Androidzie 5.0 wycofany został interfejs Camera API 1, który jest stopniowo wycofywany, ponieważ rozwój nowej platformy koncentruje się na interfejsie Camera API 2. Okres wycofywania będzie jednak długi, a wersje Androida będą przez jakiś czas nadal obsługiwać aplikacje korzystające z interfejsu Camera API 1. W szczególności dotyczy to:

  • Interfejsy Camera API 1 dla aplikacji. Aplikacje aparatu oparte na interfejsie Camera API1 powinny działać tak samo jak na urządzeniach z niższymi wersjami Androida.
  • Wersje interfejsu HAL aparatu. Obejmuje obsługę komponentu HAL aparatu 1.0.

Camera API2

Interfejs Camera API 2 udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy burst/streaming bez kopiowania i kontroli na poziomie poszczególnych klatek dotyczącej ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania i innych funkcji. Więcej informacji znajdziesz w  filmie z konferencji Google I/O.

Android 5.0 i nowsze wersje zawierają interfejs Camera API 2, ale urządzenia z Androidem 5.0 lub nowszym mogą nie obsługiwać wszystkich funkcji tego interfejsu. Właściwość android.info.supportedHardwareLevel, której aplikacje mogą używać w zapytaniach wysyłanych przez interfejsy Camera API 2, może mieć jeden z tych poziomów obsługi:

  • LEGACY: te urządzenia udostępniają aplikacjom funkcje za pomocą interfejsów Camera API 2, które są mniej więcej takie same jak te udostępniane aplikacjom za pomocą interfejsów Camera API 1. Kod starszych frameworków przekształca teoretycznie wywołania interfejsu Camera2 API w wywołania interfejsu Camera1 API. Starsze urządzenia nie obsługują funkcji interfejsu Camera2 API, takich jak sterowanie poklatkowe.
  • LIMITED: te urządzenia obsługują niektóre funkcje interfejsu Camera API 2 (ale nie wszystkie) i muszą używać interfejsu Camera HAL 3.2 lub nowszego.
  • FULL: te urządzenia obsługują wszystkie główne funkcje interfejsu Camera API 2 i muszą używać interfejsu Camera HAL 3.2 lub nowszego oraz systemu Android 5.0 lub nowszego.
  • LEVEL_3: te urządzenia obsługują ponowne przetwarzanie YUV i rejestrowanie obrazów RAW, a także dodatkowe konfiguracje strumienia wyjściowego.
  • EXTERNAL: te urządzenia są podobne do urządzeń LIMITED, ale z niektórymi wyjątkami. Na przykład niektóre informacje o czujniku lub obiektywie mogą nie być przekazywane lub mogą mieć mniej stabilną liczbę klatek. Ten poziom jest używany w przypadku zewnętrznych kamer, takich jak kamery internetowe USB.

Poszczególne funkcje są dostępne w interfejsach interfejsu Camera API 2 za pomocą właściwości android.request.availableCapabilities. Urządzenia FULL wymagają m.in. funkcji MANUAL_SENSOR i MANUAL_POST_PROCESSING. Możliwość RAW jest opcjonalna nawet w przypadku urządzeń FULL. Urządzenia LIMITED mogą wyświetlać reklamy dotyczące dowolnej podgrupy tych funkcji, a także żadnej z nich. Zawsze jednak musisz zdefiniować uprawnienie BACKWARD_COMPATIBLE.

Obsługiwany poziom sprzętu na urządzeniu oraz obsługiwane przez niego funkcje interfejsu Camera2 API 2 są dostępne jako te flagi funkcji, aby umożliwić filtrowanie aplikacji aparatu przez Google Play za pomocą interfejsu Camera2 API 2.

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

Wymagania dotyczące CTS

Urządzenia z Androidem 5.0 lub nowszym muszą przejść testy aparatu w ramach interfejsu Camera API 1, interfejsu Camera API 2 i weryfikatora CTS.

Urządzenia, które nie obsługują komponentu HAL aparatu 3.2 i nie obsługują wszystkich interfejsów Camera API 2, muszą przejść testy CTS Camera API 2. Urządzenie działa jednak w trybie Camera API2LEGACY (w którym wywołania interfejsu Camera API2 są odwzorowane na poziomie koncepcji na wywołania interfejsu Camera API1), więc wszystkie testy CTS interfejsu Camera API2 związane z funkcjami lub możliwościami wykraczającymi poza interfejs Camera API1 są automatycznie pomijane.

Na starszych urządzeniach testy CTS interfejsu Camera API 2 korzystają z dotychczasowych publicznych interfejsów i możliwości interfejsu Camera API 1 bez żadnych nowych wymagań. Wykryte błędy (które powodują niepowodzenie interfejsu Camera API 2 w CTS) to błędy występujące już w obecnej warstwie HAL aparatu na urządzeniu, które są wykrywane przez istniejące aplikacje korzystające z interfejsu Camera API 1. Nie spodziewamy się wielu błędów tego typu (wszystkie takie błędy muszą jednak zostać naprawione, aby przejść testy CTS interfejsu Camera API2).

Wymagania dotyczące VTS

Urządzenia z Androidem 8.0 lub nowszym z implementacjami HAL w ramach bindera muszą przejść testy VTS dotyczące aparatu.

Zabezpieczanie ramowego aparatu

Aby zwiększyć bezpieczeństwo frameworku multimediów i aparatów, Android 7.0 przenosi usługę aparatu z mediaservera. Począwszy od Androida 8.0 każdy zbinderyzowany interfejs HAL aparatu działa w procesie oddzielnym od usługi aparatu. W zależności od wersji interfejsu API i interfejsu HAL dostawcy mogą być zmuszeni do wprowadzenia zmian w interfejsie HAL aparatu. W następnych sekcjach opisano zmiany w architekturze AP1 i AP2 w przypadku HAL1 i HAL3 oraz wymagania ogólne.

Zmiany w architekturze interfejsu API1

Nagrywanie wideo za pomocą interfejsu API 1 może zakładać, że kamera i koder wideo działają w ramach tego samego procesu. Podczas korzystania z interfejsu API 1:

  • HAL3, w którym usługa aparatu używa kolejki buforowej do przekazywania buforów między procesami, nie wymaga aktualizacji od dostawcy.

    Aparat i multimedia w Androidzie 7.0 w interfejsie API 1 na HAL3

    Rysunek 1. Android 7.0 aparat i warstwy multimedialne w interfejsie API 1 na HAL3

  • HAL1, który obsługuje przekazywanie metadanych w buforze wideo. Producenci muszą zaktualizować HAL, aby używać kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource nie jest już obsługiwany w Androidzie 7.0).

    Android 7.0 aparat i warstwy multimedialne w interfejsie API 1 na HAL1

    Rysunek 2. Android 7.0 aparat i warstwy multimedialne w interfejsie API 1 na HAL 1

Zmiany w architekturze interfejsu API2

W przypadku interfejsu API2 na HAL1 lub HAL3 kolejka buforów przekazuje bufory, dzięki czemu te ścieżki nadal działają. Architektura Androida 7.0 dla interfejsu API 2 na:

  • Przeniesienie usługi cameraservice nie ma wpływu na HAL1 i nie wymaga aktualizacji ze strony dostawcy.
  • HAL3 jest objęty tą zmianą, ale nie trzeba aktualizować oprogramowania:

    Aparat i multimedia w Androidzie 7.0 w interfejsie API 2 na HAL3

    Rysunek 3. Android 7.0: aparat i warstwy multimedialne w interfejsie API 2 na HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w celu zwiększenia bezpieczeństwa mediów i ramyżródła danych kamery obejmują te dodatkowe wymagania dotyczące urządzeń.

  • Ogólne. Urządzenia wymagają dodatkowej przepustowości ze względu na IPC, co może mieć wpływ na przypadki użycia kamery, w których czas jest istotny, np. nagrywanie wideo z dużą szybkością. Dostawcy mogą mierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Aparat Google do nagrywania filmów w wysokiej rozdzielczości 120/240 FPS. Urządzenia wymagają też niewielkiej ilości dodatkowej pamięci RAM na potrzeby tworzenia nowego procesu.
  • Przekazywanie metadanych w buforze wideo (tylko w HAL1). Jeśli HAL1 zapisują metadane zamiast rzeczywistych danych ramki YUV w buforach wideo, musi użyć kMetadataBufferTypeNativeHandleSource jako typu bufora metadanych i przekazać VideoNativeHandleMetadata w buforach wideo. (kMetadataBufferTypeCameraSource nie jest już obsługiwany w Androidzie 7.0). Dzięki VideoNativeHandleMetadata aparaty i ramy pracy multimediów mogą przekazywać bufory wideo między procesami, odpowiednio serializując i deserializując natywne uchwyty.
  • Adres uchwytu bufora nie zawsze przechowuje ten sam bufor (dotyczy tylko HAL3). W przypadku każdego żądania przechwytywania HAL3 otrzymuje adresy uchwytów bufora. HAL nie może używać adresów do identyfikowania buforów, ponieważ adresy mogą przechowywać inny uchwyt bufora po zwróceniu bufora przez HAL. Musisz zaktualizować HAL, aby używać uchwytów buforów do identyfikowania buforów. Na przykład HAL otrzymuje adres uchwytu bufora A, który przechowuje uchwyt bufora A. Gdy HAL zwróci uchwyt bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B następnym razem, gdy HAL go otrzyma.
  • Zaktualizuj zasady SELinux dla serwera kamery Jeśli zasady SELinux dotyczące konkretnego urządzenia przyznają serwerowi multimediów uprawnienia do uruchamiania aparatu, musisz zaktualizować zasady SELinux, aby przyznać serwerowi aparatu odpowiednie uprawnienia. Nie zalecamy powielania zasad SELinux serwera mediaserver w przypadku serwera cameraserver (ponieważ serwer mediaserver i serwer cameraserver wymagają zazwyczaj różnych zasobów w systemie). Usługa cameraserver powinna mieć tylko uprawnienia potrzebne do wykonywania funkcji aparatu. Niepotrzebne uprawnienia dotyczące aparatu w mediaserver powinny zostać usunięte.
  • Oddzielenie interfejsu HAL aparatu od serwera aparatu. W Androidzie 8.0 i nowszych dodatkowo oddziela się binderized Camera HAL w procesie innym niż cameraserver. Komunikacja IPC odbywa się za pomocą interfejsów zdefiniowanych w specyfikacji HIDL.

Weryfikacja

W przypadku wszystkich urządzeń z kamerą i Androidem 7.0 sprawdź implementację, uruchamiając test Androida 7.0 CTS. Chociaż Android 7.0 nie zawiera nowych testów CTS, które sprawdzają zmiany w usługach aparatu, istniejące testy CTS nie przechodzą, jeśli nie wprowadzisz wspomnianych wyżej aktualizacji.

W przypadku wszystkich urządzeń z kamerą i Androidem 8.0 lub nowszym sprawdź implementację dostawcy, uruchamiając VTS.

Historia wersji interfejsu Camera HAL

Listę testów do oceny interfejsu HAL aparatu Androida znajdziesz na liście kontrolnej testów interfejsu Camera HAL.

Android 10

Android 10 wprowadza te zmiany.

Camera API

Interfejs HAL aparatu

W Androidzie 10 zostały zaktualizowane te wersje interfejsu Camera HAL:

3.5

ICameraDevice

  • getPhysicalCameraCharacteristics: Informacje o kamerze statycznej dla fizycznego identyfikatora kamery obsługującego urządzenie z kamerą logiczną. Zapoznaj się z artykułem Obsługa wielu aparatów.
  • isStreamCombinationSupported: ta metoda obsługuje publiczny interfejs API, który pomaga klientom sprawdzić, czy konfiguracja sesji jest obsługiwana. Zobacz interfejs API do wysyłania zapytań o kombinacje strumieni.

ICameraDeviceSession

  • isReconfigurationNeeded: metoda, która informuje framework kamery, czy wymagana jest pełna rekonfiguracja strumienia w przypadku nowych wartości parametrów sesji. Pomoże to uniknąć zbędnych opóźnień związanych z konfiguracją kamery. Zobacz zapytanie dotyczące rekonfiguracji sesji.
  • Interfejsy API zarządzania buforami HAL: te interfejsy API umożliwiają żądanie przez aparat HAL buforów z ramy aparatu tylko wtedy, gdy jest to wymagane, zamiast łączyć każde żądanie przechwytywania z odpowiednimi buforami w całym procesie aparatu, co może przynieść znaczne oszczędności pamięci.
    • signalStreamFlush: sygnalizuje HAL, że usługa kamery zamierza wykonać configureStreams_3_5 i że HAL musi zwrócić wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5: podobnie jak w przypadku funkcji ICameraDevice3.4.configureStreams, ale dodatkowo funkcja streamConfigCounter zawiera licznik streamConfigCounter, który umożliwia sprawdzenie, czy między wywołaniami funkcji configureStreams_3_5 i signalStreamFlush nie wystąpił stan rywalizacji.

Zmiany w ICameraDeviceCallback:

  • requestStreamBuffers: wywołanie zwrotne synchroniczne wywoływane przez HAL aparatu w celu zapytania serwera aparatu o bufory. Zobacz requestStreamBuffers.
  • returnStreamBuffers: wywołanie zwrotne synchroniczne dla HAL aparatu, które zwraca bufory wyjściowe do serwera aparatu. Zobacz returnStreamBuffers.

3.4

W Androidzie 10 do metadanych aparatu są dodawane te klucze:

  • Formaty obrazów
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tagi metadanych aparatu
    • 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
  • Możliwości
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
  • Wartości klucza ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Dostępne konfiguracje strumienia dynamicznej głębi
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Dostępne konfiguracje strumienia HEIC
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Moduł kamery

W Androidzie 10 zostały zaktualizowane te wersje modułów aparatu:

2,5

  • Dodaje metodę notifyDeviceStateChange, która umożliwia urządzeniom powiadamianie interfejsu HAL aparatu o zmianach fizycznych, takich jak złożenie, które wpływają na działanie aparatu i przekierowywanie.

2.4

  • Urządzenia z interfejsem API na poziomie 29 lub wyższym MUSZĄ raportować true dla isTorchModeSupported.

Android 9

Wersja Androida 9 wprowadza następujące zmiany w interfejsie API2 aparatu i interfejsie HAL.

Camera API

  • Wprowadza interfejs API dla wielu aparatów, aby lepiej obsługiwać urządzenia z większą liczbą aparatów skierowanych w ten sam kierunek. Umożliwia to korzystanie z takich funkcji, jak bokeh i płynne powiększanie. Dzięki temu aplikacje mogą wyświetlać wiele kamer na urządzeniu jako jedną jednostkę logiczną (kamerę logiczną). Prośby o przechwycenie można też wysyłać do poszczególnych urządzeń kamery objętych jedną kamerą logiczną. Zobacz Obsługa wielu kamer.
  • Przedstawia parametry sesji. Parametry sesji to podzbiór dostępnych parametrów rejestrowania, które po zmodyfikowaniu mogą spowodować poważne opóźnienia w przetwarzaniu. Te koszty można ograniczyć, jeśli klienci przekazują wartości początkowe podczas inicjowania sesji rejestrowania. Zobacz Parametry sesji.
  • Dodaje klucze danych stabilizacji optycznej (OIS) na potrzeby stabilizacji i efektów na poziomie aplikacji. Zobacz STATISTICS_OIS_SAMPLES.
  • Dodaje obsługę zewnętrznego flesza. Zobacz: CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Dodaje zamiar śledzenia ruchu w CAPTURE_INTENT. Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • wycofuje się LENS_RADIAL_DISTORTION i wprowadza LENS_DISTORTION.
  • Dodaje tryby korekty zniekształceń w aplikacji CaptureRequest. Zobacz DISTORTION_CORRECTION_MODE.
  • Dodano obsługę zewnętrznych aparatów USB/UVC na obsługiwanych urządzeniach. Zobacz INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Interfejs HAL aparatu

3.4

Zmiany w ICameraDeviceSession

Zmiany w ICameraDeviceCallback

3.3

W Androidzie 9 do metadanych aparatu są dodawane te klucze.

  • Możliwości
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tagi metadanych aparatu
    • 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

W wersji 8.0 Androida wprowadzono Treble. W przypadku Treble implementacje interfejsu Camera HAL muszą być związane. Android 8.0 zawiera też te kluczowe ulepszenia usługi Aparat:

  • Udostępnione powierzchnie: włączanie wielu powierzchni udostępniających tę samą OutputConfiguration
  • System interfejsu API do niestandardowych trybów aparatu
  • onCaptureQueueEmpty

Więcej informacji o tych funkcjach znajdziesz w sekcjach poniżej.

Powierzchnie wspólne

Ta funkcja umożliwia wykorzystanie tylko jednego zestawu buforów do obsługi dwóch wyjść, takich jak podgląd i kodowanie wideo, co zmniejsza zużycie energii i pamięci. Aby obsługiwać tę funkcję, producenci urządzeń muszą zadbać o to, aby ich implementacje HAL aparatu i HAL gralloc mogły tworzyć bufory gralloc, które są używane przez wielu różnych konsumentów (takich jak kompozytor sprzętowy/procesor graficzny i enkoder wideo), a nie tylko przez jednego konsumenta. Usługa aparatu przekazuje flagi użycia przez klienta do interfejsu HAL aparatu i interfejsu HAL gralloc. Muszą one przydzielić odpowiednie typy buforów lub interfejs HAL aparatu musi zwrócić błąd, który informuje, że ta kombinacja konsumentów nie jest obsługiwana.

Więcej informacji znajdziesz w  enableSurfaceSharingdokumentacji dla programistów.

System interfejsu API do niestandardowych trybów aparatu

Publiczny interfejs API aparatu definiuje 2 tryby działania: normalny i ograniczony nagrywanie z dużą szybkością. Mają one dość odmienną semantykę. Na przykład tryb szybkiego przesyłania ogranicza się do maksymalnie 2 specyficznych wyjść naraz. Różni producenci OEM wyrazili zainteresowanie definiowaniem innych trybów niestandardowych dla funkcji związanych z konkretnym sprzętem. Tryb to po prostu liczba całkowita przekazana do configure_streams. Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Ta funkcja obejmuje wywołanie interfejsu API systemu, którego aplikacje do obsługi aparatu mogą używać do włączenia trybu niestandardowego. Te tryby muszą zaczynać się od wartości całkowitej 0x8000, aby uniknąć konfliktów z przyszłościowymi trybami dodanymi do publicznego interfejsu API.

Aby obsługiwać tę funkcję, producenci OEM muszą tylko dodać nowy tryb do swojego interfejsu HAL, który jest uruchamiany przez tę liczbę całkowitą przekazaną do interfejsu HAL w ramach konfiguracji strumieni, a następnie dopilnować, aby ich niestandardowa aplikacja do obsługi aparatu używała interfejsu API systemu.

Nazwa metody to android.hardware.camera2.CameraDevice#createCustomCaptureSession. Zobacz: frameworks/base/core/java/android/hardware/camera2/CameraDevice.

onCaptureQueueEmpty

Celem tego interfejsu API jest zmniejszenie opóźnienia zmian ustawień, takich jak przybliżanie i oddalanie, przez utrzymywanie kolejki żądań w jak największym stopniu pustej. onCaptureQueueEmptynie wymaga pracy nad HAL; było to tylko rozszerzenie frameworku. Aplikacje, które chcą z niego korzystać, muszą dodać do niego słuchacza i odpowiednio na niego zareagować. Zazwyczaj polega to na wysłaniu kolejnego żądania przechwycenia do urządzenia z kamerą.

Interfejs HIDL aparatu

Interfejs Camera HIDL to całkowicie przebudowany interfejs Camera HAL, który korzysta ze stabilnych interfejsów API zdefiniowanych w HIDL. Wszystkie funkcje i możliwości aparatu wprowadzone w najnowszych starszych wersjach 3.4 i 2.4 (dla modułu aparatu) są również częścią definicji HIDL.

3.4

Niewielkie dodatki do obsługiwanych metadanych i zmiany w obsłudze danych_przestrzeni:

  • Dodaj metadane statyczne ANDROID_SENSOR_OPAQUE_RAW_SIZE jako obowiązkowe, jeśli format RAW_OPAQUE jest obsługiwany.
  • Dodaj ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statyczne metadane jako wymagane, jeśli obsługiwany jest dowolny format RAW.
  • Zmień pole camera3_stream_t data_space na bardziej elastyczną definicję, używając wersji 0 definicji kodowania przestrzeni danych.
  • Dodatki metadanych ogólnych, które można używać w HALv3.2 lub nowszej wersji:
    • 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

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • Aktualizacje interfejsu API dotyczące przetwarzania OPAQUE i YUV.
  • Podstawowa obsługa buforów danych wyjściowych głębi.
  • Dodano pole data_space do tabeli camera3_stream_t.
  • Dodano pole rotacji do camera3_stream_t.
  • Dodano tryb konfiguracji strumienia camera3 do camera3_stream_configuration_t.

3.2

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • Wycofane: get_metadata_vendor_tag_ops. Zamiast tego użyj w kolumnie camera_common.h wartości get_vendor_tag_ops.
  • Wycofane: register_stream_buffers. Wszystkie bufory gralloc udostępniane przez framework do HAL w process_capture_request mogą być nowe w dowolnym momencie.
  • Dodaj obsługę częściowych wyników. process_capture_result może być wywoływany wielokrotnie z podzbiorem dostępnych wyników, zanim będzie dostępny pełny wynik.
  • Dodaj szablon ręczny do camera3_request_template. Aplikacje mogą używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania.
  • Zmienić specyfikacje strumieni danych dwukierunkowych i wejściowych.
  • Zmień ścieżkę powrotu bufora wejściowego. Bufor jest zwracany w formie process_capture_result zamiast process_capture_request.

3.1

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • configure_streams przekazuje flagi użytkowania przez konsumenta do HAL.
  • wywołanie flush, aby jak najszybciej odrzucić wszystkie bieżące żądania/bufory;

3,0

Pierwsza wersja HAL z rozszerzonymi możliwościami:

  • Główna zmiana wersji, ponieważ ABI jest zupełnie inny. Nie ma zmian w wymaganych możliwościach sprzętowych ani modelu operacyjnym w wersji 2.0.
  • Przerobione interfejsy kolejek żądań wejściowych i strumieni: wywołania frameworku w HAL z kolejną prośbą i buforami strumienia już wyjętymi z kolejki. Dodano obsługę ramowego interfejsu synchronizacji, która jest niezbędna do wydajnej implementacji.
  • Przeniesienie żądań do żądań, a większości powiadomień do wyników.
  • Połączono wszystkie wywołania zwrotne w ramach frameworku w jedną strukturę, a wszystkie metody konfiguracji w jednym wywołaniu initialize().
  • Aby uprościć zarządzanie strumieniami, wprowadziliśmy konfigurację strumienia w ramach pojedynczego wywołania. Strumienie dwukierunkowe zastępują konstrukcję STREAM_FROM_STREAM.
  • Semantyka trybu ograniczonego dostępu dla starszych lub ograniczonych urządzeń.

2,0

Pierwsza wersja interfejsu HAL z rozszerzonymi możliwościami (Android 4.2) [camera2.h]:

  • Wystarczający do implementacji istniejącego interfejsu API android.hardware.Camera.
  • Umożliwia kolejkę ZSL na poziomie usługi aparatu.
  • Nie testowano nowych funkcji, takich jak ręczna kontrola rejestrowania, rejestrowanie w formacie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1,0

Początkowy interfejs HAL aparatu Androida (Android 4.0) [camera.h]:

  • Przekształcony z poziomu abstrakcji CameraHardwareInterface w C++.
  • Obsługuje interfejs android.hardware.Camera API.

Historia wersji modułu kamery

Ta sekcja zawiera informacje o wersjach modułu aparatu na podstawie camera_module_t.common.module_api_version. 2 najbardziej znaczące cyfry szesnastkowe oznaczają wersję główną, a 2 najmniej znaczące – wersję podrzędną.

2.4

Ta wersja modułu aparatu wprowadza te zmiany w interfejsie API:

  1. Obsługa trybu latarki. Framework może włączyć tryb latarki na dowolnym urządzeniu z kamerą, które ma lampę błyskową, bez otwierania urządzenia. Urządzenie z kamerą ma wyższy priorytet dostępu do jednostki lampy błyskowej niż moduł kamery. Otwarcie urządzenia z kamerą wyłącza lampę błyskową, jeśli została włączona za pomocą interfejsu modułu. W przypadku konfliktów zasobów, takich jak wywołanie open() w celu otwarcia urządzenia z kamerą, moduł HAL kamery musi poinformować framework za pomocą wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony.
  2. Obsługa kamery zewnętrznej (np. kamery USB z podłączeniem „gorącego wtyczka”). Aktualizacje interfejsu API określają, że informacje statystyczne kamery są dostępne tylko wtedy, gdy kamera jest podłączona i gotowa do użycia w przypadku zewnętrznych kamer typu „hot-plug”. Wywołania dotyczące informacji o statycznej są nieprawidłowe, gdy stan kamery nie jest CAMERA_DEVICE_STATUS_PRESENT. Aby zarządzać listą dostępnych zewnętrznych kamer, framework korzysta wyłącznie z połączeń zwrotnych zmiany stanu urządzenia.
  3. Wskazówki dotyczące arbitrażu kamery Dodano obsługę wyraźnego wskazywania liczby urządzeń z kamerą, które można otwierać i używać jednocześnie. Aby określić prawidłowe kombinacje urządzeń, w strukturze camera_info zwracanej przez wywołanie get_camera_info należy zawsze ustawić pola resource_cost i conflicting_devices.
  4. Metoda inicjowania modułu. Jest wywoływany przez usługę aparatu po załadowaniu modułu HAL, aby umożliwić jednorazową jego inicjalizację. Jest on wywoływany przed wywołaniem innych metod modułu.

2.3

Ta wersja modułu aparatu dodaje obsługę starszych urządzeń z otwartym interfejsem HAL aparatu. Framework może użyć tego klucza, aby otworzyć urządzenie z kamerą jako urządzenie z niższą wersją interfejsu HAL, jeśli to samo urządzenie obsługuje wiele wersji interfejsu API urządzenia. Standardowy wywołanie do otwierania modułu sprzętowego (common.methods->open) nadal otwiera urządzenie z kamerą w najnowszej obsługiwanej wersji, która jest też wersją wymienioną w camera_info_t.device_version.

2.2

Ta wersja modułu aparatu dodaje obsługę tagów dostawcy z modułu i zastępuje stare tagi vendor_tag_query_ops, które były wcześniej dostępne tylko po otwarciu urządzenia.

2.1

Ta wersja modułu aparatu dodaje obsługę asynchronicznych wywołań zwrotnych do frameworku z modułu HAL aparatu, który służy do informowania frameworku o zmianach stanu modułu aparatu. Moduły, które udostępniają prawidłową metodę set_callbacks(), muszą podawać co najmniej tę wersję.

2,0

Moduł aparatu, który zgłasza ten numer wersji, implementuje drugą wersję interfejsu HAL aparatu. Urządzenia z aparatem, które można otworzyć za pomocą tego modułu, mogą obsługiwać wersję 1.0 lub 2.0 interfejsu HAL. Pole device_version w camera_info jest zawsze ważne; pole static_camera_characteristics w camera_info jest ważne, jeśli pole device_version ma wartość 2.0 lub wyższą.

1,0

Moduł aparatu, który zgłasza te numery wersji, implementuje początkowy interfejs HAL aparatu. Wszystkie urządzenia z kamerą, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 komponentu HAL urządzenia z kamerą. Pola device_version i static_camera_characteristics w rekordzie camera_info są nieprawidłowe. Ten moduł i połączone z nim urządzenia obsługują tylko interfejs API android.hardware.Camera.