Invalid status(404 OK) on file requests on Android

[AlexanderVagner]

I have a problem, when getting file content an Android. Plugin handles request and return response with incorrect status value (404 OK), when everything is OK. It's because available() method on inputStream returns 0

example path is /_app_content_/com.android.contacts/contacts/1/photo, it is got from cordova-contacts-plugin

[jcesarmobile]

Can you provide a sample app? I can't reproduce.

[alexandruluca]

I have the same problem.
If I list directory contents, the files appears to be there.
Then when I try to load my file in an image using Ionic.WebView.convertFileSrc and load it, I get a 404 (OK), however, the file exists

Ionic.WebView.convertFileSrc("file:///android_asset/www/contents/file-references/29e35425-eb41-4b19-b09e-ad7f2c18336c")

This resolves to

"http://localhost/_app_file_/android_asset/www/contents/file-references/29e35425-eb41-4b19-b09e-ad7f2c18336c"

If I load it in an image, I get a 404 (OK)

[alexandruluca]

It seems it can't read from cordova.file.applicationDirectory, Anywhere else it works as expected

[HarelM]

I have the same issue on android as well:
When doing the following (can be done in the debug browser console):

let path = cordova.file.applicationDirectory + "www/" + relativePath;
path = window.Ionic.WebView.convertFileSrc(path);
fetch(path)

getting error 404.
I was able to retrieve the file when using "http://localhost/" + relativePath which is weird and a terrible workaround...
Any updates on this?

[ghost]

I fought hours with exactly the same issue to finally figure out that paths are case sensitives for the Webview in Android !
For me , "http://localhost/_app_file_/data/user/0/aaa.aaa.aaa/cache/thumbnails/1.jpg" was not working on Android as the real path was "http://localhost/_app_file_/data/user/0/aaa.aaa.aaa/cache/Thumbnails/1.jpg"...
So finally it seems that webview.convertFileSrc( path ) works perfectly for any location inside cordova.file.applicationStorageDirectory.

Hope it will help !

[jcesarmobile]

You don't really need to use convertFileSrc for applicationDirectory files as they are relative.
So file:///android_asset/www/contents/file-references/29e35425-eb41-4b19-b09e-ad7f2c18336c should be contents/file-references/29e35425-eb41-4b19-b09e-ad7f2c18336c.
But maybe we can check if android_asset/www is present in the path to convert and avoid it.

But this looks like a different problem from the OP, so can any of you having problems with applicationDirectory create a new issue?

[alexandruluca]

Thanks. I eventually solved it like you mentioned. In addition to this, I was forced to also pass the file extension so that it can detect the myme-type. Hope this will help someone

[HarelM]

I have created a new issue as was requested by @jcesarmobile: #397
I can't use relative path as it won't work on iOS - so currently there's no way to use the same code in iOS and Android, which is the main use case as far as I understand for convertFileSrc. As I said, I have a working workaround, but I would prefer a proper fix...

[alexandruluca]

@HarelM Why don't you abstract the code in a plugin (I'm doing this), or a service within the app?
Of course... a proper fix is always welcome

[HarelM]

@alexandruluca I did, just wanted to make sure this is a know issue here so it can be tracked and fixed :-)
https://github.com/IsraelHikingMap/Site/blob/78ed95e72f3691aa22acabb726e7e5a7ebac20cd/IsraelHiking.Web/sources/application/services/file.service.ts#L77

[meisterlampe]

Same problem here.
"http://localhost/" + relativePath works as long as I don't use the live reload feature. (Because it uses port 8100?).
Hope this gets fixed soon as it is easy to reproduce.

[Bierat1337]

still not fixed?

[evelas]

<edit-config file="app/src/main/AndroidManifest.xml" mode="merge" target="/manifest/application">
	<application android:requestLegacyExternalStorage="true">
</edit-config>

[Ameer-Jamal]

I was facing a very similar issue with Cordova Media Plugin File Path Compatibility with Android API 33

Problem:

When updating the target and compile version of the app from API 31 to API 33, issues arose with the Cordova Media Plugin. The problem seems to stem from the way file paths are handled in API 33, specifically with the file:// and http://localhost/ prefixes.

Root Cause:

The FileHelper.java utility within the Cordova Media Plugin was not prepared to handle the new http://localhost/ path prefix introduced in API 33. By default, the utility only stripped the file:// prefix, leading to compatibility issues.

Original Implementation in FileHelper.java:

public static String stripFileProtocol(String uriString) {
    if (uriString.startsWith("file://")) {
        return Uri.parse(uriString).getPath();
    }
    return uriString;
}

Proposed Fix:

To address this, I extended the stripFileProtocol method to handle both the file:// and http://localhost/ prefixes:

public static String stripFileProtocol(String uriString) {
    if (uriString.startsWith("file://")) {
        return Uri.parse(uriString).getPath();
    } else if (uriString.startsWith("http://localhost/")) {
        uriString = uriString.replace("http://localhost/", "");
        return Uri.parse(uriString).getPath();
    }
    return uriString;
}

By adding a check for http://localhost/ and subsequently stripping it, we ensure that the path is correctly formatted for file operations on API 33 and above.

Recommendation:

It's advisable for the Cordova Media Plugin maintainers to consider this change or a similar approach to ensure compatibility with Android API 33 and future versions.

I hope this solution aids others facing similar challenges with the Cordova Media Plugin on newer Android API versions. Ensuring seamless path handling is essential for the continued robustness of the plugin. plus this problem was an annoying pain to figure out what was even happening