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

[bege10]

Also, I'm on 2.6.6a and it seems a bug affecting restore has been introduced sometime in the last couple of upgrades:

Now, only restore app data and settings works — if you select restore full app, the restore dialog pops up, exits immediately, says app restored, will list current/backup versions identical in the backups tab — but nothing is restored…

@3c I noticed this for the first time with 2.6.6 as reported in my support request regarding the backup issue. I thought these two issues where connected but probably they are not.

 

[3c]

@3c I noticed this for the first time with 2.6.6 as reported in my support request regarding the backup issue. I thought these two issues where connected but probably they are not.

Also, I'm on 2.6.6a and it seems a bug affecting restore has been introduced sometime in the last couple of upgrades:

Now, only restore app data and settings works — if you select restore full app, the restore dialog pops up, exits immediately, says app restored, will list current/backup versions identical in the backups tab — but nothing is restored…

Thanks for letting me know, this will be resolved on 2.6.6b. Sorry for the delay in fixing this. Gladly it's "only" in beta version.

 

[白い熊]

Thanks for the fix – three observations now:

- the restore works again
- no individual files-within-package progress as on the backup, would be also nice :O)
- on the backup now the backup screen is laid out somewhat illogically:

On top you hava the individual partial file names being processed - the progress bar for this is on the bottom - should logically be under this name. The total bar should be on the bottom and above it you now only have 1 of 5 or what have you - indicating how many apps processed - it should also show the app name currently being processed.

Or vice versa - total, name and bar on top - partial, name and bar under - but grouped logically... O):

 

[fonzacus]

awesome job

been using it for months and can say this is a pretty sweet aio toolbox more suited for rooted users. it can be used just fine on non rooters to help a bit with performance with always running apps

id like to humbly make a suggestion. is it possible to include a host blocker? the droid /sys/etc/hosts requires a full reboot unlike pcs, and is very inconvenient imho

i stumbled upon a github project and hopefully you could take a peak (also has its own dns)
github.com/x-falcon/Virtual-Hosts

with the way how modern isps are operating, is it possible to somehow prevent our isps from "blocking" (lack of better word) our dns? many sites are still being blocked despite many free public dns dont
also happens on pcs but thats another topic

 

[白い熊]

@3c — hi. Could you implement Restore only data and settings from shortcut for a specific app, please?

I have one app that consistently misbehaves and lose cache or data or something regularly — so I have to keep restoring data and settings only regularly. I have a shortcut for full restore for it — but it's unnecessary and full restore takes too long… :O)

Many thanks.

 

[白い熊]

@3c there is still some serious problem with the implementation of firewall rules and their updates. I regularly find that for some particular app tse rules are messed up - most notably Firefox Nightly: gets updated from the Play store nightly and it's a hit and miss - often after the update it has no internet access rights in the firewall.

I use whitelisting - no default access - Firefox obviously has access set, so how come it gets toggled off? Is it some update of permissions from backup or whatever.

Anyhow - just now - figured out another issue with it:

all of a sudden Play Store told me “offline” - so went to firewall, found out it was off! How? Anyhow toggled it on - then checked its app permissions - and saw Full internet access is off. Even after toggle of firewall whitelist status off and on again Full internet access stays off.

Nota bene - I never set it to off, as I use the Play Store - so how come it was toggled off - and by what? Any ideas on this?

 

[3c]

@3c there is still some serious problem with the implementation of firewall rules and their updates. I regularly find that for some particular app tse rules are messed up - most notably Firefox Nightly: gets updated from the Play store nightly and it's a hit and miss - often after the update it has no internet access rights in the firewall.

I use whitelisting - no default access - Firefox obviously has access set, so how come it gets toggled off? Is it some update of permissions from backup or whatever.

Anyhow - just now - figured out another issue with it:

all of a sudden Play Store told me “offline” - so went to firewall, found out it was off! How? Anyhow toggled it on - then checked its app permissions - and saw Full internet access is off. Even after toggle of firewall whitelist status off and on again Full internet access stays off.

