nextcloud doesn't know how to open .love files

[nikeinikei]

Actual behaviour

nextcloud cannot open .love files

Expected behaviour

nextcloud should open .love files with the love2d engine
https://play.google.com/store/apps/details?id=org.love2d.android

Steps to reproduce

1. put a .love game into nextcloud
2. try to open it

Environment data

Android version:
7.1

Device model:
ZTE Axon 7

Nextcloud app version:
newest

[AndyScherzinger]

@mario @tobiasKaminsky any opinions on this?
I checked the app's code: https://bitbucket.org/MartinFelis/love-android-sdl2/src/fd60978b7bb57134e232ea2d8f9c77ff7e6483ae/app/src/main/AndroidManifest.xml?at=master&fileviewer=file-view-default#AndroidManifest.xml-35

an we basically would need to have a mime type detection for .love file extension to map to application/x-love-game

[tobiasKaminsky]

Isn't it possible to have a more generic way, e.g. if a mime type is not known, try to pass it to android app launcher and see it this can deal with it? If this is not working show something like "No app found to open .extension".
If we add every extension manually, this could get quite intensive, especially if these are rather unknown ones...

[AndyScherzinger]

I think the mime type is the issue, since we don't know it yet we do pass it to the launcher which doesn't find any app supporting the file since it is mime type based. Thus we would actually have to detect the mime type. In this the love game app could also implement the document provider chooser so it would access the file from within the app itself instead of having to open the Nextcloud client.

[AndyScherzinger]

I also discussed this with @jancborchardt here #2081 (comment) and I do agree (at least for these two issues) to add the mime type detection for these file extensions. As mentioned in the comments of Jan it should then also be added to the server, so looping in @MorrisJobke (hope I got the right person) 😃

[MorrisJobke]

Just open a ticket in server ;)

[tobiasKaminsky]

Instead of using completely our own mimetype list, we can use
https://developer.android.com/reference/android/webkit/MimeTypeMap.html#getMimeTypeFromExtension(java.lang.String)

which uses this database internally:
https://android.googlesource.com/platform/libcore/+/933e699897a15cc61e5641e6365f09f24e22b247/luni/src/main/java/libcore/net/MimeUtils.java

If so, then our "custom" mapping should get a lot smaller.
Downside is that every android release has another set of extensions, so one type can exist on 7, but not on 4...

[tobiasKaminsky]

I searched a bit and https://developer.android.com/training/secure-file-sharing/share-file.html says that the preferred way is to use:
mResultIntent.setDataAndType(fileUri, getContentResolver().getType(fileUri));

But even with installed Löve app, this results in a default "unkown" mimetype.

I would have expect that if an app is registering itself as listener for any kind of new mimetype, that this then would be also know by content resolver.