search

mwarning / trigger

Android app to lock/unlock/ring doors. Supports generic HTTPS/SSH/Bluetooth/MQTT and Nuki Smartlock.
GNU General Public License v3.0
134 stars 22 forks source link

Android 11 file selection fails #51

Closed StickyDigit closed 3 years ago

StickyDigit commented 3 years ago

Most file handling appears b0rked in Android 11.

Exporting a config fails with:

Error
java.io.IOException: Operation not permitted

(Files permissions are granted)

Importing images shows no files in a folder with several jpegs that were importable in previous versions.

I expect importing config would fail too. I'll check with an export from an older droid later.

Thanks for this fantastic tool!

mwarning commented 3 years ago

This is probably a problem with the file picker library...

mwarning commented 3 years ago

Android 11 changed the file access API. I cannot find a file picker that supports Android 11 yet.

StickyDigit commented 3 years ago

I'm not an android dev as such, so may be barking up the wrong tree, but can you not invoke the system file picker?

mwarning commented 3 years ago

I did not know that the system file picker can select directories. Looking it up again, it might work. I will give it a try.

StickyDigit commented 3 years ago

This maybe? https://developer.android.com/training/data-storage/shared/documents-files

StickyDigit commented 3 years ago

This is more of a feature/enhancement request, so don't let it stop you closing the issue once fixed. It could potentially be transferred to an issue 'config bloat causes slow startup'

While you're massaging the file handling, I'll plant a seed of an idea. Perhaps images should be copied as files to shared_prefs rather than base64 (or whatever) in the prefs file. i have four images, jpeg, totalling about 200k bytes, which makes for a 2.7 MiB config that takes a fair few seconds to unpack at startup. The images in my case are used three times in the config, for similar 'doors'. If I had a few dozen 'doors', then the config would be tens of megabytes, and the images would probably only show after my coffee got cold.

Of course simply using unique filenames if copying would cause three copies of each file to be stored in my case, though that could be partly avoided while improving user experience if the user were presented with a simple gallery of already copied images as first choice, and a button for 'add another' invoking a file picker on the last directory files got picked from. Perhaps even having an option to make a stored image the default for e.g. 'close', allowing standard doors to require no image picking step, and still allowing isome individual doors to be trivially customised.

This would be storage efficient, and quicker when doing multiple doors with the same custom graphics. Filename clashes can be avoided by abstracting the filenames when copied to shared_prefs using UUID or even sequential numbers as names. The 'gallery' view would show the original filename, and the routines handling it would work with the abstracted filename of course.

When pulling the images in at startup, a simple "sort | uniq" method could allow the app to only pull in each image once, regardless how many doors use it.

Else... informing the user that files must be left where they're picked from and not bothering to copy them would work too, but relies on user brains. Personally I'd be happy with that, as I put the images in a folder called trigger on my /storage/emulated/0 and leave them there. Many users are not FS aware, so a static copy in shared_prefs remains the preferred option IMHO.

It's the sort of thing you see a lot of in apps that parse images in any way, so I'd hope the libraries lend themselves to this.

Hit me over the head with a wet fish if my Bash oriented brain is going silly places :^|

mwarning commented 3 years ago

You see there is a lot that can be done to improve this app. But as a hobby project, changes are coming with a very slow pace, if it all.

My usual response would be to make a merge request (and maybe some communication it advance).

StickyDigit commented 3 years ago

Understood. If you get the FS basics fixed, I'll see if I can't have a go at the image file thing myself. It's about time I had a deeper tinker with android devving.

mwarning commented 3 years ago

I will try. :-)

mwarning commented 3 years ago

I've switched the code to the Android Access Framework. It should work on Android 11 as well.

StickyDigit commented 3 years ago

The file selection works fine in the newest F-Droid build. New and existing ssh doors fail though. Will open a fresh issue for that.