Obsługa wersji kamery

Ta strona zawiera szczegółowe informacje o różnicach wersji w warstwach HAL aparatu, interfejsach API i powiązanych testach zestawu testów zgodności (CTS) . Obejmuje również kilka zmian architektonicznych wprowadzonych w celu wzmocnienia i zabezpieczenia struktury kamery w systemie Android 7.0, przejście na Treble w systemie Android 8.0 oraz dostawców aktualizacji, które muszą wprowadzić, aby obsłużyć te zmiany w swoich implementacjach kamery.

Terminologia

Na tej stronie używane są następujące terminy:

API kamery1
Struktura aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 i niższym, udostępniona przez klasę android.hardware.Camera .
API kamery2
Struktura aparatu na poziomie aplikacji na urządzeniach z systemem Android 5.0 i nowszych, udostępniona za pośrednictwem pakietu android.hardware.camera2 .
Kamera HAL
Warstwa modułu kamery zaimplementowana przez dostawców SoC. Struktury publiczne na poziomie aplikacji są zbudowane na bazie warstwy HAL aparatu.
Kamera HAL3.1
Wersja urządzenia z kamerą HAL wydana z systemem Android 4.4.
Kamera HAL3.2
Wersja urządzenia z kamerą HAL wydana z systemem Android 5.0.
Kamera API1 CTS
Zestaw testów CTS kamer, które działają na interfejsie Camera API1.
Kamera API2 CTS
Dodatkowy zestaw testów CTS kamery, które działają na interfejsie Camera API2.
Potroić
Oddziela implementację dostawcy (specyficzne dla urządzenia oprogramowanie niższego poziomu napisane przez producentów krzemu) od struktury systemu operacyjnego Android za pomocą nowego interfejsu dostawcy.
HIDL
Język definicji interfejsu HAL wprowadzony wraz z Treble i używany do określania interfejsu między warstwą HAL a jej użytkownikami.
VTS
Zestaw testowy dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android zawiera następujące interfejsy API aparatu.

API kamery1

Wycofany z Androida 5.0 interfejs Camera API1, który jest stopniowo wycofywany, ponieważ rozwój nowej platformy koncentruje się na interfejsie Camera API2. Jednak okres wycofywania będzie długi, a wersje Androida będą przez jakiś czas nadal obsługiwać aplikacje Camera API1. W szczególności wsparcie jest kontynuowane dla:

  • Interfejsy API1 aparatu dla aplikacji. Aplikacje aparatu oparte na interfejsie Camera API1 powinny działać tak samo, jak na urządzeniach z niższymi wersjami Androida.
  • Wersje kamery HAL. Zawiera wsparcie dla kamery HAL1.0.

API kamery2

Struktura Camera API2 udostępnia aplikacji kontrolę nad kamerą na niższym poziomie, w tym wydajne przepływy serii/strumieniowania bez kopii oraz kontrolę ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, odszumiania, wyostrzania i innych. Aby uzyskać szczegółowe informacje, obejrzyj omówienie wideo Google I/O .

Android 5.0 i nowszy zawiera interfejs Camera API2; jednak urządzenia z systemem Android 5.0 lub nowszym mogą nie obsługiwać wszystkich funkcji interfejsu Camera API2. Właściwość android.info.supportedHardwareLevel , do której aplikacje mogą wysyłać zapytania za pośrednictwem interfejsów Camera API2, zgłasza jeden z następujących poziomów obsługi:

  • LEGACY : te urządzenia udostępniają możliwości aplikacjom za pośrednictwem interfejsów Camera API2, które są w przybliżeniu takie same, jak te udostępniane aplikacjom za pośrednictwem interfejsów Camera API1. Kod starszego frameworka koncepcyjnie tłumaczy wywołania interfejsu Camera API2 na wywołania interfejsu Camera API1; starsze urządzenia nie obsługują funkcji interfejsu Camera API2, takich jak kontrolki na klatkę.
  • LIMITED : Te urządzenia obsługują niektóre funkcje interfejsu Camera API2 (ale nie wszystkie) i muszą używać Camera HAL 3.2 lub nowszego.
  • FULL : te urządzenia obsługują wszystkie główne funkcje interfejsu Camera API2 i muszą używać Camera HAL 3.2 lub nowszego oraz Androida 5.0 lub nowszego.
  • LEVEL_3 : te urządzenia obsługują przetwarzanie YUV i przechwytywanie obrazów RAW, a także dodatkowe konfiguracje strumienia wyjściowego.
  • EXTERNAL : Te urządzenia są podobne do urządzeń LIMITED z pewnymi wyjątkami; na przykład niektóre informacje z czujnika lub obiektywu mogą nie być zgłaszane lub mieć mniej stabilne szybkości klatek. Ten poziom jest używany w przypadku kamer zewnętrznych, takich jak kamery internetowe USB.

