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.
Hi everybody!
So I am using CyanogenMod 7 Beta5.1 And I'm having huge battery problems...
It's draining abnormally fast (30% lost during night).
It started to happen when I got problems with my Defy and flashed 3.4.3-11
And now updated to 3.4.2-117.
Before these problems it usually drains only 3% during night!!
Also everytime I boot my phone, when it's completely booted I hear the camera sound (when you open camera app,it makes a physical sound).. It never happened before...
I overclocked my phone to 1100Mhz but I don't think it really affects the battery (when screen off it's set to 500Mhz)
Please help me!....
I was having that problem and I turned fast boot off and it solved the problem for me. The phone doesn't really shut down all the way if fast boot is on.
Sent from my Desire HD using XDA Premium App
schultzy001 said:
I was having that problem and I turned fast boot off and it solved the problem for me. The phone doesn't really shut down all the way if fast boot is on.
Sent from my Desire HD using XDA Premium App
Click to expand...
Click to collapse
fast boot? The one from setvsel?
schultzy001 said:
I was having that problem and I turned fast boot off and it solved the problem for me. The phone doesn't really shut down all the way if fast boot is on.
Sent from my Desire HD using XDA Premium App
Click to expand...
Click to collapse
how can u shutdown fastboot? wanna give this a try...
schultzy001 wrote
"Sent from my Desire HD"
um... a new thread? really?
by the way, i have this problem too since beta 1.. i don't know why..
but i still like it because CM7 is so fast without OC.
i try to compare froyo and CM7, with same apps and same apps settings,
CM7 lost the battery faster than froyo, even when in flight mode.
the strange one is, even the memory usage is so low on CM7 (no motoblur crap),
but why battery still drains so fast..
in battery usage statistics,
on CM7, it shows that "Display" is the one who responsible drinking so much juice (60% and the other is just 3-10%).
on froyo, is not the "Display" which responsible drinking most of the juice, it is "Cell Standby".
i thought gingerbread should have good battery management, and the battery should last much longer than froyo.
i'm sure it is a bug on CM7 for Defy.
but whatever, at least we have a Gingerbread on Defy from a great dev like Quarx.
while motorola working so slow on releasing froyo with its motoblur crap.
Hi guys,
I'm having this issue too, and i note since a few days ago. I don't know why, but my Defy is sucking his battery too fast. Could it be a bug ?
it's a little bit difficult to follow the bugs and the solutions in a huge thread like the other one. so i think that this that could be a mayor problem for all of us should be treated in a differente thread.
I use Motocharge since 1 day to follow how it discharge during the day.
I say it in the other thread, the phone loose a lot of battery when i don't touch it. sometimes it loose like 5% in 15mins and i don't touch it. maybe it doesnt sleep well, i don't know..
I hope that Quarx can solve this, because in the other betas of him i don't have the problem. only in the 5.1.
battery draining
I think It´s a bug, because I used before BETA 5.0 and without any battery life was almost 3 days in normal use, bur now with BETA 5.1 only two days or less.
By the way I´d proved with 3 or 4 diferent roms, but the same result.
But I´m sure Quarx will deleted this bug in the next version
same problem for me,but b3 and b4 is ok
Sent from my MB525
apart from low battery life.....i noticed substantial increase in battery temp..normally its 32-34 deg cel.....but wid CM7 it raises to 42-45 deg cel.....waiting for a solution so that i can come back to CM7...
I use Toggle 2G/3G to switch to 2G when phone goes to sleep. I set wifi to never sleep and use it as much as possible over 3G. I also set brightness levels long time on 16 so that in the shadow I always use just a little energy. This way I almost get double battery live.
+ it's better for battery to charge every night, empty or not, and let it go lower just occasionally.
Link to Toggle app:
http://forum.xda-developers.com/showthread.php?t=739530
yes, this issue is really annoying, 30% battery drain overnight.
something is definitely running unreasonably... hope find it.
I think it depends upon what "type" of defy u have. My battery that only used to last for 12-14 hours in eclair now went for 2 days last 2 charges.
Also depends upon how many widgets and apps u running... hard with mobile phones to judge battery as so many independent variables.
Sent from my MB525 using XDA App
OK Guys, this is an old thread, but I think it should be deleted or at least people should read this before registering this thread in their mind:
The battery drain 'issues' were almost always due to two things:
1- For the beta 6 version or older of CM7- there was a bug with the auto-brightness which was heavily stressing the cpu and making the system lag badly - hence: the battery drain. To fix this: you have to stay on auto-brigthness. So just make sure that the auto-brightness box is checked and ON. Additional info: some users also complained about the 4 action buttons (menu, home, back and search) not lighting up ---> fix: un-check auto-brightness and re-select it: done!
2- Users did not set their Network baseband properly. Fix: use the Defy Baseband Switcher application and select the newtwork that applies to you. If you don't do this, your phone might have signal reception (phone and sms) but it will use more power to communicate and get a proper lock to your phone service provider.
I don't know what is the exact build # that brought the Defy Baseband Switcher (as far as I can remember, CM7 beta 4.1 had it) but all the 'newest' CM7 will have it anyway.
And if you want to further decrease your battery consumption, you can still do it like this:
- use the bootloader cpu settings: OC'ing and governernor type to change the cpu speed. [From CM7 default 1000MHz to the Defy's stock 800MHz] and change the governor type from "interactice" default to "on demand" [OK: I'm not sure about governor change will improve or not but that is the Froyo's default I believe].
- install SetVsel to underclock --> by lowering cpu Vsel upon the 3 cpu frequencies. Do some reading; you might need to uncheck its "[email protected]" option AND also have Milestone Overclock installed for it to work properly.
- USE a recent nightly (post May 29th: there was a possible problem with custom recovery backup restoring prior to that) and you will be able to set your screen display brightness as low as you want [fix the bug described in point 1- above].
- use DroidWall and/or the CM7 built-in applications' permissions control to block some apps' access to internet and networks. BE WARNED though: changing permissions CAN make an application stop working or create problems - don't submit bug reports if you do that.
- Avoid high usage of apps that drain battery quickly (TuneIn radio is power-thirsty one that comes to my mind...) and apps that have to create catalogs and thumbnails (ex: Photoshop, Titanium Backup, Gallery, ...)
- If possible: use 2G network only, disable data synch, auto updates of apps and social networks.
- set your WiFi sleep policy to "Never" [while in Wi-Fi settings, press menu button/ Advanced] and avoid frequent Wi-Fi ON/OFF switching.
- Lower your display brightness and switch that screen off at any chance you got!
There are many other ways I'm sure, but those are the main ones anyway...
I've seen high temps yesterday on my Defy, but I later realized that I forgot to re-set my Baseband after a CM7 nightly install... It 'could' also happen when a (background) service goes "beserk" and overload the cpu: absolutely not necessarily related to CM7 --> faulty apps and bugs happen... Just stop and clear the cache of that app and/or reboot your phone and problem should be gone.
CM7 is now really stable; a VERY FEW little hickups remaining still (like with the camera, but negligeable), but the large amount of new user controls that it brings clearly overcomes the 1 or 2 minor bugs left --> IMO, just having control over each and every applications' permissions justifies forgetting about using Eclair and Froyo. Problems in CM7 are being actively sorted out and new user controls and other useful options are added in almost daily manner through the nightly builds.
I'm categoric: on CM7, I now have more control over where my battery juice goes that I've ever had on Froyo....
So please stop alarming people with high battery usage drainage on CM7 and give it a try by following the right proper steps; I'm sure that you won't regret it.
marhensa said:
um... a new thread? really?
by the way, i have this problem too since beta 1.. i don't know why..
but i still like it because CM7 is so fast without OC.
i try to compare froyo and CM7, with same apps and same apps settings,
CM7 lost the battery faster than froyo, even when in flight mode.
the strange one is, even the memory usage is so low on CM7 (no motoblur crap),
but why battery still drains so fast..
in battery usage statistics,
on CM7, it shows that "Display" is the one who responsible drinking so much juice (60% and the other is just 3-10%).
on froyo, is not the "Display" which responsible drinking most of the juice, it is "Cell Standby".
i thought gingerbread should have good battery management, and the battery should last much longer than froyo.
i'm sure it is a bug on CM7 for Defy.
but whatever, at least we have a Gingerbread on Defy from a great dev like Quarx.
while motorola working so slow on releasing froyo with its motoblur crap.
Click to expand...
Click to collapse
Display instead of cell standby showing up first in battery consumption means that Froyo (or CM7) uses less battery. The display just stayed the same of course, unless it's tuned brighter, the percentage increased because it's a relative measurement.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
*If you find this Guide Thread helpful, feel free to hit the "thanks" button below!
Getting a full day out of your battery isn't something that should be fantasized over, but rather is absolutely attainable with most phone configurations. With following this [GUIDE] you should have no trouble getting more from your Atrix 2's battery life. I will outline several "usual suspects" and "battery butchering bandits" that some may already know of, and some that you might not have ever considered. However, if you try all of these it, may ruin your Android experience because you’ll be constantly fussing with your battery; that's not what this is for. These are ALL the tips/tricks I know. Even I don’t use all of them. Using just a few of these (possibly even one or two) should be enough that you notice an increase in your battery life. So, n00bs and more knowledgeable users can both benefit from this, and for the more resident members here, we've all seen the threads like, “Please help with my battery issue”, “Does undervolting save you battery life” or “Getting horrible battery life”, so this should help give everyone some great ways to improve upon your battery's performance and lifespan between charges.
First off, let me start by telling you all to be realistic. What I mean by that is this: You Atrix 2 is meant to be used! Your Atrix 2 is more than just a phone, it is a pocket-sized computer, an arcade full of your most favorite games, it is meant to be talked on, played with, downloaded to, uploaded from, tweaked/modded/themed/rom'd and everything else that you may desire! So, again, after reading and implementing some of (or all, if you're neurotic) the things I'll outline, hopefully this will alleviate some of the questions you may have as to why your battery performance isn't everything you anticipated it to be. Though, if you think you will get days out of your battery's life by following these suggestions, you're either not using your phone for anything other than holding down a stack of papers, or you're just not being realistic. Will these suggestions help give you more from your battery? Absolutely. I know this is all (well, mostly) very elementary in effort, but overall this WILL HELP you.
*"There are many things to consider when thinking of your battery's performance, such as: Animation Speed. Polling For Notifications. GPS, WiFi scans, Overclocking. CPU/Ram Usage, Proper Sleep, Widgets, Brightness, 2G/3G/4G Data Usage, Call Time, Text Volume, just to name a few ~THESE are the things that really affect your battery life. The bottom line is, if you truly want to save battery you are going to have to get your hands dirty... there simply isn't a "one-click" (or one-flash) solution."
*STANDARD DISCLAIMER: I cannot be held responsible for any and all damage related to Hardware loss or Data or Software, which the user might cause while attempting these procedures. Additionally, I am taking the liberty to assume that anyone who attempts these procedures understands the potential risks involved. Though, there should be no such issues to arise from following this guide, I am still exempting myself from any liability.
---For All Users (Rooting Not Required)---
1) Turn Off Your Radio(s) When Not Using Them:
Radios are what connect your phone to the rest of the world. You have your general mobile connection, WiFi, data/internet connection (3G), GPS, and/or 4G. Those are listed in order from least to greatest in battery consumption. If you’re not using the radio turn it off. If you know you won’t be online for a long time, why turn 3G data on? If you’re at home, use WiFi instead of 3G. If you’re not using Google Maps why is your GPS on? You’d be amazed at how much battery life you can save just by turning off the radios that you aren’t using.
2) Vibrate Uses More Battery:
Anytime your phone vibrates a lot of battery is used. This include haptic feedback. A lot of keyboards have the option to turn off haptic feedback and I would recommend it. If you’re a heavy texter you’ll notice very quickly how much longer your phone will last. Also, if you’re in a place where you can easily hear your phone why do you need to have vibrate enabled? If you know you’ll be able to hear your phone there’s no reason for it to be buzzing too.
3) Don’t Use Task Killers:
Crazy, right? Android has it’s own task killer that’s actually very good. If programs are using too much memory your Android OS will kill it. A common misconception is that apps run in the background forever; this is not true. If an app is using too much memory (which links to battery life) it’ll be killed by your phone. That’s why if you play a game, check a message, and come back the game is still running. It’s memory usage isn’t that high. However if you put your phone down, walk away for an hour, and the game is still trying to run in the background, there’s a good chance it will be closed before you come back. Separate task managers have to constantly be running in the background which can actually use more battery than it saves. Yes, task managers can use more battery than claim to save.
4. Power Cycling:
Not sure about the real effectiveness of this charging policy, but some users have tried it and have claimed to have had good results from it. So, to begin with the phone in the on position, fully charge the battery with the phone on. Once your Atrix 2 is fully charged, unplug the charger until the led goes off. After the led goes off, plug the charger back in. When the led turns green , power off the phone. Now, with the phone fully powered off, 1) Unplug the charger. 2) Wait until led goes off. 3) Plug charger back in until the led turns green. When it turns green, unplug the charger again and go to step 1). Repeat steps 1) and 3), 10 times. This may take anywhere from 30 seconds to 30 minutes per cycle. Typically only about 1 minute though. It takes too much work for me, but I’ve done it once just to test it.
5) Don’t Use Live Wallpapers:
They look awesome, right? They also use a lot of battery (especially the more complex ones). We’ve all used live wallpapers to show off how cool our phones can be, but for daily use they can KILL your battery. Also, your animations will be a factor in diminished battery life expectancy. To adjust this, simply navigate to: Settings>Display>Animations>set to "Off or Medium". #1 when it comes to what is eating your battery, is your display. It always has been and always will be, so accept it and try to do something about it. If you don't believe me, go to your Settings>Battery> and see just how much percentages the screen takes up. But, you want to do something about this, right? This part is easy. Just lower the brightness. You can set it to a brightness that is low but you are still able to see well enough to function. Live Wallpapers fall into this category. They are cool to look at but static ones take up less RAM and also less display because they are not running all the time in the background. These screens are very bright at 100%, so tone it down.
6) Watch Your Applications:
You have to pay attention to your applications. I repeat. You have to pay attention to your apps! Especially if they run in the background. This can be anything from a harmless .99¢ game to a monster like a Live Wallpaper. The battery drain threat is twofold here because the application is running in the background but it could also be using its anonymous data collection abilities and sending that back to the Mother ship. Ever wonder why your signal bars in the status bar have arrows or other animations going back and forth when your phone is just sitting there? This is because some application is transmitting data, whether you are using it or not. There are apps in the market that monitor these situations like Watchdog Task Manager Lite or you can adjust app permissions like LBE Privacy Guard. Data transfer is #2 on the "What Kills My Battery" list.
7) Worthless Widgets:
They look cool. But widgets are nothing more than RAM and battery hungry monsters that you purposely put in your home screen. Think about it. What does a widget really do? All it really does is monitor an app that you have running. So not only is it running and taking up battery and RAM but the app that it is linked to is running in the background a la Facebook, Twitter, Google+, CNBC, MSNBC, BBC, …the list goes on and on because they want us to put THEM on our home page. What a great marketing campaign the widget is: "Hey, look at me new home screen!" "Cool. Hey what widget is that?" "Oh, it is (whatever widget)." "Nice, I’ll have to download that tonight when I get home." Right then and there, they have you and your battery. If you're serious about getting the very most out of your battery, get rid of the widgets. I know, they're hard to resist, but trust me, your Atrix 2 will be a better place if you want the most out of your battery.
8) Set Your Screen Timeout:
Some phones start with their screen timeout at 3 minutes or more. That’s completely unnecessary. While you don’t want it to be instant, you know your preferences. Set it to as low as you see fit. The sooner your screen goes off, the longer your battery life will last. I set my screen timeout to the lowest "never" -but, in doing so, every time I am done checking emails or sending a text, I kill the display with the power button to turn off the display. This takes some habitual conditioning, and if you're used to allowing your phone the responsibility of turning off the display for you, it might bode well for your battery capacity crusade to simply adjust this to the minimum. But, if if you're like me and like 'control' over your display, I recommend you still set the timeout to the lowest possible setting, in the event that you forget to manually shut the display off yourself. It's just good practice when going for battery life longevity.
9) The Charger, and What You Can Do Regarding it:
Using certain chargers causes a wakelock on your phone that prevents it from going into deep sleep. This can result in roughly 10% battery attrition, regardless of activity or screen on time. Before you try anything else, you should test each of your chargers and make sure they aren’t causing a wakelock. Though this shouldn't be of concern if you are using the stock wall charger that came when you purchased your Atrix 2, there are other aftermarket ones that you may not suspect as reasons to worry about charging your phone with. If you are not using the stock charger, and you suspect you may have a problem, or may be curious to find out: Install CPU Spy from the Play Store. Open the app to see how much time your phone spends in each CPU state. If Deep Sleep is a very small percentage, or Deep Sleep doesn’t even appear, you have a problem with your charger. Or, follow the method below to test each of your chargers:
Testing CPU Spy:
1) Plug your phone into the charger and turn the screen off. Leave it charging for about 30 seconds. (Don't do this with a fully charged phone, as I don't know how that affects the testing)
2) With the screen still off, unplug the phone from the charger.
3) Open CPU Spy, hit the menu button, and "Reset Timers". Turn the screen off.
4) Let the phone sit idle for a few minutes with the screen off.
5) Turn the phone back on and refresh the timers in CPU Spy (menu button again).
If Deep Sleep doesn’t appear in the list of CPU states, your phone is experiencing a wakelock brought on by the charger. It’s probably spent the majority of time at 192mhz or 384mhz. To further confirm this, leave your phone unplugged, restart it, leave the screen off for a few minutes, and then check CPU spy again. You should now see it going into Deep Sleep.
10) Your Camera Flash and Battery Don’t Get Along:
If you like using your camera LED for a flashlight realize that will absolutely MURDER your battery. In all seriousness, your flash uses battery more than any other process on your phone. Turn off the flash. Don't set it to "automatic", you should know when you will need it and when you will not. By setting it to "automatic" you're relying on the phone's light meter to determine if the flash is needed. Sometimes it is, and other times it isn't.
11) Low Cell Signal Hurts Battery
Your phone is always searching for a stronger signal…This process gets more hectic as the cell signal goes down. So if you’re at one bar your phone’s battery life will drop faster than if you’ve got full coverage. There’s not much you can do here, but if you’re in a place where your phone has little to no signal anyway, you probably won’t be making calls so you might want to just turn on airplane mode or your phone off. And with Airplane Mode, you can toggle the airplane mode on/off 3 times in a row, that will reduce your Cell Standby battery usage. It should only be necessary to do it once after flashing but if you think Cell Standby uses too much power at some stage, you could toggle again the airplane mode 3 times. This is a handy little trick, not well known, but should give you some relief with Cell Standby usage. I travel for my job, which means that at times, I do not get good reception, or bounce around between Edge/3G/4G, and each time that happens, your Atrix 2 is sucking more juice by trying to find a good signal. If you are not in a static network, meaning one that is either 3G/4G at any given time, without locating off-network tower connections, turn your radio off or switch to Airplane Mode.
12) Speaking Of Syncing…:
Check your settings to see what is syncing and when. You probably have things syncing you don’t even use (stocks, news, contacts, etc). You can turn those off and edit the other ones. I don’t need my contacts’ statuses every hour, so my facebook sync is scheduled for once a day rather than the old once an hour. Find out what you need and how often you want it, and turn the rest off. I know you are very important and you need to know what LeBron James is doing right now, or that you need to upload a picture of you and your girlfriend every time you two are at a party, drinking beer. That is fine and I applaud you for it, and will probably download the picture and Photoshop myself in your place. This is not the problem. Syncing your accounts is. That is what is causing battery drain. Do you really need to have your FB widget (see widgets section) streaming all day long? I doubt it. Kill it (not LeBron, but rather the auto-syncing). Every time you “friend” someone their numbers, contact info gets sync’d to your phone. Also, there are settings in Facebook, Twitter and Google+ that you can upload pictures instantly. Don’t do that. Once you do, it is out in the Ether-World and just swallowed a bunch of battery doing it too. Settings>Accounts and Sync>Auto-sync>uncheck it
13) Don’t Use GPS Unless You Have To:
Some apps give you the option to precisely determine your position using GPS, or make a general estimate (usually within 100 meters) based on WiFi or 3G data. While this isn’t always the best (like if you’re driving or getting navigated), try to use the 3G connection when it doesn’t really matter. The data radio uses far less battery than GPS.
14) We're Gonna Need A Bigger Boat, erm... I Mean Battery:
If still not completely convinced that you have have stellar performance from your stock Atrix 2 battery, you can always check out the Atrix 2 Accessories threads for suggestions and/or discussions on extended capacity batteries. I've never used one myself, but don't see as to why this wouldn't certainly add to your life expectancy of your battery -assuming you're choosing foregoing the suggestions above, and simply insist on having your widgets and eating them to -or your battery, for that matter. Nonetheless, there are several manufacturers that supply an aftermarket extended capacity battery for the Atrix 2, just use your pal Google to help you find one.
---For All Users (*Rooting Required)---
*FOR ROOT USERS: If you’ve rooted your phone you have a few more options. You don’t gain too many more options, but they are even more effective than the ones listed above.
Underclock Your Phone:
Just like SetCPU can overclock your phone, it can underclock it as well. Set it to underclock when the phone is sleeping or even lower the max clocking speed. This will give your CPU's scaling frequencies a lower "resting" point, and will not allow the load of the CPU to be any higher than the maximum setting you permit. I know everyone who likes to get their hands into the belly of their Atrix 2 and start tweaking it loves the idea of overclocking, but c'mon, you don't have to run your CPU at 1.3GHz all day, everyday. Scale that baby down when you don't require such a high CPU load, and trust me, your CPU and your battery will thank you. Also, along with underclocking your CPU, you can undervolt as well. This will allow (after some testing you'll need to do first to make sure you're not undervolted too low for stable CPU loads) for your Atrix 2 to run at a lower voltage consumption, and with these types of settings, you can allow your Atrix 2 to run at your desired CPU frequency scaling, but a slightly lower voltage rate. *Note: As aforementioned, some testing is required for this to be effective with both your CPU's table values, as well as how it may improve your battery's life. Also, please reference This Thread for the latest kernel/module overclocking and undervolting methods.
Wakelocks That Destroy Your Battery Life:
If you're not familiar with wakelocks, they're basically processes that run on your phone that prevent it from going into deep sleep. Deep sleep is the mode your phone should go into when you're not using it so that it can conserve battery. Some wakelocks are intentional, while others can be the result of rogue apps or system processes. If you're trying to maximize your battery life, you know this already. Some wakelocks are happy, friendly things, but many are silent leeches, sucking away your battery life while you remain blissfully unaware of what's happening. First off, you have to understand the difference between kernel wakelocks (KWL) and partial wakelocks (PWL). KWLs are wakelocks caused at the kernel or hardware level. Some of these are benign, and some of them are vampires. The only way to solve them is to change how your phone behaves. To effectively find your wakelocks, you'll need Better battery Stats It's free to us XDA users. You can get it IN THIS THREAD. More on wakelocks can be found in the post below.
Use SetCPU:
Create a special profile that forces the device to run at low clock speeds when the display is off.
Go to profiles
Check Enable
Press Add Profile
Set the following:
Condition: Screen Off
Max: 600MHz Max
Min: 300MHz Min
Governor: ondemand
Priority: 50
Press Save
On the Main tab make sure you have
Max: 1000MHz
Min: 300MHz
Governor: ondemand
Scheduler: deadline
Clean Out the Bloat:
Some of the bloatware and unnecessary applications on our Atrix 2's can drain battery. I really recommend you freeze the applications by using Root Freezer and run your Atrix 2 for a few days after you have frozen an unwanted application, and certainly before you decide to uninstall. This way you won’t accidentally uninstall something your phone needs to remain stable. Albeit, most of the custom roms that you will see here are already "de-bloated", if you're new to rooting and Android, and haven't quite decided that taking the next jump to flashing roms is for you, use Root Freezer to "freeze" applications that you suspect are bloat, until you decide to run a de-bloated ROM -and you will, eventually...
The Stock ROM Sucks:
If you’re still unrooted and on stock Gingerbread, I feel sorry for you. What the heck are you doing on this forum if you’re scared to flash a new ROM? This guide would be way too long if I tried to explain the battery improvements you might see by stepping up to the Stock ICS leak. You’ll probably see even more improvement if you flash one of the many custom ROMs in the Development section. If you’re dedicated to getting the most out of your phone, spend a weekend reading the ever-loving crap out of the stickies in the Development forum, and the [ROM] threads. Only after you have read those threads and feel like you have a good understanding, backup your phone and flash a new ROM on it. As long as you’ve backed up properly, you can flash between several ROMs and choose the one that works best for you. If you have any questions about the ROM you’re trying to flash, ask in that ROM's specific thread, don’t start out by creating a new thread in the General Section. You did do a search first, right?
Lost DIR Liability:
Let's say that you have your phone plugged into your PC and for some reason you, in a fit of rage, jerk the plug out without unmounting it first. This creates a file that is put into your LOST DIR folder on your SD card. Anytime you don't safely unmount the SD card, it will create a file in that folder. In the scheme of the SD card, it isn't too much, but I don't like having useless items free floating about. Clear them out using Root Explorer or a like Root File Explorer, and this will free up some (depending on how many times this has been done) valuable memory real estate.
Tombstones:
So you are downloading an update from the market and for some reason your phone freezes and the Force Close-Retry-Wait doesn't work out for you. You have to do a battery pull. Frustrating I know and the memory takes a hit too. Every time you have to do a battery pull because of a freeze up or something of the like, it creates a TOMBSTONE file in /data. These are useless and can be deleted. If you are flashing ROMs and are constantly having to do battery pulls b/c market crashes or an app freezes, then you are creating a Tombstone file. Here is where your file manager (with root) will help. Go into /data and scroll all the way to the bottom and open /tombstone. There should be some files in there and depending on how many there are, I could be a nice chunk of wasted memory. Just select all and delete. They are not needed. Your internal memory should go up by doing this.
Lost & Found:
Same scenario, but now go into /data/ cache or /cache and you'll see Dalvik Cache (don’t mess with this), Lost & Found and Recovery. If you tried to download an app and it got frozen for some reason and had to do a battery pull, the apk will be free floating in there, uninstalled (free floating radical). You can delete this. While it isn't in the Dalvik Cache folder, it is taking up space. Once you are able to download something completely and correctly from the market, it will populate into Dalvik Cache correctly and won't be a free radical, as I like to say.
---For All Users (Miscellaneous)---
Some More Memory Clearing Tips:
Home Launcher:
If you have a 3rd party home launcher, see if it has the ability to long-press an icon to take you to its screen in the Manage Apps section. I use ADWex and if you long-press on say Market, it takes me to the same place as is I were to go to Settings>Applications>Manage Apps>Market. Instead of all that, just long-press on the icon and BAM! it takes you there. Here you can clear out your cache for the market or delete the data (if you need to do that). Or clear the cache of the XDA app because you looked at too many posts with pictures, etc.
Browsers:
These develop cache that takes up memory and space, especially the stock browser. If you use a 3rd party, you can get the settings to clear cache, cookies, passwords,…on exit. I use Dolphin, but I am pretty sure that most have something like this on them. (side note: most 3rd party browsers once exited will not run in the background unlike the stock one)
Media:
So you download a bunch of mp3's from the internet or you've clicked on some pix and saved them to your SD card. Or maybe you just felt like wiping your card and having a fresh start. Every time you reboot, you phone will scan media. No big deal, but the more you criss-cross things from PC to phone and back again, it can create a bunch of double files in your media cache on the phone. With the proper placement of .nomedia files (this prevents your media scanner from doing just that, scanning media- i.e. pix, jpegs,…Don’t place a .nomedia in your music, album art or DCIM files**bad). Every once in a while, I'll hit the Diskusage or go to Manage apps and clear the media cache. Then I got to my file manager and the DCIM->Thumbs and delete the thumbnails files (should be 2). Unmount the SD card and remount to start the media scan, pull up the Gallery and wait for the thumbs to come back (depending on how many you have, this could take awhile). By doing this you can get almost 5 mb back if you have a bunch of double scans in your media folder.
Applications That Use Advertisements:
Try to avoid ad-supported applications, if you can. A research showed that in apps where there is adds, 70% of the power use comes from downloading and managing those adds to your screen. With just a 30 second use of an application that uses ads, it might drain your fully charged battery anywhere from 0.35% to 0.70%, which is enough to completely discharge the battery within a couple of hours if the process is repeated. This, according to a team of researchers, show that applications using advertisement support can take a high toll on your Android smartphone’s battery. The researchers analyzed how Android apps use the battery and concluded that the ad-serving processes that run in the background are responsible for heavy battery drainage. This may not seem like much, but so many applications that are free utilize advertisements and are blasted about the bottom or top of your application. I know I'll likely get ostracized for mentioning this, at least by some of the developers who rely on ad-support within their applications, but there is a way to eliminate these ads from showing themselves in your application(s). This is for BOTH rooted and un-rooted devices, as there are applications available from Google Play Store, such as AdFree Android (for ROOTED users only) or you can find one that will work on a non-rooted device. Or better yet, you could pony up the nominal dollar or two and show your own support for your favorite applications by buying the paid version, and thus eliminating the ads in that manner.
*I will be updating this OP as I see necessary, and if anyone has useful tips that I may have missed or overlooked, please let me know. I'm aware that there are threads of this capacity floating about through XDA, but I have taken the liberty to create on specifically for our community.
Credits & Big Thanks To: Woodrube
Wakelocks Explained
Two final notes before I get started with the Wakelock Portion of this guide: Do not go wakelock hunting right after installing a new ROM or clean-wipe reinstalling your current one. New ROMs cause the phone to go nuts for a little while, as things decache and little behind-the-scenes tweaks are made. Wait one full battery cycle (100% to 0%, which you're probably doing to calibrate after a clean ROM install anyway) before trying this, or you'll drive yourself nuts. Also, remember that solving one wakelock will often create another, especially early in this process. That's normal and to be expected. God does not hate you, your ROM of choice is not crap, your phone is not glitched, and a clean install while your current ROM is still settling in will only make things worse.
So, how do you track these wakelocks down with BBS? This is a really complicated procedure, so make sure you're with me. First, open BBS. Then, see the drop down menu at the top that probably says "Other" right now? Tap it, and then you'll see "Kernel Wakelocks" and "Partial Wakelocks" below. That was obscenely difficult, right?
There are a couple of other features of BBS that we'll make extensive use of later, but there's one you need to know right now. Tap your phone's menu button to get the BBS menu up. Tap on "More". See the button that says "Set Custom Ref."? You'll need it--you'll need it a lot.
Last, but certainly not least: modifying your system in any way, including altering or deleting processes needed to resolve wakelocks, can have unpredictable results. Use caution and make backups of your apps and data, as well as nandroid backups, frequently while finding and eliminating wakelocks. Any modifications you make are done at your own risk, and I assume no responsibility for any damage you may do to your phone while cleaning out wakelocks.
With that said, we'll get started with the KWLs, as they're the trickiest to get rid of. Use the guide below to identify your wakelock, what is causing it, and how to get rid of it.
KERNEL WAKELOCKS
wlan_rx, wlan_rx_wake, wlan_wake: This is a wakelock caused by network traffic. The easy solution would be to just turn off Wifi, but be careful doing so! If an app goes to sync and it sees that Wifi is off, it will search for a mobile data connection (which causes the ConnectivityService wakelock). If it can't find a mobile data connection, it will wait and search again at its next sync interval and/or automatically sync when the phone wakes up. This wakelock can also, deceptively, be caused by the Wifi network itself as it refreshes connections or refreshes IPs.
To fix: This is a tricky little sucker to fix, as there are so many possible causes for it. Airplane mode is a safe bet--syncing apps seem to "respect" airplane mode, whereas if Wifi alone is turned off, they'll just try to find a way around. But then, of course, you lose your ability to talk on the phone. If you're particularly unlucky, your Wifi network itself will be the problem.
PowerManagerService: This is probably your #1 or #2 kernel wakelock, and you'd probably love to get rid of it at all costs, right? Hate to say it, but there's not much that can be done about this one. PowerManagerService is a KWL that serves as a "catch-all" for your PWLs. It's a placeholder, nothing more, nothing less. Don't spend much time worrying about it.
To fix: Reduce PWLs. See below.
deleted_wake_locks: Remember what I said above about force-stopping an app and deleting its cache and data before uninstalling it? This wakelock is why. It's the PowerManagerService for deleted apps. Once the app is gone, the wakelocks it caused suddenly become unknown to the system, so they get lumped in here. This number can also go up as the system "looks for" deleted apps and/or finds more wakelocks associated with them, but not dramatically.
To fix: Make sure to force close apps and wipe their cache and data before deleting. A reboot should eliminate the wakelock entirely. If it's still showing up, wipe phone cache and Dalvik.
sdio_al: This is an annoying wakelock, as there are two potential causes for it. One's easy, and one sucks. The easy one is that you've fallen victim to the charger wakelock. If your charger shows up as AC Regular Charge, there's your problem. If it's AC Fast Charge or USB Normal Charge, your wakelock is caused by your SD card. That can be an irritating fix, but the SD card version of this wakelock is typically small enough that it's not worth addressing.
To fix: Check your charger and adjust if needed. If it's the SD card, it's probably not a strong enough wakelock to be worth fixing, but if you want to fix it, you'll have to format your SD card. If formatting doesn't work, format it again, then wipe cache and Dalvik.
alarm_rtc: This is your phone's internal alarm scheduler, set to wake up your phone for sync, push, etc. Closely related to the AlarmManager PWL.
To fix: Check your apps and make sure they're only set to sync when you want them to, not for constant push or stupid-short intervals.
mmc0_detect, mmc1_detect, mmc2_detect: I'll be honest, I have no idea what causes these. Fortunately, they seem to be minimal, so I've never wasted much time worrying about them.
To fix: Good question!
vbus_present: This is a weird one. I never could quite figure out what causes it, but it seems like it's there as long as the phone's plugged it. Strange...
To fix: Check your phone. Is there a cord plugged into it? If so, does that cord lead to a source of power? Like, I don't know, an adapter plugged into a wall socket? That's your root cause. vbus_present is a completely harmless wakelock, which will appear for as long as your charger is plugged into your phone. Set a custom reference point in BBS when you unplug, and you'll note that it's magically disappeared.
There are a number of other, lesser KWLs that I'm not going to worry about here because you shouldn't worry about them either. You might occasionally see a battery cycle with very low (sub-1%) KWLs, but that's the exception and not at all the rule.
PARTIAL WAKELOCKS
PWLs are a different beast. These are almost all caused by an app (with a couple of notable exceptions). For that reason, I won't go in-depth on too many of them, as the solution is usually to delete the app causing them. There are a few notable ones, and a few apps that merit mention.
AudioOut_1: This is an evil leech of a wakelock that will drain you dry if given the chance. For being such a pain in the app, it's surprisingly easy to get rid of. This wakelock is created whenever the phone's speaker plays a sound. With 99% of sounds, it goes away almost instantly. With keypad sounds, however, it doesn't go away so quickly, and it will sit there draining your battery for as long as it goes unnoticed.
To fix: Open Settings, then select sound. Turn off key tone sounds, touch sounds, screen lock sounds and vibrate on screen tap. It'll take some getting used to, but the extra battery you'll coax out just by solving this ridiculously simple problem is more than worth it. See DoctorQMM's post (#5), linked at the end of this one, for info on additional causes of this wakelock and how to fix them.
ConnectivityService: This will appear whenever your phone is trying to connect to a mobile data network. Excessive wakelocking here suggests that your phone is having a hard time finding a network, and an even harder time staying on it.
To fix: Test out different radios and see if one's better in your area. If you're able to control your radio bands and you don't live in an LTE area, setting your phone to hunt for GSM/HSPA connections only can save you a little bit of juice here. Not much, but every drop counts, and if you're not using LTE anyway.
AlarmManager: This isn't a wakelock unto itself so much as it's a compilation of app alarms and the time they held the device awake for. Seeing the wakelock alone doesn't tell you much, but here's where one of those features of BBS that I said we'd be using comes in.
To fix: Open BBS. Tap the menu button, then "More", then "Raw Alarms". That will show you which apps are waking up your phone, and how often they're doing so. Google will have a ton of wake-ups, but they're mostly innocuous. We'll discuss some of Google's problem apps later. Email clients will also have a ton of alarms. If anything else looks out of whack, though, first check the app settings to see how often it's refreshing. If the app is set to refresh every hour but it's set off 400 alarms in the last 30 minutes, get rid of that sucker and email the dev. You can't eliminate this wakelock, and it's constantly my #1 PWL at this point, but you can minimize it.
MediaScannerService: This is a wakelock created by the system as it scans your device for music, movies, pictures, etc. Once in a while, it will randomly get hung up and hold the phone at 384 MHz for...well...until you notice and do something about it. Like AudioOut_1, this is a heavy-drain wakelock. Luckily, like AudioOut_1, it's almost always easy to fix.
To fix: Reboot. Ninety-nine times or so out of a hundred, this solves the problem. If the problem persists, go to Settings>Applications>Running then tap on "Show cached processes". Find the Media process and stop it manually to kill the wakelock. That's a short-term fix, though, as a persistent wakelock from this process most likely means you have a corrupt media file somewhere on your phone- and there are a lot of sounds, movies and images on your phone. This is one of the few wakelocks that, if it's a regular problem, justifies considering a full wipe and clean reinstall. That's not because it's doing any kind of damage to your phone, but more because sifting through every single media file on your phone to find the culprit isn't really a practical solution.
SyncLoopWakeLock: This is exactly what it sounds like; your phone is being held awake while apps sync. There are two possible causes for this: apps syncing (duh) and a bad data connection.
To fix: Open BBS. Tap the menu button, then "More", then "Raw Network Stats". This will show you which apps are using the most data, and help you narrow down possible culprits. Once you've done so, check those app settings and make sure they're not set to constantly push notifications, refresh every five minutes or anything dumb like that. If they're set correctly and still holding sync open that long, try downloading the Speed Test app off of the Play Store and test your phone's connection. If your connection is on the slow side, it's possible that the apps are struggling to sync because of your bad data connection. Try flashing different radios to see if that solves it. If the troublesome apps remain so after you've found a better radio, it's best to just delete or freeze them.
GTALK_ASYNC_CONN family: Despite its name, this wakelock doesn't seem to be directly related to Google Talk. How do I know? I haven't had Google Talk on this phone in over a month, but the wakelock still pops up from time to time. These wakelocks can be absolute destroyers of your battery if given the chance, and unfortunately, there's no known root cause for them, and no reliable way of eliminating them.
To fix: These wakelocks will often disappear within a minute or so of generating. If one becomes persistent, reboot into recovery and wipe cache and Dalvik ASAFP. That solves the problem temporarily, but it will reoccur. Thanks, Google.
NetworkLocationLocator: What a lovely name for such a lovely wakelock. It's a minor annoyance usually, nothing more. If this one is persistent, it's because you're in an area with crappy cell coverage and very few Google-mapped WiFi networks.
To fix: Why, exactly, are you leaving Network Location on all the time anyway?
SCREEN_FROZEN: Uh oh.
To fix: If this is high on your list, you've got bigger problems than a wakelock.
PWL OFFENDING APPS
We're almost done, I promise!
Down here, I'm going to list off for you apps that will cause you severe PWL migraines, and what to do about them.
A note when uninstalling Google built-ins: Google built-ins are often system packages, and deleting them can have unpredictable results. I highly recommend freezing them in Titanium Backup for several days to see how the phone runs before uninstalling them through there as well. Deleting system processes is inherently risky, and I assume no responsibility for your own decisions.
Facebook: Any social networking app will want to sync as often as it can, but you can overrule that by setting notification intervals. Thing is, Facebook doesn't respect those intervals, and wakes up the device for data exchanges pretty constantly (even though your news feed may only update every hour or so when you want it to). This app is no better than bloat, and should be treated as such when you clean house.
Alternative App: Friendcaster. It's as good a third-party Facebook client as you'll find on Android, and it only wakes up when you tell it to.
Gmail: A running theme here will be that if there's a non-Google equivalent to a Google app, you should probably kill the Google and download the alternative. Gmail is an alarm fiend, and one of the main offenders if you have an excessive SyncLoopWakeLock problem.
Alternative App: How many email clients are out there? I've had the best luck with the stock Email app, but K-9, Kaiten, MailDroid, even Enhanced Email and Touchdown for the power users are all great alternatives. Speaking of which...
Whatever email client you're using: Email clients will always be high up on the list of alarms, and that's by their nature. Keep an eye with raw network stats on how long they're connected for, and don't be afraid to experiment. I tried K-9, Kaiten and MailDroid before settling back on the stock Email app as the one that gave me the best balance of battery life and necessary features.
Alternative Apps: Download and try out different clients until you find the one that works for you. Nothing ventured, nothing gained, right?
Google Latitude: Latitude is a tracking service. As such, it tracks you. Beyond the creepiness aspect of that, it holds your phone awake pretty often while doing so. Kill it. Kill it with fire.
Alternative App: Personally, I'm not into the whole stalking thing, but I've heard that Glympse works quite well.
Google Maps: Colossal waste of space and battery. You can do better. An important note on Google Maps: this app will still wake your device up even after being frozen in Titanium Backup. I don't know how it happens, but it does. To truly solve the alarms from Google Maps, you have no choice but to uninstall it. Do so at your own risk.
Alternative Apps: I'm a fan of Waze for navigation and MapQuest for a Google Maps-ish "browseable" interface. OSMAnd is also a great alternative, but it uses a ton of internal memory because of its offline nature.
Google Play Music & Movies: Updates itself constantly and wakelocks. Even if you freeze it, it still somehow manages to tell you that there's an update available. It's the Google zombie.
Alternative App: There are literally 100+ music and/or movie players out there. I'm sure you can find one that works for you. I'm a big fan of RocketPlayer for music, and I just use the stock video app more often than not.
JuiceDefender: What's that you say? JD sets off tons of alarms and holds the device awake for more time than I'd care to discuss, largely because of its data control settings. More harm than good, in my opinion.
Alternative Apps: JuiceDefender's main goal in life is to minimize the amount of time your device is held awake. Therefore, if you've just gone through all this to clear out wakelocks, do you really need another wakelock-prone app to do what you've already done?
Skype: Occasionally, after a call, Skype will wakelock. This is not designed to happen, and is more a glitch in the app than a forced sync. Force-stopping the app and clearing its cache have solved it for me on the rare occasion that I've seen the wakelock occur.
Alternative Apps: No idea. I don't personally consider this a "replace" situation.
That's the bulk of what I've learned from clearing out wakelocks. Remember how, early on, I specified that the search engine of your choice was the third tool? Simple fact is, I haven't installed every app on the planet, so I haven't seen every PWL out there. Because of the way my phone's set up, there are KWLs that I've never seen and never will. If you've got a pesky wakelock that won't go away and it's causing noticeable battery drain, Google (or Bing, or Ask.com, or whatever) is your friend. Good luck, happy hunting, and enjoy the extra battery life you'll get just by spending a few hours over the course of a few days tracking down and killing those wakelocks.
Credits & Big Thanks To: T.J. Bender
A Little Charging Trick
If, after rooting or more likely that case after flashing a new ROM, you often have battery reporting errors, and re-calibrating the battery along with some steps I will outline for you below will ensure that your battery is getting a full charge, and the battery reporting accuracy is right on. I run my device's CPU governor in performance mode all the time, and with a CPU overclock of 1.25GHz and various tweaks, I have about a day and a half - to a day and a quarter of full run time from my battery. This is with moderate usage (calls, emailing, text, gaming, web browsing, etc.) so you should have no problems getting acceptable battery performance after following these steps, coupled with the ones I've given in the OP:
1. Take the case off your Atrix 2 (one of the latter steps involves taking the battery out from the phone while it's plugged in. Make sure your case won't stand in the way.)
2. Install Battery Calibration app from the market
3. Plug in your Atrix 2 to charge while it's on, wait till it gets to a 100%
4. When the charge is 100%, open the BatteryCalibration app and lookup what the charge is in MV while at 100%. Write it down.
My Atrix 2 was showing ~3400MV while at 100%, which is definitely not the maximum capacity.
5. Discharge your Atrix 2 completely until it shuts off.
A good way of doing this quickly is by turning on wifi, and a video player.
6. Without turning on the phone plug it into a wall charger and let it get to 100%
7. When it's at 100%, without unplugging it from the wall charger, take off the battery cover, and take the battery out.
Your phone will "reboot" and show a Missing Battery icon.
8. Without unplugging the phone from the wall charger or turning it on, put the battery back in and wait until the phone recognizes the battery.
9. Your battery should now be recognized by the phone, and showing a charge % significantly lower than 100%.
Mine showed only 5%.
10. Let it sit there charging for 2-3 hours (or more).
My phone wouldn't charge past 10%, but yours might. The numbers don't matter much as the phone is definitely getting additional charge that could have been lost while flashing ROMs, etc.
11. After 2-3 hours (or more), turn the phone on while holding the volume down button and get into CWM.
Do not disconnect it from the charger still!
12. Wipe battery stats in CWM, reboot.
Do not disconnect it from the charger still!
13. When the phone turns on, go into Battery Calibration app again and look up your MV numbers -if you were like me, they should be significantly higher than before. After this whole process I had 4351MV at 100%, comparing to 3400MV before calibration.
Do not disconnect it from the charger still!
14. Before going to sleep - Install Watchdog Task Manager Lite from the market. Go into it's preferences, set CPU threshhold to 20%, check "Include phone processes", check "Monitor phone processes", check "Display all phone processes", set system CPU threshhold to 20% as well.
Do not disconnect it from the charger still!
15. Make sure your wifi and data connections are off. Now finally unplug the phone from the charger.
Go to bed, let your phone sleep too.
16. Success! Next morning check where your battery % is at and if you followed the instructions correctly / got lucky like me, your battery life should be 90% or more.
I went to bed with 98% and woke up to 94%. So, I consider this mission a success.
NICE JOB!!!!
Sticky... I will ask...
Nice Guide just fixed minor things and my battery is already better!
Sent from my locked MB865 on Ice Cream Sandwich.
temperature
what causes battery temperature rising ? oc? data? games?
cause i've noticed that battery drops horribly on graph when temperature increases
shardul.phatak said:
what causes battery temperature rising ? oc? data? games?
cause i've noticed that battery drops horribly on graph when temperature increases
Click to expand...
Click to collapse
Battery temperature is a direct result of device usage. If you go to sleep at night, and are NOT charging your phone overnight, in the morning when you wake up and roll over to check xda or Facebook or whatever, the phone isn't warm, right? During the day, if you're running a browser or streaming music or just have a lot of screen time on, your phone will get warmer and warmer. It's hard to say without seeing any test results from your phone as to what is causing higher temperatures, but it's safe to say that any or all of the things you listed could be a cause. Obviously, overclocking WILL cause your phone to run warmer. Your permitting a higher CPU load value at the maximum frequency scaling, and subsequently your phone's CPU is working harder. Try some (or most) of the suggestions in this thread and see if you notice a lower temperature and battery drop as a result of the changes...
Great guide mister strider!
Motorola lied and I'm still locked mb865
Nice! Thanks for putting this together, Apex... Keep on striding, man!
Apex_Strider,
Can you tell us the final result when you applied these trick on your phone ?
Mine was not used any above, and gave me ~24hrs with heavy use, wifi on 24/24, screen on 5h using wifi. Phone for 15 mins/day, sometime movies for 2hrs.
I charged it at 22:30 PM every night.
Awesome guide. I made my lady read it. She was constantly complaining about her new atrix2's battery life. She learned quit a bit. It was easier to take this way than coming from a frustrated loved one.
You should use your skills to write a guide about how to use the report button and what help or response should be given and how to give it by non op's or those not involved in a given project for all the sudo (ha!) forum cops. (See I can't do it. My sentences are too long.) The constant correcting of anyone by everyone is getting annoying.
Sent from my MB865 using Tapatalk 2
Nice guide Apex!! Keep up the excellent work!
Thanks guys, your appreciation of my time doing these is more appreciated than I can say. Writing has always been a passion of mine, and really the only thing I was good at in school/college- when I wasn't ingesting illicit substances by the truck load. I'm working another guide thread now, hopefully completing it by tonight or tomorrow sometime. Thinking, since I'm nowhere near "dev" status or knowledge, I might apply for Recognized Contributor. Not sure we have any here in this community, at least that's not as present here as I am. Not to slight anyone who might be one, just haven't seen any floating around in here...
Sent from my SAMSUNG-SGH-I747 using xda premium
Apex_Strider said:
Thanks guys, your appreciation of my time doing these is more appreciated than I can say. Writing has always been a passion of mine, and really the only thing I was good at in school/college- when I wasn't ingesting illicit substances by the truck load. I'm working another guide thread now, hopefully completing it by tonight or tomorrow sometime. Thinking, since I'm nowhere near "dev" status or knowledge, I might apply for Recognized Contributor. Not sure we have any here in this community, at least that's not as present here as I am. Not to slight anyone who might be one, just haven't seen any floating around in here...
Sent from my SAMSUNG-SGH-I747 using xda premium
Click to expand...
Click to collapse
Wait isn't "ingesting illicit substances" part of the college curriculum? If it is not officially it should be, cause it does, ur, um, it did help... LOL.
vinamilk said:
Apex_Strider,
Can you tell us the final result when you applied these trick on your phone ?
Mine was not used any above, and gave me ~24hrs with heavy use, wifi on 24/24, screen on 5h using wifi. Phone for 15 mins/day, sometime movies for 2hrs.
I charged it at 22:30 PM every night.
Click to expand...
Click to collapse
Are you asking for my "results", meaning my battery usgae stats (i.e.: maximum duration of battery from full charge to full discharge, screen time, etc.)? If so, I'll have to do this again, as it's been a couple of months since I had. Keep in mind, that everyone's results will vary, as it depends on so many different variables.
Also, being on WiFi will demand less from your battery than relying solely on the network connection. So, if you're 'always' on WiFi, you will get more from your battery than not. On my Atrix 2, I can get a full day or more from one full charge. Now, this is from my usage, and like I mentioned -everyone's will vary. Generally speaking, in practical use Wi-Fi isn’t any more or less friendly on your battery than cellular is. Sure there are differences, but the biggest one of all is distance. Since you’re probably a good-deal closer to your Wi-Fi WAP than you are to your cellular tower, it’s likely that your battery life will be better if you’re using Wi-Fi rather than cellular data.
The charging trick I outlined in this thread is very useful for battery reporting errors after flashing a new rom, or just is one feels like their battery isn't getting the kind of "full" charge it should. It helped me out, as well as others...
I have an extended battery that I've run through several full drain/charge cycles over the past two weeks (when I got it). However, it still doesn't register the charge % properly - it will say 5% for over a day. I used the BatteryCalibration app to no avail.
Ideas?
Ajfink said:
I have an extended battery that I've run through several full drain/charge cycles over the past two weeks (when I got it). However, it still doesn't register the charge % properly - it will say 5% for over a day. I used the BatteryCalibration app to no avail.
Ideas?
Click to expand...
Click to collapse
Try the battery charge trick above, without the Watchdog part -sounds like a battery reporting error. Are you using 1% battery mods?
Sent from my SAMSUNG-SGH-I747 using xda premium
Apex_Strider said:
Try the battery charge trick above, without the Watchdog part -sounds like a battery reporting error. Are you using 1% battery mods?
Sent from my SAMSUNG-SGH-I747 using xda premium
Click to expand...
Click to collapse
No, I'm completely stock with root.
The Battery Calibration app DOES list the appropriate mV levels, though.
I'll give it a shot.
governors, i/o schedulers ?
may be this & this could help if u want to do sum experiment :silly:
+10 awesome job again !!!!!
So i got installing all the battery saver apps, greenify etc... they all close apps and not much else, my version comes from the mind of an electronics engineer view point...
hardware drains power NOT some little app running in the background! (Purely software programmer logic... )
So my app grabs what states wifi/gps/bt/modem at the time the screen goes off...
When the screen comes on, it re enables them! Eg go bed with 95% wake up with 94% put in your pocket it just does it...
The 2nd feature is the lost/stolen phone feature while the app itself can not get your gps data (no permissions for it) it can switch gps on/off...
So you send "on" without the surrounding quotes, the app will then switch on gps/wifi/modem/bt... it then disables itself
Now you can use wheres my droid or any other location finding app to easily pinpoint your lost or stolen phone (try getting a location with gps/agps/data disabled which people often do to save power!)
(Includes option to keep wifi/gps untouched from the app)
as for ads!... the ui has 1 ad, no popups or notifications ... and when activated the activity with the ad on is destroyed and can't touch battery life ... at all
Craig's Root Battery Saver!
https://play.google.com/store/apps/details?id=saver.battery.craigs.craigsbatterysaver
Well done
Holy crap! Someone replied (first for me here lol)
Thanks!
To be honest, your app is great when it comes to save battery, but in my opinion your approach is plain wrong in terms of the main purpose of a smartphone - receiving notifications in a timely manner, not when you turn on the screen manually. The same purpose can be achieved by using DS Battery Saver, which will in addition turn on mobile data once per specific time interval to receive push notifications.
And you should reconsider your opinion about "software does not drain battery but hardware does". Check this great thread for example. I am using a combination of different apps (Greenify, Amplify, Power Nap) to tame aggressive services/alarms/wakelocks and I am able to achieve a battery drain close to 0.0% per hour while screen is turned off with WiFi, mobile data and location turned on the whole time without losing instant notifications.
The app supports wake up notifications (well, will... the app's not quite finished yet, been too busy to get everything finished)
If you had gone to the playstore you'd have seen
Also you might want to reconsider what i said..... hardware drains it not software!
You refer to wake locks ... well believe it or not, wake locks turn on hardware which drains the battery, i program microcontrollers with the esp8266 / bluetooth / compass / etc ...
Software can only drain the battery if it's purposely trying to max out the cpu, and if it did you'd know it's malware... there are wakelock detectors too
Craig Capel said:
The app supports wake up notifications (well, will... the app's not quite finished yet, been too busy to get everything finished)
If you had gone to the playstore you'd have seen
Click to expand...
Click to collapse
I came across this, therefore my reference to DS Battery Saver, that already is capable of exact those things. Nevertheless, your app is doing what it was designed for - saving battery (and this is pretty good, indeed).
Craig Capel said:
Also you might want to reconsider what i said..... hardware drains it not software!
You refer to wake locks ... well believe it or not, wake locks turn on hardware which drains the battery, i program microcontrollers with the esp8266 / bluetooth / compass / etc ...
Software can only drain the battery if it's purposely trying to max out the cpu, and if it did you'd know it's malware... there are wakelock detectors too
Click to expand...
Click to collapse
Well, I am familiar with what wakelocks are. But without software, that produces a wakelock, there would be no noticable drain, right? Thus we can go round and round here, I guess. From my point of view the most battery drain on an Android device is the result of poorly programmed software (which results in an unneccessary wakelock) and alarms waking up your device, not from ****ty hardware. You can hunt down those wakelocks/alarms by using apps like Better Battery Stats or Wakelock Detector and reduce them to a minimum without losing functionality. Therefore I consider this as a better approach.
But without software, that produces a wakelock, there would be no noticable drain, right? Thus we can go round and round here, I guess. From my point of view the most battery drain on an Android device is the result of poorly programmed software
Click to expand...
Click to collapse
Unless the software drains it by intensive cpu work, anything else has to be hardware, if i power a gps module, talk to it via uart to enable/disable it... then it's hardware doing it not software..
Take Qualcomm, the newer cpus support an embedded DSP
https://gigaom.com/2014/12/12/5-things-to-expect-from-qualcomms-flagship-mobile-chip-in-2015/
Qualcomm*made that feature possible*in the Snapdragon 800*with its DSP, and they’re pushing hot words even farther. New devices will have the ability to passively listen, using only a small amount of power, for more than just the word “OK.” Qualcomm calls this feature Snapdragon Sense.
The first feature it will enable is a much faster Shazam search. So if you find yourself too slow on the draw when trying to identify unfamiliar music, you’ll love this: When you boot up Shazam, it’ll already have been listening just a little bit, so it can identify the song in a few seconds.
Click to expand...
Click to collapse
As hardware gets smaller and uses less power, then things like the embedded dsp chip will allow you to use wakelocks without little drainage, but were no where near that yet...
think of it like this... software simply carries instructions which can turn on hardware via a field effect transistor, that binary 1 value shows up as 3v logic and the fet begins to conduct between the drain and source, this sets a flip flop and the hardware starts wasting power...
Or to put it another way after the software enables the hardware via a gpio the software stops, or better still, show me software draining the battery with all hardware services disabled... it can't
Good
Does it really work ..
Don't you believe the title? (Really works!)
Craig Capel said:
As hardware gets smaller and uses less power, then things like the embedded dsp chip will allow you to use wakelocks without little drainage, but were no where near that yet...
Click to expand...
Click to collapse
True words. I can also see your other points and do agree with them. But as you said, we are not even close to a system where wakelocks do not drain as much as they currently do. Would we have such a system, your app wouldn't be required, I guess. Therefore taming the unneccessary wakelocks is a good way to achieve a great battery life without losing functionality for the moment.
Awesome
Awesome!!!
Can't open the settings and this sound makes me rly angry lol. Why it makes this sound? (even my phone is silence)
Gesendet von meinem ONE A2001 mit Tapatalk
There are no settings... work in progress (says so in the play store readme)
I've had the flu for the past week so i've not been developing much... expect updates shortly to remove the "settings" option which annoyingly is placed there by default... i never put it there
The sound is cool no? ... it plays a low volume sound to indicate the app is working!
Alright, update includes support for android 4.1 for gps now... i'm slowly working my way through android oddities and different techniques to switch hardware / on and off and with 5 phones to use 4 of them use kitkat!
Had to stop for a break i've had the flu all week, throwing up constantly, later on i'll add the finishing touches to wake up notifications as right now it's extreme power saving mode...
Stay tuned.... oh and i found a bug supporting lollipop, fixed that too, so if you have lollipop and it never worked, it should now ...
Antibiotics did the trick! It was sadly not the flu but some rare bug...
I've almost finished the autowakeup every x minutes 5, 10, 20 min intervals..
Unless someone here can think up a value or maybe add it as an option.
.
I removed the blocking side of things prior i used a thread/sleep now i use a timer event this stops the lag when unlocking the device on older models...
nive work :good:
I dumped the smart check (as far as i can tell anroid never fails, so i removed it)
It should now be seamless between lock screen and the main screen without any more lock up due to the threading...
Enjoy!
great!! will try it. thanks!