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

[Guide]Using the Advanced Charging Controller (ACC) Magisk Module with Pixel 3a/XL

Search This thread

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
umm, i would be happy if someone give an advice to me the best configuration for the best battery charging cycle, anyone can help me?

Well after Jellopuddingstick educated me on the battery idle mode, I've actually been trying the "auto" charging switch the last day or two and so far it's been good.

I haven't tried it enough to edit the initial post, but in another day or two I'll edit it with my latest thoughts.

But long story short, the stock settings should work just fine. So you could install it and never change anything and it will likely work very well.
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
After several more weeks of use, I've updated the initial post again. I found some quirks with the "automatic" charging switch, so I have gone back to selecting charging switch option 2 (battery/charge_disable 0 1).
 

rackso04

New member
Mar 31, 2016
4
1
Hi
Good guide you have done.
Do you know if it is compatible with any other custom kernel that is previously installed?
Thx
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
Hi
Good guide you have done.
Do you know if it is compatible with any other custom kernel that is previously installed?
Thx

I'm using experimentalX right now and the ACC module does still have some quirks. Right now I find it charges as soon as it is plugged in and doesn't wait to reach the resume threshold. Not sure if that is kernel related or not. But other than that, everything works with the experimentalX kernel. I haven't tried any other custom kernels however.
 

Airbag888

Senior Member
May 5, 2010
325
62
While not specifically pixel related, charging wirelessly is generally slow but seems to generate more heat than wired charging. So should it be avoided just like fast chargers?
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
While not specifically pixel related, charging wirelessly is generally slow but seems to generate more heat than wired charging. So should it be avoided just like fast chargers?

Heat is really bad for a battery. However, one of the benefits to using this module is that it will systematically pause the charging briefly when the temps hit a certain threshold. If the temps continue to rise, it will turn charging off for a longer period of time to help protect the battery. All of this happens automatically (but can also be tweaked if needed). So using a module like this will help prevent the wireless charging or fast charging from heating the phone/battery up too much.
 

TheSinner

New member
Dec 7, 2007
1
0
I started using acc recently. I noticed on my Pixel 3 the reported capacity to be totally different compared to the OS reported. After -R it still shows like 23% difference. As a result if i set "-s 90-95" the phone stops charging at 72%. Did anyone experienced such issue?

PS: After reading through the log, it seems -R switch just reads the content of /sys/class/power_supply/battery/capacity . The retrieved value is indeed 95%. How come Android Q10 thinks it is 23% less remains a mystery for me....

PS2: upon further reading, it seems that issue started since the March update and was reported here . The workaround is force overwrite the value regularly, but still a number of downsides.
 
Last edited:

drsaidalavi

Senior Member
Jul 1, 2012
334
59
ACC is not working after reboot

I have successfully installed ACC, edited the configuration file as shown in the screen shot, and worked correctly for the first time, But after rebooting it never worked, the charging resumed even when the battery is above 70% and charging didn't stop at 90% and continue till continue to charge even at 100 %.
Kindly help me what to do to stop charging at 90% , resume charging at 70%'.
Thanking You
drsaidalavi
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
I have successfully installed ACC, edited the configuration file as shown in the screen shot, and worked correctly for the first time, But after rebooting it never worked, the charging resumed even when the battery is above 70% and charging didn't stop at 90% and continue till continue to charge even at 100 %.
Kindly help me what to do to stop charging at 90% , resume charging at 70%'.
Thanking You
drsaidalavi

To be honest, it hasn't worked completely for a while for me. It might be upgrading to Android 10 caused the issue, but I don't remember exactly when it stopped working completely.

That being said, it does work some for me and it sounds like it isn't working at all for you. For me, the phone will not charge past the specified max charge value (80% for me), but it does start charging as soon as I plug it in, regardless of the pause setting. So even if the phone is between 70 and 80% it will charge back to 80%. If working correctly, it shouldn't charge until the battery value falls below 70% (based on my settings).