Poszczególne możliwości są ujawniane za pomocą właściwości android.request.availableCapabilities w interfejsach Camera API2. FULL urządzenia wymagają między innymi możliwości MANUAL_SENSOR i MANUAL_POST_PROCESSING . Możliwość RAW jest opcjonalna nawet dla urządzeń FULL . Urządzenia LIMITED mogą reklamować dowolny podzbiór tych możliwości, w tym żadnej z nich. Jednak zdolność BACKWARD_COMPATIBLE musi być zawsze zdefiniowana.

Obsługiwany poziom sprzętowy urządzenia, a także określone funkcje interfejsu Camera API2, które obsługuje, są dostępne jako następujące flagi funkcji, aby umożliwić filtrowanie przez Google Play aplikacji aparatu 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

Wymagania CTS

Urządzenia z systemem Android 5.0 lub nowszym muszą przejść testy aparatu Camera API1 CTS, Camera API2 CTS i CTS Verifier.

Urządzenia, które nie obsługują implementacji Camera HAL3.2 i nie są w stanie obsługiwać pełnych interfejsów Camera API2, nadal muszą przejść testy Camera API2 CTS. Jednak urządzenie działa w trybie Camera API2 LEGACY (w którym wywołania interfejsu Camera API2 są koncepcyjnie mapowane na wywołania interfejsu Camera API1), więc wszelkie 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 Camera API2 CTS, które są uruchamiane, wykorzystują istniejące publiczne interfejsy i możliwości interfejsu Camera API1 bez nowych wymagań. Ujawnione błędy (które powodują awarię interfejsu Camera API2 CTS) są błędami już obecnymi w istniejącej warstwie Camera HAL urządzenia, a zatem mogą zostać znalezione przez istniejące aplikacje Camera API1. Nie spodziewamy się wielu błędów tego rodzaju (jednak każdy taki błąd musi zostać naprawiony, aby przejść testy Camera API2 CTS).

Wymagania VTS

Urządzenia z systemem Android 8.0 lub nowszym z implementacjami HAL zbinderyzowanymi muszą przejść testy Camera VTS .

Utwardzanie ramy kamery

Aby wzmocnić zabezpieczenia struktury mediów i aparatu, system Android 7.0 przenosi usługę aparatu z serwera mediów. Począwszy od systemu Android 8.0, każda powiązana warstwa HAL aparatu działa w procesie niezależnym od usługi aparatu. Dostawcy mogą wymagać wprowadzenia zmian w warstwie HAL aparatu w zależności od używanych wersji interfejsu API i HAL. Poniższe sekcje szczegółowo opisują zmiany architektoniczne w AP1 i AP2 dla HAL1 i HAL3, a także ogólne wymagania.

Zmiany architektoniczne dla API1

Nagrywanie wideo API1 może obejmować kamerę i koder wideo na żywo w tym samym procesie. W przypadku korzystania z API1 na:

  • HAL3, gdzie usługa kamery używa BufferQueue do przekazywania buforów między procesami, nie jest wymagana aktualizacja dostawcy .

    Stos kamer i multimediów Androida 7.0 w API1 na HAL3

    Rysunek 1. Stos kamer i multimediów Androida 7.0 w API1 na HAL3

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

    Stos kamer i multimediów Androida 7.0 w API1 na HAL1

    Rysunek 2. Stos kamer i multimediów Androida 7.0 w API1 na HAL1

