Obsługiwane wersje aparatu

Na tej stronie znajdziesz szczegółowe informacje o różnicach między wersjami interfejsów HAL aparatu, interfejsów API i powiązanych testów pakietu CTS (Compatibility Test Suite). Opisuje też kilka zmian w architekturze, które zwiększają odporność i bezpieczeństwo struktury aparatu w Androidzie 7.0, przejście na Treble w Androidzie 8.0 oraz aktualizacje, które dostawcy muszą wprowadzić, aby obsługiwać te zmiany w swoich implementacjach aparatu.

Terminologia

Na tej stronie używamy tych terminów:

Camera API1
Framework aparatu na poziomie aplikacji na urządzeniach z Androidem 4.4 lub starszym, udostępniany przez klasę android.hardware.Camera.
Camera API2
Framework aparatu na poziomie aplikacji na urządzeniach z Androidem 5.0 lub nowszym, udostępniany przez pakiet android.hardware.camera2.
HAL aparatu
Warstwa modułu aparatu zaimplementowana przez dostawców układów SoC. Publiczne platformy na poziomie aplikacji są oparte na HAL aparatu.
Camera HAL3.1
Wersja HAL urządzenia z aparatem wydana z Androidem 4.4.
Camera HAL3.2
Wersja HAL urządzenia z aparatem wydana z Androidem 5.0.
Camera API1 CTS
Zestaw testów CTS kamery, które są przeprowadzane na podstawie interfejsu Camera API1.
Camera API2 CTS
Dodatkowy zestaw testów CTS kamery, które są przeprowadzane na podstawie interfejsu Camera API2.
Sopran
Oddziela implementację dostawcy (oprogramowanie specyficzne dla urządzenia, niższego poziomu, napisane przez producentów krzemu) od struktury systemu operacyjnego Android za pomocą nowego interfejsu dostawcy.
HIDL
Język definicji interfejsu HAL wprowadzony w ramach projektu Treble i używany do określania interfejsu między HAL a jego użytkownikami.
VTS
Zestaw testów dostawcy wprowadzony wraz z Treble.

Interfejsy API aparatu

Android zawiera te interfejsy API aparatu:

Camera API1

W Androidzie 5.0 wycofano interfejs Camera API1, który jest stopniowo wycofywany, ponieważ nowe platformy są opracowywane z myślą o interfejsie Camera API2. Okres wycofywania będzie jednak długi, a wersje Androida będą jeszcze przez jakiś czas obsługiwać aplikacje korzystające z interfejsu Camera API1. W szczególności nadal obsługujemy:

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

Camera API2

Interfejs Camera API2 udostępnia aplikacji sterowanie aparatem na niższym poziomie, w tym wydajne przepływy strumieniowe i seryjne bez kopiowania oraz sterowanie ekspozycją, wzmocnieniem, wzmocnieniem balansu bieli, konwersją kolorów, odszumianiem, wyostrzaniem i innymi parametrami w przypadku każdej klatki. Szczegółowe informacje znajdziesz w  filmie z konferencji Google I/O.

Android 5.0 i nowszy zawiera interfejs Camera API2, ale urządzenia z Androidem 5.0 i nowszym mogą nie obsługiwać wszystkich funkcji interfejsu Camera API2. Właściwość android.info.supportedHardwareLevel, o którą aplikacje mogą wysyłać zapytania za pomocą interfejsów Camera API2, raportuje jeden z tych poziomów obsługi:

  • LEGACY: urządzenia te udostępniają aplikacjom funkcje za pomocą interfejsów Camera API2, które są w przybliżeniu takie same jak funkcje udostępniane aplikacjom za pomocą interfejsów Camera API1. Starsze struktury koncepcyjnie tłumaczą wywołania interfejsu Camera API2 na wywołania interfejsu Camera API1. Starsze urządzenia nie obsługują funkcji interfejsu Camera API2, takich jak sterowanie poszczególnymi klatkami.
  • LIMITED: te urządzenia obsługują niektóre funkcje interfejsu Camera API2 (ale nie wszystkie) i muszą korzystać z interfejsu HAL kamery w wersji 3.2 lub nowszej.
  • FULL: te urządzenia obsługują wszystkie główne funkcje interfejsu Camera API2 i muszą korzystać z 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 obrazów RAW, a także dodatkowe konfiguracje strumienia wyjściowego.
  • EXTERNAL: urządzenia te są podobne do urządzeń LIMITED, z pewnymi wyjątkami. Na przykład niektóre informacje o czujniku lub obiektywie mogą nie być raportowane 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ą udostępniane za pomocą właściwości android.request.availableCapabilities w interfejsach Camera API2. Urządzenia FULL wymagają m.in. funkcji MANUAL_SENSOR i MANUAL_POST_PROCESSING. Funkcja 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 funkcja BACKWARD_COMPATIBLE musi być zawsze zdefiniowana.

