Ta strona została przetłumaczona przez Cloud Translation API.

Obsługa wersji kamery

Ta strona zawiera szczegółowe informacje na temat różnic 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 aparatu w systemie Android 7.0, przejście na Treble w systemie Android 8.0 oraz aktualizacje, które muszą wprowadzić dostawcy, aby obsłużyć te zmiany w swoich implementacjach aparatu.

Terminologia

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

Interfejs API aparatu1: Struktura aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 i starszym, udostępniana przez klasę android.hardware.Camera .
Interfejs API aparatu2: Struktura aparatu na poziomie aplikacji na urządzeniach z systemem Android 5.0 lub nowszym, 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 warstwie 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.
Aparat API1 CTS: Zestaw testów CTS aparatu, które działają na interfejsie Camera API1.
Aparat API2 CTS: Dodatkowy zestaw testów CTS kamery, które działają na bazie Camera API2.
Potroić: Oddziela implementację dostawcy (specyficzne dla urządzenia oprogramowanie niższego poziomu napisane przez producentów układów scalonych) od struktury systemu operacyjnego Android za pośrednictwem 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 testów dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android zawiera następujące interfejsy API aparatu.

Interfejs API aparatu1

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

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

Interfejs API aparatu2

Ramy Camera API2 udostępniają aplikacji kontrolę nad aparatem niższego poziomu, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania oraz sterowanie ekspozycją, wzmocnieniem, wzmocnieniem balansu bieli, konwersją kolorów, usuwaniem szumów, wyostrzaniem i nie tylko. Aby uzyskać szczegółowe informacje, obejrzyj omówienie wideo Google I/O .

Android 5.0 i nowszy zawiera Camera API2; jednak urządzenia z systemem Android 5.0 lub 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 obsługi:

LEGACY : Te urządzenia udostępniają aplikacjom możliwości 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 Camera API2 na wywołania Camera API1; starsze urządzenia nie obsługują funkcji Camera API2, takich jak sterowanie klatkami.
LIMITED : Te urządzenia obsługują niektóre funkcje Camera API2 (ale nie wszystkie) i muszą korzystać z Camera HAL 3.2 lub nowszej.
FULL : te urządzenia obsługują wszystkie główne możliwości interfejsu Camera API2 i muszą korzystać z oprogramowania Camera HAL 3.2 lub nowszego oraz systemu Android 5.0 lub nowszego.
LEVEL_3 : Te urządzenia obsługują ponowne 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 mogą 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ą ujawniane za pośrednictwem właściwości android.request.availableCapabilities w interfejsach Camera API2. Urządzenia FULL wymagają między innymi funkcji MANUAL_SENSOR i MANUAL_POST_PROCESSING . Funkcja RAW jest opcjonalna nawet w przypadku urządzeń FULL . LIMITED urządzenia mogą reklamować dowolny podzestaw tych możliwości, w tym żadne z nich. Jednak zawsze musi być zdefiniowana możliwość BACKWARD_COMPATIBLE .

Obsługiwany poziom sprzętowy urządzenia, a także określone funkcje Camera API2, które obsługuje, są dostępne jako następujące flagi funkcji, aby umożliwić 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 Androidem 5.0 lub nowszym muszą przejść testy aparatu Camera API1 CTS, Camera API2 CTS i CTS Verifier.

Urządzenia, które nie mają implementacji Camera HAL3.2 i nie są w stanie obsługiwać pełnych interfejsów Camera API2, muszą przejść testy Camera API2 CTS. Jednak 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 przeprowadzane testy Camera API2 CTS wykorzystują istniejące publiczne interfejsy i możliwości Camera API1 bez nowych wymagań. Błędy, które zostały ujawnione (i które spowodowały awarię Camera API2 CTS) są już obecne w istniejącej warstwie Camera HAL urządzenia i dlatego zostałyby 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 powiązanymi implementacjami HAL muszą przejść testy Camera VTS .

Hartowanie ramy aparatu

Aby zwiększyć bezpieczeństwo środowiska multimedialnego i aparatu, Android 7.0 przenosi usługę aparatu z serwera multimedió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ą być zmuszeni do wprowadzenia zmian w warstwie HAL kamery w zależności od używanych wersji API i HAL. W poniższych sekcjach szczegółowo opisano zmiany architektury w AP1 i AP2 dla HAL1 i HAL3, a także wymagania ogólne.

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 używa BufferQueue do przekazywania buforów między procesami, aktualizacja dostawcy nie jest konieczna.
Rysunek 1. Aparat i stos multimediów z Androidem 7.0 w API1 na HAL3
HAL1, która 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.)
Rysunek 2. Aparat i stos multimediów z Androidem 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 warstwę HAL1 i nie jest wymagana żadna aktualizacja dostawcy .
Dotyczy to HAL3, ale aktualizacja dostawcy nie jest konieczna:
Rysunek 3. Aparat i stos multimediów z Androidem 7.0 w API2 na HAL3

Dodatkowe wymagania

