yashsingh1/xdaforums huggingface dataset:
[Android Apps and Games] 3c:
Indeed ;)

Got a Pixel 6 and found the problem, hard to believe.

If you try that command using root, the phone will reboot instantly:

cat /sys/devices/system/exynos_info/core_status

Other than that the app would work perfectly :) LOL

EDIT: I've published beta 2.5.4a a few minutes ago and it should be available soon.

Note that it now targets API 30 and tries to request MANAGE_ALL_FILES permission which Google is restricting and may refuse for the toolbox, fingers crossed.
[Android Apps and Games] Lughnasadh:
That's pretty funny...Exynos. Well, everyone says it's pretty much a Exynos chip. Guess this is Google admitting it now 😜

Thanks for checking that out so quickly. Much appreciated. Glad you got the phone. I'll check out the new beta when it shows up. 👍
[Android Apps and Games] Lughnasadh:
Yep, that fixed it. No more reboots. Thank you so much. Really appreciate it 👍
[Android Apps and Games] 3c:
You're very welcome. Thanks for letting me know in the first place. I didn't pre-ordered one of the Pixel 6 hoping it will go smoothly with this new CPU, and I was wrong, so much thanks for your help.
[Android Apps and Games] bege10:
@3c It looks like the tombstones have become less, but they are still being created regularly. All contain liblib3c.so.
[Android Apps and Games] 3c:
Thanks for the logs and tombstones.

Could you get more logs before the crash occurs, cause in that log the root cause is not really explained at all.

The call stack suggests it crashed in the OS when starting the library, but gives no further indication on what caused the OS to kill the process and the whole app altogether.

11-22 13:34:49.966 2446 2539 I libprocessgroup: Successfully killed process cgroup uid 10319 pid 8393 in 591ms
11-22 13:34:49.966 2446 3652 W ActivityManager: Scheduling restart of crashed service ccc71.at.free/lib3c.indicators.lib3c_indicators_service in 1000ms
11-22 13:34:49.967 2446 3652 W ActivityManager: Scheduling restart of crashed service ccc71.at.free/lib3c.controls.xposed.lib3c_logcat_service in 11000ms
11-22 13:34:49.967 2446 3652 W ActivityManager: Scheduling restart of crashed service ccc71.at.free/lib3c.app.battery_monitor.service.battery_service in 21000ms
11-22 13:34:49.967 2446 3652 W ActivityManager: Scheduling restart of crashed service ccc71.at.free/lib3c.app.app_manager.services.app_installed_service in 31000ms
11-22 13:34:49.971 2446 3652 W ActivityManager: Scheduling restart of crashed service ccc71.at.free/lib3c.widgets.lib3c_widgets_service in 41000ms

The above suggests the OS just stopped the toolbox entirely and caused its libraries to be stopped and thus created the tombstones. As I didn't get any tombstones since last time, I wonder if you have something stopping the toolbox and possibly creating that issue?

So, if you can get older logs before the crash occurs that might shed some light on this.
[Android Apps and Games] bege10:
Is this enough or do you need it further back?
[Android Apps and Games] 3c:
Yes that's enough. 15 seconds or so before the crash is generally enough. Based on that, I suspected the OS to kill the app, which in turn would crash the library and in turn create the tombstone.

So, I did some testing on my device and manually killed the toolbox background process (as it happens in your logs), and it actually created the issue you're experiencing.

There is truely nothing I can do about it as this problem is created by the OS killing the app without doing proper clean-up of the mess it creates and creating a tombstones needlessly.

Actually I could *try* using native code exception handling, however it would triple the size of the library and there's very little chance it'll work at all considering it's the OS call that's crashing, not the library.
[Android Apps and Games] bege10:
I have a number of background processes with root access and the toolbox is the only one tombstones are created for. So the toolbox is the only app the OS "does not like".

Can you see what the OS exactly does and why? Why does it kill just the toolbox?

Is there any permission missing? The toolbox here does not have permission to access camera and contacts because they are not needed for the functions I use. Network access is only for Wifi, no access while DND. All other permissions are granted.
[Android Apps and Games] 3c:
It seems to be the Android OOM that decides the app is not needed and actually reschedule it for restart. It's what Google would call a normal behavior.

