Obsługa wersji aparatu

Na tej stronie znajdują się szczegółowe informacje o różnicach w wersjach w kodach HAL, interfejsach API i powiązanych wersjach aparatu testy Compatibility Test Suite (CTS). Obejmują one również zmiany w architekturze wprowadzone w celu wzmocnienia i zabezpieczenia struktury aparatu w Androidzie 7.0, przejście na Treble w Androidzie 8.0, a dostawcy muszą wprowadzić aktualizacje obsługują te zmiany w implementacjach aparatów.

Terminologia

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

Interfejs API kamery 1
Platforma aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 i starszymi w klasie android.hardware.Camera.
Interfejs API kamery 2
Platforma aparatu na poziomie aplikacji na urządzeniach z Androidem 5.0 lub nowszym, publicznie dostępna w pakiecie android.hardware.camera2.
HAL aparatu
Warstwa modułu kamery zaimplementowana przez dostawców układów SOC. Publiczne na poziomie aplikacji platformy są oparte na HAL aparatu.
Aparat HAL3.1
Wersja HAL aparatu z Androidem 4.4.
Aparat HAL3.2
Wersja HAL aparatu z Androidem 5.0.
CTS interfejsu Camera API1
Zestaw testów CTS kamery przeprowadzanych na kamerze Interfejs API1.
CTS interfejsu Camera API2
Dodatkowy zestaw testów CTS kamery uruchamianych razem z interfejsem Camera API2.
Sopran
Oddziela implementację dostawcy (oprogramowanie niższego poziomu dostosowane do urządzenia (pisanych przez producentów krzemów) z platformy systemu operacyjnego Android za pomocą za pomocą interfejsu dostawcy usług internetowych.
HIDL
Język definicji interfejsu HAL wprowadzono za pomocą Treble i służyło do określania interfejsu między HAL swoich użytkowników.
VTS
Wprowadzono pakiet testów dostawców Tony wysokie.

Interfejsy API aparatu

Android obejmuje poniższe interfejsy API aparatu.

Interfejs API kamery 1

Android 5.0 wycofany interfejs Camera API1, który wciąż jest wycofywany jako nowy W procesie rozwoju platformy koncentrujemy się na interfejsie Camera API2. Jednak okres wycofywania będzie a wersje na Androida nadal będą obsługiwać aplikacje Camera API1 za jakiś czas. Dotyczy to w szczególności tych kategorii:

  • Interfejsy Camera API1 do aplikacji. Aplikacje aparatu stworzone na bazie Aparatu Interfejs API1 powinien działać tak samo jak na urządzeniach z starszymi wersjami Androida.
  • Wersje HAL aparatu. Obejmuje obsługę HAL1.0 aparatu.

Interfejs API kamery 2

Interfejs Camera API2 umożliwia aplikacji niższy poziom kontroli nad kamerą, w tym wydajne przepływy zdjęć typu burst/strumieniowanie bez żadnej kopii i ustawienia dla poszczególnych klatek ekspozycja, wzmocnienie, wzmocnienia balansu bieli, konwersja kolorów, odszumienie, wyostrzenie, i inne. Aby dowiedzieć się więcej, obejrzyj Omówienie Google I/O – wideo.

Android 5.0 lub nowszy zawiera interfejs Camera API2. jednak na urządzeniach z Androidem Wersja 5.0 i nowsze mogą nie obsługiwać wszystkich funkcji interfejsu Camera API2. android.info.supportedHardwareLevel właściwość, o które aplikacje mogą wysyłać zapytania przez interfejsy Camera API2 zgłasza jedną z poniższych poziomy:

  • LEGACY: te urządzenia udostępniają możliwości aplikacjom za pomocą Interfejsy Camera API2, które mają mniej więcej takie same możliwości dostępne dla aplikacji przez interfejsy Camera API1. Kod starszych platform koncepcyjnie przekłada wywołania interfejsu API2 kamery na wywołania interfejsu API1 kamery; starsze urządzenia nie obsługują funkcji interfejsu Camera API2, takich jak elementy sterujące klatki.
  • LIMITED: te urządzenia obsługują niektóre funkcje interfejsu Camera API2 (ale nie wszystkie) i musi obsługiwać standard HAL 3.2 lub nowszy.
  • FULL: te urządzenia obsługują wszystkie główne funkcje Interfejs Camera API2 i musi używać interfejsu HAL 3.2 lub nowszego oraz Androida w wersji 5.0 lub nowszej.
  • LEVEL_3: te urządzenia obsługują ponowne przetwarzanie obrazu YUV i obraz RAW oraz dodatkowe konfiguracje strumienia wyjściowego.
  • EXTERNAL: te urządzenia są podobne do urządzenia LIMITED urządzenia z pewnymi wyjątkami; Na przykład niektóre informacje z czujnika lub obiektywu nie będą zgłaszane lub mają mniej stabilną liczbę klatek. Ten poziom jest używany na zewnątrz na przykład kamer internetowych USB.

Poszczególne możliwości są przedstawiane w Właściwość android.request.availableCapabilities w interfejsie Camera API2 i interfejsów. FULL urządzeń wymaga tych uprawnień: MANUAL_SENSOR i MANUAL_POST_PROCESSING. Funkcja RAW jest opcjonalna nawet w przypadku urządzeń FULL. Urządzenia z LIMITED mogą reklamować dowolny podzbiór tych funkcji. bez żadnego z nich. Funkcja BACKWARD_COMPATIBLE musi być zawsze zdefiniowany.

Obsługiwany poziom sprzętu i konkretna kamera obsługiwane przez niego funkcje interfejsu API2 są dostępne jako poniższe flagi funkcji zezwalanie na filtrowanie przez Google Play aplikacji aparatu z interfejsu 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 dotyczące CTS

Urządzenia z Androidem 5.0 lub nowszym muszą spełniać kryteria CTS interfejsu Camera API1 i Aparatu z testów CTS interfejsu API2 i CTS Verifiera.

Urządzenia, które nie mają implementacji HAL3.2 kamery i nie są zdolny do obsługi wszystkich interfejsów Camera API2 musi w dalszym ciągu testów CTS interfejsu API2. Urządzenie działa jednak w interfejsie Camera API2. Tryb LEGACY (w którym wywołania interfejsu Camera API2 są mapowane koncepcyjnie do wywołań interfejsu API1 kamery), więc wszelkie testy CTS interfejsu Camera API2 dotyczące funkcji lub funkcje wykraczające poza interfejs Camera API1 są automatycznie pomijane.

Na starszych urządzeniach przeprowadzane testy CTS interfejsu Camera API2 korzystają z zasady dostępnych publicznie interfejsów i możliwości interfejsu Camera API1 bez nowych możliwości . ujawnione błędy (które powodują błąd CTS interfejsu Camera2 API2), są już obecne w dotychczasowym HAL aparatu na urządzeniu, więc nie znajduje się w istniejących aplikacjach z interfejsu Camera API1. Nie spodziewamy się wielu błędów tego rodzaju (takie błędy muszą jednak zostać naprawione, aby przejść testy CTS interfejsu Camera2 API2).

Wymagania dotyczące VTS

Urządzenia z Androidem 8.0 lub nowszym z powiązaną implementacją HAL muszą mijanie kamery Testy VTS.

Wzmacnianie szkieletu kamery

Aby wzmocnić zabezpieczenia multimediów i platformy aparatu, w Androidzie 7.0 wprowadzamy zmiany w aparacie poza serwerem mediów. Od Androida 8.0 każda powiązana kamera HAL jest uruchamiany w procesie innym niż usługa aparatu. Dostawcy mogą mieć obowiązek zmian HAL aparatu w zależności od używanych wersji interfejsu API i HAL. w kolejnych sekcjach znajdziesz szczegółowe informacje o zmianach w architekturze w interfejsach AP1 i AP2 dotyczących HAL1 oraz HAL3 oraz wymagania ogólne.

Zmiany architektoniczne dla interfejsu API1

W przypadku nagrywania filmu za pomocą API1 kamera i koder wideo mogą działać w tym samym proces tworzenia konta. Jeśli używasz API1 w:

  • HAL3, gdzie usługa kamery korzysta z BufferQueue do przesyłania buforów między Dostawcy nie muszą aktualizować żadnych informacji.

    Aparat i multimedia na Androidzie 7.0 stos w API1 w HAL3

    Rysunek 1. Aparat i multimedia w Androidzie 7.0 stos w API1 w HAL3

  • HAL1, który obsługuje przekazywanie metadanych w buforach wideo. Dostawcy muszą zaktualizuj HAL tak, aby używała wartości kMetadataBufferTypeNativeHandleSource. (Nazwa kMetadataBufferTypeCameraSource nie jest już obsługiwana na Androidzie 7,0)

    Aparat i multimedia na Androidzie 7.0 stos w API1 w HAL1

    Rysunek 2. Aparat i multimedia w Androidzie 7.0 stos w API1 w HAL1

Zmiany architektoniczne dla API2

W przypadku API2 w HAL1 lub HAL3 BufferQueue przekazuje bufory, aby zapewnić ciągłość ścieżki. do pracy. Architektura Androida 7.0 dla interfejsu API2:

  • Przeniesienie usługi Cameraservice nie ma wpływu na HAL1 ani brak dostawcy
  • Usługa HAL3 ma problem, ale nie została zaktualizowana przez dostawcę konieczne:

    Aparat w Androidzie 7.0 i stos multimediów w API2 w HAL3

    Rysunek 3. Aparat i multimedia w Androidzie 7.0 stos w API2 w HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w celu wzmocnienia multimediów i konstrukcji kamery obejmują dodatkowe wymagania dotyczące urządzeń.

  • Postanowienia ogólne. Urządzenia wymagają dodatkowej przepustowości ze względu na standard IPC, co może mieć wpływ na korzystanie z aparatu, gdy tylko jest to potrzebne, np. nagrywanie z dużą prędkością. nagrywanie. Dostawcy mogą mierzyć rzeczywisty wpływ poprzez android.hardware.camera2.cts.PerformanceTest i Aparat Google Aplikacja do nagrywania filmów z szybkością 120/240 FPS. Urządzenia muszą też mieć i niewielkiej ilości dodatkowej pamięci RAM do utworzenia nowego procesu.
  • Przekazywanie metadanych w buforach filmu (tylko HAL1). Jeśli HAL1 przechowuje metadane zamiast rzeczywistych danych klatki YUV w buforach wideo, kod HAL musi użyj kMetadataBufferTypeNativeHandleSource jako bufora metadanych wpisz i przekaż VideoNativeHandleMetadata w buforach wideo. (Nazwa kMetadataBufferTypeCameraSource nie jest już obsługiwana na Androidzie 7,0) Z VideoNativeHandleMetadata i platformami aparatu i multimediów mogą przesyłać bufory wideo między procesami przez serializację deserializacji uchwytów natywnych.
  • Adres bufora nie zawsze przechowuje taki sam bufor (tylko HAL3). Dla każdego żądania przechwytywania HAL3 otrzymuje adresy bufora uchwytów. HAL nie może używać adresów do identyfikowania buforów, ponieważ adresy może zapisać inny uchwyt bufora po zwróceniu bufora przez HAL. Musisz zaktualizować HAL, aby użyć uchwytów buforów do identyfikacji buforów. Na przykład kod HAL odbiera na przykład adres uchwytu bufora A, który zawiera uchwyt bufora A. Po zwrotach HAL uchwyt bufora A, adres uchwytu bufora A może zapisać uchwyt bufora B następnym razem, HAL otrzymuje wiadomość.
  • Zaktualizuj zasady SELinux dotyczące serwera Cameraserver. Jeśli specyficzne dla urządzenia zasady SELinux przyznają serwerowi mediów uprawnienia do uruchamiania kamery musisz zaktualizować zasady SELinux, aby przyznać serwerowi kamery odpowiednie uprawnienia. Śr zniechęcaj do replikowania zasad SELinux serwera mediów dla serwera Cameraserver (ponieważ serwer mediów i serwer kamery wymagają zwykle różnych zasobów ). Serwer kamery powinien mieć tylko uprawnienia wymagane do działania kamery funkcje i wszystkie niepotrzebne uprawnienia związane z aparatem na serwerze mediów. powinny zostać usunięte.
  • Oddzielenie między HAL kamery i serwerem kamery. Android, w wersji 8.0 i nowszych dodatkowo oddzielają powiązane dane HAL aparatu inaczej niż serwer kamery. Proces IPC przechodzi przez weryfikację Interfejsy zdefiniowane przez HIDL.

Weryfikacja

Na wszystkich urządzeniach z Androidem 7.0, które mają aparat, sprawdź na Androidzie 7.0 CTS. Chociaż w Androidzie 7.0 nie ma nowe testy CTS weryfikujące zmiany w działaniu kamery, obecne testy CTS kończą się niepowodzeniem .

Na wszystkich urządzeniach z aparatem i Androidem 8.0 lub nowszym wdrożenie z dostawcą przez uruchomienie VTS.

Historia wersji HAL aparatu

Listę testów dostępnych do oceny kodu HAL aparatu z Androidem znajdziesz w Testowanie HAL aparatu Lista kontrolna.

Android 10

Android 10 wprowadza poniższe aktualizacje.

Interfejs Camera API

HAL aparatu

Te wersje HAL aparatu są aktualizowane na urządzeniach z Androidem 10.

3,5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: Metoda, która informuje kamerę, czy transmisja została zakończona wymagana jest ponowna konfiguracja dla możliwych nowych wartości parametrów sesji. Ten pomaga uniknąć opóźnień w ponownej konfiguracji kamery. Zobacz Zapytanie o ponowną konfigurację sesji.
  • HAL interfejsy API do zarządzania buforem: umożliwiają wysyłanie żądań HAL aparatu. buforuje ramkę kamery tylko wtedy, gdy jest to wymagane, zamiast łączyć i powiązanych z nimi buforów w całym potoku kamery, co może doprowadzić do potencjalnie znacznej oszczędności pamięci.
    • signalStreamFlush: sygnalizuje HAL, że kamera usługa ma działać configureStreams_3_5 oraz że HAL musi zwracać wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5: podobny do ICameraDevice3.4.configureStreams, ale w ciągu dodatkowo, licznik streamConfigCounter jest dostarczany do sprawdzić stan wyścigu między configureStreams_3_5 i signalStreamFlush połączeń.

Aktualizacje w ICameraDeviceCallback:

  • requestStreamBuffers: Synchroniczne wywołanie zwrotne, które wywołuje interfejs HAL kamery, aby zażądać od serwera kamery bufory. Zobacz requestStreamBuffers
  • returnStreamBuffers: Synchroniczne wywołanie zwrotne dla HAL kamery, które zwraca bufory wyjściowe do serwera kamery. Zobacz returnStreamBuffers

3,4

Poniższe klucze są dodawane do metadanych kamery w Androidzie 10.

  • Formaty obrazu
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW10
    • ANDROID_SCALER_AVAILABLE_FORMATS_RAW12
    • ANDROID_SCALER_AVAILABLE_FORMATS_Y8
  • Tagi metadanych kamery
    • 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 parametru ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT klawisz
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_MONO
    • ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT_NIR
  • Dostępne konfiguracje strumienia dynamicznej głębi
    • 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ł aparatu

Te wersje modułu aparatu są aktualizowane na Androidzie 10.

2,5

  • Dodaje metodę notifyDeviceStateChange, o której powiadamiają urządzenia HAL aparatu, gdy zmienia się jego działanie (np. składanie) wpływa na .

2,4

  • Urządzenia uruchamiane z interfejsem API na poziomie 29 lub wyższym MUSZĄ zgłaszać true – isTorchModeSupported.

Android 9

W Androidzie 9 wprowadziliśmy poniższe aktualizacje interfejsu API 2 oraz aparatu Interfejs HAL.

Interfejs Camera API

  • Wprowadza interfejs API do obsługi wielu kamer, aby lepiej obsługiwać urządzenia z kilkoma kamery są skierowane w tę samą stronę, co umożliwia korzystanie z funkcji takich jak bokeh czy bokeh. płynne powiększanie. Umożliwia to aplikacjom wyświetlanie kilku kamer na urządzeniu jako jednej jednostka logiczna (kamera logiczna). Prośby o przechwytywanie można również wysyłać do poszczególnych użytkowników oraz obejmującym jedną kamerę logiczną. Zobacz Obsługa wielu aparatów.
  • Zawiera parametry sesji. Parametry sesji są podzbiorem parametrów parametrów rejestrowania, które mogą powodować poważne opóźnienia przetwarzania, zmodyfikowane. Koszty te można ograniczyć, jeśli klienci przekazują swoje początkowe wartości. podczas inicjowania sesji przechwytywania. Zobacz Parametry sesji.
  • Dodano klucze danych stabilizacji optycznej (OIS) na potrzeby stabilizacji na poziomie aplikacji. efekty. Zobacz STATISTICS_OIS_SAMPLES
  • Dodaje obsługę zewnętrznej pamięci flash. Zobacz CONTROL_AE_MODE_ON_EXTERNAL_FLASH
  • Dodaje intencję śledzenia ruchu w interfejsie CAPTURE_INTENT. Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING
  • Wycofuje język LENS_RADIAL_DISTORTION i dodaje 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

HAL aparatu

3,4

Aktualizacje do: ICameraDeviceSession

Aktualizacje do: ICameraDeviceCallback

3,3

Poniższe klucze są dodawane do metadanych kamery w Androidzie 9.

  • Możliwości
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_LOGICAL_MULTI_CAMERA
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MOTION_TRACKING
    • ANDROID_REQUEST_AVAILABLE_CAPABILITIES_MONOCHROME
  • Tagi metadanych kamery
    • 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

W Androidzie 8.0 wprowadzamy Treble. Treble, HAL aparatu fotograficznego muszą być powiązane. Android 8.0 też zawiera te ważne ulepszenia usługi Aparat:

  • Współdzielone platformy: włącz wiele platform współdzielących to samo OutputConfiguration
  • Systemowy interfejs API do niestandardowych trybów aparatu
  • onCaptureQueueEmpty

Więcej informacji o tych funkcjach znajdziesz w sekcjach poniżej.

Udostępnione platformy

Ta funkcja umożliwia generowanie 2 danych wyjściowych za pomocą tylko jednego zestawu buforów, np. podglądu i kodowania wideo, co zmniejsza zużycie energii i pamięci. Do obsługują tę funkcję, producenci urządzeń muszą zadbać o to, by ich aparaty HAL Implementacje gralloc HAL mogą tworzyć bufory gralloc, które są używane przez do różnych użytkowników (np. do sprzętowego kompozytora/GPU oraz kodera), a nie tylko jednego konsumenta. Usługa kamery mija flagi użytkowania dla klientów indywidualnych do HAL aparatu i gralloc HAL; muszą albo przydzielić odpowiednie rodzaje buforów, w przeciwnym razie interfejs HAL aparatu musi zwrócić błąd że to połączenie konsumentów nie jest obsługiwane.

Zobacz enableSurfaceSharing dokumentacji dla deweloperów.

Systemowy interfejs API do niestandardowych trybów aparatu

Interfejs Public Camera API definiuje 2 tryby działania: normalny i ograniczony i nagrywanie z dużą prędkością. Mają nieco inną semantykę. np. tryb wysokiej prędkości jest ograniczony do maksymalnie 2 określonych wyjścia jednocześnie. Różne Producenci OEM wyrazili zainteresowanie zdefiniowaniem innych trybów niestandardowych możliwości sprzętowych. Pod gołym niebem tryb jest tylko liczbą całkowitą. przekazano do 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ą trybu niestandardowego. Aby uniknąć konfliktów, te tryby muszą zaczynać się od wartości całkowitej 0x8000 z dodanymi do publicznego interfejsu API w przyszłości.

Aby zapewnić obsługę tej funkcji, producenci OEM muszą jedynie dodać nowy tryb do HAL. wyzwalane przez tę liczbę całkowitą przekazaną do HAL w module setup_streams, a następnie do swoich potrzeb używa interfejsu API systemu.

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

onCaptureQueueEmpty

Ten interfejs API zmniejsza czas oczekiwania na zmiany ustawień, takie jak powiększenie, o i pozostawianie możliwie pustej kolejki żądań. onCaptureQueueEmpty nie wymaga pracy HAL; Był to jedynie dodatek po stronie platformy. Aplikacje, które chcesz z niego korzystać, musisz dodać do tego wywołania detektora i zareagować w odpowiedni sposób. Zwykle polega to na wysłaniu do kamery kolejnego żądania zapisu urządzenia.

Interfejs HIDL kamery

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

3.4

Drobne dodatki do obsługiwanych metadanych i zmiany dotyczące obsługi data_space:

  • Dodaj statyczne metadane (ANDROID_SENSOR_OPAQUE_RAW_SIZE) jako obowiązkowe jeśli obsługiwany jest format RAW_OPAQUE.
  • Dodaj element statyczny ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE metadanych jako obowiązkowych, jeśli obsługiwany jest dowolny format RAW.
  • Przełącz pole camera3_stream_t data_space na bardziej elastyczne z definicją kodowania przestrzeni danych w wersji 0.
  • Ogólne dodane metadane, których można używać w przypadku HAL w wersji 3.2 lub nowszej:
    • ANDROID_INFO_SUPPORTED_HARDWARE_LEVEL_3
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST
    • ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE
    • ANDROID_SENSOR_DYNAMIC_BLACK_LEVEL
    • ANDROID_SENSOR_DYNAMIC_WHITE_LEVEL
    • ANDROID_SENSOR_OPAQUE_RAW_SIZE
    • ANDROID_SENSOR_OPTICAL_BLACK_REGIONS

3.3

Drobna zmiana w HAL z możliwością rozwijania:

  • Ponowne przetwarzanie aktualizacji interfejsu API w OPAQUE i YUV.
  • Podstawowa obsługa buforów danych wyjściowych związanych z głębokością.
  • Dodanie pola data_space do camera3_stream_t
  • Dodanie pola rotacji do tabeli camera3_stream_t.
  • Dodanie do trybu konfiguracji strumienia Camera3 camera3_stream_configuration_t

3.2

Drobna zmiana w HAL z możliwością rozwijania:

  • Wycofuje get_metadata_vendor_tag_ops. Używaj get_vendor_tag_ops w usłudze camera_common.h.
  • Wycofuje register_stream_buffers. Wszystkie bufory gralloc udostępniane w ramach platformy HAL w process_capture_request mogą być nowe w dowolnym momencie.
  • Dodaj obsługę częściowych wyników. process_capture_result może być jest wywoływane wielokrotnie z podzbiorem dostępnych wyników przed pełną wynik jest dostępny.
  • Dodaj szablon ręczny do grupy reklam camera3_request_template. aplikacji; może używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania.
  • Zmień specyfikacje strumienia dwukierunkowego i wejściowego.
  • Zmień ścieżkę zwrotną bufora wejściowego. Bufor jest zwracany w process_capture_result zamiast process_capture_request

3.1

Drobna zmiana w HAL z możliwością rozwijania:

  • configure_streams przekazuje do HAL flagi wykorzystania przez konsumentów.
  • usuń wywołanie, aby jak najszybciej usunąć wszystkie przesyłane żądania/bufory.

3,0

Pierwsza wersja HAL z możliwością rozwijania:

  • Duża zmiana wersji ze względu na zupełnie inny interfejs ABI. Bez zmian w wymaganych możliwości sprzętowych lub modelu operacyjnego w wersji 2.0.
  • Zmienione interfejsy żądań danych wejściowych i kolejki strumienia: wywołania platformy do interfejsu HAL z buforami następnego żądania i strumienia, które są już usunięte z kolejki. Obsługa synchronizacji jest niezbędna do efektywnego wdrażania.
  • Przeniesiono reguły do żądań, a większość powiadomień do wyników.
  • Skonsolidowano wszystkie wywołania zwrotne w ramach jednej struktury, a wszystkie ustawienia w jedno wywołanie initialize().
  • Zrealizowano konfigurację strumienia w jednym wywołaniu, aby uprościć zarządzanie. Strumienie dwukierunkowe zastępują STREAM_FROM_STREAM tworzyć.
  • Semantyka trybu ograniczonego dostępu w przypadku starszych/ograniczonych urządzeń.

2,0

Pierwsza wersja HAL z rozszerzonymi możliwościami (Android 4.2) [camera2.h]:

  • Wystarczający do implementacji istniejącej android.hardware.Camera API.
  • Zezwala na kolejkę ZSL w warstwie usługi kamery.
  • nie przetestowano pod kątem nowych funkcji, takich jak ręczna kontrola nagrywania czy Bayer RAW; przetwarzania i przetwarzania danych RAW itp.

1,0

Początkowa wartość HAL aparatu z Androidem (Android 4.0) [camera.h]:

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

Historia wersji modułu aparatu

Ta sekcja zawiera informacje o wersji modułów na potrzeby sprzętu Aparat moduł na podstawie camera_module_t.common.module_api_version. Obie większość znaczących cyfr szesnastkowych reprezentuje wersję durową, a dwie najmniejsze wersji podrzędnej.

2.4

W tej wersji modułu aparatu wprowadziliśmy te zmiany w interfejsie API:

  1. Obsługa trybu latarki. Platforma może włączyć tryb latarki dla każdego aparatu z lampą błyskową, bez otwierania aparatu. aparat ma wyższy priorytet dostępu do lampy błyskowej niż aparat moduł; otwarcie aparatu powoduje wyłączenie latarki, jeśli była włączona w interfejsie modułu. Gdy występują konflikty zasobów, takie jak Funkcja open() jest wywoływana, aby otworzyć aparat – moduł HAL aparatu musi powiadomić platformę za pomocą wywołania zwrotnego stanu trybu pochodnego, że pochodna Tryb został wyłączony.
  2. Obsługa kamer zewnętrznych (np. z kamerą USB z wtyczką „gorącą”). Aktualizacje interfejsu API określają, że statyczne informacje o kamerze są dostępne tylko wtedy, gdy jest ona włączona podłączony i gotowy do użycia z zewnętrznymi kamerami podłączonymi do zasilania. Połączenia statyczne informacje to nieprawidłowe połączenia, gdy stan kamery nie jest wartością CAMERA_DEVICE_STATUS_PRESENT Platforma uwzględnia wyłącznie zmiana stanu urządzenia w celu zarządzania listą dostępnych aparatów zewnętrznych.
  3. Wskazówki dotyczące arbitrażu w przypadku aparatu. Dodano obsługę jawnego wskazywania liczbę aparatów, które można jednocześnie otwierać i używać. Do określać prawidłowe kombinacje urządzeń, resource_cost oraz Pola conflicting_devices należy zawsze ustawiać w camera_info struktura zwrócona przez get_camera_info .
  4. Metoda inicjowania modułu. Wywołane przez usługę kamery po załadowaniu modułu HAL, aby umożliwić jednorazowe zainicjowanie HAL. Jest ona wywoływana przed wywołaniem innych metod modułu.

2.3

Ta wersja modułu aparatu dodaje obsługę starszych urządzeń HAL do otwartych urządzeń. Platforma może jej użyć do otwierania aparatu jako wersji HAL urządzenia niższego poziomu urządzenie HAL, jeśli to samo urządzenie może obsługiwać wiele wersji interfejsu API urządzeń. Rozmowa otwarta modułu standardowego sprzętu (common.methods->open) – kontynuacja aby uruchomić aparat w najnowszej obsługiwanej wersji, także wersję wymienioną w camera_info_t.device_version.

2.2

Ta wersja modułu aparatu dodaje obsługę tagów dostawcy z modułu. wycofuje stare vendor_tag_query_ops, które wcześniej były dostępne tylko dostępne na urządzeniu.

2.1

Ta wersja modułu aparatu obsługuje asynchroniczne wywołania zwrotne z modułu HAL aparatu, która służy do powiadamiania na temat zmian stanu modułu kamery. Moduły, które dostarczają prawidłowe wartości Metoda set_callbacks() musi raportować co najmniej ten numer wersji.

2,0

Moduły aparatu, które zgłaszają ten numer wersji, implementują drugą wersję interfejsu HAL modułu aparatu. Aparaty otwierane w tym miejscu moduł może obsługiwać wersję 1.0 lub 2.0 aparatu aparatu Interfejs HAL. Pole device_version w polu Camera_info ma zawsze wartość prawidłowy; pole static_camera_characteristics w Wartość camera_info jest prawidłowa, jeśli pole device_version ma wartość Wersja 2.0 lub nowsza.

1,0

Moduły aparatu, które zgłaszają te numery wersji, implementują element początkowy interfejsu HAL modułu aparatu. Wszystkie kamery, które można otworzyć za pomocą tego urządzenia obsługuje tylko wersję 1 HAL urządzenia z aparatem. device_version i static_camera_characteristics pola camera_info są nieprawidłowe. Tylko Interfejs android.hardware.Camera API może być obsługiwany przez ten moduł urządzenia.