Zmiany w architekturze wprowadzone w celu wzmocnienia zabezpieczeń nośników i ram aparatu 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 czasowe przypadki użycia aparatu, takie jak szybkie nagrywanie wideo. Dostawcy mogą mierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Google Camera do nagrywania wideo z dużą szybkością 120/240 kl./s. Urządzenia wymagają również niewielkiej ilości dodatkowej pamięci RAM do utworzenia nowego procesu.
Przekazuj metadane w buforach wideo ( tylko HAL1 ). Jeśli HAL1 przechowuje metadane zamiast rzeczywistych danych ramek YUV w buforach wideo, HAL musi używać kMetadataBufferTypeNativeHandleSource jako typu bufora metadanych i przekazywać VideoNativeHandleMetadata w buforach wideo. ( kMetadataBufferTypeCameraSource nie jest już obsługiwana w systemie Android 7.0.) Dzięki VideoNativeHandleMetadata platformy aparatu i multimediów mogą przekazywać bufory wideo między procesami przez prawidłowe serializowanie i deserializację natywnych uchwytów.
Adres uchwytu bufora nie zawsze przechowuje ten sam bufor ( tylko HAL3 ). Dla każdego żądania przechwycenia HAL3 pobiera 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 otrzymuje adres uchwytu bufora A, który przechowuje uchwyt bufora A. Po tym, jak 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 specyficzne dla urządzenia zasady SELinux przyznają serwerowi multimediów uprawnienia do uruchamiania kamery, należy zaktualizować zasady SELinux, aby nadać serwerowi kamer odpowiednie uprawnienia. Odradzamy powielanie zasad SELinux serwera multimediów dla serwera kamer (ponieważ serwer multimediów i serwer kamer 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ą kamerę HAL w procesie innym niż serwer kamery. IPC przechodzi przez interfejsy zdefiniowane w HIDL .

Walidacja

W przypadku wszystkich urządzeń z kamerą i systemem Android 7.0 sprawdź 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 dokonano aktualizacji wskazanych powyżej.

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

Historia wersji HAL aparatu

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

Androida 10

Android 10 wprowadza następujące aktualizacje.

Interfejs API aparatu

Ulepszenia dotyczące wielu kamer, które umożliwiają korzystanie z kamer fizycznych pojedynczo lub za pośrednictwem odpowiednich kamer logicznych poprzez ukrywanie fizycznych identyfikatorów kamer. Zobacz Obsługa wielu kamer .
Możliwość sprawdzenia, czy dana konfiguracja sesji jest obsługiwana bez narzutu na wydajność związanego z tworzeniem nowej sesji. Zobacz CameraDevice .
Możliwość pobierania zalecanych konfiguracji strumienia dla danego przypadku użycia, aby klient był bardziej energooszczędny i wydajny. Zobacz getRecommendedStreamConfigurationMap .
Obsługa głębokiego formatu obrazu JPEG . Aby uzyskać więcej informacji, zobacz specyfikację Głębokość dynamiczna .
Obsługa formatu obrazu HEIC . Zobacz Obrazowanie HEIF .
Ulepszenia prywatności. Niektóre klucze są wymagane, aby klient miał uprawnienia CAMERA , zanim będzie można je pobrać z CameraCharacteristics . Zobacz getKeysNeedingPermission .

Kamera HAL

Następujące wersje HAL aparatu są aktualizowane w systemie Android 10.

3.5

ICameraDevice

getPhysicalCameraCharacteristics : statyczne informacje o kamerze dla identyfikatora kamery fizycznej obsługującej logiczne urządzenie z kamerą. 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 platformę kamery, czy wymagana jest pełna rekonfiguracja strumienia dla możliwych nowych wartości parametrów sesji. Pomaga to uniknąć niepotrzebnych opóźnień związanych z rekonfiguracją kamery. Zobacz Kwerenda rekonfiguracji sesji .
Interfejsy API do zarządzania buforami HAL : te interfejsy API umożliwiają warstwie HAL kamery żądanie buforów ze środowiska 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 warstwie HAL, że usługa kamery ma zamiar 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 licznik streamConfigCounter służy do sprawdzania wyścigu między wywołaniami configureStreams_3_5 i signalStreamFlush .

Aktualizacje ICameraDeviceCallback :

requestStreamBuffers : Synchroniczne wywołanie zwrotne, które kamera HAL wywołuje, 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 klucze zostały dodane 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 dynamiczne konfiguracje strumienia głębokości
- 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

Następujące wersje modułów aparatu są aktualizowane w systemie Android 10.

2.5

Dodaje metodę notifyDeviceStateChange dla urządzeń, aby 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 na poziomie 29 lub wyższym MUSZĄ zgłaszać true dla isTorchModeSupported .

Androida 9

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

Interfejs API aparatu

Wprowadza interfejs API obsługi 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ą (kamerę logiczną). Żądania przechwytywania mogą być również wysyłane do poszczególnych urządzeń z kamerą objętych jedną kamerą logiczną. Zobacz Obsługa wielu kamer .
Wprowadza parametry sesji. Parametry sesji to 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. Zobacz CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
Dodaje intencję śledzenia ruchu w CAPTURE_INTENT . Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
Wycofuje 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

configureStreams_3_4 : Dodaje obsługę sessionParameters i kamer logicznych.
processCaptureRequest_3_4 : Dodaje obsługę uwzględniania fizycznych identyfikatorów kamer w strukturze strumienia.

Aktualizacje ICameraDeviceCallback

processCaptureResult_3_4 : Dodaje metadane kamery fizycznej do wyników przechwytywania.

3.3

Następujące klucze zostały dodane 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

Androida 8.0

Wersja Androida 8.0 wprowadza Treble. W przypadku tonów wysokich implementacje HAL kamery dostawcy muszą zostać zbindowane . Android 8.0 zawiera również następujące kluczowe ulepszenia usługi Aparat:

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

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

Powierzchnie wspólne

Ta funkcja umożliwia tylko jednemu zestawowi buforów sterowanie dwoma wyjściami, takimi 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 HAL dla kamer i gralloc HAL mogą tworzyć bufory gralloc, które są używane przez wielu różnych konsumentów (takich jak sprzętowy kompozytor/procesor graficzny i koder wideo), zamiast tylko jednego konsumenta. Usługa kamery przekazuje flagi użytkowania przez konsumentów do warstwy HAL kamery i warstwy HAL gralloc; muszą albo przydzielić odpowiednie rodzaje buforów, albo kamera HAL musi zwrócić błąd, że ta kombinacja konsumentów nie jest obsługiwana.

Zobacz dokumentację programisty enableSurfaceSharing , aby uzyskać dodatkowe informacje.

Systemowy interfejs API dla niestandardowych trybów aparatu

Interfejs API kamery publicznej definiuje dwa tryby pracy: nagrywanie normalne i nagrywanie z ograniczoną szybkością. Mają dość różną semantykę; na przykład tryb dużej szybkoś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. Pod maską tryb jest po prostu liczbą całkowitą przekazaną do configure_streams . Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

Ta funkcja obejmuje systemowe wywołanie interfejsu API, za pomocą którego aplikacje OEM aparatu mogą włączyć tryb niestandardowy. Te tryby muszą zaczynać się od wartości całkowitej 0x8000, aby uniknąć konfliktów z przyszłymi trybami dodawanymi do publicznego interfejsu API.

Aby obsługiwać tę funkcję, producenci OEM muszą jedynie dodać nowy tryb do warstwy HAL, uruchamiany przez tę liczbę całkowitą przekazaną do warstwy HAL w konfiguracji strumieni, a następnie zlecić, aby ich niestandardowa aplikacja aparatu korzystała 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óźnienia zmian sterowania, takich jak powiększanie, przez utrzymywanie kolejki żądań tak pustej, jak to tylko możliwe. onCaptureQueueEmpty nie wymaga pracy HAL; był to wyłącznie dodatek po stronie frameworka. Aplikacje, które chcą to wykorzystać, muszą dodać słuchacza do tego wywołania zwrotnego i odpowiednio zareagować. Zwykle jest to wysyłanie kolejnego żądania przechwycenia do urządzenia z kamerą.

Interfejs kamery HIDL

Interfejs Camera HIDL to kompletna przebudowa interfejsu Camera HAL, która wykorzystuje stabilne API zdefiniowane w 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 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.
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 dla 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.
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 kamery3 do camera3_stream_configuration_t .

3.2

Drobna wersja HAL o rozszerzonych możliwościach:

Wycofuje get_metadata_vendor_tag_ops . Zamiast tego użyj get_vendor_tag_ops w camera_common.h .
Wycofuje 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żna wywołać 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.
Przerób specyfikacje strumienia dwukierunkowego i wejściowego.
Zmień ścieżkę powrotu bufora wejściowego. Bufor jest zwracany w process_capture_result zamiast w process_capture_request .

3.1

Drobna wersja HAL o rozszerzonych możliwościach:

configure_streams przekazuje flagi użycia konsumentów do warstwy HAL.
flush, aby usunąć wszystkie żądania/bufory w locie tak szybko, jak to możliwe.

3.0

Pierwsza wersja HAL o rozszerzonych możliwościach:

Główna zmiana wersji, ponieważ ABI jest zupełnie inny. Brak zmian w wymaganych możliwościach sprzętowych lub modelu operacyjnym od wersji 2.0.
Przerobiono interfejsy żądań wejściowych i kolejek strumieniowych: wywołania struktury HAL z następnymi żądaniami i buforami strumieniowymi już usuniętymi z kolejki. Uwzględniono obsługę platformy synchronizacji, niezbędną do wydajnej implementacji.
Przeniesiono wyzwalacze do żądań, większość powiadomień do wyników.
Skonsolidowano wszystkie wywołania zwrotne w ramach jednej struktury i wszystkie metody konfiguracji w jednym wywołaniu initialize() .
Przekształcono 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

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

Wystarczające do zaimplementowania istniejącego interfejsu API android.hardware.Camera .
Pozwala na kolejkę ZSL w warstwie usługi kamery.
Nie testowano żadnych nowych funkcji, takich jak ręczna kontrola przechwytywania, przechwytywanie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1.0

Początkowa wersja HAL aparatu Android (Android 4.0) [camera.h]:

Konwertowane z warstwy abstrakcji CameraHardwareInterface języka C++.
Obsługuje interfejs API android.hardware.Camera .

Historia wersji modułu kamery

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

2.4

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

Obsługa trybu latarki. Struktura może włączyć tryb latarki dla dowolnego urządzenia z aparatem wyposażonym w lampę błyskową, bez 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 jakichkolwiek konfliktów zasobów, takich jak wywołanie open() w celu otwarcia urządzenia z kamerą, moduł HAL kamery musi powiadomić platformę za pośrednictwem wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony.
Obsługa kamery zewnętrznej (na przykład kamery podłączanej podczas pracy USB). Aktualizacje interfejsu API określają, że statyczne informacje o kamerze są dostępne tylko wtedy, gdy kamera jest podłączona i gotowa do użycia z zewnętrznymi kamerami typu hot-plug. Wywołania mające na celu uzyskanie informacji statycznych są nieprawidłowymi wywołaniami, gdy stan kamery jest inny niż CAMERA_DEVICE_STATUS_PRESENT . Framework polega wyłącznie na wywołaniach zwrotnych zmiany statusu urządzenia w celu zarządzania listą dostępnych kamer zewnętrznych.
Wskazówki dotyczące arbitrażu kamery. Dodaje obsługę jawnego wskazywania liczby urządzeń z kamerą, które mogą być jednocześnie otwierane i używane. Aby określić prawidłowe kombinacje urządzeń, należy zawsze ustawić pola resource_cost i conflicting_devices w strukturze camera_info zwróconej przez wywołanie get_camera_info .
Metoda inicjalizacji modułu. Wywoływana 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ą starszą kamerą. Framework może go użyć do otwarcia urządzenia z kamerą jako urządzenia HAL w niższej wersji urządzenia HAL, jeśli to samo urządzenie może obsługiwać wiele wersji interfejsu API urządzenia. Standardowe wywołanie otwarte modułu sprzętowego ( common.methods->open ) kontynuuje otwieranie urządzenia z kamerą w najnowszej obsługiwanej wersji, 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 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 struktury z modułu kamery HAL, który jest używany do powiadamiania struktury o zmianach stanu 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, które zgłaszają ten numer wersji, implementują drugą wersję interfejsu HAL modułu kamery. Urządzenia z kamerą, które można otworzyć 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 camera_info jest zawsze ważne; pole static_camera_characteristics w camera_info jest poprawne, 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 kamerą, 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. Ten moduł i jego urządzenia mogą obsługiwać tylko interfejs API android.hardware.Camera .

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

Terminologia

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

Interfejs API aparatu1: Struktura aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 i starszym, udostępniana przez klasę android.hardware.Camera .
Interfejs API aparatu2: Struktura aparatu na poziomie aplikacji na urządzeniach z systemem Android 5.0 lub nowszym, 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 warstwie 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.
Aparat API1 CTS: Zestaw testów CTS aparatu, które działają na interfejsie Camera API1.
Aparat API2 CTS: Dodatkowy zestaw testów CTS kamery, które działają na bazie Camera API2.
Potroić: Oddziela implementację dostawcy (specyficzne dla urządzenia oprogramowanie niższego poziomu napisane przez producentów układów scalonych) od struktury systemu operacyjnego Android za pośrednictwem 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 testów dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android zawiera następujące interfejsy API aparatu.

Interfejs API aparatu1

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

Interfejs API aparatu2

LEGACY : Te urządzenia udostępniają aplikacjom możliwości 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 Camera API2 na wywołania Camera API1; starsze urządzenia nie obsługują funkcji Camera API2, takich jak sterowanie klatkami.
LIMITED : Te urządzenia obsługują niektóre funkcje Camera API2 (ale nie wszystkie) i muszą korzystać z Camera HAL 3.2 lub nowszej.
FULL : te urządzenia obsługują wszystkie główne możliwości interfejsu Camera API2 i muszą korzystać z oprogramowania Camera HAL 3.2 lub nowszego oraz systemu Android 5.0 lub nowszego.
LEVEL_3 : Te urządzenia obsługują ponowne 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 mogą mieć mniej stabilną liczbę klatek na sekundę. Ten poziom jest używany w przypadku kamer zewnętrznych, takich jak kamery internetowe USB.

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 Androidem 5.0 lub nowszym muszą przejść testy aparatu Camera API1 CTS, Camera API2 CTS i CTS Verifier.

Wymagania VTS

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

Hartowanie ramy aparatu

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 używa BufferQueue do przekazywania buforów między procesami, aktualizacja dostawcy nie jest konieczna.
Rysunek 1. Aparat i stos multimediów z Androidem 7.0 w API1 na HAL3
HAL1, która 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.)
Rysunek 2. Aparat i stos multimediów z Androidem 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 warstwę HAL1 i nie jest wymagana żadna aktualizacja dostawcy .
Dotyczy to HAL3, ale aktualizacja dostawcy nie jest konieczna:
Rysunek 3. Aparat i stos multimediów z Androidem 7.0 w API2 na HAL3

