Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Wersja Androida 10 zawiera znaczną refaktoryzację menedżera zasad audio, aby zapewnić większą elastyczność w obsłudze złożonych przypadków użycia w motoryzacji:
Strategie routingu specyficzne dla OEM.
Konfigurowalne grupy głośności dla grup starszych typów strumieni przy użyciu tych samych krzywych głośności.
Strategie routingu deklarowane przez silnik polityki audio zamiast być zakodowane na stałe.
Krzywe głośności i grupy zarządzane przez silnik zasad audio.
Refaktoryzacja wewnętrzna przygotowująca na przyszły podział między kodem wspólnym i konfigurowalnym oraz oferująca bogatsze zarządzanie urządzeniami audio. Na przykład użycie wszystkich właściwości urządzenia, a nie tylko jego typu w regułach zasad.
W systemie Android 7.0 wprowadzono format pliku konfiguracji zasad audio (XML) do opisywania topologii dźwięku.
Poprzednie wersje Androida wymagały użycia device/<company>/<device>/audio/audio_policy.conf w celu zadeklarowania urządzeń audio obecnych w Twoim produkcie (przykład tego pliku dla sprzętu audio Galaxy Nexus znajdziesz w device/samsung/tuna/audio/audio_policy.conf ). Jednak CONF jest prostym, zastrzeżonym formatem, który jest zbyt ograniczony, aby opisywać złożone topologie dla branż takich jak telewizory i samochody.
Android 7.0 audio_policy.conf i dodał obsługę definiowania topologii dźwięku przy użyciu formatu pliku XML, który jest bardziej czytelny dla człowieka, ma szeroki zakres narzędzi do edycji i analizowania oraz jest wystarczająco elastyczny, aby opisywać złożone topologie dźwięku. Android 7.0 używa flagi kompilacji USE_XML_AUDIO_POLICY_CONF do wybierania formatu XML plików konfiguracyjnych.
Zalety formatu XML
Podobnie jak w pliku CONF, plik XML umożliwia zdefiniowanie liczby i typów profili strumieni wyjściowych i wejściowych, urządzeń nadających się do odtwarzania i przechwytywania oraz atrybutów audio. Ponadto format XML oferuje następujące ulepszenia:
W systemie Android 10 dozwolona jest jednocześnie więcej niż jedna aktywna aplikacja do nagrywania.
Rozpoczęcie nagrywania nigdy nie jest odrzucane z powodu sytuacji współbieżności.
Wywołanie zwrotne registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb) powiadamia klientów o zmianach ścieżki przechwytywania.
W następujących sytuacjach klient otrzymuje ciche próbki audio:
Przypadek użycia uwzględniający prywatność (na przykład VOICE_COMMUNICATION ) jest aktywny.
Klient nie ma usługi ani interfejsu użytkownika na pierwszym planie.
Role specjalne są uznawane przez politykę:
Usługa ułatwień dostępu: może nagrywać nawet wtedy, gdy aktywny jest przypadek użycia związany z ochroną prywatności.
Asystent: uważany za wrażliwy na prywatność, jeśli interfejs użytkownika jest na górze.
Profile audio mają strukturę podobną do prostych deskryptorów audio HDMI, umożliwiając inny zestaw częstotliwości próbkowania/masek kanałów dla każdego formatu audio.
Istnieją wyraźne definicje wszystkich możliwych połączeń między urządzeniami i strumieniami. Wcześniej niejawna reguła umożliwiała połączenie wszystkich urządzeń podłączonych do tego samego modułu HAL, uniemożliwiając polityce audio kontrolowanie połączeń żądanych za pomocą interfejsów API poprawki audio. W formacie XML opis topologii definiuje ograniczenia połączeń.
Obsługa obejmuje unikanie powtarzania standardowych definicji A2DP, USB lub przekierowywania przesyłanych definicji.
Krzywe objętości można dostosować. Wcześniej tabele objętości były zakodowane na stałe. W formacie XML tabele objętości są opisane i można je dostosować.
Szablon w frameworks/av/services/audiopolicy/config/audio_policy_configuration.xml pokazuje wiele z tych funkcji w użyciu.
Format i lokalizacja pliku
Nowy plik konfiguracyjny zasad audio to audio_policy_configuration.xml i znajduje się w /system/etc . Poniższe przykłady przedstawiają prostą konfigurację zasad audio w formacie pliku XML dla systemu Android 12 i dla wersji niższych niż Android 12.
Pokaż przykład zasad dotyczących dźwięku dla Androida 12
Struktura najwyższego poziomu zawiera moduły odpowiadające każdemu modułowi sprzętowemu audio HAL, gdzie każdy moduł ma listę portów mix, portów urządzeń i tras:
Porty miksowania opisują możliwe profile konfiguracji dla strumieni, które można otwierać w warstwie HAL audio w celu odtwarzania i przechwytywania.
Porty urządzeń opisują urządzenia, które można podłączyć, podając ich typ (oraz opcjonalnie adres i właściwości audio, jeśli dotyczy).
Trasy są oddzielone od deskryptora portu mix, umożliwiając opis tras od urządzenia do urządzenia lub strumienia do urządzenia.
Tabele głośności to proste listy punktów definiujących krzywą używaną do przełożenia z indeksu interfejsu użytkownika na głośność w dB. Oddzielny plik include zawiera krzywe domyślne, ale każdą krzywą dla danego przypadku użycia i kategorii urządzenia można nadpisać.
Metoda XML Inclusions (XInclude) może być użyta do dołączenia informacji o konfiguracji zasad audio znajdujących się w innych plikach XML. Wszystkie dołączone pliki muszą mieć strukturę opisaną powyżej z następującymi ograniczeniami:
Pliki mogą zawierać tylko elementy najwyższego poziomu.
Pliki nie mogą zawierać elementów XInclude.
Zastosowanie obejmuje uniknięcie kopiowania standardowych informacji o konfiguracji modułu HAL systemu Android Open Source Project (AOSP) do wszystkich plików konfiguracji zasad audio (co jest podatne na błędy). Standardowy plik XML konfiguracji zasad dotyczących dźwięku jest dostarczany dla następujących warstw HAL dźwięku:
AudioPolicyManager.cpp jest podzielony na kilka modułów, aby ułatwić jego konserwację i konfigurację. Organizacja frameworks/av/services/audiopolicy obejmuje następujące moduły.
Moduł
Opis
/managerdefault
Zawiera ogólne interfejsy i implementację zachowań wspólne dla wszystkich aplikacji. Podobny do AudioPolicyManager.cpp z funkcjonalnością silnika i abstrakcyjnymi typowymi koncepcjami.
/common
Definiuje klasy bazowe (na przykład struktury danych dla profili strumieni wejściowych i wyjściowych audio, deskryptory urządzeń audio, poprawki audio i porty audio). Zostało to wcześniej zdefiniowane w AudioPolicyManager.cpp .
/engine
Implementuje reguły określające, które urządzenie i woluminy powinny być używane w danym przypadku użycia. Implementuje standardowy interfejs z częścią ogólną, taki jak uzyskanie odpowiedniego urządzenia dla danego przypadku użycia odtwarzania lub przechwytywania lub ustawienie podłączonych urządzeń lub stanu zewnętrznego (tj. stanu wywołania wymuszonego użycia), który może zmienić routing decyzja.
Implementacja silnika zasad, która opiera się na strukturze parametrów (patrz poniżej). Konfiguracja opiera się na strukturze parametrów i gdzie zasady są definiowane przez pliki XML.
/enginedefault
Implementacja silnika zasad oparta na wcześniejszych implementacjach Android Audio Policy Manager. Jest to ustawienie domyślne i zawiera zakodowane reguły odpowiadające implementacjom Nexusa i AOSP.
/service
Obejmuje interfejsy spinaczy, wątki i implementację blokowania z interfejsem do reszty frameworka.
Konfiguracja przy użyciu struktury parametrów
Kod zasad dotyczących dźwięku jest zorganizowany w taki sposób, aby był łatwy do zrozumienia i utrzymania, a jednocześnie wspierał zasady dotyczące dźwięku zdefiniowane w całości przez pliki konfiguracyjne. Projekt polityki organizacji i dźwięku opiera się na strukturze parametrów Intela, opartej na wtyczkach i regułach do obsługi parametrów.
Korzystanie z konfigurowalnych zasad audio umożliwia producentom OEM:
Opisz strukturę systemu i jego parametry w XML.
Napisz (w C++) lub ponownie użyj backendu (wtyczki) w celu uzyskania dostępu do opisanych parametrów.
Zdefiniuj (w XML lub języku specyficznym dla domeny) warunki/reguły, zgodnie z którymi dany parametr musi przyjąć określoną wartość.
AOSP zawiera przykład pliku konfiguracji zasad audio, który używa struktury parametrów w Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml . Szczegółowe informacje można znaleźć w dokumentacji firmy Intel dotyczącej struktury parametrów .
W systemie Android 10 lub starszym konfigurowalne zasady audio są wybierane za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY . W systemie Android 11 lub nowszym wersja aparatu zasad audio jest wybierana w pliku audio_policy_configuration.xml . Aby wybrać konfigurowalny mechanizm zasad audio, ustaw wartość atrybutu engine_library elementu globalConfiguration na configurable , jak w poniższym przykładzie:
W systemie Android 6.0 wprowadzono publiczny interfejs API wyliczania i wyboru, który znajduje się na szczycie infrastruktury portu audio/portu audio i umożliwia deweloperom aplikacji wskazanie preferencji dotyczących określonego wyjścia lub wejścia urządzenia dla podłączonych rekordów lub ścieżek audio.
W systemie Android 7.0 interfejs API wyliczania i wyboru jest weryfikowany przez testy CTS i jest rozszerzony o routing dla natywnych strumieni audio C/C++ (OpenSL ES). Routing strumieni natywnych jest nadal wykonywany w Javie, z dodatkiem interfejsu AudioRouting , który zastępuje, łączy i odrzuca jawne metody routingu, które były specyficzne dla klas AudioRecordAudioTrack
Aby uzyskać szczegółowe informacje na temat interfejsu API wyliczania i wyboru, zapoznaj się z interfejsami konfiguracyjnymi systemu Android i OpenSLES_AndroidConfiguration.h . Aby uzyskać szczegółowe informacje na temat routingu audio, zobacz AudioRouting .
Obsługa wielu kanałów
Jeśli twój sprzęt i sterownik obsługują dźwięk wielokanałowy przez HDMI, możesz wyprowadzić strumień audio bezpośrednio do sprzętu audio (pomija to mikser AudioFlinger, dzięki czemu nie jest miksowany w dół do dwóch kanałów). Audio HAL musi ujawniać, czy profil strumienia wyjściowego obsługuje funkcje dźwięku wielokanałowego. Jeśli warstwa HAL ujawnia swoje możliwości, domyślny menedżer zasad umożliwia odtwarzanie wielokanałowe przez HDMI. Aby uzyskać szczegółowe informacje na temat implementacji, zobacz device/samsung/tuna/audio/audio_hw.c .
Aby określić, że produkt zawiera wielokanałowe wyjście audio, edytuj plik konfiguracyjny zasad audio, aby opisać wyjście wielokanałowe dla produktu. Poniższy przykład z frameworks/av/services/audiopolicy/config/primary_audio_policy_configuration_tv.xml pokazuje dynamiczną maskę kanału, co oznacza, że menedżer polityki audio pyta po połączeniu o maski kanałów obsługiwane przez ujście HDMI.
Możesz także określić maskę kanału statycznego, taką jak AUDIO_CHANNEL_OUT_5POINT1 . Mikser AudioFlinger automatycznie miksuje zawartość do stereo po wysłaniu do urządzenia audio, które nie obsługuje dźwięku wielokanałowego.
Kodeki multimedialne
Upewnij się, że kodeki audio obsługiwane przez Twój sprzęt i sterowniki są prawidłowo zadeklarowane dla Twojego produktu. Aby uzyskać szczegółowe informacje, zobacz Udostępnianie kodeków do struktury .
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.