Obsługa wersji aparatu

Na tej stronie szczegółowo opisano różnice w wersjach aplikacji Camera HAL, API i powiązanych testach Compatibility Test Suite (CTS) . Omówiono także kilka zmian architektonicznych wprowadzonych w celu wzmocnienia i zabezpieczenia platformy aparatu w systemie Android 7.0, przejście na Treble w systemie Android 8.0 oraz aktualizacje, które dostawcy muszą wprowadzić, aby wspierać te zmiany w swoich implementacjach kamer.

Terminologia

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

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

Interfejsy API aparatu

Android zawiera następujące interfejsy API aparatu.

API aparatu 1

Android 5.0 wycofał interfejs Camera API1, który jest nadal wycofywany, ponieważ rozwój nowej platformy koncentruje się na Camera API2. Okres wycofywania będzie jednak długi i przez pewien czas wersje systemu Android będą nadal obsługiwać aplikacje Camera API1. W szczególności wsparcie będzie kontynuowane dla:

  • Interfejsy API1 aparatu dla aplikacji. Aplikacje aparatu zbudowane na bazie interfejsu Camera API1 powinny działać tak samo, jak na urządzeniach z niższymi wersjami Androida.
  • Wersje kamery HAL. Zawiera obsługę kamery HAL1.0.

API aparatu 2

Struktura Camera API2 umożliwia aplikacji sterowanie kamerą niższego poziomu, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania oraz kontrolę ekspozycji, wzmocnienia, wzmocnienia balansu bieli, konwersji kolorów, usuwania szumów, wyostrzania i nie tylko. Aby uzyskać szczegółowe informacje, obejrzyj przegląd wideo Google I/O .

Android 5.0 i nowsze wersje zawierają Camera API2; jednakże urządzenia z systemem Android 5.0 i nowszym mogą nie obsługiwać wszystkich funkcji 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 wsparcia:

  • LEGACY : Te urządzenia udostępniają aplikacjom możliwości za pośrednictwem interfejsów Camera API2, które mają w przybliżeniu takie same możliwości, jak te udostępniane aplikacjom za pośrednictwem interfejsów Camera API1. Kod starszej struktury koncepcyjnie tłumaczy wywołania Camera API2 na wywołania Camera API1; starsze urządzenia nie obsługują funkcji Camera API2, takich jak kontrola poszczególnych klatek.
  • LIMITED : Te urządzenia obsługują niektóre funkcje Camera API2 (ale nie wszystkie) i muszą korzystać z Camera HAL 3.2 lub nowszego.
  • FULL : Te urządzenia obsługują wszystkie główne możliwości interfejsu Camera API2 i muszą korzystać z aplikacji Camera HAL 3.2 lub nowszej oraz systemu Android 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ć raportowane lub mieć mniej stabilną liczbę klatek na sekundę. Ten poziom jest używany w przypadku kamer zewnętrznych, takich jak kamery internetowe USB.

Poszczególne możliwości są udostępniane poprzez właściwość android.request.availableCapabilities w interfejsach Camera API2. Urządzenia FULL wymagają między innymi możliwości MANUAL_SENSOR i MANUAL_POST_PROCESSING . Możliwość RAW jest opcjonalna nawet w przypadku urządzeń FULL . Urządzenia LIMITED mogą reklamować dowolny podzbiór tych funkcji, w tym żadną z nich. Jednak zawsze należy zdefiniować funkcję BACKWARD_COMPATIBLE .

Obsługiwany poziom sprzętu urządzenia, a także konkretne obsługiwane przez nie funkcje Camera API2 są dostępne jako następujące flagi funkcji umożliwiające Google Play filtrowanie 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 i nowszym muszą przejść testy aparatu Camera API1 CTS, Camera API2 CTS i CTS Verifier.

Urządzenia, które nie są wyposażone w implementację Camera HAL3.2 i nie są w stanie obsługiwać pełnych interfejsów Camera API2, muszą mimo to przejść testy CTS Camera API2. Jednakże urządzenie działa w trybie Camera API2 LEGACY (w którym wywołania Camera API2 są koncepcyjnie mapowane na wywołania Camera API1), więc wszelkie testy Camera API2 CTS związane z funkcjami lub możliwościami wykraczającymi poza Camera API1 są automatycznie pomijane.

