Support moving to G+ community
We’re moving primary support to the G+ community.
6
Release 1.0.2 will be going beta sometime soon.
There’s a pretty big change to logging since 1.0.1 which requires some explanation.
There are essentially two logging systems in the app, one for the log fragment (which only turns on when the fragment is showing) and the one the user turns on to start recording a log to send to me. 1.02 simplifies this by reducing to one logging system.
There’s always been confusion over how logging works. I’ve been thinking about ways to address that for months. The way I came up with was to remove the user option and keep a log from the last 10 minutes, which the user can send to me at any time.
As it turns out, it’s easy to to this without taking up many resources: I’m using the sqlite API built into Android. This allows me to add timestamps for when the log entry was made and expire records older than 10 minutes as the new records are created with simple SQL queries.
The log can be dumped to disk or emailed to me with one tap. The new system shows the last 10 minutes of log whether the screen was on or not.
I am working on a maintenance release to fix a few bugs, no ETA.
I am in contact with Google support. For some reason the apk showed no restricted devices, yet some devices seem to be restricted.
I will publish a minor update to resolve the problem when the cause is identified. It may be on their end, as well.
I recently switched carriers to AT&T, and got the Galaxy S 4.
I do not know if this is the case with other AT&T Android phones, but on this one, there is a wifi advanced setting, “Auto Connect”, which was enabled when I received the phone, and which I immediately disabled.
The setting seems to be bugged, as a persistent wifi entry named ‘attwifi’ appears in the wifi known network list, and cannot be removed even after a factory reset.
Android seems to treat it as any other wifi entries, as it will connect to any network with the SSID of ‘attwifi’. Needless to say, this is horribly insecure.
Wifi Fixer 1.0 will have a blacklist for this wifi hotspot as a setting under advanced. It disables the network, and keeps it disabled so you do not connect. It seems to be working so far.
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.
Today I finished some of the new layouts. On average, the UI is rendering an order of magnitude faster than the old one.
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.
Wifi Fixer for Android 