• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Search This thread

Lughnasadh

Senior Member
Mar 23, 2015
2,741
2,398
Google Nexus 5
Huawei Nexus 6P
The file is indeed 2MB however it seems to contain only 'NUL' characters.

In five days there is the black friday, if I can get my hand on a standard Pixel 6 with some discounts I should be able to solve this once I receive it. Hopefully you'll have the patience to wait that long.
I'm assuming this was meant for me and not @bege10 .

No problem whatsoever. No rush at all, and lots of patience on my end 🙂
 

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
Code:
11-13 21:49:57.853 28431 28431 F DEBUG   : backtrace:
11-13 21:49:57.853 28431 28431 F DEBUG   :       #00 pc 0000000000000000  <unknown>
11-13 21:49:57.853 28431 28431 F DEBUG   :       #01 pc 0000000000052274  /apex/com.android.runtime/bin/linker64 (__dl__start+4) (BuildId: c2069b68ba36a64f9de875a2227ca969)

Code:
11-13 21:58:01.761 31477 31477 F DEBUG   : backtrace:
11-13 21:58:01.761 31477 31477 F DEBUG   :       #00 pc 0000000000000000  <unknown>
11-13 21:58:01.761 31477 31477 F DEBUG   :       #01 pc 0000000000052274  /apex/com.android.runtime/bin/linker64 (__dl__start+4) (BuildId: c2069b68ba36a64f9de875a2227ca969)

I found some of those in the zip you sent. They will be very hard to debug as they are not referencing the library itself but only the linker that starts them as if something goes wrong before the library is started... in the OS...

That said, I found some other tombstones that were more useful and might be related somehow. A fix for those is available in next update (beta for toolbox 2.5.4 and sensitive backup 1.5.3).

NB: The last beta updates target API 30 as per Play Store requirements, which may cause weird and unexpected side effects.
 
  • Like
Reactions: tramp20

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
I'm assuming this was meant for me and not @bege10 .

No problem whatsoever. No rush at all, and lots of patience on my end 🙂
Indeed ;)

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

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

Code:
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.
 
Last edited:

Lughnasadh

Senior Member
Mar 23, 2015
2,741
2,398
Google Nexus 5
Huawei Nexus 6P
Indeed ;)

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

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

Code:
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.
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. 👍
 

Lughnasadh

Senior Member
Mar 23, 2015
2,741
2,398
Google Nexus 5
Huawei Nexus 6P
Indeed ;)

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

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

Code:
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.
Yep, that fixed it. No more reboots. Thank you so much. Really appreciate it 👍
 

bege10

Senior Member
May 26, 2018
196
47
Germany
@3c It looks like the tombstones have become less, but they are still being created regularly. All contain liblib3c.so.
 

Attachments

  • logcat.txt
    6.6 KB · Views: 1
  • tombstones.zip
    59.3 KB · Views: 2

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
@3c It looks like the tombstones have become less, but they are still being created regularly. All contain liblib3c.so.

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.

Code:
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.
 

bege10

Senior Member
May 26, 2018
196
47
Germany
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.

Is this enough or do you need it further back?
 

Attachments

  • logcat.txt
    145.2 KB · Views: 2

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
Is this enough or do you need it further back?
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.
 

bege10

Senior Member
May 26, 2018
196
47
Germany
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.
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.
 

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
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.
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.
 

bege10

Senior Member
May 26, 2018
196
47
Germany
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.
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?
 

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
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?
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.
 
  • Like
Reactions: bege10

白い熊

Senior Member
Aug 29, 2011
803
279
相撲道
@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?
 

3c

Senior Member
Jul 19, 2005
2,812
1,938
www.3c71.com
@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?
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.
 

白い熊

Senior Member
Aug 29, 2011
803
279
相撲道
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.
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.
 

白い熊

