yashsingh1/xdaforums huggingface dataset:
[Magisk] Unspec:
If I wanted to maintain the bypass mode due to not wanting to constantly switch switches, I should probably just keep the battery at 70% right? Don't know too much about battery voltages, but battery university states that 4.10V is considered high voltage, so 70% should be slightly under that limit. Correct me if I'm wrong.

My thoughts exactly. I'll keep testing and see if I can figure out why it's doing it or at the least what conditions cause it.
[Magisk] MatteCarra:
A new update of Acc app is available!

This version is compatible with latest Acc build.

What's new:

VR25 and I have worked on this update for a long time.

We have added many new options and we have made significantly easier to use ACC.

This version includes a simple icon, schedules, editing and testing charging switches, editing voltage control file and many more!

Hope you like it.

Download: https://github.com/MatteCarra/AccA/releases/download/1.0.0/app-release.apk
[Magisk] VR25:
Yes, you're right. 70 is a good number.

You can test whether your kernel supports custom charging voltage, and greatly benefit from that. You don't have to care about limiting capacity if you can limit the voltage.

acc -v :3920 shows you a list of available voltage_max control files and lets you easily test each. 3920 is just an example. The accepted voltage range is 3920-4199 (mV).

You can use acc app for that too, and it's a hell lot simpler!
[Magisk] danicadanicadanica:
What does this mean ? All is working except when editing voltage it force closes im using samsung galaxy j6 with custom kernel..
[Magisk] VR25:
Which voltage control file are you testing? The screenshots show none.

Make sure /sdcard/acc/logs/acc-power_supply-*.log exists and it isn't just a few bytes in size. If one of these conditions is false, reinstall acc to regenerate that file. It may take up to ~2 minutes.
[Magisk] danicadanicadanica:
It seems the app is bugged because it shows the control file in the combobox but if i choose it and enable voltage ctrl it stopped. Will test voltage ctrl using terminal later.
[Magisk] MatteCarra:
Thanks for the report.
[Magisk] slimshouki:
After setting max voltage in terminal and choosing correct control files, current is very low so its charging very slow as shown in screenshot

Additionally after reboot max voltage is disabled again
[Magisk] danicadanicadanica:
This also happened to me when i tried to switch charging control i managed to fix mine by stopping accd and rebooting it. Once rebooted, u must restart accd and it will now go stable.
[Magisk] slimshouki:
Everyrhing.is messed up when it comes.to defining max voltage

I have two.control files that accept setting max voltage to 3920

1st one makes +ve current which means its discharging not charging and is very low current and after removing charger appear still connected with LED on and cannot be fixed unless a reboot

2nd one reset to 4.4V automatically once I connected the charger or restarted acc

Both of them vanishes and max voltage is reset to default after a reboot
[Magisk] squabbi:
[MENTION=9731715]MatteCarra[/MENTION]

I remember a few posts ago you were looking for some UI/UX additions, I thought I might practice some Kotlin as well.

Are you still looking for some contributions in that regard?

Screenshot below, GirHub here: https://github.com/squabbi/ACCM
[Magisk] MatteCarra:
Nice work!

You can send pull requests , but I recommend to fork my project and work on it.

I will check your work soon .

I like the dashboard a lot.

Thanks
[Magisk] Unspec:
Not sure if voltage control is not supported, or if I'm doing something wrong. I'll set the voltage to 4100mV, and when I plug my phone in, it just sets the max voltage to whatever the highest spike in charging voltage has been it seems. So often times I'll check and the max voltage is at 4350. Every time I look in the AccA app, voltage control will be enabled again, regardless of how many times I disable it.

A side note. From a user friendliness pov setting the voltage max to millivolt and then reporting it back as microvolts is pretty confusing. When I use acc -v - it reports it in microvolts, but users use milivolt to set the limit. Feel like things should remain consistent.

Edit:

Since the latest version, it appears to be respecting charge limits again. Though if I set it high (like 90-95) it still seems to be ignoring it. Currently set it to 70-75, and its still doing the thing where it stops at 76%.
[Magisk] Camerado:
[MENTION=5228676]VR25[/MENTION] expect in a new release?
[Magisk] Unspec:
You could easily accomplish this with a Tasker task.

I also don't know how this feature would be useful at all, but you do you man.
[Magisk] VR25:
You should read more about how lithium ion batteries are charged.

https://batteryuniversity.com/learn/article/charging_lithium_ion_batteries

Short Summary

When you limit the charging voltage, you're limiting capacity too.