If it isn't working at all, make sure the service is actually turned on. After that, I would try setting a specific charging switch. Currently you are using the "Auto" option. I would try the first option other than auto and see if that makes things work.
 
  • Like
Reactions: drsaidalavi

drsaidalavi

Senior Member
Jul 1, 2012
334
59
It worked

To be honest, it hasn't worked completely for a while for me. It might be upgrading to Android 10 caused the issue, but I don't remember exactly when it stopped working completely.

That being said, it does work some for me and it sounds like it isn't working at all for you. For me, the phone will not charge past the specified max charge value (80% for me), but it does start charging as soon as I plug it in, regardless of the pause setting. So even if the phone is between 70 and 80% it will charge back to 80%. If working correctly, it shouldn't charge until the battery value falls below 70% (based on my settings).

If it isn't working at all, make sure the service is actually turned on. After that, I would try setting a specific charging switch. Currently you are using the "Auto" option. I would try the first option other than auto and see if that makes things work.
Thanks for the reply.
I changed the çharging switch option from auto to the first option, then it worked.
Thanking You
drsaidalavi
 

cdljl2005

Senior Member
Dec 17, 2011
255
132
is the app independent from the module, or the app needs the magisk module to run correctly? thanks!
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
is the app independent from the module, or the app needs the magisk module to run correctly? thanks!

The app contains everything needed to run ACC now. So if you install the app, it will actually automatically uninstall the corresponding Magisk module because it isn't needed with the app. However you are not required to use the app. You can still use the Magisk module and use the command line or edit the files to make changes if that's what you know and like. But you will only use one or the other (app or module), not both.

When the app was first released, it still required use of the module and to be honest I didn't like the app. However the current version is pretty good IMHO and I actually use the app now and not the Magisk module.
 
Last edited:
  • Like
Reactions: cdljl2005

cdljl2005

Senior Member
Dec 17, 2011
255
132
The app contains everything needed to run ACC now. So if you install the app, it will actually automatically uninstall the corresponding Magisk module because it isn't needed with the app. However you are not required to use the app. You can still use the Magisk module and use the command line or edit the files to make changes if that's what you know and like. But you will only use one or the other (app or module), not both.

When the app was first released, it still required use of the module and to be honest I didn't like the app. However the current version is pretty good IMHO and I actually use the app now and not the Magisk module.

thank you for replying! I later studied the stuff up, it seems that the app will flash a magisk module ("acc" with no other info) whose actual version ("acc -V" in terminal command) can be switched within the app.:)
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
thank you for replying! I later studied the stuff up, it seems that the app will flash a magisk module ("acc" with no other info) whose actual version ("acc -V" in terminal command) can be switched within the app.:)

That may have been true at one time, but the latest versions of the app will not install a Magisk module (and in fact will actually uninstall the ACC module if it happens to already be installed). Don't get me wrong, there is still an ACC service running that can be modified using the command line, but it is installed with the App, not the Magisk module now.

I am currently using the ACCA app and I just double checked my Magisk modules and there is nothing installed related to ACC. I only have 6 modules installed: YouTube Vanced, Systemless Hosts, Active Edge Mod, Audio Compatibility Patch, Audio Modification Library, and Viper4Android.
 
Last edited:

Pixeling

Member
Nov 2, 2019
21
4
I've always been concerned about gaming while the phone is charging. Is it reasonable to assume that if I write 1 to charge_disable then it becomes safer to game while on charger? Will it discharge the battery or rely on the power supply? @sic0048
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
I've always been concerned about gaming while the phone is charging. Is it reasonable to assume that if I write 1 to charge_disable then it becomes safer to game while on charger? Will it discharge the battery or rely on the power supply? @sic0048

What is your concern about gaming while charging? I assume it is heat, but just want to make sure.......

If you are concerned about heat, then this module will be beneficial to use because it will pause the charging if the phone gets to a certain temp and even stop charging for a longer period if the phone temps continue to rise and hit a higher threshold. Both of these temp thresholds can be modified by the user. By pausing the charging automatically, you should be able to stop the temps from rising to dangerous levels.

