Obsługa wersji aparatu

Na tej stronie znajdziesz informacje o różnicach między wersjami w przypadku kodów HAL i interfejsów API aparatu oraz powiązanych z nimi testów Compatibility Test Suite (CTS). Omawiamy również kilka zmian w architekturze, które mają wzmocnić i zabezpieczyć ramę kamery w Androidzie 7.0, przejście na Treble w Androidzie 8.0 oraz zmiany, jakie dostawcy aktualizacji muszą wprowadzić w swoich implementacjach aparatów.

Terminologia

Na tej stronie używamy tych terminów:

interfejs Camera API1,
Usługa aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 lub starszym, udostępniana przez klasę android.hardware.Camera.
Camera API2
Framework aparatu na poziomie aplikacji na urządzeniach z Androidem 5.0 lub nowszym, udostępniony za pomocą pakietu android.hardware.camera2.
Interfejs HAL aparatu
Warstwa modułu kamery zaimplementowana przez dostawców układów SOC. Publiczne struktury na poziomie aplikacji są oparte na HAL aparatu.
Aparat HAL3.1
Wersja interfejsu HAL aparatu wydana w ramach Androida 4.4.
Aparat HAL3.2
Wersja interfejsu HAL urządzenia do obsługi aparatu wydana w ramach Androida 5.0.
Camera API1 CTS
Zestaw testów CTS aparatu, które są wykonywane na podstawie interfejsu Camera API 1.
Camera API2 CTS
Dodatkowy zestaw testów CTS kamery uruchamianych razem z interfejsem Camera API2.
Sopran
Oddziela implementację dostawcy (oprogramowanie na niższym poziomie, specyficzne dla urządzenia, napisane przez producentów układów scalonych) od platformy Androida za pomocą nowego interfejsu dostawcy.
HIDL
Język definicji interfejsu HAL wprowadzony w Treble, służący do określania interfejsu między HAL a użytkownikami.
VTS
Pakiet testów dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android obejmuje poniższe interfejsy API aparatu.

interfejs Camera API1,

W Androidzie 5.0 wycofany został interfejs Camera API 1, który jest stopniowo wycofywany, ponieważ rozwój nowej platformy koncentruje się na interfejsie Camera API 2. Ten okres wycofywania się jednak wydłuży, a wersje Androida będą jeszcze przez jakiś czas obsługiwać aplikacje z interfejsu Camera API1. W szczególności dotyczy to:

  • Interfejsy Camera API 1 dla aplikacji. Aplikacje aparatu oparte na interfejsie Camera API1 powinny działać tak samo jak na urządzeniach z Androidem w starszych wersjach.
  • Wersje interfejsu HAL aparatu. Obejmuje obsługę HAL1.0 aparatu.

Camera API2

Interfejs Camera API 2 udostępnia aplikacji niższy poziom kontroli nad aparatem, w tym wydajne przepływy burst/streaming bez kopiowania i sterowanie pojedynczymi klatkami w zakresie ekspozycji, wzmocnienia, balansu bieli, konwersji kolorów, redukcji szumów, wyostrzania itp. Szczegółowe informacje znajdziesz w  filmie z konferencji Google I/O.

Android 5.0 i nowsze wersje zawierają interfejs Camera API 2, ale urządzenia z Androidem 5.0 lub nowszym mogą nie obsługiwać wszystkich funkcji tego interfejsu. Właściwość android.info.supportedHardwareLevel, której aplikacje mogą używać do wysyłania zapytań za pomocą interfejsów Camera API 2, może raportować jeden z tych poziomów obsługi:

  • LEGACY: te urządzenia udostępniają aplikacjom funkcje za pomocą interfejsów Camera API 2, które są mniej więcej takie same jak te udostępniane aplikacjom za pomocą interfejsów Camera API 1. Starsze wersje kodu koncepcyjnie przekładają wywołania interfejsu Camera API2 na wywołania interfejsu Camera API1. Starsze urządzenia nie obsługują funkcji interfejsu Camera API2, takich jak ustawienia poszczególnych klatek.
  • LIMITED: te urządzenia obsługują niektóre (ale nie wszystkie) funkcje interfejsu Camera API2 i muszą korzystać z interfejsu HAL aparatu w wersji 3.2 lub nowszej.
  • FULL: te urządzenia obsługują wszystkie główne funkcje interfejsu Camera API2 i muszą korzystać z interfejsu Camera HAL w wersji 3.2 lub nowszej oraz Androida w wersji 5.0 lub nowszej.
  • LEVEL_3: te urządzenia obsługują ponowne przetwarzanie YUV i przechwytywanie obrazu RAW, a także dodatkowe konfiguracje strumienia wyjściowego.
  • EXTERNAL: te urządzenia są podobne do urządzeń LIMITED, ale z niektórymi wyjątkami. Na przykład niektóre informacje o czujniku lub obiektywie mogą nie być raportowane lub mieć mniej stabilną liczbę klatek na sekundę. Ten poziom jest używany w przypadku zewnętrznych kamer, takich jak kamery internetowe USB.