Zmiany architektoniczne dla API2

W przypadku interfejsu API2 w warstwie HAL1 lub HAL3 BufferQueue przekazuje bufory, aby te ścieżki nadal działały. Architektura Androida 7.0 dla API2 na:

  • Przeniesienie usługi cameraservice nie ma wpływu na warstwę HAL1 i nie jest wymagana aktualizacja dostawcy .
  • Problem dotyczy warstwy HAL3, ale nie jest wymagana aktualizacja dostawcy :

    Stos kamer i multimediów Androida 7.0 w API2 na HAL3

    Rysunek 3. Stos kamer i multimediów Androida 7.0 w API2 na HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w celu wzmocnienia zabezpieczeń nośników i struktury kamery obejmują następujące dodatkowe wymagania dotyczące urządzeń.

  • Ogólny. 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 liczy się czas, takie jak nagrywanie wideo z dużą szybkością. Sprzedawcy mogą mierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Aparat Google do nagrywania wideo z dużą szybkością 120/240 kl./s. Urządzenia wymagają również niewielkiej ilości dodatkowej pamięci RAM, aby utworzyć nowy proces.
  • Przekaż metadane w buforach wideo ( tylko HAL1 ). Jeśli HAL1 przechowuje metadane zamiast prawdziwych danych ramki YUV w buforach wideo, HAL musi używać kMetadataBufferTypeNativeHandleSource jako typu bufora metadanych i przekazywać VideoNativeHandleMetadata w buforach wideo. ( kMetadataBufferTypeCameraSource nie jest już obsługiwany w systemie Android 7.0.) Dzięki VideoNativeHandleMetadata kamery i multimediów są w stanie przekazywać bufory wideo między procesami przez prawidłowe serializowanie i deserializację uchwytów natywnych.
  • Adres uchwytu bufora nie zawsze przechowuje ten sam bufor ( tylko HAL3 ). Dla 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. Należy zaktualizować warstwę HAL, aby używać uchwytów buforów do identyfikowania buforów. Na przykład HAL odbiera uchwyt bufora o adresie A, który przechowuje uchwyt bufora A. Po zwróceniu przez HAL uchwytu bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B następnym razem, gdy HAL go odbierze.
  • Zaktualizuj zasady SELinux dla serwera kamery. Jeśli polityki SELinux dla poszczególnych urządzeń dają serwerowi mediów uprawnienia do uruchamiania aparatu, musisz zaktualizować zasady SELinux, aby nadać serwerowi aparatu odpowiednie uprawnienia. Odradzamy replikowanie polityk SELinux serwera medialnego dla serwera kamery (ponieważ mediaserver i cameraserver generalnie wymagają różnych zasobów w systemie). Cameraserver powinien mieć tylko uprawnienia potrzebne do wykonywania funkcji kamery, a wszelkie niepotrzebne uprawnienia związane z kamerą w mediaserverze powinny zostać usunięte.
  • Separacja między kamerą HAL a serwerem kamery. Android 8.0 i nowsze dodatkowo oddzielają powiązaną warstwę HAL kamery w procesie innym niż serwer kamery. IPC przechodzi przez interfejsy zdefiniowane przez HIDL .

Walidacja

W przypadku wszystkich urządzeń z kamerą i systemem Android 7.0 zweryfikuj implementację, uruchamiając system Android 7.0 CTS. Chociaż system Android 7.0 nie zawiera nowych testów CTS, które weryfikują zmiany w usługach aparatu, istniejące testy CTS kończą się niepowodzeniem, jeśli nie wprowadzono wyżej wskazanych aktualizacji.

W przypadku wszystkich urządzeń, które zawierają kamerę i działają w systemie Android 8.0 lub nowszym, zweryfikuj implementację dostawcy, uruchamiając VTS.

Historia wersji kamery HAL

Aby zapoznać się z listą testów dostępnych do oceny warstwy HAL aparatu Android, zobacz Lista kontrolna testowania warstwy HAL aparatu .

Androida 10

Android 10 wprowadza następujące aktualizacje.

Interfejs API aparatu

Kamera HAL