All that being said, this phone does support battery idle mode (with or without this module), so if the phone is fully charged and plugged in, the phone is not charging or discharging the battery at all. Instead the phone pulls power directly from the power cord and effectively disconnects the battery. This means that gaming while plugged in, but fully charged is perfectly safe and will not increase temps any faster than unplugging the phone. In fact, it's probably better to keep the phone plugged in during this scenario because the phone won't be using any battery power at all which will help the overall battery life expectancy last longer.

In both cases, I don't see the benefit in changing the charge_disable setting.
 
Last edited:

Pixeling

Member
Nov 2, 2019
21
4
What is your concern about gaming while charging? I assume it is heat, but just want to make sure.......

If you are concerned about heat, then this module will be beneficial to use because it will pause the charging if the phone gets to a certain temp and even stop charging for a longer period if the phone temps continue to rise and hit a higher threshold. Both of these temp thresholds can be modified by the user. By pausing the charging automatically, you should be able to stop the temps from rising to dangerous levels.

All that being said, this phone does support battery idle mode (with or without this module), so if the phone is fully charged and plugged in, the phone is not charging or discharging the battery at all. Instead the phone pulls power directly from the power cord and effectively disconnects the battery. This means that gaming while plugged in, but fully charged is perfectly safe and will not increase temps any faster than unplugging the phone. In fact, it's probably better to keep the phone plugged in during this scenario because the phone won't be using any battery power at all which will help the overall battery life expectancy last longer.

In both cases, I don't see the benefit in changing the charge_disable setting.
The concern is heat to the battery. For example if I have 40% battery and I want to pause charging proactively to not contribute any heat (rather than wait for the charge to stop because there is heat) and use power from the cord only, I'm asking if a write of 1 to charge_disable would allow that.

In that case you are saying that there will be no power drawn from the battery nor it would charge it.

Is that correct ?
 

sic0048

Senior Member
Jun 25, 2010
969
510
Google Pixel 6
The concern is heat to the battery. For example if I have 40% battery and I want to pause charging proactively to not contribute any heat (rather than wait for the charge to stop because there is heat) and use power from the cord only, I'm asking if a write of 1 to charge_disable would allow that.

Honestly I don't know if the switch will give you the desired effects because I have never tried it myself. Of course there is no fear in trying it. It isn't going to break the phone or anything like that.
 

TraderJack

Senior Member
Oct 5, 2008
351
91
The app contains everything needed to run ACC now. So if you install the app, it will actually automatically uninstall the corresponding Magisk module because it isn't needed with the app. However you are not required to use the app. You can still use the Magisk module and use the command line or edit the files to make changes if that's what you know and like. But you will only use one or the other (app or module), not both.
.

Just wanted to chime in with my experience on this. It seems like the Magisk module being uninstalled isn't foolproof...it only seemed to do it on 1 out of 3 of my devices. The other ones allowed both to be installed...which apparently isn't good. But yes, if you want to use the GUI, then all you need to do is install ACCA.

---------- Post added at 11:02 PM ---------- Previous post was at 10:28 PM ----------

While I've had many Android phones, this is the first phone that I decided to use a battery charging controller to regulate how my battery is charged. I just wanted to share my journey with others and encourage others to try this out if you are not already.

Although there are several different battery charging controllers out there (and more than one named "ACC" which makes it even more confusing) I decided to use the Advanced Charging Controller module developed by VR25. I choose this module because I felt it provided the most customization.

So I'm hoping that you or others on this thread might be able to provide some data points. I'm on a 3 XL, but decided it wasn't worth trying to start a whole new discussion on this topic as apart from this thread and the main ACC, there doesn't seem to be a lot of traction of discussion. Even the "official" Telegram chat is like pulling teeth to get any responses.

Anyway, I've installed the latest ACCA app and for the most part the default settings seem to work fine. I created a "Charge to 85%" profile modeled on the built-in "Charge to 90%". This includes using the "automatic" charging switch which for the most part does seem to perform the main desired functions of:
- Charge phone to 85% and then stop
- Resume charging if phone drops to 70%

