oandbackup
oandbackup copied to clipboard
jensstein
The oandbackup development is still alive?
well, i don't really have much time to work on it at the moment, but i haven't made a conscious decision to abandon the project so i would consider it alive, just resting.
But, why rely on 3rd party when you can release along with source? Many projects provide apk along with latest released tag
@rancidfrog because it's more work and F-Droid is pretty trustworthy and provides lots of stuff like automatic updates.
@strugee More work? I believe it is just a script. Other projects do it automatically with each tag. Or Travis:
- https://gist.github.com/mariotaku/7a0c51955d14def2fa0e
- https://docs.travis-ci.com/user/deployment/releases/
Anyway, just a personal preference. The only issue is that fdroid uses their own key to sign apps. Whereas, devs are able to sign it themselves.
I suggest you to make a PR and see if the author will accept it. Making own builds isn't a bad idea even for F-Droid with raise of Verifiable Builds. But that really would take some effort.
verifiable builds require signing with a different key owned by jensstein/oandbackup. switching to verifiable builds cannot be done after normal builds are published on f-droid without resetting the key, which would be trouble for many. jensstein chose f-droid as his/her release build system, it works perfectly well, no reason to ask for anything else. and btw, f-droid is more trustworthy than any single developer because source tarballs and apks are guaranteed to match. nobody else that i know of provides that level of trustworthiness for android. and how is travis better than f-droid?
@jensstein,
thanks for your work!
i'm having a bit of trouble finding this answer: for which android versions is this app tested and know to work? thank you again!!
If you don't mind my little opinion: Oandbackup is good with many, many versions of Android. Though it's the system -level app and quite sensitive to system staff like busybox, most problems I've seen here are solved already. IMHO
most problems I've seen here are solved already.
well the silent loss of permissions and the loss of symlinks is pretty bad IMHO, enough reason not to use this app for the time being maye. probably hardlinks within an app's data directory are lost too.
Ok, I see https://github.com/jensstein/oandbackup/issues/168 for the second issue. Is there one for the 1st issue?
As @jensstein hasn't been active since his statement that the project is "alive, just resting" and there have already been at least three major forks ( @Andr3Carvalh0, @draplater, @Lonami ). I believe this project would benefit a lot of getting more contributors with commit rights. Otherwise many more forks may arise but not working together and thus come to a standstill earlier or later. That of course requires that some devs are actually interested and finding a common ground for a direction forward. Unfortunately I am not an android dev and don't have time to learn something new right now, but I like this project and would love to see it move forward and I am thus trying to kick of this discussion.
I would appreciate hearing the opinions of the mentioned users and anyone else interested.
I believe this project would benefit a lot of getting more contributors with commit rights.
I believe the issue here is not if there're commit rights or not. I haven't seen any PRs from that guys. And I've checked why: they are doing very different forks that are too different from the initial app design.
I just hope that @jensstein will fix critical issues and maybe improve the app somewhat and also accept PRs with fixes if someone willing to make them.
@imsodin As @ildar also mentions, I do not believe any of the forks are major, as all made some changes to match their needs|desires. None however have made PR upstream, apart from 1 PR for batch uninstallation by lonami. So, not sure they want to work together, unless they have contacted dev and got no reply.
I haven't contacted anyone else, I ported the project to Kotlin and there are some things to fix, but a few other projects stopped me 😅 I may get back to this project, but currently busy.
Thank you for mentioning me. My fork supports real multi-user feature such as backup/restore apps in non-main user. But I just make this for personal use only, maybe there are some compatibility bugs.
and for completeness, @Andr3Carvalh0 has modernized the UI and made some style and naming changes, but no changes to the underlying functionality. i would be great to have a free backup app that just works, but i just don't think i have the time to look into this.
I am sorry, it IS the backup app that just works, having no critical and major issues. But yes, backup app should be even better: rock solid and have no issues up to date. Just IMHO.
it breaks and chokes on links, it resets permissions. all without diagnostics. i have to use a proprietary solution to have any confidence on a backup.
So my plan for this project was only to update the UI and attempting to bring it up to the Material design guidelines. However, since I don't have much free time and I only use this app to do batch backups/restores when I decide to switch roms on my phone. So instead I prefer to give attention to other projects and thats why it seems that this project is also dead on my end. However, I wouldn't mind joining "forces" with @Lonami and @draplater if they wanted to keep supporting this project.
- Links are quite non typical for Android apps, I know none except Termux. So this is the exceptional issue.
- I can't remember the issue of permissions resets, could you please remind?
To everybody:
I'm writing the application manager for Android which will have the backup functionality which will be work on the major verions of Android and will be able to make a backups automaticaly and send it to all known cloud servers. If @jensstein will not mind - I can unload him with their great oandbackup tool.
- Links are quite non typical for Android apps, I know none except Termux. So this is the exceptional issue.
really... but how do you know? i don't.
- I can't remember the issue of permissions resets, could you please remind?
from README.md, describing the process of app restore:
finally, the correct permissions need to be set with chmod. oandbackup does this by setting 771 for all data files although this is probably not the best method. the subdirectory lib/ needs to be excluded from both chown and chmod. on android 6 / marshmallow (api 23) you would also need to use the restorecon command on the data directory (e.g. restorecon -R /data/data/dk.jens.backup) or use another method of restoring the file security contexts.
hi @acuna-personal,
is this app going to be FLOSS? we are only interested in those here.
if i may say so here: i don't think we need a materialized UI for this app (although if Andr3Carvalh0's work is complete and bug free, it is surely welcome), i don't think we need an app manager, or any non-vital complexity whatsoever. we need a backup app that gets updated to newer androids and does one job only and does it flawlessly. bloat and the needless reimplementation of the wheel are counter to this objective. the simpler the better: less bugs and higher chance of being picked up for maintenance when the original dev takes off.
backup is a unique chore: one seldom done, and for which user friendliness, UI/UX, elegance, etc take a complete back seat to correctness (including correctness when run under newer android versions).
the only feature bloat i consider really useful is restoring from a TWRP backup. this could be done by a simple, almost no UI, and inefficient option that takes a TWRP backup and batch-produces app backups for all its content, some of which can later be restored using the usual restore UI. (the TWRP UI could just be two checkboxes for user and system apps.)
@Lanchon , let's discuss real issues, not imaginable.
Termux is real ONE.
Also even all files have 777 or whatever permissions it doesn't hurt until it doesn't hurt. As it's impossible to discuss IN a (Readme) file please file new issue if the permission handling bothers you, let's discuss it there, not here.
@ildar, we disagree on what is a real issue. 777 permissions on private app files is a security hole the size of a planet.
@ildar, i opt out of further discussion with you.
you imagine things ("Links are quite non typical for Android apps, I know none except Termux.") based on zero evidence, then call real issues such as backup failure modes in the presence of links "imagined issues", then try to stifle discussion by others about them ("let's discuss real issues, not imaginable").
"we" in "we disagree on what is a real issue" is of course you and me.
and you can file that bug report yourself if you want it.
i will not participate in further pollution of this thread. good day