The tombstone is created because I use a native library which is interconnected with the app and running as root. Well it's created because the OS is too stupid to realize it is itself the root cause of the crash, the crash happening in the OS functions...

If you don't want any tombstone just change the security context of the tombstone folder so that the OS can't create files in it. To do that you can simply delete and recreate the folder with any root app.
[Android Apps and Games] bege10:
Thank you for your answer. Well, I mind the tombstones least. I mind the app being killed. The system is not OOM and other apps are not being killed. If I look at the OOM tab in the toolbox I see that the toolbox is in the "secondary server" section (translated from German locale). The other apps in that section are not killed. What may be the reason that the OS kills just the toolbox?
[Android Apps and Games] 3c:
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.
[Android Apps and Games] bege10:
If you find out more details I will file an issue at the OS issue tracker.
[Android Apps and Games] 白い熊:
@3c I'm having an issue performing a full backup of one game: Street Fighter IV CE, jp.co.capcom.sf4ce

It downloads resource files and extracts them to /data/user/0/jp.co.capcom.sf4ce – which is mirrored to /data/user/0/jp.co.capcom.sf4ce – nothing in Android/obb/jp.co.capcom.sf4ce

The size of /data/user/0/jp.co.capcom.sf4ce is 2.2 GB. Now, the backup tool 37 MB, i.e. this is not backed up – won't be restored properly.

Could you advise?
[Android Apps and Games] 3c:
You might want to let the backup process the files, cause 2.2GB could take quite some time to backup depending on your device. Can you list the whole content that takes 2.2GB? Is there a big file or a lot of small files?

I'm installing it and will run some tests here to double-check what could happen.
[Android Apps and Games] 白い熊:
OK – I'm starting to think this is a broader issue, connected with the all app access on Android 11.

I tried backing up another smaller game – and sure enough, nothing out of its /data/data/ dir got backed up.

On a hunch opened /data/data in 3C file manager – and it sees it as almost empty – only seeing the two following directories inside it:

ccc71.at.free

com.google.android.gms

Nothing else… No wonder nothing gets backed up, that's in a /data/data/ subdir.
[Android Apps and Games] cbomb1337:
Ty for the beta update for Google pixel.
[Android Apps and Games] 白い熊:
@3c maybe the problem is on my side: it doesn't restore the /data/data and Android/data contents.

So, for valid backups I have – the contents of name.zip and the extra_data zips stored in the backup's data subdirectory won't be restored . I even uninstalled the toolbox, and clean installed from Play Store.

The Android/obb does get restored on restore. So for the Android subdir the non-restore shouldn't be caused by access rights.

Any idea what could be causing it?

OK – something must be going on here: even when I access /data/data with a root file manager, I only see the file manager's subdir and Google GMS subdir – although Termux shows me full /data/data contents, so something is not right.

What could be going on? What can be causing this?
[Android Apps and Games] 3c:
Actually, the problem is on magisk's side. You need to change the namespace mounting so that all sessions share the same. Otherwise apps have no access to /data/data subfolders even with root!

Sorry I forgot about it. Don't know why magisk is not making that the default.
[Android Apps and Games] 白い熊:
Ugh – facepalm… I totally forgot about Magisk's namespacing…

Was looking left and right, thinking: “What is happening?” Thanks.

The data is visible now – I'll try backing up the big game, just in case, but it should be solved now. :O)

Many thanks for the advice.
[Android Apps and Games] 白い熊:
Yes, it works now – many thanks.

I have two additional questions – recommendations:

1. Shouldn't all apps properties as they are modified be saved and restored with a backup?

Currently – if I backup one version of the app with, for instance full network access enabled, then disable its network access, back it up as a second backup – then if I restore the first backup, I'd expect access to be enabled and if I restore the second one, access should be disabled. This is not the current behavior – currently latest changes to properties persist through restores.

2. In the firewall tab - once I manually flip individual app settings here - I'd like to be able to export the firewall settings, so I can then import them for all apps upon toolbox reinstall.

