Can you post a log of the error, and if possible a minimal test case?

The stacktrace is:

>	[0x5D8095A0] libSDL2.so!Internal_Android_JNI_FileOpen() Line 721	C++
 	[0x5D809CBC] libSDL2.so!Android_JNI_FileOpen() Line 849	C++
 	[0x5D829C14] libSDL2.so!SDL_RWFromFile_REAL() Line 499	C++
 	[0x5D819C94] libSDL2.so!SDL_RWFromFile() Line 386	C++
 	[0x5DA547B8] libmain.so!SDLLoadFile(char const*, unsigned int*)() Line 546	C++

This is just before it goes into the DVM without returning, on:

    inputStream = (*mEnv)->CallObjectMethod(mEnv, assetManager, mid, fileNameJString);

The log doesn't appear to contain anything useful. This is all the output from "Info" level (no warnings or errors between program start and the above call):

04-17 11:52:58.814 21902 21902 I System.out: debugger has settled (1401)
04-17 11:53:00.252 21902 21902 I         : Attempting to load EGL implementation /system/lib/egl/libEGL_tegra_impl
04-17 11:53:02.218 21902 21902 I         : Loaded EGL implementation /system/lib/egl/libEGL_tegra_impl
04-17 11:53:03.110 21902 21902 I         : Loading GLESv2 implementation /system/lib/egl/libGLESv2_tegra_impl
04-17 11:53:03.139 21902 21902 I Choreographer: Skipped 202 frames!  The application may be doing too much work on its main thread.
04-17 11:53:03.141 21902 22001 I SDL     : SDL_Android_Init()
04-17 11:53:03.142 21902 22001 I SDL     : SDL_Android_Init() finished!

I don't have an easy test case, as this is part of a larger codebase. I could go work on a test case if that's the only way. Like I said the input to  this call is a sensible looking path, and SDL_Init() has been called etc.

Thanks! Do you know what happens in other devices (specially if using earlier Android versions)? Which minimum and target API levels are you using to build?

Is the path you feed to the function absolute or relative? I suspect we may be missing a third code path to open files with just fopen (we currently try opening a file via the AssetManager, if that fails we try with InputStream).

Having said that, if the AssetManager hangs when fed a path it does not recognize, that's another workaround we will have to tack onto the seemingly endless list of Android workarounds ;)

So this bug is happening on NDK r9c on Windows (through the Nvidia Tegra Android Development Pack).

I also just now tried on Linux with NDK r9d, which does NOT exhibit the bug on the same Android devices.

In both cases I build with the API set to 18 in all locations.

The path is absolute, since it is prefixed with the result of SDL_AndroidGetInternalStoragePath(), which looks correct. I am not sure if that matters, because I would hope openFP() returns correctly (or throws an exception) upon any unknown file.

Is "don't build on Windows with the r9c NDK" a good recommended fix? :)

I mean, besides adding an additional code path where we try to fopen absolute paths directly first, then go through the other alternatives if that fails, there's not much else we can do...after all, it does seem to hang inside Android internals.

And that wouldn't even be a fix, as it is crashing/halting somewhere inside openFP regardless of whether the file exists or not, and regardless of the path being absolute or relative.

(In reply to Gabriel Jacobo from comment #5)
> I mean, besides adding an additional code path where we try to fopen
> absolute paths directly first, then go through the other alternatives if
> that fails, there's not much else we can do...after all, it does seem to
> hang inside Android internals.

I think it is already implemented this way:
https://hg.libsdl.org/SDL/file/67b9285b0000/src/file/SDL_rwops.c#l469

If it goes into JNI then the file may not exist.

@Philipp, you are correct, I was just wondering if that wasn't implemented somewhere "above" the Android specific code.

So, that means that the file Wouter is trying to open does not exist...it shouldn't hang like that anyway, but it may be outside of SDL's power to fix this (and it's certainly not the first time I've seen those strange hangs inside Android's implementation, though it used to happen with the file seeking code when using SDL_ttf, not while opening a file).

It's not a problem with the file not being present (I think, at least).

SDL_AndroidGetInternalStoragePath() returns "/data/data/org.libsdl.app/files"

I then make that into a path "/data/data/org.libsdl.app/files/myfile.txt" where "myfile.txt" is definitely in the assets directory.

This fails on my Windows setup, and works on Linux with a slightly later SDK.

Also tried directly accessing "myfile.txt" without the path. Fails in the same way. Also tried with a .png to see if there was any difference in behavior with compressed files.. same thing.

Ok, found out that the problem only occurs with the Java debugger attached. If I change the debugger setting from "Java and Native code" to just "Native code", it doesn't halt inside dalvik anymore, and all works fine.

So definitely not an SDL problem. Case closed.

One thing which is an SDL problem is that it will fail on files that have SDL_AndroidGetInternalStoragePath() prefixed, it only works with relative paths.

Marking as invalid.