@aircookie
I remember the OTA update problem with v0.12.0 very well - I experienced the difficulty for myself. When reporting the current issue, I wondered whether it was indeed similar to the earlier OTA issue. It seems that it probably is!
I do not think it is appropriate to use accept= to restrict the uploadable file types. This is forcing Android to treat them as special files, when in fact they are just data objects which should simply be copied from one device to another. The Android device does not need to understand the content of the file, just copy the whole file as required.
This is an Android app running on an Android device. I don’t understand how implementing a “workaround” to make the Android app function correctly makes it less usable for everyone. How does Windows affect the Android app, and who exactly is “everyone”?
@blazoncek
If I use my browser to visit [IP address]/edit, I can use the ESP Editor to download cfg.json and presets.json. I am initially offered the [Main Storage]/Dowload folder as the destination, but I can select my SD card as an alternative destination, copying the files to [SD Card]/Download instead. I can see no reason why the Android app should not be able to offer the same choice of destinations, which are perfectly adequate for this operation.
When I come to choose a file to upload, I am given a choice of several apps, including “Files”. I can use this option to choose a file from almost anywhere on the current device, as well as Google Drive, Microsoft OneDrive, or I can select one of the other applications installed on the device, which gives me access to all the other devices on my network. Again, I believe that the same facility should be available to the Android app.
I am surprised by your assertion that I do not have access to the file system. I have more than adequate access to the files on my Android devices. As I have already said above, these files are simply data objects to be copied from one device to another. As far as the Android device is concerned, they should not be treated as CSS, JSON or any other file type, and they should not be placed “where CSS files on my Smartphone are”. The WLED files have nothing to do with Android OS and so I don’t want to put them anywhere within the internal workings of the Android file structure. I can see no good reason why you would want to do so.
While I understand that you do not accept that this is a bug in WLED, when an ordinary user clicks on a button in the reasonable expectation that it will back up the presets, and it doesn’t work, then that LOOKS like a bug to that user…