Description: After the permission to read files has been revoked (e.g. automatically, as many Android phones do), the app crashes when one attempts to open a file (from a file manager, not from the Viewer application). However, when I open the app directly, I am prompted to grant the application the permission to read files. After that, it is possible to open files from a file manager. Steps to Reproduce: 1. Revoke the application's permission to read files. 2. Click on a file in a file manager. Actual Results: The app opens and then immediately crashes. Expected Results: The app should not crash. Reproducible: Always User Profile Reset: No Additional Info: Tested on Android 7.0.
I should also note that the version I inputted into the report is the only one I tested this bug in, as it is not possible to easily downgrade apps downloaded from Google Play.
Created attachment 197867 [details] app info from Android 14 I can't reproduce on my phone that is currently on Android 14, but somehow it seems not possible to remove the permissions to read files. Version: 24.2.7.2 BuildID: ee3885777aa7 -> https://git.libreoffice.org/core/+log/ee3885777aa7 I tried also to enable the experimental features etc but I can always continue to open files. I also tried to uninstall the app and reinstall it. What I noticed is that if I go on the App info the permissions settings are greyed out and I see the note "No permissions requested", even if I can actually open an .odt stored on the phone.
In Settings on my phone, I see the app has a "Storage" permission (which is the only permission of the app), which I can revoke, as I mentioned in the report.
(In reply to Marina Latini (SUSE) from comment #2) > I can't reproduce on my phone that is currently on Android 14, but somehow > it seems not possible to remove the permissions to read files. Current Android versions generally don't allow direct storage/file access any more, so the permission is simply ignored/not available there. That's fine because the app shouldn't need direct storage access since it's using the standard Android documents provider API since commit a23bd42e9b2f6401c710ac95afcc3aa8f360d65c Author: Michael Weghorn Date: Tue Apr 6 14:26:06 2021 +0200 android: Drop custom file abstraction + UI and (for PDF export): commit 9ebcb80e2e4335fca1e137d015fe4d84631e282a Author: Michael Weghorn Date: Thu Apr 15 11:22:46 2021 +0200 android: Ask where to save PDF file on export (Thinking about it, dropping the permission from the Android manifest might therefore make sense as well.) (In reply to Samo from comment #3) > In Settings on my phone, I see the app has a "Storage" permission (which is > the only permission of the app), which I can revoke, as I mentioned in the > report. The bug description mentions Android 7.0, where storage permission was still handled less strictly. However, even there, my expectation would be that the storage permission shouldn't be needed *if* file managers properly pass the file to the app (using a content:// URL, not a file:// URI). I just tested this in an AVD (Android Virtual Device) running Android 7.0 and had no issue there, even with the permission not granted. I was using "Material Files" [1] as a file manager (the first app showing up when searching for "file manager" in F-Droid, as the AVD doesn't have a stock file manager). What file manager are you using? Does it work with others, e.g. the above-mentioned one? Version: 24.2.7.2 Build ID: ee3885777aa7 Android 7.0 in an x86 AVD [1] https://f-droid.org/en/packages/me.zhanghai.android.files/
(In reply to Michael Weghorn from comment #4) > However, even there, my expectation would be that the > storage permission shouldn't be needed *if* file managers properly pass the > file to the app (using a content:// URL, not a file:// URI). If the crash happens due to a file:// URI being passed without storage permission being granted, that's of course not the ideal response in any case. If that's the cause, potential solutions could be: 1) show a warning if file:// URI gets passed, but file cannot be opened 2) drop handling for file:// URIs altogether, show a warning that another app didn't pass proper URI In line with the security concept on modern Android versions, I'd tend to prefer 2). But it would be good to first know whether that's actually the underlying problem here and it works fine with another file manager or when opening a file from another app, like a messenger or email app.
I use Total Commander. Interestingly, I can always open files using Material Files, exactly as you described. I can also always open downloaded files by clicking the notification Chrome sends me after downloading the file is finished.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Samo from comment #6) > I use Total Commander. Interestingly, I can always open files using Material > Files, exactly as you described. I can also always open downloaded files by > clicking the notification Chrome sends me after downloading the file is > finished. Thanks for the further information. I'll further look into the options mentioned in comment 5 to fix the crash (probably sometime in January). If you intend to continue using Total Commander, I would suggest to contact the developers of that app and ask them to pass data using content:// URIs.
Thank you.