Na starszych urządzeniach testy CTS Camera API2 przeprowadzane są przy użyciu istniejących publicznych interfejsów i możliwości Camera API1 bez nowych wymagań. Wykryte błędy (powodujące awarię CTS Camera API2) to błędy już obecne w istniejącej warstwie HAL Camera na urządzeniu i dlatego można je znaleźć w istniejących aplikacjach Camera API1. Nie spodziewamy się wielu błędów tego typu (jednak każdy taki błąd musi zostać naprawiony, aby przejść testy Camera API2 CTS).

Wymagania VTS

Urządzenia z systemem Android 8.0 i nowszym z powiązanymi implementacjami HAL muszą przejść testy Camera VTS .

Utwardzanie szkieletu aparatu

Aby zwiększyć bezpieczeństwo multimediów i kamer, Android 7.0 przenosi usługę kamery z serwera multimediów. Począwszy od systemu Android 8.0, każda powiązana warstwa HAL kamery działa w procesie niezależnym od usługi kamery. Dostawcy mogą być zobowiązani do wprowadzenia zmian w warstwie HAL kamery w zależności od używanej wersji interfejsu API i warstwy HAL. W poniższych sekcjach szczegółowo opisano 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 zakładać, że kamera i koder wideo działają w tym samym procesie. Podczas korzystania z API1 na:

  • HAL3, gdzie usługa kamery wykorzystuje BufferQueue do przekazywania buforów pomiędzy procesami, nie jest konieczna żadna aktualizacja dostawcy .

    Kamera i stos multimediów z Androidem 7.0 w API1 na HAL3

    Rysunek 1. Kamera i stos multimediów w systemie Android 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.)

    Kamera i stos multimediów z Androidem 7.0 w API1 na HAL1

    Rysunek 2. Kamera i stos multimediów w systemie Android 7.0 w API1 na HAL1

Zmiany architektoniczne dla API2

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

  • Przeniesienie usługi kamery nie ma wpływu na HAL1 i nie jest wymagana żadna aktualizacja dostawcy .
  • Dotyczy to HAL3, ale nie jest wymagana żadna aktualizacja dostawcy :

    Kamera i stos multimediów w systemie Android 7.0 w API2 na HAL3

    Rysunek 3. Kamera i stos multimediów w systemie Android 7.0 w API2 na HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w celu zwiększenia bezpieczeństwa nośników i szkieletu 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, np. nagrywanie wideo z dużą szybkością. Sprzedawcy mogą zmierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Google Camera do szybkiego nagrywania wideo z szybkością 120/240 kl./s. Urządzenia wymagają również niewielkiej ilości dodatkowej pamięci RAM, aby utworzyć nowy proces.
  • Przekazuj metadane w buforach wideo ( tylko HAL1 ). Jeśli warstwa HAL1 przechowuje metadane zamiast rzeczywistych danych ramki YUV w buforach wideo, warstwa 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 struktury kamer i multimediów mogą przekazywać bufory wideo między procesami poprzez prawidłową serializację i deserializację natywnych uchwytów.
  • Adres uchwytu bufora nie zawsze przechowuje ten sam bufor ( tylko HAL3 ). Dla każdego żądania przechwytywania HAL3 pobiera adresy uchwytów buforów. HAL nie może używać adresów do identyfikowania buforów, ponieważ adresy mogą przechowywać inny uchwyt bufora po tym, jak HAL zwróci bufor. Należy zaktualizować warstwę HAL, aby używać uchwytów buforów do identyfikowania buforów. Na przykład warstwa HAL odbiera adres uchwytu bufora A, który przechowuje uchwyt bufora A. Po tym, jak warstwa HAL zwróci uchwyt bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B następnym razem, gdy warstwa HAL go odbierze.
  • Zaktualizuj zasady SELinux dla serwera kamer. Jeśli zasady SELinux specyficzne dla urządzenia dają serwerowi multimediów uprawnienia do uruchamiania kamery, należy zaktualizować zasady SELinux, aby nadać serwerowi kamery odpowiednie uprawnienia. Odradzamy replikowanie zasad SELinux serwera multimediów dla serwera kamer (ponieważ serwer multimediów i serwer kamer zazwyczaj wymagają różnych zasobów w systemie). Serwer kamery powinien mieć jedynie uprawnienia potrzebne do wykonywania funkcji kamery, a wszelkie niepotrzebne uprawnienia związane z kamerą na serwerze multimediów powinny zostać usunięte.
  • Rozdzielenie pomiędzy kamerą HAL i serwerem kamer. Android 8.0 i nowsze dodatkowo oddzielają spakowaną kamerę HAL w procesie innym niż serwer kamery. IPC przechodzi przez interfejsy zdefiniowane w HIDL .

