ACC is not working on Google Tensor Devices (Pixel 6 and newer)

[eugenesan]

It seems like current implementation is not compatible with charger controls on devices with Google's Tensor SoC.

Tried to use "/sys/devices/platform/google,charger/charge_start_level 100 5" and "/sys/devices/platform/google,charger/charge_start_level 80 5". ACC seems to be constantly "playing around" since it doesn't get proper and timely feedback from current and charging status.

Charging on Tensor devices can be controlled using: /sys/devices/platform/google,charger/charge_stop_level /sys/devices/platform/google,charger/charge_start_level

For example to set charging at 80%: echo 80 > /sys/devices/platform/google,charger/charge_stop_level echo 79 > /sys/devices/platform/google,charger/charge_start_level

Caveats/Observations:

1. Controls seemingly randomly revert to defaults even with "Adaptive Battery Management" disabled.
2. Current is not going to 0mA right away but instead the charger will slowly (~150mA at idle) discharge to 1% under the "stop" value, quickly charge to "stop" value and only then switch to real "IDLE" mode (<10mA).
3. If SOC is above "stop" value, the device will simply discharge until SOC is %1 under the "stop" value and continue the process described in 2.
4. /sys/devices/platform/google,battery/power_supply/battery/status reports "Not charging" for both discharging and idle modes.
5. In "IDLE" mode, current fluctuates between +10mA and -10mA.

Possible solution:

1. If current SOC is above desired value, adjust "stop" value to current SOC +1% and wait for current to go below 10mA without doing anything.
2. If current SOC is at desired value, wait for current to go below 10mA without doing anything.
3. If current SOC is below, wait for SOC to reach desired value and then wait for current to go below 10mA without doing anything.

P.S. I believe "start" value just triggers charging until SOC it is at the "stop" value and after that only the "stop" value will affects charging.

[wimex]

@eugenesan thank you for collecting all this information, I was working on something similar for the past few days but didn't get this far. I was experimenting a lot with idle mode and couldn't get it working properly, your description explains why this is. Acc reports that it's supported tough. I have a Pixel 7a and I can help beta test things if there is a new version.

[VR-25]

Great information! I'll work on it and share builds here.

[eugenesan]

@eugenesan thank you for collecting all this information, I was working on something similar for the past few days but didn't get this far. I was experimenting a lot with idle mode and couldn't get it working properly, your description explains why this is. Acc reports that it's supported tough. I have a Pixel 7a and I can help beta test things if there is a new version.

I am testing on Pixel 7a as well. Though according to reports on various forums, it seems like it works on all Pixel 6 and newer.

As a temporary workaround I am using Magisk module from: https://forum.xda-developers.com/t/mod-magisk-root-set-charging-limit-to-80-85-90-95-v2.4482011/ to enable charging control on boot.

To control charging after boot I am using a few scripts:

To set charging to 80%: google_tensor_charge_limit_80.sh

#!/system/bin/sh -x

cat /sys/devices/platform/google,battery/power_supply/battery/status
cat /sys/devices/platform/google,charger/charge_start_level
cat /sys/devices/platform/google,charger/charge_stop_level

echo 79 > /sys/devices/platform/google,charger/charge_start_level
echo 80 > /sys/devices/platform/google,charger/charge_stop_level

To revert to 100%: #!/system/bin/sh -x

cat /sys/devices/platform/google,battery/power_supply/battery/status
cat /sys/devices/platform/google,charger/charge_start_level
cat /sys/devices/platform/google,charger/charge_stop_level

echo 99 > /sys/devices/platform/google,charger/charge_start_level
echo 100 > /sys/devices/platform/google,charger/charge_stop_level

To read current status: google_tensor_charge_limit_cur.sh

#!/system/bin/sh -x

cat /sys/devices/platform/google,battery/power_supply/battery/status
cat /sys/devices/platform/google,charger/charge_start_level
cat /sys/devices/platform/google,charger/charge_stop_level

P.S. For me the easiest way to manage and run scripts is to use X-Plore

[VR-25]

I'd like to see the result of acc -t /sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity.

Btw, what's the default value of charge_start_level?

X-Plore has been an all-time favorite since the Symbian days.

[wimex]

For me it's this:

This may take a while... ⏳
Ensure the charger is plugged 🔌
Hang on...
  switch: - (N/A)       current: -2290mA (Charging)
  switch: - (N/A)       current: -2290mA (Charging)

/sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity
  switch: off (48)      current: -12mA (Idle)
  switch: on (100)      current: -2284mA (Charging)
  Switch works ✅
