[Feature Request] Allow backing up only app data by default

[larena1]

Is your feature request related to a problem? Please describe it. A clear and concise description of what the problem is.

Describe the primary solution Currently, when backing up an app, APK and Data will always be preselected at minimum. Coming from Titanium Backup, it'd be great if there was a setting to only backup app data. The app itself will be restored from Google Play anyway if used and backups will take less space and time this way.

Describe alternative solutions, if any A clear and concise description of any alternative solutions or features you've considered.

Screenshots If you're willing to add demonstrative screenshots, you're welcome to do so.

System Information (please complete the following information):

• Device:
• Android Version:
• ROM: (AOSP, MIUI, OOS...)
• App Version:

[MrEngineerMind]

The potential problem of just backing up data is that your data backup could get out of sync with the version of the app in the play store, so if you then try to restore data for an older apk with the newer version of the app from the play store, it may not work.

By backing up the data and it's matched APK, you can be assured the restore will work. Then you can gracefully update the APK to the latest version in the play store and the data will migrate as designed by the app developer.

[larena1]

Not quite sure where the difference is. When I restore the old app and its data and then install the newest version from the Play Store, the new version of the app from the Play Store will still have to read the old data and if needed, migrate it. That's basically the same as installing the most recent version and restore the old data.

[machiav3lli]

You can already use the batch backup tab or a schedule to do this

[hg42]

it's an interesting discussion...

At this point, I'm not aware of a documentation about what exactly happens when installing an app and I didn't explicitely search for it. Actually, I didn't feel like I need this information, yet.

My general way to handle this, is trying to restore everything to the state it was before the backup as exactly as I can. Well, I also experiment with other ways sometimes, if something isn't ideal or because of lazyness. But I always try to have a backup that is complete. A similar topic is bycking up system apks, while I never restore them (but there might be a case in future...or actually I already did, e.g. downgrading a Webview, that didn't work in the new version).

Some points to consider:

• is there a method for an app to define that any code (including scripts) can be run on installation?
• does it know of the update condition?
• does the installer migrate app data (e.g. databases could be migrated automatically, though I'm not saying, that this is really the case)?
• does the app know (by info from the system) if it's installed and if it's updated when started after installation?
• or is it defined and documented that it needs to derive that from it's data?
• the purpose of the backup...they can be for a specific purpose e.g. migrating a ROM, or for a possible failure of "something" in the future. In that case you don't know what will be the future situation (e.g. installer strategies) and you save as much as possible to not miss a part you might need. Basically, you should not assume anything for this purpose. The backup might be much older, e.g. if it's an app you don't use for some time but keep it in case you need it later, in some cases as a tool for recovery from a failure.

In pure theory, which also includes possible future changes:

When restoring without apk:

• you install the app

this is mandatory for restoring, because the app uid and directories must exist. It's a fresh install, no migration takes place (if that's even possible). If the installer

• you restore the data

• you start the app

the app doesn't know, that it was updated. It may derive that info from it's own data (which is quite normal via versioning the data formats)

With restoring apk:

• (ideally) anything app related is in the state it had before the backup

• you upgrade the app

it's the usual procedure, guarantied to work, no assumptions that could change, installer and app get exactly what they expect

As a conclusion: it may indeed work, if the app migrates it's data purely based on it's own data and does not get info from the system about the fresh installation or if it was updated, but unless you find definitive documentation and everything follows that definition, you cannot be sure. The purpose of the backup plays an important role.

[larena1]

I used to do exactly this with Titanium Backup and also when I had to convert my Titanium backups to Neo Backup because restoring them with Titanium made all the apps crash for reasons I could not find when I went from A11 to A13. Converting them to Neo Backup format and then restoring was no issue.

I think there's a broadcast sent for when an app is updated but the usual procedure is that the app takes care itself of any migrations necessary when started. The app would either store the data version or its own version code somewhere and compare that to the current version.