This became painfully evident now – when I uninstalled the toolbox, reinstalled it clean and lost all firewall settings for all apps.
[Android Apps and Games] 3c:
If you reinstall toolbox clean, you'll loose all settings, not just firewall.

That said, if you backup the toolbox, or export its settings from app settings, you can restore, or import them back at any desired time. It will include firewall settings (might require a reboot), but also any other settings, like full-screen, rotation, screen-on you might have applied on other apps.
[Android Apps and Games] 白い熊:
OK – thanks.

How about part 1 above? Regarding backing up and restoring different app properties… because – I assume – app settings export and then later import will overwrite all apps' settings and I one might like to change and fiddle with them individually across backups and restores.
[Android Apps and Games] 3c:
Might be a little complicated but possible. I'll take a look.

Note that this will have to include many other settings: permissions, screen on state, rotation, full-screen, events/components disabled and a way during restore to choose whether to restore only the toolbox setting or optionnally restore them with the APK version.

There's a little bit of work, but that'll be quite cool to have that :)
[Android Apps and Games] 3c:
Just to let you know I'm about to publish an update in beta version that will backup and restore toolbox settings automatically. Toolbox settings are included with "restore data and settings" during restore if selected.

It will backup/restore the following settings:

- Firewall

- Disabled notifications

- Disabled components, *note that it will only disabled previously disabled components and a clean restore is preferable to restore state of previous components

- Screen-on, full-screen, rotation, crystalize, locked and permissions states
[Android Apps and Games] 白い熊:
You mean with each individual app's backup? Or cumulatively - for all apps together?
[Android Apps and Games] 3c:
For each app.
[Android Apps and Games] 白い熊:
Hi @3c

what do you mean by this exactly? If I back up with some permissions disabled and some enabled, then enable some and disable some, then restore – that the ones disabled in the backup will be disabled, but the ones that were backed up as enabled and then afterwards disabled, now won't be enabled on restore?

Also, that it's better to remove the app completely and then restore – rather than just restore settings? Why? This is an honest question – as in my user case, when tinkering with the app it is much preferable to restore without uninstalling.
[Android Apps and Games] 3c:
It is about components, not permissions.

The problem with that it might take a few minutes to restore ALL components states, even though user has not messed with the app in any way.

Also, on Android below 7.0, app cannot restore original state (default-state) because Android doesn't provide a way to do that, so every components will be enabled even if they are disabled by default, which could create other problems.

And it'll have to be done for every app restored no matter what.

You still have a way, before restore, to reset components manually in app's list, manage, reset.

I'll run some tests to see how it impact the overall restore time.
[Android Apps and Games] 白い熊:
@3c I have an additional improvement proposal for the freeze/unfreeze shortcut.

The user case: I have a Samsung Fold 3 – it, along with it's current root status, and Android 11, result in strange behavior: for instance Termux uses storage access privileges on reboot – however most importantly, all frozen apps are unfrozen on reboot.

So, to combat this, I've created a “Freeze” tag, filter the user and system apps by this tag on reboot, select all and freeze.

Could you add selection by tag to the freeze shortcut? This would enable me to run the freeze with one click on reboot.

I could theoretically select them all one-by-one when creating the shortcut – however sometimes my selection changes, any I freeze hundreds of apps, and there is no way to update the shortcut once created – so that's not practical.
[Android Apps and Games] pz4551:
Hello @C3.

I am a big fan of the Toolbox's capability to monitor the battery data and export them as CSV.

The capability to log battery current are not found anywhere else! Great work.

I have a question regarding the battery logging frequency (see pic)

Questions: Where can I find documentation on the offered options? Especially "Real Time".

Suggestion: Is is possible to offer more options? My suggestions:

- 5 / 10 / 30 / 60 seconds (all modes)

- 5 seconds while charging / 60 seconds in other mods

View attachment 5488479
[Android Apps and Games] pz4551:
I would like to add a separate suggestion

Is it possible to add accuracy to the State of Charge % - value?

Currently it is an integer (55%). One or two digits additional would help me out a lot (55.47%).

Background: from changes in State of Charge an average current value can be calculated between two logging points.
[Android Apps and Games] 3c:
There was no actual documentation page about this, but here it is: https://www.3c71.com/android/?q=node/2785

