No, Android is complicated due to the filesystem abstraction (storage access framework, legacy file access etc). Android added a full layer on top of the filesystem to track who has created a file, who has permission to access it etc. It’s totally possible that a file is created using legacy methods, then accessed using SAF and you get a 0 KB file.
Some “system” file managers get more access, same for accessing from a computer via USB. The download directory is often a public, shared directory. Otherwise apps have their private user storage area where they can create files and the user can read them, but no other apps (and 3rd party file managers are just apps). Except if you use legacy file access etc. It’s complicated.
That said I’ve used ZFlasher to read from the MCU without problems. After all it’s just avrdude with a wrapper around it.
Possible. Just read out flash its 12.6Kb. Phone old Samsung S5; Android 11; Lineage 18.1 OS. But yea, Zflasher asked for permision to use OTG… but Pixel6a and Android 14 cant see OTG connected programmer “programmer not found”;(
Interesting. I know Android, and specially its newer versions, significantly restrict the directories apps can access, but I didn’t know these restrictions made it possible for an app to be allowed to create a file and then be denied (with the file already open in O_CREAT mode) to write to it, as it makes no sense, and specially from a security standpoint would allow a hostile app to bring down the system anyway via filesystem inode depletion.
But I’m not really deep into Android internals and you seem to know what you’re talking about, so I will defer to you on this.
ZFlasher uses read and write. Write is ok but read not. It’s ridiculous. If read it can be used for backup a file you have to give the permission for use it.
Otherwise it’s useless.
Also how many pogo pin I have to buy?
BOSS flashlight are programmed by a monitor and a buzzing color. It’s more simple. Yes I know is a bit different but is cool.
Please note that me and @SammysHP were commenting on this as seen from the app-to-filesystem perspective, while you seem to be commenting from the app-to-USB perspective, so what he and I called “write” (from the app to the filesystem) is for you “read” (from the USB to the app, which then the app writes to the filesystem), and the same (only inverted) for “read”.
It’s ridiculous.
Agreed. Google has been making a lot of bad decisions on Android lately.
I caution people from jumping to the conclusion that Zflasher does not work to create a backup.
Only one person, roostre, has reported that issue. I dont know why he had the problem.
There has been no confirmation from a second source that Zflasher does not work to create a backup.
So jumping to the conclusion that Zflasher always has a problem creating a backup is imo, premature, and has not been confirmed.
IF the issue is universal, we should be seeing confirmation from additional users. I have not seen any indication that all attempts to make a backup w Zflasher will fail.
I invite anyone w an Android to share their experience and results, when using Zflasher to create a backup of the stock firmware.
Please confirm if it is not possible to restore the backup to the light, when using Zflasher.
I only tried ZFlasher once (to see what the buzz was all about) and had the other issue (“programmer not found”), the same that @Quadrupelhas already reported.
That was on my Xiaomi running LineageOS 20 (AOSP 13 derivative) – didn’t go any deeper to try and diagnose/resolve the issue as I don’t plan on using a phone for flashing anyway.
Yeah, I’m pretty sure ZFlasher works almost all the time. And when it fails I think it’s more probably something on the phone’s side (OTG implementation and/or Android permissions and whatever) and not direct a ZFlasher failure.
I guess everybody interested in ZFlasher should just try it, but paying attention that if you get a zero-sized file after a “Read” operation when trying to make a backup of your flash/eeprom contents, be very aware that it in fact has silently failed and then that file is obviously no backup at all.
fwiw, we already know that Zflasher works to install a hex file. If for some reason Zflasher does not work to make a backup, it is still possible to access original hex files from the repositories. So in that sense, backing up the light is not the only option to restore stock firmware.
I assume Zflasher works correctly since no one else has reported any issues.
My issue may be due to an unanticipated interaction between the Zflasher App and the particulars for the Android version Samsung is using on my tablet.
I only use this Android tablet occasionally every few months to flash a new firmware version from a trusted repository and it does take a while to start up while it updates the software, so hopefully at some point everything will fix itself.