Closed leifalbor closed 3 years ago
Still not working with Magisk v21.1 and acc V2020.11.20.
No errors in Magisk log.
Stock build RD1A.200810.022.A4
Also not working on the December 2020 update with stock kernel, nor with ElementX 1.0.4 kernel.
It also does not work on my Pixel 4a 5G Dec and Jan update
I can confirm it doesn't work on Pixel 5, but only after July update. It worked flawlessly before. It seems that all 4 charging switches are unavailable now. Is there anything we can do to make it work again?
I'll soon push an update with new charging switches and more.
I'll soon push an update with new charging switches and more.
Nice! Hope you're doing well dude - I thought you must have abandoned the entire project!
I'll soon push an update with new charging switches and more.
That would be great.
I'll soon push an update with new charging switches and more.
Unfortunately, the update doesn't seem to bring any fix to this issue. I also noticed that the acc daemon crashes/stops working for some reason. When I occasionally run "acc" in terminal (or over adb) it says the daemon isn't running, even though I started it like a few minutes ago. Is there any particular logs you'd like to see?
Charging switch test says none of them work, but the Acc App says that
UPD: The app says so for any switch, so I guess it's broken.dc/input_suspend
works, although I didn't notice it affecting charging.
I'm running latest stock on Pixel 5. I haven't had any issues with acc at all on my old phone (OG Pixel) and Pixel 5 (until the latest firmware update). I also tried ElementalX kernel, but no luck with it either.
I'll soon push an update with new charging switches and more.
Unfortunately, the update doesn't seem to bring any fix to this issue. I also noticed that the acc daemon crashes/stops working for some reason. When I occasionally run "acc" in terminal (or over adb) it says the daemon isn't running, even though I started it like a few minutes ago. Is there any particular logs you'd like to see?
~Charging switch test says none of them work, but the Acc App says that
dc/input_suspend
works, although I didn't notice it affecting charging.~ UPD: The app says so for any switch, so I guess it's broken.I'm running latest stock on Pixel 5. I haven't had any issues with acc at all on my old phone (OG Pixel) and Pixel 5 (until the latest firmware update). I also tried ElementalX kernel, but no luck with it either.
After the daemon stops, you can grab /dev/.vr25/acc/accd-*.log
.
Alternatively, run acc -l cat > /sdcard/accd.log
regarding charging control, have you tried a regular adapter (a.k.a., slow charger)?
After the daemon stops, you can grab
/dev/.vr25/acc/accd-*.log
. Alternatively, runacc -l cat > /sdcard/accd.log
Here you go: accd.log.
regarding charging control, have you tried a regular adapter (a.k.a., slow charger)?
I usually use slow wireless charger. When I performed the tests from my last comment my phone was connected to a laptop via USB-A - USB-C cable.
Here you go: accd.log.
exitCode=7
means all charging switches are failing - i.e., none of them responds when toggled.
I usually use slow wireless charger. When I performed the tests from my last comment my phone was connected to a laptop via USB-A - USB-C cable.
I see.
This really has to do with the kernel.
Have you tried voltage and current control?
Speaking of current, acc -ss
has presets of 0-500 mA.
You may want to try the lowest values and see if charging stops or at least slows down dramatically.
Monitor changes with acc -i
or acc -w1
.
Regarding voltage, it''s just a matter of testing whether the limit is honored.
acc -sv 3920
: 3920 millivolts
acc -sv -
: restore default
P.S., see if changing switchDelay=2
to switchDelay=5
in /data/adb/modules/acc/misc-functions.sh
(line 379) solves the charging switch issue.
Restart accd after the change.
One-line: sed -i '/switchDelay=2/s/2/5/' /data/adb/modules/acc/misc-functions.sh; accd
Revert: sed -i '/switchDelay=5/s/5/2/' /data/adb/modules/acc/misc-functions.sh; accd
Have you tried voltage and current control?
I tried just now and voltage limit seems to be working. As soon as I set the voltage limit to 3920, it stops charging and current becomes negative (battery voltage is over 4200mV now).
Speaking of current,
acc -ss
has presets of 0-500 mA. You may want to try the lowest values and see if charging stops or at least slows down dramatically.
No luck with that, though. I tried acc -s --current 10
and it kinda worked. But strange, though. Sometimes current goes up more than 800mA:
CURRENT_NOW=784302
CURRENT_NOW=805969
CURRENT_NOW=-423889
CURRENT_NOW=-246582
CURRENT_NOW=-174865
CURRENT_NOW=-195617
CURRENT_NOW=-188293
CURRENT_NOW=6408
CURRENT_NOW=-53100
CURRENT_NOW=810242
CURRENT_NOW=-248413
I didn't notice anything like that with voltage limit.
P.S., see if changing
switchDelay=2
toswitchDelay=5
in/data/adb/modules/acc/misc-functions.sh
(line 379) solves the charging switch issue. Restart accd after the change. One-line:sed -i '/switchDelay=2/s/2/5/' /data/adb/modules/acc/misc-functions.sh; accd
Revert:sed -i '/switchDelay=5/s/5/2/' /data/adb/modules/acc/misc-functions.sh; accd
That didn't work. accd says that switches don't work.
Interesting!
This suggests current works only partially.
Very small values are not honored.
Now, you may rely on voltage control as is - or use voltage control files as charging switches.
Share /dev/.vr25/acc/ch-volt-ctrl-files
.
battery/constant_charge_voltage::v000::4300000
bms/voltage_max::v000::4450000
main/voltage_max::v000::4300000
sm7250_bms/constant_charge_voltage_max::v000::4300000
sm7250_bms/voltage_max::v000::4300000
redfin_volt.txt acc_latest_snapshot.zip
There you go.
Test that list of potential switches - with acc -t /path/to/list (e.g., acc -t /sdcard/Download/redfin_volt.txt
.
Use the latest acc zip attached.
redfin:/ # acc -t /sdcard/redfin_volt.txt
(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...
(!) [battery/constant_charge_voltage 4300000 3300000] won't work
(!) [bms/voltage_max 4450000 3300000] won't work
(!) [main/voltage_max 4300000 3300000] won't work
(!) [sm7250_bms/constant_charge_voltage_max 4300000 3300000] won't work
(!) [sm7250_bms/voltage_max 4300000 3300000] won't work
redfin:/ #
Interestingly enough, it seems to be working now, but as strange as I mentioned before with current (goes up to 800+mA for 5 seconds for about once in 10-15 secs). It might be charging till 4200mV and then stops, then voltage drops to 4130mV and in a few seconds it starts charging again. Current battery level is 78%. Config is default.
Update: In about 10 minutes it charged to 79%.
Interestingly enough, it seems to be working now, but as strange as I mentioned before with current (goes up to 800+mA for 5 seconds for about once in 10-15 secs). It might be charging till 4200mV and then stops, then voltage drops to 4130mV and in a few seconds it starts charging again. Current battery level is 78%. Config is default.
Update: In about 10 minutes it charged to 79%.
That behavior is expected. With a low voltage limit, the battery level will only go so far. You can rely on this for now.
redfin:/ # acc -t /sdcard/redfin_volt.txt (!) Charger must be plugged to continue... (i) Alright, this may take a minute or so... (!) [battery/constant_charge_voltage 4300000 3300000] won't work (!) [bms/voltage_max 4450000 3300000] won't work (!) [main/voltage_max 4300000 3300000] won't work (!) [sm7250_bms/constant_charge_voltage_max 4300000 3300000] won't work (!) [sm7250_bms/voltage_max 4300000 3300000] won't work redfin:/ #
This may be happening because the charging status is inconsistent - i.e., it may be fluctuating. That's not an issue at all. I just have to make acc understand this voltage related logic.
That behavior is expected. With a low voltage limit, the battery level will only go so far. You can rely on this for now.
Well, thanks for the help! This is much better than nothing. But what is the right way to fix the problem with charging to the specified percent? Could this be fixed from your side or only from the kernel side?
Well, thanks for the help! This is much better than nothing. But what is the right way to fix the problem with charging to the specified percent? Could this be fixed from your side or only from the kernel side?
The right way of fixing it is updating the kernel. From my side, I can only provide workarounds. Those may not satisfy all users.
Here's one more thing for you to try:
Upgrade to the latest version and run acc -s s=0 cw=true; accd
Analyze charging control (pause, resume) for some time.
cw
is short for current_workaround
.
After reading a couple of posts on XDA, it became clear that this is a kernel issue. Recent system updates have introduced it on Pixel devices. (Google trying harder to enforce programmed obsolescence?) Some users are suggesting switching to certain custom kernels, e.g., Proton, ElementalX (not the latest), etc..
Before going down that route, I suggest testing pairs of switches, like so:
acc -t dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1
acc -ss:
prints a list of known switches.
If a pair works, set it with acc -s s="file1 on off file2 on off --"
, e.g., acc -s s="dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1 --"
Does ACCA support adding pairs of switches? If so, how would this need to be formatted into the Add Charging Switch prompt?
Does ACCA support adding pairs of switches? If so, how would this need to be formatted into the Add Charging Switch prompt?
file1 on off file2 on off -- e.g., dc/input_suspend 0 1 sm7250_bms/charge_disable 0 1 --
No good I'm afraid. Every combination I've tried, ACC reports back won't work. Looks like if I want to use it, I'll have to go looking for a compatible kernel.
No good I'm afraid. Every combination I've tried, ACC reports back won't work. Looks like if I want to use it, I'll have to go looking for a compatible kernel.
With accd stopped, have you tried writing to each control file manually and waiting in between (few secs) to see if charging stops? Possibly, some switches work at least intermittently. Again, it's a kernel issue, but we're looking for workarounds here. It almost looks like OEMs have been introducing those kernel bugs intentionally.
Hi, this works for me:
echo 1 > /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/charge_disable
It also changes _/sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250bms/status to 'Not charging'
My build is: RQ3A.210805.001.A1
@VR-25 Could you explain please, why we need pair of switches instead of just one?
PS: Probably this can be useful:
redfin:/sys/devices # ls -la /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/
total 0 drwxr-xr-x 4 root root 0 1970-05-21 12:41 . drwxr-xr-x 3 root root 0 1970-05-21 12:41 .. -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_charger_state -rw-r--r-- 1 root root 4096 2021-08-13 17:12 charge_disable -r--r--r-- 1 root root 4096 2021-08-13 17:03 charge_done -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_term_current -r--r--r-- 1 root root 4096 2021-08-13 14:06 charge_type -rw-r--r-- 1 root root 4096 2021-08-13 07:35 constant_charge_current_max -rw-r--r-- 1 root root 4096 2021-08-13 07:35 constant_charge_voltage_max -r--r--r-- 1 root root 4096 2021-08-13 14:06 current_now lrwxrwxrwx 1 root root 0 2021-08-13 16:19 device -> ../../../c440000.qcom,spmi:qcom,pm7250b@2:google,bms -r--r--r-- 1 root root 4096 2021-08-13 14:06 fcc_stepper_enable -r--r--r-- 1 root root 4096 2021-08-13 14:06 health -rw-r--r-- 1 root root 4096 2021-08-13 07:35 input_current_limited -r--r--r-- 1 root root 4096 2021-08-13 14:06 online drwxr-xr-x 2 root root 0 2021-08-13 14:06 power -r--r--r-- 1 root root 4096 2021-08-13 14:06 present -r--r--r-- 1 root root 4096 2021-08-13 14:06 recharge_soc -rw-r--r-- 1 root root 4096 2021-08-13 14:06 rerun_aicl -r--r--r-- 1 root root 4096 2021-08-13 14:06 resistance_id -r--r--r-- 1 root root 4096 2021-08-13 14:06 safety_timer_expired -r--r--r-- 1 root root 4096 2021-08-13 14:06 status lrwxrwxrwx 1 root root 0 2021-08-13 16:19 subsystem -> ../../../../../../../../../class/power_supply -r--r--r-- 1 root root 4096 2021-08-13 14:06 temp -r--r--r-- 1 root root 4096 2021-08-13 14:06 type -rw-r--r-- 1 root root 4096 2021-08-13 14:06 uevent -rw-r--r-- 1 root root 4096 2021-08-13 07:35 voltage_max -r--r--r-- 1 root root 4096 2021-08-13 14:06 voltage_now drwxr-xr-x 2 root root 0 1970-05-21 12:41 wakeup40 redfin:/sys/devices # cat /sys/devices/platform/soc/c440000.qcom,spmi/spmi-0/spmi0-02/c440000.qcom,spmi:qcom,pm7250b@2:google,bms/power_supply/sm7250_bms/uevent
POWER_SUPPLY_NAME=sm7250_bms POWER_SUPPLY_STATUS=Not charging POWER_SUPPLY_RESISTANCE_ID=9971 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_CONSTANT_CHARGE_CURRENT_MAX=0 POWER_SUPPLY_CONSTANT_CHARGE_VOLTAGE_MAX=4390000 POWER_SUPPLY_CHARGE_CHARGER_STATE=16973825 POWER_SUPPLY_CHARGE_TYPE=N/A POWER_SUPPLY_CHARGE_DONE=0 POWER_SUPPLY_CURRENT_NOW=-6103 POWER_SUPPLY_INPUT_CURRENT_LIMITED=0 POWER_SUPPLY_ONLINE=1 POWER_SUPPLY_CHARGE_TERM_CURRENT=-80 POWER_SUPPLY_TEMP=337 POWER_SUPPLY_VOLTAGE_MAX=4390000 POWER_SUPPLY_VOLTAGE_NOW=4287658 POWER_SUPPLY_SAFETY_TIMER_EXPIRED=0 POWER_SUPPLY_FCC_STEPPER_ENABLE=0 POWER_SUPPLY_CHARGE_DISABLE=1 POWER_SUPPLY_RERUN_AICL=0 POWER_SUPPLY_RECHARGE_SOC=97
@gisthere, do sm7250_bms/charge_disable
, sm7250_bms/status
and the like exist in /sys/class/power_supply/
?
Does /sys/class/power_supply/battery/status
also change?
Does acc -t sm7250_bms/charge_disable 0 1
work?
If not, try the full path.
Some devices (e.g., most MediaTek) require two switches - i.e., both have to be toggled for charging to stop/resume. Some OnePlus phones also require two switches to enable idle mode.
@VR-25 thanks for the explanation!
do sm7250_bms/charge_disable, sm7250_bms/status and the like exist in /sys/class/power_supply/?
Yes, they exist as symbolic links.
Does /sys/class/power_supply/battery/status also change?
No
Does acc -t sm7250_bms/charge_disable 0 1 work? If not, try the full path.
Seems, it doesn't work. But I noticed, that running 'acc -t ...' switches sm7250_bms/charge_disable from 1 to 0:
redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
0 redfin:/ # echo 1 > /sys/class/power_supply/sm7250_bms/charge_disable
redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
1 redfin:/ # acc -t sm7250_bms/charge_disable 0 1(!) Charger must be plugged to continue... (i) Alright, this may take a minute or so...
(!) [sm7250_bms/charge_disable 0 1] won't work
redfin:/ # cat /sys/class/power_supply/sm7250_bms/charge_disable
0
The fact that battery/status
does not change, while sm7250_bms/status
does, reinforces the idea that the kernel is flawed.
Anyways, we're getting somewhere.
Have you confirmed that charging actually stops when sm7250_bms/status
is Discharging
or Not charging
?
What does acc -i curr
suggest?
Does sm7250_bms/status
also change after toggling battery/input_suspend
?
I noticed, that running 'acc -t ...' switches sm7250_bms/charge_disable from 1 to 0:
That's because acc -t restores the default value, 0
.
Have you confirmed that charging actually stops when sm7250_bms/status is Discharging or Not charging? What does acc -i curr suggest?
It seems like it really stops, because the phone becomes colder and percentage of the battery indicator (on the status bar) stops rising BUT:
acc -i curr
Battery Service Max charging current: 450000
Uevent CONSTANT_CHARGE_CURRENT=2800000 CURRENT_AVG=4272 CURRENT_NOW=6408 INPUT_CURRENT_LIMITED=0 CURRENT_NOW=6.408 Amps
the value of CURRENT_NOW is strange. When I again put 0 to sm7250_bms/charge_disable, it becomes 0.289917 Amps.
Does sm7250_bms/status also change after toggling battery/input_suspend?
I couldn't find battery/input_suspend, only dc/input_suspend.
The fact that battery/status does not change, while sm7250_bms/status does, reinforces the idea that the kernel is flawed.
Hope, they will fix it in Android 12
Ok, it seems charging does indeed stop. The weird current values are just a unit conversion issue, no big deal (working on that too).
Here's the verdict so far...
The kernel is flawed.
It does not report the correct charging status in /sys/class/power_supply/battery/status
.
While we wait for a kernel update, I'll implement a workaround - _invite sm7250_bms/status
to the party_.
Install and test this build.
Focus primarily on the following commands:
acc -d # disable charging
acc -e; accd # enable charging and start the daemon
acc -i # print battery info
acc -i stat # print charging status
Didn't help:
130|redfin:/ # acc -d (i) Manual mode
(i) Alright, this may take a minute or so... (i) /data/adb/vr25/acc-data/logs/acc-logs-redfin.tar.bz2
130|redfin:/ # cat /sys/class/power_supply/sm7250_bms/status
Charging 130|redfin:/ # acc -i statBattery Service status: 2
Uevent CHARGE_CHARGER_STATE=50397205 STATUS=Charging
Here's another attempt to fixing the broken charging status.
This versions also lets you use voltage control files as charging switches.
That said, acc -ss
has a new preset, 3600.
It limits voltage to 3600 in order to stop charging.
Essentially, whenever disable_charging() is called, voltage is limited to 3600 millivolts.
Keep mind that while limiting voltage may not always change the charging status, it still prevents charging past the set threshold.
That's essentially what I call pseudo idle mode.
The battery works as a power buffer.
This fixed my issue with recent versions not working on pixel5. Thank you VR-25!!
On Pixel 4a it also runs since v2021.8.17 with 3600 preset. Thank you!!
It seems the official kernel fix isn't coming anytime soon. We can't expect Google to care enough about this anyway.
I'm glad major progress has been made!
Yes, the workaround I implemented targets all devices with this issue.
Those who have been relying on a voltage setting may also try acc -t
, since the regular charging switch approach should work as well.
It seems that it stopped working again after September update.
I tested these versions, but they don't appear to work. ACC stops working while in the background. It could find a working charging switch, but for some reason still stops working:
# acc -t
(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...
(!) [/sys/devices/platform/soc/soc:google,charger/charge_disable 0 1] won't work
(!) [dc/input_suspend 0 1] won't work
(i) [sm7250_bms/charge_disable 0 1] works
- battIdleMode=true
https://github.com/VR-25/acc/files/7147378/acc_v2021.9.11_.202109110.zip
This build has a rollback feature.
To undo an upgrade, simply run acc -b
.
If it stops working while in the background, share the output of acc -l tail
after the occurrence, before restarting the daemon.
This is what I get after acc exists
89: cycle_switches off
60: typeset 'on='
61: typeset 'off='
61: </dev/.vr25/acc/ch-switches
63: read -A chargingSwitch
/data/adb/vr25/acc/accd.sh[549]: chargingSwitch[0]: parameter not set
65: exxit
89: exitCode=1
90: false
90: set +eux
Is this really today's build?
Anyway, you can bypass this error by manually setting the working switch with acc -ss
.
Probably I did not restart the daemon before giving you the logs. Now it should be right:
251: off=1
252: chmod 0644 /sys/devices/platform/soc/soc:google,charger/charge_disable
252: >/sys/devices/platform/soc/soc:google,charger/charge_disable
252: eval echo '$off'
252: echo 1
252: return 1
252: exxit
89: exitCode=1
90: false
90: set +eux
Anyway, you can bypass this error by manually setting the working switch with acc -ss.
I'll try this, thank you.
UPD: Seems like it's working. Thanks!
I'm guessing it's probably a kernel issue - but either way, here the logs to help troubleshoot.
Module flashes fine in the latest canary version of Magisk, but doesn't seem to actually do anything regardless of configuration (and charging switch) used.
acc-logs-redfin.tar.bz2.zip