Następujące wersje Camera HAL zostały zaktualizowane w systemie Android 10.

3,5

ICameraDevice

  • getPhysicalCameraCharacteristics : statyczne informacje o kamerze dla fizycznego identyfikatora kamery obsługującego logiczne urządzenie kamery. Zobacz Obsługa wielu kamer .
  • isStreamCombinationSupported : ta metoda obsługuje publiczny interfejs API, który pomaga klientom sprawdzać, czy konfiguracja sesji jest obsługiwana. Zobacz API do zapytań o kombinacje strumieni .

ICameraDeviceSession

  • isReconfigurationNeeded : metoda, która informuje strukturę kamery, czy wymagana jest pełna rekonfiguracja strumienia dla ewentualnych nowych wartości parametrów sesji. Pomaga to uniknąć niepotrzebnych opóźnień w ponownej konfiguracji kamery. Zobacz Zapytanie o rekonfigurację sesji .
  • Interfejsy API zarządzania buforem HAL : te interfejsy API pozwalają kamerze HAL żądać buforów z platformy kamery tylko wtedy, gdy jest to wymagane, zamiast łączyć każde żądanie przechwytywania z powiązanymi buforami w całym potoku kamery, co daje potencjalnie znaczne oszczędności pamięci.
    • signalStreamFlush : sygnalizuje warstwie HAL, że usługa kamery zamierza wykonać configureStreams_3_5 i że warstwa HAL musi zwrócić wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5 : podobny do ICameraDevice3.4.configureStreams , ale dodatkowo dostępny jest licznik streamConfigCounter do sprawdzania wyścigu między wywołaniami configureStreams_3_5 i signalStreamFlush .

Aktualizacje ICameraDeviceCallback :

  • requestStreamBuffers : Synchroniczne wywołanie zwrotne, które wywołuje warstwa HAL kamery, aby poprosić serwer kamery o bufory. Zobacz requestStreamBuffers .
  • returnStreamBuffers : Synchroniczne wywołanie zwrotne dla warstwy HAL kamery w celu zwrócenia buforów wyjściowych do serwera kamery. Zobacz returnStreamBuffers .

3.4

Następujące klawisze są dodawane do metadanych aparatu w systemie Android 10.

  • Formaty obrazu
    • 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 dynamicznego strumienia głębokości
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
  • Dostępne konfiguracje strumieni HEIC
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Moduł kamery

Następujące wersje modułu aparatu zostały zaktualizowane w systemie Android 10.

2,5

  • Dodaje metodę notifyDeviceStateChange , aby urządzenia powiadamiały warstwę HAL kamery, gdy fizyczne zmiany, takie jak składanie, wpływają na kamerę i routing.

2,4

  • Urządzenia uruchamiane z interfejsem API 29 lub wyższym MUSZĄ zgłosić true dla isTorchModeSupported .

Android 9

Wersja Androida 9 wprowadza następujące aktualizacje interfejsu API2 i HAL aparatu.

Interfejs API aparatu

  • Wprowadza interfejs API wielu kamer, aby lepiej obsługiwać urządzenia z wieloma kamerami skierowanymi w tym samym kierunku, umożliwiając takie funkcje, jak bokeh i płynne powiększanie. Dzięki temu aplikacje mogą wyświetlać wiele kamer na urządzeniu jako jedną jednostkę logiczną (kamera logiczna). Żądania przechwycenia można również wysyłać do poszczególnych urządzeń kamer objętych jedną kamerą logiczną. Zobacz Obsługa wielu kamer .
  • Wprowadza parametry sesji. Parametry sesji stanowią podzbiór dostępnych parametrów przechwytywania, które po zmodyfikowaniu mogą powodować poważne opóźnienia w przetwarzaniu. Koszty te można ograniczyć, jeśli klienci przekażą swoje wartości początkowe podczas inicjowania sesji przechwytywania. Zobacz Parametry sesji .
  • Dodaje klawisze danych stabilizacji optycznej (OIS) dla stabilizacji i efektów na poziomie aplikacji. Zobacz STATISTICS_OIS_SAMPLES .
  • Dodaje obsługę zewnętrznej lampy błyskowej. Zobacz CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Dodaje intencję śledzenia ruchu w CAPTURE_INTENT . Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • LENS_RADIAL_DISTORTION i dodaje w jego miejsce LENS_DISTORTION .
  • Dodaje tryby korekcji zniekształceń w CaptureRequest . Zobacz DISTORTION_CORRECTION_MODE .
  • Dodaje obsługę zewnętrznych kamer USB/UVC na obsługiwanych urządzeniach. Zobacz INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Kamera HAL

