My guess is that they're measuring time in milliseconds stored in a 32-bit signed integer and its overflowing to negative after 24.5 days (which is approx 2^31 milliseconds http://www.google.com/search?q=2^31+milliseconds+to+days )
it is related to 24.5 days = 2^31 milliseconds. however it's not an overflow, it's a bug with sign extension when casting from uint32 -> int32 -> int64 -> uint64, instead of directly uint32 -> uint64.
those operations are equivalent whenever the most significant bit of the uint32 is a 0, but orders of magnitude different when the most significant bit is a 1. so that explains why the bug turns off after 24.5 days and then turns back on after another 24.5 days.
Is there a date workaround yet? I don't have the phone, but it would be interesting to see if manually setting the date to a certain period fixes the autofocus until the update.
Edit: Answered my own question:
"Just changed the date back to 11/11 and got red boxes. Went back to 11/17 and got green boxes again. Could be something to it." - From the article comments.
Well, there are many options how to do autofocusing, but one of them involves sending out either ultrasonic or infrared wave and calculating the delay it takes to cover the distance to the subject.
Now lets just hope that someone with more knowledge about the implementation of this system can describe the problem more clearly...
I'd like to point out that if we assume that the infrared wave travels at the speed of light in empty space (I know it's somehow slower but good enough for the back of this virtual envelope) to a subject 1.5m from the camera and comes back, the total time would be 10.007 nanoseconds, so the timer should be accurate enough to measure fractions of nanoseconds to perform a correct autofocus.
So, I don't think that's how it works. Now, for the sound wave, maybe?