Walidacja

W przypadku wszystkich urządzeń wyposażonych w kamerę i działających pod kontrolą systemu Android 7.0 sprawdź implementację, uruchamiając system Android 7.0 CTS. Chociaż Android 7.0 nie zawiera nowych testów CTS weryfikujących zmiany w usługach aparatu, istniejące testy CTS nie powiodą się, jeśli nie dokonano wskazanych powyżej aktualizacji.

W przypadku wszystkich urządzeń wyposażonych w kamerę i korzystających z systemu Android 8.0 lub nowszego sprawdź implementację dostawcy, uruchamiając VTS.

Historia wersji kamery HAL

Listę testów dostępnych do oceny HAL aparatu Android znajdziesz na liście kontrolnej testowania HAL aparatu .

Androida 10

Android 10 wprowadza następujące aktualizacje.

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 identyfikatora kamery fizycznej wspierającego kamerę logiczną. Zobacz Obsługa wielu kamer .
  • isStreamCombinationSupported : Ta metoda obsługuje publiczny interfejs API, który pomaga klientom wysyłać zapytania, czy obsługiwana jest konfiguracja sesji. Zobacz API do sprawdzania kombinacji strumieni .

ICameraDeviceSession

  • isReconfigurationNeeded : Metoda informująca strukturę kamery, czy wymagana jest pełna rekonfiguracja strumienia w celu uzyskania ewentualnych nowych wartości parametrów sesji. Pomaga to uniknąć niepotrzebnych opóźnień w rekonfiguracji kamery. Zobacz Zapytanie o rekonfigurację sesji .
  • Interfejsy API zarządzania buforem HAL : te interfejsy API umożliwiają kamerze HAL żądanie buforów ze struktury kamery tylko wtedy, gdy jest to wymagane, zamiast łączenia każdego żądania przechwytywania z powiązanymi z nim buforami w całym potoku kamery, co skutkuje potencjalnie znaczną oszczędnością pamięci.
    • signalStreamFlush : Sygnalizuje warstwę HAL, że usługa kamery wkrótce 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 w celu sprawdzenia warunku wyścigu między configureStreams_3_5 i signalStreamFlush .

Aktualizacje ICameraDeviceCallback :

  • requestStreamBuffers : Synchroniczne wywołanie zwrotne wywoływane przez warstwę HAL kamery w celu zapytania serwera 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

Do metadanych aparatu w systemie Android 10 dodano następujące 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 dla 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łów aparatu zostały zaktualizowane w systemie Android 10.

2.5

  • Dodaje metodę notifyDeviceStateChange dla urządzeń, która powiadamia warstwę HAL kamery, gdy zmiany fizyczne, takie jak składanie, wpływają na kamerę i routing.

2.4

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

Androida 9

W wersji Androida 9 wprowadzono następujące aktualizacje interfejsu API2 i HAL aparatu.

API aparatu

  • Wprowadzono interfejs API obsługujący wiele kamer, aby lepiej obsługiwać urządzenia z wieloma kamerami skierowanymi w tym samym kierunku, umożliwiając korzystanie z takich funkcji, jak efekt bokeh i płynny zoom. Dzięki temu aplikacje mogą wyświetlać wiele kamer na urządzeniu jako jedną jednostkę logiczną (kamerę logiczną). Żądania przechwytywania można także wysyłać do poszczególnych 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 modyfikacji mogą powodować poważne opóźnienia przetwarzania. Koszty te można ograniczyć, jeśli klienci przekażą swoje wartości początkowe podczas inicjowania sesji przechwytywania. Zobacz Parametry sesji .
  • Dodaje klucze danych stabilizacji optycznej (OIS) do stabilizacji i efektów na poziomie aplikacji. Zobacz STATISTICS_OIS_SAMPLES .
  • Dodaje obsługę zewnętrznej lampy błyskowej. Patrz CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
  • Dodaje zamiar śledzenia ruchu w CAPTURE_INTENT . Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Wycofuje LENS_RADIAL_DISTORTION i dodaje w jego miejscu 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