- battIdleMode=true

Charge_start_level is currently 0 for me although acc is active so I'm not sure if that's the default.

[VR-25]

Ok, it's zero, then.

Set that switch and see if it actually works reliably.

acc -s s="/sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity --"

[wimex]

This is correct, right? I'll report back in a few hours.

[VR-25]

Sorry, I edited my previous comment. The "acc -t " part shouldn't be there. The switch is /sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity with trailing " --". The full line becomes: /sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity --. The " --" is there to prevent the switch from being automatically unset/replaced in case it fails for whatever reason. ACC will keep trying to use it anyway.

[wimex]

Okay, testing this now...

[wimex]

For me this seems to be working perfectly, even the idle mode looks good. Charged until 80% then stayed like this, didn't discharge 1-2% like before.

[eugenesan]

Similarly to @wimex, provided ACC setting (https://github.com/VR-25/acc/issues/201#issuecomment-1646545327) seems to be working.

_Note: Below are my "raw" observations and conclusions which are not directly related to ACC but might be useful to understand how Tensor devices control power delivery. Also it seems that most of the issues won't appear if Tensor devices are used in optimal conditions (idle CPU, low environment temperature and 18W charger).

Observations:

1. Percentage readings are inconsistent. For example at some point ACC was reading 59%, ACCA was reading 58%, Android status bar was showing 60%.
2. The reading of Android status bar was fluctuating between 58%-60% for a few minutes until it settled on 60% and ACC switched to IDLE mode.
3. Charging Tensor devices with background activities (HotSpot, Downloads etc) is inconsistent. It seems like the phone stays hot all the time when not idling which affects power delivery.

Experiment:

Conditions:

1. Enabled a HotSpot on Pixel7a
2. Connected to 5V/1A charger
3. Disabled ACC (to see how start/stop values behave on their own)
4. Set start/stop values to 64/65
5. Waited for SOC to reach 65% and switch to IDLE
6. Let it run for 12H

Result: After 12H SOC was at 57% and battery temp was ~15C above room temperature

Conclusions:

1. Tensor is very power hungry when not idling. If my calculations are correct HotSpot consumes ~350mA, which is A LOT!
2. Not sure how exactly thermal optimizations are set on Tensor devices but when the battery is at 37C, combined power delivery is limited to 500mA. As result SOC won't be consistent and might even go down.
3. ACC might have to intervene once in a while to compensate for the lost charge if the charger is not providing enough power at all times. I think current implementation already supports that.
4. Disparity in power delivery and consumption might confuse the heck out of ACC. I've seen charging status fluctuate between Discharge(main)/Charge(main). Even when I tried 12W and 30W chargers it took ~10min to gain 1% of SOC because power delivery was limited, probably due to thermal constrains.

[wimex]

So after testing it for a few days it looks like it works okay. Sometimes there is a 1-2% charge drop during idle mode, I can't consistently reproduce it though. I also noticed the percentage inaccuracy but I don't think it's an ACC bug because the inaccuracy also exists between the system and AccuBattery (I'm using LineageOS btw).

[eugenesan]

So after testing it for a few days it looks like it works okay. Sometimes there is a 1-2% charge drop during idle mode, I can't consistently reproduce it though. I also noticed the percentage inaccuracy but I don't think it's an ACC bug because the inaccuracy also exists between the system and AccuBattery (I'm using LineageOS btw).

I concur. As I reported before, Tensor is very power inefficient and is hot all the time (unless it is idle and is not charging). It starts limiting power input severely when the battery reaches 37C which causes all the issues. I rarely saw it under 37C making it barely useful in idle mode.

In fact it was so bad that I returned my Pixel 7a. I guess I'll try again when phones with Tensor3 will show up this fall.

@VR-25 I think we can close this issue as ACC is doing everything that is possible for that platform.

[wimex]

Would it be possible to use ACC to raise the 37C cutoff temperature? I was experimenting with different charging heads and sometimes they worked, sometimes they didn't and I just realized that maybe this was the issue.

[VR-25]

Would it be possible to use ACC to raise the 37C cutoff temperature? I was experimenting with different charging heads and sometimes they worked, sometimes they didn't and I just realized that maybe this was the issue.

It may be possible. I need to take a look at the power supply interface. Share a log archive generated by acc -le.

[wimex]

Here it is There are some files in the google,charger directory that might be related:

• bd_resume_abs_temp
• bd_resume_temp
• bd_temp_dry_run
• bd_temp_enable
• bd_trigger_temp

