Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.
Wersja Androida 10 zawiera znaczącą refaktoryzację menedżera zasad dotyczących dźwięku, aby zapewnić większą elastyczność w obsługiwaniu złożonych przypadków użycia w samochodach:
Strategie routingu dla poszczególnych producentów OEM.
Grupy głośności, które można dostosowywać w przypadku grup starszych typów strumieni za pomocą tych samych krzywych głośności.
strategie routingu zadeklarowane przez mechanizm zasad audio zamiast być zakodowane na stałe.
Krzywe głośności i grupy zarządzane przez mechanizm zasad dotyczących dźwięku.
Wewnętrzny refaktoring w ramach przygotowań do przyszłego podziału na kod wspólny i kod konfigurowalny oraz zapewnienie bogatszego zarządzania urządzeniami audio. Na przykład w regułach zasad można używać wszystkich właściwości urządzenia, a nie tylko jego typu.
W Androidzie 7.0 wprowadzono format pliku konfiguracji zasad audio (XML) do opisywania topologii audio.
W poprzednich wersjach Androida wymagane było używanie pliku device/<company>/<device>/audio/audio_policy.conf do deklarowania urządzeń audio obecnych w produkcie (przykład tego pliku dla sprzętu audio Galaxy Nexus znajdziesz w pliku device/samsung/tuna/audio/audio_policy.conf). Jednak plik CONF to prosty, zastrzeżony format, który jest zbyt ograniczony, aby opisywać złożone topologie w branżach takich jak telewizory czy samochody.
wycofano obsługę Androida 7.0 audio_policy.conf i dodano obsługę definiowania topologii audio za pomocą formatu pliku XML, który jest bardziej czytelny dla człowieka, zawiera szeroki zakres narzędzi do edycji i analizy oraz jest na tyle elastyczny, że umożliwia opisywanie złożonych topologii audio. Android 7.0 używa parametru kompilacji USE_XML_AUDIO_POLICY_CONF do wyboru formatu XML plików konfiguracji.
Zalety formatu XML
Podobnie jak plik CONF, plik XML umożliwia definiowanie liczby i typów profili strumieni wyjściowych i wejściowych, urządzeń do odtwarzania i przechwytywania oraz atrybutów audio. Format XML zapewnia też te ulepszenia:
W Androidzie 10 można jednocześnie używać więcej niż 1 aktywnej aplikacji do nagrywania.
Rozpoczęcie nagrywania nigdy nie jest odrzucane z powodu sytuacji równoległej.
registerAudioRecordingCallback(AudioManager.AudioRecordingCallback cb)
Usługa powiadamia klientów o zmianach ścieżki przechwytywania.
W tych sytuacjach klient otrzymuje cichutkie próbki dźwiękowe:
Aktywny jest przypadek użycia, który wymaga ochrony prywatności (np. VOICE_COMMUNICATION).
Klient nie ma usługi na pierwszym planie ani interfejsu użytkownika na pierwszym planie.
Zasady uwzględniają te role specjalne:
Usługa ułatwień dostępu: może nagrywać nawet wtedy, gdy aktywne jest zastosowanie związane z ochrona prywatności.
Asystent: uważany za wrażliwy na prywatność, jeśli interfejs jest na górze.
Profile audio mają strukturę podobną do prostych wskaźników audio HDMI, co umożliwia stosowanie innego zestawu częstotliwości próbkowania lub masek kanałów w przypadku każdego formatu audio.
Istnieją wyraźne definicje wszystkich możliwych połączeń między urządzeniami i strumieniami.
Wcześniej reguła domyślna umożliwiała łączenie wszystkich urządzeń podłączonych do tego samego modułu HAL, uniemożliwiając zasadom dotyczącym dźwięku kontrolowanie połączeń żądanych za pomocą interfejsów API dźwięku. W formacie XML opis topologii określa ograniczenia połączenia.
Obsługa includes pozwala uniknąć powtarzania standardowych definicji A2DP, USB i przekierowania przesyłania.
Krzywe głośności można dostosowywać. 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 na stronieframeworks/av/services/audiopolicy/config/audio_policy_configuration.xmlpokazuje wiele z tych funkcji w akcji.
Format i lokalizacja pliku
Nowy plik konfiguracji zasad dotyczących dźwięku to audio_policy_configuration.xml, który znajduje się w /system/etc. Poniższe przykłady pokazują prostą konfigurację zasad dotyczących dźwięku w formacie pliku XML na potrzeby Androida 12 i wersji starszych niż Android 12.
Przykład zasad dotyczących dźwięku w Androidzie 12
Struktura najwyższego poziomu zawiera moduły odpowiadające poszczególnym modułom sprzętowym HAL audio. Każdy moduł ma listę portów miksowania, portów urządzenia i tras:
Porty miksowania opisują możliwe profile konfiguracji strumieni, które można otworzyć w HAL dźwięku na potrzeby odtwarzania i przechwytywania.
Porty urządzenia opisują urządzenia, które można podłączyć, wraz z ich typem (i opcjonalnie właściwościami adresu i dźwięku, jeśli są istotne).
Routes jest oddzielone od deskryptora portu mix, co umożliwia opisywanie tras z urządzenia na urządzenie lub z strumienia na urządzenie.
Tabele głośności to proste listy punktów definiujących krzywą używaną do przekształcania indeksu interfejsu na głośność w dB. Oddzielny plik include zawiera domyślne krzywe, ale każdą krzywą dla danego zastosowania i kategorii urządzenia można zastąpić.
Metody uwzględniania kodu XML (XInclude) można używać do uwzględniania informacji o konfiguracji zasad dotyczących dźwięku znajdujących się w innych plikach XML. Wszystkie uwzględnione pliki muszą mieć strukturę opisaną powyżej z tymi ograniczeniami:
Pliki mogą zawierać tylko elementy najwyższego poziomu.
Pliki nie mogą zawierać elementów XInclude.
Użyj include, aby uniknąć kopiowania informacji o standardowych konfiguracjach modułu HAL dźwięku z projektu Android Open Source (AOSP) do wszystkich plików konfiguracji zasad dźwięku (co może powodować błędy). Standardowy plik XML konfiguracji zasad audio jest dostępny dla tych interfejsów HAL dźwięku:
AudioPolicyManager.cpp jest podzielony na kilka modułów, aby ułatwić jego konfigurowanie i utrzymanie. Organizacja frameworks/av/services/audiopolicy obejmuje te moduły:
Moduł
Opis
/managerdefault
Obejmuje interfejsy i zachowanie wspólne dla wszystkich aplikacji. Podobnie jak w przypadku AudioPolicyManager.cpp, funkcje silnika i pojęcia ogólne są abstrakcyjne.
/common
Definiuje klasy podstawowe (np. struktury danych dla profili wejściowych profili strumienia audio, deskryptorów urządzeń audio, łat na potrzeby audio i portów audio). Wcześniej była ona zdefiniowana w AudioPolicyManager.cpp.
/engine
Wdraża reguły, które określają, jakie urządzenie i woluminy należy użyć w danym przypadku użycia. Implementuje standardowy interfejs z częścią ogólną, na przykład aby uzyskać odpowiednie urządzenie do danego przypadku użycia odtwarzania lub rejestrowania, albo aby ustawić połączone urządzenia lub stan zewnętrzny (czyli stan połączenia z wymuszonym użyciem), który może zmienić decyzję o przekierowaniu.
Implementacja mechanizmu zasad, która opiera się na ramach parametrów (patrz poniżej).
Konfiguracja opiera się na ramach parametrów, a zasady są definiowane za pomocą plików XML.
/enginedefault
Wdrożenie mechanizmu zasad oparte na wcześniejszych implementacjach Menedżera zasad dotyczących dźwięku w Androidzie. Jest to domyślna opcja, która zawiera zakodowane na stałe reguły odpowiadające implementacjom w Nexusie i AOSP.
/service
Obejmuje interfejsy bindera, implementację wątków i blokowania z interfejsem do reszty frameworka.
Konfiguracja za pomocą platformy parametrów
Kod zasad dotyczących dźwięku jest uporządkowany w sposób ułatwiający jego zrozumienie i utrzymanie, a jednocześnie obsługuje zasady dźwięku zdefiniowane wyłącznie przez pliki konfiguracji. Organizacja i projekt zasad dotyczących dźwięku są oparte na platformie Intel Parameter Framework, która jest platformą opartą na wtyczkach i regułach do obsługi parametrów.
Dzięki konfigurowalnej polityce dotyczącej dźwięku producenci OEM mogą:
Opisz strukturę systemu i jego parametry w formacie XML.
Aby uzyskać dostęp do opisanych parametrów, napisz (w C++) lub ponownie użyj backendu (wtyczki).
Zdefiniuj (w formacie XML lub w języku domeny) warunki lub reguły, na podstawie których dany parametr musi przyjmować określoną wartość.
AOSP zawiera przykładowy plik konfiguracji zasad audio, który korzysta z ramy parametrycznej (Frameworks/av/services/audiopolicy/engineconfigurable/parameter-framework/example/Settings/PolicyConfigurableDomains.xml). Szczegółowe informacje znajdziesz w dokumentacji firmy Intel na temat ramy danych.
W Androidzie 10 lub starszym konfigurowalna polityka dźwięku jest wybierana za pomocą opcji kompilacji USE_CONFIGURABLE_AUDIO_POLICY.
W Androidzie 11 lub nowszym wersja silnika zasad dotyczących dźwięku jest wybierana w pliku audio_policy_configuration.xml.
Aby wybrać konfigurowalną wyszukiwarkę zasad dotyczących dźwięku, ustaw wartość atrybutu engine_library elementu globalConfiguration na configurable, jak w tym przykładzie:
Android 6.0 wprowadził publiczny interfejs API Enumeration and Selection, który działa na podstawie infrastruktury ścieżki audio lub portu audio i umożliwia deweloperom aplikacji wskazanie preferowanego wyjścia lub wejścia na urządzeniu dla połączonych nagrań lub ścieżek audio.
W Androidzie 7.0 interfejs API do zliczania i wybierania jest weryfikowany przez testy CTS i rozszerzony o przekierowywanie natywnych strumieni audio C/C++ (OpenSL ES).
Przekierowywanie strumieni natywnych nadal odbywa się w języku Java, ale z dodatkiem interfejsu AudioRouting, który zastępuje, łączy i wycofa jawne metody kierowania, które były specyficzne dla klas AudioTrack i AudioRecord.
Szczegółowe informacje o interfejsach konfiguracji interfejsu API Enumeration and Selection znajdziesz w interfejsach konfiguracji Androida i OpenSLES_AndroidConfiguration.h.
Szczegółowe informacje o przesyłaniu dźwięku znajdziesz w artykule AudioRouting.
Pomoc w wielu kanałach
Jeśli sprzęt i sterownik obsługują dźwięk wielokanałowy przez HDMI, możesz przesyłać strumień audio bezpośrednio do sprzętu audio (omijając mikser AudioFlinger, dzięki czemu nie zostanie on zmiksowany do 2 kanałów). HAL dźwięku musi udostępniać informacje o tym, czy profil strumienia wyjściowego obsługuje funkcje dźwięku wielokanałowego. Jeśli HAL udostępnia swoje możliwości, domyślny menedżer zasad zezwala na odtwarzanie wielokanałowe przez HDMI. Szczegóły wdrażania znajdziesz w device/samsung/tuna/audio/audio_hw.c.
Aby określić, że Twój produkt zawiera wyjście audio wielokanałowe, zmodyfikuj plik konfiguracji zasad dotyczących dźwięku, 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 zasad dotyczących dźwięku wysyła zapytanie o maski kanałów obsługiwane przez odbiornik HDMI po połączeniu.
Możesz też podać stałą maskę kanału, np. AUDIO_CHANNEL_OUT_5POINT1. Mikser w AudioFlinger automatycznie konwertuje treści na dźwięk stereo, gdy zostaną wysłane na urządzenie audio, które nie obsługuje dźwięku wielokanałowego.
Kodeki multimediów
Upewnij się, że kodeki audio obsługiwane przez sprzęt i sterowniki są prawidłowo zadeklarowane w Twoim produkcie. Szczegółowe informacje znajdziesz w artykule Wyświetlanie kodeków w ramach frameworku.
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.