The oandbackup development is still alive?

[micressor]

Thanks for feedback.

[jensstein]

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.

[rancidfrog]

It would be great to have apk also available in release section

[ildar]

Apks available from F-Droid client and website.

[rancidfrog]

But, why rely on 3rd party when you can release along with source? Many projects provide apk along with latest released tag

[strugee]

@rancidfrog because it's more work and F-Droid is pretty trustworthy and provides lots of stuff like automatic updates.

[rancidfrog]

@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.

[ildar]

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.

[Lanchon]

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?

[Lanchon]

@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!!

[ildar]

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

[Lanchon]

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.

[ildar]

Ok, I see https://github.com/jensstein/oandbackup/issues/168 for the second issue. Is there one for the 1st issue?

[imsodin]

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.

[ildar]

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.

[rancidfrog]

@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.

[Lonami]

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.

[draplater]

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.

[Lanchon]

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.

[ildar]

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.

[Lanchon]

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.

[Andr3Carvalh0]

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.

[ildar]

1. Links are quite non typical for Android apps, I know none except Termux. So this is the exceptional issue.
2. I can't remember the issue of permissions resets, could you please remind?

[ointeractive-depot]

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.

[Lanchon]

1. 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.

2. 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.

[Lanchon]

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).

[Lanchon]

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.)

[ildar]

@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.

[Lanchon]

@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]

Issue # please? Emm, "we" is who?

[Lanchon]

@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

[ointeractive-depot]

@Lanchon hello, yep) I don't really want to open its codes, because if it'll be up to date, have a material design and will be popular - I don't want to see its clones in Play Market with tons of advertisment, hope you'll understand. But why it's so important to be open? My apps have my own settings which I set expecially for me, so I don't need to get others backups of its users or another data. And it's simply will work with apps (install/delete it and make its data backups), so there's no any actions which will be dangerous. And finally - I don't really want to have a problems with Play Market on this stage :/

[Lonami]

I don't want to see its clones in Play Market with tons of advertisment

Set a restrictive open source license (like GPLv3) and report the clones you find, if any. I'm sure people would be happy to help out reporting dirty clones. Also, you can publish a dummy package (hidden) so they can't take the official package name from you, if you like.

so there's no any actions which will be dangerous.

Has root access, it could do anything. Who knows?

I don't really want to have a problems with Play Market

What problems are you concerned about?

[ointeractive-depot]

@Lonami Ah, I don't mean clones with the same names, like "AppManager+", "AppManager Extended" etc., I mean an independent apps with other names based on my sources, so it will be impossible to prove the Google that it's my app.

Yes, I know too that GitHub issue tracker is great, I using it hard too, and don't know any more or less normal alternatives, but what you mean about "dummy package (hidden)"? Do you mean a private repos? I'm not sure this repos can have an issue tracker for all users.

What problems are you concerned about?

I'm talking about problems which will be take part with Google if something dangerous activity of some app will be known (and it will be known after a while if it'll take a place).

[ointeractive-depot]

@ildar

Also even all files have 777 or whatever permissions it doesn't hurt until it doesn't hurt.

@Lanchon was right - it's a biggest security hole. It's neccessary to know how do the permissions working. It have three stages for three types of users (mean three levels of security - from regular users to system). This stages are read, write and execute. Every file have different types of permissions for different types of user, eg every user can read and write to the db file (mean some app users can read and write its data), but there's some files which allowed to read (for example) only by this app (called owner) and nobody else, of course not by users. Most of files on the Android creates with it and sets its permissions automatically, for example at first launch. So, 777 is the greatest level of the permissions, which allows to do everything by anybody with this files. And as for me as developer, I don't want that my files would be used by other apps with no any restrictions :/

[Lonami]

dummy package

I meant you can upload your fork to Google Play with a certain package name (say foo.bar) so that people can't use it, but if you're against Google Play, you can just "reserve" the package name like that (so nobody else can) but not make the application public. Source would still be on GitHub or wherever public for anyone, sure. And Google does take applications down if you request them so (has happened to me, and my application wasn't even on their store).

[ildar]

Also even all files have 777 or whatever permissions it doesn't hurt until it doesn't hurt.

It doesn't hurt because:

all those "unprotected" files are covered on top by the 700 directory: /data/data/$package_id

And I leave aside SELinux additional level of protection.

[Lanchon]

@acuna-personal,

i'm very sad to hear that your app will not be free software. i will absolutely never use your app.

why is freedom important? https://www.gnu.org/philosophy/philosophy.html

we are discussing a free software backup app here. this is NOT a place to push proprietary software, this action is akin to spamming. if this was my project, i would delete your messages from this github issue.

those users willing to run non-free software are perfectly capable of using Titanium Backup today, and don't need to wait for what would most likely end up being an inferior product (except for the fact that it might cost less - even nothing).

good luck with your endeavor.

[micressor]

Can we please stop this discussion here? This is a bug reporting tool!

@jensstein May you add a project status to the README.md file and close this issue?

[ointeractive-depot]

@Lanchon well, if you ready to spend >1 year to the development and ready to see any apps based ony your code - it's your choise. But I see, that most of GNU apps now are dead and/or remain in 2012 with clumsy UI like Titanium Backup. I think there's matter in some kind of profit and motivation as a result of, so I'm not sure I'll psychologically can be more efficient than an more known apps developers and support it with all new appear versions of Android. They throw it after a while on althruism, so I'm afraid I can throw it like them. I think so.

[ointeractive-depot]

@ildar unfortunately no, you can write to any higher folder if it have 777 permissions, even its antestor folders have 770.

[ointeractive-depot]

@ildar I see a notification om my e-mail, but can't see your answer there, so strange... I don't know why. It's bad form to write not in English so that users can't understand what we're talking about, so seems that we must write in English... So, as for permissions - I've tested it before writing my last comment for not to discredit me as a developer)) You forgot that oanbackup unzip all backups with 777 permissions, so after that you'll get access to the all files, for example, it's possible to edit any file in /data/data/$package_id from ANY app, not only owner, because all of /data/data folders have a 751 permissions, not 700.

[jensstein]

where do you see that oandbackup sets file permissions as 777? ShellCommands.java sets permissions for various files to 0771, 755 and 644. git grep 777 $(git rev-list --all -- src/) -- src/ yields nothing. if you experience that oandbackup sets permissions as 777 then please report it as a bug.

[Lanchon]

please see https://github.com/jensstein/oandbackup/issues/180#issuecomment-356460454 for the root of the permissions issue.

[acuna-public]

@jensstein I'm so sorry for forget to answer you. Okay, I want to believe, but how ShellCommands.java knows which perms needed to any file which was holded before its backup? I thought I must be stored somewere behind.

[Lalarian]

Titanium is a non working piece of crap. I own the Pro version for years, an batch restore never worked.

[ointeractive-depot]

@Lalarian ahahaha, awesome!)

[godfuture]

Hi thread, I am from the future, and you know what? This thing is a zombie. Your hope was for nothing...

[Lanchon]

i dont care!!! just tell me the next powerball!

[acuna-public]

@godfuture I've released an app which can make a backups like oandbackup: https://play.google.com/store/apps/details?id=pro.fapman Need root too.

[haja]

@acuna-public thanks for the effort, but is it on f-droid though?