E.g. bd_trigger_temp is 350 which might be 35 Celsius * 10? Just guessing here...

[VR-25]

E.g. bd_trigger_temp is 350 which might be 35 Celsius * 10? Just guessing here...

Yes, that's the same on all devices, °C * 10.

[beeshyams]

Pixel 6a stock July update with latest ACC version. I set acc -s mcv=4200 and the flickering stopped with the switch recommended by @VR-25 acc -s s="/sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity --"

Edit: Idle mode battery is at 37.5 ° C so it should address thermal issues raised.

Of course, the charging speed is slow but it suits me fine. I am currently experimenting with 4150 mV , which seems to be the lowest it accepts without stopping charging (and entering idle mode) Edit 2: Anything lower than 4200 mV is unreliable. It charges and at some point goes into idle mode. So, I will stick with 4200 mV and will test for some days. If I don't update the comment here after a week, please assume 4200 mV works.

May be considered if charging speed is not an issue

[thejohnha]

I've experienced this behavior (with default profile, charges to 80% but as soon as it drops to 79% it starts charging again) with Pixel 6 Pro and Pixel 7 Pro on versions v2023.8.19 and v2023.8.12. Reverted to version v2023.7.17 and works as expected. Hope this helps others.

[alensiljak]

Hi. I'm on Pixel 7 with LineageOS 20 and the ACCA module simply crashes if the charger is connected. I have not run the acc commands above as there is no Terminal available in the Developer settings. I may try with ADB. I did enter the line through the app UI but am not sure if it is correct. The test charging switch just closed and the switch is now visible on the main screen but not in the list of switches. Let me know if there is anything I can do to help.

(edited the message, adding more details)

[alensiljak]

Using

sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity --

The test never seems to complete. The app seems to hang for a while.

It also shows that the current is ~-300mA, i.e. discharging, while Charge Control shows ~+300, i.e. charging. The device is connected. Edit: The ACC is correct here. The USB port I used (with a mechanical switch) was not providing enough power to charge, although the charging indicator was on.

Edit2: However, the charging did not stop at 80% as set in the profile. When I open ACC, I see that the Daemon is not running. It seems to crash whenever it needs to take some action.

[alensiljak]

Reverted to version v2023.7.17 and works as expected. Hope this helps others.

Thanks for that! Indeed it does. The charging stopped at the preset value in a quick test after reverting to this version. Will do a real trial on Monday, when the phone is connected to a cable for most of the day.

[VR-25]

Here it is There are some files in the google,charger directory that might be related:

* bd_resume_abs_temp

* bd_resume_temp

* bd_temp_dry_run

* bd_temp_enable

* bd_trigger_temp

E.g. bd_trigger_temp is 350 which might be 35 Celsius * 10? Just guessing here...

Have you explored this further?

[VR-25]

I've experienced this behavior (with default profile, charges to 80% but as soon as it drops to 79% it starts charging again) with Pixel 6 Pro and Pixel 7 Pro on versions v2023.8.19 and v2023.8.12. Reverted to version v2023.7.17 and works as expected. Hope this helps others.

Which switch are you using? Check with acc -sp sw.

[VR-25]

Reverted to version v2023.7.17 and works as expected. Hope this helps others.

Thanks for that! Indeed it does. The charging stopped at the preset value in a quick test after reverting to this version. Will do a real trial on Monday, when the phone is connected to a cable for most of the day.

Which acc version were you using before installing v2023.7.17?

Note: AccA (the app) is not supported here nor recommended. It comes with a very old acc build and the developer has suspended development.

[thejohnha]

Note: AccA (the app) is not supported here nor recommended. It comes with a very old acc build and the developer has suspended development.

Oops, guilty. I saw it was the first front end listed on the xda thread and was influenced by that. I'll switch to crazyboyfeng's app and try the newer versions of acc again. Thank you for this knowledge!

p.s. @VR-25 if you might have suggestions for any front ends, I think we would be very grateful to know. Perhaps you could share them on the first post of the xda thread for wider reach. Much appreciated for your many years of work on acc which is one of the main reasons I prefer android to the alternatives. My phone is about a year old now and AccuBattery says the health is 99%! How amazing 🤩 and I have you to thank for it. Just think of the resource savings and phone longevity if everyone used this important tool 🙏

[alensiljak]

Which acc version were you using before installing v2023.7.17?

Hmm, hard to say now but the latest selectable is 2023.8.19

Note: AccA (the app) is not supported here nor recommended. It comes with a very old acc build and the developer has suspended development.

