Obsługa wersji kamery

Ta strona szczegóły różnice w wersji HAL kamery, API oraz związanych Compatibility Test Suite (CTS) testów. Obejmuje również kilka zmian architektonicznych wprowadzonych w celu wzmocnienia i zabezpieczenia struktury aparatu w systemie Android 7.0, przejście na Treble w systemie Android 8.0 oraz dostawców aktualizacji, które muszą wprowadzić, aby obsługiwać te zmiany w implementacjach aparatu.

Terminologia

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

API kamery1
Ramy kamera na poziomie aplikacji Android 4.4 i niższych urządzeniach, wystawiony przez android.hardware.Camera klasie.
Interfejs API aparatu2
Ramy aparat poziomie aplikacji Android 5.0 i wyższe urządzeniach, narażonych przez android.hardware.camera2 opakowania.
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
HAL język definicji interfejsu wprowadzono Treble i używany do określenia interfejsu między HAL i jej użytkowników.
VTS
Zestaw testów sprzedawca wprowadził obok Treble.

Interfejsy API aparatu

Android zawiera następujące interfejsy API aparatu.

API kamery1

Wycofany interfejs Camera API1 w systemie Android 5.0, 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.

Interfejs API aparatu2

Struktura Camera API2 udostępnia aplikacji kontrolę nad kamerą niższego poziomu, w tym wydajne przepływy zdjęć seryjnych/strumieniowych z zerową liczbą kopii oraz kontrolę ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, odszumiania, wyostrzania i innych. Aby uzyskać szczegółowe informacje, oglądać / Przegląd 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. android.info.supportedHardwareLevel właściwość, że aplikacje mogą zapytania poprzez interfejsy API2 Camera donosi jeden z następujących poziomów wsparcia:

  • LEGACY : Urządzenia te narazić funkcje do aplikacji za pośrednictwem interfejsów API2 kamer, które są w przybliżeniu takie same możliwości jak te narażone na działanie aplikacji za pośrednictwem interfejsów API1 Camera. 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 : Urządzenia te obsługują pewne możliwości API2 Camera (ale nie wszystkie) i musi używać aparatu HAL 3.2 lub wyższej.
  • FULL : Urządzenia te obsługują wszystkie najważniejsze możliwości API2 aparat i musi używać aparatu HAL 3.2 lub nowszy oraz Android 5.0 lub wyższej.
  • LEVEL_3 : Urządzenia te obsługują YUV przetworzenie i surowe przechwytywanie obrazu, wraz z dodatkowymi konfiguracji strumienia wyjściowego.
  • EXTERNAL : Urządzenia te są podobne do LIMITED urządzeń 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 funkcje są narażone przez android.request.availableCapabilities nieruchomości w interfejsach API2 Camera. FULL urządzenia wymagają MANUAL_SENSOR i MANUAL_POST_PROCESSING możliwości, między innymi. RAW funkcja jest opcjonalna nawet FULL urządzeń. LIMITED urządzenia mogą reklamować dowolny podzbiór tych funkcji, w tym żaden z nich. Jednak BACKWARD_COMPATIBLE zdolność zawsze musi być 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 pracuje w Camera API2 LEGACY trybie (w którym domaga API2 aparatu pojęciowo są odwzorowane na wezwania API1 Camera) więc każdy aparat API2 CTS badania dotyczące cech lub funkcji poza API1 aparatu 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 aplikacji 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 Androidem 8.0 i wyższe z binderized wdrożeń HAL musi przejść kamera testy VTS .

Hartowanie ramy kamery

