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

[3c]

Hello 3C,

Is there any chance /situation that "real-time-data" does log less data than "every 60s"? I cannot do a comparison because of course I cannot collect data with both frequency at the same time....

I'm sorry I don't understand the question. Real-time correspond to every-time the OS sends data update, which is often the most accurate however logging rate is undefined and adapt itself to the situation and data variations.

Logging less data than every 60 seconds, then use an interval delay however it will be far less accurate.

With real-time data you can long-press history and tap 'shows % changes only'. Either way I don't understand how it prevents collecting data or doing a comparison? What are you trying to compare in the first place?

 

[白い熊]

@3c I think you have substring search implemented when filtering by tag:

I have "freeze" and "nonfreeze" tags – when I select "freeze" as the filter it also lists the "nonfreeze" apps. This is undesirable I think.

 

[pz4551]

I'm sorry I don't understand the question. Real-time correspond to every-time the OS sends data update, which is often the most accurate however logging rate is undefined and adapt itself to the situation and data variations.

Logging less data than every 60 seconds, then use an interval delay however it will be far less accurate.

With real-time data you can long-press history and tap 'shows % changes only'. Either way I don't understand how it prevents collecting data or doing a comparison? What are you trying to compare in the first place?

I want to collect data with the maximum accuracy possible.

I did a short study:

Galaxy S6 Edge is left untouched with display off from midnight to 6 AM and not plugged in.

Test 1 with Setting "log every minute": 72 log entries.
'11.01.2022 00:04:53'
'11.01.2022 00:09:52'
'11.01.2022 00:14:52'
'11.01.2022 00:19:52'
'11.01.2022 00:24:52'
'11.01.2022 00:29:52'
...
1.01.2022 05:44:52'
'11.01.2022 05:49:52'
'11.01.2022 05:54:52'
'11.01.2022 05:59:52'

Test 2 with Setting "Real Time": 13 log entries.
'12.01.2022 00:16:53'
'12.01.2022 00:47:52'
'12.01.2022 01:14:36'
'12.01.2022 01:37:13'
'12.01.2022 02:07:14'
'12.01.2022 02:30:22'
'12.01.2022 03:00:55'
'12.01.2022 03:32:07'
'12.01.2022 04:02:39'
'12.01.2022 04:33:26'
'12.01.2022 05:04:00'
'12.01.2022 05:39:30'
'12.01.2022 05:41:47'


Apparently the app is sent to sleep somehow and does not log every 60s.
With log setting "every 60s" this results in a log entry every 5 minutes. And "real time" every 15-30 minutes....

If display is turned on, the app does indeed log every 60s, example here:
'09.01.2022 08:36:29'
'09.01.2022 08:37:29'
'09.01.2022 08:38:29'
'09.01.2022 08:39:30'

 

[3c]

I want to collect data with the maximum accuracy possible.

I did a short study:

Galaxy S6 Edge is left untouched with display off from midnight to 6 AM and not plugged in.

Test 1 with Setting "log every minute": 72 log entries.
'11.01.2022 00:04:53'
'11.01.2022 00:09:52'
'11.01.2022 00:14:52'
'11.01.2022 00:19:52'
'11.01.2022 00:24:52'
'11.01.2022 00:29:52'
...
1.01.2022 05:44:52'
'11.01.2022 05:49:52'
'11.01.2022 05:54:52'
'11.01.2022 05:59:52'

Test 2 with Setting "Real Time": 13 log entries.
'12.01.2022 00:16:53'
'12.01.2022 00:47:52'
'12.01.2022 01:14:36'
'12.01.2022 01:37:13'
'12.01.2022 02:07:14'
'12.01.2022 02:30:22'
'12.01.2022 03:00:55'
'12.01.2022 03:32:07'
'12.01.2022 04:02:39'
'12.01.2022 04:33:26'
'12.01.2022 05:04:00'
'12.01.2022 05:39:30'
'12.01.2022 05:41:47'


Apparently the app is sent to sleep somehow and does not log every 60s.
With log setting "every 60s" this results in a log entry every 5 minutes. And "real time" every 15-30 minutes....

If display is turned on, the app does indeed log every 60s, example here:
'09.01.2022 08:36:29'
'09.01.2022 08:37:29'
'09.01.2022 08:38:29'
'09.01.2022 08:39:30'

All this is coincidental. App is not put to sleep, it's the whole device is in deep sleep and waking up only when needed. When I use my device it logs more frequently than every minute. And at night I sometimes get only 2 logs or 20, depending on how busy the device gets or how many poorly developed apps are waking-up the device.

If you want 1-minute interval logging, eg "relative maximum accuracy", simply select that option. But if you see battery draining more than usual at night don't be surprised.

Given you experienced both, what are the actual battery drain at night you see and your estimated gain using 1-minute vs real-time?

 

[pz4551]