Once the peak voltage is reached (faster with higher current), the current starts to drop. Thus, charging gradually slows down. When the current drops down to zero or very close, battery is considered fully charged relative to the set charging voltage).

Switching gears, if you want persistent voltage limit, use onBoot=file:voltage.
[Magisk] VR25:
Read the previous post.

Which device is that?

Keep in mind that not all kernels support custom charging voltage.

A Few Questions

- Why 3920?

- What was the battery capacity when you set that voltage?
[Magisk] VR25:
Have you tested this with acc -v :millivolts? Perhaps you're not using the right (or a working) voltage control file?

Worst case scenario: your kernel doesn't support custom charging voltage.

As you wish...

Meanwhile, you only have to look at the first four digits (mV) - no conversion needed.

Seems like another device specific issue... ?
[Magisk] slimshouki:
Poco f1 havoc 2.2 rom with franko r20 kernel

I choosed 3920 because its mentioned any number within safe threshold 3920 to 4199

Capacity was 76%

---------- Post added at 08:04 PM ---------- Previous post was at 08:02 PM ----------

Ok will do it

But I have to resolve max voltage first
[Magisk] VR25:
Oh, I forgot that!

The next version will have it.
[Magisk] VR25:
I didn't realize both posts were yours! :p

Anyway, 3920mV is way below what 76% capacity represents. That's why the charging current was too low.
[Magisk] Unspec:
I used acc -v 4100. I went through every single control file presented to me in the app. Using AccA to do the voltage control testing. Either the app gave me a toast saying the file doesn't work, or no toast but it automatically shows "?attery..." again when I click "Edit Config". Pretty sure my kernal just doesn't support it. ElementalX is what I use.

Yup, personally I understand it all pretty well and don't have trouble reading it. Just viewing it from a clarity pov, its not very intuitive for a user to set a limit with mV and then be given uV for everything else.

It's also created an issue in AccA where voltage limit is being reported incorrectly. Already submitted the bug to AccA's github.

Likely. Hopefully the next security update doesn't break anything.

Edit: Also, just to be sure. If I update a setting (e.g. update pause-resume values), do I need to restart the daemon for it to take effect? I'm assuming yes.
[Magisk] slimshouki:
So what do you recommend?

I mean by low that it charges 1% every 30 mins so I dont think its convenient.

I though by limiting voltage to be max 4199 in order to preserve battery life span will negatively reflect charging current by a little value.ie: if voltage limited from 4400 to 4199 current should be reduced by same %.
[Magisk] VR25:
Thanks for all the reports and suggestions!

Restarting the daemon is only necessary when you want $onBoot to be reapplied.

Everything else takes effect within ~$loopDelay seconds -- without a restart.
[Magisk] nogaff:
So, on my Pixel 2, acc defaulted to input_suspend which meant that during cooldown cycles the screen kept waking and sleeping, over and over. That was a little distracting and I assumed it might not be good for the screen, so I switched acc to charge_disable which solved the problem, but you say that's actually worse for the battery. Do you think the effects on the battery are significant enough that we should avoid charge_disable if possible?

I mean, having read your comment, I'm kinda wondering which is the "lesser evil":

input_suspend + cooldown enabled: continual screen waking, so possible wear on the screen?

input_suspend + cooldown disabled: battery stress from heat during charging?

charge_disable: battery stress when charging gets paused at higher voltages?

Or are all these effects neglible enough that it's not really worth worrying about?
[Magisk] Unspec:
If you were to choose the lesser of two evils, charge_disable is still better. Given all the Pixel 2 screen burn in issues, it's better to mistreat a $25 battery than a $230 screen, according to iFixit part prices.

Personal opinion below:

My suggestion is to limit charge to 70% if you're just going about your normal everyday life, and keep it on charge_disable. The unhealthy part is if you keep the battery in a prolonged high-voltage state, which is 4.10V and above according to battery university. This is due to bypass no longer using the actual battery, so the battery just sits charged at 4.10V+ and ends up harming itself. But if you charge it to 4V (Disclaimer: In theory. This is from my understanding of what I've read) and then enter bypass mode, it should be fine.

If you're out traveling, just disable acc (or disable resume-pause). A little bit of battery wear is better than having a dead phone because it only charged to 70% and you don't know where the next outlet is.

All of these battery/screen effects are pretty negligible if you're someone who replaces their phone every 2-3 years tbh. Good battery practices are of course good to have, but being really strict about it is really meant for people who don't regularly get new phones.
[Magisk] VR25:
I'd set daily schedules for this. That's what acc -v was originally intended for.

djs daily 05 00 "acc -v 4050" -- around wake-up time