Dodatkowe wymagania

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

Ogólny. Devices require additional bandwidth due to IPC, which may affect time-sensitive camera use cases such as high-speed video recording. Vendors can measure actual impact by running android.hardware.camera2.cts.PerformanceTest and the Google Camera app for 120/240 FPS high-speed video recording. Devices also require a small amount of additional RAM to create the new process.
Pass metadata in video buffers ( HAL1 only ). If HAL1 stores metadata instead of real YUV frame data in video buffers, the HAL must use kMetadataBufferTypeNativeHandleSource as the metadata buffer type and pass VideoNativeHandleMetadata in video buffers. ( kMetadataBufferTypeCameraSource is no longer supported on Android 7.0.) With VideoNativeHandleMetadata , camera and media frameworks are able to pass the video buffers between processes by serializing and deserializing the native handles properly.
Buffer handle address doesn't always store the same buffer ( HAL3 only ). For each capture request, HAL3 gets addresses of buffer handles. HAL can't use the addresses to identify buffers because the addresses may store another buffer handle after HAL returns the buffer. You must update the HAL to use buffer handles to identify the buffers. For example, HAL receives a buffer handle address A, which stores buffer handle A. After HAL returns buffer handle A, buffer handle address A may store buffer handle B next time the HAL receives it.
Update SELinux policies for cameraserver. If device-specific SELinux policies give mediaserver permissions to run the camera, you must update the SELinux policies to give cameraserver proper permissions. We discourage replicating the mediaserver's SELinux policies for cameraserver (as mediaserver and cameraserver generally require different resources in the system). Cameraserver should have only the permissions needed to perform camera functionalities and any unnecessary camera-related permissions in mediaserver should be removed.
Separation between Camera HAL and cameraserver. Android 8.0 and higher additionally separate the binderized Camera HAL in a process different from cameraserver. IPC goes through HIDL-defined interfaces.