Poszczególne funkcje są udostępniane za pomocą właściwości android.request.availableCapabilities w interfejsach API2 kamery. Urządzenia FULL wymagają m.in. funkcji MANUAL_SENSOR i MANUAL_POST_PROCESSING. Możliwość RAW jest opcjonalna nawet w przypadku urządzeń FULL. Urządzenia LIMITED mogą wyświetlać reklamy dotyczące dowolnego podzbioru tych funkcji, a także żadnego z nich. Zawsze jednak musisz zdefiniować uprawnienie BACKWARD_COMPATIBLE.

Obsługiwane poziomy sprzętowe urządzenia oraz konkretne funkcje interfejsu Camera API2, które obsługuje, są dostępne jako poniższe flagi funkcji umożliwiające filtrowanie aplikacji aparatu za pomocą interfejsu Camera API2 przez Google Play.

  • 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ą przejść testy aparatu w ramach interfejsu Camera API 1, interfejsu Camera API 2 i weryfikatora CTS.

Urządzenia, które nie obsługują komponentu HAL aparatu 3.2 i nie obsługują wszystkich interfejsów Camera API 2, muszą przejść testy CTS Camera API 2. Urządzenie działa jednak w trybie Camera API2LEGACY (w którym wywołania interfejsu Camera API2 są mapowane na wywołania interfejsu Camera API1), więc wszystkie testy CTS interfejsu Camera API2 związane z funkcjami lub możliwościami wykraczającymi poza interfejs Camera API1 są automatycznie pomijane.

Na starszych urządzeniach przeprowadzane testy CTS interfejsu Camera API2 CTS wykorzystują istniejące publiczne interfejsy i możliwości interfejsu Camera API1 bez żadnych nowych wymagań. Wykryte błędy (które powodują niepowodzenie interfejsu Camera API 2 w CTS) to błędy występujące już w obecnej warstwie abstrakcyjnej aparatu na urządzeniu, które mogą zostać znalezione przez istniejące aplikacje korzystające z interfejsu Camera API 1. Nie spodziewamy się wielu takich błędów (ale trzeba je naprawić, aby przejść testy CTS interfejsu Camera2 API2).

Wymagania dotyczące VTS

Urządzenia z Androidem 8.0 lub nowszym z implementacjami HAL w ramach bindera muszą przejść testy VTS dotyczące aparatu.

Zabezpieczanie mechanizmu kamery

Aby zwiększyć bezpieczeństwo frameworku multimediów i aparatów, Android 7.0 przenosi usługę aparatu z mediaservera. Począwszy od Androida 8.0 każdy zbinderyzowany interfejs aparatu (HAL) działa w procesie oddzielnym od usługi aparatu. W zależności od używanej wersji interfejsu API i interfejsu HAL dostawcy mogą być zmuszeni do wprowadzenia zmian w interfejsie HAL aparatu. W następnych sekcjach opisano zmiany w architekturze AP1 i AP2 w przypadku HAL1 i HAL3 oraz wymagania ogólne.

Zmiany architektoniczne dla interfejsu API1

