Audio from source without mime type does not work on Android

Hi guys!

So, I’m trying to make an Audio Player and for the moment if the source is something like: www.example.com/example.mp3 or .wav, it works, but if the source uri is something like this: www.example.com/12345-231235, it works only on iOS. Any ideas of what I can do to solve this?

The error that I get is: “java.lang.IllegalStateException: mSimpleExoPlayer is null!”

pinging @greg here.

What’s the actual URL from your second example? Does it specify a content-type header?

Hi, I’m his colleague. Unfortunately, we cannot give you the link, but we can say that there is no Content-Type header specified. We figured that this may be our problem. Do you have any other thoughts or solutions?

Thanks!

UPDATE: After some tests, on Android we’ve found that cookies don’t send with the request. Is there a possibility to send it manually?

I don’t work on the AV stuff myself, so I’m not positive, but I’d guess that the response from the second URL will need to either specify a content-type header or include an extension on the file it downloads.

@notbrent do you know how to convince Android to send cookies?

We have found that cookies are not sent, so we are waiting for a suggestion or a solution…

@jesse are you familiar with Android cookie issues?

@mihaim19 I’m still confused how missing cookies would call a null pointer with the exoplayer file – can you share what steps you took to arrive at that conclusion?

Hi @mihaim19:

I believe that a stopgap solution should be to fall back to the old Android AV implementation until we can make a fix to the SDK on our end.

In SDK20, we upgraded from MediaPlayer to ExoPlayer on Android as the under-the-hood implementation for AV playback. The MediaPlayer implementation is still available in SDK20 if you pass androidImplementation: 'MediaPlayer' into the initial status of the Sound that you are trying to play (the second argument of Audio.Sound.create() or soundInstance.loadAsync()). I believe that the old implementation should fix the problem for now, but we will work on fixing this bug moving forward in the new Android implementation (since the new Android implementation provides a much better experience across devices anyway, in addition to other desirable features).

Let us know if you encounter any more issues, and we’ll follow up when fixing this issue.

Thanks!

Greg

@dikaiosune Hi! If the user is not authenticated we receive from the server an empty response with a status of 401. The null pointer exception is raised, I believe, because of that empty response body.

@greg Hi! Thank you for your feedback! We arrived on the conclusion that the cookies are not sent by sniffing packets sent to the server (with wireshark). I also tried downloading the file first with the FileSystem api, but the same problem was encountered. If the security is off, both the audio and the FileStystem api work as expected. I will upload later this day an expo app with a server for easier testing of the problem.

Hi @greg:

Thank you for your feedback!
I have passed androidImplementation: 'MediaPlayer' into the initial status, but, as before, soundInstance is null. If the link is public and doesn’t request any session token or anything similar to that, it works, but in our case, it doesn’t. I’m pretty sure the problem is about cookies on Android.

Hello! Here is a simple project demonstrating the problem. https://github.com/LunguIonut007/no-cookies-android-expo
If there is something wrong in the example please announce me.

1 Like

With axios, see withCredentials

“If you have trouble maintaining the user’s session or CSRF protection through fetch requests, please ensure that you’ve read and understood the Sending cookies section. fetch doesn’t send cookies unless you ask it to.”
https://github.com/github/fetch#sending-cookies

This topic was automatically closed after 23 days. New replies are no longer allowed.