[Bug]: RetroArch launch fails (black screen) on non-default user profiles due to hardcoded user ID paths in cocoon_db and launcher URI expansion

[f1nlay]

Cocoon version

Beta 3.06

Device and Android version

AYN Thor, Android 13

What does this relate to?

Crash or freeze, Emulator or game launching

What happened?

When running Cocoon within a non-default user profile (e.g., a work profile created via Shelter or native Android multi-user features), attempting to launch games through RetroArch fails, resulting in a black screen.

This issue is critical and severely limits Cocoon's usability for multi-user setups.

From what I can tell, the issue appears to be two-fold:

1. The default launcher arguments stored in the amStartArguments column of the players table in cocoon_db explicitly hardcode the default user profile ID (0) across multiple path arguments (e.g., -e CONFIGFILE, -e SDCARD, -e EXTERNAL).

2. Manually patching cocoon_db to replace /storage/emulated/0/ with the correct profile path (e.g., /storage/emulated/10/) does not resolve the issue. Cocoon’s launcher code appears to internally resolve/expand {file.path} from SAF-formatted URIs directly into /storage/emulated/0/ at launch time regardless of the active profile context.

Cocoon should dynamically detect the current Android user ID at runtime, replacing both template variables in amStartArguments and SAF path resolutions with the active profile's storage directory (perhaps using something like /storage/emulated/{user_id}/).

Steps to reproduce

1. Set up a secondary user profile (e.g., using Shelter on AYN Thor).

2. Install Cocoon into the secondary profile and set up a player (e.g., RetroArch).

3. Attempt to launch a game using RetroArch.

4. Observe that RetroArch launches to a black screen and fails to respond.

How often does it happen?

The issue occurs every time a secondary user profile attempts to launch a game through Cocoon that uses the RetroArch emulator.

Additional context

• The same bug is currently present in iiSU, though in that case it can be resolved through modification of emuladores.json: RetroArch launch fails (black screen) for non-default user profiles due to hardcoded user ID in CONFIGFILE path iisu-network/iiSU#432

• This issue was previously reported a few months ago by a different user on https://feedback.cocoon-shell.com/p/launching-games-using-retro-arch-doesn-t-work-for-android-secondary-users.

• Additionally, there appear to be separate issues with themes loading incorrectly on external profiles that require further investigation.

Before submitting

• I searched existing discussions and did not find this problem already reported.
• I have not included passwords, personal information, or other sensitive data.

[DaniPhii]

Hi @f1nlay, thanks for reporting this here, I found out that my original report doesn't exist anymore.

I've been using Daijishō as a fallback, but it would be great to have this fixed in Cocoon Shell.

[f1nlay]

As this bug has been bothering me a bit, I've whipped up a patcher which fixes this issue by decompiling the APK and replacing the hard-coded paths with the correct, user-scoped paths: https://github.com/f1nlay/cocoonfe-multiuser.

You can patch it yourself, or download a prebuilt APK from: https://github.com/f1nlay/cocoonfe-multiuser/releases

Note that this is just a quick prototype and as such, the code is heavily AI assisted. Ideally this should still be fixed upstream with much better, human-written code. I've been testing it on my device and haven't noticed any issues thus far, but please beware that this may be unstable and that you should absolutely back up your existing Cocoon data using the settings menu before installing the patched APK.

(Paging @DaniPhii as you may be interested in testing)

[mistiryshak]

I'm not in the interest of sparking any drama but this feels like a bit of a speculative read as I don't quite get the same impression from inssekt's prior comments. Maybe I'm wrong, but I'm just trying to help people out here and don't have any ill intentions.

To be clear, I'm also not trying to spark any drama or claiming that you have ill intentions and am more so trying to make you aware that this could be seen as malicious or unhelpful by Cocoon's developers.

For a practical example, people that download this APK may come to them with bugs that cannot be reproduced because they only exist in this patch and cause frustration for the team. Releasing the modified APK to the public even with warnings can have side-effects that you may not have foreseen such as this, as many general users will be unable to distinguish between errors that came from the patch and errors inherent to Cocoon. Ergo, for such things I am generally of the belief that they should remain private.

I thought publishing a prebuilt APK should be alright too as it's essentially the same as the one already published in this repo, just with the patches applied.

It's generally a faux pas to duplicate a closed-source project, even for a tiny modification. It's not very common in the software world and when it happens it usually involves lawyers, either for takedowns or for discussing the terms and conditions the editor will have to follow when modifying the project. It's very much so a legal process as closed-source projects are protected by copyright.

[f1nlay]

For a practical example, people that download this APK may come to them with bugs that cannot be reproduced because they only exist in this patch and cause frustration for the team. Releasing the modified APK to the public even with warnings can have side-effects that you may not have foreseen such as this, as many general users will be unable to distinguish between errors that came from the patch and errors inherent to Cocoon. Ergo, for such things I am generally of the belief that they should remain private.

I would generally agree with that concern, but I think the circumstances here make it considerably less likely. The only people likely to encounter this issue in the first place are those with at least some degree of technical knowledge. Running Cocoon in a multi-user Android setup is already a fairly niche use case, and someone would presumably only come across this workaround after discovering that Cocoon does not work correctly in that setup by default.

So while I understand the concern in principle, I don't think it presents much of a practical risk for this particular issue.

It's generally a faux pas to duplicate a closed-source project, even for a tiny modification.

I did consider whether including a prebuilt APK was appropriate, but I wasn't convinced that it materially changed anything in this situation. There's no attempt to pass the app off as my own or anything like that, it's simply a very small bug fix intended as a temporary workaround for people affected by a specific issue.

The reason for providing the APK is just convenience: without it, anyone affected would have to patch and rebuild the APK themselves. I can understand being cautious about redistribution of closed source software in general, but I think equating this with duplicating or republishing the project itself overstates what is actually being done here!

[inssekt]

I'm not too bothered. We have this in our backlog to complete ourselves for next public release. I would recommend removing the distribution though just to be fair to us and to avoid confusion, but this will be fixed on our behalf soon.

[mistiryshak]

Understood. In that case, my apologies for making assumptions about your thoughts and apologies to @f1nlay for any trouble or inconvenience.

[inssekt]

Don't worry :)) All is good with everyone. Thanks for taking the time to discuss and suggest things !