Walidacja

For all devices that include a camera and run Android 7.0, verify the implementation by running Android 7.0 CTS. Although Android 7.0 doesn't include new CTS tests that verify camera service changes, existing CTS tests fail if you haven't made the updates indicated above.

For all devices that include a camera and run Android 8.0 and higher, verify the vendor implementation by running VTS.

Camera HAL version history

For a list of tests available for evaluating the Android Camera HAL, see the Camera HAL Testing Checklist .

Android 10

Android 10 introduces the following updates.

Camera API

Multi-camera improvements that allow physical cameras to be used individually or through corresponding logical cameras by hiding physical camera IDs. See Multi-Camera Support .
Ability to check whether a particular session configuration is supported without the performance overhead of creating a new session. See CameraDevice .
Ability to retrieve recommended stream configurations for a given use case to make the client more power efficient and performant. See getRecommendedStreamConfigurationMap .
Support for the depth JPEG image format . For further details, see the Dynamic Depth specification .
Support for the HEIC Image format . See HEIF Imaging .
Privacy improvements. Certain keys are required for the client to have CAMERA permissions before they can be retrieved from CameraCharacteristics . See getKeysNeedingPermission .

Camera HAL

The following Camera HAL versions are updated in Android 10.

3.5

ICameraDevice

getPhysicalCameraCharacteristics : The static camera information for a physical camera ID backing a logical camera device. See Multi-Camera Support .
isStreamCombinationSupported : This method supports a public API that helps clients query if a session configuration is supported. See API to query stream combinations .

ICameraDeviceSession

isReconfigurationNeeded : Method that tells the camera framework whether complete stream reconfiguration is required for possible new session parameter values. This helps avoid unnecessary camera reconfiguration delays. See Session reconfiguration query .
HAL buffer management APIs : These APIs allow the camera HAL to request buffers from the camera framework only when required instead of coupling each capture request with its associated buffers throughout the camera pipeline, resulting in potentially significant memory savings.
- signalStreamFlush : Signals to the HAL that the camera service is about to perform configureStreams_3_5 and that the HAL must return all buffers of designated streams.
- configureStreams_3_5 : Similar to ICameraDevice3.4.configureStreams , but in addition, the streamConfigCounter counter is provided to check for a race condition between the configureStreams_3_5 and signalStreamFlush calls.

Updates to ICameraDeviceCallback :

requestStreamBuffers : Synchronous callback that the camera HAL calls to ask the camera server for buffers. See requestStreamBuffers .
returnStreamBuffers : Synchronous callback for the camera HAL to return output buffers to the camera server. See returnStreamBuffers .

3.4

The following keys are added to camera metadata in Android 10.

Image formats
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
- ANDROID_SCALER_AVAILABLE_FORMATS_Y8
Camera metadata tags
- 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
Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
Values for the ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT key
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
Available dynamic depth stream configurations
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
Available HEIC stream configurations
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Camera module

The following camera module versions are updated in Android 10.

2.5

Adds the notifyDeviceStateChange method for devices to notify the camera HAL when physical changes, such as folding, affect camera and routing.

2.4

Devices launching with API level 29 or higher MUST report true for isTorchModeSupported .

Android 9

The Android 9 release introduces the following updates to the camera API2 and HAL interface.

