[Feature Request] Back up apps currently frozen by Shelter
daniellandau opened this issue · 7 comments
Is your feature request related to a problem? Please describe it.
Neo-Backup can backup apps in the "work" profile created by shelter. It doesn't currently show apps that are at "frozen" by shelter.
Describe the primary solution
I'd like for Neo-Backup to be able to just back up the apps without having to un-freeze them first.
Describe alternative solutions, if any
Manually un-freezing the apps before a backup works, but backups shouldn't be manual.
System Information (please complete the following information):
- Device: Oneplus 6
- Android Version: 13
- ROM: Lineageos 20.0 with microg
- App Version: 8.3.1
Actually, what it does is freeze then unfreeze them (to make sure the data is stable while doing the backup). To change the behaviour (un)check both: Seetings>advanced>developer settings>advanced usrrs> backupPauseApp/backupSuspendApp
That doesn't help. My issue is, that neobackup doesn't show the apps frozen by Shelter at all in the list of installed apps.
the main question is, what "freeze" really means in this case.
I see a lot of apps using this word, but it's meaning differs.
You might find out some things with AppManager (btw. it also uses the term "freeze" lately, I didn't check, yet, how this is handled).
Also try
pm list packages
with various options to find out when a frozen app is listed.
NB uses the PackageManager API to get a package list. So, the pm command might give some hints.
Perhaps Shelter plays some additional tricks.
Look at the package dirs, may be they are renamed ot made inaccessible etc.
I don't really know, but it seems that this might be the line for what shelter does: https://gitea.angry.im/PeterCxy/Shelter/src/branch/master/app/src/main/java/net/typeblog/shelter/services/FreezeService.java#L119
Android docs for that method: https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setApplicationHidden(android.content.ComponentName,%20java.lang.String,%20boolean)
The only flag for pm list packages that surfaces the freezed apps are -a and -u for "all" and "uninstalled". Those show the frozen application for both the normal and work profile though.
ok, thanks for investigating.
Well, this opens a pandora box...
I'm not the project owner, but I would postulate some principles:
- NB follows general APIs and conditions etc. We don't have time to adapt to special environments (which may also create conflicting conditions fir different users)
- so NB will not do special treatment for special apps or systems
- it's ok, if a general rule can be given, that can handle special apps etc. (e.g. we lately added nsenter usage with rules that cover all known SU solutions)
- however, I could imagine (possibly script-) plugins, that handle special cases, once a plugin system is established
will think about...
plugins:
I guess we should have different classes for different purposes.
The (jsr223) script can derive from them.
They would be automatically registered as handler for a certain purpose.
we could extend the list of packages to all those that are managed by PackageManager (for whatever reason).
We can ask the package entry, if it is installed, where we need that (e.g. to get a list of installed packages).
However if we backup uninszalled packages that still exist and are managed, we get another problem:
Restoring such a package would make it installed again.
And we don't know whatever was the reason for the "uninstalled" state, and especially we don't know, how to put it back to that state again.
Even with a shelter plugin that could use the shelter methid to implement this, we would not know if it was uninstalled because of shelter or of other reasons (e.g. I have uninstalled packages, too, but I don't have shelter).
So, such plugins need a way to determine when they are responsible for a particular operation on a package.
Also, are all uninstalled packages still in the system? I guess not...
A more general approach would be possible, if the policies managed by DevicePolicyManager could be backed up and restored similar to permissions.
Maybe someone using Shelter or similar (extensively) could investigate that...