Nagrywanie wideo za pomocą interfejsu API 1 może zakładać, że kamera i koder wideo działają w ramach tego samego procesu. Podczas korzystania z interfejsu API 1:

  • HAL3, w którym usługa aparatu używa kolejki buforowej do przekazywania buforów między procesami, nie wymaga aktualizacji od dostawcy.

    Aparat i multimedia w Androidzie 7.0 w interfejsie API 1 na HAL3

    Rysunek 1. Android 7.0 aparat i warstwy multimedialne w interfejsie API 1 na HAL3

  • HAL1, który obsługuje przekazywanie metadanych w buforze wideo. Producenci muszą zaktualizować HAL, aby używać kMetadataBufferTypeNativeHandleSource. Funkcja kMetadataBufferTypeCameraSource nie jest już obsługiwana w Androidzie 7.0.

    Android 7.0 aparat i warstwy multimedialne w interfejsie API 1 na HAL1

    Rysunek 2. Aparat i stos multimediów na Androidzie 7.0 w interfejsie API1 w HAL1

Zmiany w architekturze interfejsu API2

W przypadku interfejsu API2 na HAL1 lub HAL3 kolejka buforów przekazuje bufory, aby te ścieżki nadal działały. Architektura Androida 7.0 dla interfejsu API 2 na:

  • Przeniesienie usługi cameraservice nie ma wpływu na HAL1 i nie wymaga aktualizacji ze strony dostawcy.
  • HAL3 jest objęty tą zmianą, ale nie trzeba aktualizować oprogramowania dostawcy:

    Aparat i multimedia w Androidzie 7.0 w interfejsie API 2 na HAL 3

    Rysunek 3. Android 7.0: aparat i warstwy multimedialne w interfejsie API 2 na HAL3

Dodatkowe wymagania

Zmiany architektoniczne wprowadzone w ramach wzmacniania zabezpieczeń mediów i ramy kamery obejmują te dodatkowe wymagania dotyczące urządzeń.

  • Ogólne. Urządzenia wymagają dodatkowej przepustowości ze względu na standard IPC, co może wpływać na przypadki użycia kamer, takich jak nagrywanie z dużą prędkością. Dostawcy mogą mierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Aparat Google do nagrywania filmów z dużą szybkością 120/240 FPS. Urządzenia wymagają też niewielkiej ilości dodatkowej pamięci RAM na potrzeby tworzenia nowego procesu.
  • Przekazywanie metadanych w buforze wideo (tylko w HAL1). Jeśli HAL1 zapisują metadane zamiast rzeczywistych danych ramki YUV w buforach wideo, musi użyć kMetadataBufferTypeNativeHandleSource jako typu bufora metadanych i przekazać VideoNativeHandleMetadata w buforach wideo. Usługa kMetadataBufferTypeCameraSource nie jest już obsługiwana na Androidzie 7.0. Dzięki VideoNativeHandleMetadata aparaty i ramy pracy multimediów mogą przekazywać bufory wideo między procesami, odpowiednio serializując i deserializując natywne uchwyty.
  • Adres uchwytu bufora nie zawsze przechowuje ten sam bufor (tylko HAL3). W przypadku każdego żądania przechwytywania HAL3 otrzymuje adresy uchwytów bufora. HAL nie może używać adresów do identyfikowania buforów, ponieważ adresy mogą przechowywać inny uchwyt bufora po zwróceniu bufora przez HAL. Musisz zaktualizować HAL, aby używać uchwytów buforów do identyfikowania buforów. Na przykład HAL otrzymuje adres uchwytu bufora A, który zawiera uchwyt A. Gdy HAL zwróci uchwyt bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B następnym razem, gdy HAL go otrzyma.
  • Zaktualizuj zasady SELinux dla usługi cameraserver Jeśli zasady SELinux dotyczące konkretnego urządzenia przyznają serwerowi multimediów uprawnienia do uruchamiania kamery, musisz zaktualizować zasady SELinux, aby przyznać serwerowi kamery odpowiednie uprawnienia. Nie zalecamy powielania zasad SELinux serwera mediaserver w przypadku serwera cameraserver (ponieważ serwer mediaserver i serwer cameraserver wymagają zazwyczaj różnych zasobów w systemie). Usługa cameraserver powinna mieć tylko uprawnienia potrzebne do wykonywania funkcji aparatu. Niepotrzebne uprawnienia dotyczące aparatu w mediaserver powinny zostać usunięte.
  • Oddzielenie interfejsu HAL aparatu od serwera aparatu. W Androidzie 8.0 i nowszych dodatkowo oddziela się binderized Camera HAL w procesie innym niż cameraserver. Komunikacja IPC odbywa się za pomocą interfejsów zdefiniowanych w specyfikacji HIDL.

