Fix launch commands to work with file provider in next fkodi

[djay]

It looks like to make it work with the file provider API in the upcoming Kodi we can't use extras. There is an example of ppsspp working without it
xbmc/xbmc#24075 (comment)

Not sure if other emulators can be called the same way.
Retroarch needs at least two Params I think but only one needs to use the file provider API.

[zach-morris]

I'll test this once it's merged into an alpha

[djay]

They might be waiting on us to merge it. If an emulator needs the extras for it to work then the current PR isn't sufficient so we should tell them now if that's the case.
I'll work out how to test it manually.

[zach-morris]

IAGL v4 can handle android manually entered commands. I used it to try and get dolphin or ppsspp working (but couldn't because of the file permissions issue, but i was able to get the app to launch without any game). You can use one of the existing commands as the first entry, then update again and select manually entered command and edit it as needed:

[djay]

ok. I've got one to work.

IAGL:  Launching game with StartAndroidActivity:
                                                   {'package': 'org.mupen64plusae.v3.fzurita', 'intent': 'android.intent.action.VIEW', 'dataType': '*/*', 'dataURI': '/storage/emulated/0/Download/IAGL/Nintendo 64/Super Smash Bros. (USA).z64', 'flags': '', 'extras': [], 'action': '', 'category': '', 'className': 'paulscode.android.mupen64plusae.SplashActivity', 'extras_json': '[]'}
 info <general>: StartActivity: Share using FileProvider: content://org.xbmc.kodi.fileprovider/external/Download/IAGL/Nintendo%2064/Super%20Smash%20Bros.%20(USA).z64

Still haven't got PPSSPP to work but at least it proves it works.

[djay]

ok working with PPSSPP.

IAGL:  Launching game with StartAndroidActivity:
                                                   {'package': 'org.ppsspp.ppsspp', 'intent': 'android.intent.action.VIEW', 'dataType': '*/*', 'dataURI': '/storage/emulated/0/Download/IAGL/Sony PlayStation Portable/Daxter (US).iso', 'flags': '', 'extras': [], 'action': '', 'category': 'android.intent.category.DEFAULT', 'className': 'org.ppsspp.ppsspp.PpssppActivity', 'extras_json': '[]'}
    info <general>: StartActivity: Share using FileProvider: content://org.xbmc.kodi.fileprovider/external/Download/IAGL/Sony%20PlayStation%20Portable/Daxter%20(US).iso

One important thing is the storage has to be internal storage rather than an external. it won't warn you about it. It will just fail to recongnise the content as it will be sent without the fileprovider change. so perhaps IAGL needs to put in a warning?

[zach-morris]

Thanks for testing. I'm guessing I'll put in some extra settings and/or notifications to let people know. It seems both ways work depending on the emulator being launched.

[djay]

@zach-morris I guess the question is if there are any commands that absolutely require the shortcut/extras instead of using the dataUri. These won't work and would require a different change to kodi so it would be nice to let them know now if thats the case. I only use a couple of external emulators though.
I tried to get Drastic to work but failed. It did receive the content url but said it can't read it.

[zach-morris]

Retroarch doesn't take datauri as far as i know.
This is the best reference I'm aware of on what emulators require what data for launching:
https://pegasus-frontend.org/tools/metagen-android/

[djay]

@zach-morris thanks. I've passed that on. Duckstation seems to be another. It would be nice to have retroarch work because it would be one less instruction to have to tell people they need to enable "all file" access to make retroarch work.
However I'm not really sure how it's going to work in terms of the kodi api. How will kodi know to convert the rom path and not the core path?

[zach-morris]

Kodi doesn't need to convert any internal paths in the other apps. It wouldn't be able to anyway since it doesn't have permission. The config path and core path are both internal, and while they're currently needed to launch, they don't need to be converted (just known, which they are currently in a very manual process performed by the user).

Even if this non-data uri option can't be accomplished in Kodi, i think it's a good change. It would likely be better for the other emulators to change their manifests to support datauri's since thats the method other apps and frontends have to send files.

[djay]

Kodi doesn't need to convert any internal paths in the other apps.
I know. I'm just saying that kodi wouldn't necessarily know whats internal to the other app and thus shouldn't be converted.

But it would be nice if the ROM path was converted even if it's in the extras. I'm just not sure how kodi would know that without a change in the execute api.

[zach-morris]

Looking at the implementation, i see why it doesn't convert extras. There's no reliable way to know if it's a path that needs sharing since extras are too generalized. It would need another discrete API function like StartAndroidActivity. Something like AndroidGrantUriPermission(activitytosharewith,filename) exposed in python, and then the translatedpath would be passed instead.

This is a pretty specific use case though. I doubt the Kodi developers would want to make such a change just for launcher addons. I think pushing for a change to the emulators androidmanifest is more likely. This is the way it should be done, since new Android OS' restrict passing the filenames in other ways anyway.

It's still possible IAGL can work around this. I'd have to experiment though. I could sent a datauri in addition to the extras. If i can translate the path in python and use that in the extras (generate the same share uri that Kodi does), since the file is already shared, it should work. The emulator would just throw away the datauri value passed since it's unused. Since permission was already granted though, it would in theory still have access to the file.

[djay]

It's still possible IAGL can work around this. I'd have to experiment though. I could sent a datauri in addition to the extras. If i can translate the path in python and use that in the extras (generate the same share uri that Kodi does), since the file is already shared, it should work. The emulator would just throw away the datauri value passed since it's unused. Since permission was already granted though, it would in theory still have access to the file.

Thats pretty clever. The content url generated seems predictable so it should work

[djay]

@zach-morris so they have fixed the problem with external drives. At least those that can be accessed via /storage.

So if you are testing then use this latest build
https://jenkins.kodi.tv/job/BuildMulti-PR/32701/

[djay]

@zach-morris unrelated question about the retroarch launch command. If retroarch on android doesn't let you have the cores anywhere else other than it's internal storage, do you really need to ask the user for the location of teh retroarch config? can there be a simpler setup that just involves assuming the cores and config are in the default place?

[zach-morris]

'Default' is a misnomer. It depends on the system. There are currently 11 different possible default locations for android. Every Android flavor does things differently unfortunately.

It would be an awesome change in the retroarch android just to use the current config file and default core directory. If the user doesn't provide a config, then fallback to the current config. Similarly, if i only provided a core name, then it would load from the default core directory. As far as i know, these are required though:
https://github.com/libretro/RetroArch/blob/master/pkg/android/phoenix-legacy/src/com/retroarch/browser/mainmenu/MainMenuActivity.java#L161