All this is coincidental. App is not put to sleep, it's the whole device is in deep sleep and waking up only when needed. When I use my device it logs more frequently than every minute. And at night I sometimes get only 2 logs or 20, depending on how busy the device gets or how many poorly developed apps are waking-up the device.

If you want 1-minute interval logging, eg "relative maximum accuracy", simply select that option. But if you see battery draining more than usual at night don't be surprised.

Given you experienced both, what are the actual battery drain at night you see and your estimated gain using 1-minute vs real-time?

I dont see big differences. After all, we are talking about only 59 additional log entries in 6 hours. No too much.

Do you know how with what frequency the average current value is updated?

 

[3c]

I dont see big differences. After all, we are talking about only 59 additional log entries in 6 hours. No too much.

Do you know how with what frequency the average current value is updated?

That depends on device and manufacturer, I've never seen any precise rule as your previous post shows, it's very inconsistent.
Google have set some rules asking manufacturer to report in micro-Amp (positive when charging) but it is barely followed, even Pixel devices don't keep up with this rule!

 

[pz4551]

My summary would then be for myself:

1. Use the most lightweight app so a wake-up of the device/app leads to little processor load.
2. Logging short term/at the beginning: Log Current Now & Current Averaged with a very high frequency. (1s?)
3. With that data: Find out how often the averaged current is updated for the device type
4. Logging long term: Set the logging frequency to the actual update frequency of current average

 

[3c]

My summary would then be for myself:

1. Use the most lightweight app so a wake-up of the device/app leads to little processor load.
2. Logging short term/at the beginning: Log Current Now & Current Averaged with a very high frequency. (1s?)
3. With that data: Find out how often the averaged current is updated for the device type
4. Logging long term: Set the logging frequency to the actual update frequency of current average

To determine your device update frequency open status tab and tap mA value repeatedly and you'll see it updates after the actual interval.

 

[pz4551]

To determine your device update frequency open status tab and tap mA value repeatedly and you'll see it updates after the actual interval.

Great suggestion.

My results:

		Update frequency of „Current Avg.“ Analysis through Manual Tapping in 3c toolbox	Update frequency of „Current Now“ Analysis through logging another app (logs every few milliseconds)
MS	Google Nexus 7	1s	1s
UA	Samsung Galaxy S6 Edge	30s	10s

My conclusion:

• 60s update is not enough to capture either 1s or 30s...
• Real-time frequency is also not frequent enough as it is even less frequent.

Next, I will use "log every 5 second during charging" for now and will only use the data during charging.
Let's see if results change.

Thank you.

My wish would still be to allow the user to set logging frequency in seconds manually (text input field), but I understand that you get worse user review then.

 

[白い熊]

@3c I think you have substring search implemented when filtering by tag:

I have "freeze" and "nonfreeze" tags – when I select "freeze" as the filter it also lists the "nonfreeze" apps. This is undesirable I think.

It is definitely undesirable - as it also has an effect the "opposite" way:

If you filter for exclusion of apps tagged "freeze" it will not list any app tagged "unfreeze" as of course the "freeze" substring is picked up by the filter there.

I think the filtering by tags should definitely work by the full string of the tag's name, not substring.

 

[3c]

It is definitely undesirable - as it also has an effect the "opposite" way:

If you filter for exclusion of apps tagged "freeze" it will not list any app tagged "unfreeze" as of course the "freeze" substring is picked up by the filter there.

I think the filtering by tags should definitely work by the full string of the tag's name, not substring.

It is fixed in 2.5.7 (in beta).

 

[bege10]

It's usually based on memory usage but Google is being more and more obscure about why it does what it does. I remember the days where apps with widgets were killed while others like net browsers were not, so nothing surprises me anymore.

Looking at your logs the OS kills an app that has 4+ services running... And it restarts them immediately!?

I will monitor my device for such thing to try to understand what's going on.

After your relating fixes it takes 4 instead of 3 days to get the tombstones folder filled with 50 entries regarding the 3C library.
Is there anything more you found out? Is there something the devs of LineageOS or /e/OS can do? Is there something you can do that 3C Toolbox is not being killed by the system?
There is an extremely unpleasant situation when 3C Toolbox is being killed: Shortly before a scheduled task should start. That task will not start as it happened here with a daily backup.

 

[Kay Kostrowski]

Hello everybody and thank you so much for that wounderful convolute
of all the stuff, I used to scan playstore up and down, untill I have found 3C last autum and just changed playstore to instructions and threads on 3c71 and here at xda before asking every allready answerd question again.

I hope I also will support this thread with some productive questions and input in future.

Regarding to Bege10 worries about app kills by daily new suprising reasons, this is my biggest disappointment of the app, too.
Especially loseing Companion-tool privilegs after every unsuccessful kill attempt by google is so sad.... still alive somehow, but more like disabled zombie mode and not predictable to have PC around.
Since ccc71 I am only restarting my phone -and loseing Companion tool-
when there is my computer within range of 1meter to restart it right again after. But there is allways something kickingaccessibility permissions most of the times and sometimes one of the other permissions. So I am loosing the toolbox step by step and lose it at some point.