Nota bene - I never set it to off, as I use the Play Store - so how come it was toggled off - and by what? Any ideas on this?

Hello and sorry for the inconveniences. I'm testing this right now, but have never seen such issues so far.

Note that app stores access by app UID (an ID "calculated" by OS at install time) so it should never change when updating the app, unless you uninstall it.
The the app will also double-check package name to ensure its configuration is still valid for the package being configured/updated/installed.

If either of those changes the app/package is considered "new" and unconfigured. Hence in a white-listing mode will not get internet.


What "full internet access" permission are you referring to ? Are you using Xposed ?
Can you post some screenshots to clarify the situation?

 

[白い熊]

Hello and sorry for the inconveniences. I'm testing this right now, but have never seen such issues so far.

Note that app stores access by app UID (an ID "calculated" by OS at install time) so it should never change when updating the app, unless you uninstall it.
The the app will also double-check package name to ensure its configuration is still valid for the package being configured/updated/installed.

If either of those changes the app/package is considered "new" and unconfigured. Hence in a white-listing mode will not get internet.


What "full internet access" permission are you referring to ? Are you using Xposed ?
Can you post some screenshots to clarify the situation?

I was translating from Japanese — I switched the Toolbox UI to English now, so that I have proper naming. And right after I wrote it — it happened again, so I can describe:

So Firefox nighty - what happens:

- Update Firefox from the Play Store
- No webpage opens in it
- I go to the Toolbox Firewall page - it's in whitelist mode
- Find out Firefox is unticked in both Wi-Fi and APN columns
- Tick both
- Switch to the Applications tab, find Firefox
- Click Manage - Permissions
- In the Permissions tab then, discover that “have full network permissions” is off - even though I whitelisted it before in the Firewall tab
- Toggle this to on
- Now Firefox has web access
- After next update from Play Store the full scenario repeats

I.e. the toolbox “unticks” both columns in the Firewall tab, this results in the “have full network permissions” to be toggled off in the Permissionn tabs.

It must be reading it from somewhere - or it must be associated somehow with whitelist peculiarity - or it must have something to do with applying the IP rules - without reboot. Do you have it set somewhere that it's only fully applied on reboot or whatever - I don't know.

It is problematic anyhow - I think if I toggle and untoggle tse rules in the Firewall tab this should be propagated immediately to affected apps “have full network permissions”.

Or there should be some “Apply firewall rules” button or what have you - but it must be ensured that somehow the firewall Settings are independently and reliably preserved.

Like this it's really a pain… :O)

 

[3c]

I was translating from Japanese — I switched the Toolbox UI to English now, so that I have proper naming. And right after I wrote it — it happened again, so I can describe:

So Firefox nighty - what happens:

- Update Firefox from the Play Store
- No webpage opens in it
- I go to the Toolbox Firewall page - it's in whitelist mode
- Find out Firefox is unticked in both Wi-Fi and APN columns
- Tick both
- Switch to the Applications tab, find Firefox
- Click Manage - Permissions
- In the Permissions tab then, discover that “have full network permissions” is off - even though I whitelisted it before in the Firewall tab
- Toggle this to on
- Now Firefox has web access
- After next update from Play Store the full scenario repeats

I.e. the toolbox “unticks” both columns in the Firewall tab, this results in the “have full network permissions” to be toggled off in the Permissionn tabs.

It must be reading it from somewhere - or it must be associated somehow with whitelist peculiarity - or it must have something to do with applying the IP rules - without reboot. Do you have it set somewhere that it's only fully applied on reboot or whatever - I don't know.

It is problematic anyhow - I think if I toggle and untoggle tse rules in the Firewall tab this should be propagated immediately to affected apps “have full network permissions”.

Or there should be some “Apply firewall rules” button or what have you - but it must be ensured that somehow the firewall Settings are independently and reliably preserved.