Note that any higher rates while charging don't usually help with accuracy, as for lower than 1 minute intervals, they have been removed quite some time ago for the same reason. Since then, I receive no more complain that the app is draining battery, app behavior reporting on Google is getting better, and again it doesn't affect accuracy because most devices report 1-minute average mA, which is hardware calculated an way more accurate.

If you have a Samsung device, those do report more accurate %, but not visible to end-user. It can be used to calculate mA (there's an option called high accuracy estimated when available), sometimes more accurately than old sensors do.

However, it's not available as a standard API, it requires root since Android M or so, and is only available on Samsung devices.
[Android Apps and Games] 3c:
I'll add an option "Freeze/unfreeze apps by tag", that should do the trick ;)
[Android Apps and Games] pz4551:
Thank you for the detailed explanations. I have switched my monitoring to Real-Time.

I am exploring the use of the toolbox for a project. The project encompasses the analysis of battery logs from different devices from different users. Analysis should access all battery logs centrally.

Is any automatic upload/aggregation feature planned which would support such a use case?

E.g. an automated upload to Google Drive or comparable?

Another idea would be an automated export to local file which could be synced then by a second app.

The toolbox seems like a perfect fit for measuring battery data. Building a dedicated app for the project seems extreme as I see that monitoring battery data across many manufacturers requires lots of adaption to the different implementations...
[Android Apps and Games] 白い熊:
Many thanks : )

Please keep in mind, it needs to be two separate actions: freeze and unfreeze, and not toggle freeze state – as is currently the case. This due to the fact that if you have a freeze tag, some of the apps might be frozen and others not – so you don't want to toggle all.
[Android Apps and Games] 白い熊:
@3c another idea I have: could you enable selecting when backing up / restoring to only backup or restore the permissions?

The reason for this: I often tinker with system apps that I have to keep, but want to disable their receivers, services etc. Examples of these include for instance Samsung Bixby, which you have to keep, as without it the power button can't be remapped – but I want to block its million services etc. So I don't want to backup the app itself, or its data – but would like too backup individually what is enabled and what disabled – so I could restore the configuration upon system upgrade, or new phone, easily.

I think this would be useful. :mad:) What do you think?
[Android Apps and Games] 3c:
I have been thinking about such thing for a long time, with the objective of comparing devices battery efficiencies, more precisely comparing consumption in standby and when screen-on, with brightness information to have a mark for comparison. The idea was not to store historical data, but the average information shown in estimates tab.