So,my question and wish would be some kickstart / reset button of Companion tool right on mobile phone without any need of computer and USB ADB.

Couple days ago I have found a thread how to directly use ADB from phone via Wifi debugging and some kind of self breeding by sending the signal in a circle from one app via wifi to another receiving app on same phone.

I haven't had time to follow that idea so far, but maybe it might be some Idea for walkaround to use the Companion tool or at least a refresh command, after once fully installed via USB and computer, right from mobile phone.

For me, the pain from beaten up by Google would be much smaller with oportunity to just restart app again.
My suggestion for internal project name for a restart button:
= Don Quixote =

Thanks for reading my first post on xda ever,
but way more for outstanding support around 3C over the years!

Kay

 

[3c]

Hello everybody and thank you so much for that wounderful convolute
of all the stuff, I used to scan playstore up and down, untill I have found 3C last autum and just changed playstore to instructions and threads on 3c71 and here at xda before asking every allready answerd question again.

I hope I also will support this thread with some productive questions and input in future.

Regarding to Bege10 worries about app kills by daily new suprising reasons, this is my biggest disappointment of the app, too.
Especially loseing Companion-tool privilegs after every unsuccessful kill attempt by google is so sad.... still alive somehow, but more like disabled zombie mode and not predictable to have PC around.
Since ccc71 I am only restarting my phone -and loseing Companion tool-
when there is my computer within range of 1meter to restart it right again after. But there is allways something kickingaccessibility permissions most of the times and sometimes one of the other permissions. So I am loosing the toolbox step by step and lose it at some point.

So,my question and wish would be some kickstart / reset button of Companion tool right on mobile phone without any need of computer and USB ADB.

Couple days ago I have found a thread how to directly use ADB from phone via Wifi debugging and some kind of self breeding by sending the signal in a circle from one app via wifi to another receiving app on same phone.

I haven't had time to follow that idea so far, but maybe it might be some Idea for walkaround to use the Companion tool or at least a refresh command, after once fully installed via USB and computer, right from mobile phone.

For me, the pain from beaten up by Google would be much smaller with oportunity to just restart app again.
My suggestion for internal project name for a restart button:
= Don Quixote =

Thanks for reading my first post on xda ever,
but way more for outstanding support around 3C over the years!

Kay

If you set adb wifi (adb tcpip something, should be documented on companion page), this will help the app to make it survive kills.

Also, to avoid (or reduce) app kills you can add a notification shortcut that will tell the OS the app is on foreground, which in turn might help keep companion features alive longer.

 

[3c]

After your relating fixes it takes 4 instead of 3 days to get the tombstones folder filled with 50 entries regarding the 3C library.
Is there anything more you found out? Is there something the devs of LineageOS or /e/OS can do? Is there something you can do that 3C Toolbox is not being killed by the system?
There is an extremely unpleasant situation when 3C Toolbox is being killed: Shortly before a scheduled task should start. That task will not start as it happened here with a daily backup.

There's no much I can do while Google still believe their oom system is best and smartest of all, but still keeps killing apps having active service, even widgets.

That said, of you add a notification shortcut it will tell the OS that the app is active and might help prevent the killings.

 

[白い熊]

@3c which properties of managed apps are dependent on the xposed module? Only networking?

I'm asking because now on A12 I have to use LSPosed and so need to whitelist all the apps to be affected by the module, so need to know what is effectively managed outside of the module scope.

 

[ciclolars]

Does the app provide an alarm or notification if battery reaches or drops above or below a certain percentage? I cannot find this option.
Thanks in advance!
This is an awesome app that is always on my android devices, thanks @3c

 

[3c]

Does the app provide an alarm or notification if battery reaches or drops above or below a certain percentage? I cannot find this option.
Thanks in advance!
This is an awesome app that is always on my android devices, thanks @3c

Yes, in device manager, watchers tab.

 

[白い熊]

@3c which properties of managed apps are dependent on the xposed module? Only networking?

I'm asking because now on A12 I have to use LSPosed and so need to whitelist all the apps to be affected by the module, so need to know what is effectively managed outside of the module scope.

Also, which operations does the additional “System helper” provide? Its description only says “additional” – I'm trying to see whether it's beneficial for me to have it installed.

 

[3c]

Also, which operations does the additional “System helper” provide? Its description only says “additional” – I'm trying to see whether it's beneficial for me to have it installed.

Mainly permission control and battery icons (notification settings), the others can be achieved without Xposed (using logcat), and include app's management control (full-screen, rotate, lock, etc). The app will tell you it's missing xposed if you just don't enable the module when stumbling on a feature that needs it. Unless you hide them.

System helper adds many toggles and ability to turn on/off wifi/apn and other things, can be quite useful.

Can't make an exhaustive list as it keeps changing with every version of Android and I lost track of the mess left by Google when things become possible with helper in Android vX and then no more in vY and again in vZ.