Obsługiwany poziom sprzętu urządzenia oraz konkretne funkcje interfejsu Camera API2, które obsługuje, są dostępne jako te flagi funkcji, aby umożliwić filtrowanie w Google Play aplikacji aparatu korzystających 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 pakietu CTS

Urządzenia z Androidem 5.0 i nowszym muszą przejść testy CTS interfejsu Camera API1, CTS interfejsu Camera API2 i CTS Verifier.

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

Na starszych urządzeniach testy CTS interfejsu Camera API2 są przeprowadzane przy użyciu istniejących publicznych interfejsów i funkcji Camera API1 bez nowych wymagań. Błędy, które są widoczne (i powodują niepowodzenie testu CTS interfejsu Camera API2), to błędy już obecne w istniejącym HAL kamery urządzenia, a zatem byłyby wykrywane przez istniejące aplikacje korzystające z interfejsu Camera API1. Nie spodziewamy się wielu błędów tego typu (jednak wszystkie takie błędy muszą zostać naprawione, aby przejść testy CTS interfejsu Camera API2).

Wymagania dotyczące VTS

Urządzenia z Androidem 8.0 lub nowszym z implementacjami HAL opartymi na Binderze muszą przejść testy VTS aparatu.

Zwiększenie bezpieczeństwa struktury aparatu

Aby zwiększyć bezpieczeństwo platformy multimediów i aparatu, w Androidzie 7.0 usługa aparatu została przeniesiona poza serwer multimediów. Od Androida 8.0 każdy interfejs HAL aparatu powiązany z binderem działa w procesie oddzielnym od usługi aparatu. W zależności od używanych wersji interfejsu API i HAL dostawcy mogą musieć wprowadzić zmiany w HAL aparatu. W sekcjach poniżej opisujemy zmiany w architekturze AP1 i AP2 w przypadku HAL1 i HAL3, a także ogólne wymagania.

Zmiany w architekturze interfejsu API1

Nagrywanie wideo za pomocą interfejsu API1 może zakładać, że kamera i enkoder wideo działają w tym samym procesie. Podczas korzystania z interfejsu API1 na:

  • W przypadku HAL3, gdzie usługa aparatu używa BufferQueue do przekazywania buforów między procesami, nie jest wymagana aktualizacja dostawcy.

    Stos aparatu i multimediów w Androidzie 7.0 w API1 na HAL3

    Rysunek 1. Aparat i stos multimediów w Androidzie 7.0 w API1 na HAL3

  • HAL1, który obsługuje przekazywanie metadanych w buforach wideo, wymaga od dostawców zaktualizowania HAL-u, aby używał kMetadataBufferTypeNativeHandleSource. (kMetadataBufferTypeCameraSource nie jest już obsługiwane w Androidzie 7.0).

    Stos aparatu i multimediów w Androidzie 7.0 w interfejsie API1 na HAL1

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

Zmiany w architekturze interfejsu API2

W przypadku interfejsu API2 na HAL1 lub HAL3 BufferQueue przekazuje bufory, więc te ścieżki nadal działają. Architektura Androida 7.0 dla API2 na urządzeniach:

  • Przeniesienie usługi kamery nie ma wpływu na HAL1 i nie wymaga aktualizacji dostawcy.
  • HAL3 jest dotknięty problemem, ale nie wymaga aktualizacji:

    Stos aparatu i multimediów w Androidzie 7.0 w API2 na HAL3

    Rysunek 3. Aparat i stos multimediów w Androidzie 7.0 w API2 na HAL3

Dodatkowe wymagania

