Hi All, I tried to implement the JRDC2 implementation of Erel in one program. The implementation of Erel is in the below URL: https://www.b4x.com/android/forum/threads/b4x-jrdc2-b4j-implementation-of-rdc-remote-database-connector.61801/ I get the following error: ResponseError. Reason...
Apps that run on Android 11 but target Android 10 (API level 29) can still request the requestLegacyExternalStorage attribute. This flag allows apps to temporarily opt out of the changes associated with scoped storage, such as granting access to different directories and different types of media files. After you update your app to target Android 11, the system ignores the requestLegacyExternalStorage flag.
The test app below is using targetSdkVersion="33" and has no issues with the non-https site http://serenewonderfulsoothinglight.neverssl.com/online/ . Are you sure everything is working properly with the site you are trying to access?
same here; no problem with (personal use) app on android 14, sdk 33.
note: it is possible to publish cleartext apps on play. you need a security policy. see this: https://www.b4x.com/android/forum/threads/cleartext-traffic-allowed-for-all-domains.126573/
you just need to set up a file with a list of the non-ssl sites your app uses. a global cleartext policy is not possible
I've attached an updated app of the ClearTextTest with the problem I'm talking about. If you uncomment the https mp3 then it plays it fine. If you uncomment the http mp3 line then it doesn't play and throws an error (MEDIA_ERROR_UNKNOWN, -1015). One change that I made was switching from a paid web host to a free web host.
From some quick "Googling", it looks like a server has to support ranges (Accept-Ranges) and the "HTTP" server that hosts the MP3 file in question does not support ranges.
I've attached an updated example that includes a way to test if a site supports Accept-Ranges
the site does have an accept-ranges header, but the particular mp3 is short and appears to have been obtained with a simple get. there doesn't seem to be much "streaming" involved. does op have another (preferably much longer) example?
So it looks like it is a server-side configuration issue as it pertains to small files on the HTTP server (if it otherwise supports accept-ranges). If you download the mp3's of both sites, they are the same size. The HTTP server does not support accept-ranges for that particular file and the HTTPS one does. My conclusion was that the HTTP server itself does not support accept-ranges, but it could be that it does not support accept-ranges for small(ish) file sizes (or maybe, for some reason, just this file). In the end, not having an accept-ranges in the returned header is why the file from the HTTP server fails to play with MediaPlayerStream.
Thanks to all for your help! I'm assuming at this point that a free web host will not suffice for what I want to do in my app. I've tried quite a few free web hosts and none of them seem to allow insecure mp3 streaming. I assume because of the lack of accept-ranges in the returned header. I was trying to get-away with not paying for a web host or ssl but that doesn't seem possible.
I'm assuming at this point that a free web host will not suffice for what I want to do in my app. I've tried quite a few free web hosts and noce of them seem to allow insecure mp3 streaming. I assumed because of the lack of accep-ranges in the returned header.
This may not work, since the header must also include a correct content-length (the size of the file). Or the server used is not Apache-based. Or .htaccess is not allowed. And many other failure points...