djs daily 23 00 "acc -v 3920" -- around sleep time

Of course, you can do that in the app too. It runs those commands for you.

djs (Daily Job Scheduler) is a standalone Magisk module, and it ships with acc.
[Magisk] VR25:
Superb response! ??
[Magisk] slimshouki:
Ok figured out why limiting voltage wasnt going well with me.

It appeared to be kernel issue as you mentioned before. Once I reverted back to stock kernel, limiting voltage is working normally now.

its now confirmed that franko r20 doesn't support custom voltage tuning.

What makes me going mad now that when I set voltage file path:4050 on boot script as shown in attached photo, it never survives after boot and voltage limit got disabled again.

I tried even "exit on boot", acc stops and never back on even after restarting daemon or rebooting device unless I turn off this option.
[Magisk] VR25:
Don't enable onBootExit, unless you don't need any other feature, besides voltage limiting.

Keep in mind that onBoot values must be in raw format. You have to use the default voltage unit. Have you checked whether yours is microvolt (7 digits) or millivolt (4 digits)?

Tips

You can always remove the "*power_supply/" part.

"battery/voltage_max" works fine.

Wildcards are supported.
[Magisk] slimshouki:
Ok but I am confused now so is the default raw format to use in "onBoot" is the microvolt or millivolt?

Something weird is happening

It was working fine below 70% capacity but as soon as I reached capacity 70% current is limited from +50 to -50 which means its switching between charging and discharging by itself so after 5 hrs from charging capacity is fixed on 72% although my setting to upper threshold is 85%.
[Magisk] ovizii:
I tried using this module to get my phone to stop charging when the battery reaches 80% but I ended up having to disable it.

I have a Samsung S7 running lineageos 15.1 so after installing this module, enabling it and rebooting I installed the acc app, had a look at the default settings, did not change anything but simply saved them to make sure they were applied and tried charging with a couple of different chargers with the same result: the charging would simply not go over 600mA anymore.

Amy hints on what to do to get this working as "advertised" ?
[Magisk] VR25:
You're missing what impact limiting voltage has on battery capacity. Charging voltage and battery capacity go hand-in-hand. If the voltage you set is not enough to reach 85% capacity, you'll never get there. You have to play around to figure out how many millivolts can get you up to 85% capacity.

Current fluctuating between -50 and 50mAh is normal.

To know which unit you should use with onBoot, run acc -i and see how many digits voltage_max has.
[Magisk] VR25:
See whether disabling coolDown (acc -s coolDown) helps.
[Magisk] slimshouki:
Ok

Will try and let you know

I need to know what is the value of steps range to play around. i.e: do I try 1st 4199 then 4198 and so on or 4199 then 4150 or 4199 then 4100 and so on.

Thank you.for your patience
[Magisk] ovizii:
Thanks, I will try as now that you mention that feature I'm not 100% sure I was below the cooldown battery capacity and the cooldown temperature.

Will reply after testing
[Magisk] slimshouki:
Regarding "onBoot" script

I figured out that voltage should be written in 7 digits as acc -i shows and I wrote the correct path along required max voltage as per attached screenshot but still cannot survive boot!!
[Magisk] VR25:
The next update won't depend on onBoot for this, and the unit will always be millivolt.

Perhaps your setting is reset once the external power supply is reconnected...? ?

What's the output of acc -s?

Try acc -s onPlugged file:voltage

Edit: [MENTION=4991063]slimshouki[/MENTION], disregard the above! I found a bug. In order to bypass it, use onBoot=battery/voltage_max:4190000.
[Magisk] slimshouki:
Not surviving boot

Max voltage Resets to default just after reboot before connecting an charger as you can see from screenshot max voltage is disabled
[Magisk] VR25:
The change is not reflected there, since it was applied differently. The next update will kill this mess.

Check the file itself (/sys/class/power_supply/battery/voltage_max).

Also, the app and acc -i should show you a value no higher than the set voltage.

4050mV may get you right up to 85% or very close. Increase or decrease by 50mV, as needed.
[Magisk] slimshouki:
Ok

Now its obvious as you say, its not reflected there but its already applied since values are below my set values.

Gr8 work

Waiting for your next update
[Magisk] Unspec:
How accurate is the acc -i "capacity" field? The UI for the phone reports 70%, but acc -i reports capacity at 69. Could this be why it appeared that my phone was charging past resume-pause limits?
[Magisk] VR25:
Yes, that may be the reason.

acc -i is as accurate as it can be. The information it shows comes straight from the source -- the battery management system.

