Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add workaround for resource/folder when ACTION_VIEW fails while pointing to downloads directory #604

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

Sir-Photch
Copy link
Contributor

@Sir-Photch Sir-Photch commented Nov 1, 2023

This is probably specific to grapheneos, but it still fixes works around an edge case of a long-standing bug that causes nothing to happen when a SavableSearchable result that is a directory is launched.

This happens because by default, apparently no app implements Intent.ACTION_VIEW for mime-type resource/folder on grapheneos, even though the default file browser (com.android.documentsui) is available.

In that case, just open com.android.documentsui directly with the given uri.
If the uri happens to be the download folder, call com.android.documentsui with ViewDownloadsActivity.

Also, this fixes a possible issue where the launchcount is incremented even though launching fails.

@Sir-Photch Sir-Photch marked this pull request as draft November 1, 2023 21:05
@Sir-Photch
Copy link
Contributor Author

Sir-Photch commented Nov 1, 2023

Okay, seems like com.android.documentsui can't open arbitrary directories. But it has it's own activity for viewing downloads; It's probably sensible to keep that?

@Sir-Photch Sir-Photch marked this pull request as ready for review November 1, 2023 22:04
@Sir-Photch Sir-Photch changed the title add workaround for resource/folder mime types when view activity fails Add workaround for resource/folder when ACTION_VIEW fails while pointing to downloads directory Nov 1, 2023
@MM2-0
Copy link
Owner

MM2-0 commented Nov 1, 2023

Okay, seems like com.android.documentsui can't open arbitrary directories. But it has it's own activity for viewing downloads; It's probably sensible to keep that?

Yes, IIRC I have tried that before and it didn't work. Hardcoding downloads (and other paths that can be opened by intent) would make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants