Related
Hi,
I wonder if we could have advanced battery charging management on Android in order to minimize wear. The basic idea is to avoid micro-cycles, i.e. don't start charging every time the power supply is plugged in. I find myself plugging in my Nexus several times a day, so I get several charge cycles every day. Instead, the Nexus should draw its power over USB, but not start charging.
The thinkpad_smapi module implements this for IBM/Lenovo laptops. There are two thresholds, start_charge_thresh and stop_charge_thresh. Setting the start threshold to e.g. 40 will not start charging unless the remaining capacity is below 40 %, and stop_charge_thresh will probably (I don't use it) stop charging early. I use a start threshold of 25 % on my Thinkpad, so I always have at least around 1 hour left, which is enough for me. I understand if people want a full battery all the time and rather buy a new battery every now and then. However, my first Thinkpad battery died after 1.5 years (~500 cycles). The second battery is 2 years old and still charges to 77 % of the original capacity (50 Wh of 64 Wh), so this simple measure has a significant effect.
There's a lot to know about LiPo/LiIon-batteries, way more than I know, but the bottom line is that keeping the battery between 40 % and 95 % minimizes chemical wear.
Maybe someone came across battery-related stuff while digging through the kernel sources and can comment on this. Charging is probably not handled in the kernel, but in the radio or by a dedicated circuit, but maybe there's an interface exposed to the kernel that can be used to set those threshold values. That's how it's done on Thinkpads.
Some changes to how charge management (which is done in the kernel in the ds2784_battery driver) is handled in full and near-full situations are under way. Look for them in the .32-test1 kernel sources in the near future. We're not planning on being quite as aggressive as you propose (wait until 40% to begin charging, etc), but reducing discharge/recharge cycling once the battery is full is planned.
swetland said:
Some changes to how charge management (which is done in the kernel in the ds2784_battery driver) is handled in full and near-full situations are under way. Look for them in the .32-test1 kernel sources in the near future. We're not planning on being quite as aggressive as you propose (wait until 40% to begin charging, etc), but reducing discharge/recharge cycling once the battery is full is planned.
Click to expand...
Click to collapse
i found some unusual battery behavior on the nexus one. i'll charge to 100% when on. then ill delete the batterystats.bin and power off. when off, the light is still orange. takes about a full 5 minutes later then turns green. when i do this and power on, with heavy usage it stays on 100% for 15-35 min, then slowly drops. but without doing this, it just slowly drops from 100%.
100% is not quite the same as fully charged (yes this is a little confusing). If you yank power immediately upon hitting 100% you will typically have a less full battery than if you let it sit until it stops charging. The "power off charge mode" doesn't indicate 100% with the green light -- it indicates "charge complete".
The battery log at /d/battery_log gives a bit more detail as to what's going on (as well as the chatter from the battery driver in the dmesg log).
swetland said:
100% is not quite the same as fully charged (yes this is a little confusing). If you yank power immediately upon hitting 100% you will typically have a less full battery than if you let it sit until it stops charging. The "power off charge mode" doesn't indicate 100% with the green light -- it indicates "charge complete".
The battery log at /d/battery_log gives a bit more detail as to what's going on (as well as the chatter from the battery driver in the dmesg log).
Click to expand...
Click to collapse
thanks for the response! i learned something new today
I've used the Battery University to guide me on Li-Ion batteries:
http://www.batteryuniversity.com/parttwo-34.htm
http://www.batteryuniversity.com/partone-12.htm
(scroll down on either page to see some guidelines).
The first page says that multiple partial recharges are healthier for the battery than fewer deeper discharge/recharges due to less heat buildup. Personally I have never fretted about just plugging in my Macbooks or phones whenever I wanted and the batteries have all lasted quite well.
I also use a slightly weaker charger for my G1 and N1 than the supplied chargers (500 to 700mA Blackberry chargers) and they don't get as hot when I charge them, yet charge to full capacity quickly enough for my needs. The second page recommends a 0.5C charge current (1C == 1400mAmps, 0.5C == 700mAmps) for better life.
I've been playing w the 32 test kernel and looks like this commit has implemented the battery management.
I've now noticed that if the battery level is higher than 90%, plugging in the charger will not charge the phone. Once the battery drops below 90, the battery will start getting charged.
http://r.android.com/#change,13342
is this .32 kernel going to be released as an OTA soon? or is it still in dev stages?
*push*
1.8 years later...
Is it finally implemented in Gingerbread? Are there any mods that provide a frontend to that settings?
I'm really frustrated because i really used to love the n7 so much I was an early adopter and bought another one after I dropped my first and then went on to buy my girlfriend one. But after being plagued with this issue and stuck on 4.1 its just not the same anymore since I cant flash custom roms all day :/
I've been having a charging issue with android 4.2.1 since it came out (both stock and all the roms I tried) but I noticed that whenever I reverted to 4.1.2 the issue went away completely. So I've been waiting for 4.2.2 to come out for a while now to see if it fixed the issue and after flashing the update tonight it seems to have the same problem.
I've tried searching for months now and haven't found any answers.
So this is the issue with both 4.2.1 and 4.2.2:
The battery charges at an insanely slow pace to the point that it ruins the tablet completely. I'll plug it in over night for 8+ hours and it will not gain more then 40% battery life in that time.
Its to the point that when I was just using it right now on the charger with brightness turned all the way down and nothing on other then sync and WiFi that light web browsing for 10 mins caused it to discharge a percent after being plugged in for 19 minutes.
Notes:
Its a c70 16gb
I tried 3 different stock N7 chargers with stock cables as well as trying them with other cables.
I'm not plugged into any kind of extension cords and I've tried multiple wall sockets at different locations.
My girlfriends nexus 7 32g charges fine on 4.2.1 and I have not updated her to 4.2.2 to test yet.
I haven't checked the battery connection because like I said whenever I revert to stock 4.1.2 or any 4.1.2 rom it charges in 4 hours flat or 6 hours with heavy usage while charging.
So anyone have any ideas? If not I guess I have to rma.
Do both, yours and your girlfriend's devices take that long to charge?
sl4y3r88 said:
Do both, yours and your girlfriend's devices take that long to charge?
Click to expand...
Click to collapse
Nope her nexus 7 charges fine. ( a little slower on 4.2 then 4.1 but nothing like mine)
Her nexus does have issues with turning on sometimes on 4.2.1 like a lot of other users but its nothing holding the power button for 10 seconds doesn't fix.
It also just noticed it seems to discharge at an extremely fast pace. (still on 4.2.2)
It just dropped from 55% to 51% in the time I've typed these responses with brightness all the way down.
So anyone want to try and help me figure this out before I send it in friday? I called it in to Google play device support to try and report the software bug and they said its the first they heard of it and they would pass it on but I felt like the rep didnt want to help as I bought it from a third party. I'm willing to do any tests suggested and hop between software versions to try and figure out this bug.
Why do you think it is a "software bug" when millions of people running the "same software" don't experience the same behavior?
I realize that software can exhibit data-dependent behaviors, and thus exhibit low occurrence rates... but there is no "software" involved in charging the battery.
Do you think a booted Linux kernel is needed to charge a battery? How would the battery get charged when the device is turned off in that case? C'mon!
Send it back and tell them the battery (or charge contoller CIRCUIT) is defective.
If it's out of warranty, PAY them to replace it.
bftb0 said:
Why do you think it is a "software bug" when millions of people running the "same software" don't experience the same behavior?
I realize that software can exhibit data-dependent behaviors, and thus exhibit low occurrence rates... but there is no "software" involved in charging the battery.
Do you think a booted Linux kernel is needed to charge a battery? How would the battery get charged when the device is turned off in that case? C'mon!
Send it back and tell them the battery (or charge contoller CIRCUIT) is defective.
If it's out of warranty, PAY them to replace it.
Click to expand...
Click to collapse
Then how do you explain that if right now I flash back to 4.1.2 it will work fine? If you want I'll provide screenshots.
I just flashed back to 4.1.2 this morning and it worked perfectly. Just now I flashed codefires 4.2.2 build and the problems back.
Please explain how that is hardware related.
I may of jumped the gun assuming it was a charging issue. It seems like it might be a battery drain issue. Here's a couple screenshots from a fresh install of codefirex 4.2.2 build.
Sent from my Nexus 7 using XDA Premium HD app
All I was trying to say is that when the OS is booted, at most all it does is monitor battery voltage and current - it doesn't get actively involved in control of charging circuitry.
At most this historical data can be used to *predict* when the battery will run out of juice, and this number is what is shown to the user as a % charge number. Hopefully that allows the prediction to be sort of correct as the battery ages and it's characteristics change.
This "calibration data" is only used for prediction - it does absolutely nothing to alter the rate at which current is drawn from the battery by the motherboard, nor for attempting to alter the behavior of a battery charge controller.
Li-Ion and Li-Polymer batteries are indeed complicated enough that they should not be charged by extremely simple circuits if a long operating lifetime is desired. For this purpose though, monolithic battery charge controllers chips are used - they do not need any assistance of a micro-controller or advanced CPU running a modern OS. That's why they are able to charge batteries rapidly and appropriately when the motherboard is in a "powered down" state.
Relative to a big multi-core CPU chip, which might have hundreds of millions of transistors, battery charge controllers are extremely small circuits - they are sold by the billions and cost in the ballpark of one to several pennies. They don't need the support of a CPU or even a microcontroller to operate correctly.
Good luck with your tab; I hope you enjoy it.
bftb0 said:
All I was trying to say is that when the OS is booted, at most all it does is monitor battery voltage and current - it doesn't get actively involved in control of charging circuitry.
At most this historical data can be used to *predict* when the battery will run out of juice, and this number is what is shown to the user as a % charge number. Hopefully that allows the prediction to be sort of correct as the battery ages and it's characteristics change.
This "calibration data" is only used for prediction - it does absolutely nothing to alter the rate at which current is drawn from the battery by the motherboard, nor for attempting to alter the behavior of a battery charge controller.
Li-Ion and Li-Polymer batteries are indeed complicated enough that they should not be charged by extremely simple circuits if a long operating lifetime is desired. For this purpose though, monolithic battery charge controllers chips are used - they do not need any assistance of a micro-controller or advanced CPU running a modern OS. That's why they are able to charge batteries rapidly and appropriately when the motherboard is in a "powered down" state.
Relative to a big multi-core CPU chip, which might have hundreds of millions of transistors, battery charge controllers are extremely small circuits - they are sold by the billions and cost in the ballpark of one to several pennies. They don't need the support of a CPU or even a microcontroller to operate correctly.
Good luck with your tab; I hope you enjoy it.
Click to expand...
Click to collapse
Thank you for taking the time to write out this detailed explanation. I read it over a couple times and that all makes a lot of sense and now I have a little better understanding of how things work charging wise.
But I still can't wrap my head around how the problem DISAPPEARS COMPLETELY on any 4.1 based build...
I'm not trying to contradict you in anyway it seems like you are way more knowledgeable then me on the subject.
It just doesn't make any sense and I was hoping you could make more of it for me.
Maybe it isn't the charging but a battery drain issue something on 4.2 based builds is draining more current then the charger can dish out.
But while i was doing research I read that chargers up the current they dish out if the device is in use. Is that correct?
I've looked into the media server bug but as I just did a fresh install of stock 4.2.1 and haven't changed or added anything to the file structure that wasn't included in the factory image, I also went through and turned off the keyboard press sound and all other sounds like explained in some of the threads I have read. I also read that the problem is supposed to be fixed in 4.2.2. I also haven't installed any apps from the market.
I guess all I'm looking for is the answer to this question:
Could there really be a hardware related problem of any sort (not just charging and battery problems but anything) that causes problems with 4.2 based builds specifically but doesn't cause problems with 4.1?
If the answer is yes then I don't have to feel bad about sending it in but if its software based issues I'll be upset that I wasn't able to fix it and gave up.
Have you let the battery drain all the way or do you just plug it in at a certain point? if not let it get to the point were it will turn itself off. if the battery with the cross in it stays for more than it would take for 1% to drain then it just might be your battery stats file. even if its not let it drain and then charge it while its off. you can check the battery by pushing the power button quick. i know i have had this problem with other devices that were fixed by doing this. and my N7 did it last night were i updated and plugged it in, it was at 60% and when i woke up it was at 46%.
projectzro said:
Have you let the battery drain all the way or do you just plug it in at a certain point? if not let it get to the point were it will turn itself off. if the battery with the cross in it stays for more than it would take for 1% to drain then it just might be your battery stats file. even if its not let it drain and then charge it while its off. you can check the battery by pushing the power button quick. i know i have had this problem with other devices that were fixed by doing this. and my N7 did it last night were i updated and plugged it in, it was at 60% and when i woke up it was at 46%.
Click to expand...
Click to collapse
I'll give this a try right now then post results, the battery is already pretty low so It shouldn't take very long. Thanks for the response.
projectzro said:
Have you let the battery drain all the way or do you just plug it in at a certain point? if not let it get to the point were it will turn itself off. if the battery with the cross in it stays for more than it would take for 1% to drain then it just might be your battery stats file. even if its not let it drain and then charge it while its off. you can check the battery by pushing the power button quick. i know i have had this problem with other devices that were fixed by doing this. and my N7 did it last night were i updated and plugged it in, it was at 60% and when i woke up it was at 46%.
Click to expand...
Click to collapse
So I let it run dry and am getting some weird behavior...
The dead battery symbol did not pop at all. It actually booted played the low battery sound half way through the nexus logo loaded into the OS and immediately was greeted by the battery to low logo powering down message and then it returned off. It did this cycle all the way through three times in a row before holding the power button did nothing. I let it sit for a minute before trying again and I got another boot out of it all the way to the OS again. But I've yet to be greeted by the battery with the cross symbol. Holding the power button will do the cycle described above or do nothing at all.
krisserapin said:
But while i was doing research I read that chargers up the current they dish out if the device is in use. Is that correct?
Click to expand...
Click to collapse
Well, the 120v->5v converter certainly can be providing more current @5v because the device is active, but that's only because the motherboard is drawing current in parallel with the battery charging circuit. It doesn't mean the battery charge rate is higher.
krisserapin said:
Could there really be a hardware related problem of any sort (not just charging and battery problems but anything) that causes problems with 4.2 based builds specifically but doesn't cause problems with 4.1?
Click to expand...
Click to collapse
I suppose so.
I would do a few things to determine whether that is a reasonable hypotheses, though.
1) See how fast the battery charges with the tablet turned off. Should be close to 40%/hour for a new battery. You know there is no "software" running with the tablet turned off, so if you don't see some reasonable number here (say > 20%/hr) then a bad battery or charge controller circuit in the tab are the most likely culprits. Also, if the temperature rise of the tablet while doing this seems higher than the gf's unit, that would implicate the battery, not the charging circuit.
2) There's software, and then there's software. (Preinstalled vs. User installed) Run the battery down a ways, and then observe the battery charging rate with the device on but screen off (sleeping), but on a stock 4.2 install with ZERO user apps installed. Then, install/restore all your favorite apps, reboot, maybe use a couple of your fave apps, and repeat the same charge rate trial (screen off/sleeping). Are there large differences between the two cases? If so, that would implicate one of your apps in causing either lots of additional compute operations or preventing entry into the LP0 state (perhaps because of wakelocks?)
The thing is, the N7 battery is rated at 4325 mAh; that is sort of the same thing as 4.325 amps of current for 1 hour. (Voltage range of roughly 4v to 3.5v).
So, if a "good battery" can be charged in 2.5hrs, that is sort of like stuffing 1.73 amps into the battery for that time (1.73 x 2.5 = 4.325 A-h or 4325 mA-h). That's pretty near to the max capacity of the AC charger (2A)
Now, some users have reported discharging their tabs in 4 hours under heavy continuous use; that would be about 1.08 amps for 4 hours.
Since the wall charger is rated to produce 2A, this suggests that very heavy usage simultaneous with charging would indeed cause battery charging to slow down significantly - let's suppose it drops from 1.73a to 0.65a. Now it takes the battery 6.6hrs to charge ... but that is still just over 15%/hr ... with the tab in active use.
But that's not what you were noticing - you were seeing much worse charge rates than this when the tablet was supposed to be more or less idle!
Finally I should point out that I previously mentioned that the % charge number is a prediction, not a measurement! If for some reason this number were screwed up, then the "charge rate" observations could be completely screwed up. (Think of this as being analogous to trying to partially fill a gas tank in a car or estimate fuel mileage with a broken gas gauge) The only way to be sure that you are not falling victim to something like this is to record battery voltages - the 100% level should be up around 4v, and the 10% values down around 3.5v.
You can observe this value at /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/voltage_now
(note value is reported in uV)
Whew - long post. It doesn't directly answer your question about "why was 4.1 so different?" - but gives you an idea about why I was skeptical when you saw charging rates as low as you did.
I dunno, maybe the % charge prediction value numbers are screwy on your tab for some strange reason in 4.2, perhaps because of a minor hardware difference. I can't rule it out - I once saw a bug expression in a hardware/software combination that required three independent conditions (from three separate vendors!) to have precise configurations before the bug would show itself.
I hope this post gives you some ideas to try; it certainly doesn't give a solution.
Good luck - if you feel like spending more time investigating, go for it; just don't let the clock run out on the warranty period if you have one left.
bftb0 said:
Well, the 120v->5v converter certainly can be providing more current @5v because the device is active, but that's only because the motherboard is drawing current in parallel with the battery charging circuit. It doesn't mean the battery charge rate is higher.
I suppose so.
I would do a few things to determine whether that is a reasonable hypotheses, though.
1) See how fast the battery charges with the tablet turned off. Should be close to 40%/hour for a new battery. You know there is no "software" running with the tablet turned off, so if you don't see some reasonable number here (say > 20%/hr) then a bad battery or charge controller circuit in the tab are the most likely culprits. Also, if the temperature rise of the tablet while doing this seems higher than the gf's unit, that would implicate the battery, not the charging circuit.
2) There's software, and then there's software. (Preinstalled vs. User installed) Run the battery down a ways, and then observe the battery charging rate with the device on but screen off (sleeping), but on a stock 4.2 install with ZERO user apps installed. Then, install/restore all your favorite apps, reboot, maybe use a couple of your fave apps, and repeat the same charge rate trial (screen off/sleeping). Are there large differences between the two cases? If so, that would implicate one of your apps in causing either lots of additional compute operations or preventing entry into the LP0 state (perhaps because of wakelocks?)
The thing is, the N7 battery is rated at 4325 mAh; that is sort of the same thing as 4.325 amps of current for 1 hour. (Voltage range of roughly 4v to 3.5v).
So, if a "good battery" can be charged in 2.5hrs, that is sort of like stuffing 1.73 amps into the battery for that time (1.73 x 2.5 = 4.325 A-h or 4325 mA-h). That's pretty near to the max capacity of the AC charger (2A)
Now, some users have reported discharging their tabs in 4 hours under heavy continuous use; that would be about 1.08 amps for 4 hours.
Since the wall charger is rated to produce 2A, this suggests that very heavy usage simultaneous with charging would indeed cause battery charging to slow down significantly - let's suppose it drops from 1.73a to 0.65a. Now it takes the battery 6.6hrs to charge ... but that is still just over 15%/hr ... with the tab in active use.
But that's not what you were noticing - you were seeing much worse charge rates than this when the tablet was supposed to be more or less idle!
Finally I should point out that I previously mentioned that the % charge number is a prediction, not a measurement! If for some reason this number were screwed up, then the "charge rate" observations could be completely screwed up. (Think of this as being analogous to trying to partially fill a gas tank in a car or estimate fuel mileage with a broken gas gauge) The only way to be sure that you are not falling victim to something like this is to record battery voltages - the 100% level should be up around 4v, and the 10% values down around 3.5v.
You can observe this value at /sys/devices/platform/tegra-i2c.4/i2c-4/4-0055/power_supply/battery/voltage_now
(note value is reported in uV)
Whew - long post. It doesn't directly answer your question about "why was 4.1 so different?" - but gives you an idea about why I was skeptical when you saw charging rates as low as you did.
I dunno, maybe the % charge prediction value numbers are screwy on your tab for some strange reason in 4.2, perhaps because of a minor hardware difference. I can't rule it out - I once saw a bug expression in a hardware/software combination that required three independent conditions (from three separate vendors!) to have precise configurations before the bug would show itself.
I hope this post gives you some ideas to try; it certainly doesn't give a solution.
Good luck - if you feel like spending more time investigating, go for it; just don't let the clock run out on the warranty period if you have one left.
Click to expand...
Click to collapse
Wow thank you so much for the help. I'll play around with this tonight and see what happens. If I can't figure it out by the morning I think I'll be able to RMA it without feeling like I just rolled over and let my n7 get the best of me.
So after charging it on stock 4.2.1 with the power completely off it only charged 3% in a little over a hour and voltages read 3.6. I'm gonna leave it on the charger over night turned on starting from 3% with only two extra battery monitoring apps installed and report back in the morning with screenshots of the results. After that ill probably revert to 4.1.2 drain the battery fully, charge it off for an hour report the values then let it charge fully with the battery apps on for reference take a few more screenshots then lock the bootloader install the ota and ship it off to good old ASUS since it sounds like its hardware from whats been explained.
FWIW, I drained my N7 last night (LOL, typing novels into XDA threads) - when I finished I was at 6% charge - that was 3.66v. In the morning @ 100%, the battery voltage was 4.1-something.
Sounds to me like you've definitely got a hardware problem.
Good luck with the RMA.
Canyou help me?
Since I flashed 4.2.2 my 240V-USB charger only cahrges thes battery about 5% in one hour.
Before (with 4.2.1) It was definitely faster. It charged more tha 5% per hour (maybe 20-25%).
I double checked the plug in the socket. checked the correct fit of the USB cable on the docking station.
Everything fits tight. No wiggle.
It must be software related, since it started after flashing the OTA zip from 4.2.1 to 4.2.2
Polarfuchs said:
Canyou help me?
Since I flashed 4.2.2 my 240V-USB charger only cahrges thes battery about 5% in one hour.
Before (with 4.2.1) It was definitely faster. It charged more tha 5% per hour (maybe 20-25%).
I double checked the plug in the socket. checked the correct fit of the USB cable on the docking station.
Everything fits tight. No wiggle.
It must be software related, since it started after flashing the OTA zip from 4.2.1 to 4.2.2
Click to expand...
Click to collapse
From a partially charged state, say below 50%, turn the device off, (NOT sleeping, but powered OFF) and put it on the charger for one hour.
It should charge at around 30-40%/hr.
As I pointed out above, how is it possible that software would be affecting the charging with the device turned OFF?
I believe you are seeing exactly what you report; my best guess is that a hardware problem occurred just about coincidentally with your upgrade. Just coincidence - not causation.
You also should inspect the battery voltage (see above for path in /sys) in case something crazy is happening with the %charge *prediction* (it is not a measurement) - because the total charging range is from about 3.65v-4.15v, a normal charge rate should be roughly 150 to 200 mV/hr
good luck
Battery Calibration/Improving Battery life
Requirements:
Device needs to be rooted "Obviously".
Need to have Rom Tool Box Lite or Rom Tool Box Pro.
Some Basic Knowledge on how to use the app.
Note: Turn off Wi-Fi, Bluetooth, GPS, and Auto-sync if they are not in use. Hold down the notifications bar to disable them and activate the Power Saving mode which will make the device conserve energy under low battery state.
Battery Calibration Procedure.
1. Use your phone until the phone battery drains out completely and device gets switched off
2. Switch on the Device to make sure battery really is 0%.
3. Now plug in charger (Device turned off, Dont turn on the device)& leave it for charging until it reaches 100%
4. When the battery is full, switch on the phone, unplug the charger & check if the battery drops by 1 or 2% immediately.
5. If you notice battery drops immediately plug in charger once more (while the phone is on) & let it charge completely.
6. Once charging to 100% is done, don't disconnect the charger, open your root explorer, Provice RW permissions.
7.Search for 'DATA' Folder then 'SYSTEM' Folder.
8.In the 'System' folder you will find 'batterystats.bin' delete this file.
9.Exit Root Explorer and Use your phone normally unless it completly drains the battery(Dont connect your charger)
10.Power On your device and charge your device untill it reached 100%
11.Now you should enjoy the Samsung long Battery Life!!
Note: These methods are not permanent this worked for me so sharing with you.
Greenify your Apps:
NEW: Non-root working mode is now supported in 2.0+, Greenify is a convenient utility that will consequently hibernate battery hoarding applications that wait out of sight after you're done utilizing them.
Google Playstore & Thread
Titanium Backup:
Great battery life, wonderful execution and cool customization— we have seen one or more applications for these things. Presently we should see an alternate must have and a standout amongst the most evaluated applications for established Android gadgets. On the off chance that you got root benefits on your gadget, Titanium Backup is an exceptionally suggested application for you. You may discover various reinforcement applications at the Google Play Store, however none of them does the employment so splendidly and pleasantly.
Google playstore
The KERNEL can do some important things to help with battery saving as it is the controller of all things working in your phone:
1. Underclocking - if you feel your phone is fast enough, go ahead and lower the maximum frequency of your CPU, it will save power as the faster the CPU goes, the more energy it uses.
2. Undervolting - it's more complicated; every CPU requires certain amount of supplied voltage to run and the amount increases with the speed of CPU (clock frequency). For example 200Mhz requires only 0.9V while 1600Mhz requires 1.25V by default. The thing is, the higher the voltage, the higher the heat and of course power consumption. So the best way to lower it is to lower voltage - Samsung had to set voltage at the high enough level that every CPU they produce would work correctly but every CPU is different and some of them allow for lowering voltage and still remaining fully stable thus using less power to do the same work. Typically you can save about 0.05V but some CPU will allow as much as 0.1V to be saved. The same really goes for our GPU part, it can be undervolted as well. There are other parts in our phone that can be undervolted, like memory or controllers of various part but I have found (well in my phone) that saving were very small and caused instability so I would not recommend playing with them. We could think about undervolting our display as it is the biggest consumer of energy in our phone but actually we are doing it all the time The voltage supplied to the screen decides its brightness so if we were to lower the voltage it would just get dimmer
3. There are small savings to be had in various other parts controlled by the kernel:
- first and second thing are tied with SDcard - using it carries high power requirements - the less we use it, the better. Now we can't reduce to completely as all our data, apps and whole system is on it but we can reduce it's use by setting various caches.
a) read cache for internal and external SD combined with scheduler that minimizes reads and writes - so far the best scheduler created specifically for mobile SD use is FIOPS, so using that with a large buffer (maximum of 4096) is actually the best from energy standpoint.
b) system swap space - some kernels allow for creating a very specific kind of swap space, Android will use it once the free memory falls below certain point. Normally this swap space would be placed on SDcard but in this case it's inside a specific region of RAM. Why it is created like this? Because it can be easily compressed to keep more data, so basically we are using Android mechanisms and compressing memory so we can run more apps and keep them in physical RAM That means they are accessible faster than if we were to read them from SDcard and they use less power. Compressing and decompressing data as they go in and out of swap space is still far less energy consuming process then reading them from SDcard.
- third is governor configuration - governor is a system service that decides at what frequency should the CPU be working at every moment and how much cores should be enabled - this of course has great impact on energy consumption and on the smoothness of our experience with our phone. There are two schools of setting up governor and they base their decisions on two premises:
a) sharply increase CPU speed to get the work done fast and sharply decrease speed once it's not needed.
b) slowly increase speed and only so much to do what must be don then slowly decrease speed once you are done because you may have to do something again in a moment
There are pros and cons of both ways - way A means jumping to high frequency for a short time but high frequency uses comparatively large amount of energy, way B means slow increase but also means remaining in intermediate states for longer actually using energy for longer. I don't have any way to actually measure the resulting energy consumption but way A has a distinct advantage of creating much smoother experience so I use that myself.
- fourth is hotplug configuration - our CPU can dynamically enable and disable additional cores - the process is called hotplugging. Some governors are created specifically for controlling this process, the best, as far as I have tested, in this is Lulzactiveq. Hotplugging has to be wise as to the IF and WHEN to enable and disable additional cores, it measures how many "packets" of data are in queue to be processed and based on short history anticipates increase and decrease of workload.
All those interesting options are configured in scripts created for main contemporary kernels: Nadia, Devil and Agni and available HERE.
Latest OC / UV Scripts for Devil / Agni and Nadia Kernels for Note 2 are HERE
Guide to EXT4 to F2FS migration for Note 2 is HERE
CourtesyMat9V
Reserverd
very useful info , thanks :good:
rraaka said:
very useful info , thanks :good:
Click to expand...
Click to collapse
Your welcome :good:
Very briefly stated.
Thanks for sharing
I read all your posts, This will help me in my next configuration for Emotion V7, Nadia with mat's script.
Now on Emotion V6 ....AGNi Pure Stock v4.2.2
yogi909 said:
Very briefly stated.
Thanks for sharing
I read all your posts, This will help me in my next configuration for Emotion V7, Nadia with mat's script.
Now on Emotion V6 ....AGNi Pure Stock v4.2.2
Click to expand...
Click to collapse
Glad you liked it.
The android system, unlike other OS's actually displays the battery reading from a written data config, known as battery stats in general. While there is, in perception no disadvantage to this method of reporting the average remaining battery life, it isn't the actual battery life you are getting, but the percentage read from your daily usage and then sends the information to the OS for displaying the battery life. Due to this, you can have the percentage misreported, so it is suggested to factory reset every 6 months on stock unrooted and if rooted wipe battery stats using rom toolbox free/pro every 2 weeks to ensure correct reporting of your battery life.
Note - This won't increase battery life, but will ensure correct reporting of battery percentage, which gets messed up quite quickly on custom roms(for some unknow reason).
Undervolting can cause battery drain or better battery life depending on your configurations, if you have the CPU set to running high many of the times(like from a governor or background apps that need regular wakelocks for syncing content) it will slow down the ramping up of frequencies during deep sleep(no effect when screen on) and thus it will hold a longer wakelock for the purpose, so undervolt carefully depending on your usage - mild to mid(medium to high undervolt), mid to high(low to medium undervolt), heavy(low to no undervolt).
Different governors have different scaling methods for CPU, thus will give better or worse battery life depending on your config and usage. A governor ramping up faster and scaling down slower will give better battery life in scenario of heavy usage because the device can go to deep sleep state faster and perform background syncs in an instant; while someone with low to mid(or a bit high also) would like to have a governor that ramps up slower and scales down slowly too so as to complete the syncing of files and media scan(if running) and make the device perform smoother and go into deep-sleep and remain in the state for longer times(though going to DS mode will be a bit slower than a fast downscaling governor) and will occasionally wake up for background syncs, but those will be longer, but won't have much effect on battery life because of lower frequencies being used and syncing complete before high frequency threshold is reached.
Depending on what a user needs for his daily usage it is a good idea to keep the rest of apps(preferably facebook, musixmatch, instagram and shazam) hibernated using something like greenify(which now supports auto-hibernation without root in the beta versions). Auto sync should only be enabled for apps that need it, like E-Mail, Google+, Gmail etc.and rest should be set onto manual sync.
Samsung has a habit of throwing in a lot of features onto their device, so keeping motions enabled, which you don't even use, except for a show-off, is a bad idea because it will drain battery. Exploring the settings menu to disable unneeded things can pay-off as a positive fruit for patience.
Keeping the storage clean is also a good way. A corrupted or highly filled up storage requires more passes to be read and thus keeps the media scanner process running for longer, which puts a strain on the battery life. Also, android OS is based of the 32-bit kernel of linux(for now, 64-bit is planned to be introduced after some time), so the media scanner has to look for data linearly in the storage blocks on the internal and external SD, unlike 64-bit where the data is arranged into random blocks which are then brought together as one and the media scanner can be informed of the address of the blocks due to more threads allowed to be run for same process and also a higher memory bandwidth allocated to each process so as to make it perform faster. Due to this reason, the media scanned isn't informed of all the addresses on the time of data writing and thus has to scan linearly looking for bits of data. So keep the storage clean and minimal. Cloud is a good way if you have decent internet and won't need access to the files stored there in regular period of times.
If using a custom rom make sure that it either comes with the modem for your region or flash the modem of your region after that, so as to ensure better signal stability and thus better lasting battery life. A correct modem can give more dBm of signal at the same place as compared to a wrong one.
A good way to have stable battery life is to enable power saving mode in areas with low signal and when on low battery life only, keep it disabled otherwise or it will slow down the race-to-idle for Deep sleep mode and hence cause a bit more battery drain just before deep-sleep state.
Having location services enabled all the time isn't a good idea either, use it only when needed and keep GPS off otherwise. Samsung allows toggling of most things from notification panel so use it.
Smart stay, smart pause, smart scroll all use the front camera for detection, which requires high voltage for operation(separate from CPU, uncontrollable by software) so keep them off unless needed.
Make sure to keep your device clean. How does this affect battery life? Dust and other things when collected around pins, sockets and connectors prevent efficient passing of electricity and thus forces the device to demand more energy, around half of which is taken away by these. Even metallic dust can have adverse effect due to it making the transfer more rapid and forcing the battery to supply the power, which is most probably wasted.
Automatic brightness is good during daytime, but useless during late evening and night, because brightness level doesn't need to be changed and it keeps the light sensor activated. Disable it after 7 Pm(you can also set up tasker or some other automation tool for this).
An Odexed rom provides more battery life as compared to deodexed, but at the cost of available customization as no mods will work and will instead crash the file related to them. Choose your side wisely and patiently.
If you're going to use some app, check if it uses GCM for providing notifications(usually google search at your service), if not look for an alternative which does. GCM doesn't even use marginal amount of battery and is more efficient in providing the notifications at time and also doesn't need a persistent notification.
Check for wakelocks thoroughly and remove the misbehaving apps or hibernate them if you need them on your device. Also, be sure to update the apps for receiving any fixes and optimizations, which can sometimes also decrease the required wakelock frequency for an app and thus preserve battery life.
Don't keep too much of auto updating widgets on homescreen, these only serve to drain the battery further by auto syncing.
if rooted, use Xposed and boot-manager to disable unneeded apps at boot time and thus preserve battery and time required for full boot-up.
If on a custom kernel use DAC direct(if available) for sounds. This bypasses the output mixer and thus preserves a little bit of battery required to produce and refine the sounds, instead utilize 128x oversampling and FLL tuning for an even better quality.
Don't reboot on a regular basis unless needed, this will eat up battery life quicker.
Don't use any task killer( a long debate on uselessness of those can be found on many sites, with a simple google search), the Android system's LMK is itself more than enough.
Be sure to research carefully on what you really need and what you don't and then use it. Don't go on downloading useless things which you'll delete later on because it creates a small entry in /data/data which gets scanned by media scanner due to being present in its path and thus will make the process longer and more battery hungry.
Some custom kernels allow for controlling deep sleep type. Usually these types are already defined in the kernel tweaking app itself. A person with heavy usage should use the IDLE deep sleep more so the device is able to wake up quickly and doesn't drain much battery in case of many wakelocks. Similarly a light user will benefit with AFTR+LPA due to CPU deep sleep, but this isn't advised for medium to heavy usage(use IDLE+LPA instead) because the wakelocks require a high power to even wake up the device, which will drain more battery if you use your mobile more, because many apps will try to acquire a partial/complete wakelock.
I know this is quite long, but read through carefully and you'll surely get better battery life.
Source : Experience and Google groups
Good knowledge
Thanx
cartmanez said:
Good knowledge
Thanx
Click to expand...
Click to collapse
People are still spreading the batterystats.bin myth? *facepalm*
This has been totally and utterly disproven many, many times, including by core Android developer
So delete away. It doesn't calibrate or improve your battery life though.
I cannot study myself all technically like you what you mentioned in "[Experience][Share]My Usage and Testing of Custom kernels for Touchwiz Kitkat".
But above is well informative and now i get why i was getting worse battery life & longer wakelock by OC and UV with selective governer.
By testing different setting in AgniPureStock 4.2.2 today i reach 25 hr + battery life with my moderate usage.
I am sure above valued information, i will get most out of my battery.
Thank you very much KNIGHT97 for sharing.
aukhan, Hi mate, do i need to install greenify too?
botski said:
aukhan, Hi mate, do i need to install greenify too?
Click to expand...
Click to collapse
Yes
Sent from my GT-N7100 using Tapatalk
aukhan said:
Yes
Sent from my GT-N7100 using Tapatalk
Click to expand...
Click to collapse
if i use greenify i need to install xposed framework too?
botski said:
if i use greenify i need to install xposed framework too?
Click to expand...
Click to collapse
Xposed is optional. It is only for the experimental features. However, the developer has got 1 or 2 of those working without Xposed in the latest beta(you'll need to join the greenify G+ community for getting the beta, though)
Sent from my RPG with auto targeting
非常有用的信息，谢谢 ：好：
thanks for the info man.....its very helpful
aukhan said:
The KERNEL can do some important things to help with battery saving as it is the controller of all things working in your phone:
1. Underclocking - if you feel your phone is fast enough, go ahead and lower the maximum frequency of your CPU, it will save power as the faster the CPU goes, the more energy it uses.
2. Undervolting - it's more complicated; every CPU requires certain amount of supplied voltage to run and the amount increases with the speed of CPU (clock frequency). For example 200Mhz requires only 0.9V while 1600Mhz requires 1.25V by default. The thing is, the higher the voltage, the higher the heat and of course power consumption. So the best way to lower it is to lower voltage - Samsung had to set voltage at the high enough level that every CPU they produce would work correctly but every CPU is different and some of them allow for lowering voltage and still remaining fully stable thus using less power to do the same work. Typically you can save about 0.05V but some CPU will allow as much as 0.1V to be saved. The same really goes for our GPU part, it can be undervolted as well. There are other parts in our phone that can be undervolted, like memory or controllers of various part but I have found (well in my phone) that saving were very small and caused instability so I would not recommend playing with them. We could think about undervolting our display as it is the biggest consumer of energy in our phone but actually we are doing it all the time The voltage supplied to the screen decides its brightness so if we were to lower the voltage it would just get dimmer
3. There are small savings to be had in various other parts controlled by the kernel:
- first and second thing are tied with SDcard - using it carries high power requirements - the less we use it, the better. Now we can't reduce to completely as all our data, apps and whole system is on it but we can reduce it's use by setting various caches.
a) read cache for internal and external SD combined with scheduler that minimizes reads and writes - so far the best scheduler created specifically for mobile SD use is FIOPS, so using that with a large buffer (maximum of 4096) is actually the best from energy standpoint.
b) system swap space - some kernels allow for creating a very specific kind of swap space, Android will use it once the free memory falls below certain point. Normally this swap space would be placed on SDcard but in this case it's inside a specific region of RAM. Why it is created like this? Because it can be easily compressed to keep more data, so basically we are using Android mechanisms and compressing memory so we can run more apps and keep them in physical RAM That means they are accessible faster than if we were to read them from SDcard and they use less power. Compressing and decompressing data as they go in and out of swap space is still far less energy consuming process then reading them from SDcard.
- third is governor configuration - governor is a system service that decides at what frequency should the CPU be working at every moment and how much cores should be enabled - this of course has great impact on energy consumption and on the smoothness of our experience with our phone. There are two schools of setting up governor and they base their decisions on two premises:
a) sharply increase CPU speed to get the work done fast and sharply decrease speed once it's not needed.
b) slowly increase speed and only so much to do what must be don then slowly decrease speed once you are done because you may have to do something again in a moment
There are pros and cons of both ways - way A means jumping to high frequency for a short time but high frequency uses comparatively large amount of energy, way B means slow increase but also means remaining in intermediate states for longer actually using energy for longer. I don't have any way to actually measure the resulting energy consumption but way A has a distinct advantage of creating much smoother experience so I use that myself.
- fourth is hotplug configuration - our CPU can dynamically enable and disable additional cores - the process is called hotplugging. Some governors are created specifically for controlling this process, the best, as far as I have tested, in this is Lulzactiveq. Hotplugging has to be wise as to the IF and WHEN to enable and disable additional cores, it measures how many "packets" of data are in queue to be processed and based on short history anticipates increase and decrease of workload.
All those interesting options are configured in scripts created for main contemporary kernels: Nadia, Devil and Agni and available HERE.
Latest OC / UV Scripts for Devil / Agni and Nadia Kernels for Note 2 are HERE
Guide to EXT4 to F2FS migration for Note 2 is HERE
CourtesyMat9V
Click to expand...
Click to collapse
Thanks man....you rock:good::good:
What about using Juice Defender (available in play store)? I used the basic one first and then ended up buying ultimate because I saw good results. Now the location (using cell tower) based WiFi enable/disable extends my battery life significantly.
The is one of the first apps I install once I feel a new flash is stable.
If you have the Samsung "Toolbox" utility, that floats a button on the screen to access your choice of five apps from anywhere - turn it off. It causes the "security storage" process to peg at 20% all the time the screen is on if "Toolbox" is enabled. When "Toolbox" is disabled, "security storage" process drops to a couple of percent when the device is idle. There's quite a saving on battery drain.
Battery calibration
I have a rooted Nook HD+ running Android 7.1 and I decided to calibrate its battery.
I ran it down to zero as recommended then attached it to the mains.
All I have had for several hours is a black screen with just the charging symbol (battery with lightning inside it). Nothing else, no progress bar, no charge %, nothing Androidy.
Is this as it should be and should I just wait for several more hours or is there something wrong?
Many thanks.
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!
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.
pbanj said:
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.
Click to expand...
Click to collapse
This is why I always use a low current charger unless I absolutely need a quick charge. I have used the Dash charger that came with my OnePlus 5 only about 10 times in 2 years.
As I use my phone more, I realize that none of the charging switches seem to work 100% of the time as expected. I'll continue to do trial and error tests, but please share if you find a switch that works consistently.
sic0048 said:
As I use my phone more, I realize that none of the charging switches seem to work 100% of the time as expected. I'll continue to do trial and error tests, but please share if you find a switch that works consistently.
Click to expand...
Click to collapse
I was having issues with ACC not working before installing the apk. I'll report back if I have any issues.
Nice guide BTW.
I've continued to edit my original post to provide as much information about the different charging switches and the issues I see with each one. Hopefully it is easy to understand.
I still find myself defaulting to the 3rd charging switch option and while it can act a little erratic sometimes, it does work normally most of the time.
I'm just curious if anyone has tried the "auto" charging switch in the latest ACC version? According to the release notes, there was some changes made to the auto system as it may not have been working correctly.
I'll try it here in a little while, but thought I would ask.
sic0048 said:
I'm just curious if anyone has tried the "auto" charging switch in the latest ACC version? According to the release notes, there was some changes made to the auto system as it may not have been working correctly.
I'll try it here in a little while, but thought I would ask.
Click to expand...
Click to collapse
I've been using the apk auto switch, no issues.
Is this working for anyone:
usb/current_max:500000
I have is set in the app as an On plugged option and It is not working for me.
gargleblarg said:
I've been using the apk auto switch, no issues.
Click to expand...
Click to collapse
The phone discharges at the pause threshold and not simply hold the charge at the threshold percentage?
I found the auto setting showed the same tendencies as switch 2 - not discharging below the pause threshold. But I haven't tried it with the new release which specifically mentioned the auto setting bring changed.
sic0048 said:
The phone discharges at the pause threshold and not simply hold the charge at the threshold percentage?
I found the auto setting showed the same tendencies as switch 2 - not discharging below the pause threshold. But I haven't tried it with the new release which specifically mentioned the auto setting bring changed.
Click to expand...
Click to collapse
I'm on 2019.6.14-r1 version.
I charged up to 80% and kept it plugged in to see if it would drop or maintain, it dropped. It took forever.
Edit: 8 hours later and it has only dropped to 78%
@creeve4, I can't get the On Plugged options to work either. I tried "./usb/current_max:500000" and "usb/current_max:500000", I tried unplugging/plugging in the charger, resetting the daemon, still no luck. The settings were saved to the config file correctly. No idea.
gargleblarg said:
I'm on 2019.6.14-r1 version.
I charged up to 80% and kept it plugged in to see if it would drop or maintain, it dropped. It took forever.
Edit: 8 hours later and it has only dropped to 78%
Click to expand...
Click to collapse
Interesting. That's unfortunately not what I experience.
I just tried the auto setting and plugged my phone in and it immediately went into what I am calling a "maintenance charge". It was only charging the phone by about 200 mA. I set the charging switch back to #3, unplugged and replugged in the phone and it is charging at about 1200mA which a pretty normal charging current for me.
It's this same roughly 200mA charge that I have seen previously with the auto setting after the phone reaches the set pause threshold - so the phone charges at normal current levels and then drops to the 200mA current after reaching the pause threshold. Admittedly, I did not allow the phone to reach the pause threshold this time (which would take forever at 200mA), but seeing that charging level at all leads me to believe that the auto charging switch is still not working for me (it should either be fully charging or full discharging). I suspect because the phone was above the resume threshold it defaulted to this maintenance charge (thinking the phone shouldn't be fully charged until it dropped below the resume threshold).
sic0048 said:
Interesting. That's unfortunately not what I experience.
Click to expand...
Click to collapse
What was the battery level when you plugged it in?
sic0048 said:
Interesting. That's unfortunately not what I experience.
Click to expand...
Click to collapse
That is interesting, have you tried updating yet?
I should also mention that I have only changed the percentage to 3% for the phone to shut off, the rest of the options are default.
Is anyone else getting the following message in the acc app after updating to the latest version?
creeve4 said:
Is anyone else getting the following message in the acc app after updating to the latest version?
Click to expand...
Click to collapse
I'm not using the app, so I can't answer your question. I was hoping someone else might chime in if they are using the app.
sic0048 said:
I'm not using the app, so I can't answer your question. I was hoping someone else might chime in if they are using the app.
Click to expand...
Click to collapse
I just needed to update to the latest app version. The module was updated before the app.
Did anyone else lose their config settings when updating the ACC module recently? I updated a day or two ago and woke up to my phone at 100% charge. I started troubleshooting and found that the config file was set to all the default settings. This means the charging switch was set to "auto" which has never worked for me and it explains why the module didn't pause the charging at the default pause setting (80%).
The release notes talked about a lot of changes in the config file, but it never mentioned that users would lose their settings and be reset to default. I was just curious if anyone else experienced the same thing or not.
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
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?
Hello!
Some time ago I found inside Advanced Charging Controller this feature called battery idle mode. When the ASUS ROG phone 3 was launched I immediately noticed the pass through charging.
Basically it is the ability to run the phone directly from the charger and stop charging the battery in certain conditions (like when the battery is hot, or it reaches 80 %). On the long run this could mean a big improvement in battery longevity, especially for people that use their phones while charging (overnight charging, in-car navi, gaming, etc.)
Sadly, this feature is kernel dependent. So I am trying to figure out if there is a kernel that supports this feature. I've tried searching around the development area, but there was nothing obvious and I didn't dig through the discussions.
Thanks!
Did you happen to find a kernel with support?
Sadly I haven't.
But I did find a different trick: set ACC to charge with 0 A (or any other very low value) and you'd basically get the same outcome (the battery will stay at the same value). Now I am not sure if this is in fact activating some trickle charging mode (and wearing the battery in the process)...