[APP 4.0+] 3C All-in-One Toolbox

[rsngfrce]

There's nothing random, however it may look that way because of how Android OS stop and restart apps.

Force-stop is supposed to prevent an app from restarting until user opens its UI.

When you force-stop an app, the OS first removes any app's schedule, timer, alarms, etc. and then tells the app it is being stopped. An app based on that information can schedule a restart of its services using a specific delay, be it in milliseconds, seconds or even minutes.
For example, in my apps, required background services are auto-restarted after 1 or 5 seconds. So if you force-stop the toolbox twice within less than 1 or 5 seconds, it will not restart at all, because the auto-restart schedule is canceled and the app is not informed it is being stopped the second time (it's not yet running).


Concerning process count, it will not necessarily match the UI because the background service is not reloading exclusion "often enough". If you stop the background process, it will auto-restart (as explained above) and reload exclusion and will report up-to-date process count.

This issue is particularly visible after a fresh install. However it resolves itself when app/background process is restarted, including after an app update.

In next update, the list will be reloaded more appropriately which should solve this. Thanks for bringing that up.

EDIT: Devices running magisk may have processes named <package>:zygote64 which may be accounted for by mistake. I'll try to resolve that in next update too.

EDIT2: On more recent Android versions, process may be named <package>:usap64 Taken care of in next update too.

Thanks for the info! You know far, far more about how this works than I do, which is next to nothing, but it does APPEAR to me to be random. The reason I say this is because when I am force closing apps, I am generally force closing the same apps that I regularly use, that take approximately the same amount of time to force close, plus or minus a few in either category, but different apps seem to survive the force close each time. Based on my understanding of what you are saying, I would expect the same apps that are restarting themselves within the specific time period to always be the apps that survive the first force stop?

On a somewhat related note, I was quite shocked when I discovered that most, if not all, apps that claim to freeze apps are just force closing them, which the system then sees as being frozen. This is why you have to be careful which apps you force close, because then you can end up wondering why they aren't running themselves. It can be a good method of preventing apps you don't use often from running themselves, however (outside of running themselves at startup, I believe, if they are set for that).

 

[3c]

Thanks for the info! You know far, far more about how this works than I do, which is next to nothing, but it does APPEAR to me to be random. The reason I say this is because when I am force closing apps, I am generally force closing the same apps that I regularly use, that take approximately the same amount of time to force close, plus or minus a few in either category, but different apps seem to survive the force close each time. Based on my understanding of what you are saying, I would expect the same apps that are restarting themselves within the specific time period to always be the apps that survive the first force stop?

On a somewhat related note, I was quite shocked when I discovered that most, if not all, apps that claim to freeze apps are just force closing them, which the system then sees as being frozen. This is why you have to be careful which apps you force close, because then you can end up wondering why they aren't running themselves. It can be a good method of preventing apps you don't use often from running themselves, however (outside of running themselves at startup, I believe, if they are set for that).

The scheduling I mentioned is not as precise as that. Since Android M, the OS will try to arrange different schedules together. So an app trying to restart after 5 seconds might actually be scheduled after 10 seconds instead. All to the discretion of the OS. Hard to tell.

The OS defines 2 states: stopped and disabled, each are very different:

1) stopped means the app won't start unless the user starts it manually first. That's Google's definition which is somehow not true under specific circumstances.
2) disabled (frozen) means the app cannot be used, its main icon is not shown and app cannot run. Again that's Google's definition which is not entirely true for some apps like NFC or Bluetooth and sometimes WebView !

Now, what I called freezing in my app does disable apps, while stop do force stop as expected. Not sure why I called it freeze in the first place, must be historical lol.

If an app claim to freeze others but only force close them, it's very deceptive and the system should not show them as 'disabled' in Android settings. If disabled, this means they are truly frozen, but you won't be able to use them.

Quite some time ago users asked for a shortcut to freeze/unfreeze pre-selected apps that could be added to the launcher. You could use that to ensure those selected apps never run unless you want them to. Very effective in most cases.

 

