yashsingh1/xdaforums huggingface dataset:
[Android Apps and Games] doggydog2:
3 to the C, the legend.

Overtook the role of another even older legend - TitaniumBackup - which died in silence.

I miss encryption of backups because whenever possible (not much nowadays) I place backups on unencrypted SD card. That is great in case system is broken, phone is damaged -> backup is available. Chin chin! However it is very unsafe obviously.

I didn't know there's even debloat function. I use the paid 3C app for centuries, but didn't notice. I will publish my next debloat article support this format:) One tiny bug: when press "Reset" button, "Cancel" doesn't cancel the operation but proceed. This one is not important: I use Scheduler to debloat via script. Every other time I boot it's after firmware update as it's so frequent and debloat needs to be executed again. One of the possible resulting actions "tasks" could be (and surprisingly it's not) ta daaa... debloat (see the picture, i mean the inhouse one, not the script). This would positively promote the existing function and more people would perhaps use the suggested format.

Finally talking about features, hard to find something missing, but I do:) I use Xposed Edge the legend, but worry about XPosed into future, or impossible to use during first months of new Android release (e.g. the last A11 came in October, Xposed came in January). So i'd like their "more triggers" in 3C. There are already triggers in "Watcher" but too much battery oriented. What a perfect screen for more triggers. Can we add bit more? Especially the connectivity condition (wifi / mobile), perhaps wifi with SSID (see picture)?

Thanks!
[Android Apps and Games] j1gga84:
I am using 3c toolbox Pro since a long time.

Currently my phone is running a stock based android 10 Samsung ROM which is rooted.

The biggest problem is that I cannot deactivate any apps. When I uncheck them, leave the app and open it again the app is checked again.

Any ideas?

Regards
[Android Apps and Games] 3c:
Deactivating apps is achieved from apps manager, apps tab where you can tap 'freeze' to deactivate an app.

Checkboxes are used to deactivate apps components, and the app double-check setting is properly applied and issue a "failed" error message if it's not applied.

Returning to that screen suggests the components are automatically reactivated, which is possible, but doubtful it's that fast, unless applied to running apps that do check their events.

Can you post screenshots showing which app/component you're trying to disable and what happens after you do so?
[Android Apps and Games] rsngfrce:
Samsung Galaxy S10e, Android 11.

I have been having terrible issues with apps getting killed in the background since upgrading to Android 11, which I am quite sure is due to memory issues and not battery. I have been using the 3C task manager (via widget) to kill all non-excluded apps before I restart to clear memory. For some reason, I always have to run this twice to get all the apps killed. I am aware that apps can restart themselves, but which and how many apps remain unkilled after the first run always varies. I am using the automated accessabilty service method (non-root/non-3C helper).
[Android Apps and Games] j1gga84:
Thanks for your feedback but I was wrong.

Not deactivating apps is the problem, it is disabling the autostart from the apps.

When I click on the checked boxes to uncheck an autostart nothing happens.

After closing and reopening 3C Toolbox the hooks are back again.

Any ideas?

Regards
[Android Apps and Games] 3c:
Assuming you don't receive a failed message from the app, this means the auto-start is truely disabled.

Where are you disabling auto-start? I assume from events tab, right?

Can you try opening app's detail page (from task manager or apps' manager), go to receivers tab, then filter by "boot" and disable them there ?

The app double-check it's setting is properly applied, but I'm surprised it would actually revert while only closing/reopening the tab.

Is your device rooted or using 3C Companion?

There are ways in Android for apps to recover from force-stop. I have implemented those in my app, however force-stopping the app twice usually prevents it from recovering.

When an app has required background services, the OS will restart them after a simple kill, after 5 seconds.

When a force-stop occurs however, the app will be informed that its services are being shutdown and have the opportunity to set an alarm to restart itself.

However if a second force-stop occurs before those services are restarted, those alarms are cleared and the app won't restart anymore.