There shouldn't be a difference if an old version of the app is restored with the old data or a new version with the old data because the system is not doing any migrations by itself, leaving it solely to the app to manage its data. The same is also the case if user has auto updates disabled, missed a few versions and then installs a new version later.

[hg42]

I said "defined" and "documented" for a reason.

"I think" the same as you, but it's not the same as being defined like that (and the future behavior is still open).

The same is also the case if user has auto updates disabled, missed a few versions and then installs a new version later

I disagree... In this case you don't uninstall, install fresh and then restore data on top. It's a much different procedure. E.g. the app gets a new user and group id if installed fresh. If any data is bound to the user id, then it would be very different.

I agree when you would say the developer must be mad to add such a dependency. But I assure you, I saw a lot of mad developers in my life :-)

[larena1]

In this case you don't uninstall, install fresh and then restore data on top. It's a much different procedure. E.g. the app gets a new user and group id if installed fresh. If any data is bound to the user id, then it would be very different.

But the user id is only for sandboxing and while the app could potentially store its user id and check for changes, I don't know why it should. The user id will also not be the same if Neo Backup restores the backed up APK on a fresh system, right? So again, where's the difference?

[hg42]

btw. the Titanium analogy is not valid any more. I am a TiB user from the beginning. Those times were easy compared to what happens now.

And you saw it yourself, crashes in A13, well, that's probably because of assumptions in TiBs procedures, that are no more vaild.

To make it clear, you can do it with NB, Antonios explained the two possibilities. I only think about, if that makes sense (also for my own usage patterns).

NB only restricts something, if it's not possible without.

E.g. it's definitely not possible to restore only data, when the app is not installed.

In fact, NB could create new directories for the data, but they would have the wrong UIDs and GIDs and selinux contexts. And installing a fresh app would probably delete the directories again (I guess, not sure...).

[hg42]

In this case you don't uninstall, install fresh and then restore data on top. It's a much different procedure. E.g. the app gets a new user and group id if installed fresh. If any data is bound to the user id, then it would be very different.

while the app could potentially store its user id and check for changes, I don't know why it should

I agree, why the hell should a developer do that...