The main thing I'm having issues with is the Battery indicator in ACCA isn't matching up to the Android OS output:

Code:
crosshatch:/ # dumpsys battery | grep level
  level: 83
crosshatch:/ # acc -i | grep CAPACITY
CAPACITY=81

The first number (dumpsys) is what the OS reports - that's the number that you see in the statusbar/lockscreen.
The second number (acc) is what ACCA/ACC shows. My presumption is that it is this number here that ACC uses to charge to.

Apparently it is somewhat of a known issue that there is a discrepancy between them, especially on Pixel phones. This is discussed in the ACC README:

Code:
# Change this only if your system reports incorrect battery capacity ("acc -i" (BMS) vs "dumpsys battery" (system)). Pixel devices are know for having this issue.
capacityOffset=+0

# This is an alternative to capacityOffset. It tells acc whether the battery capacity reported by Android should be updated every few seconds to reflect the actual value from the battery management system.
capacitySync=false

The capacityOffset value works. So if I change this value to capacityOffset=+2 , acc will change it's value (in the example above) to 83 (81+2).
This works great to keep them in sync...for a few minutes anyway. What I have found is that the actual value of the discrepancy is anything but constant.
For example, the reading above was from my phone an hour ago. This is my reading now (with no capacityOffset configured):
Code:
crosshatch:/ # dumpsys battery | grep level
  level: 70
crosshatch:/ # acc -i | grep CAPACITY
CAPACITY=71

So now my OS is actually reporting 1 less whereas an hour ago it was reporting 2 higher!

Clearly the ACC folks still knew this was an issue, which is why (I assume) they also created the second option, capacitySync.
Unlike capacityOffset, which appears to modify the value in acc, capacitySync appears to make acc actually modify the OS setting.

This seems like the more foolproof way to keep the numbers in sync, but I've got two concerns with this:
1) It would seem to be more intensive to do a constant poll/update rather than just have ACCA adjust it's display value by an offset. But there is no information presented anywhere as to just how intensive this may be.
2) The README text of the capacitySync states (again):

It tells acc whether the battery capacity reported by Android should be updated every few seconds to reflect the actual value from the battery management system.

So it seems clear that acc is modifying the OS' reported capacity. I'm not sure how it is actually doing this, but it is updating it in a way that dumpsys will report the synced value. The developer of ACC has stated that the Pixels actually have *bugs* in reporting the battery level to the user. This is a direct quote from the Telegram group:

VR25

ACC/A values are raw, from the Battery Management System (kernel level) itself.

There are Android APIs which provide such values, but these are not guaranteed to be accurate. This is due to secondary battery management systems, or actual system level bugs... *cough*Google Pixel phones*cough*.

Run the following as root and compare the data:

echo; dumpsys battery; echo; dumpsys batteryproperties; echo; acc -i

You may want to run each command (except echo) individually as well - and perhaps all in parallel also.

And here is another quote from Telegram:

VR25
...
- AccA gets the battery readings from acc, which in turn obtains the data straight from the battery management system - which in theory should be more accurate than Android itself. This is not the first time a Pixel user reports such issue. That's why I came up with capacityOffset and capacitySync features. None of those will solve the underlying issue, though. They just mask values. While the battery management system seems to be working just fine, for some weird reason, Android (which depends on it) is misreporting the values. Is Google trying to make you believe your battery holds less charge, so you can replace the phone sooner?

I don't have much of a point...other than the capacitySync option seems the only way to deal with this.
I would like to know how other Pixel users are dealing with this. Do you see discrepancies like this between the two numbers?
If so, how are you compensating?
If not, why do you think that some Pixels will have these discrepancy issues, but not others?

For what it's worth I've seen this issue on no less than 3 Pixel 3 XL phones that I've used over the past month or so, therefore I find it unlikely that it is just a fluke in a device that may have a "bad" battery. If that's the case then I expect the majority of Pixel 3 devices would have them.
 
Last edited:

TraderJack