Considering the various complexities involved and the need for a server storing the stats, I never quite put it together. With new Google's rules, it's getting more annoying and adding this feature will require more time justifying it to Google than actually implemented it :(.

But it's a good idea and I'll give it some further thinking.

First, you can now add a shortcut to freeze/unfreeze/backup/restore apps by tags, in latest beta version (2.5.5).

I'll take a look at adding a separate option for restoring toolbox settings, vs apps' data. Note that it'll restore all toolbox settings, from components state (what you call permission), behavior changes, firewall and actual permissions (if using xposed).
[Android Apps and Games] 白い熊:
Thanks. Yeah – I guess I called it that since what I'm talking about is in the per-app setting, the way to get to it in the toolbox is: you click on the app, then “Manage” and then “Permissions”, right? :@)
[Android Apps and Games] 白い熊:
Hi @3c

I see you've added “restore settings only” – many thanks for this.

Could you also add a settings-only option for backup – for when you don't want to backup data?
[Android Apps and Games] 白い熊:
I just had an idea for a killer improvement for the above – could you add a restore and backup by tag shortcuts only for settings?

This would make it a killer to upgrade phones / ROMs where you've invested time into limiting components state, permissions etc. for system apps – you'd create a “Limit” tag or whatever – and then one–click backup and one click restore of just the settings for all the tagged apps – not the app, not the data.

How about this idea?
[Android Apps and Games] 3c:
Taping "permissions" gets you to permissions tab, then you tap on "receivers" or "activities".

You can get there either from task manager, or in events tab in app's manager where you get all components you can disable in one place for all apps.

Just untick 'data and settings' and you will get that. I have to change that header to 'data' only as toolbox settings are always saved.

Already added when I added freeze/unfreeze by tag.
[Android Apps and Games] 白い熊:
OK – I see it. It seems though this will be a full backup and restore, right?

I meant if you only wanted to back up just the settings, and restore only the settings – for the apps you can't remove or freeze, but want to limit.

I mean – it's doable manually: in the sense select all these by tag, then run backup, unselecting everything. Then on the shortcut restore, only the settings get restored, as there is nothing else to restore.

So the idea is mostly about the backup shortcut, but it's no biggie :) as it's doable by hand like this.
[Android Apps and Games] pz4551:
Do you know if the Battery State of Charge in Android is actually the State of Charge or a "state of energy"?

The definitions differ: "State of Charge is percentage of remaining Ah in cell. State of Energy is percentage of remaining Wh in cell." [https://www.researchgate.net/post/I...when_it_comes_to_monitoring_the_system_health ]
[Android Apps and Games] 3c:
SoC used to be calculated using coulomb counting as suggested in your article. I'm pretty sure this remains true and is the most accurate way to calculate remaining capacity.

If you have actual mV value you can actually calculate Wh based on this state of charge and back to State of Energy:

SoC% = Ah / tAh, so Ah = SoC% x tAh

SoE% = Wh / tWh and Wh = Ah / V, so SoE% = Ah / V.tWh = SoC% . tAh / V.tWh

And because tWh = tAh / Vnom,

SoE% = SoC% . Vnom / V.

So the difference between the 2 is the difference between nominal voltage (as per manufacturer specifications) and actual voltage. Voltage varying depending on device usage, it's best to use SoC% which is less fluctuating and generally more accurate for our little device.
[Android Apps and Games] 白い熊:
@3c how about tags for non-backed-up apps?

I'm getting ready for a ROM upgrade - after a full data wipe. I have hundreds of system apps tagged as “Freeze”, so how to save this, so I can easily freeze them on ROM upgrade? Export the toolbox settings? Will this preserve all tags' assignments?
[Android Apps and Games] 3c:
You probably be best by using the debloat feature in one click tab. You can save the current debloat state and restore it. Debloat state includes 'uninstalled' system apps and should include frozen system apps as well. You can save it and restore it easily. Backing up the toolbox or exporting it's settings should also save the debloat list. Just have to double check.
[Android Apps and Games] 白い熊:
Right - but the toolbox settings export doesn't save which apk has which tags?

So, if I wanted to preserve the tags for non-backed-up apps the best bet for me is to backup without everything? So then the package permissions, settings etc. and the tags would be saved. :@)
[Android Apps and Games] 3c:
Tags are saved with toolbox settings or export.

However if you want to save other toolbox settings you need to backup the apps you want to save settings for. All backups automatically include the tags and the toolbox settings applied to the backed up app.
[Android Apps and Games] pz4551:
Thanks for all the previous feedback.

I have some questions:

Which current value is logged? "Now" or Average"?

https://developer.android.com/reference/android/os/BatteryManager#BATTERY_PROPERTY_CURRENT_AVERAGE

or

https://developer.android.com/reference/android/os/BatteryManager#BATTERY_PROPERTY_CURRENT_NOW

Is this the logged battery State of Charge?

https://developer.android.com/reference/android/os/BatteryManager#BATTERY_PROPERTY_CAPACITY

Do you know if this capacity parameter is a constant value set by the manufacturer or updated on-board?

Is this parameter shown/used in your app?

https://developer.android.com/reference/android/os/BatteryManager#BATTERY_PROPERTY_CHARGE_COUNTER

Thank you very much!
[Android Apps and Games] 3c:
Average is logged because now is not reliable and not available on all device. Average being calculated by hardware, it would require recording every milliseconds to get the same accuracy and even at one second interval would kill one's battery.

Property capacity is a measure of total capacity (in mAh) as far as I remember.

Charge counter cannot be used because it resets when factory resetting one's device or installing a custom ROM, while app records all charge cycles in it's data which will be backed up and restored upon changing custom ROM.

It is actually used the first time app is started (and/or after clean install) just to get current charge counter.