Camera API

Introduces the multi-camera API to better support devices with multiple cameras facing in the same direction, enabling features such as bokeh and seamless zoom. This allows apps to view multiple cameras on a device as one logical unit (logical camera). Capture requests can also be sent to individual camera devices encompassed by one logical camera. See Multi-Camera Support .
Introduces session parameters. Session parameters are a subset of the available capture parameters that can cause severe processing delays when modified. These costs can be mitigated if clients pass their initial values during capture session initialization. See Session Parameters .
Adds optical stabilization (OIS) data keys for app-level stabilization and effects. See STATISTICS_OIS_SAMPLES .
Adds external flash support. See CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
Adds a motion tracking intent in CAPTURE_INTENT . See CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
Deprecates LENS_RADIAL_DISTORTION and adds LENS_DISTORTION in its place.
Adds distortion correction modes in CaptureRequest . See DISTORTION_CORRECTION_MODE .
Adds support for external USB/UVC cameras on supported devices. See INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Camera HAL

3.4

Updates to ICameraDeviceSession

configureStreams_3_4 : Adds support for sessionParameters and logical cameras.
processCaptureRequest_3_4 : Adds support for including physical camera IDs in stream structure.

Updates to ICameraDeviceCallback

processCaptureResult_3_4 : Adds physical camera metadata in capture results.

3.3

The following keys are added to camera metadata in Android 9.

Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
Camera metadata tags
- 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

The Android 8.0 release introduces Treble. With Treble, vendor Camera HAL implementations must be binderized . Android 8.0 also contains these key enhancements to the Camera service:

Shared surfaces: Enable multiple surfaces sharing the same OutputConfiguration
System API for custom camera modes
onCaptureQueueEmpty

See the sections below for more information on these features.

Shared surfaces

This feature enables only one set of buffers to drive two outputs, such as preview and video encoding, which lowers power and memory consumption. To support this feature, device manufacturers need to ensure their camera HAL and gralloc HAL implementations can create gralloc buffers that are used by multiple different consumers (such as the hardware composer/GPU and the video encoder), instead of just one consumer. The camera service passes the consumer usage flags to the camera HAL and the gralloc HAL; they need to either allocate the right kinds of buffers, or the camera HAL needs to return an error that this combination of consumers isn't supported.

See the enableSurfaceSharing developer documentation for additional details.

System API for custom camera modes

The public camera API defines two operating modes: normal and constrained high-speed recording. They have fairly different semantics; for example, high-speed mode is limited to at most two specific outputs at once. Various OEMs have expressed interest in defining other custom modes for hardware-specific capabilities. Under the hood, the mode is just an integer passed to configure_streams . See: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams .

This feature includes a system API call that OEM camera apps can use to enable a custom mode. These modes must start at integer value 0x8000 to avoid conflicting with future modes added to the public API.

To support this feature, OEMs merely need to add the new mode to their HAL, triggered by this integer passed to the HAL on configure_streams, and then have their custom camera app use the system API.

The method name is android.hardware.camera2.CameraDevice#createCustomCaptureSession . See: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

The purpose of this API is to reduce the latency of control changes like zoom by keeping the request queue as empty as possible. onCaptureQueueEmpty requires no HAL work; it was purely a framework-side addition. Applications that want to take advantage of it need to add a listener to that callback and respond appropriately. Generally that's by sending another capture request to the camera device.

Camera HIDL interface

The Camera HIDL interface is a complete overhaul of the Camera HAL interface that uses stable HIDL-defined APIs. All features and camera capabilities introduced in the most recent legacy versions 3.4 and 2.4 (for the camera module) are also part of the HIDL definitions.

3.4

Minor additions to supported metadata and changes to data_space support:

Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if RAW_OPAQUE format is supported.
Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as mandatory if any RAW format is supported.
Switch camera3_stream_t data_space field to a more flexible definition, using the version 0 definition of dataspace encoding.
General metadata additions which are available to use for HALv3.2 or newer:
- 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

Minor revision of expanded-capability HAL:

OPAQUE and YUV reprocessing API updates.
Basic support for depth output buffers.
Addition of data_space field to camera3_stream_t .
Addition of rotation field to camera3_stream_t .
Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t .

3.2

Minor revision of expanded-capability HAL:

Deprecates get_metadata_vendor_tag_ops . Use get_vendor_tag_ops in camera_common.h instead.
Deprecates register_stream_buffers . All gralloc buffers provided by framework to HAL in process_capture_request may be new at any time.
Add partial result support. process_capture_result may be called multiple times with a subset of the available results before the full result is available.
Add manual template to camera3_request_template . Applications may use this template to control the capture settings directly.
Rework the bidirectional and input stream specifications.
Change the input buffer return path. The buffer is returned in process_capture_result instead of process_capture_request .

3.1

Minor revision of expanded-capability HAL:

configure_streams passes consumer usage flags to the HAL.
flush call to drop all in-flight requests/buffers as fast as possible.

3.0

First revision of expanded-capability HAL:

Major version change since the ABI is completely different. No change to the required hardware capabilities or operational model from 2.0.
Reworked input request and stream queue interfaces: Framework calls into HAL with next request and stream buffers already dequeued. Sync framework support is included, necessary for efficient implementations.
Moved triggers into requests, most notifications into results.
Consolidated all callbacks into framework into one structure, and all setup methods into a single initialize() call.
Made stream configuration into a single call to simplify stream management. Bidirectional streams replace the STREAM_FROM_STREAM construct.
Limited mode semantics for older/limited hardware devices.

2.0

Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:

Sufficient for implementing existing android.hardware.Camera API.
Allows for ZSL queue in camera service layer.
Not tested for any new features such as manual capture control, Bayer RAW capture, reprocessing of RAW data, etc.

1.0

Initial Android camera HAL (Android 4.0) [camera.h]:

Converted from C++ CameraHardwareInterface abstraction layer.
Supports android.hardware.Camera API.

Camera module version history

This section contains module versioning information for the Camera hardware module, based on camera_module_t.common.module_api_version . The two most significant hex digits represent the major version, and the two least significant represent the minor version.

2.4

This camera module version adds the following API changes:

Torch mode support. The framework can turn on torch mode for any camera device that has a flash unit, without opening a camera device. The camera device has a higher priority accessing the flash unit than the camera module; opening a camera device turns off the torch if it had been enabled through the module interface. When there are any resource conflicts, such as open() is called to open a camera device, the camera HAL module must notify the framework through the torch mode status callback that the torch mode has been turned off.
External camera (for example, USB hot-plug camera) support. The API updates specify the camera static info is available only when camera is connected and ready to use for external hot-plug cameras. Calls to get static info are invalid calls when camera status isn't CAMERA_DEVICE_STATUS_PRESENT . The framework counts solely on device status change callbacks to manage the available external camera list.
Camera arbitration hints. Adds support for explicitly indicating the number of camera devices that can be simultaneously opened and used. To specify valid combinations of devices, the resource_cost and conflicting_devices fields should always be set in the camera_info structure returned by the get_camera_info call.
Module initialization method. Called by the camera service after the HAL module is loaded to allow for one-time initialization of the HAL. It is called before any other module methods are invoked.

2.3

This camera module version adds open legacy camera HAL device support. The framework can use it to open the camera device as lower device HAL version HAL device if the same device can support multiple device API versions. The standard hardware module open call ( common.methods->open ) continues to open the camera device with the latest supported version, which is also the version listed in camera_info_t.device_version .

2.2

This camera module version adds vendor tag support from the module, and deprecates the old vendor_tag_query_ops that were previously only accessible with a device open.

2.1

This camera module version adds support for asynchronous callbacks to the framework from the camera HAL module, which is used to notify the framework about changes to the camera module state. Modules that provide a valid set_callbacks() method must report at least this version number.

2.0

Camera modules that report this version number implement the second version of the camera module HAL interface. Camera devices openable through this module may support either version 1.0 or version 2.0 of the camera device HAL interface. The device_version field of camera_info is always valid; the static_camera_characteristics field of camera_info is valid if the device_version field is 2.0 or higher.

1.0

Camera modules that report these version numbers implement the initial camera module HAL interface. All camera devices openable through this module support only version 1 of the camera device HAL. The device_version and static_camera_characteristics fields of camera_info aren't valid. Only the android.hardware.Camera API can be supported by this module and its devices.

This page details version differences in Camera HALs, APIs, and associated Compatibility Test Suite (CTS) tests. It also covers several architectural changes made to harden and secure the camera framework in Android 7.0, the switch to Treble in Android 8.0, and the updates vendors must make to support these changes in their camera implementations.

Terminology

The following terms are used on this page:

Camera API1: The app-level camera framework on Android 4.4 and lower devices, exposed through the android.hardware.Camera class.
Camera API2: The app-level camera framework on Android 5.0 and higher devices, exposed through the android.hardware.camera2 package.
Camera HAL: The camera module layer implemented by SoC vendors. The app-level public frameworks are built on top of the camera HAL.
Camera HAL3.1: Version of the camera device HAL released with Android 4.4.
Camera HAL3.2: Version of the camera device HAL released with Android 5.0.
Camera API1 CTS: Set of camera CTS tests that run on top of Camera API1.
Camera API2 CTS: Additional set of camera CTS tests that run on top of Camera API2.
Treble: Separates the vendor implementation (device-specific, lower-level software written by silicon manufacturers) from the Android OS framework through a new vendor interface.
HIDL: HAL interface definition language introduced with Treble and used to specify the interface between a HAL and its users.
VTS: Vendor test suite introduced alongside Treble.

Camera APIs

Android includes the following camera APIs.

Camera API1

Android 5.0 deprecated Camera API1, which continues to be phased out as new platform development focuses on Camera API2. However, the phase-out period will be lengthy, and Android releases will continue to support Camera API1 apps for some time. Specifically, support continues for:

Camera API1 interfaces for apps. Camera apps built on top of Camera API1 should work as they do on devices running lower Android release versions.
Camera HAL versions. Includes support for Camera HAL1.0.

Camera API2

The Camera API2 framework exposes lower-level camera control to the app, including efficient zero-copy burst/streaming flows and per-frame controls of exposure, gain, white balance gains, color conversion, denoising, sharpening, and more. For details, watch the Google I/O video overview .

Android 5.0 and higher includes Camera API2; however, devices running Android 5.0 and higher may not support all Camera API2 features. The android.info.supportedHardwareLevel property that apps can query through the Camera API2 interfaces reports one of the following support levels:

LEGACY : These devices expose capabilities to apps through the Camera API2 interfaces that are approximately the same capabilities as those exposed to apps through the Camera API1 interfaces. The legacy frameworks code conceptually translates Camera API2 calls into Camera API1 calls; legacy devices don't support Camera API2 features such as per-frame controls.
LIMITED : These devices support some Camera API2 capabilities (but not all) and must use Camera HAL 3.2 or higher.
FULL : These devices support all of the major capabilities of Camera API2 and must use Camera HAL 3.2 or higher and Android 5.0 or higher.
LEVEL_3 : These devices support YUV reprocessing and RAW image capture, along with additional output stream configurations.
EXTERNAL : These devices are similar to LIMITED devices with some exceptions; for example, some sensor or lens information may not be reported or have less stable frame rates. This level is used for external cameras such as USB webcams.

Individual capabilities are exposed through the android.request.availableCapabilities property in the Camera API2 interfaces. FULL devices require the MANUAL_SENSOR and MANUAL_POST_PROCESSING capabilities, among others. The RAW capability is optional even for FULL devices. LIMITED devices can advertise any subset of these capabilities, including none of them. However, the BACKWARD_COMPATIBLE capability must always be defined.

The supported hardware level of the device, as well as the specific Camera API2 capabilities it supports, are available as the following feature flags to allow Google Play filtering of Camera API2 camera apps.

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

CTS requirements

Devices running Android 5.0 and higher must pass the Camera API1 CTS, Camera API2 CTS, and CTS Verifier camera tests.

Devices that don't feature a Camera HAL3.2 implementation and aren't capable of supporting the full Camera API2 interfaces must still pass the Camera API2 CTS tests. However, the device runs in Camera API2 LEGACY mode (in which the Camera API2 calls are conceptually mapped to Camera API1 calls) so any Camera API2 CTS tests related to features or capabilities beyond Camera API1 are automatically skipped.

On legacy devices, Camera API2 CTS tests that are run use the existing public Camera API1 interfaces and capabilities with no new requirements. Bugs that are exposed (and that cause a Camera API2 CTS failure) are bugs already present in the device's existing Camera HAL, and thus would be found by existing Camera API1 apps. We don't expect many bugs of this nature (however, any such bugs must be fixed to pass the Camera API2 CTS tests).