[rsngfrce]

The scheduling I mentioned is not as precise as that. Since Android M, the OS will try to arrange different schedules together. So an app trying to restart after 5 seconds might actually be scheduled after 10 seconds instead. All to the discretion of the OS. Hard to tell.

The OS defines 2 states: stopped and disabled, each are very different:

1) stopped means the app won't start unless the user starts it manually first. That's Google's definition which is somehow not true under specific circumstances.
2) disabled (frozen) means the app cannot be used, its main icon is not shown and app cannot run. Again that's Google's definition which is not entirely true for some apps like NFC or Bluetooth and sometimes WebView !

Now, what I called freezing in my app does disable apps, while stop do force stop as expected. Not sure why I called it freeze in the first place, must be historical lol.

If an app claim to freeze others but only force close them, it's very deceptive and the system should not show them as 'disabled' in Android settings. If disabled, this means they are truly frozen, but you won't be able to use them.

Quite some time ago users asked for a shortcut to freeze/unfreeze pre-selected apps that could be added to the launcher. You could use that to ensure those selected apps never run unless you want them to. Very effective in most cases.

My understanding, which I am not saying is correct, is that there are two states as you say, stopped and disabled, but stopped is considered to be frozen, rather than disabled being considered frozen.

A disabled app, as you say, can't be run and it's icon is not visible. On a non-root phone, the only way to disable an app is to use ADB or an app designed for that purpose that you grant Device Owner status (which can be a pain).

I use an app on F-Droid, SuperFreezZ App stopper (Entirely freeze all background activities of apps.), which says it works the same as Greenify. I discovered that if I force stop an app, it is listed in SuperFreezZ as frozen (not disabled, as I think you misunderstood). This is where I got my impression that force stopping equals freezing and discovered why apps that I had force stopped would not run in the background until I started them again. For me at least, it was important to understand that force stopping an app didn't just stop it for "now" to release memory, but would prevent it from running until I ran it again (or restarted for apps that start on boot, I believe, but I could be confused about that)... so I have to be more careful about what I force stop, especially if I don't plan to restart immediately.

Samsung phones have an app called Device Care which tells you that you it can free up memory by stopping background apps that "haven't been used recently". These are mostly system apps that can restart themselves I believe, since they aren't being disabled, but it gives no indication that if it stops a user app, that app will be "frozen".

On my rooted phone, Titanium Backup would do what it called "freeze" apps, but that was actually disabling them I believe. So the meaning of "freezing" becomes confusing.


UPDATE: I am going to leave what I already typed above, because it illustrates my confusion over this issue. I just had something happen that I have seen happen before, but hadn't thought about enough and really confuses me.

I attempted to run an app on my phone and it kept crashing immediately. My first thought was to try to download it from the Play Store again. The Play Store, instead of giving me the option to uninstall or open it, as it usually would, gave me the option to enable it. I checked in SuperFreezZ and it was listed as frozen. Running it was not "unfreezing" it.

After I enabled it in the Play Store, an update was immediately available, so it was being kept from updating as well. This app was not disabled and was still visible in my app drawer. I have a non-rooted phone, so SuperFreezZ would not be able to disable it anyway. I checked it in CCSWE (Device Owner version) and it wasn't listed as disabled and I know I hadn't disabled it anyway.

I checked some other apps that were listed as frozen in SuperFreezZ and some gave me an enable option in the Play Store and would not run and others did not and would run.

So this is VERY confusing, but reinforces why I was thinking that force stopping an app is potentially very dangerous, unless you really want to FREEZE it.

But why does there seem to be two "frozen" states, one that won't run on its own but is still "enabled" and another which is functionally "disabled", but still visible in the app drawer, unlike a true "disabled" app?

I have attempted to ask the devs of SuperFreezZ similar questions on GitLab.