Aby wzmocnić zabezpieczenia struktury mediów i aparatu, system Android 7.0 przenosi usługę aparatu poza serwer 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 aparat wykorzystuje BufferQueue przekazać bufory pomiędzy procesami, żadna aktualizacja sprzedawca jest konieczne.

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

    Rysunek 1. Android 7,0 aparatu i stos materiałów w API1 na HAL3

  • HAL1, który wspiera przekazując metadane w buforach video, producenci muszą zaktualizować HAL używać kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource nie jest już obsługiwana w Androidzie 7.0.)

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

    Figura 2. Android 7,0 aparatu i stos materiałów 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:

  • HAL1 nie ma wpływu na ruch cameraservice, a nie zmiana dostawcy jest konieczne.
  • HAL3 ma wpływu, ale nie zmiana dostawcy jest konieczne:

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

    Rysunek 3. Android 7,0 aparatu i stos materiałów w API2 na HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w celu wzmocnienia zabezpieczeń nośników i aparatu fotograficznego 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 kamer, w których liczy się czas, takie jak nagrywanie wideo z dużą szybkością. Sprzedawcy mogą zmierzyć rzeczywisty wpływ uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Aparat Google dla 120/240 FPS nagrywania wideo o wysokiej prędkości. Urządzenia wymagają również niewielkiej ilości dodatkowej pamięci RAM, aby utworzyć nowy proces.
  • Przekazać metadane w buforach wideo (tylko HAL1). Jeśli sklepy HAL1 metadanych zamiast danych YUV rzeczywisty ramki w buforach wideo, HAL musi używać kMetadataBufferTypeNativeHandleSource jako rodzaj bufora metadanych i przekazać VideoNativeHandleMetadata w buforach wideo. ( kMetadataBufferTypeCameraSource nie jest już obsługiwane na Androidzie 7.0.) Z VideoNativeHandleMetadata , ramy kamer i mediów są w stanie przekazać buforów wideo między procesami przez szeregowania i deserializacji rodzimych uchwyty prawidłowo.
  • Bufor adres uchwyt nie zawsze przechowywać 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 kamery, musisz zaktualizować polityki SELinux, aby nadać serwerowi kamery odpowiednie uprawnienia. Odradzamy replikowanie polityk SELinux serwera medialnego dla serwera kamery (ponieważ mediaserver i cameraserver zazwyczaj 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 HIDL zdefiniowane interfejsy.

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 usług 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 uzyskać listę dostępnych badaniach do oceny Android Camera HAL, zobacz Aparat HAL Testowanie Checklist .

Android 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 : Statyczna kamera informacje o fizycznej kamery ID Postawienie logicznego urządzenia kamery. Zobacz Multi-Camera wsparcie .
  • isStreamCombinationSupported : Metoda ta obsługuje API publiczny, który pomaga klientom zapytanie, czy konfiguracja sesja jest obsługiwana. Zobacz API do kombinacji strumienia zapytania .

ICameraDeviceSession

  • isReconfigurationNeeded : Metoda, która opowiada ramy kamery czy kompletna strumień rekonfiguracja jest wymagane dla ewentualnych nowych wartości parametrów sesji. Pomaga to uniknąć niepotrzebnych opóźnień w ponownej konfiguracji kamery. Zobacz zapytania rekonfiguracji Session .
  • HAL API zarządzania bufor : Te interfejsy API umożliwiają HAL kamery do żądania zderzaki z ram kamery tylko wtedy, gdy wymagany zamiast sprzęgła każdy wniosek przechwytywania ze związanym z nim buforów w całym rurociągu kamery, powodując potencjalnie znaczne oszczędności pamięci.
    • signalStreamFlush : Sygnały do HAL, że obsługa aparatu jest o wykonywanie configureStreams_3_5 i że HAL musi zwrócić wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5 : Podobny do ICameraDevice3.4.configureStreams , ale dodatkowo, streamConfigCounter licznik jest do sprawdzenia stanu wyścigu między configureStreams_3_5 i signalStreamFlush połączeń.

Aktualizacje ICameraDeviceCallback :

  • requestStreamBuffers : Synchronous zwrotna, że aparat HAL wzywa zapytać serwer kamery dla buforów. Zobacz requestStreamBuffers .
  • returnStreamBuffers : Synchronous zwrotna dla HAL aparatu, aby powrócić bufory wyjściowe 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 dla ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT klucza
    • 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 notifyDeviceStateChange metodę urządzenia do powiadamiania HAL aparatu podczas zmiany fizyczne, takie jak składanie, wpływają na aparat i routingu.

2,4

  • Urządzenia do spuszczania z API poziomie 29 lub wyższym musi 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 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ą (kamera logiczna). Żądania przechwycenia można również wysyłać do poszczególnych urządzeń kamer objętych jedną kamerą logiczną. Zobacz Multi-Camera wsparcie .
  • Wprowadza parametry sesji. Parametry sesji stanowią podzbiór dostępnych parametrów przechwytywania, które po modyfikacji 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 parametrów 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 Motion Tracking zamiar w CAPTURE_INTENT . Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
  • Deprecates LENS_RADIAL_DISTORTION i dodaje LENS_DISTORTION na swoim miejscu.
  • Dodaje zniekształcenia tryby korekta 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. Z Treble, sprzedawca implementacje Camera HAL należy binderized . Android 8.0 zawiera również te kluczowe ulepszenia usługi Aparat:

  • Udostępnione powierzchnie: Włącz wiele powierzchni korzystające z tej samej 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 warstwy gralloc 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życia 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.

Zobacz enableSurfaceSharing dokumentacji dla programistów dodatkowych szczegółów.

Systemowe API dla niestandardowych trybów aparatu

Interfejs API kamery publicznej definiuje dwa tryby pracy: normalne i ograniczone szybkie nagrywanie. 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ą, ten tryb jest tylko liczbą całkowitą przekazane 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 jest 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, przez utrzymywanie jak największej liczby żądań w kolejce żądań. onCaptureQueueEmpty wymaga żadnej pracy 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 ANDROID_SENSOR_OPAQUE_RAW_SIZE statyczny metadanych jako obowiązkowe, jeśli RAW_OPAQUE format jest obsługiwany.
  • Dodaj ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE statyczny metadanych jako obowiązkowe, jeśli w dowolnym formacie RAW jest obsługiwany.
  • Przełącznik camera3_stream_t data_space pole do bardziej elastycznej definicji, z wykorzystaniem wersji 0 definicji kodowania dataspace.
  • 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 rewizja warstwy HAL o rozszerzonych możliwościach:

  • Aktualizacje API przetwarzania OPAQUE i YUV.
  • Podstawowe wsparcie dla buforów wyjściowych głębokości.
  • Dodanie data_space pola do camera3_stream_t .
  • Dodawanie pola do obrotu camera3_stream_t .
  • Dodanie trybie konfiguracji strumień camera3 do camera3_stream_configuration_t .

3.2

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

  • Deprecates get_metadata_vendor_tag_ops . Zastosowanie get_vendor_tag_ops w camera_common.h zamiast.
  • Deprecates register_stream_buffers . Wszystkie bufory gralloc świadczone przez ramy do HAL w process_capture_request mogą być nowe w dowolnym momencie.
  • Dodaj częściową obsługę wyników. process_capture_result można nazwać kilka razy z podzbioru dostępnych wyników przed pełnym wynik jest dostępny.
  • Dodaj ręcznego szablon 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 zwrócony w process_capture_result zamiast process_capture_request .

3.1

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

  • configure_streams przechodzi flagi użytkowania konsumentów do 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.
  • Skonsolidowane wszystkie wywołania zwrotne język w ramach jednej struktury, a wszystkie metody instalacji w jeden initialize() rozmowy.
  • Przekształciliśmy konfigurację strumienia w jedno wywołanie, aby uprościć zarządzanie strumieniem. Dwukierunkowy strumień wymienić STREAM_FROM_STREAM konstrukcję.
  • 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 android.hardware.Camera API.
  • 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 android.hardware.Camera API.

Historia wersji modułu kamery

Ta sekcja zawiera informacje moduł wersjonowania dla modułu sprzętowego aparatu, 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. Platforma może włączyć tryb latarki dla dowolnego urządzenia z 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. Gdy są jakieś konflikty zasobów, takich jak open() jest powołany, aby otworzyć urządzenie kamery, moduł HAL kamera musi powiadomić ramy poprzez oddzwonienie status trybu latarka, że tryb palnik 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. Apeluje, aby uzyskać informacje statyczne są nieprawidłowe połączenia, gdy aparat nie jest stan 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ń, resource_cost i conflicting_devices pola powinny zawsze być ustawiony w camera_info struktury zwracanej przez get_camera_info rozmowy.
  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 HAL niższego urządzenia, jeśli to samo urządzenie może obsługiwać wiele wersji interfejsu API urządzenia. Standardowy moduł sprzętowy otwarte zaproszenie ( common.methods->open ) nadal otwierać urządzenia kamery z najnowszej wersji obsługiwanej, który jest również wersja wymienione w camera_info_t.device_version .

2.2

Ta wersja dodaje wsparcie moduł kamery tag sprzedawca z modułu i deprecates stare vendor_tag_query_ops , które wcześniej były dostępne 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ą prawidłowe set_callbacks() metoda musi zgłosić przynajmniej to 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. device_version pole camera_info zawsze jest ważny; static_camera_characteristics pole camera_info jest ważny, jeżeli device_version pole jest w wersji 2.0 lub wyższej.

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ą. W device_version i static_camera_characteristics pola camera_info nie są ważne. Tylko android.hardware.Camera API może być obsługiwane przez ten moduł i jego urządzeń.