On wake locks, or how I stopped worrying and learned to love the CPU governor

wake locks cause this

Wake locks are a mechanism the developer has to make sure the screen is on and/or the CPU is ramped-up.  The developer requests the wake lock, then acquires it to turn it on, and releases it to turn it off.

This sort of thing can become rather complicated in large apps with multiple threads and objects which may be garbage collected before they can release their wake lock, which is why so many apps in the market have problems with battery use due to these “leaked” wake locks.

Right, backing up a bit, wake locks are equated with battery use because of that ramped-up CPU.   Mobile CPUs are designed to go into power-sipping modes when the screen is off, which is ramping-down.  A wake lock held longer than necessary causes the CPU to wake up to full speed and power consumption,  leaving it there.

Previously, I had taken a conservative approach to the use of wake locks in Wifi Fixer.  Some operations were critical, I needed to make sure the CPU and radio were available, so with a bit of experimentation, I was able to acquire wake locks for just long enough, and release them with no “leaks”.

This resulted in moderate wake lock usage, which was acceptable.  But recently the battery use of apps has come under a great deal of scrutiny by users, in part thanks to an improved battery history in jelly bean, and terrific tools like better battery stats.   These tools have allowed me to look at Wifi Fixer and think maybe I can do better with wake locks, and thus battery use.

The new code works like this: it tries to do a network thing, and if it fails, then the wake lock is acquired, the network thing is tried again, and the wake lock is released.     But that’s not the only way wake locks can be conserved.

Since fairly early, I’ve had an alarm which made sure Wifi Fixer’s important wifi monitor service was running when it was supposed to, i.e. not killed by a task killer or by the system due to low memory.    The consequence of this is wake locks where I did not explicitly acquire any.    I am still working on this problem, but I expect to have it solved soon.

In any case, expect Wifi Fixer 1.0 to be easier on your battery.

Towards 1.0

Today I finished some of the new layouts.  On average, the UI is rendering an order of magnitude faster than the old one. 

 

2013 Status

A few comments on the subject of Wifi Fixer that I’ve received:

“Wifi Fixer needs a refresh”

“The design needs to holo”

“It needs to use less memory and CPU”

I agree with all of these.  The last major design refresh was done before the design guidelines at developer.android.com were available. I’m going to try to give it some project time and do a design refresh to bring Wifi Fixer into 2013, and I’ll likely clean up the code as well.

0.9.5.6

Rebuilt with GPL licensing and proguard disabled. 

Fake app in Google Play

A less-than-ethical developer (Exhibit Studios, from the email) has put up a ripped-off build of Wifi Fixer in the store with a few image assets changed. 

https://play.google.com/store/apps/details?id=com.boostupstudios.WifiBooster

This was not done with my permission, and while my app is open source, I do not want to provide jerks with ad networks free revenue.   

I have contacted Google, and am considering several options for response.

In the meantime, if you have downloaded this app, please remove it and install Wifi Fixer.   The apk is quite a bit bigger, probably for the ad network libraries, but it may contain something else you don’t want.

Project Status 12-11-2012

Maintenance release coming with 4.2 compatibility and a few important things.

I’ve been studying machine learning and computer science full-time, which has been great for my ability to write code, but it’s affecting my ability to look at this project’s code without wanting to refactor it all.

I discovered how obnoxious even a minor refactor for dependency injection would become with robojuice.    I probably won’t have the time/energy for a complete refactor of Wifi Fixer for some time.

So, once the build I’m working on is out the door, that’s it for guaranteed time on the project.

If you are a programmer with stout heart, you might find some interesting things in the source, which you are welcome to.

Despite my lack of formal education in computer science (until recently), there are good examples of the use of abstract classes to handle differing Android versions, different UIs, and some clever uses of intents.

One might ask why I wrote my own preferences utility class.  It was because I made a mistake early on thinking I should put the network check service in a separate process, and I noticed that the SharedPreferences instances in the service did not see the changes made in the activity using SharedPreferences methods, so I decided to implement my own listener, before I knew what a listener was.

I hope someone finds the source useful.

There will be more Android apps.

Android 4.2, etc.

It appears that Android 4.2 has some more undocumented changes to WifiManager which break Wifi Fixer.   I will be disabling downloads for any devices with Android 4.2 installed until I can sort it out.

I will get a quick patch out with a few bugfixes and a compatibility fix for 4.2 when I do figure it out.