UPDATE 2: Another related question has occurred to me. The system of my Samsung Galaxy S10e phone can put apps to sleep or to deep sleep. It defines sleep as, "These apps won't run in the background. They may not receive updates or send notifications." Deep sleep is defined as, "Deep sleeping apps will never run in the background. They'll only work when you run them." So this seems to be three states, sleeping, deep sleeping and disabled, and which of the three is considered frozen? I'm not really sure the definitions of sleeping and deep sleeping are actually different, other than the fact that sleeping apps MIGHT recieved updates and/or send notifications, while deep sleeping apps WON'T. which is a pretty odd distinction.

 

[3c]

My understanding, which I am not saying is correct, is that there are two states as you say, stopped and disabled, but stopped is considered to be frozen, rather than disabled being considered frozen.

A disabled app, as you say, can't be run and it's icon is not visible. On a non-root phone, the only way to disable an app is to use ADB or an app designed for that purpose that you grant Device Owner status (which can be a pain).

I use an app on F-Droid, SuperFreezZ App stopper (Entirely freeze all background activities of apps.), which says it works the same as Greenify. I discovered that if I force stop an app, it is listed in SuperFreezZ as frozen (not disabled, as I think you misunderstood). This is where I got my impression that force stopping equals freezing and discovered why apps that I had force stopped would not run in the background until I started them again. For me at least, it was important to understand that force stopping an app didn't just stop it for "now" to release memory, but would prevent it from running until I ran it again (or restarted for apps that start on boot, I believe, but I could be confused about that)... so I have to be more careful about what I force stop, especially if I don't plan to restart immediately.

Samsung phones have an app called Device Care which tells you that you it can free up memory by stopping background apps that "haven't been used recently". These are mostly system apps that can restart themselves I believe, since they aren't being disabled, but it gives no indication that if it stops a user app, that app will be "frozen".

On my rooted phone, Titanium Backup would do what it called "freeze" apps, but that was actually disabling them I believe. So the meaning of "freezing" becomes confusing.


UPDATE: I am going to leave what I already typed above, because it illustrates my confusion over this issue. I just had something happen that I have seen happen before, but hadn't thought about enough and really confuses me.

I attempted to run an app on my phone and it kept crashing immediately. My first thought was to try to download it from the Play Store again. The Play Store, instead of giving me the option to uninstall or open it, as it usually would, gave me the option to enable it. I checked in SuperFreezZ and it was listed as frozen. Running it was not "unfreezing" it.

After I enabled it in the Play Store, an update was immediately available, so it was being kept from updating as well. This app was not disabled and was still visible in my app drawer. I have a non-rooted phone, so SuperFreezZ would not be able to disable it anyway. I checked it in CCSWE (Device Owner version) and it wasn't listed as disabled and I know I hadn't disabled it anyway.

I checked some other apps that were listed as frozen in SuperFreezZ and some gave me an enable option in the Play Store and would not run and others did not and would run.

So this is VERY confusing, but reinforces why I was thinking that force stopping an app is potentially very dangerous, unless you really want to FREEZE it.

But why does there seem to be two "frozen" states, one that won't run on its own but is still "enabled" and another which is functionally "disabled", but still visible in the app drawer, unlike a true "disabled" app?

I have attempted to ask the devs of SuperFreezZ similar questions on GitLab.


UPDATE 2: Another related question has occurred to me. The system of my Samsung Galaxy S10e phone can put apps to sleep or to deep sleep. It defines sleep as, "These apps won't run in the background. They may not receive updates or send notifications." Deep sleep is defined as, "Deep sleeping apps will never run in the background. They'll only work when you run them." So this seems to be three states, sleeping, deep sleeping and disabled, and which of the three is considered frozen? I'm not really sure the definitions of sleeping and deep sleeping are actually different, other than the fact that sleeping apps MIGHT recieved updates and/or send notifications, while deep sleeping apps WON'T. which is a pretty odd distinction.