Senior Member
Oct 5, 2008
351
91
Ok, I dug around in the code and believe I have found an answer to all my questions (well most of them, I'm still not sure how performance may be affected by the various options).

So basically we have 3 settings that I was wanting more info about:

Code:
capacityOffset
capacitySync
forceStatusAt100

Again, I'm particularly interested in how they apply or why they are needed on Pixel devices.
To reiterate (mostly taken on faith by what VR25 and others have said), the Pixel *OS* battery system seems to report different battery information (i.e. capacity) than the actual *kernel* (bms).

Normally acc (-i) and the ACCA app are reading the capacity directly from the kernel via /sys/class/power_supply/battery. For example if you issue the following command

Code:
cat /sys/class/power_supply/battery/capacity

You will be returned with a battery reading (in %). This is directly from the kernel and what ACC/S uses.

Contrast this with what the OS uses to show you battery level (in statusbar/lockscreen/most apps):

Code:
dumpsys battery | grep level

If you are lucky these 2 values should always be consistent, but apparently not on Pixel phones. No one has a really good reason why Google isn't reporting the value directly from the kernel into the OS and/or what they are doing (intentionally or not) to have the OS report something different. We may never know why.

Much of the above is indirectly described in some roundabout way in the ACC README, but I wanted to clarify/gather all of this in one place to continue with the next part here...

So the easiest to understand here is capacityOffset. It is strictly contained within ACC and simply will change what ACC reports to fall in line with what the OS believes (dumpsys battery). So if your OS thinks the battery is 80%, but ACC gets 77% from the kernel, an offset of +3 will make ACC report 80% instead of 77%. The code for this is a bit spread throughout the app because there are many places that ACC needs to compensate using the offset that you define.
I think the capacityOffset is not a great solution because:
  1. The differences between the two values may change over time and the offset value is static, so the results may still be off.
  2. I believe it is probably better to trust the kernel rather than the OS. That being said, there may be some issue that occur within the OS if this was a conscious decision by Google to insert these discrepancies in the first place.

The capacitySync setting is a bit more straightforward, albeit more intrusive as it modifies OS values instead of just modifying ACC's view of the system itself. The code for capacitySync is pretty small:

Code:
 # correct the battery capacity reported by Android
  if eval $(get_value capacitySync); then
    dumpsys battery reset || :
    dumpsys battery set level $(cat $batt/capacity) || :
  fi > /dev/null 2>&1

Basically what it does is check to see if you have capacitySync to true. If you do it simply uses dumpsys to set the battery level to that reported by the kernel. IOW, it forces the kernel value into the OS by means of dumpsys battery set.

This is embedded in the is_charging() subroutine, but I'm not sure yet when this routine is run. The sync is clearly working even when the phone is discharging, so it does run all the time. It appears to execute every 60 seconds, and I'm not sure if this is configurable. I believe this is the preferable option based on all the reasons listed above that I am wary of offsetCapacity. Again, I don't know how taxing this is on the system, but it appears that this is embedded within a subroutine that will run regardless of if this option is set or not. The only additional load on the system is the additional dumpsys command which should not cause any noticeable drain on resources.

The last option which I couldn't find a direct answer about was the forceStatusAt100. The README states what it does, but isn't incredibly descriptive if you don't know the background:

Workaround for end-of-charge issues on Android 10 (e.g., force fully charged status at 100% capacity, value 5 for Pixel devices)
.

The code is here:

Code:
    # forceStatusAt100
    if ! $forcedStatusAt100 && [[ "$(get_value forceStatusAt100)" == [0-9]* ]] && [ $(cat $batt/capacity) -gt 99 ]; then
      dumpsys battery set level 100 2>/dev/null \
        && dumpsys battery set status $(get_value forceStatusAt100) 2>/dev/null \
        && { forcedStatusAt100=true; frozenBattSvc=true; } \
        || sleep $(get_value loopDelay | cut -d, -f1)
    fi

  else

    # revert forceStatusAt100
    if $frozenBattSvc; then
      dumpsys battery reset 2>/dev/null \
        && { frozenBattSvc=false; forcedStatusAt100=false; } \
        || sleep $(get_value loopDelay | cut -d, -f2)
    fi

Basically what this appears to do is if forceStatusAt100=5 and the kernel reports the battery capacity as greater than 99 (i.e. 100%), then it will force the value of 100 into the OS. Additionally it will update the status of the battery to "5" which is the way to signal to the OS that the battery has reached "Full" charge. It will keep the value at 100% as long as the kernel reports it while charging and once charging is done will reset the OS values back to whatever the original value it believed was.

I'm not aware of the situation that required this piece of code. It appears that there must be an issue on some Pixels where the kernel believes it is charged to 100% but the device is only reporting 99% (or maybe less)? In these cases triggers which depend on the OS reporting 100% would fail to run. This would fix that both cosmetically (through the set level) and functionally (through the set status).

I haven't seen this yet on my phone, but based on what I see in the code it shouldn't hurt to enable this option even if you aren't affected by this particular problem. After all, if your device is already reporting 100/Full then forcing these values there isn't going to change anything.

So - some mysteries solved, some mysteries remain.

Hope this helped someone else!
 
  • Like
Reactions: alispeedsport

Top Liked Posts

  • There are no posts matching your filters.
  • 20
    While I've had many Android phones, this is the first phone that I decided to use a battery charging controller to regulate how my battery is charged. I just wanted to share my journey with others and encourage others to try this out if you are not already.

    Although there are several different battery charging controllers out there (and more than one named "ACC" which makes it even more confusing) I decided to use the Advanced Charging Controller module developed by VR25. I choose this module because I felt it provided the most customization.

    Step 1 - Installation
    Installing the module is easy. It is listed in the Magisk repository. Simply browse the available modules and find the one titled, "Advanced Charging Controller (acc) created by VR25 @ XDA-developers". There are several ACC modules, so make sure you install the one by VR25 to follow this thread.

    Magisk will flash the module and start it automatically. You don't even need to reboot, although it is the only way to clear the Magisk notification that the module will be started at the next reboot.

    Step 2 - Changing the Charging Switch Setting
    I found that the default charging switch setting (auto) does not work reliably with our phones. Therefore I would suggest changing it using the commands below. Personally I have choose option 2 (battery/charge_disable 0 1) but I listed all the options with the quirks that I have found with each one.

    Step 2.1 - open your preferred command line app - I use Terminal Emulator.
    Step 2.2 - type "su" and hit enter to gain root
    Step 2.3 - type "acc -s s" and hit enter - this is the command that allows us to select another charging switch
    Step 2.4 - type what number of the charging switch you want to use.

    Here are the available charging switches and the issues I have found with them:
    1) Automatic - this switch tries to cycle through the available switches until if find one that "works".
    - Passes the ACC switch test (type "acc -t"): Yes
    - Charges and discharges according to the cooldownratio: No - I found that the phone would charge anytime it was plugged in and below the Pause threshold. It did not seem to wait until the battery level was below the Resume threshold.
    - Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): Yes
    - Begins charging when phone reaches Resume threshold: Yes
    - Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: ???
    - Suffers from wakelock issues when phone is plugged in but not charging: It does have a "overheat_mitigation" wakelock when on the battery idle mode, but because the phone is not using the battery power, it doesn't effect battery life and therefore I don't concern myself with this issue.
    - Other issues:​

    2) battery/charge_disable 0 1 :
    - Passes the ACC switch test (type "acc -t"): Yes
    - Charges and discharges according to the cooldownratio: Yes
    - Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): Yes
    - Begins charging when phone reaches Resume threshold: Yes
    - Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: ???
    - Suffers from wakelock issues when phone is plugged in but not charging: It does have a "overheat_mitigation" wakelock when on the battery idle mode, but because the phone is not using the battery power, it doesn't effect battery life and therefore I don't concern myself with this issue.
    - Other issues:
    3) battery/input_suspend 0 1:
    - Passes the ACC switch test (type "acc -t"): Yes
    - Charges and discharges according to the cooldownratio: Yes
    - Works with battery idle mode (the phone will pull power from the AC power and not the battery when the battery reaches the Pause threshold): No - phone begins discharging from battery when Pause threshold is reached but the phone is still plugged in
    - Begins charging when phone reaches Resume threshold: Yes
    - Charging "chime" and battery icons correctly reflect if the phone is charging or discharging: No - may show charging icon when phone is really discharging, especially during cooldownratio times and the chime doesn't always ring when charging resumes.
    - Suffers from wakelock issues when phone is plugged in but not charging: No
    - Other issues: The phone seems to follow the cooldown charge/discharge times even before reaching the cooldown threshold. I find the phone pausing for 10 seconds (my cool down ratio) when the batter level might be a 50% - long before the 60% cooldown threshold I have set in the config file.
    4) dc/input_suspend 0 1:
    - Passes the ACC switch test (type "acc -t"): NO, so this switch doesn't work with ACC
    - Charges and discharges according to the cooldownratio:
    - Starts discharging when the phone reaches the Pause threshold:
    - Begins charging when phone reaches Resume threshold:
    - Charging "chime" and battery icons correctly reflect if the phone is charging or discharging:
    - Suffers from wakelock issues when phone is plugged in but not charging:
    - Other issues:
    5) battery/charge_control_limit 0 1:
    - Passes the ACC switch test (type "acc -t"): NO, so this switch doesn't work with ACC
    - Charges and discharges according to the cooldownratio:
    - Starts discharging when the phone reaches the Pause threshold:
    - Begins charging when phone reaches Resume threshold:
    - Charging "chime" and battery icons correctly reflect if the phone is charging or discharging:
    - Suffers from wakelock issues when phone is plugged in but not charging:
    - Other issues:

    Step 3 - Configuration
    You can configure the ACC controller using a couple of different methods. You can do everything using command lines, you can use the beta ACC app (see note below), or you can edit a config file that ACC creates when it is installed. Personally I found that editing the config file was the quickest and easiest method to make general changes.

    The ACC config file is found at /storage/emulated/0/acc The file is named "config.txt" You can open the file with a text editor. I personally use the app Root Explorer. I long click on the file name, and then press the three dot button in the upper right hand corner. Choose "Open in Text Editor" and the config file will open and allow changes to be made. Saving the file will automatically push the changes to ACC, you do not need to reboot or restart the ACC daemon for changes to take effect.

    I won't go into a lot of detail about all of the different configuration options here as the developer's xda thread is the best place to get that type of information. But I will talk about the most basic setting - the "capacity" setting. It is the second setting listed in the config file and it should look something like "capacity=0, 60, 70-80". Here is a break down of what those numbers mean:
    - The First Number (0): is battery level were the phone will shut off. The default setting of 0 means the phone will turn off when the battery level hits 0. Personally I don't want my battery completely draining, so I have it set at 5.
    - The Second Number (60): is the battery level where the module starts it's "cool down" functionality. Cool down (listed as coolDownRatio in the config file) is where the phone will stop charging briefly and then restart charging. The default "cool down" setting is coolDownRatio=50/10 which means the phone will charge for 50 seconds, and then stop charging for 10 seconds before charging again for 50 seconds, etc, etc, etc. This is designed to keep the battery temps low. A battery with a charge level less than this number (60 in this example) will charge without pausing, but when the battery level gets to this number or above, the phone will charge and pause based on the coolDownRatio.
    - The Third Number (70): is the "resume" value. If the phone's battery level is below this resume value, the phone will charge. If the battery level is at or above this resume value, the phone will not charge even while plugged in.
    - The Fourth Number (80): is the "pause" value. This is the battery level where the phone will stop charging and should not charge above this value.​

    The default settings are set this way because research has shown that a phone's battery will last the longest with the least amount of battery capacity loss if it is charged to a max of 80% of the battery's capacity, and allowed to discharge just a small amount (10%) before being charged again. I realize this goes against the old "wives tale" that our phone's batteries have a very limited number of charges and it is best to limit the number of charges by only charging the phone when it gets to a low level. This is not true in actual battery performance however and if you charge like this, you are actually decreasing your battery's life expectancy and performance.

    Obviously the default settings may not be the best setting for you. The default settings are probably only practical for a device that is plugged in 100% of the time. Personally I have changed my capacity setting to capacity=5, 60, 70-90. This means my phone will turn off when the battery level reaches 5% (something it has never dropped to yet), it is charged to a max of 90% and will discharge to 70% before charging again, and the cooldown charging cycling starts when the battery is 60% or higher. Obviously I'm not on my charger all the time, so it is very common for my battery to drop below 70%. However, if the battery is below 70% and I have a charger at my disposal, I am going to charge the phone back to 90% rather than let it the battery levels continue to fall.


    Final Notes and Misc Thoughts
    There are lots of other options and commands you can use in ACC. Feel free to share any changes you like to make, or post if you are having problems getting the module to work as expected on the 3a. I hope this helps some people feel give the module a try.

    There is an ACC app that is available now that allows you to control some of the settings from a nice GUI. I personally did not like using it as I found it would overwrite settings in the config file that I was not intending to be changed.

    There is an ACC telegram group if you want to join and have direct communication with the developer and others.

    Thanks to @jellopuddingstick for educating me on what the battery idle mode does and why it is beneficial to have it working!
    3
    if you want to extend your batteries life, one of the best ways is to not fast charge it. fast charging not only degrades it a bit faster because of the amount of current, but it also tends to heat the battery up more which makes it degrade even faster too. heat is the main reason i tell people not to use wireless charging.
    2
    Any particular reason you do this?

    The Pixel 3a devices support "Battery Idle" mode which basically says anytime the phone has reach a "full" charge and is still plugged into a power source, the phone will bypass the battery and draw power directly from the power source. So whether you tell the phone that a full charge is 42% or 80%, once it hits that number it bypasses the battery completely. There is no harm is letting the battery charge to 80% and then leaving it plugged in for extended periods of time.

    Phones that don't support "Battery Idle" mode will draw power from the battery while also charging the battery - even when the battery is fully changed.

    Phones that support "Battery Idle" mode at full charge and still plugged in:
    Power supply --> Phone​
    Phones that don't support "Battery Idle" mode at full charge and still plugged in:
    Power Supply --> Battery --> Phone​
    Fair question [emoji846]

    There are two reasons. I've had my Tasker setup since ~2015. The P3XL (not P3aXL) is the first device I've owned that supported battery idle mode. I'm too lazy to tweak a working Tasker project. Additionally, the battery is happiest at ~42% and the extended days I have when driving allows the battery to live there. Obviously, it's not practical if the device can not be plugged in all day.

    Also, when I post here, I try to keep in mind that there many different devices. Many do not support battery idle mode and especially in those cases, I believe the battery is better served to be cycled at ~42% if plugged in for extended periods.

    (Even though this is a device specific forum, it will be read by many people without the device)
    2
    There's a bit of misinformation / misunderstanding going on here, I think. The best control file for our devices is battery/charge_disable. The "maintenance charge" (ACC refers to it as "idle mode") you're referring to is a good thing! This is explained both in the ACC readme [1] and by the developer of Battery Charge Limit [2][3]. The ping-ponging between the upper and lower thresholds is a fallback, it's not the desired mechanism. Hope this clears things up!

    [1] "Charging switches that support battery idle mode take precedence", https://github.com/VR-25/acc/blob/master/README.md
    [2] https://forum.xda-developers.com/showpost.php?p=76523599&postcount=1834
    [3] https://android.stackexchange.com/a/200037
    1
    So why are my options different from what you have in the guide? @sic0048


    I should also state I am on Pixel 5...
    This guide was written nearly two years ago. That meant we were on Android Pie (9) back then. A lot has change in the two major OS versions that have since been released and it's not surprising that the switches might have changed. Plus, being a different phone may mean your switches are different too.