Open files with "Show in Amaze" option

[seelchen]

Description

When users open an arbitrary file, there is now an option "Show in Amaze". Amaze then tries to find the path of the file and navigate to it.

https://github.com/TeamAmaze/AmazeFileManager/assets/74261221/c45a7e8a-5c04-46dc-a188-719f399983fc

Issue tracker

Fixes #2714

Automatic tests

• [ ] Added test cases

Manual tests

• [x] Done

Devices:

• Pixel 7 emulator running Android 13
• HTC U11 life running Android 10

Build tasks success

Successfully running following tasks on local:

• [x] ./gradlew assembledebug
• [x] ./gradlew spotlessCheck

[seelchen]

This issue was more complicated than I thought. I tried my best, but I am not very satisfied with my implementation.

This PR adds an intent filter for all ACTION_VIEW intents. I could not find a way to restrict it to intents which show files that are on the filesystem, so the "Show in Amaze" option could also be shown for intents that want to view something else than files.

To resolve the URI from the intents I added a new function which tries to find the file path using the ContentProvider. I think that this only works if the URI was constructed with the default ContentProvider. In the other cases, the function tries to guess the path using the URI path, but this only works if the file path is in the URI. When I tested this, the files downloaded from Chrome for example could not be found because the URI only contained the file ID.

[VishnuSanal]

hi @seelchen, the code looks good to me.

I could not find a way to restrict it to intents which show files that are on the filesystem, so the "Show in Amaze" option could also be shown for intents that want to view something else than files.

is this the only issue right now? users selecting "open with amaze" on non-files?

When I tested this, the files downloaded from Chrome for example could not be found because the URI only contained the file ID.

I see that you are handling the issue it gracefully (by giving the heads-up to the user).

if this works in most cases, we will be good to go! but, create issues for the things that don't work after merging.

also, there's a current implementation for the same from AmazeFileUtilities that uses (com.amaze.fileutilities.AFM_LOCATE_FILE_NAME); can you please check whether that can be done along with your implementation?

[seelchen]

Hi @VishnuSanal, unfortunately I currently don't have time to investigate this further. It seems that Android tries to reduce the exposure of file paths when files are shared, so there will probably be no reliable solution for this. I think that my solution is too hacky, so I will close this PR.

[VishnuSanal]

Hi @VishnuSanal, unfortunately I currently don't have time to investigate this further. It seems that Android tries to reduce the exposure of file paths when files are shared, so there will probably be no reliable solution for this. I think that my solution is too hacky, so I will close this PR.

since this PR works well as of now, we'll take it from here. :)