Like this it's really a pain… :O)

You didn't say if you have xposed framework and if toolbox module is enabled ? So I'm asking *again*...

That said, the "have full network permissions" only reflect firewall tab settings but only if you have xposed. Otherwise it's just stay active as per OS settings, so without Xposed it has nothing to do with firewall rules.

In any case I did a test in whitelist mode, with many apps, about 10. As far as I can tell it's perfectly reliable and I couldn't reproduce your issue.


It's clear I'm missing information about your device, starting with Android version and support information and logs taken during the update as specified in #2.

Please provide support request data by using app's settings, help and support, starting a debug session, then reproducing the steps of updating firefox, then sending the support request or attaching the support data here.


Please note that if you uninstall the app, it will reset firewall rules, and there's no way around it to avoid another app from using uninstalled app settings.

 

[白い熊]

You didn't say if you have xposed framework and if toolbox module is enabled ? So I'm asking *again*...

That said, the "have full network permissions" only reflect firewall tab settings but only if you have xposed. Otherwise it's just stay active as per OS settings, so without Xposed it has nothing to do with firewall rules.

In any case I did a test in whitelist mode, with many apps, about 10. As far as I can tell it's perfectly reliable and I couldn't reproduce your issue.


It's clear I'm missing information about your device, starting with Android version and support information and logs taken during the update as specified in #2.

Please provide support request data by using app's settings, help and support, starting a debug session, then reproducing the steps of updating firefox, then sending the support request or attaching the support data here.


Please note that if you uninstall the app, it will reset firewall rules, and there's no way around it to avoid another app from using uninstalled app settings.

Sorry - missed it - yes LSposed, and active.

It seems to work one way though - when the app's internet permissions are unchecked in the Firewall - it toggles the internet access in permissions of - however when internet is toggled to allowed in firewall - it doesn't toggle it back on in permissions.

That's why I was thinking it's not fully reloading - or, now it occurred to me, could it be that it's just not rereading the app's permissions for updating the display in the Permissions tab without Toolbox restart?

I'll try to start a debug session tomorrow before update - to record it and see what's up?

Do you want me to send the support request even before that, now - so you can inspect the setup?

 

[白い熊]

OK - there was a new update now, so started a debug session to reproduce, ran the update - and what would you guess? It didn't mess up the firewall settings…

Ugh, I understand it's impossible to track without cleanly reproducing like this…

Perhaps - if I could ask, just to think on what might be causing it in a non-100% of cases: which actions, and with what delay affect iptables settings thus?

- Does toggling an individual app in the Firewall tab get set immediately, or does the Toolbox have to be restarted.
- Importing Toolbox settings - is it effective on reboot WRT Firewall?
- Anything else?

 

[白い熊]

OK, now it happened again. I started a debug session before update - updated the app from the store, after update checked the firewall tab - it showed access allowed, opened Firefox, it loaded a page.

Then restarted - no access - firewall show Firefox unticked, before restart it showed no change in the top “apply on boot” icon.

So something is misbehaving - WRT to reading the firewall settings on boot, it's apparent that even when it shows in the firewall tab that this is to be applied on boot - it hasn't been either saved, or refreshed from the tab - or it's reading firewall permissions on boot from somewhere and these are not immediately in synch with what the firewall tab shows you during usage - but something is up…

 

[3c]

OK, now it happened again. I started a debug session before update - updated the app from the store, after update checked the firewall tab - it showed access allowed, opened Firefox, it loaded a page.

Then restarted - no access - firewall show Firefox unticked, before restart it showed no change in the top “apply on boot” icon.

So something is misbehaving - WRT to reading the firewall settings on boot, it's apparent that even when it shows in the firewall tab that this is to be applied on boot - it hasn't been either saved, or refreshed from the tab - or it's reading firewall permissions on boot from somewhere and these are not immediately in synch with what the firewall tab shows you during usage - but something is up…

What is showed in firewall tab is what is currently applied and if on-boot button is blue, that is what is saved.