Senior Member
Aug 29, 2011
803
279
相撲道
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.
@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?
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    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).
    3
    I clean installed the latest beta - still the same behavior. Can't send the support request, as I can't restore my mail client, so am attaching here.
    Well my bad, was too eager to publish it and it was half fixed, so next update (2.5.6b) has all the necessary fixes.
    PS: Sorry for the inconveniences.
    2
    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 ]

    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.
    1
    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...
    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.

    @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?
    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).
    1
    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? :mad:)
    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.

    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?
    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.

    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?

    Already added when I added freeze/unfreeze by tag.
  • 54
    [APP 4.1+] 3C All-in-One Toolbox

    3C Toolbox, available on Play Store and XDA Labs is the most comprehensive must-have toolbox for Android version 4.1 and above, running any ROM or kernel. Issues, suggestions, feature requests, please make sure to read post #2.

    This app includes all features delivered separately in below apps. This is the result of many years of work to bring all features together in an easy-to-use giant toolbox, and it includes the features of many other apps, including Titanium Backup, Greenify, BetterBatteryStats, App2SD, Seeder, ROM Toolbox Pro, SetCPU, System Panel, Root Explorer, Autorun Manager, Terminal Emulator, Script Editor, SD Booster, BuildProp Editor, ATK and so much more.

    What is 3C Toolbox Replaces 20+ apps easily worth 30€ for the price of a couple of beers!

    Download link Play Store XDA Labs


    Can take advantage of the following apps (not integrated because of policy restrictions from Play Store):

    3C Sensitive Backup - Allows backup/restore of SMS/MMS and call-log, can work with 3C Toolbox to schedule backups.

    3C Legacty Battery Stats - Allows reading Android legacy battery statistics


    Non-exhaustive list of integrated apps and features :

    3C CPU Manager (root) - CPU/GPU controls for root users

    3C Kernel Tweaker (root) - Kernel tweaking for root users

    3C Task Manager - A simple yet powerful task manager for Android

    3C Task Recorder - A simple yet powerful task recorder for Android

    3C Log Reader - A simple log reader allowing you to read logcat, kernel and xposed logs from a single place

    3C Explorer - This is a very simple file explorer for Android

    3C Toggles - Highly customizable widgets to control about 30 system components.

    3C Battery Monitor - The most complete tool to monitor your battery, have no equal on Play Store.

    3C Network Manager - Monitor trafic and control network configurations

    3C Apps Manager - The most complete app manager to backup/restore/control all your apps

    3C SQLite Manager - A simple SQLite editor


    More information

    App Features

    App screenshots

    3C Apps Feature Comparison

    Lowest CPU consumption on Play Store

    Permissions requested

    Getting started guide

    Online help

    Unique features not available elsewhere

    Track your ROM, kernel and battery performance (%/h or mA, screen on or standby)
    ◊ Battery milli-amp (mA), mW and %/h consumption reporting
    ◊ Automatic backup of installed and updated applications
    ◊ Highly configurable textual and graphical monitoring widgets
    ◊ The most advanced and configurable UI
    ◊ Clean and safe reboots, without data loss (root required)
    ◊ And much more
    29
    FAQ and guidelines for any queries

    Before you put a bad rating on Play Store for a single broken feature among the 100 the app delivers, and before you contact me (or post here), you may consider the following:
    3C Toolbox runs on hundreds of devices and custom ROMs, I cannot test all of them, however I try to change device regularly to ensure the app is compatible with all devices, please check my signature.

    ◊ 3C Toolbox and its derived apps are, at the time of writing, used by more than half a million users and 3C Toolbox Pro is rated 4.8/5 by about 3000 users.

    ◊ 3C Toolbox runs on Android 4.x and above, I always have at least one device running 4.x, 5.x, 6.x, 7.x and 8.x to avoid issues, however I may miss some key differences from time to time, possibly causing the app to crash or a feature to malfunction.

    ◊ 3C Toolbox is not a game relying on well established documentation, but an advanced toolbox which uses some undocumented features, which have evolved along with each version of Android. Even some documented features had to be adapted to newer Android versions.

    ◊ 3C Toolbox provides milli-Ampere data for your battery either provided by Android OS or estimated by the app when there is no current sensor. Hardware current sensor can sometimes report inaccurate or no data at all. It's impossible to predict how the next device will report milli-Ampere if it does at all.

    ◊ I'm a human being, not a service center, not a big corporate. Like any other human being I don't like being bashed or insulted by email or anywhere else and will no longer waste my time for anyone doing so.
    Why such guidelines?
    - You want new features and improvements as soon as possible?
    - You want a quick solution to a problem?
    - You don't want to waste your time explaining?

    Me too, that's that simple.
    Feature requests?
    Please explain using as few words as it's possible and join a screenshot if it applies to an existing feature. Pictures speaks 1000 words they say, maybe.
    Issues with CPU temperature or battery current mA or capacity mAh?
    Please explain this in a support request sent from app settings, help and support so I can provide the appropriate option to use in 'mA retrieval method' of battery / monitoring settings and add out-of-the-box support for your device. All necessary information is provided in the request's attachments.

    Battery current mA and CPU temperature are non standard on Android and every devices/manufacturers provides it differently or not at all. Don't blame the app if your device doesn't provide it or report inconsistent values, ask your manufacturer which get paid lots of bucks.
    Issues with GPU tab missing features?
    GPU configuration is not something standard on Android, and there are currently 10+ implementations available. If you miss something, please send a support request from app settings, help and support mentioning what's missing and a screenshot of each GPU tabs.
    How to get support for any other issues
    Please send a support request from app settings, help and support. You need to clearly explain your issue, attach any relevant screenshots showing where and how the issue occurs. I will not provide any support here.

    The idea is that you explain the observed issue, possibly add a screenshot so that I know exactly where to look (app has 100+ screens and sometimes words don't mean the same for you and me), from there I can really do a good job at helping you. You want my help, do it the right way or simply don't.

    The support requests contains the following (you can check the content before sending). Privacy policy is available here.

    ◊ Battery technical details as available on device
    ◊ Battery history recorded (last 100 records)
    ◊ CPU technical details as available on device
    ◊ SD mount points (to help identify unsupported SD locations)
    ◊ Previous visible and internal crash reports (FC)
    ◊ Process running (to identify possible conflicts)
    ◊ App configuration (version number, type and mA retrieval method in use)
    ◊ Android configuration (version, security settings, ROM, kernel)


    You've read all this? I thank you for your time and hope you enjoy my apps.
    17
    Future plans

    Here is what I'm working on or planning next:

    • Improve ROM Manager with extra features.
    • Improve Battery Manager status tab and displayed data
    • Add tabs to App Manager (protect, debloat, crystallize, others?)
    • Add 'optimize' tab to System Manager for memory/storage
    • Improve file manager with swipe left-right and new tab options
    • Improve Terminal Emulator with real terminal display.
    • Improve UI, suggestions most welcome.
    • Removing all ads to see if it brings any positive results (currently testing on 3C Toolbox).
    • Add PayPal to XDA Labs apps if possible.

    This is my current objectives:
    • Increase user support from Play Store, Huawei AppGallery or XDA Labs
    • Get XDA Labs apps Google-free (using PayPal)
    11
    3C Task Manager 3.0 (beta)

    Dear users,

    I've updated (in beta) 3C Task Manager with the new project/build structure. APK size is reduced by 15% while delivering more features. Future maintenance will also be much easier.
    3C Task Manager is now capable of managing app's components (activities, services, etc...) and also to renice (Linux priority scheduling) processes (optionally using Xposed for efficiency).
    On rooted device, the app will also be able to use 3C Explorer to open an app's data folder or 3C Log Reader to get app's logs.

    This new build allows me to reduce development and maintenance times greatly when publishing apps other than the Toolbox.

    A lot of refactoring and splitting took place, allowing to build other apps (with similar look'n'feel) faster too, namely the SMS/Call-log backups that's now missing in the toolbox (due to Play Store restrictions).

    Next steps include:
    • Building an SMS/Call-log backup companion app and link it to the toolbox.
    • Adding full SAF / Content Provider support to Explorer
    • Allowing browsing network shares through Explorer's SAF / Content Provider
    • Adding app labeling in Apps Manager.
    • Rebuilding other apps (Battery Monitor, Toggles)
    • Creating 3C App Manager
    11
    Recent Update - Mea Culpa

    You have certainly noticed the recent updates that is supposed to improve root handling in my apps, and might have experienced issues.

    Why make such change

    In versions before 1.6.12, the app was using a very common root method, using scripts and Android commands. Each action was taking 120ms just to get started. Some features like app manager and explorer run a lot of them. With Marshmallow, there's even a bug that cause determining path to fail and require root, slowing down everything a lot.

    I started testing a shared library in 1.6.12 that would run root commands directly without this 120ms overhead and it worked really well, running some commands in 1ms instead!

    In 1.7, I've started 'migrating' all root features to this new method, always implementing a fall-back in case something went wrong. That didn't work so well in the end.

    What went wrong?

    To make it short, I was testing this new method on a few devices, running Android 6.0.1, 5.1, 4.4 and supposedly 2.3 but it was running 4.1.2. You can imagine easily how misleading this was!

    I learned that Samsung devices had special security constraints that made some commands fail completely and prevented the fallback to take place.

    At the same time, Xposed module was reported to fail on Marshmallow because of new security policies. Had to change everything because of that!

    Then the APK build process was no longer building the x64 versions anymore.

    What's next

    I'm still receiving reports of various issues on different versions of Android that I will have to address in the next few days/weeks.

    Android N is coming with new security restrictions that will require further changes, but this new root method is already taking care of that.

    Did I make a bad decision?

    No. Since Android implemented SELinux security policies in 4.2/4.3, each new version of Android has required many internal changes to keep features working, and its getting worse with M and now N.

    This new method not only offers much better performance but also requires much less workaround to keep working.

    Yes, I made a mistake. After hours of working nights and week-ends, it was still not ready for public release as I thought.

    What went even more wrong?

    In my desire to offer the best experience possible, I published fixes too quickly and instead of stabilizing stuff, I've only made it worse.

    Long story short

    I'm sorry for any inconveniences you might have experienced, and I'll do my best to make it better asap.

    Want to help?

    If you experience any issues and want to help, please send a support request from app settings, help and support, mentioning what happens and possibly screenshot for my understanding.

    The support request provides valuable information on the Android version, app logs, Xposed version if installed, app config, etc... Much needed so that I can investigate the issue with similar environment, otherwise I might be testing on a dozen devices without reproducing the issue.

    I can then send you an updated APK with a fix or with active debug if I can't pin-point the problem on my test devices.

    FWIW: Version 1.7 was addressing a number of issues in previous versions and I did hope it would make users happy with some nice improvements. My bad.