Weryfikacja

W przypadku wszystkich urządzeń z kamerą i Androidem 7.0 sprawdź implementację, uruchamiając test CTS dla Androida 7.0. Chociaż Android 7.0 nie zawiera nowych testów CTS, które sprawdzają zmiany w usłudze aparatu, istniejące testy CTS nie przechodzą, jeśli nie wprowadzisz wspomnianych wyżej aktualizacji.

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

Historia wersji HAL aparatu

Listę testów do oceny interfejsu HAL aparatu Androida znajdziesz na liście kontrolnej testów interfejsu Camera HAL.

Android 10

Android 10 wprowadza te zmiany.

Camera API

Interfejs HAL aparatu

W Androidzie 10 zostały zaktualizowane te wersje interfejsu Camera HAL:

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: metoda, która informuje framework kamery, czy wymagana jest pełna rekonfiguracja strumienia w przypadku nowych wartości parametrów sesji. Pozwala to uniknąć niepotrzebnych opóźnień w ponownej konfiguracji kamery. Zobacz zapytanie dotyczące rekonfiguracji sesji.
  • Interfejsy API zarządzania buforami HAL: te interfejsy API umożliwiają żądanie przez aparat HAL buforów z ramy aparatu tylko wtedy, gdy jest to wymagane, zamiast łączyć każde żądanie przechwytywania z odpowiednimi buforami w całym procesie aparatu, co może przynieść znaczne oszczędności pamięci.
    • signalStreamFlush: sygnalizuje HAL, że usługa kamery ma wykonać configureStreams_3_5 i że HAL musi zwracać wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5: podobnie jak w przypadku funkcji ICameraDevice3.4.configureStreams, ale dodatkowo funkcja streamConfigCounter zawiera licznik streamConfigCounter, który służy do sprawdzania warunków wyścigu między wywołaniami funkcji configureStreams_3_5 i signalStreamFlush.

Zmiany w ICameraDeviceCallback:

  • requestStreamBuffers: wywołanie zwrotne synchroniczne wywoływane przez HAL aparatu w celu zapytania serwera aparatu o bufory. Zobacz requestStreamBuffers.
  • returnStreamBuffers: wywołanie zwrotne synchroniczne dla HAL aparatu, które zwraca bufory wyjściowe do serwera aparatu. Zobacz returnStreamBuffers.

3.4

W Androidzie 10 do metadanych aparatu są dodawane te 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 klucza ANDROID_SENSOR_INFO_COLOR_FILTER_ARRANGEMENT
    • 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 strumienia HEIC
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_OUTPUT
    • ANDROID_HEIC_AVAILABLE_HEIC_STREAM_CONFIGURATIONS_INPUT

Moduł aparatu

W Androidzie 10 zaktualizowano te wersje modułów aparatu:

2,5

  • Dodaje metodę notifyDeviceStateChange, która umożliwia urządzeniom powiadamianie interfejsu HAL aparatu, gdy zmiany fizyczne, takie jak złożenie, wpływają na działanie aparatu i przekierowywanie.

2.4

  • Urządzenia z interfejsem API na poziomie 29 lub wyższym MUSZĄ raportować true dla isTorchModeSupported.

Android 9

W Androidzie 9 wprowadziliśmy poniższe aktualizacje interfejsu API2 i HAL aparatu.