Like TiBu, my app uses "freeze" meaning "disabled" in OS terms. It's just the SuperFreezZ app Stopper that's mixing both terms in the most confusing way (IMO). Just so that they get better listing/views on Play Store.

It works the same as Greenify or my app on non rooted devices. However it definitely doesn't work like it or my app on rooted devices.

Stopped (short for Force-stopped) and frozen (replacement for disabled) are 2 OS states that exists on all Android devices, rooted or not. Those are available in Android settings, app's management, app's detail pages.

Now, what you mention about Samsung sleep and deep sleep are actually Samsung's implementation of my app's crystallize or the greenified state, which simply put prevent apps from running in background, without preventing user to use them. My app offer 3 ways to crystallize: never run in background whatsoever, may run in background if used until screen goes off and may run in background when used only.

Force-stop is a good way to prevent most apps from running in background, except that it's not 100% reliable (to put it simply), so it's safer to use than disabling (freezing) which will prevent you from using the app.

Crystallizing apps is very complex to implement by third party apps (unless using Xposed), but is a great way to prevent apps from running in background and can save some battery time if used correctly.

That said, force-stop does a great job in most cases, except on Google (or manufacturers) apps, which in my experience are always the ones draining the battery in standby. Hence the crystallize (deep sleep) feature in my app.

 

[rsngfrce]

Like TiBu, my app uses "freeze" meaning "disabled" in OS terms. It's just the SuperFreezZ app Stopper that's mixing both terms in the most confusing way (IMO). Just so that they get better listing/views on Play Store.

It works the same as Greenify or my app on non rooted devices. However it definitely doesn't work like it or my app on rooted devices.

Stopped (short for Force-stopped) and frozen (replacement for disabled) are 2 OS states that exists on all Android devices, rooted or not. Those are available in Android settings, app's management, app's detail pages.

Now, what you mention about Samsung sleep and deep sleep are actually Samsung's implementation of my app's crystallize or the greenified state, which simply put prevent apps from running in background, without preventing user to use them. My app offer 3 ways to crystallize: never run in background whatsoever, may run in background if used until screen goes off and may run in background when used only.

Force-stop is a good way to prevent most apps from running in background, except that it's not 100% reliable (to put it simply), so it's safer to use than disabling (freezing) which will prevent you from using the app.

Crystallizing apps is very complex to implement by third party apps (unless using Xposed), but is a great way to prevent apps from running in background and can save some battery time if used correctly.

That said, force-stop does a great job in most cases, except on Google (or manufacturers) apps, which in my experience are always the ones draining the battery in standby. Hence the crystallize (deep sleep) feature in my app.

I checked with the Dev of SuperFreezZ and he confirmed that SuperFreezZ just force stops apps. He says this is the same thing that Greenify does, but I don't know (I know Greenify has different levels of hibernation though).

Upon further investigation, I found that the Samsung deep sleep is actually disabling the user apps. They are still visible in the app drawer, but offer the option to enable them on the Play Store or turn them on in the system app manager. This, as you say, seems to be 3C Toolbox's crystallize state. These, along with force stopped apps, are listed in SuperFreezZ as frozen.

The odd thing is that last night, when I tried run deep sleeping apps, they would either immediately crash, or freeze up when loading (which is why I started trying to find out what was happening). This is not good, because the Samsung system will put unused apps into this state unless they are manually excluded. Today, however, if I run a deep sleeping app, they seem to run fine and are removed from the deep sleeping state.

I don't have the crystallize option in 3C. The docs say it requires the Xposed Framework or enabled (default) system logs. Other than being rooted, does this mean the 3C Companion App would be required?

 

[3c]

I checked with the Dev of SuperFreezZ and he confirmed that SuperFreezZ just force stops apps. He says this is the same thing that Greenify does, but I don't know (I know Greenify has different levels of hibernation though).

Upon further investigation, I found that the Samsung deep sleep is actually disabling the user apps. They are still visible in the app drawer, but offer the option to enable them on the Play Store or turn them on in the system app manager. This, as you say, seems to be 3C Toolbox's crystallize state. These, along with force stopped apps, are listed in SuperFreezZ as frozen.

