Adding shortcuts to home screen doesn't work

[pazos]

Originally Posted by chaley

Well, file URIs didn't work in CC when I tried changing the target release, using the Android emulator(s) in Android Studio and on my OnePlus phone. It could be that Huawei took out the restriction.

Just an update related to pass files to other activities with targetSdk >= 24. It turned out that is something enforced by the default VM policy. in core/java/android/os/StrictMode.java.

While it isn't nice to use StrictMode on production we can override VM policies and get rid of the DeathOnFileUriExposure penalty, just by using the following code on a application subclass (or the kotlin equivalent):

StrictMode.setVmPolicy((new StrictMode.VmPolicy.Builder()).build())

As you can see this approach still works on Android Q and works on every phone/vendor I tried.

Originally Posted by chaley

Another complication is that when using the SAF (Storage Access Framework), it is *very hard* to get a real file path. I used a hack that requires reaching into the kernel to get the mount names. I found on some devices the hack doesn't work. I don't know whether my hack will work if targeting V9 or V10. Unfortunately one must use the SAF when accessing SD card. The Android 10 "Scoped Access" documents imply (strongly) that the SAF will be needed for all storage, not just SD cards. If the hack for getting a file path doesn't work then the app must use Android's SAF content provider. The resulting URI can be handed unchanged to other apps.

If the hack is related to reading /proc/self/fd that still works if the content shared is really a local file (and not a socket or whatever). About SAF: it is a pain in the ass and this is going to be enforced by SELinux, so no workaround is possible.

I help in the android port of koreader, which uses generic filesystem api across all platforms, and the future for us is to stick in the places where fs api still work and import content there using SAF. As ko is a document viewer we don't share files with other activities but we will need to remove intent filters for handling action.VIEW because even when the uri has a file scheme we won't have permissions to read from that path. There's a work in progress Pull Request

Originally Posted by chaley

At this point the problem belongs to Sam & Co. I don't know what they plan to do. I do know that I am (happily) not in the loop.

It was not my intention to bring you in the loop again. Enjoy your holidays outside the android platform mess

ps: if Sam is reading this: feel free to pick the workaround and apply it in production. You're not alone: Moonreader and most vendor file managers are still doing this.

[pazos]

A quick update: I just uploaded a sample activity that showcases how to workaround the two issues mentioned on this thread. As chaley said this won't work as intended if scoped storage is enforced, but should allow to still use android apps built with latest api level (29) using the good old "everything is a file" paradigm.

The repo: https://github.com/pazos/filesResolver

Feel free to use for whatever you want.