Android itself can be inaccurate due to significant BMS checking delays (perhaps caused by power saving features), or something else.
[Magisk] shouk_1987:
[MENTION=5228676]VR25[/MENTION]

I donot have any control file to show when I type acc -v :4195 in terminal

While acc -v 4195 gives a result by setting max voltage to 4195

What is the difference between both commands and why it does not show control files ?

I have the device and setup as [MENTION=4991063]slimshouki[/MENTION] except different ROM
[Magisk] VR25:
/sdcard/acc/logs/acc-power_supply-*.log may be missing or incomplete. Reinstall acc (no reboot needed) to generate that file. It takes about a minute.
[Magisk] ovizii:
Problem solved, thanks
[Magisk] danicadanicadanica:
What if i dont have voltage_max ?
[Magisk] shouk_1987:
Yes now it found tthe files

Now what is the difference between applying global max voltage acc -v 4195 and applying it on a specific control file acc -v :4195
[Magisk] mia.backkind:
The deamon wont run, i guess my device is unsupported. I uploaded my powerlog into your dropbox. Would be great to get the benefits from this module. I hope my log helps out :)

Great work!:svetius:
[Magisk] Evengard:
On my Asus Max Pro M1 I've got a weird problem. During charging it randomly disconnects/reconnects the charging even though no thresholds were reached. Is there any way to avoid this?
[Magisk] wilsonhlacerda:
Probably is the battery temperature. If you really want, disable the acc "temperature check" feature (or "cool down"?) or change its limits.
[Magisk] VR25:
You may have a voltage_max file somewhere else. Run "acc -v :" to see if that's true. Also, check /sdcard/acc/logs/acc-power_supply-*.log -- if it's empty or you don't see your device's name at the end of the file, reinstall acc to regenerate it (no reboot needed). You won't have to do that again. Future releases will handle this better.
[Magisk] VR25:
The first command uses the already set charging voltage control file. The second lets you set one.
[Magisk] VR25:
I'll check it.

Thanks

Edit

[MENTION=9728428]mia.backkind[/MENTION], while charging, run

su

chmod +rw /sys/devices/platform/battery/ChargerStatus

cat /sys/devices/platform/battery/ChargerStatus

What's the output?
[Magisk] VR25:
acc -s coolDown

You didn't read the documentation, did you?
[Magisk] svbarbosa:
Hello [MENTION=5228676]VR25[/MENTION],

My device is a Xiaomi Mi Max 3 (nitrogen),

acc detects three possible switches, but none of them work.

The first detected switch, the usual "./battery/input_suspend", turns the charging off for a brief while.

Is there any way I can force this switch to work or find more switches?

The following is the output of "acc -s" and "acc -s s" and attached is my acc-power_supply-nitrogen.log.

:/ $ su

:/ # acc -s

capacity=5,101,70-80

coolDown=50/10

temp=900-950_90

verbose=false

resetUnplugged=false

loopDelay=10

maxLogSize=5

switch=

onBoot=

onBootExit=false

onPlugged=

voltFile=./?attery/voltage_max

selfUpgrade=true

:/ # acc -s s

(i) Available charging switches

- Choose one and press <enter> to set it

1) ./battery/input_suspend 0 1

2) ./parallel/charging_enabled 1 0

3) ./parallel/input_suspend 0 1

4) exit

#? 4

:/ #
[Magisk] Evengard:
That is kind of weird as the battery temperature wasn't that high (around 40 degrees celcius at the time it happened), and it happened from time to time, not all the time (one night it would charge without this behaviour, another one it happened the whole night). Still, thanks for the tip, trying it out.
[Magisk] mia.backkind:
[MENTION=5228676]VR25[/MENTION]

looks like there is no output. i checked the file with ghostcommander while charging too - anyway no input in the file (like the command "cat" should show the input of the file right?)

btw: is the filestructure based on the ROM or hardware? maybe in future i will flash mookee 7.1 on my phone but dont know if i will bring up the mess
[Magisk] guest4711:
The structure is based on the kernel in use (so in most cases on the ROM in use).
[Magisk] VR25:
**2019.3.3-r1 (201903031)**

- `acc -f|--force|--full <capacity>`: charge to a given capacity (fallback: 100) once and uninterrupted.

- `acc -s s` has an "auto" option (unsets switch).

- `acc -v $@` commands accept and output voltage values in millivolts only. Outputs include the unit (e.g., 4050mV).

- `acc -v file:millivolts` saves settings to config if <file> works.

- Additional devices support

- Custom charging voltage limit is automatically set on boot (without `onBoot=file:voltage`).

- Daemon exit text

- General fixes and optimizations