Do metadanych aparatu w systemie Android 9 dodano następujące 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

Androida 8.0

W wersji Androida 8.0 wprowadzono Treble. W przypadku Treble implementacje HAL kamery dostawcy muszą być spakowane . Android 8.0 zawiera także następujące kluczowe ulepszenia usługi Aparat:

  • Powierzchnie współdzielone: ​​Włącz wiele powierzchni współdzielących tę samą OutputConfiguration
  • Interfejs API systemu dla niestandardowych trybów aparatu
  • onCaptureQueueEmpty

Więcej informacji na temat tych funkcji można znaleźć w poniższych sekcjach.

Wspólne powierzchnie

Ta funkcja umożliwia użycie 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ą upewnić się, że implementacje HAL i gralloc HAL w ich kamerach umożliwiają tworzenie buforów gralloc używanych przez wielu różnych konsumentów (takich jak sprzętowy kompozytor/GPU i koder wideo), a nie tylko jeden konsument. Usługa kamery przekazuje flagi użytkowania klienta do warstwy HAL kamery i warstwy HAL gralloc; muszą albo przydzielić odpowiednie rodzaje buforów, albo HAL kamery musi zwrócić błąd informujący, że ta kombinacja konsumentów nie jest obsługiwana.

Dodatkowe szczegóły można znaleźć w dokumentacji programisty enableSurfaceSharing .

Interfejs API systemu dla niestandardowych trybów aparatu

Interfejs API kamer publicznych definiuje dwa tryby działania: normalne i ograniczone nagrywanie z dużą szybkością. Mają dość odmienną semantykę; na przykład tryb dużej prędkości jest ograniczony do maksymalnie dwóch określonych wyjść jednocześnie. Różni producenci OEM wyrazili zainteresowanie zdefiniowaniem innych niestandardowych trybów dla możliwości specyficznych dla sprzętu. W skrócie, tryb jest po prostu liczbą całkowitą przekazywaną configure_streams . Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Ta funkcja obejmuje wywołanie systemowego interfejsu API, za pomocą którego aplikacje aparatu OEM mogą włączyć tryb niestandardowy. Tryby te 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 konfiguracji_streams, a następnie pozwolić swojej niestandardowej aplikacji aparatu na korzystanie z systemowego interfejsu API.

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óźnień związanych ze zmianami kontroli, takimi jak powiększenie, poprzez utrzymywanie możliwie pustej kolejki żądań. onCaptureQueueEmpty nie wymaga pracy HAL; był to wyłącznie dodatek po stronie frameworka. Aplikacje, które chcą z tego skorzystać, muszą dodać słuchacza do tego wywołania zwrotnego i odpowiednio zareagować. Zwykle polega to na wysłaniu kolejnego żądania przechwytywania do urządzenia z kamerą.

Interfejs aparatu HIDL

Interfejs Camera HIDL to kompletna przeróbka interfejsu Camera HAL, który wykorzystuje stabilne API zdefiniowane przez HIDL. Wszystkie funkcje i możliwości aparatu 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 obsługiwany jest format RAW_OPAQUE .
  • Dodaj statyczne metadane ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE jako obowiązkowe, jeśli obsługiwany jest dowolny format RAW.
  • Zmień pole camera3_stream_t data_space na bardziej elastyczną definicję, korzystając z definicji kodowania przestrzeni danych w wersji 0.
  • Ogólne dodatki do metadanych, które można wykorzystać 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 wersja HAL o rozszerzonych możliwościach:

  • Aktualizacje API ponownego przetwarzania OPAQUE i YUV.
  • Podstawowa obsługa buforów wyjściowych głębokości.
  • Dodanie pola data_space do camera3_stream_t .
  • Dodanie pola obrotu do camera3_stream_t .
  • Dodanie trybu pracy konfiguracji strumienia kamery3 do camera3_stream_configuration_t .

3.2

Drobna wersja HAL o rozszerzonych możliwościach:

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

3.1

Drobna wersja HAL o rozszerzonych możliwościach:

  • configure_streams przekazuje flagi użytkowania konsumenta do warstwy HAL.
  • wywołanie typu Flush, aby jak najszybciej usunąć wszystkie żądania/bufory w locie.

3.0