Zmiany w architekturze wprowadzone w celu zwiększenia bezpieczeństwa platformy multimediów i kamery obejmują te dodatkowe wymagania dotyczące urządzenia:

  • Postanowienia ogólne. Urządzenia wymagają dodatkowej przepustowości ze względu na komunikację międzyprocesową, co może mieć wpływ na zastosowania kamery wymagające szybkiego działania, takie jak nagrywanie filmów w wysokiej rozdzielczości. Dostawcy mogą zmierzyć rzeczywisty wpływ, uruchamiając android.hardware.camera2.cts.PerformanceTest i aplikację Aparat Google do nagrywania filmów w wysokiej rozdzielczości z prędkością 120/240 kl./s. Urządzenia wymagają też niewielkiej ilości dodatkowej pamięci RAM, aby utworzyć nowy proces.
  • Przekazywanie metadanych w buforach wideo (tylko HAL1). Jeśli HAL1 przechowuje metadane zamiast rzeczywistych danych klatek YUV w buforach wideo, musi używać kMetadataBufferTypeNativeHandleSource jako typu bufora metadanych i przekazywać VideoNativeHandleMetadata w buforach wideo. (kMetadataBufferTypeCameraSource nie jest już obsługiwane na Androidzie 7.0). Dzięki VideoNativeHandleMetadata struktury aparatu i multimediów mogą przekazywać bufory wideo między procesami, prawidłowo 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ż po zwróceniu bufora przez HAL adresy mogą przechowywać inny uchwyt bufora. Musisz zaktualizować HAL, aby do identyfikowania buforów używać uchwytów buforów. Na przykład HAL otrzymuje adres uchwytu bufora A, który przechowuje uchwyt bufora A. Gdy HAL zwróci uchwyt bufora A, adres uchwytu bufora A może przechowywać uchwyt bufora B przy następnym otrzymaniu go przez HAL.
  • Zaktualizuj zasady SELinux dla serwera aparatu. Jeśli zasady SELinux dotyczące urządzenia przyznają serwerowi multimediów uprawnienia do uruchamiania aparatu, musisz zaktualizować te zasady, aby przyznać serwerowi aparatu odpowiednie uprawnienia. Odradzamy powielanie zasad SELinux serwera multimediów na potrzeby serwera aparatu (ponieważ serwer multimediów i serwer aparatu zwykle wymagają różnych zasobów w systemie). Serwer aparatu powinien mieć tylko uprawnienia potrzebne do wykonywania funkcji aparatu, a wszelkie niepotrzebne uprawnienia związane z aparatem na serwerze multimediów powinny zostać usunięte.
  • Oddzielenie HAL aparatu od serwera aparatu. Android w wersji 8.0 i nowszych dodatkowo rozdziela interfejs HAL aparatu powiązany z binderem w procesie innym niż serwer aparatu. IPC odbywa się za pomocą interfejsów zdefiniowanych w HIDL.

Weryfikacja

W przypadku wszystkich urządzeń z aparatem i Androidem 7.0 sprawdź implementację, uruchamiając pakiet CTS dla Androida 7.0. Chociaż Android 7.0 nie zawiera nowych testów CTS, które weryfikują zmiany w usłudze aparatu, istniejące testy CTS nie powiodą się, jeśli nie wprowadzisz wskazanych powyżej aktualizacji.

W przypadku wszystkich urządzeń z aparatem i Androidem w wersji 8.0 lub nowszej sprawdź implementację dostawcy, uruchamiając VTS.

Historia wersji HAL aparatu

Listę testów dostępnych do oceny interfejsu HAL aparatu na Androidzie znajdziesz w tym dokumencie.

Android 10

Android 10 wprowadza te aktualizacje:

Camera API

HAL aparatu

W Androidzie 10 zaktualizowano te wersje HAL aparatu:

3.5

ICameraDevice

ICameraDeviceSession

  • isReconfigurationNeeded: metoda, która informuje platformę aparatu, czy pełna rekonfiguracja strumienia jest wymagana w przypadku możliwych nowych wartości parametrów sesji. Pozwoli to uniknąć niepotrzebnych opóźnień w ponownej konfiguracji kamery. Patrz sekcja Zapytanie o ponowną konfigurację sesji.
  • Interfejsy API zarządzania buforami HAL: te interfejsy API umożliwiają HAL aparatu przesyłanie żądań buforów do platformy aparatu tylko wtedy, gdy jest to konieczne, zamiast łączyć każde żądanie przechwytywania z powiązanymi z nim buforami w całym potoku aparatu, co może znacznie zmniejszyć zużycie pamięci.
    • signalStreamFlush: sygnalizuje HAL-owi, że usługa kamery ma wykonać configureStreams_3_5 i że HAL musi zwrócić wszystkie bufory wyznaczonych strumieni.
    • configureStreams_3_5: podobne do ICameraDevice3.4.configureStreams, ale dodatkowo udostępniany jest licznik streamConfigCounter, który umożliwia sprawdzenie, czy nie występuje wyścig między wywołaniami configureStreams_3_5 i signalStreamFlush.