3.4

Aktualizacje ICameraDeviceSession

Aktualizacje ICameraDeviceCallback

3,3

Następujące klawisze są dodawane do metadanych aparatu w systemie Android 9.

  • 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

Wersja Androida 8.0 wprowadza Treble. W przypadku Treble implementacje Camera HAL dostawcy muszą być zbindowane . Android 8.0 zawiera również te kluczowe ulepszenia usługi Aparat:

  • Udostępnione powierzchnie: Włącz wiele powierzchni współdzielących tę samą OutputConfiguration
  • Systemowe API dla niestandardowych trybów aparatu
  • onCaptureQueueEmpty

Więcej informacji na temat tych funkcji znajdziesz w poniższych sekcjach.

Wspólne powierzchnie

Ta funkcja umożliwia tylko jeden zestaw 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ą zapewnić, że ich implementacje warstwy HAL i gralloc HAL w kamerach mogą tworzyć bufory gralloc, które są używane przez wielu różnych konsumentów (takich jak kompozytor/GPU i koder wideo), a nie tylko przez jednego konsumenta. Usługa kamery przekazuje flagi użytkowania przez konsumenta do warstwy HAL kamery i warstwy HAL gralloc; muszą albo przydzielić odpowiednie rodzaje buforów, albo HAL kamery musi zwrócić błąd, że ta kombinacja konsumentów nie jest obsługiwana.

Więcej informacji można znaleźć w dokumentacji dla programistów enableSurfaceSharing .

Systemowe API dla niestandardowych trybów aparatu

Interfejs API kamery publicznej definiuje dwa tryby pracy: normalne i ograniczone nagrywanie z dużą szybkością. Mają dość inną semantykę; na przykład tryb szybki jest ograniczony do co najwyżej dwóch określonych wyjść jednocześnie. Różni producenci OEM wyrazili zainteresowanie zdefiniowaniem innych niestandardowych trybów dla funkcji specyficznych dla sprzętu. Pod maską tryb jest tylko liczbą całkowitą przekazaną do configure_streams . Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Ta funkcja obejmuje systemowe wywołanie interfejsu API, którego aplikacje aparatu OEM mogą używać do włączania trybu niestandardowego. Te tryby muszą zaczynać się od wartości całkowitej 0x8000, aby uniknąć konfliktu z przyszłymi trybami dodanymi do publicznego interfejsu API.

Aby obsługiwać tę funkcję, producenci OEM muszą jedynie dodać nowy tryb do swojej warstwy HAL, wyzwalany przez tę liczbę całkowitą przekazaną do warstwy HAL w configure_streams, a następnie zlecić swojej niestandardowej aplikacji aparatu korzystanie z systemowego interfejsu API.

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

onCaptureQueuePusty

Celem tego interfejsu API jest skrócenie czasu oczekiwania na zmiany kontroli, takie jak powiększanie, poprzez utrzymywanie jak największej liczby żądań w kolejce żądań. onCaptureQueueEmpty nie wymaga żadnej pracy z HAL; był to wyłącznie dodatek po stronie frameworka. Aplikacje, które chcą z niego skorzystać, muszą dodać słuchacza do tego wywołania zwrotnego i odpowiednio zareagować. Zwykle polega to na wysłaniu kolejnego żądania przechwycenia do urządzenia z kamerą.

Interfejs kamery HIDL

Interfejs Camera HIDL to kompletna przebudowa interfejsu Camera HAL, który wykorzystuje stabilne interfejsy API zdefiniowane przez HIDL. Wszystkie funkcje i możliwości kamery wprowadzone w najnowszych starszych wersjach 3.4 i 2.4 (dla modułu kamery) są również częścią definicji HIDL.

