Jetzt starten

WARNUNG: OpenSL ES wird eingestellt. Entwickler sollten die Open-Source-Oboe-Bibliothek verwenden, die auf GitHub verfügbar ist. Oboe ist ein C++-Wrapper, der eine API bietet, die AAudio sehr ähnelt. Oboe ruft AAudio auf, wenn AAudio verfügbar ist, und wechselt zu OpenSL ES, wenn AAudio nicht verfügbar ist.

In diesem Abschnitt finden Sie die Informationen, die Sie für den Einstieg in die OpenSL ES APIs benötigen.

OpenSL ES zu Ihrer App hinzufügen

Sie können OpenSL ES sowohl über C- als auch über C++-Code aufrufen. Wenn Sie Ihrer App die grundlegenden OpenSL ES-Funktionen hinzufügen möchten, fügen Sie die OpenSLES.h-Headerdatei ein: 

#include <SLES/OpenSLES.h>

Wenn Sie auch die Android-Erweiterungen von OpenSL ES hinzufügen möchten, fügen Sie die OpenSLES_Android.h-Headerdatei hinzu: 

#include <SLES/OpenSLES_Android.h>

Wenn Sie die Headerdatei OpenSLES_Android.h einfügen, werden die folgenden Header automatisch eingefügt: 

#include <SLES/OpenSLES_AndroidConfiguration.h>
#include <SLES/OpenSLES_AndroidMetadata.h>

Hinweis : Diese Header sind nicht erforderlich, werden aber als Hilfestellung für das Erlernen der API angezeigt.

Erstellen und debuggen

Sie können OpenSL ES in Ihren Build einbinden, indem Sie es in der Datei Android.mk angeben, die als eines der Makefiles des NDK-Build-Systems dient. Fügen Sie die folgende Zeile zu Android.mk hinzu: 

LOCAL_LDLIBS += -lOpenSLES

Für eine zuverlässige Fehlerbehebung empfehlen wir, den Wert SLresult zu prüfen, den die meisten OpenSL ES APIs zurückgeben. Sie können zum Debuggen Asserts oder eine erweiterte Logik zur Fehlerbehandlung verwenden. Beides bietet keinen Vorteil bei der Arbeit mit OpenSL ES, obwohl die eine oder andere Methode für einen bestimmten Anwendungsfall besser geeignet sein kann.

In unseren Beispielen verwenden wir Assertions, da damit unrealistische Bedingungen erkannt werden, die auf einen Codierungsfehler hinweisen. Für andere Bedingungen, die in der Produktion häufiger auftreten, haben wir eine explizite Fehlerbehandlung verwendet.

Viele API-Fehler führen neben einem nicht nullwertigen Ergebniscode auch zu einem Logeintrag. Solche Logeinträge können zusätzliche Details liefern, die sich für relativ komplexe APIs wie Engine::CreateAudioPlayer als besonders nützlich erweisen.

Sie können das Protokoll entweder über die Befehlszeile oder über Android Studio aufrufen. Geben Sie folgenden Befehl in die Kommandozeile ein, um das Protokoll zu prüfen: 

$ adb logcat

Wenn Sie das Protokoll in Android Studio prüfen möchten, wählen Sie Ansicht > Toolfenster > Logcat aus. Weitere Informationen finden Sie unter Logs mit Logcat schreiben und ansehen.

Beispielcode

Wir empfehlen, unterstützten und getesteten Beispielcode zu verwenden, der als Modell für Ihren eigenen Code verwendet werden kann. Sie finden ihn in den Verzeichnissen audio-echo und native-audio des GitHub-Repositorys android-ndk.

Achtung : Die OpenSL ES 1.0.1-Spezifikation enthält in den Anhängen Beispielcode. Weitere Informationen finden Sie in der Khronos OpenSL ES Registry. In den Beispielen in Anhang B: Beispielcode und Anhang C: Beispielcode für Anwendungsfälle werden jedoch Funktionen verwendet, die von Android nicht unterstützt werden. Einige Beispiele enthalten auch Tippfehler oder verwenden APIs, die sich wahrscheinlich ändern werden. Seien Sie bei der Verwendung dieser Beispiele vorsichtig. Der Code kann zwar hilfreich sein, um den vollständigen OpenSL ES-Standard zu verstehen, sollte aber nicht unverändert in Android-Apps verwendet werden.