The odd thing is that last night, when I tried run deep sleeping apps, they would either immediately crash, or freeze up when loading (which is why I started trying to find out what was happening). This is not good, because the Samsung system will put unused apps into this state unless they are manually excluded. Today, however, if I run a deep sleeping app, they seem to run fine and are removed from the deep sleeping state.

I don't have the crystallize option in 3C. The docs say it requires the Xposed Framework or enabled (default) system logs. Other than being rooted, does this mean the 3C Companion App would be required?

Yes greenify does force-stop apps when not rooted.

Using 3C Companion will definitely enable a lot of features including a "clean" force-stop, and crystallize (got to double-check though) amongst other things. My favorite these days is the uninstall system apps that allows debloating a device effectively.

As for all manufacturers adding their own s**t optimizations on top of Google's doze, it's all just crap. I tested my app just showing % in notification, it ended-up being disabled by OS because I didn't open the UI often enough!
The worst of all is that an app can request to be excluded from optimizations, but manufacturers don't tell users that it's not excluded from their own optimizations! They don't tell users that their optimizations brings no benefit either (IMO)!

 

[rsngfrce]

Yes greenify does force-stop apps when not rooted.

Using 3C Companion will definitely enable a lot of features including a "clean" force-stop, and crystallize (got to double-check though) amongst other things. My favorite these days is the uninstall system apps that allows debloating a device effectively.

As for all manufacturers adding their own s**t optimizations on top of Google's doze, it's all just crap. I tested my app just showing % in notification, it ended-up being disabled by OS because I didn't open the UI often enough!
The worst of all is that an app can request to be excluded from optimizations, but manufacturers don't tell users that it's not excluded from their own optimizations! They don't tell users that their optimizations brings no benefit either (IMO)!

I definitely agree with what you are saying about manufacturer optimizations. On my Samsung there are particularly so many battery optimizations in so many places that excluding apps from optimization is a struggle. My phone does get a score of 100% from the Don'tKillMyApp app, but unfortunately that seems to focus only on battery optimization issues, because since upgrading to Android 11, I am having EXTREME issues with background apps being closed due to memory issues rather than battery issues, which is why I am killing apps so often.

Today, the 3C task manager was reporting 60 non-excluded apps running. Using the task manager accessibility method, it took 4 times to kill all the apps, except for 2 that were still running after 8 times. I successfully killed one of them manually, the other one, MiXplorer, I could watch restart itself no matter how many times I manually killed it. You say that an app should not restart after being killed twice. This is why, at least on my phone, I believe something isn't working correctly with the task manager, but it isn't working manually either.

 

[F308]

You say that an app should not restart after being killed twice.

I apologize for jumping into middle of discussion, but it is rather not realistic to read 70+ pages of thread.

The above may happen for a reason.
In Linux init there exists behavior definition called respawn.
Such program or application after being observed dead is launched again.
System cares of that.
You may watch for pid to know it is new instance.
It differs from the one which was killed.


For myself I like 3C, I bought it and years ago I even had it's grandfather, 3C System Tuner Pro, checked version - it is 3.20.8.
Still alive on other phone.
It was too complicated to migrate from it to 3C All-in-One Toolbox then I bought current one.

 

[rsngfrce]

I apologize for jumping into middle of discussion, but it is rather not realistic to read 70+ pages of thread.

The above may happen for a reason.
In Linux init there exists behavior definition called respawn.
Such program or application after being observed dead is launched again.
System cares of that.
You may watch for pid to know it is new instance.
It differs from the one which was killed.


For myself I like 3C, I bought it and years ago I even had it's grandfather, 3C System Tuner Pro, checked version - it is 3.20.8.
Still alive on other phone.
It was too complicated to migrate from it to 3C All-in-One Toolbox then I bought current one.