Camera API

  • Wprowadza interfejs API obsługi wielu aparatów, aby lepiej obsługiwać urządzenia z wieloma aparatami skierowanymi w tym samym kierunku, co umożliwia działanie takich funkcji jak bokeh czy płynne powiększanie. Dzięki temu aplikacje mogą wyświetlać kilka kamer na urządzeniu jako jedną jednostkę logiczną (kamerę logiczną). Prośby o przechwycenie można też wysyłać do poszczególnych urządzeń kamery, które są objęte jedną kamerą logiczną. Zapoznaj się z artykułem Obsługa wielu aparatów.
  • Zawiera parametry sesji. Parametry sesji to podzbiór dostępnych parametrów rejestrowania, które po zmodyfikowaniu mogą spowodować poważne opóźnienia w przetwarzaniu. Te koszty można ograniczyć, jeśli klienci przekazują wartości początkowe podczas inicjowania sesji rejestrowania. Zobacz Parametry sesji.
  • Dodaje klucze danych stabilizacji optycznej (OIS) na potrzeby stabilizacji i efektów na poziomie aplikacji. Zobacz STATISTICS_OIS_SAMPLES.
  • Dodaje obsługę zewnętrznego flesza. Zobacz: CONTROL_AE_MODE_ON_EXTERNAL_FLASH.
  • Dodaje zamiar śledzenia ruchu w CAPTURE_INTENT. Zobacz CONTROL_CAPTURE_INTENT_MOTION_TRACKING.
  • Wycofuje funkcję LENS_RADIAL_DISTORTION i zastępuje w niej obiekt LENS_DISTORTION.
  • Dodaje tryby korekcji zniekształceń w CaptureRequest. Zobacz DISTORTION_CORRECTION_MODE.
  • Dodano obsługę zewnętrznych aparatów USB/UVC na obsługiwanych urządzeniach. Zobacz INFO_SUPPORTED_HARDWARE_LEVEL_EXTERNAL.

Interfejs HAL aparatu

3.4

Zmiany w ICameraDeviceSession

Aktualizacje do: ICameraDeviceCallback

3.3

W Androidzie 9 do metadanych aparatu są dodawane te klucze:

  • 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 wersji 8.0 Androida wprowadzono interfejs Treble. W przypadku Treble implementacje interfejsu Camera HAL muszą być związane. Android 8.0 zawiera też te kluczowe ulepszenia usługi Aparat:

  • Współdzielone platformy: włącz wiele platform korzystających z tego samego konta OutputConfiguration
  • Systemowy interfejs API do niestandardowych trybów aparatu
  • onCaptureQueueEmpty

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

Powierzchnie wspólne

Ta funkcja umożliwia wykorzystanie 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 móc korzystać z tej funkcji, producenci urządzeń muszą zadbać o to, aby ich implementacje HAL i gralloc umożliwiały tworzenie buforów gralloc u różnych użytkowników (takich jak kompozytor sprzętowy/GPU i koder wideo), a nie tylko dla jednego klienta. Usługa kamery przekazuje flagi wykorzystania przez użytkowników do HAL kamery i gralloc HAL. Muszą albo przydzielić odpowiednie rodzaje buforów, albo HAL musi zwracać błąd informujący o tym, że ta kombinacja konsumentów nie jest obsługiwana.

Więcej informacji znajdziesz w  enableSurfaceSharingdokumentacji dla programistów.

Systemowy interfejs API do niestandardowych trybów aparatu

Interfejs Public Camera API określa 2 tryby działania: normalne i ograniczone nagrywanie z dużą prędkością. Mają one dość odmienną semantykę. Na przykład tryb szybkiego przesyłania danych jest ograniczony do maksymalnie 2 specyficznych wyjść naraz. Różne firmy OEM wyraziły zainteresowanie definiowaniem innych niestandardowych trybów dla funkcji sprzętowych. Tryb to po prostu liczba całkowita przekazana do configure_streams. Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams.

Ta funkcja obejmuje wywołanie interfejsu API systemu, którego aplikacje do obsługi aparatu mogą używać do włączenia trybu niestandardowego. Te tryby muszą zaczynać się od wartości całkowitej 0x8000, aby uniknąć konfliktów z przyszłościowymi trybami dodanymi do publicznego interfejsu API.

Aby obsługiwać tę funkcję, producenci OEM muszą tylko dodać nowy tryb do swojego interfejsu HAL, który jest uruchamiany przez tę liczbę całkowitą przekazaną do interfejsu HAL w ramach konfiguracji strumieni, a następnie dopilnować, aby ich niestandardowa aplikacja do obsługi aparatu używała interfejsu API systemu.

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 ustawień, takich jak przybliżanie i oddalanie, przez utrzymywanie kolejki żądań w stanie jak najbardziej pustym. onCaptureQueueEmptynie wymaga pracy nad HAL; było to tylko rozszerzenie frameworku. Aplikacje, które chcą z niego korzystać, muszą dodać do niego słuchacza i odpowiednio na niego zareagować. Zazwyczaj polega to na wysłaniu kolejnego żądania przechwycenia do urządzenia z kamerą.