3.4

Drobne dodatki do obsługiwanych metadanych i zmiany w obsłudze data_space:

  • Dodaj statyczne metadane ANDROID_SENSOR_OPAQUE_RAW_SIZE jako obowiązkowe, jeśli format RAW_OPAQUE jest obsługiwany.
  • Dodaj statyczne metadane ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE jako obowiązkowe, jeśli obsługiwany jest dowolny format RAW.
  • Przełącz pole camera3_stream_t data_space na bardziej elastyczną definicję, używając definicji kodowania przestrzeni danych w wersji 0.
  • Ogólne dodatki do metadanych, które są dostępne w wersji HALv3.2 lub nowszej:
    • 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

Drobna zmiana warstwy HAL o rozszerzonych możliwościach:

  • Aktualizacje API przetwarzania OPAQUE i YUV.
  • Podstawowe wsparcie dla buforów wyjściowych głębokości.
  • Dodanie pola data_space do camera3_stream_t .
  • Dodanie pola rotacji do camera3_stream_t .
  • Dodanie trybu pracy konfiguracji strumienia camera3 do camera3_stream_configuration_t .

3.2

Drobna zmiana warstwy HAL o rozszerzonych możliwościach:

  • get_metadata_vendor_tag_ops . Zamiast tego użyj get_vendor_tag_ops w pliku camera_common.h .
  • Przestarzałe register_stream_buffers . Wszystkie bufory gralloc dostarczone przez framework do HAL w process_capture_request mogą być nowe w dowolnym momencie.
  • Dodaj częściową obsługę wyników. process_capture_result może być wywoływany wiele razy z podzbiorem dostępnych wyników, zanim pełny wynik będzie dostępny.
  • Dodaj szablon instrukcji do camera3_request_template . Aplikacje mogą używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania.
  • Zmień specyfikacje strumienia dwukierunkowego i wejściowego.
  • Zmień ścieżkę powrotu bufora wejściowego. Bufor jest zwracany w process_capture_result zamiast process_capture_request .

3.1

Drobna zmiana warstwy HAL o rozszerzonych możliwościach:

  • configure_streams przekazuje flagi użytkowania konsumenta do warstwy HAL.
  • flush call, aby jak najszybciej usunąć wszystkie żądania/bufory w locie.

3,0

Pierwsza wersja HAL o rozszerzonych możliwościach:

  • Główna zmiana wersji, ponieważ ABI jest zupełnie inny. Brak zmiany wymaganych możliwości sprzętowych lub modelu operacyjnego z wersji 2.0.
  • Przerobione interfejsy żądań wejściowych i kolejki strumieniowej: Framework wywołuje HAL z kolejnymi żądaniami i buforami strumieni, które są już usunięte z kolejki. Uwzględniono obsługę frameworka Sync, niezbędną do wydajnych implementacji.
  • Przeniesiono wyzwalacze do żądań, większość powiadomień do wyników.
  • Skonsolidowano wszystkie wywołania zwrotne w ramach jednej struktury, a wszystkie metody konfiguracji w jednym wywołaniu initialize() .
  • Przekształciliśmy konfigurację strumienia w jedno wywołanie, aby uprościć zarządzanie strumieniem. Strumienie dwukierunkowe zastępują konstrukcję STREAM_FROM_STREAM .
  • Semantyka trybu ograniczonego dla starszych/ograniczonych urządzeń sprzętowych.

2,0

Pierwsze wydanie HAL o rozszerzonych możliwościach (Android 4.2) [camera2.h]:

  • Wystarczające do wdrożenia istniejącego API android.hardware.Camera .
  • Pozwala na kolejkę ZSL w warstwie obsługi aparatu.
  • Nie testowano pod kątem żadnych nowych funkcji, takich jak ręczne sterowanie przechwytywaniem, przechwytywanie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1,0

Początkowy HAL kamery Android (Android 4.0) [camera.h]:

  • Konwersja z warstwy abstrakcji CameraHardwareInterface w języku C++.
  • Obsługuje interfejs API android.hardware.Camera .

Historia wersji modułu kamery