Zmiany w ICameraDeviceCallback:

  • requestStreamBuffers: Synchroniczne wywołanie zwrotne, które HAL aparatu wywołuje, aby poprosić serwer aparatu o bufory. Zobacz requestStreamBuffers.
  • returnStreamBuffers: synchroniczne wywołanie zwrotne dla HAL aparatu, aby zwrócić bufory wyjściowe do serwera aparatu. Zobacz returnStreamBuffers.

3.4

Te klucze są dodawane do metadanych aparatu w Androidzie 10.

  • Formaty obrazów
    • 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 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łę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ł kamery

W Androidzie 10 zaktualizowano te wersje modułu aparatu:

2.5

  • Dodaje metodę notifyDeviceStateChange, która umożliwia urządzeniom powiadamianie interfejsu HAL aparatu o zmianach fizycznych, takich jak składanie, które mają wpływ na aparat i routing.

2.4

  • Urządzenia z interfejsem API na poziomie 29 lub wyższym MUSZĄ zgłaszać wartość true w przypadku isTorchModeSupported.

Android 9

W Androidzie 9 wprowadziliśmy te zmiany w interfejsie API2 aparatu i interfejsie HAL.

Camera API

  • Wprowadza interfejs API wielu aparatów, aby lepiej obsługiwać urządzenia z kilkoma aparatami skierowanymi w tym samym kierunku, co umożliwia korzystanie z funkcji takich jak bokeh i płynne powiększanie. Dzięki temu aplikacje mogą traktować wiele kamer na urządzeniu jako jedną jednostkę logiczną (kamerę logiczną). Żądania zapisu można też wysyłać do poszczególnych urządzeń z aparatem wchodzących w skład jednego aparatu logicznego. Zobacz obsługę wielu aparatów.
  • Wprowadza parametry sesji. Parametry sesji to podzbiór dostępnych parametrów przechwytywania, których modyfikacja może powodować poważne opóźnienia w przetwarzaniu. Można je ograniczyć, jeśli klienci przekażą wartości początkowe podczas inicjowania sesji przechwytywania. Zobacz Parametry sesji.
  • Dodaje klucze danych optycznej stabilizacji obrazu (OIS) na potrzeby 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 zamiar ś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.

HAL aparatu

3.4

Aktualizacje ICameraDeviceSession

Aktualizacje ICameraDeviceCallback

3.3

W Androidzie 9 do metadanych kamery dodawane są 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 Androidzie 8.0 wprowadzono Treble. W przypadku Treble implementacje HAL kamery dostawcy muszą być powiązane. Android 8.0 zawiera też te kluczowe ulepszenia usługi Aparat:

  • Wspólne powierzchnie: włącz wiele powierzchni udostępniających ten sam OutputConfiguration
  • Interfejs API systemu do niestandardowych trybów aparatu
  • onCaptureQueueEmpty

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

Wspólne powierzchnie

Ta funkcja umożliwia używanie tylko jednego zestawu buforów do obsługi dwóch wyjść, np. podglądu i kodowania wideo, co zmniejsza zużycie energii i pamięci. Aby obsługiwać tę funkcję, producenci urządzeń muszą zadbać o to, aby implementacje HAL aparatu i HAL gralloc mogły tworzyć bufory gralloc używane przez wielu różnych odbiorców (np. kompozytor sprzętowy/GPU i enkoder wideo), a nie tylko przez jednego odbiorcę. Usługa aparatu przekazuje flagi użycia przez konsumenta do warstwy HAL aparatu i warstwy HAL gralloc. Muszą one przydzielić odpowiednie rodzaje buforów lub warstwa HAL aparatu musi zwrócić błąd, że ta kombinacja konsumentów nie jest obsługiwana.

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

Interfejs API systemu do niestandardowych trybów aparatu

Publiczny interfejs API aparatu definiuje 2 tryby działania: normalny i ograniczony nagrywanie z dużą szybkością. Mają one dość odmienną semantykę. Na przykład tryb dużej szybkości jest ograniczony do maksymalnie 2 określonych wyjść jednocześnie. Różni producenci OEM wyrazili zainteresowanie zdefiniowaniem innych trybów niestandardowych dla funkcji specyficznych dla sprzętu. W rzeczywistości tryb ten jest liczbą całkowitą przekazywaną do funkcji configure_streams. Zobacz: hardware/camera/device/3.2/ICameraDeviceSession#configurestreams

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