If it resets on reboot it means the app found the UID or app package name have changed. That's the only thing that will reset firewall rules for an app. So next time it happens, please check app's UID and package name in details tab.

If after next update it resets firewall before reboot, send a support request mentioning it.

If it doesn't please take a screenshot of detail's page showing UID and package name before reboot. Upon reboot try to send a support request as soon as possible, check firewall rules and if reset send a support request again. The idea is to get the logs when the app will apply firewall rules and with recent Android versions it's hard to tell when it will happen so sending the request will help get the appropriate logs.

 

[ZappaDong]

Pixel 4a, Android 13 (German UI), Version 2.6.7 (and older)

Since Android 13 the "Force-stop all included apps" does not stop the apps anymore.
As everything worked fine before Android 13 I assume this is a problem with the Android 13 UI.

The app-info-panel for every app is opened but the "Force Stop" ("Beenden erzwingen" in German) button is not pressed in 3 of 4 cases. On the second run the function sometimes stops at the last info-panel keeping the panel open. It has to be closed manually.

On the first and second run you can "help" the function by quickly pressing the "Force Stop" button yourself and the following dialog is pressed automatically.


A feature request/idea:
Can you place a "transparent layer" over the app-info panels? SD Maid uses the same info panel to empty app caches. And to avoid flickering a grey layer is put over the panels first. This makes all the fast panel opening and closing less looking like a light show in the evening.
(I am using android in standard light mode)

 

[3c]

Pixel 4a, Android 13 (German UI), Version 2.6.7 (and older)

Since Android 13 the "Force-stop all included apps" does not stop the apps anymore.
As everything worked fine before Android 13 I assume this is a problem with the Android 13 UI.

The app-info-panel for every app is opened but the "Force Stop" ("Beenden erzwingen" in German) button is not pressed in 3 of 4 cases. On the second run the function sometimes stops at the last info-panel keeping the panel open. It has to be closed manually.

On the first and second run you can "help" the function by quickly pressing the "Force Stop" button yourself and the following dialog is pressed automatically.


A feature request/idea:
Can you place a "transparent layer" over the app-info panels? SD Maid uses the same info panel to empty app caches. And to avoid flickering a grey layer is put over the panels first. This makes all the fast panel opening and closing less looking like a light show in the evening.
(I am using android in standard light mode)

Well, you seem lucky to get it to work 3 times out of 4, as for me it doesn't at all! Simply because the OS doesn't give the app the popup information to access the OK button at all !?

Google has changed reported information and messing with accessibilty filtering seems to bring back the information. What a mess and what a pain to test/debug as I just re-enabled the accessibility service a good hundred times to get the missing data!

An update has been published on Play Store with a fix for that (beta 2.6.8).

 

[ZappaDong]

An update has been published on Play Store with a fix for that (beta 2.6.8).

Thank you.

I have joined the beta program now and will give it a try.

 

[3c]

A feature request/idea:
Can you place a "transparent layer" over the app-info panels? SD Maid uses the same info panel to empty app caches. And to avoid flickering a grey layer is put over the panels first. This makes all the fast panel opening and closing less looking like a light show in the evening.
(I am using android in standard light mode)

Forgot to mention if you grant 'draw over other apps' to the app, it'll do just that.

 

[白い熊]

What is showed in firewall tab is what is currently applied and if on-boot button is blue, that is what is saved.

If it resets on reboot it means the app found the UID or app package name have changed. That's the only thing that will reset firewall rules for an app. So next time it happens, please check app's UID and package name in details tab.

If after next update it resets firewall before reboot, send a support request mentioning it.

If it doesn't please take a screenshot of detail's page showing UID and package name before reboot. Upon reboot try to send a support request as soon as possible, check firewall rules and if reset send a support request again. The idea is to get the logs when the app will apply firewall rules and with recent Android versions it's hard to tell when it will happen so sending the request will help get the appropriate logs.

