Na tej stronie szczegółowo opisano różnice w wersjach aplikacji Camera HAL, API i powiązanych testach Compatibility Test Suite (CTS) . Omówiono także kilka zmian architektonicznych wprowadzonych w celu wzmocnienia i zabezpieczenia platformy aparatu w systemie Android 7.0, przejście na Treble w systemie Android 8.0 oraz aktualizacje, które dostawcy muszą wprowadzić, aby wspierać te zmiany w swoich implementacjach kamer.
Terminologia
Na tej stronie używane są następujące terminy:
- API aparatu 1
- Struktura aparatu na poziomie aplikacji na urządzeniach z systemem Android 4.4 i niższych, udostępniana za pośrednictwem klasy
android.hardware.Camera
. - API aparatu 2
- Struktura kamer na poziomie aplikacji na urządzeniach z Androidem 5.0 i nowszych, udostępniana za pośrednictwem pakietu
android.hardware.camera2
. - Kamera HAL
- Warstwa modułu kamery wdrożona przez dostawców SoC. Struktury publiczne na poziomie aplikacji są zbudowane na bazie warstwy HAL kamery.
- Kamera HAL3.1
- Wersja aparatu HAL wydana z systemem Android 4.4.
- Kamera HAL3.2
- Wersja aparatu HAL wydana z systemem Android 5.0.
- Kamera API1 CTS
- Zestaw testów CTS kamer działających na platformie Camera API1.
- Kamera API2 CTS
- Dodatkowy zestaw testów CTS kamer, które działają na platformie Camera API2.
- Potroić
- Oddziela implementację dostawcy (oprogramowanie niższego poziomu specyficzne dla urządzenia napisane przez producentów krzemu) od struktury systemu operacyjnego Android za pomocą nowego interfejsu dostawcy.
- HIDL
- Język definicji interfejsu HAL wprowadzony w Treble i używany do określania interfejsu pomiędzy HAL a jego użytkownikami.
- VTS
- Zestaw testów dostawców wprowadzony wraz z Treble.
Interfejsy API aparatu
Android zawiera następujące interfejsy API aparatu.
API aparatu 1
Android 5.0 wycofał interfejs Camera API1, który jest nadal wycofywany, ponieważ rozwój nowej platformy koncentruje się na Camera API2. Okres wycofywania będzie jednak długi i przez pewien czas wersje systemu Android będą nadal obsługiwać aplikacje Camera API1. W szczególności wsparcie będzie kontynuowane dla:
- Interfejsy API1 aparatu dla aplikacji. Aplikacje aparatu zbudowane na bazie interfejsu Camera API1 powinny działać tak samo, jak na urządzeniach z niższymi wersjami Androida.
- Wersje kamery HAL. Zawiera obsługę kamery HAL1.0.
API aparatu 2
Struktura Camera API2 umożliwia aplikacji sterowanie kamerą niższego poziomu, w tym wydajne przepływy zdjęć seryjnych/strumieniowych bez kopiowania oraz kontrolę ekspozycji, wzmocnienia, wzmocnienia balansu bieli, konwersji kolorów, usuwania szumów, wyostrzania i nie tylko. Aby uzyskać szczegółowe informacje, obejrzyj przegląd wideo Google I/O .
Android 5.0 i nowsze wersje zawierają Camera API2; jednakże urządzenia z systemem Android 5.0 i nowszym mogą nie obsługiwać wszystkich funkcji Camera API2. Właściwość android.info.supportedHardwareLevel
, do której aplikacje mogą wysyłać zapytania za pośrednictwem interfejsów Camera API2, zgłasza jeden z następujących poziomów wsparcia:
-
LEGACY
: Te urządzenia udostępniają aplikacjom możliwości za pośrednictwem interfejsów Camera API2, które mają w przybliżeniu takie same możliwości, jak te udostępniane aplikacjom za pośrednictwem interfejsów Camera API1. Kod starszej struktury koncepcyjnie tłumaczy wywołania Camera API2 na wywołania Camera API1; starsze urządzenia nie obsługują funkcji Camera API2, takich jak kontrola poszczególnych klatek. -
LIMITED
: Te urządzenia obsługują niektóre funkcje Camera API2 (ale nie wszystkie) i muszą korzystać z Camera HAL 3.2 lub nowszego. -
FULL
: Te urządzenia obsługują wszystkie główne możliwości interfejsu Camera API2 i muszą korzystać z aplikacji Camera HAL 3.2 lub nowszej oraz systemu Android 5.0 lub nowszego. -
LEVEL_3
: Te urządzenia obsługują przetwarzanie YUV i przechwytywanie obrazów RAW, a także dodatkowe konfiguracje strumienia wyjściowego. -
EXTERNAL
: Te urządzenia są podobne do urządzeńLIMITED
z pewnymi wyjątkami; na przykład niektóre informacje z czujnika lub obiektywu mogą nie być raportowane lub mieć mniej stabilną liczbę klatek na sekundę. Ten poziom jest używany w przypadku kamer zewnętrznych, takich jak kamery internetowe USB.
Poszczególne możliwości są udostępniane poprzez właściwość android.request.availableCapabilities
w interfejsach Camera API2. Urządzenia FULL
wymagają między innymi możliwości MANUAL_SENSOR
i MANUAL_POST_PROCESSING
. Możliwość RAW
jest opcjonalna nawet w przypadku urządzeń FULL
. Urządzenia LIMITED
mogą reklamować dowolny podzbiór tych funkcji, w tym żadną z nich. Jednak zawsze należy zdefiniować funkcję BACKWARD_COMPATIBLE
.
Obsługiwany poziom sprzętu urządzenia, a także konkretne obsługiwane przez nie funkcje Camera API2 są dostępne jako następujące flagi funkcji umożliwiające Google Play filtrowanie aplikacji aparatu Camera API2.
-
android.hardware.camera.hardware_level.full
-
android.hardware.camera.capability.raw
-
android.hardware.camera.capability.manual_sensor
-
android.hardware.camera.capability.manual_post_processing
Wymagania CTS
Urządzenia z systemem Android 5.0 i nowszym muszą przejść testy aparatu Camera API1 CTS, Camera API2 CTS i CTS Verifier.
Urządzenia, które nie są wyposażone w implementację Camera HAL3.2 i nie są w stanie obsługiwać pełnych interfejsów Camera API2, muszą mimo to przejść testy CTS Camera API2. Jednakże urządzenie działa w trybie Camera API2 LEGACY
(w którym wywołania Camera API2 są koncepcyjnie mapowane na wywołania Camera API1), więc wszelkie testy Camera API2 CTS związane z funkcjami lub możliwościami wykraczającymi poza Camera API1 są automatycznie pomijane.
Na starszych urządzeniach testy CTS Camera API2 przeprowadzane są przy użyciu istniejących publicznych interfejsów i możliwości Camera API1 bez nowych wymagań. Wykryte błędy (powodujące awarię CTS Camera API2) to błędy już obecne w istniejącej warstwie HAL Camera na urządzeniu i dlatego można je znaleźć w istniejących aplikacjach Camera API1. Nie spodziewamy się wielu błędów tego typu (jednak każdy taki błąd musi zostać naprawiony, aby przejść testy Camera API2 CTS).
Wymagania VTS
Urządzenia z systemem Android 8.0 i nowszym z powiązanymi implementacjami HAL muszą przejść testy Camera VTS .
Utwardzanie szkieletu aparatu
Aby zwiększyć bezpieczeństwo multimediów i kamer, Android 7.0 przenosi usługę kamery z serwera multimediów. Począwszy od systemu Android 8.0, każda powiązana warstwa HAL kamery działa w procesie niezależnym od usługi kamery. Dostawcy mogą być zobowiązani do wprowadzenia zmian w warstwie HAL kamery w zależności od używanej wersji interfejsu API i warstwy HAL. W poniższych sekcjach szczegółowo opisano zmiany architektoniczne w AP1 i AP2 dla HAL1 i HAL3, a także ogólne wymagania.
Zmiany architektoniczne dla API1
Nagrywanie wideo API1 może zakładać, że kamera i koder wideo działają w tym samym procesie. Podczas korzystania z API1 na:
- HAL3, gdzie usługa kamery wykorzystuje BufferQueue do przekazywania buforów pomiędzy procesami, nie jest konieczna żadna aktualizacja dostawcy .
- HAL1, który obsługuje przekazywanie metadanych w buforach wideo, dostawcy muszą zaktualizować HAL, aby używać
kMetadataBufferTypeNativeHandleSource
. (kMetadataBufferTypeCameraSource
nie jest już obsługiwany w systemie Android 7.0.)
Zmiany architektoniczne dla API2
W przypadku API2 na HAL1 lub HAL3 BufferQueue przekazuje bufory, aby te ścieżki nadal działały. Architektura Androida 7.0 dla API2 na:
- Przeniesienie usługi kamery nie ma wpływu na HAL1 i nie jest wymagana żadna aktualizacja dostawcy .
- Dotyczy to HAL3, ale nie jest wymagana żadna aktualizacja dostawcy :
Dodatkowe wymagania
Zmiany architektoniczne wprowadzone w celu zwiększenia bezpieczeństwa nośników i szkieletu kamery obejmują następujące dodatkowe wymagania dotyczące urządzeń.
- Ogólny. Urządzenia wymagają dodatkowej przepustowości ze względu na IPC, co może mieć wpływ na przypadki użycia kamery, w których liczy się czas, np. nagrywanie wideo z dużą szybkością. Sprzedawcy mogą zmierzyć rzeczywisty wpływ, uruchamiając
android.hardware.camera2.cts.PerformanceTest
i aplikację Google Camera do szybkiego nagrywania wideo z szybkością 120/240 kl./s. Urządzenia wymagają również niewielkiej ilości dodatkowej pamięci RAM, aby utworzyć nowy proces. - Przekazuj metadane w buforach wideo ( tylko HAL1 ). Jeśli warstwa HAL1 przechowuje metadane zamiast rzeczywistych danych ramki YUV w buforach wideo, warstwa HAL musi używać
kMetadataBufferTypeNativeHandleSource
jako typu bufora metadanych i przekazywaćVideoNativeHandleMetadata
w buforach wideo. (kMetadataBufferTypeCameraSource
nie jest już obsługiwany w systemie Android 7.0.) DziękiVideoNativeHandleMetadata
struktury kamer i multimediów mogą przekazywać bufory wideo między procesami poprzez prawidłową serializację i deserializację natywnych uchwytów. - Adres uchwytu bufora nie zawsze przechowuje ten sam bufor ( tylko HAL3 ). Dla każdego żądania przechwytywania HAL3 pobiera adresy uchwytów buforów. HAL nie może używać adresów do identyfikowania buforów, ponieważ adresy mogą przechowywać inny uchwyt bufora po tym, jak HAL zwróci bufor. Należy zaktualizować warstwę HAL, aby używać uchwytów buforów do identyfikowania buforów. Na przykład warstwa HAL odbiera adres uchwytu bufora A, który przechowuje uchwyt bufora A. Po tym, jak warstwa HAL zwróci uchwyt bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B następnym razem, gdy warstwa HAL go odbierze.
- Zaktualizuj zasady SELinux dla serwera kamer. Jeśli zasady SELinux specyficzne dla urządzenia dają serwerowi multimediów uprawnienia do uruchamiania kamery, należy zaktualizować zasady SELinux, aby nadać serwerowi kamery odpowiednie uprawnienia. Odradzamy replikowanie zasad SELinux serwera multimediów dla serwera kamer (ponieważ serwer multimediów i serwer kamer zazwyczaj wymagają różnych zasobów w systemie). Serwer kamery powinien mieć jedynie uprawnienia potrzebne do wykonywania funkcji kamery, a wszelkie niepotrzebne uprawnienia związane z kamerą na serwerze multimediów powinny zostać usunięte.
- Rozdzielenie pomiędzy kamerą HAL i serwerem kamer. Android 8.0 i nowsze dodatkowo oddzielają spakowaną kamerę HAL w procesie innym niż serwer kamery. IPC przechodzi przez interfejsy zdefiniowane w HIDL .
Walidacja
W przypadku wszystkich urządzeń wyposażonych w kamerę i działających pod kontrolą systemu Android 7.0 sprawdź implementację, uruchamiając system Android 7.0 CTS. Chociaż Android 7.0 nie zawiera nowych testów CTS weryfikujących zmiany w usługach aparatu, istniejące testy CTS nie powiodą się, jeśli nie dokonano wskazanych powyżej aktualizacji.
W przypadku wszystkich urządzeń wyposażonych w kamerę i korzystających z systemu Android 8.0 lub nowszego sprawdź implementację dostawcy, uruchamiając VTS.
Historia wersji kamery HAL
Listę testów dostępnych do oceny HAL aparatu Android znajdziesz na liście kontrolnej testowania HAL aparatu .
Androida 10
Android 10 wprowadza następujące aktualizacje.
API aparatu
- Ulepszenia obsługi wielu kamer, które umożliwiają używanie kamer fizycznych indywidualnie lub poprzez odpowiednie kamery logiczne poprzez ukrywanie identyfikatorów kamer fizycznych. Zobacz Obsługa wielu kamer .
- Możliwość sprawdzenia, czy konkretna konfiguracja sesji jest obsługiwana bez narzutu na wydajność związanego z tworzeniem nowej sesji. Zobacz
CameraDevice
. - Możliwość pobrania zalecanych konfiguracji strumieni dla danego przypadku użycia, aby zwiększyć energooszczędność i wydajność klienta. Zobacz
getRecommendedStreamConfigurationMap
. - Obsługa formatu obrazu JPEG z głębią . Dalsze szczegóły można znaleźć w specyfikacji Głębokość dynamiczna .
- Obsługa formatu obrazu HEIC . Zobacz Obrazowanie HEIF .
- Ulepszenia prywatności. Aby klient mógł pobrać określone klucze z
CameraCharacteristics
, wymagane jest posiadanie uprawnieńCAMERA
. ZobaczgetKeysNeedingPermission
.
Kamera HAL
Następujące wersje Camera HAL zostały zaktualizowane w systemie Android 10.
3.5
ICameraDevice
-
getPhysicalCameraCharacteristics
: statyczne informacje o kamerze dla identyfikatora kamery fizycznej wspierającego kamerę logiczną. Zobacz Obsługa wielu kamer . -
isStreamCombinationSupported
: Ta metoda obsługuje publiczny interfejs API, który pomaga klientom wysyłać zapytania, czy obsługiwana jest konfiguracja sesji. Zobacz API do sprawdzania kombinacji strumieni .
ICameraDeviceSession
-
isReconfigurationNeeded
: Metoda informująca strukturę kamery, czy wymagana jest pełna rekonfiguracja strumienia w celu uzyskania ewentualnych nowych wartości parametrów sesji. Pomaga to uniknąć niepotrzebnych opóźnień w rekonfiguracji kamery. Zobacz Zapytanie o rekonfigurację sesji . - Interfejsy API zarządzania buforem HAL : te interfejsy API umożliwiają kamerze HAL żądanie buforów ze struktury kamery tylko wtedy, gdy jest to wymagane, zamiast łączenia każdego żądania przechwytywania z powiązanymi z nim buforami w całym potoku kamery, co skutkuje potencjalnie znaczną oszczędnością pamięci.
-
signalStreamFlush
: Sygnalizuje warstwę HAL, że usługa kamery wkrótce wykonaconfigureStreams_3_5
i że warstwa HAL musi zwrócić wszystkie bufory wyznaczonych strumieni. -
configureStreams_3_5
: Podobny doICameraDevice3.4.configureStreams
, ale dodatkowo dostępny jest licznikstreamConfigCounter
w celu sprawdzenia warunku wyścigu międzyconfigureStreams_3_5
isignalStreamFlush
.
-
Aktualizacje ICameraDeviceCallback
:
-
requestStreamBuffers
: Synchroniczne wywołanie zwrotne wywoływane przez warstwę HAL kamery w celu zapytania serwera kamery o bufory. ZobaczrequestStreamBuffers
. -
returnStreamBuffers
: Synchroniczne wywołanie zwrotne dla warstwy HAL kamery w celu zwrócenia buforów wyjściowych do serwera kamery. ZobaczreturnStreamBuffers
.
3.4
Do metadanych aparatu w systemie Android 10 dodano następujące klucze.
- Formaty obrazów
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
-
ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
-
ANDROID_SCALER_AVAILABLE_FORMATS_Y8
-
- Tagi metadanych aparatu
-
ANDROID_REQUEST_CHARACTERISTIC_KEYS_NEEDING_PERMISSION
-
ANDROID_SCALER_AVAILABLE_RECOMMENDED_STREAM_CONFIGURATIONS
-
ANDROID_SCALER_AVAILABLE_RECOMMENDED_INPUT_OUTPUT_FORMATS_MAP
-
ANDROID_INFO_SUPPORTED_BUFFER_MANAGEMENT_VERSION
-
ANDROID_DEPTH_AVAILABLE_RECOMMENDED_DEPTH_STREAM_CONFIGURATIONS
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_MIN_FRAME_DURATIONS
-
ANDROID_LOGICAL_MULTI_CAMERA_ACTIVE_PHYSICAL_ID
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS
-
ANDROID_HEIC_AVAILABLE_HEIC_MIN_FRAME_DURATIONS
-
ANDROID_HEIC_AVAILABLE_HEIC_STALL_DURATIONS
-
ANDROID_HEIC_INFO_SUPPORTED
-
ANDROID_HEIC_INFO_MAX_JPEG_APP_SEGMENTS_COUNT
-
- Możliwości
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_SECURE_IMAGE_DATA
-
- Wartości dla klucza
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
-
ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
-
- Dostępne konfiguracje dynamicznego strumienia głębokości
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_OUTPUT
-
ANDROID_DEPTH_AVAILABLE_DYNAMIC_DEPTH_STREAM_CONFIGURATIONS_INPUT
-
- Dostępne konfiguracje strumieni HEIC
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
-
ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT
-
Moduł kamery
Następujące wersje modułów aparatu zostały zaktualizowane w systemie Android 10.
2.5
- Dodaje metodę
notifyDeviceStateChange
dla urządzeń, która powiadamia warstwę HAL kamery, gdy zmiany fizyczne, takie jak składanie, wpływają na kamerę i routing.
2.4
- Urządzenia uruchamiane z poziomem API 29 lub wyższym MUSZĄ zgłaszać
true
dlaisTorchModeSupported
.
Androida 9
W wersji Androida 9 wprowadzono następujące aktualizacje interfejsu API2 i HAL aparatu.
API aparatu
- Wprowadzono interfejs API obsługujący wiele kamer, aby lepiej obsługiwać urządzenia z wieloma kamerami skierowanymi w tym samym kierunku, umożliwiając korzystanie z takich funkcji, jak efekt bokeh i płynny zoom. Dzięki temu aplikacje mogą wyświetlać wiele kamer na urządzeniu jako jedną jednostkę logiczną (kamerę logiczną). Żądania przechwytywania można także wysyłać do poszczególnych kamer objętych jedną kamerą logiczną. Zobacz Obsługa wielu kamer .
- Wprowadza parametry sesji. Parametry sesji stanowią podzbiór dostępnych parametrów przechwytywania, które po modyfikacji mogą powodować poważne opóźnienia przetwarzania. Koszty te można ograniczyć, jeśli klienci przekażą swoje wartości początkowe podczas inicjowania sesji przechwytywania. Zobacz Parametry sesji .
- Dodaje klucze danych stabilizacji optycznej (OIS) do stabilizacji i efektów na poziomie aplikacji. Zobacz
STATISTICS_OIS_SAMPLES
. - Dodaje obsługę zewnętrznej lampy błyskowej. Patrz
CONTROL_AE_MODE_ON_EXTERNAL_FLASH
. - Dodaje zamiar śledzenia ruchu w
CAPTURE_INTENT
. ZobaczCONTROL_CAPTURE_INTENT_MOTION_TRACKING
. - Wycofuje
LENS_RADIAL_DISTORTION
i dodaje w jego miejscuLENS_DISTORTION
. - Dodaje tryby korekcji zniekształceń w
CaptureRequest
. ZobaczDISTORTION_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ę dołączania identyfikatorów kamer fizycznych do struktury strumienia.
Aktualizacje ICameraDeviceCallback
-
processCaptureResult_3_4
: Dodaje metadane kamery fizycznej do wyników przechwytywania.
3.3
Do metadanych aparatu w systemie Android 9 dodano następujące klucze.
- Możliwości
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
-
ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
-
- Tagi metadanych aparatu
-
ANDROID_LOGICAL_MULTI_CAMERA_PHYSICAL_IDS
-
ANDROID_LOGICAL_MULTI_CAMERA_SENSOR_SYNC_TYPE
-
ANDROID_DISTORTION_CORRECTION_AVAILABLE_MODES
-
ANDROID_LENS_POSE_REFERENCE
-
ANDROID_LENS_DISTORTION
-
ANDROID_REQUEST_AVAILABLE_SESSION_KEYS
-
ANDROID_REQUEST_AVAILABLE_PHYSICAL_CAMERA_REQUEST_KEYS
-
ANDROID_STATISTICS_OIS_DATA_MODE
-
ANDROID_STATISTICS_OIS_TIMESTAMPS
-
ANDROID_STATISTICS_OIS_X_SHIFTS
-
ANDROID_STATISTICS_OIS_Y_SHIFTS
-
Androida 8.0
W wersji Androida 8.0 wprowadzono Treble. W przypadku Treble implementacje HAL kamery dostawcy muszą być spakowane . Android 8.0 zawiera także następujące kluczowe ulepszenia usługi Aparat:
- Powierzchnie współdzielone: Włącz wiele powierzchni współdzielących tę samą
OutputConfiguration
- Interfejs API systemu dla niestandardowych trybów aparatu
-
onCaptureQueueEmpty
Więcej informacji na temat tych funkcji można znaleźć w poniższych sekcjach.
Wspólne powierzchnie
Ta funkcja umożliwia użycie tylko jednego zestawu buforów do obsługi dwóch wyjść, takich jak podgląd i kodowanie wideo, co zmniejsza zużycie energii i pamięci. Aby obsługiwać tę funkcję, producenci urządzeń muszą upewnić się, że implementacje HAL i gralloc HAL w ich kamerach umożliwiają tworzenie buforów gralloc używanych przez wielu różnych konsumentów (takich jak sprzętowy kompozytor/GPU i koder wideo), a nie tylko jeden konsument. Usługa kamery przekazuje flagi użytkowania klienta do warstwy HAL kamery i warstwy HAL gralloc; muszą albo przydzielić odpowiednie rodzaje buforów, albo HAL kamery musi zwrócić błąd informujący, że ta kombinacja konsumentów nie jest obsługiwana.
Dodatkowe szczegóły można znaleźć w dokumentacji programisty enableSurfaceSharing
.
Interfejs API systemu dla niestandardowych trybów aparatu
Interfejs API kamer publicznych definiuje dwa tryby działania: normalne i ograniczone nagrywanie z dużą szybkością. Mają dość odmienną semantykę; na przykład tryb dużej prędkości jest ograniczony do maksymalnie dwóch określonych wyjść jednocześnie. Różni producenci OEM wyrazili zainteresowanie zdefiniowaniem innych niestandardowych trybów dla możliwości specyficznych dla sprzętu. W skrócie, tryb jest po prostu liczbą całkowitą przekazywaną configure_streams
. Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams
.
Ta funkcja obejmuje wywołanie systemowego interfejsu API, za pomocą którego aplikacje aparatu OEM mogą włączyć tryb niestandardowy. Tryby te muszą zaczynać się od wartości całkowitej 0x8000, aby uniknąć konfliktu z przyszłymi trybami dodanymi do publicznego interfejsu API.
Aby obsługiwać tę funkcję, producenci OEM muszą jedynie dodać nowy tryb do swojej warstwy HAL, wyzwalany przez tę liczbę całkowitą przekazaną do warstwy HAL w konfiguracji_streams, a następnie pozwolić swojej niestandardowej aplikacji aparatu na korzystanie z systemowego interfejsu API.
Nazwa metody to android.hardware.camera2.CameraDevice#createCustomCaptureSession
. Zobacz: frameworks/base/core/java/android/hardware/camera2/CameraDevice
.
onCaptureQueueEmpty
Celem tego interfejsu API jest zmniejszenie opóźnień związanych ze zmianami kontroli, takimi jak powiększenie, poprzez utrzymywanie możliwie pustej kolejki żądań. onCaptureQueueEmpty
nie wymaga pracy HAL; był to wyłącznie dodatek po stronie frameworka. Aplikacje, które chcą z tego skorzystać, muszą dodać słuchacza do tego wywołania zwrotnego i odpowiednio zareagować. Zwykle polega to na wysłaniu kolejnego żądania przechwytywania do urządzenia z kamerą.
Interfejs aparatu HIDL
Interfejs Camera HIDL to kompletna przeróbka interfejsu Camera HAL, który wykorzystuje stabilne API zdefiniowane przez HIDL. Wszystkie funkcje i możliwości aparatu wprowadzone w najnowszych starszych wersjach 3.4 i 2.4 (dla modułu kamery) są również częścią definicji HIDL.
3.4
Drobne dodatki do obsługiwanych metadanych i zmiany w obsłudze data_space:
- Dodaj statyczne metadane
ANDROID_SENSOR_OPAQUE_RAW_SIZE
jako obowiązkowe, jeśli obsługiwany jest formatRAW_OPAQUE
. - Dodaj statyczne metadane
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
jako obowiązkowe, jeśli obsługiwany jest dowolny format RAW. - Zmień pole
camera3_stream_t data_space
na bardziej elastyczną definicję, korzystając z definicji kodowania przestrzeni danych w wersji 0. - Ogólne dodatki do metadanych, które można wykorzystać w wersji HALv3.2 lub nowszej:
-
ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
-
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
-
ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
-
ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
-
ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
-
ANDROID_SENSOR_OPAQUE_RAW_SIZE
-
ANDROID_SENSOR_OPTICAL_BLACK_REGIONS
-
3.3
Drobna wersja HAL o rozszerzonych możliwościach:
- Aktualizacje API ponownego przetwarzania OPAQUE i YUV.
- Podstawowa obsługa buforów wyjściowych głębokości.
- Dodanie pola
data_space
docamera3_stream_t
. - Dodanie pola obrotu do
camera3_stream_t
. - Dodanie trybu pracy konfiguracji strumienia kamery3 do
camera3_stream_configuration_t
.
3.2
Drobna wersja HAL o rozszerzonych możliwościach:
- Przestarzałe
get_metadata_vendor_tag_ops
. Zamiast tego użyjget_vendor_tag_ops
wcamera_common.h
. - Przestarzałe
register_stream_buffers
. Wszystkie bufory gralloc dostarczone przez framework do HAL wprocess_capture_request
mogą być w każdej chwili nowe. - Dodaj częściową obsługę wyników.
process_capture_result
można wywoływać wielokrotnie z podzbiorem dostępnych wyników, zanim dostępny będzie pełny wynik. - Dodaj szablon ręczny do
camera3_request_template
. Aplikacje mogą używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania. - Przerób specyfikacje strumienia dwukierunkowego i wejściowego.
- Zmień ścieżkę zwrotną bufora wejściowego. Bufor jest zwracany w
process_capture_result
zamiastprocess_capture_request
.
3.1
Drobna wersja HAL o rozszerzonych możliwościach:
-
configure_streams
przekazuje flagi użytkowania konsumenta do warstwy HAL. - wywołanie typu Flush, aby jak najszybciej usunąć wszystkie żądania/bufory w locie.
3.0
Pierwsza wersja HAL o rozszerzonych możliwościach:
- Duża zmiana wersji, ponieważ ABI jest zupełnie inne. Brak zmian w wymaganych możliwościach sprzętowych i modelu operacyjnym od wersji 2.0.
- Przerobione interfejsy żądań wejściowych i kolejek strumieniowych: wywołania frameworka do HAL z następnym żądaniem i buforami strumieniowymi już usuniętymi z kolejki. Uwzględniono obsługę środowiska synchronizacji, niezbędną do wydajnych wdrożeń.
- Przeniesiono wyzwalacze do żądań, większość powiadomień do wyników.
- Skonsolidowano wszystkie wywołania zwrotne w ramach w jedną strukturę, a wszystkie metody konfiguracji w jednym wywołaniu
initialize()
. - Dokonano konfiguracji strumienia w jednym wywołaniu, aby uprościć zarządzanie strumieniem. Strumienie dwukierunkowe zastępują konstrukcję
STREAM_FROM_STREAM
. - Semantyka trybu ograniczonego dla starszych/ograniczonych urządzeń sprzętowych.
2.0
Pierwsza wersja HAL o rozszerzonych możliwościach (Android 4.2) [camera2.h]:
- Wystarczające do wdrożenia istniejącego API
android.hardware.Camera
. - Umożliwia kolejkę ZSL w warstwie usług kamer.
- Nie testowano pod kątem żadnych nowych funkcji, takich jak ręczna kontrola przechwytywania, przechwytywanie Bayer RAW, ponowne przetwarzanie danych RAW itp.
1,0
Początkowa kamera z Androidem HAL (Android 4.0) [camera.h]:
- Przekonwertowano z warstwy abstrakcji C++ CameraHardwareInterface.
- Obsługuje API
android.hardware.Camera
.
Historia wersji modułu kamery
Ta sekcja zawiera informacje o wersji modułu sprzętowego Camera w oparciu o camera_module_t.common.module_api_version
. Dwie najbardziej znaczące cyfry szesnastkowe reprezentują wersję główną, a dwie najmniej znaczące reprezentują wersję pomocniczą.
2.4
Ta wersja modułu kamery dodaje następujące zmiany API:
- Obsługa trybu latarki. Struktura może włączyć tryb latarki dla dowolnego aparatu wyposażonego w lampę błyskową, bez konieczności otwierania aparatu. Aparat ma wyższy priorytet w dostępie do lampy błyskowej niż moduł aparatu; otwarcie urządzenia z kamerą powoduje wyłączenie latarki, jeśli została włączona poprzez interfejs modułu. W przypadku wystąpienia konfliktów zasobów, np. wywołania
open()
w celu otwarcia urządzenia z kamerą, moduł HAL kamery musi powiadomić platformę za pomocą wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony. - Obsługa kamer zewnętrznych (na przykład kamer USB z możliwością podłączenia podczas pracy). Aktualizacje API określają, że informacje statyczne kamery są dostępne tylko wtedy, gdy kamera jest podłączona i gotowa do użycia z zewnętrznymi kamerami z możliwością podłączenia podczas pracy. Wywołania mające na celu uzyskanie informacji statycznych są nieprawidłowymi wywołaniami, gdy stan kamery jest inny niż
CAMERA_DEVICE_STATUS_PRESENT
. Struktura liczy wyłącznie na wywołania zwrotne zmiany stanu urządzenia w celu zarządzania listą dostępnych kamer zewnętrznych. - Wskazówki dotyczące arbitrażu kamery. Dodaje obsługę bezpośredniego wskazywania liczby kamer, które można jednocześnie otwierać i używać. Aby określić prawidłowe kombinacje urządzeń, w strukturze
camera_info
zwróconej przez wywołanieget_camera_info
należy zawsze ustawić polaresource_cost
iconflicting_devices
. - Metoda inicjalizacji modułu. Wywoływane przez usługę kamery po załadowaniu modułu HAL, aby umożliwić jednorazową inicjalizację warstwy HAL. Jest wywoływana przed wywołaniem jakichkolwiek innych metod modułu.
2.3
Ta wersja modułu kamery dodaje obsługę urządzeń HAL z otwartą kamerą starszego typu. Struktura może go użyć do otwarcia urządzenia kamery jako urządzenia niższej wersji HAL urządzenia HAL, jeśli to samo urządzenie może obsługiwać wiele wersji API urządzenia. Standardowe wywołanie otwartego modułu sprzętowego ( common.methods->open
) w dalszym ciągu otwiera kamerę z najnowszą obsługiwaną wersją, która jest również wersją wymienioną w camera_info_t.device_version
.
2.2
Ta wersja modułu kamery dodaje obsługę tagów dostawcy z modułu i wycofuje starą vendor_tag_query_ops
, która wcześniej była dostępna tylko przy otwartym urządzeniu.
2.1
Ta wersja modułu kamery dodaje obsługę asynchronicznych wywołań zwrotnych do platformy z modułu HAL kamery, która służy do powiadamiania platformy o zmianach w stanie modułu kamery. Moduły udostępniające prawidłową metodę set_callbacks()
muszą zgłaszać co najmniej ten numer wersji.
2.0
Moduły kamer zgłaszające ten numer wersji implementują drugą wersję interfejsu HAL modułu kamery. Urządzenia z kamerą otwierane za pomocą tego modułu mogą obsługiwać wersję 1.0 lub wersję 2.0 interfejsu HAL urządzenia z kamerą. Pole device_version
w parametrze Camera_info jest zawsze prawidłowe; pole static_camera_characteristics
w parametrze camera_info
jest prawidłowe, jeśli pole device_version
ma wartość 2.0 lub wyższą.
1,0
Moduły kamer zgłaszające te numery wersji implementują początkowy interfejs HAL modułu kamery. Wszystkie urządzenia z kamerą, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 urządzenia z kamerą HAL. Pola device_version
i static_camera_characteristics
w parametrze camera_info
są nieprawidłowe. Ten moduł i jego urządzenia mogą obsługiwać wyłącznie interfejs API android.hardware.Camera
.