Hi, I have FP Open OS 18.04 and I still struggle with the rights management concerning SD cards, but not limited to that. I have a problem with Amaze (file manager) and possibly with Vanilla music.
When I go over the settings dialog to the rights that an app has, I see (in the case of Amaze) just “Speicher” (memory). There is a toggle switch, so I can turn in on or off.
Over the three dots I can view “Alle Berechtigungen” (all rights).
There I see two discrete rights: “SD-Karteninhalte ändern oder löschen” (change or delete SD card contents) and “SD-Karteninhalte lesen” (read SD card contents). But there is no toggle switch, so I do NOT know whether they are on or off, and I cannot change their status.
When I tap on them, I simply get something like a one line help text ?!
Also listed, and also unclear, are a couple of WLAN and/or network related rights and “use fingerprint hardware” (?!?).
In Amaze I cannot rename folders on my SD card. And in Vanilla Music / Cover Fetch I have trouble writing cover images to the music folder…
Add’l info: Vanilla Music / Cover Fetch also shows this one right “memory” (currently on) und over all rights is see the two more detailed rights with no toggle switch, so the settings look identical to those of Amaze. Reading files from the SD card is no problem.
Open Camera also cannot write to the SD card (it was set to /storage/emulated/0, but I learned this is not the SD card) When I try to set it to /storage/39FB-0908/Picture I get an error message. It has everything set like Amazae and Vanilla, but one additional entry in ‘all rights’: Record images and videos. That looks 100% identical to the settings of Kamera, and Kamera CAN save photos on the SD card.
Try with this setting enabled:
Open Camera - Settings - More camera controls… - Use Storage Access Framework
" If selected, Open Camera will instead use Android’s Storage Access Framework. This has some advantages, such as using the standard Android file picker, and being the only way to save to SD cards on Android 5 - though it may be slightly slower to take photos. (Requires Android 5.0 or higher.)"
(https://opencamera.sourceforge.io/help.html#settings)
That really opened my eyes. Thanks, dude. Storage Access Framework! Abbreviated: SAF… That is the new Android rights managed controlled way to access storage, that Google claims too many apps do not, or not correctly use…
Yes, now Open Camera runs on the SD card.
Now I understand what Vanilla Music / Cover Fetch tells mt with the error message “nothing selected from SAF file picker, exiting”.
The problem remains: I have to delete Cover Fetch and re-install it, to gain the possibiliy to enter SAF file picker again. There I can go to the SD card, search for the music directory and THEN I can save the cover (folder.jpg) there. Arghhh. I couldn’t think of a more non-intuitive way. Vanilla sees the directory where the music comes from, but is unable to save folder.jpg JUST THERE, the user has to manually navigate there. And even that cannot be simply repeated, for each and every occurence Cover Fetch has to be deleted and re-installed… Oh my goodness. That’s what I call a productivity killer…
I THOUGHT it would work, but something is still wrong. I created a directory for OpenCamera, on the SD card, through SAF. At first, Windows would not see the directory. After separating and reconnecting USB, the OpenCamera directory was there. I took a photo. It went into the folder, Gallery shows it there. And I can see the photo in the folder under Windows. But when I click on it, I get an error because the file has 0 bytes. But it has a decent looking thumbnail. How can a photo of 0 byte have a correct thumbnail? Something is very weird here…
USB connections with Android are managed over MTP/PTP. These protocols rely on the device sending a list of files. Android maintains this list in a database, which can take a while to update (especially if there are a lot of file changes). In some cases the database develops glitches, sometimes a reboot and a bit of patience (for the database to update) solves this. In other cases it can help to reset the database by deleting data for the system app ‘media storage’ (this deletes the database, not the media files themselves). Rebuilding the database takes a while (proportional to the amount of files and metadata stored in them).
For more background on connection modes, this is a nice into.
Thanks. Well, for official Android this would a given fact. But on FP Open OS, is there no way (for the FP Open makers, that is) to simply implement the MUCH more robust mass storage protocol? That is a standard as defined by USB implementers forum, and not a fishy OLD leftover from Canon, patented and locked…