Fehlerbehebung

Fehler vom Typ „Cleartext HTTP traffic not permitted“ beheben

Dieser Fehler tritt auf, wenn Ihre App Cleartext-HTTP-Traffic anfordert (d. h. http:// anstelle von https://), die Netzwerksicherheitskonfiguration dies aber nicht zulässt. Wenn Ihre App auf Android 9 (API-Level 28) oder höher ausgerichtet ist, ist Cleartext-HTTP-Traffic in der Standardkonfiguration deaktiviert.

Wenn Ihre App mit Cleartext-HTTP-Traffic funktionieren muss, benötigen Sie eine Netzwerksicherheitskonfiguration, die dies zulässt. Weitere Informationen finden Sie in der Dokumentation zur Netzwerksicherheit von Android. Wenn Sie den gesamten Cleartext-HTTP-Traffic aktivieren möchten, fügen Sie einfach android:usesCleartextTraffic="true" dem application Element der AndroidManifest.xml Ihrer App hinzu.

Die ExoPlayer-Demo-App verwendet die Standardkonfiguration für die Netzwerksicherheit und lässt daher keinen Cleartext-HTTP-Traffic zu. Sie können ihn mit der obigen Anleitung aktivieren.

Fehler vom Typ „SSLHandshakeException“, „CertPathValidatorException“ und „ERR_CERT_AUTHORITY_INVALID“ beheben

SSLHandshakeException, CertPathValidatorException und ERR_CERT_AUTHORITY_INVALID weisen alle auf ein Problem mit dem SSL-Zertifikat des Servers hin. Diese Fehler sind nicht spezifisch für ExoPlayer. Weitere Informationen finden Sie in der SSL-Dokumentation von Android.

Warum kann in einigen Mediendateien nicht gesucht werden?

Standardmäßig unterstützt ExoPlayer die Suche in Medien nicht, bei denen die einzige Methode für genaue Suchvorgänge darin besteht, dass der Player die gesamte Datei scannt und indexiert. ExoPlayer betrachtet solche Dateien als nicht durchsuchbar. Die meisten modernen Media-Containerformate enthalten Metadaten für die Suche (z. B. einen Beispielindex), haben einen genau definierten Suchalgorithmus (z. B. interpolierte Bisektionssuche für Ogg) oder geben an, dass ihre Inhalte eine konstante Bitrate haben. In diesen Fällen sind effiziente Suchvorgänge möglich und werden von ExoPlayer unterstützt.

Wenn Sie die Suche benötigen, aber nicht durchsuchbare Medien haben, empfehlen wir, Ihre Inhalte in ein geeigneteres Containerformat zu konvertieren. Bei MP3-, ADTS- und AMR-Dateien, können Sie die Suche auch unter der Annahme aktivieren, dass die Dateien eine konstante Bitrate haben, wie hier beschrieben.

Warum ist die Suche in einigen MP3-Dateien ungenau?

MP3-Dateien mit variabler Bitrate (VBR) sind grundsätzlich nicht für Anwendungsfälle geeignet, die eine genaue Suche erfordern. Dafür gibt es zwei Gründe.

  1. Für eine genaue Suche sollte ein Containerformat idealerweise eine präzise Zuordnung von Zeit zu Byte in einem Header enthalten. Mit dieser Zuordnung kann ein Player eine angeforderte Suchzeit dem entsprechenden Byte-Offset zuordnen und ab diesem Offset Medien anfordern, parsen und wiedergeben. Die Header, die zum Angeben dieser Zuordnung in MP3 verfügbar sind (z. B. XING-Header), sind leider oft ungenau.
  2. Bei Containerformaten, die keine präzise Zuordnung von Zeit zu Byte (oder überhaupt keine Zuordnung von Zeit zu Byte) bieten, ist es dennoch möglich, eine genaue Suche durchzuführen, wenn der Container absolute Zeitstempel für die Beispiele im Stream enthält. In diesem Fall kann ein Player die Suchzeit einer bestmöglichen Schätzung des entsprechenden Byte-Offsets zuordnen, Medien ab diesem Offset anfordern, den ersten absoluten Zeitstempel für das Beispiel parsen und effektiv eine geführte binäre Suche in den Medien durchführen, bis er das richtige Beispiel findet. Leider enthält MP3 keine absoluten Zeitstempel für die Beispiele im Stream, daher ist dieser Ansatz nicht möglich.

Aus diesen Gründen besteht die einzige Möglichkeit, eine genaue Suche in einer VBR-MP3-Datei durchzuführen, darin, die gesamte Datei zu scannen und im Player manuell eine Zuordnung von Zeit zu Byte zu erstellen. Diese Strategie kann mit FLAG_ENABLE_INDEX_SEEKING, aktiviert werden, das für eine festgelegt werden kannDefaultExtractorsFactory mit setMp3ExtractorFlags. Beachten Sie, dass sie nicht gut für große MP3-Dateien skaliert, insbesondere wenn der Nutzer kurz nach Beginn der Wiedergabe versucht, in der Nähe des Endes des Streams zu suchen. In diesem Fall muss der Player warten, bis der gesamte Stream heruntergeladen und indexiert wurde, bevor er die Suche durchführen kann. In ExoPlayer haben wir uns in diesem Fall für die Geschwindigkeit gegenüber der Genauigkeit entschieden und FLAG_ENABLE_INDEX_SEEKING ist daher standardmäßig deaktiviert.

Wenn Sie die Medien steuern, die Sie wiedergeben, empfehlen wir dringend, ein geeigneteres Containerformat wie MP4 zu verwenden. Uns sind keine Anwendungsfälle bekannt, in denen MP3 die beste Wahl für das Media-Format ist.

Warum ist die Suche in meinem Video langsam?

Wenn der Player in einem Video zu einer neuen Wiedergabeposition sucht, muss er zwei Dinge tun:

  1. Die Daten, die der neuen Wiedergabeposition entsprechen, in den Puffer laden (dies ist möglicherweise nicht erforderlich, wenn diese Daten bereits gepuffert sind).
  2. Den Videodecoder leeren und die Decodierung ab dem I-Frame (Keyframe) vor der neuen Wiedergabeposition starten, da die Intra-Frame-Codierung von den meisten Videokomprimierungsformaten verwendet wird. Damit die Suche genau ist (d. h. die Wiedergabe genau an der Suchposition beginnt), müssen alle Frames zwischen dem vorherigen I-Frame und der Suchposition decodiert und sofort verworfen werden (ohne auf dem Bildschirm angezeigt zu werden).

Die durch (1) verursachte Latenz kann verringert werden, indem entweder die Menge der vom Player im Arbeitsspeicher gepufferten Daten erhöht oder die Daten auf der Festplatte vorab im Cache gespeichert werden.

Die durch (2) verursachte Latenz kann verringert werden, indem entweder die Genauigkeit der Suche mit ExoPlayer.setSeekParameters reduziert oder das Video neu codiert wird, um häufigere I-Frames zu haben (was zu einer größeren Ausgabedatei führt).

Warum können einige MPEG-TS-Dateien nicht wiedergegeben werden?

Einige MPEG-TS-Dateien enthalten keine Zugriffseinheitentrennzeichen (Access Unit Delimiters, AUDs). Standardmäßig verwendet ExoPlayer AUDs, um Framegrenzen kostengünstig zu erkennen. Ebenso enthalten einige MPEG-TS-Dateien keine IDR-Keyframes. Standardmäßig sind dies die einzigen Keyframes, die von ExoPlayer berücksichtigt werden.

ExoPlayer scheint im Pufferungsstatus festzustecken, wenn er aufgefordert wird, eine MPEG-TS-Datei wiederzugeben, die keine AUDs oder IDR-Keyframes enthält. Wenn Sie solche Dateien wiedergeben müssen, können Sie dies mit FLAG_DETECT_ACCESS_UNITS bzw. FLAG_ALLOW_NON_IDR_KEYFRAMES tun. Diese Flags können für eine DefaultExtractorsFactory mit setTsExtractorFlags oder für eine DefaultHlsExtractorFactory mit dem Konstruktor festgelegt werden. Die Verwendung von FLAG_DETECT_ACCESS_UNITS hat keine Nebenwirkungen, ist aber im Vergleich zur AUD-basierten Erkennung von Framegrenzen rechenintensiv. Die Verwendung von FLAG_ALLOW_NON_IDR_KEYFRAMES kann bei der Wiedergabe einiger MPEG-TS-Dateien zu vorübergehenden visuellen Fehlern zu Beginn der Wiedergabe und unmittelbar nach der Suche führen.

Warum werden in einigen MPEG-TS-Dateien keine Untertitel gefunden?

Einige MPEG-TS-Dateien enthalten CEA-608-Tracks, werden aber nicht in den Container-Metadaten deklariert, sodass ExoPlayer sie nicht erkennen kann. Sie können Untertitel-Tracks manuell angeben, indem Sie der DefaultExtractorsFactory eine Liste der erwarteten Untertitelformate zur Verfügung stellen, einschließlich der Barrierefreiheitskanäle, mit denen sie im MPEG-TS-Stream identifiziert werden können:

Kotlin

val extractorsFactory =
  DefaultExtractorsFactory()
    .setTsSubtitleFormats(
      listOf(
        Format.Builder()
          .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
          .setAccessibilityChannel(accessibilityChannel)
          // Set other subtitle format info, such as language.
          .build()
      )
    )
val player: Player =
  ExoPlayer.Builder(context, DefaultMediaSourceFactory(context, extractorsFactory)).build()

Java

DefaultExtractorsFactory extractorsFactory =
    new DefaultExtractorsFactory()
        .setTsSubtitleFormats(
            ImmutableList.of(
                new Format.Builder()
                    .setSampleMimeType(MimeTypes.APPLICATION_CEA608)
                    .setAccessibilityChannel(accessibilityChannel)
                    // Set other subtitle format info, such as language.
                    .build()));
Player player =
    new ExoPlayer.Builder(context, new DefaultMediaSourceFactory(context, extractorsFactory))
        .build();

Warum werden einige MP4-/FMP4-Dateien falsch wiedergegeben?

Einige MP4-/FMP4-Dateien enthalten Bearbeitungslisten, mit denen die Media-Timeline neu geschrieben wird, indem Listen von Beispielen übersprungen, verschoben oder wiederholt werden. ExoPlayer unterstützt die Anwendung von Bearbeitungslisten teilweise. So können beispielsweise Gruppen von Beispielen ab einem Synchronisationsbeispiel verzögert oder wiederholt werden, aber Audioproben werden nicht abgeschnitten oder Medien für Bearbeitungen, die nicht mit einem Synchronisationsbeispiel beginnen, werden nicht vorab geladen.

Wenn ein Teil der Medien unerwartet fehlt oder wiederholt wird, versuchen Sie, Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS oder FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS festzulegen. Dadurch werden Bearbeitungslisten vom Extractor vollständig ignoriert. Diese können für eine DefaultExtractorsFactory mit setMp4ExtractorFlags oder setFragmentedMp4ExtractorFlags festgelegt werden.

Warum schlagen einige Streams mit dem HTTP-Antwortcode 301 oder 302 fehl?

Die HTTP-Antwortcodes 301 und 302 weisen beide auf eine Weiterleitung hin. Kurze Beschreibungen finden Sie auf Wikipedia. Wenn ExoPlayer eine Anfrage stellt und eine Antwort mit dem Statuscode 301 oder 302 erhält, folgt er normalerweise der Weiterleitung und startet die Wiedergabe wie gewohnt. Der einzige Fall, in dem dies standardmäßig nicht geschieht, sind protokollübergreifende Weiterleitungen. Eine protokollübergreifende Weiterleitung ist eine Weiterleitung von HTTPS zu HTTP oder umgekehrt (oder seltener zwischen einem anderen Protokollpaar). Sie können mit dem Befehlszeilentool wget testen, ob eine URL eine protokollübergreifende Weiterleitung verursacht:

wget "https://yourserver.example.com/test.mp3" 2>&1  | grep Location

Die Ausgabe sollte in etwa so aussehen:

Location: https://secondserver.example.net/test.mp3 [following]
Location: http://thirdserver.example.org/test.mp3 [following]

In diesem Beispiel gibt es zwei Weiterleitungen. Die erste Weiterleitung erfolgt von https://yourserver.example.com/test.mp3 zu https://secondserver.example.net/test.mp3. Beide sind HTTPS, daher handelt es sich nicht um eine protokollübergreifende Weiterleitung. Die zweite Weiterleitung erfolgt von https://secondserver.example.net/test.mp3 zu http://thirdserver.example.org/test.mp3. Hier wird von HTTPS zu HTTP weitergeleitet, daher handelt es sich um eine protokollübergreifende Weiterleitung. ExoPlayer folgt dieser Weiterleitung in der Standardkonfiguration nicht, was bedeutet, dass die Wiedergabe fehlschlägt.

Bei Bedarf können Sie ExoPlayer so konfigurieren, dass protokollübergreifenden Weiterleitungen gefolgt wird wenn Sie DefaultHttpDataSource.Factory-Instanzen in Ihrer Anwendung instanziieren. Informationen zum Auswählen und Konfigurieren des Netzwerk-Stacks hier.

Warum schlagen einige Streams mit „UnrecognizedInputFormatException“ fehl?

Diese Frage bezieht sich auf Wiedergabefehler der folgenden Form:

UnrecognizedInputFormatException: None of the available extractors
(MatroskaExtractor, FragmentedMp4Extractor, ...) could read the stream.

Für diesen Fehler gibt es zwei mögliche Ursachen. Die häufigste Ursache ist, dass Sie versuchen, DASH- (mpd), HLS- (m3u8) oder SmoothStreaming-Inhalte (ism, isml) wiederzugeben, der Player sie aber als progressiven Stream wiederzugeben versucht. Um solche Streams wiederzugeben, müssen Sie vom jeweiligen ExoPlayer-Modul abhängig sein. In Fällen, in denen die Stream-URI nicht mit der Standarddateiendung endet, können Sie auch MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 oder MimeTypes.APPLICATION_SS an setMimeType von MediaItem.Builder übergeben, um den Streamtyp explizit anzugeben.

Die zweite, weniger häufige Ursache ist, dass ExoPlayer das Containerformat der Medien, die Sie wiedergeben möchten, nicht unterstützt. In diesem Fall funktioniert der Fehler wie vorgesehen. Sie können jedoch eine Featureanfrage in unserem Issue Trackereinreichen, einschließlich Details zum Containerformat und einem Teststream. Suchen Sie nach einer vorhandenen Featureanfrage, bevor Sie eine neue einreichen.

Warum funktioniert „setPlaybackParameters“ auf einigen Geräten nicht richtig?

Wenn Sie einen Debug-Build Ihrer App unter Android M und früher ausführen, kann es bei Verwendung der setPlaybackParameters-API zu einer ruckeligen Leistung, hörbaren Artefakten und einer hohen CPU-Auslastung kommen. Das liegt daran, dass eine für diese API wichtige Optimierung für Debug-Builds deaktiviert ist, die unter diesen Android-Versionen ausgeführt werden.

Dieses Problem betrifft nur Debug-Builds. Es betrifft nicht Release-Builds, für die die Optimierung immer aktiviert ist. Daher sollten die Releases, die Sie Endnutzern zur Verfügung stellen, nicht von diesem Problem betroffen sein.

Was bedeuten Fehler vom Typ „Player is accessed on the wrong thread“?

Weitere Informationen finden Sie auf der Seite Erste Schritte im Abschnitt zu Threads.

Wie kann ich den Fehler „Unexpected status line: ICY 200 OK“ beheben?

Dieses Problem kann auftreten, wenn die Serverantwort eine ICY-Statuszeile anstelle einer HTTP-konformen Statuszeile enthält. ICY-Statuszeilen sind veraltet und sollten nicht verwendet werden. Wenn Sie den Server steuern, sollten Sie ihn aktualisieren, um eine HTTP-konforme Antwort zu liefern. Wenn Sie dies nicht tun können, wird das Problem durch die Verwendung der ExoPlayer OkHttp-Bibliothek behoben, da sie ICY Statuszeilen korrekt verarbeiten kann.

Wie kann ich abfragen, ob der wiedergegebene Stream ein Livestream ist?

Sie können die Methode isCurrentWindowLive des Players abfragen. Außerdem können Sie mit isCurrentWindowDynamic prüfen, ob das Fenster dynamisch ist (d. h. sich im Laufe der Zeit noch ändert).

Wie kann ich die Audiowiedergabe fortsetzen, wenn meine App im Hintergrund ausgeführt wird?

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass die Audiowiedergabe fortgesetzt wird, wenn Ihre App im Hintergrund ausgeführt wird:

  1. Sie benötigen einen laufenden Dienst im Vordergrund. Dadurch wird verhindert, dass das System Ihren Prozess beendet, um Ressourcen freizugeben.
  2. Sie müssen eine WifiLock und eine WakeLock halten. Dadurch wird sichergestellt, dass das System das WLAN-Funkgerät und die CPU aktiv hält. Wenn Sie ExoPlayer verwenden, können Sie dies ganz einfach mit setWakeMode tun. Dadurch werden die erforderlichen Sperren automatisch zur richtigen Zeit abgerufen und freigegeben.

Es ist wichtig, dass Sie die Sperren freigeben (wenn Sie setWakeMode nicht verwenden) und den Dienst beenden, sobald keine Audioinhalte mehr wiedergegeben werden.

Warum unterstützt ExoPlayer meine Inhalte, die ExoPlayer Cast-Bibliothek aber nicht?

Möglicherweise ist für die Inhalte, die Sie wiedergeben möchten, CORS nicht aktiviert. Das Cast-Framework erfordert, dass für Inhalte CORS aktiviert ist, damit sie wiedergegeben werden können.

Warum können Inhalte nicht wiedergegeben werden, aber es wird kein Fehler angezeigt?

Möglicherweise unterstützt das Gerät, auf dem Sie die Inhalte wiedergeben, ein bestimmtes Media-Beispielformat nicht. Sie können dies ganz einfach bestätigen, indem Sie Ihrem Player ein EventLogger als Listener hinzufügen und in Logcat nach einer Zeile wie dieser suchen:

[ ] Track:x, id=x, mimeType=mime/type, ... , supported=NO_UNSUPPORTED_TYPE

NO_UNSUPPORTED_TYPE bedeutet, dass das Gerät das durch mimeType angegebene Media-Beispielformat nicht decodieren kann. Informationen zu unterstützten Beispielformaten finden Sie in der Dokumentation zu Android-Media-Formaten. Der Artikel Wie kann ich eine Decodierungsbibliothek laden und für die Wiedergabe verwenden? kann ebenfalls hilfreich sein.

Wie kann ich eine Decodierungsbibliothek laden und für die Wiedergabe verwenden?

  • Bei den meisten Decoder-Bibliotheken sind manuelle Schritte erforderlich, um die Abhängigkeiten auszuchecken und zu erstellen. Folgen Sie daher der Anleitung in der README-Datei für die entsprechende Bibliothek. Für die ExoPlayer FFmpeg-Bibliothek müssen Sie beispielsweise der Anleitung unter libraries/decoder_ffmpeg/README.md folgen und Konfigurationsflags übergeben, um Decoder zu aktivieren für alle Formate, die Sie wiedergeben möchten.
  • Bei Bibliotheken mit nativem Code müssen Sie die richtige Version des Android NDK verwenden, wie in der README-Datei angegeben. Achten Sie auf Fehler, die bei der Konfiguration und Erstellung auftreten. Nachdem Sie die Schritte in der README-Datei ausgeführt haben, sollten im Unterverzeichnis libs des Bibliothekspfads für jede unterstützte Architektur .so-Dateien angezeigt werden.
  • Informationen zum Testen der Wiedergabe mit der Bibliothek in der Demo-App finden Sie unter Gebündelte Decoder aktivieren. In der README-Datei der Bibliothek finden Sie eine Anleitung zur Verwendung der Bibliothek in Ihrer eigenen App.
  • Wenn Sie DefaultRenderersFactory verwenden, sollte in Logcat eine Logzeile auf Informationsebene wie „Loaded FfmpegAudioRenderer“ angezeigt werden, wenn der Decoder geladen wird. Wenn diese fehlt, prüfen Sie, ob die Anwendung eine Abhängigkeit von der Decodierungsbibliothek hat.
  • Wenn in Logcat Logs auf Warnungsebene von LibraryLoader angezeigt werden, ist das Laden der nativen Komponente der Bibliothek fehlgeschlagen. Prüfen Sie in diesem Fall, ob Sie die Schritte in der README-Datei der Bibliothek korrekt ausgeführt haben und ob bei der Ausführung der Anleitung keine Fehler aufgetreten sind.

Wenn Sie weiterhin Probleme mit Decodierungsbibliotheken haben, suchen Sie im Media3 Issue Tracker nach relevanten aktuellen Problemen. Wenn Sie ein neues Problem melden müssen und es sich auf die Erstellung des nativen Teils der Bibliothek bezieht, fügen Sie die vollständige Befehlszeilenausgabe der Ausführung der README-Anleitung bei, damit wir das Problem diagnostizieren können.

Kann ich YouTube-Videos direkt mit ExoPlayer wiedergeben?

Nein, ExoPlayer kann keine Videos von YouTube wiedergeben, z. B. URLs der Form https://www.youtube.com/watch?v=.... Verwenden Sie stattdessen die YouTube iFrame Player API, die offizielle Methode zum Wiedergeben von YouTube-Videos unter Android.

Videowiedergabe ruckelt

Das Gerät kann die Inhalte möglicherweise nicht schnell genug decodieren, wenn beispielsweise die Bitrate oder Auflösung der Inhalte die Möglichkeiten des Geräts übersteigt. Möglicherweise müssen Sie Inhalte mit geringerer Qualität verwenden, um auf solchen Geräten eine gute Leistung zu erzielen.

Wenn die Videowiedergabe auf einem Gerät mit einer Android-Version von Android 6.0 (API-Level 23) bis einschließlich Android 11 (API-Level 30) ruckelt, insbesondere bei der Wiedergabe von DRM-geschützten Inhalten oder Inhalten mit hoher Bildrate, können Sie die asynchrone Pufferwarteschlange aktivieren.

Instabile API-Lint-Fehler

Media3 garantiert binäre Kompatibilität für eine Teilmenge der API-Oberfläche. Die Teile, für die keine binäre Kompatibilität garantiert wird, sind mit @UnstableApi gekennzeichnet. Um diese Unterscheidung deutlich zu machen, wird bei der Verwendung von instabilen API-Symbolen ein Lint-Fehler generiert, es sei denn, sie sind mit @OptIn annotiert.

Die Annotation @UnstableApi sagt nichts über die Qualität oder Leistung einer API aus, sondern nur, dass sie nicht „API-eingefroren“ ist.

Sie haben zwei Möglichkeiten, mit instabilen API-Lint-Fehlern umzugehen:

  • Wechseln Sie zu einer stabilen API, die dasselbe Ergebnis erzielt.
  • Verwenden Sie weiterhin die instabile API und annotieren Sie die Verwendung mit @OptIn, wie weiter unten gezeigt.
Die Annotation @OptIn hinzufügen

Android Studio kann Ihnen helfen, die Annotation hinzuzufügen:

Screenshot: So fügen Sie die Opt-in-Anmerkung hinzu
Abbildung 2: Hinzufügen einer @androidx.annotations.OptIn-Annotation mit Android Studio.

Sie können auch bestimmte Verwendungsstellen manuell annotieren:

Kotlin

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

@OptIn(UnstableApi::class)
fun functionUsingUnstableApi() { ... }

Java

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

@OptIn(markerClass = UnstableApi.class)
private void methodUsingUnstableApis() { ... }

Sie können ganze Pakete aktivieren, indem Sie eine package-info-Datei hinzufügen:

Kotlin

// In your package-info.kt
@OptIn(UnstableApi::class)
package name.of.your.package

import androidx.annotation.OptIn
import androidx.media3.common.util.UnstableApi

Java

// In your package-info.java
@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;

import androidx.annotation.OptIn;
import androidx.media3.common.util.UnstableApi;

Sie können ganze Projekte aktivieren, indem Sie den spezifischen Lint-Fehler in der Datei lint.xml unterdrücken:

 <?xml version="1.0" encoding="utf-8"?>
 <lint>
   <issue id="UnsafeOptInUsageError">
     <option name="opt-in" value="androidx.media3.common.util.UnstableApi" />
   </issue>
 </lint>

Es gibt auch eine kotlin.OptIn-Annotation, die nicht verwendet werden sollte. Es ist wichtig, die Annotation androidx.annotation.OptIn zu verwenden.