But why are developers binding each and every data of their app to the keystore? That's a similar non-sense. Still, it exists. I guess, it's partly security by obscurity, and partly not understanding all the security concepts (I admit I'm not that guy either) and taking the simplest approach, where you don't have to think about what to encrypt and what doesn't need to. To build an encryption key, developers often have funny ideas, not thinking about all the consequences. But maybe that's all too theoretical. But good software engineering is to use the given documented definitions, not any assumptions or thinking "it will do". What you do with your own data is your part...

The user id will also not be the same if Neo Backup restores the backed up APK on a fresh system, right? So again, where's the difference?

ok, that's correct... so the uid, gid and the user related part of the selinux context are out of the game.

[hg42]

about the crashes... did you change from a 32bit to a 64bit device?

It's easy to forget that. The usual (pure jvm) apps still work, but those that use native libraries, will not work out of a restored backup.

[larena1]

But why are developers binding each and every data of their app to the keystore?

And the keystore can not be restored anyway, right?

ok, that's correct... so the uid, gid and the user related part of the selinux context are out of the game.

Yeah I think there's not much that could go wrong. But it would be enough if there was a toggle in the settings to turn off backing up the APK by default maybe accompanied by a warning that that could in rare cases lead to issues.

about the crashes... did you change from a 32bit to a 64bit device?

It's easy to forget that. The usual (pure jvm) apps still work, but those that use native libraries, will not work out of a restored backup.

It was the same device. Just upgraded from stock A11 to LOS A13. All the apps worked fine when I converted the same data from Titanium Backup to the format that Neo Backup expects and restored them through Neo Backup. It was some issues with the room databases I think but I guess Titanium is just broken on A13. Also the native libs come with the APK and I installed the APKs from the Play Store and the apps would only crash after Titanium restored the data.

[MrEngineerMind]

Larena1,

hg42 is one of the developers volunteering his precious time to this NB project, so please just let this issue go so you don't risk pushing too hard. It's not like you can't simply untick the apk checkbox during the restore to just restore the data.

So, please just enjoy NB as the great app it is and don't continue with this non-critical issue.

[larena1]

hg42 is one of the developers volunteering his precious time to this NB project, so please just let this issue go so you don't risk pushing too hard. It's not like you can't simply untick the apk checkbox during the restore to just restore the data.

I'm aware of that and we're just having a professional discussion about potential issues that could arise to make sure that Neo Backup continues to work great for everybody. Please try to only post here if you've got valuable information to add or else you're only making it harder to follow for everybody.

I just saw that when doing batch backups it's also possible to back up only app data and not the APK and I guess that works for me. Wasn't aware of that yet.

What would be great though is if Neo Backup could redo the backups with the previous settings. If previous backup of app X contained APK and data, redo that and if app Y had only data backed up previously, only back up data again for Y. Or is that also already possible?

[hg42]

@MrEngineerMind thanks for stepping in, but I agree with larena1, it was a discussion I wanted, otherwise I wouldn't have written such a long post above.

@larena1 MrEngineerMinds message was still valuable for you, wasn't it? it reminded of a fact that Antonios already wrote:

You can already use the batch backup tab or a schedule to do this

let's keep friendly... everyone has it's own reasons.

about the redo... it may be useful. Though with multiple backups it's not always clear. I had that problem with TiB, too. The last backup is not always the one you want to go for.

If you often do the same things, you should probably use schedules. The naming is a bit limited. In your case, see them as configurable batches, that just happen to also be able to be scheduled. I lately added a run button to each entry, so you can quickly start them from the list.

If you are interested, you can also start them from Tasker or any other way to start either an intent or a shell command. Though such discussions should move to the Telegram group, if you have Telegram. Or you could write a mail via github...

[larena1]

about the redo... it may be useful. Though with multiple backups it's not always clear. I had that problem with TiB, too. The last backup is not always the one you want to go for.

I agree with you that there's limitations to everything. Just thought it might be useful in case for some apps one needs the apk additionally to the data but for others only data is enough. One could then check the redo option in the schedule together with the old backups special filter and have all their backups refreshed.

Feel free to close this issue though. Using the schedule should be enough for my needs and for single backups I can just uncheck APK if needed.

[machiav3lli]

@larena1 just to make it clear: it's not only about UIDs, KeyStore etc.. there's a lot of dynamic components in apps data nowdays, that could be corrupted through the explained process e.g. database migrations.

On the redo thingy, it was default to use the same data structure of the last backup when doing backup from AppSheet, but it seems to have reversed among other changes. I'll considering adding a more concrete version of this. Otherwise repeating myself: this thing can already be done using schedules.

@MrEngineerMind thanks for intervention, I share your opinion but as Harald pointed out, he wouldn't be responding if not interested.

@hg42 I wouldn't say it's a security by obscurity thing (there's better examples for this e.g. blocking rooted devices), rather some use cases e.g. Signal, use this to full potential, while others encrypt some data but doesn't have the NB-user use case on their map of personas and thus doesn't invest time catching/fixing resulting issues (contrary to what you did in NB).

[machiav3lli]

On the TiB front: the software has been abandoned so long that the SDK changes killed it..

[larena1]

there's a lot of dynamic components in apps data nowdays, that could be corrupted through the explained process e.g. database migrations.

Out of curiosity, could you elaborate on which dynamic components and which process exactly?

Otherwise repeating myself: this thing can already be done using schedules.

I suppose one could be able to do it by using multiple schedules, one for APK and data, one only data and then picking the specific apps in these.

Signal

Yeah, I was unable to restore that one even through Neo Backup. I think it would just crash when restored.

[hg42]

yes, Signal has good reasons...

but when I once looked, some commercial apps had all their data encrypted, some had everything in dedata, etc. This didn't look like a plan...

This might eventually have todo with WebView etc. Perhaps their tools don't allow different categories.