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

Vantskruv

Member
Apr 17, 2010
34
6
Hello! I have a question!
If prioritizeBattIdleMode is set to true, what is the behaviour if using a wireless charger? The option works on my device (Pixel 4XL) when using a wired charger.
I guess it will not work, maybe even not recommended? But it would be cool if it would.

I currently do not have a wireless charger, but thinking on buying one to relieve the mechanically wear on the USB-C port.
 
  • Like
Reactions: duttyend

Vantskruv

Member
Apr 17, 2010
34
6
Could not resist and bought myself a wireless charger.
It seems to work great for now, temp is low (currently 26.5 C) while using battery idling mode, and I am currently supervising it. :)
 
Last edited:
  • Like
Reactions: duttyend

Fif_

Senior Member
Jun 5, 2013
1,148
1,210
Google Nexus 10
Google Nexus 4
OnePlus 8T here on 11.0.8.13 firmware.

Long time user of Battery Charge Limit on both this phone and my prior OnePlus 5T, had virtually zero issues with that working. Since the 8T can charge at ridiculously high rates (65W with the factory charger or 27W with USB PD), I want to limit the charging to extend the battery lifespan. I got over 3 years with my 5T and never really had a problem with the battery life, but I always used a non-factory charger (7.5W) and never charged over 80% (only killed the battery on a few occasions too). My hope was to achieve something similar for my 8T.

With AccA running version 202010150 of Acc, I have setup charge limits (80% limit, 70% start), voltage and current limits, and tried battery idle mode. Of those, only the voltage and current limits work. Of the control files that work, none of them fix the charging past 80% issue, not even setting it to the same one that works for Battery Charge Limit (battery/charging_enabled 1 0). I have had to re-enable Battery Charge Limit to get the phone to stop charging at 80%. I also find that if the phone is not charging, USB audio routing stops working. If I uninstall AccA then remove Acc via Magisk, the audio routing works as expected. The 8T doesn't have a 3.5mm port so a USB audio/power splitter is what I use to charge and have audio out simultaneously. So, this is really only an issue if I am using a USB DAC on-the-go rather than in my car or home. Yes, I could use bluetooth, but until you get to expensive equipment, the usual bluetooth codecs suck in terms of latency and compression, so I prefer a wired connection.

I just updated Acc to the latest 202107281, so we'll see if anything works better than before.

