Android GPS bug

Jun 2, 2007
403
Beneteau First 375 Slidell, LA
Trying to remain, um, thrifty, I recently downloaded MX Mariner to my old Toshiba Android tablet. While not a substitute for a real chartplotter, since you can't read the screen in daylight, it was nice to have and did what I expected it to do. However, after running it continuously for some 36 hours while making a Gulf crossing, something surprising has come up. I got an alert on my tablet that I was low on storage. What? I have 12 gigs, only showing about 2 used, but only a couple of hundred megs available.
After much poking around on the Internet, I have come to the conclusion that I am seeing the effects of a bug in the Android system. Apparently when the built-in GPS is in use, it maintains a log file that eventually eats up all of memory and furthermore is invisible to the ordinary user, so can't be deleted. Without becoming a Unix expert, all I can do is a factory reset to get my storage back. Note this is not a fault of MX Mariner but Android itself, at least in the version I have, 4.0.3 I believe. Just an alert to other users. Argh.
 
Jan 22, 2008
597
Oday 35 and Mariner 2+2 Alexandria, VA
Bug was fixed in 4.4.0 and above, but you should be able to free up memory on the older OS with the app fast reboot. At least it removes temp files on terminated processes. Other than that, without rooting the tablet, it is a tough issue. Incidentally, IOS had the same issue.
 
Jan 22, 2008
597
Oday 35 and Mariner 2+2 Alexandria, VA
IOS 7 has a similar GPS log file that would not delete itself. I don't work much on IOS so I can't tell you which specific applications had the bad log files, but it is a known issue. Anything later than IOS 7.1 and Android 4.4 do not have the issue.
 
Nov 8, 2010
11,386
Beneteau First 36.7 & 260 Minneapolis MN & Bayfield WI
IOS 7 has a similar GPS log file that would not delete itself. I don't work much on IOS so I can't tell you which specific applications had the bad log files, but it is a known issue. Anything later than IOS 7.1 and Android 4.4 do not have the issue.
Do you have link that describes that issue?

It's well known that iOS kept some GPS location info in an internal file called consolidated.db, but that was for internal use and never got 'out of control'.
 
Nov 8, 2010
11,386
Beneteau First 36.7 & 260 Minneapolis MN & Bayfield WI
Is it really that important Jackdraw? ios and android are not impervious to issues, especially ios. But, I think dparilla might be talking about this issue with ios 7.

http://www.iphonehacks.com/2014/02/ios-7-1-fix-issue-location-based-apps.html
??? I simply asked him to clarify an assertion he made. Not sure why you have an issue with that. He claimed iOS had the same problem the OP described on android. I am quite sure he is wrong. If he's right, I'd like to know about it. Professional interest... I'm the CTO of a company that develops mobile apps.

PS - That's not the issue he is talking about.
 
Nov 8, 2010
11,386
Beneteau First 36.7 & 260 Minneapolis MN & Bayfield WI
My iPhone and iPad (8.1.1) does it with the Google earth app.
Harley,
I'm going to guess that you are experiencing a Google Earth problem, and not an iOS problem.

Google Earth for iOS is/was an notoriously buggy app, and a memory hog. In all its incarnations (windows, osX, android, iOS, etc) it attempts to cache large areas of bit-mapped maps in memory, and in its iOS form often crashes with a low-memory error.
 
Jan 22, 2008
597
Oday 35 and Mariner 2+2 Alexandria, VA
I will see if I still have the tech paper on it. It was from my work at FLTCYBERCOM that we found the bug. The issue was a bad copy of the acquisition time per satellite which when not augmented by a cell network position caused it to continually log each satellite as a new track.
 
Nov 8, 2010
11,386
Beneteau First 36.7 & 260 Minneapolis MN & Bayfield WI
I will see if I still have the tech paper on it. It was from my work at FLTCYBERCOM that we found the bug. The issue was a bad copy of the acquisition time per satellite which when not augmented by a cell network position caused it to continually log each satellite as a new track.
Hmm.. That actually doesn't not make sense to be, but I'm intrigued. Where in the stack was this happening? What level were you working at? At the app level you deal with location at a very abstract level... the location service simply populates a collection of CLLocation objects that include lat/log/elevation/error for the app to use. The operating system itself has no notion of a 'track'. Nor does the GPS subsystem, which looks at individual satellite data only to be combined into a 'fix'. Data observed outside a correlated solution is simply treated as error (most likely multi-path) and discarded.
 
Jun 2, 2007
403
Beneteau First 375 Slidell, LA
I'll muddy the waters a bit here - one of the posts I read indicated that a developer had accidentally left his code in test mode when it was submitted. It was implied a superuser could get in and switch off the data logging. Meanwhile, back to sailing...