Oh, I wasn't aware of that. I know of ACC only through AccA. I was under the impression that they were part of the same package. Sorry for that. Good to learn that there are other GUI apps out there, too. Will have to do some more reading on this and try some. I simply had AccA working for years on Mi 9T without any issues and didn't think about it twice. That said, the latest ACC version listed in AccA seems fairly recent to me.

[VR-25]

Which acc version were you using before installing v2023.7.17?

Hmm, hard to say now but the latest selectable is 2023.8.19

Note: AccA (the app) is not supported here nor recommended. It comes with a very old acc build and the developer has suspended development.

Oh, I wasn't aware of that. I know of ACC only through AccA. I was under the impression that they were part of the same package. Sorry for that. Good to learn that there are other GUI apps out there, too. Will have to do some more reading on this and try some. I simply had AccA working for years on Mi 9T without any issues and didn't think about it twice. That said, the latest ACC version listed in AccA seems fairly recent to me.

Nevertheless, I'm keeping acc backwards compatible with AccA. So, if you still want to use the app, be my guest. Update acc whenever you face issues.

Back to the issue, see if you still face it after upgrading to the latest snapshot (acc -u -f dev) and changing the switch (acc -s s="/sys/devices/platform/google,charger/charge_stop_level 100 5").

You can always rollback to the previous installation and config by simply running acc -b.

[alensiljak]

With the Dev version, Aug 19, and the switch above, the charging seems to go to idle mode when the limit is reached. It does not stop the charging indicator. This is probably better than to continuously cycle in a i.e. 60-80% loop.

[beeshyams]

The charging icon is on by default even on idle mode

To disable charging icon in idle mode

su acc -s rbsp=true

---

17-Sept-2023 1:59:45 am Alen Šiljak @.***>:

With the Dev version, Aug 19, the charging seems to go to idle mode when the limit is reached. It does not stop the charging indicator. This is probably better than to continuously cycle in a i.e. 60-80% loop.

