Related
10/19/11 Update: Added patches for the recently released GB sources to keyboard_patches-GB.tar.gz.
7/9/11 Update: New patch to export the "column-switch delay", which allows for much decreased CPU utilization/much better efficiency. See below for details.
3/23/11 Update: Add alternate "timer delay" patch to enable runtime configuration of keypad_timer delay. See below for details.
Attached is a kernel source patch that fixes the EB13 hardware keyboard dropped/skipped key press problem, at least for twice-pressed keys. It restores DI18-level responsiveness for the hardware keyboard.
I know dropped keypresses on the hardware keyboard has been a problem for a long time, even with DI18. There are likely multiple factors at play here, and this patch only corrects one of them. However, DK28/EB13 are particularly bad at dropping twice-pressed keys, and hopefully this patch alleviates this issue for most folks who experience it.
Bug details:
Sesquipedalian points out in one of the General threads concerning the issue that EB13 often drops twice-pressed letters on the hardware keyboard. For example, if one types "hello", often "helo" is emitted.
Yesterday I performed some timing tests and discovered that the EB13 keyboard driver delays 1/10th of a second (100 ms) between reporting "key_press" & "key_release" events. Unfortunately this delay is on the order of human muscle response, and when folks press the same letter twice in that 100 ms, the kernel will only be able to acknowledge one of the presses.
Keyboard driver background:
The Epic's keyboard driver is located at drivers/input/keyboard/victory/s3c-keypad.c in the EB13 kernel sources.
On initialization, the driver establishes an interrupt handler (s3c_keypad_isr) for keyboard ("keypad") events, which is executed whenever the kernel is interrupted with a key press. During an interrupt, the handler starts a timer (keypad_timer) to expire after "3 * HZ/100" jiffies (27 ms), and clears the interrupt request. The driver actually figures out which key was pressed/released in a separate routine that executes after the timer expires. Also, the interrupt is not immediately reenabled, so if a second keyboard event (either a key press or release) comes in before the timer expires, nothing additional happens.
When keypad_timer expires, the keypad_timer_handler function is invoked. This routine scans through each of the six "columns" (which roughly corresponds to the rows) of the keyboard looking for key presses & releases. In doing so, the driver delays 0.3 ms to ensure each column switch is accepted by the hardware, so the enitre routine should take rougly 1.8 ms to execute. This is actually quite a long time (but not inappropriately so) relative to the clockspeed of the processor, which is partly why the scanning is done outside the keyboard interrupt where operations "that take a while" are discouraged. So this isn't a bad setup, even if it might appear a bit unusual at first.
The end of the scanning routine (keypad_timer_handler) checks to see if any keys are currently held down, and if so it restarts keypad_timer. It must do this, becuase if a key is pressed & released "quickly", before the timer actually expires, then a release interrupt would never be generated (even if the interrupt was immediately reenabled). Hence, if a key is pressed & released "quickly", it is detected by the scanning routine after the second timer expiration. It's likely that the keybord only generates an interrupt on key press, so the timer is necessary to detect key releases. While a key is held down, the scanning routine keeps resetting the timer. Once a key release is detected, the timer is deactivated and the interrupt reenabled.
The bug:
Now, the problem is that keypad_timer, when restarted by the scanning routine, is set to expire after "HZ/10" jiffies (98 ms). This is an unusually long waiting time--four times as long as the original timer. If the same key is pressed twice in this interval, the scanning routine will pick it up only as a single press/release pair. If multiple, different keys are pressed in this interval, I believe the scanning routine will pick all of them up, but not necessarilly in the right order.
So the fix is to change the keypad_timer's restart expiration time to something more reasonable, like the 27 ms used by the interrupt handler. This decreases the waiting time to one in which it's unlikely that someone will be able to press multiple, or repeatedly press a key. As it turns out, that's exactly what DI18 does, so we know it works. It's totally unclear why Samsung changed it.
Oh well.
Edit: Originally I thought keys were latched, so press events would be detected by the scanning routine even if the key is released before keypad_timer expires. They're most certainly not though, the scanning routine likely polls the instantenous key (up or down) state, so a key press must be held for at least 27 ms so that the scanning may complete after the interrupt is serviced. If a key is held shorter than this, it will not be detected.
3/23/11: Alternate "timer delay" patch:
Also attached is an alternate patch that supercedes the original. It allows for runtime configuration of the keypad_timer delay via a sysfs exported timer_delay variable.
The current delay may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/timer_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/timer_delay
where N is the delay in jiffies.
A delay of "1" yields the shortest timer, and the most responsive keypad possible, whereas a delay of "256" (1 second) (in most kernels) is the longest allowed. At that point the keyboard is already useless since any keypress results in either repeated characters or the "alternate character popup".
In most kernels (where HZ=256), the default delay is "7" (27 ms), which is the same as the original patch and DI18. A delay of "16" (63 ms) approximates the behavior of stock EB13/EC05.
Basically, the delay is the minimum amount of time one must hold a key down for a keypress to register. It's also the maxmimum time the kernel believes a key is "held down" after it's let go. For example, with a delay of "7" one must hold a key down for 27 ms to register as pressed, and no-more-than 55 ms later does the key register as being released.
Or for a better example, with a delay of "128" one must hold a key down for half a second, and once registered, the key is "held down" for an additional half a second. Which almost guarantees an application-level repeated keypress or the alternate character popup.
Ideally one would start with a delay of "7" and reduce by one until the timer is fast enough for your typing rate that you no longer have dropped keypresses. Although many folks will find that a delay of "7" is fast enough for them.
7/9/11: New "column-switch delay" patch:
Attached are two (mutually exclusive) patches to export the "column-switch delay" (column_delay) in addition to the timer_delay variable. The first applies against stock EC05 and supercedes all previous patches. The second (alt patch) applies against stock EC05 with the previous timer_delay patch already applied and should be used for custom kernels already containing that patch.
The column-switch delay is the amount of time, in µs, that the driver delays while switching between the six keyboard "columns" (actually rows) in the keyboard scaning routine. A delay is necessary to ensure that the column switch has been performed by the hardware before scanning a new column, otherwise ghost keypresses result.
However, the 300 µs delay specified by Samsung is very inefficient, particularly for "reasonable" timer_delay values. With theimpaler747's suggested timer_delay of 5, the keyboard driver, while holding a key down, consumes 9.7% of CPU time (empirically tested), at any clock rate. This is quite-likely responsible for folks' previous complaints that use of the hardware keyboard causes audio skips, poor game performance, decreased battery life, etc.
This patch allows this (default) 300 µs delay value to be modified through a sysfs exported column_delay variable. Similar to the timer_delay, it may be read with:
Code:
cat /sys/devices/platform/s3c-keypad/column_delay
and a new delay may be set with:
Code:
echo N > /sys/devices/platform/s3c-keypad/column_delay
where N is the delay in µs.
A delay of "1" is the most efficient (only 0.02% CPU utilization) but results in ghost key presses. In testing, I've found ghosting to disappear at delays of "3" and above. To provide some buffer, I've been using (and recommend) a delay of "5" for both column_delay and timer_delay values for the past week, and I've not run into any issues.
At a delay of "5", the keyboard driver is far more efficient, consuming only 0.2% of CPU time while keys are held. This hopefully translates into less stuttering/performance problems and better battery life.
Testing on other devices is needed (and appreciated!) to find a reasonable delay where ghosting doesn't appear, assuming that "5" is too low on some devices. Even delays of "10" and "50" (comparable to other keyboard drivers) result in ~0.3% and 1.7% CPU utilization respectively, which is much better than the Samsung default.
Mirror links:
GB kernel patches: keyboard_patches-GB.tar.gz
Column-switch & timer delay patch: epic_keypad_delays-EC05.diff (for stock EC05)
Column-switch & timer delay patch: epic_keypad_delays_alt-EC05.diff (for kernels with timer delay patch already applied)
Historical links:
Timer delay patch: epic_keypad_timer_delay-EB13.diff
Original patch: epic_keypad_timer_fix-EB13.diff
Nice work!
Wow , nice work! I wish we had people as smart as you working @ Samsung or Sprint.
Sent from my SPH-D700 using XDA App
Nice WORK!!!
Since you have this fix, this will definetly improve it a little, now u just need to find a fix to fix all missed letters.
Great Job, cant wait for an updated kernal with this in it.
Our poor developers on here work so hard to clean up manufactures phones issues and bugs and do an amazing job. They should fire everyone at samsung and hire all the devlopers here. lol
great job! so i take it this is both not necessary and not even compatible with DI18?
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Lol , sorry I dont know why that is funny to me. Hope you get it working!
Sent from my SPH-D700 using XDA App
This fix seems to be worse as the special key popup is even more noticeable than before. Perhaps a change in timing would be better. Maybe Samsung changed this in response to complaints of the popup coming up when unwanted.
Sent from Bonsai 6.0.3
TheDub said:
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Click to expand...
Click to collapse
Rodderik is already all over it broham. =]
TheDub said:
Well... downloaded Genocides kernel, was able to compile it after getting the toolchain and everything. Worked great. Loaded it on my zip, flashed it..
Kernel doesn't boot and suddenly my SD card is unreadable.. LOL! Guess I'll leave it to the pro's as I try to recover some data off my SD card...
Tried Genocides kernel flash zip, still didn't work, dang.
Click to expand...
Click to collapse
thats my bad your sdcard got nuked it has to do with the i9000 having and internal and external sdcard storage...for now use my modified initramfs and not the new ported one on my git (says not to use i9000 initramfs in README on github)
mkasick thx for the info and i will put it in the kernel immediately and test
Now fix the QAOL bug
Sent from my SPH-D700 using Tapatalk
Top Nurse said:
This fix seems to be worse as the special key popup is even more noticeable than before.
Click to expand...
Click to collapse
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
mkasick the patch works beautifully! one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 (it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...if we used the config's value in original settings (256/10) then that would give us 25.6 where as your patch is giving us 30 (3*1000/100)...i may fix this later but using your diff patch for now...thanks again
mkasick said:
I've seen mention of this before, but I'm not particularly familiar with the issue.
When the does the special key popup happen (besides long-pressing a letter)? Can you give an example that would somewhat-reliably recreate the problem?
Click to expand...
Click to collapse
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Sent from Bonsai 6.0.3
I will install this as soon as there is a Kernel that has it.
Nice work!
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Originally Posted by TheDub View Post
Nice work!
Building Genocide with this patch applied for all interested testers...
Rodderick will need to be the one to officially include it in HIS! Kernel but now we all have something we can test... will post link when it's done compiling.
Rodderik is already all over it broham. =]
Click to expand...
Click to collapse
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
TheDub said:
I hate to be "THAT" guy but..
If you press and old A for about a second you get that popup everyone is referring to.
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
It was a known issue in DI18 I believe, that it would come up to frequently, Samsung probably fixed it by increasing that timer..
On genocide .3a and my rom I can't produce the hello bug reliably, the missed keys seem completely random and happen very very rarely with Swype gone.
Just a thought.
Nice to see, mine was a horrible fail anyways lol! but hey I was bored and you can't hurt anything by trying
Click to expand...
Click to collapse
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Forcystos said:
Now fix the QAOL bug
Click to expand...
Click to collapse
I wasn't sure what this was. Then I saw this post which describes it. Amusing.
Sadly I don't think it's an easy fix. This bug is known as ghosting, and it's due to the way the keyboard matrix works. If you simultaneously press keys in two different rows ("columns" in driver-speak), e.g., Q & A, pressing L is ambiguous. The hardware, since it lacks diodes, can't differentiate between L & O. Basically, if multiple buttons are pressed simultaneously all bets are off.
If this was a serious issue, as in folks were seeing spurious keypresses when not intentionally trying to perturb the hardware, we could fix it by modifying the keyboard driver to just ignore all press events when multiple columns have non-zero key masks. Basically this would result in simultaneous key presses not registering, whether they're in conflict or not.
Rodderik said:
one note you might want to mention is any kernel developers that attempt to change the Kconfig or CONFIG_HZ=256 ... then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
I don't think it should. Keep in mind that jiffies (the unit timers use) are defined in terms of CONFIG_HZ anyways. Specifically, HZ=CONFIG_HZ (in kernel space), and time_in_seconds = time_in_jiffies/HZ.
So a delay of (3*HZ/100) is nominally 30 ms regardless of HZ. It only deviates because it's integer division, so while (3*1000/100) = 30 ms, (3*256/100) is 23 27 ms (edit: foolish math! multiply before divide). For the most part, it shouldn't matter too much.
Rodderik said:
(it is set to 256 here but the Kconfig sets it to 1000 anyway) then that will throw this timer off (patched or not)
Click to expand...
Click to collapse
Wait what? CONFIG_HZ is 256 in both my .config and autoconf.h. Is there some bug I'm not aware of that resets it to 1000, or are you using 1000 in your config?
Rodderik said:
i think samsung missed the CONFIG_HZ=256 being used in the Kconfig...
Click to expand...
Click to collapse
I think they used CONFIG_HZ=200 in DI18, and it was changed to 256 for Froyo. The Linux default (on i386 anways) is 250 IIRC. I'm not sure why Samsung bothered to change it, maybe it's a upstream thing. But 200 vs 250 vs 256 is somewhat arbitrary anyways.
Top Nurse said:
Typing two letters quickly brings up the popup. Also the arrow keys act somewhat funny.
Click to expand...
Click to collapse
Hmm, I tried to induce both of these but I can't seem to. Any other thoughts on it?
davidrules7778 said:
i never new that would pop up til u just told me, i guess i dont type multiple "A's" often..
Click to expand...
Click to collapse
Please don't take my first comments as criticism of any kind! Just discussing the topic at hand
I don't type multiple A's either but when changing that timer to be much shorter does that make the time required to hold down A to produce that pop up shorter as well?
I saw a few people report that it makes it more noticeable (accidental pop ups).
TheDub said:
Now if we are decreasing that timer unintentionally with this patch it could produce it popping up all the dang time on accident.
Click to expand...
Click to collapse
Ah, no, different timer. Changing the duration of keypad_timer merely changes how often the kernel keyboard driver checks to see if a key has been released. But if you hold a key down for 5 seconds, the kernel won't report a key_release event until 5 seconds after the key_press event. In the interim, other stuff might be happening like the "special character popup", or a key-repeat timer--but those are IME/app level and not controlled by the kernel.
If anything, this patch should strictly help. Say the "special character popup" happens after holding down a key for 0.5 seconds (it's about this). Previously, if you held a key down for 0.43 s, the release might not be detected until after 0.5 s and the popup would happen. Now, if you hold a key down for 0.43 s, the release would be detected no later than 0.46 s, and the popup won't show.
Think of it this way: a shorter keypad_timer results in more accurate key event timing, but (somewhat negligibly) increases CPU load due to having to run the scan routine more often.
So I was investigating loadable kernel modules on the Droid 2 this weekend. One of the modules I tried loading was the smartass governor module and to my surprise it worked. From what I can tell it appears to be working with no problems.
The module itself is from a Milestone Cyanogen ROM. Given how close the Milestone is to the Droid 1 and how close the Droid 1 is to the Droid 2 it seemed like a safe try to see if it would load.
Requirements:
You must be rooted. This really should go without saying but I'm trying to cover all the bases here.
You must have busybox installed.
You must be able to boot into clockwork recovery.
I've tried this on Fission ROM but since we can't change the kernel on the Droid 2 this will probably work on any other Droid 2 ROM. D2G users, YMMV.
NOTICE: By installing this you assume any and all risk for what might happen to your phone. I am not responsible if this mod causes your phone to stop working, catch fire, steal your significant other, and/or hijack a plane. Basically I haven't had any issues but that is not a guarantee that you won't have any issues.
Attached is the update.zip. Boot into clockwork recovery and choose this zip to install. Once you reboot you'll be using the smartass governor.
So what has this done for your battery life?
Anecdotally I believe my battery life has improved. With the ondemand governor and data and wifi off I've seen my battery drop 10% in a night. With the smartass governor under the same conditions my battery appears to be the same. Now given that Motorola phones report the battery in just 10% increments my totally non-scientific analysis might end up being nothing.
Really you'd have to try it yourself and determine if things are better. From what I've read online the smartass governor is better at conserving battery than ondemand but it really depends on how you use your phone.
Download circle battery widget from the market. Its free and somehow it reports 1% increments. I have been using it for a while now and it seems to be spot on.
Sent from my DROID2 using Tapatalk
It just guesses
Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.
Looks interesting. I'll wait until a little more feedback is given before I try it. How is the performance after the install?
I'm guessing you have to sbf to go back?
tbaker077 said:
How is the performance after the install?
Click to expand...
Click to collapse
No different than using the ondemand governor. Smartass takes a clever approach to CPU scaling: instead of polling CPU usage like ondemand it detects when the phone comes out of sleep and sets a timer to go off in two ticks. Once that timer goes off it looks at CPU usage and scales if needed. What does all this mean? Well, if you turn on your phone to quickly check the time and then turn it back off the smartass governor will never ramp up the clockspeed. So far after a few days of light usage I've been quite pleased.
rtfield said:
I'm guessing you have to sbf to go back?
Click to expand...
Click to collapse
Nope. If you want to revert just chmod 644 /etc/startup/smartass.sh and reboot.
Sweet
Thanks
I wonder if they could modify this to work with the new gingerbread kernel.
I know when I had an HTC Eris, Conap used a smartass gov on his kernel and it was awesome.
So I took a shot and flashed the smartass governor a second ago on my GB d2, and seems to be working just fine. I'll report later with battery stats and anything else i notice.
Spitemare said:
Well, there is a way to get an accurate battery reading. Reading /sys/devices/platform/cpcap_battery/power_supply/battery/charge_counter will give you the battery level in 1% increments. However, the system reads from /sys/devices/platform/cpcap_battery/power_supply/battery/capacity which provides the bounded 10% increments. Some widgets, Minimalistic Text for example, will read from charge_counter on Moto devices.
Ideally a kernel module could be written that changes what is written out to capacity so the entire system could take advantage of 1% battery increments. If I had the time I would take a crack at it, but it's been awhile since I've done any C coding.
Click to expand...
Click to collapse
I took a look at this and found some stuff that might be encouraging.
Here is the source for the battery driver. Line 397 reads as such:
Code:
val->intval = sply->batt_state.capacity;
If line 397 is changed to this
Code:
val->intval = sply->batt_state.batt_capacity_one;
then battery level should be reported in 1% increments. I've posted the updated driver code here.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...
Do we really need busybox to uses this?
tbaker077 said:
Do we really need busybox to uses this?
Click to expand...
Click to collapse
Busybox's insmod is a little more robust then the insmod that's on the Droid 2. You can try editing the file /etc/startup/smartass.sh to remove the references to busybox and see if it works; I just stuck with busybox since that was what worked for me when building this thing. I'd try it myself but I can't at the moment.
I'm running an experiment now to see how long this governor will take me. I charged my phone to 100% last night (really 100% and not just to when the charging light went off) and turned it off. I turned it on this morning and will let the phone run until 5% battery is left. At that time I'll take a screenshot showing how long the system has been up. A few guidelines:
ROM is Fission 2.6.1 which of course means Froyo. I've been thinking about switching to the leaked Gingerbread ROM but I've decided to wait a little longer
Data must remain on. I usually turn data off when I'm not using it but to get results closer to worst case I'll keep data on. The only time it will go off is when I turn on Wi-Fi at home.
No turning off the phone at any time nor plugging it in. I guess I'm going to be using Dropbox a lot during this to transfer files but I don't want to reset the time since plugged in at all.
No overclocking, underclocking, or undervolting. Clockspeed and voltage are stock.
Usage will be light to moderate. I tend to use my phones for calls, chats, and web browsing. I'll throw in some YouTube videos and maybe download Angry Birds.
No apps that try to maximize battery life. That means no SetCPU, Tasker, Superpower, etc. This is supposed to be about how well the smartass governor does for battery life.
Again, once I reach 5% I'll try to take a screenshot of how long the phone went without being recharged.
Spitemare said:
I took a look at this and found some stuff that might be encouraging.
The problem is the gorram encrypted bootloader. It's not easily possible to swap a built-in hardware driver with a compiled module. If someone with more Linux kernel experience than I wants to take a crack at it then by all means...
Click to expand...
Click to collapse
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.
So unfortunately my phone rebooted halfway into the experiment so there is no screenshot for you all. I will say my phone made it just under 36 hours (6:30 Friday to 18:15 Saturday) on this governor. With some moderate internet browsing and way too many YouTube videos I'm quite happy with the outcome using this governor.
ZaneKaminski said:
Is this difficult to swap in simply because of the nature of what we'd be switching out, or does the eFuse chip and whatever other protection play a role here? I would try compiling your modified code and putting it on my device, except I'm afraid there will be some protective measure or something like that would brick my phone if I try. That and the fact that I have no idea what libraries and stuff I would compile this against.
Click to expand...
Click to collapse
I've already compiled the modified module and tried to load it. The phone just prevents it from loading since the hardware interrupts are already bound to the compiled in driver.
eFuse doesn't prevent new kernel modules from being loaded. Since a kernel module can alter almost anything not being able to change the kernel isn't too much of a problem. What a kernel module can't really do, however, is change device drivers. There's not a really clean way to unload a device driver module since it binds to hardware interrupts and you can't really unbind that once the phone is up and running. If you want to replace a device driver with an alternate module you have to load the module before the original module is loaded sometime during the boot process. With compiled in device drivers though that's not really possible.
Basically we're in a situation where we need to load an alternate version of the device driver in module form before the compiled in device driver binds to the hardware interrupts. That would take some sort of ramdisk containing the altered driver module and we can't do that with eFuse.
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.
I installed this and didn't see any improvement in battery life until I ran
Code:
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
It said it was still ondemand. I checked scaling_available_governors and smartass was not in there, so I went ahead and installed the zip again... still doesn't work.
I went ahead and took a look at /etc/startup/smartass.sh. The permissions were right, so I ran /etc/startup/smartass.sh. I then checked /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor and it was set to smartass.
Can anyone shed some light on why this script is not running on boot? I'm running the leaked Motorola Gingerbread ROM if that makes a difference.
Spitemare said:
The other option would be to write a module that hijacks calls to the particular function in the device driver and replaces that call with an alternative. That's got loads of problems though and is potentially dangerous. It would take someone with a lot more kernel experience than I have to write such a thing.
Click to expand...
Click to collapse
I see. I'm guessing the way to hijack said calls would be through directly modifying memory, right? That definitely is not something that sounds easy to do.
I tried running smartass.sh through an init.d script... still nothing. I actually had to make the /etc/init.d/ directory, so I figured that init.d scripts aren't supported on the Motorola Gingerbread rom... strange. I'll look for somewhere else where I can run stuff on startup.
Look for /etc/install_recovery.sh. That file is run by /init.rc if it exists. It's how the overclock stuff gets loaded on Fission. What the update.zip does is back up that file if it exists and then append /etc/startup/smartass.sh to the end. Just add the following to the end of /etc/install_recovery.sh if the update.zip doesn't add it:
Code:
/etc/startup/smartass.sh
Have you ever tried having your phone lay on a table for some time and when you come back to pick it up, it had almost burned through the table because of the battery heat do to an app running the CPU on a constant 100%?
Or have you tried waking up two hours to late for work, because you alarm did not go off do to the phones battery running dry during the night?
Bad applications or problems with some back-end processes is a problem for most people. To get some help with this problem, I have been running the Watchdog app for the last 3 years. It is a great application that will alert you whenever an app or a process is running wild in the background. However there is one issue with this app. It only alerts you when there is a problem. This does not help much if you are to far away from the phone, if your phone is in silent mode or if you are sleeping.
I wrote the developer of the app to see if there was any plans for making a tasker plug-in so that profiles can be made to handle this. I have yet to get an answer. In the mean time, I have made a complete watchdog profile for tasker that does what the watchdog app does, only this profile will auto terminate any wild processes if the screen is turned off. If the screen is on, it will to what the watchdog app does and alert you of the problem. It could be that you was playing a game or running a benchmark, so auto terminate while the screen is on, would not be a good idea.
The profile however, will drain more battery than the watchdog app does. Because of this I have set the check interval for 15 minutes instead of the 5 minutes I used on the app. This reduces the drain to about the same amount.
And to save even more power, I have included a Data control profile that will turn off data/wifi/sync when the screen is off, as long as you are not connected to a power source or if you are downloading, uploading or streaming. In this case the profile will wait until this state changes before turning off anything. And while off, tasker will alow sync (email and such) once every 15 minutes.
Both profiles is included in the attached download below.
Important!
The watchdog profile will need a proper busybox installed with proper symlinks for sed, grep and awk. It will also need a toolbox that supports top and ps with arguments.
You can run the update script from the Busybox Installer thread to make sure that your phone will work with this profile.
Changelog (2012-11-18)
Reduced the time from where the screen turns off, to the time Data/Sync is disabled
Data/Sync will now turn back on when the screen is unlocked rather than turned on. No need to waste power if you just want to check the time or notifications (Which can be done from lock screen in Android 4.x)
Fixed the 15 minutes data check when the screen is off. It only executed once after the screen was turned off
_______________________
Wow! Your watchdog implementation looks great! Will adopt it on my phone over the weekend.
Now I have only one battery-drain-controlling dream left - being able to find out the apps holding the wakelock for too long to kill them automatically. The reason for this is that sometimes I find battery drain to go from usual 1% per hour to 10% per hour just because some badly written app has not released the wakelock.
Alte.78 said:
Wow! Your watchdog implementation looks great! Will adopt it on my phone over the weekend.
Now I have only one battery-drain-controlling dream left - being able to find out the apps holding the wakelock for too long to kill them automatically. The reason for this is that sometimes I find battery drain to go from usual 1% per hour to 10% per hour just because some badly written app has not released the wakelock.
Click to expand...
Click to collapse
Are you talking about BetterBatteryStats? I know that it tells you exactly how long since a point in time (which can be manually customized) that certain programs/tasks hold wakelocks.
But not sure about any kind of specific stratification that displays only programs that hold the lock too long to kill them automatically (assuming that's what you are wanting?).
And OP, these sound great - I'm importing them as we speak :highfive:
dk_zero-cool said:
Important!
The watchdog profile will need a proper busybox installed with proper symlinks for sed, grep and awk. It will also need a toolbox that supports top and ps with arguments.
_______________________
Click to expand...
Click to collapse
I got all excited when reading about this until I read the Important section. After watchdog everything started getting confusing . I know I read somewhere about busybox but the other terms are all new to me...could someone explain it with a little more details on what I have to get/set up in order for this to work??
2am said:
I got all excited when reading about this until I read the Important section. After watchdog everything started getting confusing . I know I read somewhere about busybox but the other terms are all new to me...could someone explain it with a little more details on what I have to get/set up in order for this to work??
Click to expand...
Click to collapse
The profile is using some linux commands to get a list of all current processes and their CPU usage. These commands needs to be available in order for the profile to work.
If you are using a custom ROM, then you are most likely to have all what is needed. Especially if you are using a more current custom ROM.
In order to test this, download a terminal app or enter an ADB shell (Hope you know what this is) and see if the command line
Code:
top -n 1 | sed -e 1,7d | grep -e '[0-9]\+%' | awk '{print $3}'
returns anything. If it does (Except errors), then you will have all that is needed.
Alternatively you could check my Better Busybox Integration thread which will make sure that your phone is setup to work with this.
dk_zero-cool said:
The profile is using some linux commands to get a list of all current processes and their CPU usage. These commands needs to be available in order for the profile to work.
If you are using a custom ROM, then you are most likely to have all what is needed. Especially if you are using a more current custom ROM.
In order to test this, download a terminal app or enter an ADB shell (Hope you know what this is) and see if the command line
Code:
top -n 1 | sed -e 1,7d | grep -e '[0-9]\+%' | awk '{print $3}'
returns anything. If it does (Except errors), then you will have all that is needed.
Alternatively you could check my Better Busybox Integration thread which will make sure that your phone is setup to work with this.
Click to expand...
Click to collapse
well I entered that command and got
invalid argument "-n". and then a bunch of other lines after that...and I checked your other thread and there's even more code language ...ugh, I think this is one of those threads that I need to leave alone because it's too much for me to handle...sucks too cause your set up sounds really awesome...thanx for trying to help me though
2am said:
well I entered that command and got
invalid argument "-n". and then a bunch of other lines after that...and I checked your other thread and there's even more code language ...ugh, I think this is one of those threads that I need to leave alone because it's too much for me to handle...sucks too cause your set up sounds really awesome...thanx for trying to help me though
Click to expand...
Click to collapse
I will make a more simple command fix for you tomorrow that will make your phone work with this without having you enter any code.
dk_zero-cool said:
I will make a more simple command fix for you tomorrow that will make your phone work with this without having you enter any code.
Click to expand...
Click to collapse
ah thank you soo much!!!
2am said:
ah thank you soo much!!!
Click to expand...
Click to collapse
I have updated the Busybox Installer script to make sure that it will work on newer devices other than MTD, and I have added a custom toolbox binary that will contain the proper options for these profiles.
Just check the first post at the buttom in the Important section. Fallow the link, download the installer and run it in your recovery. After that you can import the profiles from this thread into your Tasker application.
Recently I have been digging all about my LED in Moto X Force (for those who do not know, Motorola did install a LED on the front panel, but didn't enable it for anything usable - some people state that it's on when battery is very low, and then phone does not start, but I have never seen it). This very strange decision of Motorola encouraged me to look how to use it anyways. I have found a few apps that supposedly were in control of it, but none seemed to be nor well written nor even working. So I decided not to use those. But one app did occur to be usable. And only option I liked there was LED blinking every time any IO operation on the SD Card occured. Yet, the app is in two versions. One (free) disallows to "start at boot" so everytime i reboot the phone, I have to manually run it to "blink again".
As I'm a dev, I did little digging and found out that it's really simple to make such functionality by just one command as root (it's basically telling the linux kernel when to trigger the LED - thanks kernel.org people ):
echo mmc0 > /sys/class/leds/charging/trigger
Just one command.
As this applies to ANY device, it's for everybody to see.
Moreover, if you type:
cat /sys/class/leds/charging/trigger
You will see the response like this:
none fg_adc-online MOTOSH-ANTCAP-PSY-DRIVER-online usb-online flash0_trigger torch0_trigger usb-parallel-online wireless-online bms-online battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid dc-online rfkill0 mmc0 [mmc1] backlight default-on bcl-online rfkill13
You can guess that for example:
- battery-full will light your LED when battery is full
- wireless-online will light when WiFi is on (and possibly have the internet connection - just guessing, test by yourself, it's not the point of this post)
- and so on
The one in square brackets is "active" trigger (in this case mmc1 - external sd card)
If you type:
ls -1 /sys/class/leds/
(or even: ls -1r /sys/class/leds/ for more details)
You will see all the LEDs you can use.
When you use /sys/class/leds/*/trigger the kernel will do all the job for you. If you want to do the job yourself from within your app, you may use /sys/class/leds/*/brightness
To be honest, I really regret I have rooted my phone so late (after warranty) .
Have fun guys
PS. If you are not a dev, you still can use above in tools like Automate or Tasker.
PS2. WARNING: for Moto X Force fiddling with lcd-backlight "LED" can cause reboots (if done at boot, bootloops). Only two "trigger happy" working LEDs are charging and torch-light0 for my phone. Still, lcd-backlight possibly can be done "manually" (brightness)
Hey, this is already years old. But how to undo the changes?
Hey xda-Community!
I recently wanted to reduce my idle drain and searched for ways to edit Android Doze settings, because I remembered seeing a tutorial that said you can change deviceidle-constants, that dictate how Doze works (how fast it kicks in, how long it kicks in, light/deep doze).
I tried all those old tutorials, but I quickly realized the old ways to change the parameters are deprecated, so I asked people on android.stackexchange.com and someone actually gave me the answer (thanks Andrew) (https://android.stackexchange.com/questions/247680/is-device-idle-constants-deprecated-in-android-12).
This works from Android 12 on and is achieved using a shell.
Commands:
Note: When using an adb shell, you have to put "adb shell" before those commands. I'll just put the bare commands here, you add what you have to add.
Checking the settings:
You can check your current Doze settings (and statistics) with "dumpsys deviceidle".
Changing a setting;
Every parameter has to be set individually. It's not that bad tho, as you only have to do this once.
Syntax is: "device_config put device_idle [KEY] [VALUE]".
One example: "device_config put device_idle light_after_inactive_to 30000"
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Spoiler: My recommended settings
First; reset parameters with: "device_config reset trusted_defaults device_idle"
light_after_inactive_to 30000
light_pre_idle_to 120000
light_idle_to 300000
light_idle_factor 2
light_max_idle_to 900000
light_idle_maintenance_min_budget 30000
light_idle_maintenance_max_budget 180000
inactive_to 900000
sensing_to 0
locating_to 0
motion_inactive_to 0
idle_after_inactive_to 900000
idle_pending_to 60000
max_idle_pending_to 120000
idle_pending_factor 2
idle_to 900000
max_idle_to 21600000
idle_factor 2
wait_for_unlock true
I also wrote a windows batch script (works via adb, you have to rename the .txt file to .bat) and a bash file that changes the parameters to my recommendations. See attachments.
will these settings persists even after a reboot? or upgrading rom?
maxs8007 said:
will these settings persists even after a reboot? or upgrading rom?
Click to expand...
Click to collapse
yes, these will stick after a reboot. Not sure about upgrading, but I would guess that it'll stay, because we don't actually modify anything on the system partition
@Doomkopf for me those settings won't stick.
For testing purpose I just applied those yesterday morning:
adb shell device_config put device_idle motion_inactive_to 300000
adb shell device_config put device_idle light_after_inactive_to 180000
This morning they are back to stock values. Any ideas? :S
Utini said:
@Doomkopf for me those settings won't stick.
For testing purpose I just applied those yesterday morning:
adb shell device_config put device_idle motion_inactive_to 300000
adb shell device_config put device_idle light_after_inactive_to 180000
This morning they are back to stock values. Any ideas? :S
Click to expand...
Click to collapse
I set mine like 6 weeks ago, it's still set. I miss many information, what phone do you use, what ROM, how you check if it's still set etc
Doomkopf said:
I set mine like 6 weeks ago, it's still set. I miss many information, what phone do you use, what ROM, how you check if it's still set etc
Click to expand...
Click to collapse
Hi, oh well here are some more infos:
Pixel 6 Pro
Latest Android 13 Stock ROM
Kirisakura Kernel
I check via "adb shell dumpsys deviceidle".
I set it all your settings on friday and today (monday) there are back to stock values.
Previously I tried settings my own settings on wednesday morning and had stock values on the next day already as well :S
Utini said:
Hi, oh well here are some more infos:
Pixel 6 Pro
Latest Android 13 Stock ROM
Kirisakura Kernel
I check via "adb shell dumpsys deviceidle".
I set it all your settings on friday and today (monday) there are back to stock values.
Previously I tried settings my own settings on wednesday morning and had stock values on the next day already as well :S
Click to expand...
Click to collapse
That doesn't sound good I'd check right after setting it, so you can see if it was changed at all (which I assume). If it indeed gets set and unset again, you could check this github repo (https://github.com/easz/doze-tweak) at "Caveat".
Those values got reset in the past already, but as it didn't happen to me, I thought Google stopped doing that. Maybe that old workaround still works Otherwise, you'll have to flash a custom rom I guess xD
EDIT: I also recommend looking at values easy to distinguish. For example, "sensing_to" and "locating_to" were nonzero before, now they are zero (for me), so these values are easy to compare for me. The values you need to look at are at the most upper part of the output, but I guess you already knew that
Doomkopf said:
That doesn't sound good
Click to expand...
Click to collapse
Did you ever mess with any other settings using device_config before? Like the number phantom processes, empty or cached processes, ActivityManager tweaks or anything else? Because I assume you did (and using Android 10 or higher) and disabled the settings sync back to the defauls.
Did you ever use the below command?
device_config set_sync_disabled_for_tests persistent
What does the below commands says?
device_config is_sync_disabled_for_tests
Perhaps it says true? If yes that's why your settings aren't changing.
crok.bic said:
Did you ever mess with any other settings using device_config before? Like the number phantom processes, empty or cached processes, ActivityManager tweaks or anything else? Because I assume you did (and using Android 10 or higher) and disabled the settings sync back to the defauls.
Did you ever use the below command?
device_config set_sync_disabled_for_tests persistent
What does the below commands says?
device_config is_sync_disabled_for_tests
Perhaps it says true? If yes that's why your settings aren't changing.
Click to expand...
Click to collapse
You quoted the wrong man
@Utini How'd it work out? If my last response doesn't help, maybe this one helps u
Doomkopf said:
You quoted the wrong man
@Utini How'd it work out? If my last response doesn't help, maybe this one helps u
Click to expand...
Click to collapse
No, logically I quoted the correct man Just wanted to indirectly tell others about the above trick / setting
Doomkopf said:
Hey xda-Community!
I recently wanted to reduce my idle drain and searched for ways to edit Android Doze settings, because I remembered seeing a tutorial that said you can change deviceidle-constants, that dictate how Doze works (how fast it kicks in, how long it kicks in, light/deep doze).
I tried all those old tutorials, but I quickly realized the old ways to change the parameters are deprecated, so I asked people on android.stackexchange.com and someone actually gave me the answer (thanks Andrew) (https://android.stackexchange.com/questions/247680/is-device-idle-constants-deprecated-in-android-12).
This works from Android 12 on and is achieved using a shell.
Commands:
Note: When using an adb shell, you have to put "adb shell" before those commands. I'll just put the bare commands here, you add what you have to add.
Checking the settings:
You can check your current Doze settings (and statistics) with "dumpsys deviceidle".
Changing a setting;
Every parameter has to be set individually. It's not that bad tho, as you only have to do this once.
Syntax is: "device_config put device_idle [KEY] [VALUE]".
One example: "device_config put device_idle light_after_inactive_to 30000"
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Spoiler: My recommended settings
First; reset parameters with: "device_config reset trusted_defaults device_idle"
light_after_inactive_to 30000
light_pre_idle_to 120000
light_idle_to 300000
light_idle_factor 2
light_max_idle_to 900000
light_idle_maintenance_min_budget 30000
light_idle_maintenance_max_budget 180000
inactive_to 900000
sensing_to 0
locating_to 0
motion_inactive_to 0
idle_after_inactive_to 900000
idle_pending_to 60000
max_idle_pending_to 120000
idle_pending_factor 2
idle_to 900000
max_idle_to 21600000
idle_factor 2
wait_for_unlock true
I also wrote a windows batch script (works via adb, you have to rename the .txt file to .bat) and a bash file that changes the parameters to my recommendations. See attachments.
Click to expand...
Click to collapse
Hi, currently I am using Naptime by Franco with ADB permissions. I'm not sure, but it should work by using the following options (maybe not only these, but I don't know well if there are other places where Doze options are stored):
inactive_to=2592000000,
motion_inactive_to=2592000000,
light_after_inactive_to=0,
light_pre_idle_to=30000,
light_max_idle_to=86400000,
light_idle_to=43200000,
light_idle_maintenance_max_budget=30000,
light_idle_maintenance_min_budget=10000,
min_time_to_alarm=60000,
min_light_maintenance_time=10000,
wait_for_unlock=0,
quick_doze_delay_to=86400000
It's working very well (I get 2% drain in 8 hours of sleep), but I wanted to try and improve it further, because the App tells you when and how much Doze is enforced and when maintenances are performed.
In my case, from my understanding, I don't need maintanances so often, or maybe I don't need it at all, because all the apps of which I need notifications are in non-optimized battery mode.
For reference, during night it performs 4-6 maintenances circa.
Coming to the point, I wanted to ask you I can use you settings even if they have further options like:
sensing_to 0
locating_to 0
and if I can make your settings even more extreme on some values.
For further reference, I have disabled through adb the "motion_engine", any system gesture and I have the Location always disabled (through UI shortcut, not ADB or advanced options).
NovaProspekt70 said:
Hi, currently I am using Naptime by Franco with ADB permissions. I'm not sure, but it should work by using the following options (maybe not only these, but I don't know well if there are other places where Doze options are stored):
inactive_to=2592000000,
motion_inactive_to=2592000000,
light_after_inactive_to=0,
light_pre_idle_to=30000,
light_max_idle_to=86400000,
light_idle_to=43200000,
light_idle_maintenance_max_budget=30000,
light_idle_maintenance_min_budget=10000,
min_time_to_alarm=60000,
min_light_maintenance_time=10000,
wait_for_unlock=0,
quick_doze_delay_to=86400000
It's working very well (I get 2% drain in 8 hours of sleep), but I wanted to try and improve it further, because the App tells you when and how much Doze is enforced and when maintenances are performed.
In my case, from my understanding, I don't need maintanances so often, or maybe I don't need it at all, because all the apps of which I need notifications are in non-optimized battery mode.
For reference, during night it performs 4-6 maintenances circa.
Coming to the point, I wanted to ask you I can use you settings even if they have further options like:
sensing_to 0
locating_to 0
and if I can make your settings even more extreme on some values.
For further reference, I have disabled through adb the "motion_engine", any system gesture and I have the Location always disabled (through UI shortcut, not ADB or advanced options).
Click to expand...
Click to collapse
Hey; please don't quote the whole post, it doesn't really tell me anything
I don't really understand: What do you want to know from me/what is your question? ^^
Yes, you can make some values more extreme, but you said you already did (less maintenance, more idle)
Doomkopf said:
Hey; please don't quote the whole post, it doesn't really tell me anything
I don't really understand: What do you want to know from me/what is your question? ^^
Yes, you can make some values more extreme, but you said you already did (less maintenance, more idle)
Click to expand...
Click to collapse
Hey, I'm really sorry, I'm new on XDA.
I wanted to know why you have some options valued that I don't, like for example:
light_idle_factor 2
sensing_to 0
locating_to 0
and if using them might improve even more my doze.
Also, even if I have Naptime installed, which already improved things by a lot, I wanted to know if some of my values could be improved further to avoid useless maintenances (like I said I have between 4 and 6 maintenances during night, but I barely need 1).
NovaProspekt70 said:
Hey, I'm really sorry, I'm new on XDA.
I wanted to know why you have some options valued that I don't, like for example:
light_idle_factor 2
sensing_to 0
locating_to 0
and if using them might improve even more my doze.
Also, even if I have Naptime installed, which already improved things by a lot, I wanted to know if some of my values could be improved further to avoid useless maintenances (like I said I have between 4 and 6 maintenances during night, but I barely need 1).
Click to expand...
Click to collapse
Doomkopf said:
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Click to expand...
Click to collapse
I linked a xda post that explains every value in detail (first link in second quote/my post);
locating_to and sensing_to: By the pictures (also in second quote/my post), you can see how deep doze works; before going into IDLE mode of deep doze, it goes through a sensing phase (motion detection starts) and locating phasing. Default behavior of doze is to not go sleep when you move the device. This skips this phase (time for detecting motion with sensor is 0). Same with locating; when android notices that you move the device (train, car, ...) via gps (or wifi triangulation, etc) it doesn't go to sleep. This also skips that phase
light_idle_factor 2: This multiplies light_idle_to with 2 everytime if goes thorugh a idle/maintenance cycle until it reaches light_max_idle_to. So this basically doubles your light idle time every cycle until it reaches a max duration (which you can set, I also did in my recommended settings)
In that overview you could also think about how to tweak your values so you get less maintenances during night, as you wanted. Basically you have to make both (deep and light) idle_to's longer. I recommend to increase light idle_to first (more light idle, less maintenance), before going too deep on deep sleep - sometimes your phone needs to do backups at night, etc. Dont be afraid to set a "too large" maintenance window, your phone won't suddenly start to draw much power for nothing. You just have a few seconds/minutes less deep sleep (which is ok, little percentage). Give it something like 2 minutes per night, if you're afraid a backup will take longer, you can even go for 3-4 minutes per night.
Doomkopf said:
I linked a xda post that explains every value in detail (first link in second quote/my post);
locating_to and sensing_to: By the pictures (also in second quote/my post), you can see how deep doze works; before going into IDLE mode of deep doze, it goes through a sensing phase (motion detection starts) and locating phasing. Default behavior of doze is to not go sleep when you move the device. This skips this phase (time for detecting motion with sensor is 0). Same with locating; when android notices that you move the device (train, car, ...) via gps (or wifi triangulation, etc) it doesn't go to sleep. This also skips that phase
light_idle_factor 2: This multiplies light_idle_to with 2 everytime if goes thorugh a idle/maintenance cycle until it reaches light_max_idle_to. So this basically doubles your light idle time every cycle until it reaches a max duration (which you can set, I also did in my recommended settings)
In that overview you could also think about how to tweak your values so you get less maintenances during night, as you wanted. Basically you have to make both (deep and light) idle_to's longer. I recommend to increase light idle_to first (more light idle, less maintenance), before going too deep on deep sleep - sometimes your phone needs to do backups at night, etc. Dont be afraid to set a "too large" maintenance window, your phone won't suddenly start to draw much power for nothing. You just have a few seconds/minutes less deep sleep (which is ok, little percentage). Give it something like 2 minutes per night, if you're afraid a backup will take longer, you can even go for 3-4 minutes per night.
Click to expand...
Click to collapse
Thank you very much, very helpuful!!
Based on your information, I think I understand better how Naptime works. It increases the parameters of Light Doze making them similar to those of Deep Doze, and also increases the duration.
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
tfn said:
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
Click to expand...
Click to collapse
I do use Samsung Routines to Enable Offline Mode and Battery Saving at night, which along with Naptime gives me 2% used battery in 8 hours over night, but during the day I can't find a good usage for it.
tfn said:
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
Click to expand...
Click to collapse
I don't know what it would be easier as; this method?
This basically just configures doze to better fit your needs. It already had values in it before and it was activated before. You can (and should) do all this and still create a routine or mode additionally.
Doze is android's main internal battery saving feature, so tweaking it goes a long way.