Ta sekcja zawiera informacje o wersji modułu dla modułu sprzętowego aparatu na podstawie camera_module_t.common.module_api_version . Dwie najbardziej znaczące cyfry szesnastkowe reprezentują wersję główną, a dwie najmniej znaczące reprezentują wersję pomocniczą.

2,4

Ta wersja modułu aparatu dodaje następujące zmiany API:

  1. Obsługa trybu latarki. Platforma może włączyć tryb latarki dla dowolnego urządzenia fotograficznego wyposażonego w lampę błyskową, bez konieczności otwierania urządzenia z aparatem. Urządzenie z aparatem ma wyższy priorytet dostępu do lampy błyskowej niż moduł aparatu; otwarcie urządzenia z kamerą wyłącza latarkę, jeśli została włączona przez interfejs modułu. W przypadku wystąpienia konfliktu zasobów, na przykład wywołania open() w celu otwarcia urządzenia kamery, moduł HAL kamery musi powiadomić platformę za pomocą wywołania zwrotnego stanu trybu palnika, że ​​tryb palnika został wyłączony.
  2. Obsługa aparatu zewnętrznego (na przykład aparatu podłączanego podczas pracy USB). Aktualizacje API określają, że informacje statyczne kamery są dostępne tylko wtedy, gdy kamera jest podłączona i gotowa do użycia z zewnętrznymi kamerami typu hot-plug. Wywołania w celu uzyskania informacji statycznych są nieprawidłowe, gdy stan kamery jest inny niż CAMERA_DEVICE_STATUS_PRESENT . Struktura liczy wyłącznie na wywołania zwrotne zmiany stanu urządzenia w celu zarządzania dostępną listą kamer zewnętrznych.
  3. Wskazówki dotyczące arbitrażu kamery. Dodaje obsługę wyraźnego wskazywania liczby urządzeń z kamerami, które mogą być jednocześnie otwierane i używane. Aby określić prawidłowe kombinacje urządzeń, pola resource_cost i camera_info conflicting_devices przez wywołanie get_camera_info .
  4. Metoda inicjalizacji modułu. Wywoływany przez usługę kamery po załadowaniu modułu HAL, aby umożliwić jednorazową inicjalizację warstwy HAL. Jest wywoływana przed wywołaniem jakichkolwiek innych metod modułu.

2,3

Ta wersja modułu kamery dodaje obsługę urządzeń HAL dla starszych kamer. Struktura może go użyć do otwarcia urządzenia kamery jako urządzenia HAL w wersji niższej, jeśli to samo urządzenie może obsługiwać wiele wersji interfejsu API urządzenia. Standardowe wywołanie otwartego modułu sprzętowego ( common.methods->open ) kontynuuje otwieranie aparatu z najnowszą obsługiwaną wersją, która jest również 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 wycofuje starą vendor_tag_query_ops , która była wcześniej dostępna tylko przy otwartym urządzeniu.

2,1

Ta wersja modułu kamery dodaje obsługę asynchronicznych wywołań zwrotnych do frameworka z modułu HAL kamery, który jest używany do powiadamiania frameworka o zmianach stanu modułu kamery. Moduły, które zapewniają poprawną set_callbacks() , muszą zgłaszać co najmniej ten numer wersji.

2,0

Moduły kamery, które zgłaszają ten numer wersji, implementują drugą wersję interfejsu HAL modułu kamery. Urządzenia kamery otwierane za pomocą tego modułu mogą obsługiwać wersję 1.0 lub wersję 2.0 interfejsu HAL urządzenia kamery. Pole device_version w camera_info jest zawsze prawidłowe; pole static_camera_characteristics w camera_info jest prawidłowe, jeśli pole device_version ma wartość 2.0 lub wyższą.

1,0

Moduły kamery, które zgłaszają te numery wersji, implementują początkowy interfejs HAL modułu kamery. Wszystkie urządzenia z kamerami, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 warstwy HAL urządzenia z kamerą. Pola device_version i static_camera_characteristics w camera_info są nieprawidłowe. Tylko interfejs API android.hardware.Camera może być obsługiwany przez ten moduł i jego urządzenia.