So, when you do a force-stop that's what happens and why some apps are still running (restarted actually). Upon second force-stop they are permanently terminated.

Given you use the accessibility service, it'll be highly cumbersome to auto-run this twice. But I should probably add an option to do so.
[Android Apps and Games] rsngfrce:
Running it twice isn't as cumbersome as running it once in the first place with accessability, because there are always few apps that require it twice.
[Android Apps and Games] 3c:
Double-force-stop will be added in next update, whether rooted or not.
[Android Apps and Games] rsngfrce:
Samsung Galaxy S10e, Android 11.

Is the 3C All-In-One Toolbox Pro key required to be running in the background? My phone reported that it was using high background battery, so put it to sleep. The next time I used 3C Toolbox, the pro features weren't active, so I ran the Pro key which fixed the issue. I can prevent the system from putting the Pro key to sleep, but I am concerned regarding the high background battery usage message. It could just be a Samsung overreaction, I haven't monitored it with an app.
[Android Apps and Games] 3c:
The pro key only provides a licensing service that does not need to run in background per-se, however it'll be used by the main app to validate its license, which run in background. I usually exclude pro key from any Android optimizations, more importantly on non-Google devices where most manufacturers add their own limitations, which more often than not prevent the licensing service from working. You can find more information here: https://3c71.com/optim and https://3c71.com/key.

That said, it should never consume battery (usually runs for 0.0x seconds to validate license, once). You can run task recorder to verify actual CPU consumed.

I'm running the task recorder constantly on a few devices and did double-check that the pro key is not listed in running apps.

Should you still find issues, please send the task recording or let me know with a screenshot. I'll make sure to double-check that.

You could also uninstall/reinstall the key, as sometimes the OS can corrupt an app without warning. After an OTA for example.
[Android Apps and Games] rsngfrce:
Thanks for the detailed reply!
[Android Apps and Games] doggydog2:
also one note, can there be an offline license?

it seems the app will be unregistered on a new phone, which will make it the only root app with this problem (the problem is i don't want to sign up to google before i do my dirty work).

in fact 3c-backed up apk won't even install -> ok this is because split apks perhaps, got it from aurora.

Cannot restore apps, OK button disabled -> that was VirtualXposed package.
[Android Apps and Games] rsngfrce:
It continues to appear to me that the apps that are not killed after the first force-stop are somewhat random, which indicates to me that they aren't the apps requiring background services, unless possibly Android 11 is killing the background services for some apps (which seems to be an issue I am having), so those apps aren't surviving the force stop when they should be (which makes the apps that survive the force-stop differ). Does that make sense? I will have to pay attention to whether the apps that are surviving are all apps with background services.

I am also seeing a very few apps that require three force-stops.

On a related question, I have a widget with the top value set to Process Count. After I force-stop all non-excluded apps, the widget always lists 4 apps running, though the task manager shows no non-excluded (including system apps) running. Do you know why it always displays 4 instead of 0? Also in the example below, it shows 96 apps total, but if I count the number of excluded apps in the task manager (including system), there are only 89 displayed?

View attachment 5272867
[Android Apps and Games] 3c:
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.
[Android Apps and Games] rsngfrce:
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).
[Android Apps and Games] 3c:
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.
[Android Apps and Games] 3c:
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.
[Android Apps and Games] rsngfrce:
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?
[Android Apps and Games] 3c:
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)!
[Android Apps and Games] rsngfrce:
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.
[Android Apps and Games] F308:
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.
[Android Apps and Games] rsngfrce:
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.
[Android Apps and Games] 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.
[Android Apps and Games] 3c:
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.
[Android Apps and Games] rsngfrce:
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.
[Android Apps and Games] 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?
[Android Apps and Games] 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.
[Android Apps and Games] 3c:
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".

You can either use the standard backup/restore, it works on toolbox itself. Or manual import/export from settings.
[Android Apps and Games] bege10:
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?
[Android Apps and Games] 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.
[Android Apps and Games] 3c:
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.

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.