Pierwsza wersja HAL o rozszerzonych możliwościach:

  • Duża zmiana wersji, ponieważ ABI jest zupełnie inne. Brak zmian w wymaganych możliwościach sprzętowych i modelu operacyjnym od wersji 2.0.
  • Przerobione interfejsy żądań wejściowych i kolejek strumieniowych: wywołania frameworka do HAL z następnym żądaniem i buforami strumieniowymi już usuniętymi z kolejki. Uwzględniono obsługę środowiska synchronizacji, niezbędną do wydajnych wdrożeń.
  • Przeniesiono wyzwalacze do żądań, większość powiadomień do wyników.
  • Skonsolidowano wszystkie wywołania zwrotne w ramach w jedną strukturę, a wszystkie metody konfiguracji w jednym wywołaniu initialize() .
  • Dokonano konfiguracji strumienia w jednym wywołaniu, 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

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

  • Wystarczające do wdrożenia istniejącego API android.hardware.Camera .
  • Umożliwia kolejkę ZSL w warstwie usług kamer.
  • Nie testowano pod kątem żadnych nowych funkcji, takich jak ręczna kontrola przechwytywania, przechwytywanie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1,0

Początkowa kamera z Androidem HAL (Android 4.0) [camera.h]:

  • Przekonwertowano z warstwy abstrakcji C++ CameraHardwareInterface.
  • Obsługuje API android.hardware.Camera .

Historia wersji modułu kamery

Ta sekcja zawiera informacje o wersji modułu sprzętowego Camera w oparciu o 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 kamery dodaje następujące zmiany API:

  1. Obsługa trybu latarki. Struktura może włączyć tryb latarki dla dowolnego aparatu wyposażonego w lampę błyskową, bez konieczności otwierania aparatu. Aparat ma wyższy priorytet w dostępie do lampy błyskowej niż moduł aparatu; otwarcie urządzenia z kamerą powoduje wyłączenie latarki, jeśli została włączona poprzez interfejs modułu. W przypadku wystąpienia konfliktów zasobów, np. wywołania open() w celu otwarcia urządzenia z kamerą, moduł HAL kamery musi powiadomić platformę za pomocą wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony.
  2. Obsługa kamer zewnętrznych (na przykład kamer USB z możliwością podłączenia podczas pracy). 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 z możliwością podłączenia podczas pracy. Wywołania mające na celu uzyskanie informacji statycznych są nieprawidłowymi wywołaniami, 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 listą dostępnych kamer zewnętrznych.
  3. Wskazówki dotyczące arbitrażu kamery. Dodaje obsługę bezpośredniego wskazywania liczby kamer, które można jednocześnie otwierać i używać. Aby określić prawidłowe kombinacje urządzeń, w strukturze camera_info zwróconej przez wywołanie get_camera_info należy zawsze ustawić pola resource_cost i conflicting_devices .
  4. Metoda inicjalizacji modułu. Wywoływane 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 z otwartą kamerą starszego typu. Struktura może go użyć do otwarcia urządzenia kamery jako urządzenia niższej wersji HAL urządzenia HAL, jeśli to samo urządzenie może obsługiwać wiele wersji API urządzenia. Standardowe wywołanie otwartego modułu sprzętowego ( common.methods->open ) w dalszym ciągu otwiera kamerę z najnowszą obsługiwaną wersją, która jest również wersją wymienioną w camera_info_t.device_version .

2.2

Ta wersja modułu kamery dodaje obsługę tagów dostawcy z modułu i wycofuje starą vendor_tag_query_ops , która wcześniej była dostępna tylko przy otwartym urządzeniu.

2.1

Ta wersja modułu kamery dodaje obsługę asynchronicznych wywołań zwrotnych do platformy z modułu HAL kamery, która służy do powiadamiania platformy o zmianach w stanie modułu kamery. Moduły udostępniające prawidłową metodę set_callbacks() muszą zgłaszać co najmniej ten numer wersji.

2.0

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

1,0

Moduły kamer zgłaszające te numery wersji implementują początkowy interfejs HAL modułu kamery. Wszystkie urządzenia z kamerą, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 urządzenia z kamerą HAL. Pola device_version i static_camera_characteristics w parametrze camera_info są nieprawidłowe. Ten moduł i jego urządzenia mogą obsługiwać wyłącznie interfejs API android.hardware.Camera .