EDIT:
Seems that the charge limits work with 202107281, but am having issues with the voltage limit not working now (haven't drained my battery enough to test the current limit yet). Battery idle mode does not work still, though it does say that the kernel supports it. I'll probably try removing the app (AccA) and do some testing with just the CLI, see if that helps with anything.

EDIT 2:
Didn't uninstall the app yet, but can confirm that the voltage and current limits are indeed working (had to reset the values, re-enter them, and reboot the phone before they worked). The battery idle does not work. So, the two key features for me are working and the two nice-to-have features are not working, yet.

Now, I have more details on the audio routing issue. If I unplug the charging cable while between 70-80% (my start/stop limits), the audio routing works fine until the battery hits 70%. As soon as that happens, the audio routing stops working and there is the Android notification for "charging this USB device" (or something like that) that gets stuck in my notifications even if I unplug the charge/audio splitter adapter. Plugging the charger back in does not fix the audio routing even after the phone gets back between 70-80%; only rebooting the phone seems to get the audio routing working again.

EDIT 3:
All of a sudden, the battery idle mode is working. I didn't change anything, but it is working on two different chargers. The battery charges to 80% (my limit) and then sits there "not charging" with 0mA being the current. Before it would hit 80% and switch to "discharging" until the battery dropped to 70%. Now, charging still happens if I reconnect the charger while it is still above 70% (the resume charging limit).

The only thing I can think of is that I did have the audio routing problem today. The charger was unplugged from the audio/charger splitter for long enough that the phone got into that "charging this USB device" message. Plugging the charger back in did not fix the issue so I unplugged the splitter and plugged it back in which did the trick (normally I have to reboot the phone). Perhaps that is what caused things to work, perhaps it was just a coincidence?

Side note: the logs show "battery/op_disable_charge 0 1 battery/input_suspend 0 0" being used as the switch. I have tried that switch manually in the past, but I don't recall if it was after updating to 202107281.
Do you have charging optimization turned off? I suspect it uses the same sys switch as acc (battery/op_disable_charge) and night interfere with it?
Screenshot_20210916-112830.png

Also, would using "battery/input_suspend 0 0" have any effect since it's using 0 for both turning charging on and off?
 
  • Like
Reactions: duttyend

VR25

Senior Member
Apr 20, 2013
1,827
4,523
github.com
**v2021.9.19 (202109190)**
- Additional charging switches - the database is more concise with the extensive use of wildcards.
- Battery status detection enhancements
- capacity_mask=true: forces Android to report capacity = capacity * (100 / pause_capacity), effectively masking capacity limits. This replaces capacity_freeze2.
- current_workaround no longer requires a reboot (just accd --init).
- Fixed cooldown and acc -f issues.
- General fixes & optimizations
- Optimized --parse (acc -p).
- Support for "volatile" plugins (gone on reboot, useful for debugging): /dev/.vr25/acc/plugins/
- Updated documentation (mainly tips > idle mode and alternatives)
- Upgrade rollback feature (-b|--rollback or wizard option f)
 

VR25

Senior Member
Apr 20, 2013
1,827
4,523
github.com
Broken Kernels Killing Charging Control

Extensive testing suggests that several kernels have been messed up lately.
Either the manufacturers themselves are doing it on purpose or something extraordinary is going on.
To put that into perspective, some devices even have 6+ known charging switches. Yet, none works.
While I'm still keeping an eye on this issue and trying to come up with workarounds, don't expect much from my actions.
This should be addressed with actual kernel patches.
Start threatening kernel devs with guns.
 

VR25

Senior Member
Apr 20, 2013
1,827
4,523
github.com
Idle Mode and Alternatives

1. Charging switch that supports idle mode (the obvious winner).
Note that self discharge is a thing.
This is as if the battery were physically disconnected.
Extremely slow discharge rate is expected.

2. charging_switch=0
If current fluctuates, also set current_workaround=true (only takes affect after a reboot).
If this method works, the behavior is exactly the same as #1.

3. charging_switch=3920: only works on devices that actually support voltage control.
Unlike regular idle mode, this maintains 3920 mV (the sweet spot) indefinitely.
This is not good with higher voltages.
We're trying to minimize battery stress as much as possible.
Maintaining a voltage higher than 3920 for a long time is not recommended.

4. acc 3920
This is short for acc 3920 3870 (a 50 mV difference).
It tries to maintain 3920 mV without voltage control support.
Yes, it's definitely not a joke.
This works with regular charging switches and voltage readings.

5. acc 45 44
I prefer this over acc 50 49, since voltage and capacity (%) do not have a linear relationship.
Voltage varies with temperature, battery chemistry and age.
Considering those variables, acc 45 44 is more optimal than acc 50 49.
50% is more likely to translate to voltage values higher than 3920 mV.
 

Koushik87

Senior Member
Nov 3, 2014
74
24
34
Kolkata
ACCA app keeps freezing and force closing whenever new values are applied. Profile also doesn't get applied. Running OOS A11 with MCD kernel on my Fajita (OP 6T). Any1 can suggest workaround. I don't want to go terminal emulator way.

Using ACCA version 1.0.35 and ACC version bundled with it.
 
Last edited:
  • Like
Reactions: duttyend

gorilla p

Recognized Contributor
Nov 30, 2011
3,662
2,833
Milwaukee
Xiaomi Mi Pad 4
OnePlus 9
Regarding my issues with the OP9, this appears to be one with an aforementioned broken stock kernel? Constant problems with daemon failing while charging.
Arter97 just released a Non-OOS but CAF-based kernel and ACC is working fine with it so far, at least while plugged in. Will test wireless charging soon.
 

VR25

Senior Member
Apr 20, 2013
1,827
4,523
github.com
**v2021.9.20 (202109200)**
- General enhancements
- Manual capacitySync toggle (`[capacity_sync|cs] = [true|false]`) - it overrides the automatic. Both include the `freeze at 2%` feature. This is the actual `capacity_freeze2` replacement now. `capacity_mask` implies `capacity_sync`.
- Unlike in previous versions, changes to `capacity_mask` and `capacity_sync` take effect (within a few seconds) without a daemon restart.
- Updated documentation
 

VR25

Senior Member
Apr 20, 2013
1,827
4,523
github.com
ACCA app keeps freezing and force closing whenever new values are applied. Profile also doesn't get applied. Running OOS A11 with MCD kernel on my Fajita (OP 6T). Any1 can suggest workaround. I don't want to go terminal emulator way.

Using ACCA version 1.0.35 and ACC version bundled with it.
There's a new front-end in town.
I've been working closely with the dev.
 

yg213

New member
Aug 23, 2021
4
0
My battery life is down after install ACC via AccA. My phone's minute per %1 was 5-6 minutes before, and now %2-3. Also, Charge is decrease (%14-15) even after I do not use my phone for 7-8 hours. I uninstalled AccA app and ACC by executing the uninstall file but nothing changed :\\
 
Last edited:

Vantskruv

Member
Apr 17, 2010
34
6
Yeah, something new with the kernel is disturbing the charging, having big problems after upgrading Android Coral from june version to september version. Had the phone cable-connected to power while sleeping tonight, it sneakly charged it up to 77% from 46% in 6 hours, but I wanted to be in idle mode keeping (charging span between 39% to 42%).
So it seems ACC bravely is fighting for its life not to charge, as I told it to do. :D
Using v2021.9.19.
(I did see now a 9.20 version is released ...)
 

Attachments

  • acc-logs-coral.tar.gz
    194.7 KB · Views: 8
Last edited:

Koushik87

Senior Member
Nov 3, 2014
74
24
34
Kolkata
Thanks. The UI is pretty simple but looks promising. I am excited to see the final version of it. Thanks dev and will let know for any specific observations on this test version.
The 9.20 acc version is working fine for me now along with new UI app. However, the new app for ACC is missing DJ's. Hope this will be incorporated in future builds of the app.
 

Koushik87

Senior Member
Nov 3, 2014
74
24
34
Kolkata
My battery life is down after install ACC via AccA. My phone's minute per %1 was 5-6 minutes before, and now %2-3. Also, Charge is decrease (%14-15) even after I do not use my phone for 7-8 hours. I uninstalled AccA app and ACC by executing the uninstall file but nothing changed :\\
Please check if you are coming from clean install of a kernel. Sometimes leftovers from previous kernel can cause such issues. Suggest re-flash stock/custom rom then Kernel and try acc version 9.20 if there is any improvement.
 

yg213

New member
Aug 23, 2021
4
0
My last kernel flashing was:
1. system recovery > wipe cache partition
2. flash everything (boot.img included) of stock ROM without PRELOADER (sp flash tool)

So I don't think I am coming from bad installation of kernel

%4 has gone even writing this :/

I will try re-flash without USRDATA.
 

melphoi

Senior Member
Jul 31, 2012
146
36
Batam
Hello, I installed ACC module from Magisk on stock ROM A11 Pixel 3 with Kirisakura Kernel
I set ACC to pause charging at 80 and resume at 50, it seems working but the charging stopped at 70-73% instead 80%

And also when I try to check on charging switch, it says :
[battery / step_charging_enabled 1 0 ] won't work
[dc / input_suspend 0 1 ] won't work

While the other 2 charge_disable and input_suspend says "works"

Maybe someone could me by pointing to where should I look for the fix, cause I'm noob myself, and the documentation kind of confussing for me

Edit : I got it working now, and also I think editing the commands via Termux works too.
But still what bothering me is why the charging process stopped at 70% instead of 80% :unsure:
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 3
    Oh. Really thank for ur advance!!!
    I ll research more for that. Also that, I a bit noob here ^^!. So if u give me a directly step or terminal code for that, it ll be really helpful for me. I dont know what i did right or there ll be something better for "working same with 100% vut in 85% " really thank again. ^^
    The documentation has all the steps I would have you go through. Outlining them all again would be too redundant. You can start by running acc -t. It'll tell you whether your kernel supports idle mode (battIdleMode=true). If the result is positive for at least one charging switch, run acc -ss and select it.
    3
    I'm curious if anyone has had success with this on the Pixel 6. I read this on the acc github but I'm not sure how to make use of that in the configuration (I'm a noob with this module/config app).

    It mentions:
    Code:
    /sys/devices/platform/google,charger/charge_start_level:100
    /sys/devices/platform/google,charger/charge_stop_level:0

    I'm confused on how to create the commands to set this up. It's clearly a "acc -s" command, but where does the "charger/charge_start_level:100" go? I'm assuming "/sys/devices/platform/google" is the switch file?

    zee3are0 et al.,


    I've been experimenting with botth.
    So far, those control files seem to behave very inconsistently.
    Perhaps Google released non-production quality software.
    Have you tried the current/voltage approaches? (Readme > tips > idle mode and alternatives)


    Anyway, here's how to test and and set those two switches:


    1. /sys/devices/platform/google,charger/charge_stop_level and /sys/devices/platform/google,charger/charge_start_level

    Test: acc -t /sys/devices/platform/google,charger/charge_stop_level 100 5 /sys/devices/platform/google,charger/charge_start_level 0 95

    Set: acc -s s="/sys/devices/platform/google,charger/charge_stop_level 100 5 /sys/devices/platform/google,charger/charge_start_level 0 95"


    2. Just /sys/devices/platform/google,charger/charge_stop_level

    Test: acc -t /sys/devices/platform/google,charger/charge_stop_level 100 5

    Set: acc -s s="/sys/devices/platform/google,charger/charge_stop_level 100 5"
    2
    Should I update the Magisk module even though I'm using the AccA or should I only update the AccA through the apk?
    Last update for AccA was from a few months ago while the Magisk module was just last updated back in the 1st week of November.
    The general rule of thumb is updating things only if you absolutelly need to.
    Don't fix what's not broken.

    That's not to discourage anyone.
    Being a bit adventurous won't hurt.
    I don't intruduce breakng changes without notice.
    Besides, acc has a rollback feature - acc -b command reverts everthing (including the config) - no reboot required.
    2
    After testing, I found the following 2 reporting "works" on my OP9.

    sys/devices/platform/soc/soc:eek:plus,chg_intf/oplus_chg/battery/chg_enable 1 0

    /sys/devices/platform/soc/soc:eek:plus,chg_intf/soc:eek:plus,chg_intf:eek:plus,wireless-charge/oplus_chg/wireless/batt_chg_enable 1 0

    For each, I entered acc -ss /path/to/switchabove.

    Ill see of it works nay better.
    To set switches, run acc --set charging_switch="file on off file2 on off --"

    As you can see, more than one switch can be set at once, but most of the time, one is enough. The trailing " --" ensures the switch is not unset if it fails (i.e., prevents falling back to "automatic")

    acc --set charging_switch= can be shortened for faster typing: acc -s s=
    2
    I research for quite a long time and I still cant find answer for my trouble. Pls help me out :(.

    I just want to limit the battery at e.g 85% like samsung did have option for there new phone, then they remain % and never go down if i still plus in charger, like plug on to charge 100% and play game. Not switch on or off. Charge to that % and remain it.

    In short, is there anyway to make this module work like normal charge to 100% but in 85%? Thanks alot :(
    Sr for my bad English
    There is and it's called idle mode. It depends on the kernel. Refer to README > TIPS > Idle Mode and Alternatives.
  • 75
    Archive
    Find newer zips here.
    40
    Those who are worried about other projects of mine not being updated for a long time, possibly abandoned...
    Stop worrying.
    After the next stable ACC release, I'll focus more on the other Magisk modules (fbind, Migrator, Systemless GApps, etc.).
    The current ACC framework is the base of all the other projects - meaning, making it rock stable it priority #0.
    29
    A new stable release is up.
    It can be downloaded from Magisk Manager > Downloads as well.
    Refer to the readme for a full list of changes, features and recommendations.
    Now I'll be focusing more on the other projects (migrator, fbind, systemless GApps, daily job scheduler...).
    Until these reach satisfactory status, acc will only get occasional maintenance updates (bugfixes, optimizations, new charging control files...).

    Edit: the installer enforced by Magisk Manager is not playing nice with acc. Until I fix that, use the zip from GitHub (release link above).

    Edit 2: fixed.