Aby obsługiwać tę funkcję, producenci OEM muszą jedynie dodać nowy tryb do warstwy HAL, wywoływany przez liczbę całkowitą przekazywaną do warstwy HAL podczas konfigurowania strumieni, a następnie sprawić, aby ich niestandardowa aplikacja aparatu korzystała z 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 sterowania, takich jak powiększenie, poprzez utrzymywanie kolejki żądań w stanie jak najbardziej pustym. onCaptureQueueEmpty nie wymaga pracy w warstwie HAL, ponieważ jest to dodatek po stronie platformy. Aplikacje, które chcą z niej korzystać, muszą dodać detektor do tego wywołania zwrotnego i odpowiednio reagować. Zazwyczaj polega to na wysłaniu do urządzenia z kamerą kolejnej prośby o zrobienie zdjęcia.

Interfejs HIDL aparatu

Interfejs HIDL aparatu to całkowicie zmieniony interfejs HAL aparatu, 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 (w przypadku modułu aparatu) są również częścią definicji HIDL.

3.4

Drobne zmiany w obsługiwanych metadanych i obsłudze przestrzeni danych:

  • Dodaj ANDROID_SENSOR_OPAQUE_RAW_SIZE statyczne metadane jako obowiązkowe, jeśli obsługiwany jest RAW_OPAQUE format.
  • Dodaj ANDROID_CONTROL_POST_RAW_SENSITIVITY_BOOST_RANGEstatyczne metadane jako obowiązkowe, jeśli obsługiwany jest dowolny format RAW.
  • Zmień 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 można wykorzystać 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 rozszerzonej wersji HAL:

  • Aktualizacje interfejsu API ponownego przetwarzania OPAQUE i YUV.
  • Podstawowa obsługa buforów wyjściowych głębi.
  • Dodanie pola data_space do camera3_stream_t.
  • Dodanie pola rotacji do camera3_stream_t.
  • Dodanie trybu działania konfiguracji strumienia camera3 do camera3_stream_configuration_t.

3.2

Drobna zmiana rozszerzonej wersji HAL:

  • Wycofuje get_metadata_vendor_tag_ops. Zamiast niej używaj zasady get_vendor_tag_ops w camera_common.h.
  • Wycofuje register_stream_buffers. Wszystkie bufory gralloc przekazywane przez framework do HAL w process_capture_request mogą być w dowolnym momencie nowe.
  • Dodanie obsługi częściowych wyników. process_capture_result może być wywoływana wielokrotnie z podzbiorem dostępnych wyników, zanim będzie dostępny pełny wynik.
  • Dodaj szablon utworzony ręcznie do camera3_request_template. Aplikacje mogą używać tego szablonu do bezpośredniego kontrolowania ustawień przechwytywania.
  • Przekształć specyfikacje strumieni dwukierunkowych i wejściowych.
  • Zmień ścieżkę powrotu bufora wejściowego. Bufor jest zwracany w formacie process_capture_result zamiast process_capture_request.

3.1

Drobna zmiana rozszerzonej wersji HAL:

  • configure_streams przekazuje do HAL flagi dotyczące korzystania przez konsumentów.
  • wywołanie flush, aby jak najszybciej odrzucić wszystkie żądania w trakcie realizacji i buforowane dane.

3,0

Pierwsza wersja HAL o rozszerzonych możliwościach:

  • Zmiana wersji głównej, ponieważ interfejs ABI jest zupełnie inny. Wymagania sprzętowe ani model operacyjny nie ulegną zmianie w porównaniu z wersją 2.0.
  • Przeprojektowane interfejsy żądań wejściowych i kolejki strumieni: framework wywołuje HAL z następnym żądaniem i buforami strumieni już usuniętymi z kolejki. Obsługa platformy synchronizacji jest uwzględniona i niezbędna do skutecznych wdrożeń.
  • Przeniesiono wyzwalacze do żądań, a większość powiadomień do wyników.
  • Połączyliśmy wszystkie wywołania zwrotne w ramach struktury w jedną strukturę, a wszystkie metody konfiguracji w jedno wywołanie initialize().
  • Uprościliśmy zarządzanie strumieniami, przekształcając ich konfigurację w jedno wywołanie. Strumienie dwukierunkowe zastępują konstrukcję STREAM_FROM_STREAM.
  • Semantyka trybu ograniczonego dostępu na starszych i ograniczonych urządzeniach.

