Khắc phục sự cố

Khắc phục lỗi "Không cho phép lưu lượng truy cập HTTP qua văn bản thô" các lỗi

Lỗi này sẽ xảy ra nếu ứng dụng của bạn yêu cầu lưu lượng truy cập HTTP qua văn bản thô (tức là http:// thay vì https://) khi Cấu hình bảo mật mạng có không cho phép. Nếu ứng dụng của bạn nhắm đến Android 9 (API cấp 28) trở lên, hãy dùng văn bản thô Lưu lượng truy cập HTTP bị vô hiệu hóa theo cấu hình mặc định.

Nếu ứng dụng của bạn cần xử lý lưu lượng truy cập HTTP qua văn bản thô, thì bạn cần sử dụng Cấu hình bảo mật mạng cho phép việc này. Xem tài liệu về bảo mật mạng để biết thông tin chi tiết. Để bật tất cả lưu lượng truy cập HTTP qua văn bản thô, bạn chỉ cần thêm android:usesCleartextTraffic="true" vào phần tử application trong ứng dụng của bạn AndroidManifest.xml.

Ứng dụng minh hoạ ExoPlayer sử dụng Cấu hình bảo mật mạng mặc định, v.v. không cho phép lưu lượng truy cập HTTP qua văn bản thô. Bạn có thể bật tính năng này theo hướng dẫn ở trên.

Khắc phục lỗi "SSLhandshakeException", "CertPathValidatorException" và "ERR_CERT_AUTHORITY_INVALID" các lỗi

SSLHandshakeException, CertPathValidatorException và ERR_CERT_AUTHORITY_INVALID đều cho biết có vấn đề với SSL của máy chủ chứng chỉ. Những lỗi này không dành riêng cho ExoPlayer. Xem Tài liệu về SSL của Android để biết thêm chi tiết.

Tại sao một số tệp nội dung nghe nhìn không thể tìm kiếm được?

Theo mặc định, ExoPlayer không hỗ trợ tìm kiếm trong nội dung đa phương tiện trong đó phương thức duy nhất để thực hiện thao tác tìm kiếm chính xác là để trình phát quét và lập chỉ mục toàn bộ tệp. ExoPlayer coi các tệp như vậy là không thể tìm kiếm được. Phương tiện truyền thông hiện đại nhất định dạng vùng chứa bao gồm siêu dữ liệu để tìm kiếm (chẳng hạn như chỉ mục mẫu), hãy có thuật toán tìm kiếm được xác định rõ (ví dụ: tìm kiếm phần chia đôi nội suy cho Ogg), hoặc cho biết nội dung có tốc độ bit không đổi. Hoạt động tìm kiếm hiệu quả là có thể và được ExoPlayer hỗ trợ trong những trường hợp này.

Nếu có nhu cầu tìm kiếm nhưng lại không có nội dung nghe nhìn, bạn nên chuyển đổi để sử dụng định dạng vùng chứa thích hợp hơn. Đối với tệp MP3, ADTS và AMR, bạn cũng có thể bật tính năng tìm kiếm với giả định rằng các tệp có hằng số tốc độ bit, như được mô tả tại đây.

Tại sao lại tìm kiếm không chính xác trong một số tệp MP3?

Tệp MP3 có tốc độ bit biến (VBR) về cơ bản không phù hợp với các trường hợp sử dụng cần tua chính xác. Có hai lý do dẫn đến điều này:

  1. Để tìm kiếm chính xác, định dạng vùng chứa sẽ cung cấp lý tưởng ánh xạ thời gian theo byte trong tiêu đề. Việc ánh xạ này cho phép người chơi lập bản đồ được yêu cầu thời gian tua đến lần bù byte tương ứng và bắt đầu yêu cầu, phân tích cú pháp và phát nội dung nghe nhìn từ độ lệch đó. Tiêu đề có sẵn cho chỉ định ánh xạ này trong MP3 (như tiêu đề XING) rất tiếc, thường không chính xác.
  2. Đối với những định dạng vùng chứa không cung cấp ánh xạ thời gian theo byte chính xác (hoặc bất kỳ ánh xạ từng thời điểm đến byte nào), vẫn có thể thực hiện được chính xác tìm kiếm xem vùng chứa có bao gồm dấu thời gian mẫu tuyệt đối trong luồng hay không. Trong trong trường hợp này, người chơi có thể liên kết thời gian tìm kiếm với một phỏng đoán chính xác nhất về độ lệch byte, bắt đầu yêu cầu nội dung nghe nhìn từ độ lệch đó, phân tích cú pháp dấu thời gian mẫu tuyệt đối và thực hiện hiệu quả việc tìm kiếm nhị phân có hướng dẫn vào nội dung đa phương tiện cho đến khi tìm được đúng mẫu. Rất tiếc, MP3 không bao gồm dấu thời gian mẫu tuyệt đối trong luồng, vì vậy, phương pháp này không nhất có thể.

Vì những lý do này, cách duy nhất để thực hiện tìm kiếm chính xác vào tệp VBR MP3 là quét toàn bộ tệp và tạo ánh xạ theo thời gian theo byte theo cách thủ công trong trình phát. Bạn có thể bật chiến lược này bằng cách sử dụng FLAG_ENABLE_INDEX_SEEKING, có thể được đặt trên DefaultExtractorsFactory bằng cách sử dụng setMp3ExtractorFlags. Lưu ý rằng biểu ngữ này không chuyển tỷ lệ tốt đối với các tệp MP3 lớn, đặc biệt nếu người dùng cố gắng tua đến gần cuối luồng sau khi bắt đầu phát. Quá trình này yêu cầu trình phát phải chờ cho đến khi video được tải xuống và lập chỉ mục toàn bộ luồng trước khi thực hiện tìm kiếm. Trong ExoPlayer, chúng tôi đã quyết định tối ưu hoá tốc độ thay vì độ chính xác trong trường hợp này và Do đó, FLAG_ENABLE_INDEX_SEEKING bị tắt theo mặc định.

Nếu điều khiển nội dung nghe nhìn đang phát, bạn nên sử dụng định dạng vùng chứa thích hợp, chẳng hạn như MP4. Không có trường hợp sử dụng nào mà chúng tôi biết trong đó MP3 là lựa chọn tốt nhất cho định dạng nội dung đa phương tiện.

Tại sao tua trong video của tôi bị chậm?

Khi tìm kiếm một vị trí phát mới trong video, trình phát cần thực hiện hai lần những điều sau:

  1. Tải dữ liệu tương ứng với vị trí phát mới vào vùng đệm (điều này có thể không cần thiết nếu dữ liệu này đã được lưu vào vùng đệm).
  2. Xoá bộ giải mã video và bắt đầu giải mã từ khung hình I (khung hình chính) trước vị trí phát mới, do phương pháp mã hoá trong khung hình mà hầu hết video sử dụng định dạng nén. Để đảm bảo lượt tìm kiếm chính xác (tức là quá trình phát bắt đầu chính xác tại vị trí tua), tất cả các khung hình giữa khung chữ I ở trước và vị trí tua cần được giải mã và ngay lập tức đã bị loại bỏ (mà không hiển thị trên màn hình).

Có thể giảm thiểu độ trễ do (1) tạo ra bằng cách tăng thời lượng dữ liệu được trình phát lưu vào bộ đệm trong bộ nhớ hoặc lưu trước dữ liệu vào bộ nhớ đệm vào ổ đĩa.

Có thể giảm thiểu độ trễ do (2) tạo ra bằng cách giảm độ chính xác của lượt tìm kiếm bằng cách sử dụng ExoPlayer.setSeekParameters hoặc mã hoá lại video để có nhiều khung hình I thường xuyên hơn (dẫn đến tệp đầu ra lớn hơn).

Tại sao một số tệp MPEG-TS không phát được?

Một số tệp MPEG-TS không chứa dấu phân cách đơn vị truy cập (AUD). Theo mặc định, ExoPlayer dựa vào AUD để phát hiện ranh giới khung hình với chi phí thấp. Tương tự, một số Tệp MPEG-TS không chứa khung hình chính IDR. Theo mặc định, đây là loại duy nhất khung hình chính được ExoPlayer cân nhắc.

ExoPlayer sẽ có vẻ bị kẹt ở trạng thái lưu vào bộ đệm khi được yêu cầu phát Tệp MPEG-TS thiếu khung hình chính AUD hoặc IDR. Nếu bạn cần phát các tệp đó, bạn có thể thực hiện việc này bằng cách sử dụng FLAG_DETECT_ACCESS_UNITS và FLAG_ALLOW_NON_IDR_KEYFRAMES. Những cờ này có thể được đặt trên DefaultExtractorsFactory sử dụng setTsExtractorFlags hoặc trên DefaultHlsExtractorFactory sử dụng hàm khởi tạo. Việc sử dụng FLAG_DETECT_ACCESS_UNITS không có tác dụng phụ nào khác ngoài việc tốn kém hơn so với khả năng phát hiện ranh giới khung hình dựa trên AUD. Việc sử dụng FLAG_ALLOW_NON_IDR_KEYFRAMES có thể dẫn đến hỏng hình ảnh tạm thời ở bắt đầu phát và ngay sau khi tìm kiếm khi phát một số tệp MPEG-TS.

Tại sao không tìm thấy phụ đề trong một số tệp MPEG-TS?

Một số tệp MPEG-TS bao gồm các bản nhạc CEA-608 nhưng không khai báo chúng trong vùng chứa, vì vậy, ExoPlayer không phát hiện được chúng. Bạn có thể theo cách thủ công chỉ định bất kỳ phụ đề nào bằng cách cung cấp một danh sách cho DefaultExtractorsFactory, bao gồm cả khả năng hỗ trợ tiếp cận các kênh có thể được sử dụng để nhận dạng chúng trong luồng MPEG-TS:

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();

Tại sao một số tệp MP4/FMP4 phát không chính xác?

Một số tệp MP4/FMP4 chứa danh sách chỉnh sửa viết lại dòng thời gian của nội dung đa phương tiện bằng bỏ qua, di chuyển hoặc lặp lại danh sách mẫu. ExoPlayer hỗ trợ một phần để áp dụng danh sách chỉnh sửa. Ví dụ: tính năng này có thể trì hoãn hoặc lặp lại các nhóm mẫu bắt đầu trên một mẫu đồng bộ hoá, nhưng không cắt bớt mẫu âm thanh hoặc chèn nội dung đa phương tiện vào đầu video đối với những nội dung chỉnh sửa không bắt đầu trên mẫu đồng bộ hoá.

Nếu bạn thấy một phần nội dung đa phương tiện đột ngột bị thiếu hoặc lặp lại, hãy thử đặt Mp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS hoặc FragmentedMp4Extractor.FLAG_WORKAROUND_IGNORE_EDIT_LISTS, việc này sẽ khiến trình trích xuất để bỏ qua hoàn toàn danh sách chỉnh sửa. Bạn có thể đặt các báo cáo này trên DefaultExtractorsFactory sử dụng setMp4ExtractorFlags hoặc setFragmentedMp4ExtractorFlags.

Tại sao một số luồng không thành công với mã phản hồi HTTP 301 hoặc 302?

Mã phản hồi HTTP 301 và 302 đều biểu thị lệnh chuyển hướng. Nội dung mô tả ngắn gọn trên Wikipedia. Khi ExoPlayer đưa ra yêu cầu và nhận được phản hồi có mã trạng thái 301 hoặc 302, thường sẽ theo lệnh chuyển hướng và bắt đầu phát như bình thường. Trường hợp mà điều này không xảy ra theo mặc định dành cho chuyển hướng giữa nhiều giao thức. Chuyển hướng giữa nhiều giao thức là phương thức chuyển hướng từ HTTPS sang HTTP hoặc ngược lại (hoặc ít phổ biến hơn là giữa một cặp giao thức). Bạn có thể kiểm tra xem một URL có gây ra lệnh chuyển hướng giữa nhiều giao thức hay không bằng cách sử dụng công cụ dòng lệnh wget như sau:

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

Kết quả đầu ra sẽ có dạng như sau:

Location: https://second.com/test.mp3 [following]
Location: http://third.com/test.mp3 [following]

Trong ví dụ này, có hai lệnh chuyển hướng. Lệnh chuyển hướng đầu tiên từ https://yourserver.com/test.mp3 thành https://second.com/test.mp3. Cả hai đều HTTPS nên đây không phải là lệnh chuyển hướng giữa nhiều giao thức. Lệnh chuyển hướng thứ hai đến từ https://second.com/test.mp3 thành http://third.com/test.mp3. URL này chuyển hướng từ HTTPS sang HTTP và hoạt động chuyển hướng giữa nhiều giao thức cũng vậy. ExoPlayer sẽ không đi theo lệnh chuyển hướng này trong cấu hình mặc định, tức là không phát được.

Nếu cần, bạn có thể định cấu hình ExoPlayer để tuân theo các lệnh chuyển hướng giữa nhiều giao thức khi tạo thực thể DefaultHttpDataSource.Factory dùng trong . Tìm hiểu về cách chọn và định cấu hình bộ phần cứng và phần mềm mạng tại đây.

Tại sao một số luồng không thành công với UnRecognitionInputFormatException?

Câu hỏi này liên quan đến lỗi phát biểu mẫu sau:

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

Có hai nguyên nhân có thể gây ra lỗi này. Nguyên nhân phổ biến nhất là bạn đang cố gắng phát DASH (mpd), HLS (m3u8) hoặc smoothStreaming (ism, isml) nhưng trình phát sẽ cố gắng phát nội dung đó ở dạng luồng tiến bộ. Để chơi những trò chơi này luồng, bạn phải phụ thuộc vào mô-đun ExoPlayer tương ứng. Trong trường hợp URI của luồng không kết thúc bằng đuôi tệp chuẩn, bạn cũng có thể chuyển MimeTypes.APPLICATION_MPD, MimeTypes.APPLICATION_M3U8 hoặc MimeTypes.APPLICATION_SS đến setMimeType trong số MediaItem.Builder để hiển thị rõ ràng chỉ định loại luồng.

Nguyên nhân thứ hai, ít phổ biến hơn, là do ExoPlayer không hỗ trợ vùng chứa của nội dung nghe nhìn mà bạn đang muốn phát. Trong trường hợp này, lỗi hoạt động như dự kiến, tuy nhiên, vui lòng gửi yêu cầu về tính năng đến công cụ theo dõi lỗi, bao gồm các thông tin chi tiết về định dạng vùng chứa và luồng thử nghiệm. Vui lòng tìm kiếm yêu cầu tính năng hiện có trước khi gửi yêu cầu mới.

Tại sao setPlaybackParameters không hoạt động đúng cách trên một số thiết bị?

Khi chạy một bản gỡ lỗi của ứng dụng trên Android M trở xuống, bạn có thể gặp phải tình trạng hiệu suất bị giật, các cấu phần phần mềm âm thanh và mức sử dụng CPU cao khi thông qua API setPlaybackParameters. Lý do là vì tối ưu hoá quan trọng đối với API này bị tắt đối với các bản gỡ lỗi chạy trên các phiên bản Android khác nhau.

Điều quan trọng cần lưu ý là vấn đề này chỉ ảnh hưởng đến các bản gỡ lỗi. Cách này không ảnh hưởng đến bản phát hành mà tính năng tối ưu hoá luôn được bật. Do đó, phương thức bản phát hành bạn cung cấp cho người dùng cuối sẽ không bị ảnh hưởng bởi sự cố này.

Lỗi "Truy cập trình phát trên không đúng luồng" là gì? lỗi có nghĩa là gì?

Hãy xem phần Lưu ý về việc tạo chuỗi trên trang bắt đầu.

Làm cách nào để khắc phục lỗi "Dòng trạng thái không mong muốn: ICY 200 OK"?

Sự cố này có thể xảy ra nếu phản hồi của máy chủ có dòng trạng thái ICY, thay vì một loại tuân thủ HTTP. Các dòng trạng thái ICY không được dùng nữa và không nên sử dụng, vì vậy nếu bạn kiểm soát máy chủ, bạn nên cập nhật máy chủ để cung cấp một phản hồi tương thích với HTTP. Nếu bạn không thể thực hiện việc này thì sử dụng Thư viện ExoPlayer OkHttp sẽ giải quyết vấn đề vì thư viện này có thể xử lý ICY chính xác dòng trạng thái.

Làm cách nào để truy vấn xem sự kiện đang phát có phải là một sự kiện phát trực tiếp hay không?

Bạn có thể truy vấn phương thức isCurrentWindowLive của người chơi. Ngoài ra, bạn có thể kiểm tra isCurrentWindowDynamic để tìm hiểu xem cửa sổ đó có phải là cửa sổ động hay không (tức là vẫn đang cập nhật theo thời gian).

Làm cách nào để tiếp tục phát âm thanh khi ứng dụng của tôi chạy trong nền?

Hãy làm theo các bước sau để đảm bảo ứng dụng của bạn có thể tiếp tục phát âm thanh màu nền:

  1. Bạn cần có một dịch vụ trên nền trước đang chạy. Việc này ngăn chặn hệ thống từ việc dừng quy trình để giải phóng tài nguyên.
  2. Bạn cần giữ một WifiLock và một WakeLock. Những công cụ này đảm bảo rằng giữ cho đài Wi-Fi và CPU luôn bật. Bạn có thể thực hiện việc này dễ dàng nếu sử dụng ExoPlayer bằng cách gọi setWakeMode. Thao tác này sẽ tự động thu thập và giải phóng các khoá bắt buộc vào đúng thời điểm.

Bạn phải thả khoá (nếu không sử dụng setWakeMode) và ngừng dịch vụ ngay khi âm thanh không còn được phát nữa.

Tại sao ExoPlayer hỗ trợ nội dung của tôi nhưng thư viện ExoPlayer Cast thì không?

Có thể nội dung bạn đang cố gắng phát không phải Đã bật CORS (Chia sẻ tài nguyên giữa nhiều nguồn gốc). Khung truyền yêu cầu bật CORS cho nội dung trong để chơi trò chơi đó.

Tại sao nội dung không phát được nhưng không có lỗi xuất hiện?

Có thể thiết bị mà bạn đang phát nội dung không có hỗ trợ một định dạng mẫu nội dung đa phương tiện cụ thể. Bạn có thể dễ dàng xác nhận điều này bằng cách thêm EventLogger với vai trò là trình nghe của người chơi và đang tìm một dòng tương tự như đoạn mã này trong Logcat:

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

NO_UNSUPPORTED_TYPE có nghĩa là thiết bị không thể giải mã nội dung nghe nhìn do mimeType chỉ định. Xem các định dạng nội dung nghe nhìn của Android tài liệu để biết thông tin về các định dạng mẫu được hỗ trợ. Làm cách nào để tải một thư viện giải mã cần tải và sử dụng để phát lại không? cũng có thể hữu ích.

Làm cách nào tôi có thể tải thư viện giải mã để tải và sử dụng để phát lại?

  • Hầu hết các thư viện bộ giải mã đều có các bước thủ công để kiểm tra và xây dựng phần phụ thuộc, vì vậy, đảm bảo bạn đã làm theo các bước trong README cho thư viện liên quan. Ví dụ: đối với thư viện FFmpeg của ExoPlayer, bạn cần thực hiện theo có các hướng dẫn trong thư viện/decoder_ffmpeg/README.md, bao gồm cả việc truyền cờ cấu hình để bật bộ giải mã cho mọi định dạng mà bạn muốn phát.
  • Đối với các thư viện có mã gốc, hãy đảm bảo bạn đang sử dụng đúng phiên bản Android NDK như chỉ định trong tệp README và chú ý xem có bất kỳ xuất hiện trong quá trình định cấu hình và tạo bản dựng. Bạn sẽ thấy .so xuất hiện trong thư mục con libs trong đường dẫn của thư viện cho mỗi tệp cấu trúc được hỗ trợ sau khi làm theo các bước trong tệp README.
  • Để thử tính năng phát bằng thư viện trong ứng dụng minh hoạ, hãy xem bật bộ giải mã đi kèm. Hãy xem phần README cho thư viện của hướng dẫn sử dụng thư viện từ ứng dụng của riêng bạn.
  • Nếu đang sử dụng DefaultRenderersFactory, bạn sẽ thấy cấp thông tin dòng nhật ký như "Đã tải FfmpegAudioRenderer" trong Logcat khi bộ giải mã tải. Nếu thiếu thông tin này, hãy đảm bảo ứng dụng này phụ thuộc vào thư viện giải mã.
  • Nếu bạn thấy nhật ký cấp cảnh báo từ LibraryLoader trong Logcat, điều này chỉ ra rằng việc tải thành phần gốc của thư viện không thành công. Nếu trường hợp này xảy ra, kiểm tra xem bạn đã làm theo đúng các bước trong tệp README của thư viện hay chưa và không gặp lỗi nào khi làm theo hướng dẫn.

Nếu bạn vẫn gặp sự cố khi sử dụng thư viện giải mã, vui lòng kiểm tra Công cụ theo dõi lỗi Media3 để phát hiện mọi vấn đề có liên quan gần đây. Nếu bạn cần gửi một vấn đề mới và vấn đề này liên quan đến việc xây dựng phần gốc của thư viện, vui lòng bao gồm đầu ra dòng lệnh đầy đủ từ việc chạy hướng dẫn README để giúp chúng tôi chẩn đoán vấn đề.

Tôi có thể phát video trên YouTube trực tiếp bằng ExoPlayer không?

Không, ExoPlayer không thể phát video từ YouTube, chẳng hạn như URL của biểu mẫu https://www.youtube.com/watch?v=.... Thay vào đó, bạn nên sử dụng YouTube API Trình phát IFrame, là cách chính thức để phát video YouTube trên Android.

Quá trình phát video bị gián đoạn

Có thể thiết bị đó không giải mã được nội dung đủ nhanh nếu, ví dụ: tốc độ bit hoặc độ phân giải của nội dung vượt quá khả năng của thiết bị. Bạn có thể cần để sử dụng nội dung có chất lượng thấp hơn nhằm đạt được hiệu suất tốt trên các thiết bị như vậy.

Trường hợp bạn đang gặp phải tình trạng video bị giật trên thiết bị chạy phiên bản Android từ Android 6.0 (API cấp 23) tới Android 11 (API cấp 30), đặc biệt khi phát nội dung được bảo vệ bằng DRM hoặc có tốc độ khung hình cao, bạn có thể thử bật hàng đợi bộ đệm không đồng bộ.

Lỗi tìm lỗi mã nguồn API không ổn định

Media3 đảm bảo khả năng tương thích nhị phân cho một nhóm nhỏ nền tảng API. Chiến lược phát hành đĩa đơn những phần không đảm bảo khả năng tương thích nhị phân sẽ được đánh dấu bằng @UnstableApi. Để làm rõ sự khác biệt này, việc sử dụng nguồn không ổn định Các biểu tượng API sẽ báo lỗi tìm lỗi mã nguồn, trừ phi các biểu tượng đó được chú thích bằng @OptIn.

Chú giải @UnstableApi không ngụ ý gì về chất lượng hoặc hiệu suất của API, chỉ có điều là nó không "bị cố định API".

Bạn có hai lựa chọn để xử lý các lỗi tìm lỗi mã nguồn API không ổn định:

  • Chuyển sang sử dụng API ổn định để đạt được kết quả tương tự.
  • Tiếp tục sử dụng API không ổn định và chú thích cách sử dụng bằng @OptIn, như được hiển thị sau.
Thêm chú giải @OptIn

Android Studio có thể giúp bạn thêm chú thích:

Ảnh chụp màn hình: Cách thêm chú thích Optin
Hình 2: Thêm chú thích @androidx.annotations.OptIn bằng Android Studio.

Bạn cũng có thể chú thích các trang web sử dụng cụ thể theo cách thủ công trong Kotlin:

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

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

Trong Java:

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

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

Bạn có thể chọn sử dụng toàn bộ gói bằng cách thêm tệp package-info.java:

@OptIn(markerClass = UnstableApi.class)
package name.of.your.package;

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

Bạn có thể chọn sử dụng cho toàn bộ dự án bằng cách chặn lỗi tìm lỗi mã nguồn cụ thể trong Tệp lint.xml:

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

Ngoài ra, còn có chú giải kotlin.OptIn không nên sử dụng. Bây giờ quan trọng là cần sử dụng chú giải androidx.annotation.OptIn.