Thanks for the info I agree that it is unrealistic to read a massive number of pages if you haven't read the thread for a while, plus the new XDA search function is not the best.

I was also a user of 3C System Tuner Pro.

 

[rsngfrce]

@3c , thanks for adding the double kill option to the task manager. On my first attempt using it, all of my apps were killed, which is the first time I have seen that, even if I was running it twice.

I just noticed the option to auto kill apps if memory is low. How is low memory defined? I enabled it and will be very interested to see how it functions on my phone with Android 11 memory issues.

 

[3c]

@3c , thanks for adding the double kill option to the task manager. On my first attempt using it, all of my apps were killed, which is the first time I have seen that, even if I was running it twice.

I just noticed the option to auto kill apps if memory is low. How is low memory defined? I enabled it and will be very interested to see how it functions on my phone with Android 11 memory issues.

Hard to tell exactly what low memory condition means. It's defined by Android OS and used to be based on OOM settings, which since Android 11 are no longer available in a file. However it still works more or less the same way.

OOM defines groups of apps, like system, foreground, visible, content provider, background services, etc.
It also defines minimum memory available before it starts killing apps from each group.

For example, one large memory models, it'll try to keep 512MB, and if it goes lower it will start killing apps from the less visible groups, eg background services.

Now it's quite unclear when an app will receive the low memory message. I suspect it'll get that message when the memory goes lower than a specific value assigned to the group it is currently running in.

If the group running the toolbox is affected, enabling that option will kill all included apps from task manager.

 

[rsngfrce]

Hard to tell exactly what low memory condition means. It's defined by Android OS and used to be based on OOM settings, which since Android 11 are no longer available in a file. However it still works more or less the same way.

OOM defines groups of apps, like system, foreground, visible, content provider, background services, etc.
It also defines minimum memory available before it starts killing apps from each group.

For example, one large memory models, it'll try to keep 512MB, and if it goes lower it will start killing apps from the less visible groups, eg background services.

Now it's quite unclear when an app will receive the low memory message. I suspect it'll get that message when the memory goes lower than a specific value assigned to the group it is currently running in.

If the group running the toolbox is affected, enabling that option will kill all included apps from task manager.

Thanks. I remember experimenting adjusting the OOM groups with 3C Toolbox on my old rooted phone.

I found out how the auto-kill on low memory works on my phone and it was just as I feared. I was playing a game (nothing intense) and the task killer suddenly started running and killed the game I was playing (along with the other non-excluded apps). I don't know if this is the expected Behavior, it wouldn't surprise me if it doesn't work correctly on my phone due to the memory issues. Obviously I guess, I could have excluded this game, but this is exactly the kind of thing that is residing in memory when I am not playing it that I want killed when the memory is low... but not while playing it. Shouldn't it be protected as a foreground app, or is that irrelevant to the task killer (because it becomes the foreground app)?

The task killer just started again while I was typing this and killed three apps. If I am having a low memory condition with only three non-excluded apps running, I think that illustrates the memory issue I am having on Android 11 (unless I have too many excluded apps).