2,0

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

  • Wystarczające do wdrożenia istniejącego interfejsu API android.hardware.Camera.
  • Umożliwia kolejkę ZSL w warstwie usługi aparatu.
  • Nie testowano nowych funkcji, takich jak ręczne sterowanie rejestrowaniem, rejestrowanie w formacie Bayer RAW, ponowne przetwarzanie danych RAW itp.

1,0

Początkowy HAL aparatu na Androidzie (Android 4.0) [camera.h]:

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

Historia wersji modułu aparatu

Ta sekcja zawiera informacje o wersjach modułu sprzętu aparatu 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ę podrzędną.

2.4

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

  1. Obsługa trybu latarki. Platforma może włączyć tryb latarki w przypadku dowolnego urządzenia z aparatem, które ma lampę błyskową, bez otwierania tego urządzenia. Urządzenie z aparatem ma wyższy priorytet dostępu do lampy błyskowej niż moduł aparatu. Otwarcie urządzenia z aparatem wyłącza latarkę, jeśli została włączona przez interfejs modułu. W przypadku konfliktów zasobów, np. gdy wywoływana jest funkcja open() w celu otwarcia urządzenia z aparatem, moduł HAL aparatu musi powiadomić platformę za pomocą wywołania zwrotnego stanu trybu latarki, że tryb latarki został wyłączony.
  2. Obsługa kamer zewnętrznych (np. kamer USB podłączanych na gorąco). Aktualizacje interfejsu API określają, że statyczne informacje o aparacie są dostępne tylko wtedy, gdy aparat jest podłączony i gotowy do użycia w przypadku zewnętrznych aparatów podłączanych na gorąco. Wywołania funkcji pobierania statycznych informacji są nieprawidłowe, gdy stan aparatu nie jest CAMERA_DEVICE_STATUS_PRESENT. Platforma polega wyłącznie na wywołaniach zwrotnych dotyczących zmiany stanu urządzenia, aby zarządzać listą dostępnych aparatów zewnętrznych.
  3. Wskazówki dotyczące arbitrażu kamery Dodaje obsługę wyraźnego wskazywania liczby urządzeń z aparatem, które można jednocześnie otwierać i używać. Aby określić prawidłowe kombinacje urządzeń, pola resource_cost i conflicting_devices powinny być zawsze ustawione w strukturze camera_info zwracanej przez wywołanie get_camera_info.
  4. Metoda inicjowania modułu. Wywoływana przez usługę aparatu po załadowaniu modułu HAL, aby umożliwić jednorazową inicjację HAL. Jest wywoływana przed wywołaniem innych metod modułu.

2.3

Ta wersja modułu aparatu dodaje obsługę starszych urządzeń HAL aparatu. Framework może używać tego parametru do otwierania urządzenia z aparatem jako urządzenia HAL w starszej wersji, jeśli to samo urządzenie może obsługiwać wiele wersji interfejsu API urządzenia. Standardowe wywołanie otwierające moduł sprzętowy (common.methods->open) nadal otwiera urządzenie aparatu w najnowszej obsługiwanej wersji, która jest też wymieniona 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 vendor_tag_query_ops, które wcześniej były dostępne tylko po otwarciu urządzenia.

2.1

Ta wersja modułu aparatu dodaje do platformy obsługę asynchronicznych wywołań zwrotnych z modułu HAL aparatu, który służy do powiadamiania platformy o zmianach stanu modułu aparatu. Moduły, które udostępniają prawidłową metodę set_callbacks(), muszą zgłaszać 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. Urządzenia z aparatem, które można otworzyć za pomocą tego modułu, mogą obsługiwać interfejs HAL urządzenia z aparatem w wersji 1.0 lub 2.0. Pole device_version w obiekcie camera_info jest zawsze prawidłowe. Pole static_camera_characteristics w obiekcie camera_info jest prawidłowe, jeśli pole device_version ma wartość 2.0 lub wyższą.

1,0

Moduły aparatu, które zgłaszają te numery wersji, implementują początkowy interfejs HAL modułu aparatu. Wszystkie urządzenia z aparatem, które można otworzyć za pomocą tego modułu, obsługują tylko wersję 1 komponentu HAL aparatu. 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.