I might have an idea of what's going on - I've seen toggling FK checkboxes doesn't update the Permissions tab on App details WRT the internet access before reboot - so it could have been that I was toggling it on in the Permissions tab - but something else was set in the FW tab, then on reboot it got lost.

Anyhow tried now - setting the FW tab properly and immediately rebooting - access is on after reboot - gets preserved.

Three issues:

- Why the reboot? Why doesn't it propagate immediately to the Permissions tab and from it - back and forth on toggle everywhere? I.e. if you uncheck internet access in Permissionn, FW page should show you updated settings and they should be saved for boot…
- Sometimes I have to clear whitelisting completely and allow everything, to check for problems - if I forget this and don't reread the boot FW settings and reboot - the FW on reboot is empty and cannot be reloaded on the bottom.
- Finally - do you really save it by uid? If so, isn't that flawed? Meaning I export the toolbox settings before
system upgrade - then obviously all app uids are different on restore. Shouldn't it be saved just by package id - unless I'm reading you wrong. But thenga change of uid wouldn't be a problem no?

 

[3c]

I might have an idea of what's going on - I've seen toggling FK checkboxes doesn't update the Permissions tab on App details WRT the internet access before reboot - so it could have been that I was toggling it on in the Permissions tab - but something else was set in the FW tab, then on reboot it got lost.

Anyhow tried now - setting the FW tab properly and immediately rebooting - access is on after reboot - gets preserved.

Three issues:

- Why the reboot? Why doesn't it propagate immediately to the Permissions tab and from it - back and forth on toggle everywhere? I.e. if you uncheck internet access in Permissionn, FW page should show you updated settings and they should be saved for boot…
- Sometimes I have to clear whitelisting completely and allow everything, to check for problems - if I forget this and don't reread the boot FW settings and reboot - the FW on reboot is empty and cannot be reloaded on the bottom.
- Finally - do you really save it by uid? If so, isn't that flawed? Meaning I export the toolbox settings before
system upgrade - then obviously all app uids are different on restore. Shouldn't it be saved just by package id - unless I'm reading you wrong. But thenga change of uid wouldn't be a problem no?

I've never needed to reboot, so I'm not sure why you would need to. There is no propagation to the permission tab as firewall rules apply to network access, it's the other way around, when blocking permission it uses the firewall.
It seems like a UI glitch, but I'll have to enable Xposed on my device to test this more closely.

About changing whitelisting and clearing everything, I see the on-boot button gets red so that change is not saved and this would restore original settings upon reboot... Just make sure for them to be loaded...
That is wait for stupid OS to have run all apps that have requested to run on boot, which can take minutes since one of those *** Android updates.
I tested and it worked as designed. reload even reloaded settings before they were applied.

Firewall rules are applied based on UID, so they are saved based on that and with package name. UIDs are then auto-adjusted upon restoring toolbox settings.
So there's no actual problem.

 

[白い熊]

I've never needed to reboot, so I'm not sure why you would need to. There is no propagation to the permission tab as firewall rules apply to network access, it's the other way around, when blocking permission it uses the firewall.
It seems like a UI glitch, but I'll have to enable Xposed on my device to test this more closely.

OK – however, I've established the following:

If no access is whitelisted in Firewall tab, I then whitelist it in Firewall tab, it is not propagated to Permissions tab - moreover no access is granted to the app, until I also toggle it on in the Permissions tab - that's when access is granted immediately.

If, on the other hand, I toggle it on in the Firewall tab, then reboot - then open the Permissions tab - it's been propagated now, internet access is now on, and app has access.

Sounds like some interplay between the Firewall tab and Xposed - i.e. when does Xposed read the status and show it in the Permissions tab.

Moreover - without a reboot - if the internet access is off as seen by Xposed and shown on the Permissions tab, toggling it on in the Firewall tab doesn't give the app the access.

It's only received - either by manually toggling the internet access on in the Permissions tab - or by rebooting.