- Faster power supply log generator - users no longer have wait for it.

- `rebootOnPause= # After set seconds (disabled if null).`

- The output of `acc -v :` is cleaner.

- Updated documentation and debugging tools

Notes

- acc updates itself ~10 minutes after accd is started/restarted. The update zip weights less than 60 kilobytes.

- A new acc app release will soon be available.

Unsupported device?

Test whether one of the following switches can control charging:

# experimental (may cause lag)

./bms/temp_cold 0 500

./bms/temp_hot 500 0

./battery/system_temp_level 0 9

Use acc -t <switch> (e.g., acc --test ./bms/temp_cold 0 500).

EDIT

More switches:

./battery/charge_done 0 1

./dc/power/control auto disabled (or off)

./bms/power/control auto disabled (or off)

./battery/power/control auto disabled (or off)

EDIT 2

Check whether one of the following commands disables charging notifications:

echo disabled > /sys/class/power_supply/dc/power/wakeup

echo disabled > /sys/class/power_supply/bms/power/wakeup
[Magisk] slimshouki:
Powerful module, amazing update, app update is gd as well. [MENTION=5228676]VR25[/MENTION] I cant find the words to describe your module perfection.

Everything working as it suppposed to be without any complications
[Magisk] shouk_1987:
I echo slimshouki for his post

You are really amazing [MENTION=5228676]VR25[/MENTION]
[Magisk] Lanzer0:
i cant install the new update, what i will do?

sorry for my english
[Magisk] afr33sl4ve:
So, I've had some interesting results.

When I was using MCS, my battery was charging fine. When I updated to ACC, my battery is discharging at a faster rate while plugged in.

Any thoughts?
[Magisk] MatteCarra:
Press Save log and attach it to xda
[Magisk] jessie maarat:
Hi admin please me fix this, cant apply the auto shutdown,

Im on havoc os 2.2, pocophone f1.
[Magisk] VR25:
Everyone, thanks for the feedback! :)

What's your Magisk version, device, ROM...?

Without logs and specific details, we can't help you.

This has been a hot topic for a while.

Run "acc -s s" to enforce a particular charging switch (go from bottom to top). Test it. If the issue persists, try the next. Repeat as needed.

am start -n android/com.android.internal.app.ShutdownActivity

Does that command shutdown your system?
[Magisk] jessie maarat:
Hi admin, heres the full log of the acc,

Cant get the auto shutdown to work.

Also the cooldown function keeps applying even if the setting for cooldown is not reach yet.. i think the logs dont have the record for it cause i disable it for the moment.

Pocophone f1, beryllium
[Magisk] jessie maarat:
No sir., It gives an error.
[Magisk] VR25:
Recall that coolDown is triggered by at least one of the following conditions:

- Battery temperature >= 40°C (default)

- Battery capacity >= 60% (default)

Thanks for the extra information. Auto-shutdown has been fixed.
[Magisk] jessie maarat:
Thank you, can i have a copy of the fixed autoshutdown build for me to try?
[Magisk] VR25:
That build is still under testing.

You can fix the auto-shutdown issue right now by running...

sed -i 's|am start -n android/com.android.internal.app.ShutdownActivity|reboot -p|' /sbin/.magisk/img/acc/accd

Simply paste that on terminal press <enter> (no system reboot needed).

P.S., restart accd afterwards (acc -D restart).
[Magisk] jessie maarat:
Thank you very much dev/admin, it is fixed now and also thank you for explaining the cooldown. It is perfect now.

More power.
[Magisk] Camerado:
[MENTION=5228676]VR25[/MENTION]

rebootOnPause=30 # After set seconds (disabled if null).

Does not work. I put on charging for the night and in the morning after reboot the system should ask for unlocking with a fingerprint, but this does not happen. So there was no reboot.
[Magisk] VR25:
I'm aware of that (same issue as the one above). This has already been fixed in the current (unreleased) build.

Test that feature again after running...

sed -i 's|am.*OT|reboot|' /sbin/.magisk/img/acc/accd && acc -D restart
[Magisk] Camerado:
Termux log
[Magisk] HorrorLemons:
Facing the same issue. I can't update to the latest version. On Magisk 18.1, Oreo 8.1. I've attached the install log.

EDIT: Uninstalled and reinstalled.
[Magisk] VR25:
The next release is around the corner.

Did the reinstallation work?

If you're on Telegram, PM me, so I can send you test builds.
[Magisk] HorrorLemons:
Yeah! Sorry I didn't mention previously, but reinstalling worked. I don't have Telegram... Maybe I should...