(STANDARD DISCLAIMER: The above text was entered using the horrific Google speech-to-text service. Please excuse any random capitalization, improper grammer, nonsensical phrases or random "oh" 's)

Update: Yeah, I was just in the middle of typing a long message on Discord when the task killer auto-started again, so I lost everything. I' ve disabled the auto-kill on low memory, I can't imagine obviously that this is how you intend it to work or how it works for others.

 

[bege10]

I keep a spare device up to date with the data from my daily device by syncing among others the app backups.
Now what is the best way to transfer the Toolbox app manager settings to the other device? And which settings are included in the backup?

 

[bege10]

In backup settings of app manager, please, add a confirmation if changing settings for all apps.
I just worked 1 hour to change the settings and by mistake tapped once on all apps instead of app alone. Now I can begin again.

Edit: Additionally to "Import App Settings" in Help and Support.

 

[3c]

In backup settings of app manager, please, add a confirmation if changing settings for all apps.
I just worked 1 hour to change the settings and by mistake tapped once on all apps instead of app alone. Now I can begin again.

Edit: Additionally to "Import App Settings" in Help and Support.

You mean a confirmation in both backup settings and when importing app settings?
Note that such will have a 'do not ask again' checkbox, which if ticked will be as "usual".

I keep a spare device up to date with the data from my daily device by syncing among others the app backups.
Now what is the best way to transfer the Toolbox app manager settings to the other device? And which settings are included in the backup?

You can either use the standard backup/restore, it works on toolbox itself. Or manual import/export from settings.

 

[bege10]

You mean a confirmation in both backup settings and when importing app settings?
Note that such will have a 'do not ask again' checkbox, which if ticked will be as "usual".

Yes, exactly, that will be very helpful against mistakes as happened to me. In backup settings only if one chooses "all apps".

You can either use the standard backup/restore, it works on toolbox itself. Or manual import/export from settings.

Which settings are backed up/restored in these ways? Or which ones are not? As far as I see the tags are in every folder of a backup version, so they are not stored in the Toolbox but in separate files. Are there any other settings that are not backed up? Can you add a dialog to import to choose the settings to import, e.g. deselect scheduled tasks?

 

[bege10]

On the two phones where I use the Toolbox I noticed that on one phone within the app manager I see the tags from the file in the latest backup folder of every app, on the other phone the tags of the latest but one backup folder. This may come because I synchronize the backups of both phones. This means that synchronization may add a backup folder, not the app manager itself. Same with the tags file.
Is there a reason that you store the tags in every version rather than only in the main backup folder of every app? I cannot think of a scenario where I need different tags for different app versions. Only one tags file would remove this inconsistency.

 

[3c]

Yes, exactly, that will be very helpful against mistakes as happened to me. In backup settings only if one chooses "all apps".

Which settings are backed up/restored in these ways? Or which ones are not? As far as I see the tags are in every folder of a backup version, so they are not stored in the Toolbox but in separate files. Are there any other settings that are not backed up? Can you add a dialog to import to choose the settings to import, e.g. deselect scheduled tasks?

Warning/confirmation will be added in next update.

Everything from /data/data/<app_folder> and /sdcard/Android/data/<app_folder> folders is backed-up. Including saved tags for live apps.

Backups are also saving tags for the purpose of restoring in case toolbox's settings is not restored, hence tags are restored from backup if needed.

On the two phones where I use the Toolbox I noticed that on one phone within the app manager I see the tags from the file in the latest backup folder of every app, on the other phone the tags of the latest but one backup folder. This may come because I synchronize the backups of both phones. This means that synchronization may add a backup folder, not the app manager itself. Same with the tags file.
Is there a reason that you store the tags in every version rather than only in the main backup folder of every app? I cannot think of a scenario where I need different tags for different app versions. Only one tags file would remove this inconsistency.

Because restoring will restore a version and I won't bother read multi-level folders. If tags are different in an older version, those tags get restored. Some users want it that way too.

If you synchronize 2 phones, I'm sure you use the same version, hence will get the same tags. Nevertheless tags are saved in toolbox's settings as well, as explained above. Backup tags are there for users restoring apps without restoring toolbox.

 

[bege10]

Warning/confirmation will be added in next update.

Thank you very much.

Because restoring will restore a version and I won't bother read multi-level folders. If tags are different in an older version, those tags get restored. Some users want it that way too.

So if I restore an older version because the current one is buggy I will restore the old tags also. Are you sure that this is what most 3C Toolbox users want? I definitely don't want to restore old tags.

 

[bege10]

Hello,
when I change the state of an app component (service, provider ...) in the Toolbox the App Manager io.github.muntashirakon.AppManager (F-Droid) immediately shows the new state. But it doesn't work vice versa, 3C Toolbox only shows the state set in the Toolbox itself.
Can you, please, show the real state in the Toolbox also?
Thank you very much.