Audio-Inhalt

Es gibt viele Möglichkeiten, Audioinhalte für Ihre Anwendung zu verpacken:

  • Ressourcen: Wenn du deine Audiodateien im Ordner res/raw/ ablegst, können die zugehörigen APIs für Resources ganz einfach darauf zugreifen. Es gibt jedoch keinen direkten nativen Zugriff auf Ressourcen. Daher müssen Sie Java-Programmiercode schreiben, um sie vor der Verwendung herauszukopieren.
  • Assets: Wenn Sie Ihre Audiodateien in den Ordner assets/ verschieben, können die nativen Asset-Manager-APIs von Android direkt darauf zugreifen. Weitere Informationen zu diesen APIs finden Sie in den Headerdateien android/asset_manager.h und android/asset_manager_jni.h. Im Beispielcode im GitHub-Repository android-ndk werden diese nativen Asset-Manager-APIs in Verbindung mit dem Android-Datenlocator für Dateien verwendet.
  • Netzwerk: Mit dem URI-Data Locator können Sie Audioinhalte direkt aus dem Netzwerk wiedergeben. Wir empfehlen Ihnen jedoch, den Artikel Sicherheit und Berechtigungen zu lesen.
  • Lokales Dateisystem: Der URI-Data Locator unterstützt das Schema file: für lokale Dateien, sofern die Dateien für die Anwendung zugänglich sind. Das Android-Sicherheitsframework schränkt den Dateizugriff über die Linux-Nutzer-ID- und Gruppen-ID-Mechanismen ein.
  • Aufgenommen: Ihre Anwendung kann Audiodaten über den Mikrofoneingang aufnehmen, diese Inhalte speichern und später wiedergeben. Im Beispielcode wird diese Methode für den Clip Wiedergabe verwendet.
  • Inline kompiliert und verknüpft: Sie können Ihre Audioinhalte direkt in der freigegebenen Bibliothek verknüpfen und dann mit einem Audioplayer mit einem Datenlocator für die Pufferwarteschlange abspielen. Diese Option eignet sich am besten für kurze Clips im PCM-Format. Im Beispielcode wird diese Technik für die Clips Hallo und Android verwendet. Die PCM-Daten wurden mit einem bin2c-Tool (nicht im Lieferumfang enthalten) in Hexadezimalstrings umgewandelt.
  • Echtzeitsynthese: Ihre Anwendung kann PCM-Daten direkt synthetisieren und dann mit einem Audioplayer mit Pufferwarteschlangen-Datensuchmechanismus abspielen. Dies ist eine relativ fortgeschrittene Technik und die Details der Audiosynthese gehen über den Rahmen dieses Artikels hinaus.

Hinweis : Das Finden oder Erstellen nützlicher Audioinhalte für Ihre Anwendung wird in diesem Artikel nicht behandelt. Sie können Suchbegriffe wie interaktive Audioinhalte, Game-Audio, Tondesign und Audioprogrammierung verwenden, um weitere Informationen zu finden.

Achtung:Sie sind dafür verantwortlich, dass Sie Inhalte legal abspielen oder aufzeichnen dürfen. Beim Aufzeichnen von Inhalten können Datenschutzaspekte zu beachten sein.

Codebeispiele

Diese Beispielanwendungen sind auf unserer GitHub-Seite verfügbar:

Die Android-NDK-Implementierung von OpenSL ES unterscheidet sich in einigen Punkten von der Referenzspezifikation für OpenSL ES 1.0.1. Diese Unterschiede sind ein wichtiger Grund dafür, dass Beispielcode, den Sie direkt aus der OpenSL ES-Referenzspezifikation kopieren, möglicherweise nicht in Ihrer Android-App funktioniert.

Weitere Informationen zu den Unterschieden zwischen der Referenzspezifikation und der Android-Implementierung finden Sie unter OpenSL ES für Android.