VTS requirements

Devices running Android 8.0 and higher with binderized HAL implementations must pass the Camera VTS tests .

Camera framework hardening

To harden media and camera framework security, Android 7.0 moves camera service out of mediaserver. Starting with Android 8.0, each binderized Camera HAL runs in a process separate from camera service. Vendors may need to make changes in the camera HAL depending on the API and HAL versions in use. The following sections detail architectural changes in AP1 and AP2 for HAL1 and HAL3, as well as general requirements.

Architectural changes for API1

API1 video recording may assume camera and video encoder live in the same process. When using API1 on:

HAL3, where camera service uses BufferQueue to pass buffers between processes, no vendor update is necessary.
Figure 1. Android 7.0 camera and media stack in API1 on HAL3
HAL1, which supports passing metadata in video buffers, vendors must update the HAL to use kMetadataBufferTypeNativeHandleSource . ( kMetadataBufferTypeCameraSource is no longer supported in Android 7.0.)
Figure 2. Android 7.0 camera and media stack in API1 on HAL1

Architectural changes for API2

For API2 on HAL1 or HAL3, BufferQueue passes buffers so those paths continue to work. The Android 7.0 architecture for API2 on:

HAL1 isn't affected by the cameraservice move, and no vendor update is necessary.
HAL3 is affected, but no vendor update is necessary:
Figure 3. Android 7.0 camera and media stack in API2 on HAL3

Additional requirements

The architectural changes made for hardening media and camera framework security include the following additional device requirements.

General. Devices require additional bandwidth due to IPC, which may affect time-sensitive camera use cases such as high-speed video recording. Vendors can measure actual impact by running android.hardware.camera2.cts.PerformanceTest and the Google Camera app for 120/240 FPS high-speed video recording. Devices also require a small amount of additional RAM to create the new process.
Pass metadata in video buffers ( HAL1 only ). If HAL1 stores metadata instead of real YUV frame data in video buffers, the HAL must use kMetadataBufferTypeNativeHandleSource as the metadata buffer type and pass VideoNativeHandleMetadata in video buffers. ( kMetadataBufferTypeCameraSource is no longer supported on Android 7.0.) With VideoNativeHandleMetadata , camera and media frameworks are able to pass the video buffers between processes by serializing and deserializing the native handles properly.
Buffer handle address doesn't always store the same buffer ( HAL3 only ). For each capture request, HAL3 gets addresses of buffer handles. HAL can't use the addresses to identify buffers because the addresses may store another buffer handle after HAL returns the buffer. You must update the HAL to use buffer handles to identify the buffers. For example, HAL receives a buffer handle address A, which stores buffer handle A. After HAL returns buffer handle A, buffer handle address A may store buffer handle B next time the HAL receives it.
Update SELinux policies for cameraserver. If device-specific SELinux policies give mediaserver permissions to run the camera, you must update the SELinux policies to give cameraserver proper permissions. We discourage replicating the mediaserver's SELinux policies for cameraserver (as mediaserver and cameraserver generally require different resources in the system). Cameraserver should have only the permissions needed to perform camera functionalities and any unnecessary camera-related permissions in mediaserver should be removed.
Separation between Camera HAL and cameraserver. Android 8.0 and higher additionally separate the binderized Camera HAL in a process different from cameraserver. IPC goes through HIDL-defined interfaces.

Walidacja

For all devices that include a camera and run Android 8.0 and higher, verify the vendor implementation by running VTS.

Camera HAL version history

For a list of tests available for evaluating the Android Camera HAL, see the Camera HAL Testing Checklist .

Android 10

Android 10 introduces the following updates.

Camera API

Multi-camera improvements that allow physical cameras to be used individually or through corresponding logical cameras by hiding physical camera IDs. See Multi-Camera Support .
Ability to check whether a particular session configuration is supported without the performance overhead of creating a new session. See CameraDevice .
Ability to retrieve recommended stream configurations for a given use case to make the client more power efficient and performant. See getRecommendedStreamConfigurationMap .
Support for the depth JPEG image format . For further details, see the Dynamic Depth specification .
Support for the HEIC Image format . See HEIF Imaging .
Privacy improvements. Certain keys are required for the client to have CAMERA permissions before they can be retrieved from CameraCharacteristics . See getKeysNeedingPermission .

Camera HAL

The following Camera HAL versions are updated in Android 10.

3.5

ICameraDevice

getPhysicalCameraCharacteristics : The static camera information for a physical camera ID backing a logical camera device. See Multi-Camera Support .
isStreamCombinationSupported : This method supports a public API that helps clients query if a session configuration is supported. See API to query stream combinations .

ICameraDeviceSession

isReconfigurationNeeded : Method that tells the camera framework whether complete stream reconfiguration is required for possible new session parameter values. This helps avoid unnecessary camera reconfiguration delays. See Session reconfiguration query .
HAL buffer management APIs : These APIs allow the camera HAL to request buffers from the camera framework only when required instead of coupling each capture request with its associated buffers throughout the camera pipeline, resulting in potentially significant memory savings.
- signalStreamFlush : Signals to the HAL that the camera service is about to perform configureStreams_3_5 and that the HAL must return all buffers of designated streams.
- configureStreams_3_5 : Similar to ICameraDevice3.4.configureStreams , but in addition, the streamConfigCounter counter is provided to check for a race condition between the configureStreams_3_5 and signalStreamFlush calls.

Updates to ICameraDeviceCallback :

requestStreamBuffers : Synchronous callback that the camera HAL calls to ask the camera server for buffers. See requestStreamBuffers .
returnStreamBuffers : Synchronous callback for the camera HAL to return output buffers to the camera server. See returnStreamBuffers .

3.4

The following keys are added to camera metadata in Android 10.

Image formats
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
- ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
- ANDROID_SCALER_AVAILABLE_FORMATS_Y8
Camera metadata tags
- 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
Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
Values for the ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT key
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
- ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
Available dynamic depth stream configurations
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
Available HEIC stream configurations
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
- ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Camera module

The following camera module versions are updated in Android 10.

2.5

Adds the notifyDeviceStateChange method for devices to notify the camera HAL when physical changes, such as folding, affect camera and routing.