Interfejs HIDL aparatu

Interfejs Camera HIDL to całkowicie przebudowany interfejs Camera HAL, który korzysta ze stabilnych interfejsów API zdefiniowanych w HIDL. Wszystkie funkcje i możliwości aparatu wprowadzone w najnowszych starszych wersjach 3.4 i 2.4 (dla modułu aparatu) również są częścią definicji HIDL.

3.4

Niewielkie dodatki do obsługiwanych metadanych i zmiany w obsłudze danych_przestrzeni:

  • Dodaj statyczne metadane ANDROID_SENSOR_OPAQUE_RAW_SIZE jako obowiązkowe, jeśli obsługiwany jest format RAW_OPAQUE.
  • Jeśli obsługiwany jest dowolny format RAW, musisz dodać metadane statyczne ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGE.
  • Przełącz pole camera3_stream_t data_space na bardziej elastyczną definicję, korzystając z definicji kodowania przestrzeni danych w wersji 0.
  • Dodatki metadanych ogólnych, które można używać w HALv3.2 lub nowszej wersji:
    • 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

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • Aktualizacje interfejsu API dotyczące przetwarzania OPAQUE i YUV.
  • Podstawowa obsługa buforów danych wyjściowych głębi.
  • Dodano pole data_space do tabeli camera3_stream_t.
  • Dodanie pola rotacji do tabeli camera3_stream_t.
  • Dodano tryb konfiguracji strumienia camera3 do camera3_stream_configuration_t.

3.2

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • Wycofane: get_metadata_vendor_tag_ops. Zamiast tego użyj w kolumnie camera_common.h wartości get_vendor_tag_ops.
  • Wycofuje register_stream_buffers. Wszystkie bufory gralloc udostępniane przez framework do HAL w process_capture_request mogą być nowe w dowolnym momencie.
  • Dodaj obsługę częściowych wyników. process_capture_result może być wywoływany wielokrotnie z podzbiorem dostępnych wyników, zanim będzie dostępny pełny wynik.
  • Dodaj szablon ręczny do camera3_request_template. Aplikacje mogą używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania.
  • Zmienić specyfikacje strumieni dwukierunkowych i wejściowych.
  • Zmień ścieżkę powrotu bufora wejściowego. Bufor jest zwracany w formie process_capture_result zamiast process_capture_request.

3.1

Niewielka modyfikacja interfejsu HAL o rozszerzonych możliwościach:

  • configure_streams przekazuje flagi użytkowania przez konsumenta do HAL.
  • usuń wywołanie, aby jak najszybciej usunąć wszystkie przesyłane żądania/bufory.

3,0

Pierwsza wersja HAL z rozszerzonymi możliwościami:

  • Główna zmiana wersji, ponieważ ABI jest zupełnie inny. Nie ma zmian w wymaganych możliwościach sprzętowych ani modelu operacyjnym w wersji 2.0.
  • Przerobione interfejsy kolejek żądań wejściowych i strumieni: wywołania frameworku w HAL z kolejną prośbą o dane i buforami strumieni już wyjętymi z kolejki. Dodano obsługę ramki synchronizacji, która jest niezbędna do wydajnej implementacji.
  • Przeniesienie żądań do żądań, a większości powiadomień do wyników.
  • Połączono wszystkie wywołania zwrotne w ramach frameworku w jedną strukturę, a wszystkie metody konfiguracji w jednym wywołaniu initialize().
  • Aby uprościć zarządzanie strumieniami, wprowadziliśmy konfigurację strumienia w ramach pojedynczego wywołania. Strumienie dwukierunkowe zastępują konstrukcję STREAM_FROM_STREAM.
  • Semantyka trybu ograniczonego dostępu dla starszych lub ograniczonych urządzeń.

2,0

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

  • Wystarczający do implementacji istniejącego interfejsu API android.hardware.Camera.
  • Umożliwia kolejkę ZSL na poziomie usługi aparatu.
  • Nie testowano nowych funkcji, takich jak ręczna kontrola rejestrowania, rejestrowanie w formacie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1,0

