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.
Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
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 zastosowań motoryzacyjnych:
Strategie routingu dla poszczególnych producentów OEM.
Grupy głośności, które można dostosowywać, dla grup starszych typów strumieni za pomocą tych samych krzywych głośności.
strategie routingu deklarowane 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.
wycofane w Androidzie 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 strumienia wyjściowego i wejściowego, urządzeń do odtwarzania i rejestrowania 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)
callback 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 opisów dźwięku 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 z patchem audio. 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 dostępny pod adresemframeworks/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 toaudio_policy_configuration.xml, który znajduje się w folderze/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, a każdy z nich ma listę portów miksowania, portów urządzeń 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ą dostępne).
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ą służącą do przekształcania indeksu interfejsu w 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żywaj poleceń, 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 obsługę. 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, poprawek audio i portów audio). Wcześniej była ona zdefiniowana w AudioPolicyManager.cpp.
/engine
Wdraża reguły, które określają, które urządzenia i woluminy należy używać w danym przypadku użycia. Implementuje standardowy interfejs z częścią ogólną, aby uzyskać odpowiednie urządzenie do danego przypadku użycia odtwarzania lub rejestrowania albo 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 i zasadach zdefiniowanych w plikach 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 konfigurowalną politykę dźwięku można wybrać 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 łatki 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 wyboru 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 dokumentacji 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.
Ostatnia aktualizacja: 2025-04-04 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-04-04 UTC."],[],[]]