2.4

Devices launching with API level 29 or higher MUST report true for isTorchModeSupported .

Android 9

The Android 9 release introduces the following updates to the camera API2 and HAL interface.

Camera API

Introduces the multi-camera API to better support devices with multiple cameras facing in the same direction, enabling features such as bokeh and seamless zoom. This allows apps to view multiple cameras on a device as one logical unit (logical camera). Capture requests can also be sent to individual camera devices encompassed by one logical camera. See Multi-Camera Support .
Introduces session parameters. Session parameters are a subset of the available capture parameters that can cause severe processing delays when modified. These costs can be mitigated if clients pass their initial values during capture session initialization. See Session Parameters .
Adds optical stabilization (OIS) data keys for app-level stabilization and effects. See STATISTICS_OIS_SAMPLES .
Adds external flash support. See CONTROL_AE_MODE_ON_EXTERNAL_FLASH .
Adds a motion tracking intent in CAPTURE_INTENT . See CONTROL_CAPTURE_INTENT_MOTION_TRACKING .
Deprecates LENS_RADIAL_DISTORTION and adds LENS_DISTORTION in its place.
Adds distortion correction modes in CaptureRequest . See DISTORTION_CORRECTION_MODE .
Adds support for external USB/UVC cameras on supported devices. See INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL .

Camera HAL

3.4

Updates to ICameraDeviceSession

configureStreams_3_4 : Adds support for sessionParameters and logical cameras.
processCaptureRequest_3_4 : Adds support for including physical camera IDs in stream structure.

Updates to ICameraDeviceCallback

processCaptureResult_3_4 : Adds physical camera metadata in capture results.

3.3

The following keys are added to camera metadata in Android 9.

Capabilities
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
- ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
Camera metadata tags
- 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

The Android 8.0 release introduces Treble. With Treble, vendor Camera HAL implementations must be binderized . Android 8.0 also contains these key enhancements to the Camera service:

Shared surfaces: Enable multiple surfaces sharing the same OutputConfiguration
System API for custom camera modes
onCaptureQueueEmpty

See the sections below for more information on these features.

Shared surfaces

See the enableSurfaceSharing developer documentation for additional details.

System API for custom camera modes

To support this feature, OEMs merely need to add the new mode to their HAL, triggered by this integer passed to the HAL on configure_streams, and then have their custom camera app use the system API.

The method name is android.hardware.camera2.CameraDevice#createCustomCaptureSession . See: frameworks/base/core/java/android/hardware/camera2/CameraDevice .

onCaptureQueueEmpty

Camera HIDL interface

3.4

Minor additions to supported metadata and changes to data_space support:

Add ANDROID_SENSOR_OPAQUE_RAW_SIZE static metadata as mandatory if RAW_OPAQUE format is supported.
Add ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE static metadata as mandatory if any RAW format is supported.
Switch camera3_stream_t data_space field to a more flexible definition, using the version 0 definition of dataspace encoding.
General metadata additions which are available to use for HALv3.2 or newer:
- 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

Minor revision of expanded-capability HAL:

OPAQUE and YUV reprocessing API updates.
Basic support for depth output buffers.
Addition of data_space field to camera3_stream_t .
Addition of rotation field to camera3_stream_t .
Addition of camera3 stream configuration operation mode to camera3_stream_configuration_t .

3.2

Minor revision of expanded-capability HAL:

Deprecates get_metadata_vendor_tag_ops . Use get_vendor_tag_ops in camera_common.h instead.
Deprecates register_stream_buffers . All gralloc buffers provided by framework to HAL in process_capture_request may be new at any time.
Add partial result support. process_capture_result may be called multiple times with a subset of the available results before the full result is available.
Add manual template to camera3_request_template . Applications may use this template to control the capture settings directly.
Rework the bidirectional and input stream specifications.
Change the input buffer return path. The buffer is returned in process_capture_result instead of process_capture_request .

3.1

Minor revision of expanded-capability HAL:

configure_streams passes consumer usage flags to the HAL.
flush call to drop all in-flight requests/buffers as fast as possible.

3.0

First revision of expanded-capability HAL:

Major version change since the ABI is completely different. No change to the required hardware capabilities or operational model from 2.0.
Reworked input request and stream queue interfaces: Framework calls into HAL with next request and stream buffers already dequeued. Sync framework support is included, necessary for efficient implementations.
Moved triggers into requests, most notifications into results.
Consolidated all callbacks into framework into one structure, and all setup methods into a single initialize() call.
Made stream configuration into a single call to simplify stream management. Bidirectional streams replace the STREAM_FROM_STREAM construct.
Limited mode semantics for older/limited hardware devices.

2.0

Initial release of expanded-capability HAL (Android 4.2) [camera2.h]:

Sufficient for implementing existing android.hardware.Camera API.
Allows for ZSL queue in camera service layer.
Not tested for any new features such as manual capture control, Bayer RAW capture, reprocessing of RAW data, etc.

1.0

Initial Android camera HAL (Android 4.0) [camera.h]:

Converted from C++ CameraHardwareInterface abstraction layer.
Supports android.hardware.Camera API.

Camera module version history

2.4

This camera module version adds the following API changes:

Torch mode support. The framework can turn on torch mode for any camera device that has a flash unit, without opening a camera device. The camera device has a higher priority accessing the flash unit than the camera module; opening a camera device turns off the torch if it had been enabled through the module interface. When there are any resource conflicts, such as open() is called to open a camera device, the camera HAL module must notify the framework through the torch mode status callback that the torch mode has been turned off.
External camera (for example, USB hot-plug camera) support. The API updates specify the camera static info is available only when camera is connected and ready to use for external hot-plug cameras. Calls to get static info are invalid calls when camera status isn't CAMERA_DEVICE_STATUS_PRESENT . The framework counts solely on device status change callbacks to manage the available external camera list.
Camera arbitration hints. Adds support for explicitly indicating the number of camera devices that can be simultaneously opened and used. To specify valid combinations of devices, the resource_cost and conflicting_devices fields should always be set in the camera_info structure returned by the get_camera_info call.
Module initialization method. Called by the camera service after the HAL module is loaded to allow for one-time initialization of the HAL. It is called before any other module methods are invoked.

2.3

2.2

This camera module version adds vendor tag support from the module, and deprecates the old vendor_tag_query_ops that were previously only accessible with a device open.