— Reply to this email directly, view it on GitHub[https://github.com/VR-25/acc/issues/201#issuecomment-1722309778], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AFPKOXUYPTKHU3ABKQUOTRLX2YD3TANCNFSM6AAAAAA2SOMWAI]. You are receiving this because you commented. [Tracking image][https://github.com/notifications/beacon/AFPKOXUPJ4LQYGCMRSUOVZTX2YD3TA5CNFSM6AAAAAA2SOMWAKWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTTGVBOJE.gif]

 [content://com.android.providers.media.documents/document/image%3A22800]

Rgds... Shyam

[VR-25]

With the Dev version, Aug 19, and the switch above, the charging seems to go to idle mode when the limit is reached. It does not stop the charging indicator. This is probably better than to continuously cycle in a i.e. 60-80% loop.

In idle mode, it's not uncommon to have a persistent charging indicator. It just shows that the charger is plugged.

[VR-25]

acc_v2023.9.17-dev_202309170_1042.zip

Fixed restricted current, accd crash, and control file related issues. Direct upgrade: acc -u -f dev

[alensiljak]

Current findings for Pixel 7:

The /sys/devices/platform/google,charger/charge_stop_level 100 5 switch works well without the idle mode. It stops correctly, then discharges the battery until the lower limit, then goes back to charging...

The gcpm/constant_charge_current_max 3000000 0 goes into the idle mode correctly. Not sure where the 3000000 vs 4280000 comes from. The 4280000 version seems to have acted a bit weird so I'm using the 3000000 one. Will stay on this and observe details.

accd seems to die occasionally and that contributed to prior confusion with not stopping at limits. This is also not obvious until one runs acc itself, to check.

[alensiljak]

Confirming that the 4280000 value keeps switching on/off when the limit is hit, while the 3000000 one goes into the idle mode correctly.

[alensiljak]

After adding the capacity_sync=false switch (or cs=false, for short), the annoying on/off switching sounds have gone away. This sorts out an annoyance which allows focusing on the actual switch. As for the values in the switch, the 428... value seems to work just as well now. Idling works correctly, at pretty-much 0.00A.

The thing that hindered the observation was the fact that accd would stop at times. So, all in all, the

gcpm/constant_charge_current_max 4280000 0

switch seems to work well, in combination with cs and making sure that accd is running if no action on the limit. Even if the capacity limit is passed during charging with accd off, the phone will correctly go into Idle mode once accd is started again. This seems to work well.

All in all, I'd say that acc (the latest version 2023.10.9) works fine on Pixel 7 and hopefully other Tensor devices. Will keep observing for a bit longer, however. Not sure if the charger max power has effect since I've used the same power source most of the time.

[eugenesan]

@VR-25 I started testing latest (v2023.10.1) on Pixel 8 (Tensor 3).

Started with default settings (fresh install of AccA):

1. Installed latest (v2023.10.1) using AccA settings UI
2. Changed charging switch to: charge_stop_level 100 battery/capacity
3. Disabled automatic cycle through switches
4. Idle mode was on by default
5. Changed Resume to 77 and Stop to 78 (just random range at which the phone was at the time)

And it seems to be working. On the very first try ;-)

Surprisingly (at least to me), it seems like OS reacts to acc stopping the charge. The moment Status changes to "Not charging (GCPM)", Andoid Settings UI pops-up the following notification:

**Protecting your battery**
Charging is optimized to help extend your battery's lifespan
<<Learn More>> <<Charge to full>>

Now, the questions are:

1. Should we continue discussing the topic in a new issues?
2. Is that expected behavior with Tensor 3 and Android 14?
3. If more investigation is needed, what information do I need to post?

Thanks.

[VR-25]

@eugenesan, this means the system uses that same switch for its "battery care" feature -- and should not be an issue, since automatic cycling is off. Is there any toggle for that built-in Pixel feature to get rid of the message?

[eugenesan]

@VR-25 The notification is not an issue. I actually kinda like it. it's silent and unobtrusive and let's you know if the charging is idling without firing AccA. Also, when you disconnect the charger the notification changes and informs for how long the charging was "optimized". Since the notification is standard notification it can be easily customized to users liking.

Regarding settings; there is no setting to control the notification and Adaptive Battery setting moved to Battery Saver screen.

[hatl]

Current findings for Pixel 7:

The /sys/devices/platform/google,charger/charge_stop_level 100 5 switch works well without the idle mode. It stops correctly, then discharges the battery until the lower limit, then goes back to charging...

I see the same behavior on Pixel 8 and Pixel 8 pro.

The gcpm/constant_charge_current_max 3000000 0 goes into the idle mode correctly. Not sure where the 3000000 vs 4280000 comes from. The 4280000 version seems to have acted a bit weird so I'm using the 3000000 one. Will stay on this and observe details.

In my case it's 5940000 directly after plugging in the charger.

Maybe there's another option to enter idle mode?

[eugenesan]

Current findings for Pixel 7: The /sys/devices/platform/google,charger/charge_stop_level 100 5 switch works well without the idle mode. It stops correctly, then discharges the battery until the lower limit, then goes back to charging...

I see the same behavior on Pixel 8 and Pixel 8 pro.

The gcpm/constant_charge_current_max 3000000 0 goes into the idle mode correctly. Not sure where the 3000000 vs 4280000 comes from. The 4280000 version seems to have acted a bit weird so I'm using the 3000000 one. Will stay on this and observe details.

In my case it's 5940000 directly after plugging in the charger.

Maybe there's another option to enter idle mode?

@hatl Please see https://github.com/VR-25/acc/issues/201#issuecomment-1765523358 how to setup IDLE mode on Pixel 8

[hatl]

As far as I understand it setting start/stop to e.g. 79, 80 will constantly charge and discharge the battery. Of course with a very low current. But this would actually be bad for the battery life time - or am I overlooking something?

[eugenesan]

As far as I understand it setting start/stop to e.g. 79, 80 will constantly charge and discharge the battery. Of course with a very low current. But this would actually be bad for the battery life time - or am I overlooking something?

If you use Tensor specific charge_stop_level 100 battery/capacity and enable ACC's IDLE mode that will utilize Tensor's built-in idle capabilities. From experience with Pixel 7a and Pixel 8, it works. If you monitor charging current using AccA you'll notice that after the state of charge inside defined range and after battery voltage settles, the battery will stop charging and only occasionally you'll see ~10mA drain which is normal since battery voltage can drift a little once in a while. I believe it to be as close as possible to an ideal IDLE mode on Tensor SoC. Also, Pixel's built-in charging optimizer AI uses exactly the same switches (on Tensor SoCs) and on Android 14 you will see OS notifications reacting to ACC interacting with those switches as if it was the OS enabling the idle mode.

[alensiljak]

I've installed the latest dev and tried the /sys/devices/platform/google,charger/charge_stop_level 100 battery/capacity switch again on Pixel 7. It seems to work well, just like the gcpm/constant_charge_current_max 4280000 0, I used until now. Thanks for the tip. I'll keep this on.