Początkowy interfejs HAL aparatu Androida (Android 4.0) [camera.h]:

  • Przekształcony z poziomu abstrakcji CameraHardwareInterface w C++.
  • Obsługuje interfejs android.hardware.Camera API.

Historia wersji modułu aparatu

Ta sekcja zawiera informacje o wersjach modułu aparatu na podstawie camera_module_t.common.module_api_version. Dwie najbardziej istotne cyfry szesnastkowe oznaczają wersję główną, a dwie najmniej istotne – wersję podrzędną.

2.4

Ta wersja modułu aparatu wprowadza te zmiany w interfejsie API:

  1. Obsługa trybu latarki. Framework może włączyć tryb latarki na dowolnym urządzeniu z kamerą, które ma lampę błyskową, bez otwierania urządzenia. Aparat ma wyższy priorytet dostępu do lampy błyskowej niż moduł aparatu. Otwarcie aparatu powoduje wyłączenie latarki, jeśli została włączona przez interfejs modułu. W przypadku konfliktów zasobów, takich jak wywołanie open() w celu otwarcia urządzenia z kamerą, moduł HAL kamery musi poinformować framework za pomocą wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony.
  2. Obsługa kamer zewnętrznych (np. kamer USB z podłączeniem „gorącego wtyczka”). W aktualizacjach interfejsu API określono, że statyczne informacje o kamerze są dostępne tylko wtedy, gdy kamera jest podłączona i gotowa do użycia z zewnętrznymi kamerami podłączanymi do zasilania. Połączenia z prośbą o informacje statyczne są nieprawidłowe, jeśli stan kamery jest inny niż CAMERA_DEVICE_STATUS_PRESENT. Platforma zlicza wyłącznie wywołania zwrotne zmiany stanu urządzenia w celu zarządzania listą dostępnych aparatów zewnętrznych.
  3. Wskazówki dotyczące arbitrażu kamery Dodano obsługę wyraźnego wskazywania liczby urządzeń z kamerą, które można otwierać i używać jednocześnie. Aby określić prawidłowe kombinacje urządzeń, w strukturze camera_info zwracanej przez wywołanie get_camera_info należy zawsze ustawić pola resource_cost i conflicting_devices.
  4. Metoda inicjowania modułu. Jest wywoływany przez usługę aparatu po załadowaniu modułu HAL, aby umożliwić jednorazową jego inicjalizację. Jest on wywoływany przed wywołaniem innych metod modułu.

2.3

Ta wersja modułu aparatu dodaje obsługę starszych urządzeń z otwartym interfejsem HAL aparatu. Framework może użyć tego klucza, aby otworzyć urządzenie z kamerą jako urządzenie z niższą wersją interfejsu HAL, jeśli to samo urządzenie obsługuje wiele wersji interfejsu API urządzenia. Standardowy wywołanie wywołania modułu sprzętowego (common.methods->open) nadal otwiera urządzenie z kamerą w najnowszej obsługiwanej wersji, która jest też wersją wymienioną w camera_info_t.device_version.

2.2

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

2.1

Ta wersja modułu aparatu dodaje obsługę asynchronicznych wywołań zwrotnych do frameworku z modułu HAL aparatu, który służy do informowania frameworku o zmianach stanu modułu aparatu. Moduły, które udostępniają prawidłową metodę set_callbacks(), muszą podawać co najmniej tę wersję.

2,0

Moduł aparatu, który zwraca ten numer wersji, implementuje drugą wersję interfejsu HAL modułu aparatu. Urządzenia aparatów otwierane za pomocą tego modułu mogą obsługiwać interfejs HAL 1.0 lub 2.0 aparatu. Pole device_version w polu Camera_info jest zawsze poprawne. Pole static_camera_characteristics w polu camera_info jest prawidłowe, jeśli pole device_version ma wartość 2.0 lub większą.

1,0

Moduł aparatu, który zgłasza te numery wersji, implementuje początkowy interfejs HAL aparatu. Wszystkie urządzenia z kamerą, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 komponentu HAL urządzenia z kamerą. Pola device_version i static_camera_characteristics w rekordzie camera_info są nieprawidłowe. Ten moduł i połączone z nim urządzenia obsługują tylko interfejs API android.hardware.Camera.