• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[PATCH][MOD] GPS assistance & crash workarounds (4/21/11, new workaround)

Search This thread

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
4/20/11 Update: Added a second workaround for the libsecgps synchronization bug that otherwise allows multiple GPS requests to be sent to the RIL, causing the GPS to crash on assistance downloads (via GPS Status & Toolbox) and on application switch/exit. Details on this and the assistance workarounds, which are complementary to each other, follow below.

To folks with GPS problems:

If your GPS reliably works after a reboot, but ceases to work after appreciable uptime, it's quite likely that one or both of these workarounds will address the issue. Try the crash workaround first, as all EC05 Epics are vulnerable to the libsecgps synchronization bug, whereby the GPS crashes and is only recoverable by a full power cycle. If you continue to have issues, the assistance workaround may further help by keeping your assistance data fresh.

If your GPS rarely or never works in EC05, even outdoors with clear skies, even after a reboot, it's quite possible the assistance workaround will help. But please post in the thread or PM me first, as I'm interested in obtaining a boot-time logcat that would confirm the exact issue you're suffering.

Summary of issues discovered and/or resolved in this thread:
  • NTP/XTRA data doesn't download/inject on boot (jdelano; addressed by assistance workaround).
  • Synchronization bug with RIL that causes the GPS to crash (slwelsh; addressed by crash workaround).
  • Stale ephemeris (from XTRA data) after a few hours to a day of uptime. Possibly addressed by assistance workaround, needs confirmation (aero1, buggerritt, slwelsh?).
  • Time until ephemeris becomes stale differs across devices. Unknown cause, although a separate workaround exists to improve this to a day or longer (buggerritt).

4/11/11 Update: Fixed the update.zips so they actually flash in ClockworkMod. Apparently /system needs to be mounted, which it already is in stock recovery.

GPS assistance workaround:

Attached is a platform source patch against android-cts-2.2_r2 that, hopefully, works-around most assistance-related EC05 GPS problems by modifying the GPS location provider to download & inject time (NTP) and assistance (XTRA) data every time the "Use GPS satellites" setting is enabled. Also attached is a smali patch against EC05's /system/framework/framework.odex that implements this workaround in bytecode.

Finally, attached are testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including modified a modified framework.odex or framework.jar for: (i) the EC05 stock ROM, (ii) deodexed (framework-unmodified) ROMs, (iii) SyndicateROM Frozen 1.1.0 and (iv) midNIGHT ROM 5.2. All three implement the GPS workaround, and the first two also contain the TWS bug fix and ringer volume control mod. I'll try to take requests for additional ROMs as I can.

Assistance workaround directions:

Once flashed, keep the "Use GPS satellites" setting/notification widget toggle off until you're ready to use GPS. While having (any) active data connection, toggle GPS on and wait about five seconds before attempting a GPS fix.

Alternatively, if you always keep the GPS toggle on, toggle it off & on again to download new assistance data when you have difficulty getting a fix.

Assistance background:

In Froyo, the Epic GPS works in "standalone mode" with various types of supplemental assitance data pushed ("injected") by the GPS location provider if they're available. This includes:
  • XTRA (ephemeris & almanac) data: Downloaded and pushed automatically on reboot after a network connection is established.
  • NTP time: Nominally pushed after reboot and every four hours thereafter.
  • Location: Location data from other providers (e.g., cellular, wifi, etc.).

The XTRA ephemeris data, combined with a rough estimate of current location and an accurate (NTP-synced) clock, provides the GPS receiver with precise orbital positions of each satellite, allowing the receiver to quickly lock onto them even in weak signal (e.g., indoor) conditions or in the present of multipath (e.g., high-rise buildings). The gpsonextra servers appear to update XTRA data every hour at half-past. It's ephemeris data is (to the best I can discern) supposed to be valid for one week, although it's speculated that the Epic GPS may consider this data stale after a much shorter period of time, perhaps a few days, and in some cases, no more than a few hours.

The almanac data provides the GPS receiver with coarse orbital parameters of each satellite, allowing the receiver to locate the satellites reasonably quickly when outdoors with clear sky visibility. However, in absence of recent ephemeris (e.g., from XTRA or a previous fix), the receiver must download the current ephemeris from each satellite. Satellites broadcast their own ephemeris every 30 seconds, and thus, the receiver requires 30-60 seconds of strong signal from each satellite in order to obtain its ephemeris and lock onto it. The ephemeris broadcast from the satellite is valid for five hours, much less than that of the XTRA data. Each satellite also broadcasts the almanac data for the entire constellation every 12.5
minutes, and this data is valid for a few months.

This all means that, an Epic with recent XTRA data, NTP sync, and location estimate should be able to lock onto any visible satellite quickly (less than 10 seconds), possibly even indoors, whereas an Epic with stale ephemeris will fall back to using almanac data and should fix within a minute outdoors with clear sky visibility. Thus, Epics that take a long time to fix or can't fix indoor likely suffer from stale ephemeris. However, as long as these phones retain a GPS fix for at least fifteen minutes once every month or so, their almanac data will be fresh enough to operate indefinitely in this degraded mode.

Assistance workaround details:

XTRA data is downloaded automatically on boot, but it isn't downloaded again unless requested by the GPS receiver. Although this data is supposed to be valid for one week, folks report that their Epics take a long time to fix (30+ seconds) after a day, or even just a few hours of uptime, suggesting that the ephemeris downloaded at boot data becomes stale.

I don't know the root cause of why this data becomes stale, although it seems that temporarily downgrading and obtaining fixes in DI18 will improve the amount of time the ephemeris is considered valid to a day or longer in instances where it's only good for a few hours.

The idea behind this workaround is to exploit a simple heuristic: by activating the GPS toggle the user intends to use GPS for a while, so that's (probably) the best time to download new assistance data. Even if the toggle is left on all the time, it's an intuitive means to "reset" the GPS that most users will try, so it should download new assistance data every time. So while this might not directly fix the stale-ephemeris issue, hopefully this workaround will make the current and future assistance problems less relevant since they're easily bypassed.

A second issue is that NTP time and/or XTRA data often fails to be acquired on boot. The GPS location provider waits until there's an available network connection before connecting to the NTP and XTRA servers. However the "network available" notification doesn't quite work right, and the initial NTP request may happen before DNS resolvers are registered and the NTP request fails hostname lookup. While I never observed a failed XTRA download on my phone due to lookup failure, this seems to be the case with others. If you have trouble acquiring a fix even after a reboot, failed XTRA downloads may be to blame.

Since this workaround doesn't attempt to do NTP/XTRA until the GPS is enabled, this should no longer be an issue. However, to ensure it works in most instances when the GPS is left enabled across a reboot, I've added a network-notification settle delay of 5 seconds, which should be long enough (2.5 seconds is the longest it took my phone to settle) that NTP/XTRA will work on boot in that instance.

GPS crash workaround:

Attached is a platform source patch against android-cts-2.2_r2's liblog that avoids the GPS crash that happens when multiple GPS requests are sent via libsecgps to the RIL, which occurs during assistance downloads (via GPS Status & Toolbox) and on application switch/exit.

Also attached is a testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including a patched liblog.so for all EC05 (stock, deodexed, and custom) ROMs. I've also attached a "backout" update.zip that replaces liblog.so with the original EC05 version, should anyone wish to revert to it.

Crash workaround directions:

None, it works automatically once flashed.

Crash background:

The Epic's GPS receiver is integrated into the baseband, and communication with it is done via the Radio Interface Layer (RIL). The native library, libsecgps.so, implements various GPS-oriented commands (open, stop, location_fix, inject_time, xtra_set_data, and others) as requests, via the RIL, to be performed by the baseband processor and GPS receiver.

When a GPS app runs, location_fix requests are issued (synchronously) by a native library timer once every second while the app is actively seeking fixes. When a GPS app is closed or suspended, a stop request is issued to the GPS to cease fixing on satellites. Regarding these stop requests, it's important to note that: stops are often asynchronous, being the result of user action; and there appears to be no locking to ensure that a stop request is performed outside a location_fix cycle.

That is, a stop may come: (i) just prior to a location_fix request being issued, (ii) just after a request is issued but before it's sent to the baseband, (iii) after the baseband receives the request and performs the fix, and (iv) after the resulting location data is sent back (which completes a location_fix cycle).

A stop performed outside a location_fix cycle (iv) is most preferable, but due to the length of a location_fix cycle (~0.7 s) this happens only a third of the time. Most often, a stop if performed while a fix is actively being performed (iii) which results in a harmless recoverable error. However, if a stop is performed just before a location_fix is issued (i) or just after (ii), before the baseband can fully receive it, then the two requests may collide, throwing the baseband-side GPS functionality into an unrecoverable error state that is resolved only by a power cycle.

The critical window here is approximately 60 ms wide, meaning that the GPS crashes with 5% probability during a stop, or any other asynchronous request that occurs while the GPS is actively fixing. In other words, on average, every 20 GPS app closes/suspsends results in a GPS crash. For folks who use the GPS once or twice the day during a long navigation session, a crash may rarely be observed. For folks who use various GPS-utilizing apps throughout the day, crashes happen regularly after a day or two of uptime on average.

It's also worth noting that an XTRA download issues 40 xtra_set_data requests in a short window of time (~7 s). While these are safe outside an active fix (e.g., on boot or GPS toggle w/assistance workaround), if an assistance download is performed during active GPS use, e.g., via GPS Status & Toolbox, the GPS almost always crashes and the download fails. This is actually why GPS Status's assistance features appear not to work in Froyo, although with the crash workaround, I believe they do.

GPS workaround details:

Ultimately the GPS crash is due to insufficient locking in libsecgps that enables the interleaving of simultaneous requests to the RIL. Although we've observed instances where libsecgps appears to defer requests, it's locking behavior is insufficient to prevent interleaving in many instances.

For illustrative purposes, here's an excerpt of the log statements produced by libsecgps when properly processing a location_fix request:
Code:
...
D/libgps  ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps  ( 2931): newGpsRequest: new gps req 0x4303c8 cmd 5, idx 1
D/libgps  ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x4303c8 wait 1000
D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302648124 tv_nsec 519263548
D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302648125 tv_nsec 519263548
D/libgps  ( 2931): onRawReqComplete: oem_function_id 0x0E cmd 0x05 len 4
D/libgps  ( 2931): process_response: req 0x4303c8 cmd 0x05 plen 1
D/libgps  ( 2931): recv_ril_gps_location_fix_req: status 0
D/libgps  ( 2931): ril_gps_wakeup: 0x4303c8
D/libgps  ( 2931): ril_gps_wakeup: Entered critsec
D/libgps  ( 2931): ril_gps_wakeup: Left critsec
D/libgps  ( 2931): ril_gps_wait_for_ril: (n=0, r=0)
D/libgps  ( 2931): removeGpsRequest : removed req with cmd 5
...
The newGpsRequest function is called by the issuing thread for each request. Requests are then sent to the RIL (send_ril_gps_request) and the issuing thread waits on a condition varible (ril_gps_wait_for_ril). The RIL wakes up (ril_gps_wakeup), sends the request to the baseband, and signals the issuing thread to wake again. The issuing thread then deletes the request (removeGpsRequest).

For comparison, here's an excerpt of the log when a stop request interleaves a location_fix:
Code:
...
D/libgps  ( 2931): send_ril_gps_stop_req:
D/libgps  ( 2931): newGpsRequest: new gps req 0x3900f8 cmd 6, idx 2
D/libgps  ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps  ( 2931): newGpsRequest: new gps req 0x390958 cmd 5, idx 1
D/libgps  ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x390958 wait 1000
D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x3900f8 wait 1000
D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 191173085
D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 191173085
D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 210846213
D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 210846213
D/libgps  ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps  ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps  ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps  ( 2931): removeGpsRequest : removed req with cmd 6
D/libgps  ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps  ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps  ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps  ( 2931): removeGpsRequest : removed req with cmd 5
...
This time, a second newGpsRequest (location_fix) appears before the first (stop) request completes. Both threads appear to send their requests to the RIL, but the RIL never wakes up (no ril_gps_wakeup). Although it likely does, sees invalid data in its request buffer, and dies or something. Meanwhile the two issuing threads wait on the condition variable, which is never signaled. Eventually the condition variable times out and the request fail. At this point, the GPS has effectively crashed, as any subsequent GPS request to the RIL fails with the same error.

Fixing this synchronization bug involves either repairing the existing libsecgps locking logic, or adding new logic to prevent the interleaving of two or more requests. Unfortunately it's quite difficult to diagnose, repair, patch, and subsequently maintain said patch for source-code-less native libraries.

However, as libsecgps frequently makes use of logging statements, as illustrated above, during the processing of GPS requests, we can instrument the logging library to hijack the log calls and provide the necessary synchronization. Since libsecgps uses the logging routines provided by liblog, a library unmodified-by-Samsung for which we have source code, this is where the workaround code is placed.

Specifically, this workaround modifies liblog's __android_log_print's to look for logging messages made by libsecgps (libgps). Each newGpsRequest log statement signifies the creation of a request. When a second request (newGpsRequest statement) is encountered before an outstanding request completes, liblog defers the request by forcing the issuing thread to wait on a condition variable that's later signaled by the completion of RIL receiving the first request (ril_gps_wakeup). This prevents two requests from interleaving, and provides the necessary synchronization to prevent a GPS crash.

Final notes:

At this point the assistance workaround has been tested by multiple parties, some of whom have reported an improvement in GPS fix times, and none of whom have reported side-effects or adverse behavior.

The crash workaround has been tested by myself and slwelsh for three days now without either of us experiencing a crash or side-effects. At this point, I invite others to test the crash workaround, particularly if you experience them on a frequent basis as well.

As usual, please keep a copy of Odin and a stock/custom ROM tar file on hand, just in case something silly happens and your phone is bricked.

Also, while we've had a lot of feedback on folks's GPS issues already in this thread, I'd still appreciate feedback on whether these workarounds help you, or if you have a different GPS-related problem that you believe is not yet addressed by these.

Assistance workaround (mirror links, do not require forum login):
platform_gps_xtra_on_enable.diff
platform_gps_xtra_on_enable_smali.diff
tws_fix_ringer_vib_silent_gps-EC05-odex.zip
tws_fix_ringer_vib_silent_gps-EC05-deodex.zip
gps_xtra_on_enable-SRF110.zip
gps_xtra_on_enable-midNIGHT52.zip

Crash workaround (mirror links, do not require forum login):
platform_gps_request_sync.diff
gps_request_sync-EC05.zip
orig_liblog-ECO5.zip (to backout the crash workarond)
 

Attachments

  • platform_gps_xtra_on_enable.diff.txt
    2.7 KB · Views: 25
  • platform_gps_xtra_on_enable_smali.diff.txt
    3.4 KB · Views: 14
  • tws_fix_ringer_vib_silent_gps-EC05-odex.zip
    3.4 MB · Views: 26
  • tws_fix_ringer_vib_silent_gps-EC05-deodex.zip
    3.4 MB · Views: 32
  • gps_xtra_on_enable-SRF110.zip
    3.3 MB · Views: 82
  • platform_gps_request_sync.diff.txt
    4.2 KB · Views: 8
  • gps_request_sync-EC05.zip
    166.2 KB · Views: 39
  • orig_liblog-ECO5.zip
    165.9 KB · Views: 11
Last edited:

mrzood

Senior Member
Apr 29, 2010
187
37
San Antonio, TX
Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
 

slwelsh

Senior Member
Mar 30, 2011
50
4
Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.

Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?

Thanks.

-Sean
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
Isn't this just doing what the app GPS status already does?
I'm not sure exactly what GPS Status & Toolkit does, but this suggests that the "Download Assistance Data" approach should be the similar. Although it's possible that the API GPS Status uses to do that doesn't work for other reasons.

One difference might be that GPS Status downloads new assistance data after attempting to start a fix, which happens when starting the application. Whereas this workaround (can) download assistance data before attempting a fix. I don't know if this is the case, but I understand how new assistance data might be ignored by the GPS while a fix is attempted, and even shortly thereafter.

Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
I believe the XTRA data is downloaded on boot regardless of that setting, although I've not confirmed that. However, what may be different is that with that setting disabled, location data is never injected.

Are you consistently getting fixes without "Wireless networks" and not with it? Is this when using 3G data, 4G data, wifi, or all of the above?

If it's with wifi, is the location data for your access point accurate? That is, if you pull up Maps with "Wireless networks" enabled, wifi on, and GPS disabled, is your location on the map accurate or far off?

I thought the GPS app doesn't work properly for our phones? I could be wrong though
It definitely didn't under DI18/Eclair, although I don't believe Eclair supported the XTRA download interface. I've not tried it since upgrading to Froyo.

Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
Have you tried them under Froyo, or just in Eclair?

This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.

Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
If you're running EC05 stock, before installing this, make a backup copy of "/system/framework/framework.odex" to "/data/local/tmp". If nothing else, this can be done with an "adb shell":
Code:
cat /system/framework/framework.odex > /data/local/tmp/framework.odex
sync
then go ahead and install the appropriate update.zip.

If you wish to backout the modification, make sure "USB debugging" is enabled and reboot into ClockworkMod. Connect the USB cable, pull up an "adb shell", and run:
Code:
cat /data/local/tmp/framework.odex > /system/framework/framework.odex
sync
then reboot. Once rebooted, feel free to delete the backup /data/local/tmp/framework.odex.

If you're running a deodexed ROM instead of stock, replace "framework.odex" with "framework.jar" in the above directions. Note that replacing "framework.jar/odex" is best done in recovery since it's not used then. If you replace it while the phone is running under a normal boot, it should still take, but it might cause your phone to panic and reboot.

Alternatively, you can replce "framework.odex" or "framework.jar" in one of the update.zips with the copy from your phone and install that update.zip from ClockworkMod. Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
 
  • Like
Reactions: slwelsh

slwelsh

Senior Member
Mar 30, 2011
50
4
Have you tried them under Froyo, or just in Eclair?
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).

This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.
Fair enough, that sounds like a good reason to at least give this patch a try. My GPS reliably stops working within a day or two after boot, so, in theory, just toggling GPS off and then back on again should inform us whether this patch resolves my issue.

... Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?

I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.

-Sean
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
Also, it would be really helpful for folks who do find they have problems, to start CatLog's log recording feature before enabling GPS, then enable and attempt a fix, stop the log record, and send the recorded log if the fix didn't work.

Or if you run into a bad fix when not actively recording, you can still run CatLog and save its latest buffer, although it might not contain information from far enough back to be useful, hence recording is preferred.

If you're concerned about the contents of the log, you can filter for lines containing "gps" (case insensitive, please) after pulling it to a workstation.
 
Last edited:

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).
I don't think it's worth doing that. Eclair's GPS problems are well known, Froyo does things completely differently.

I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.
SRF shouldn't make a difference. Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?

Also, reinstalling SRF will get rid of it, but that's a bit more of a hassle.
 

jdelano

Senior Member
Sep 10, 2010
3,004
1,983
Buford, GA
Bonsia version?

i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.

I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.

If you think what would be useful to you.
 

slwelsh

Senior Member
Mar 30, 2011
50
4
... Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?

I think I can get by with the directions. That said, I would not turn you down if you wanted to post a flashable back-out zip. :)

I flashed your mod this morning. In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle. If experience is any guide, that will be sometime in the next 48 hours. Whatever happens, I will post the results here.

-Sean
 

slwelsh

Senior Member
Mar 30, 2011
50
4
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.

I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.

-Sean
 

Death259

Senior Member
Nov 15, 2010
646
303
I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.

-Sean

I'm using midNIGHT Rom which is based off of bonsai, and i have absolutely 0 gps issues. I get a lock within a few seconds.
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
i'd love to check this out; any chance of a Bonsai version?
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.

Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.

I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.
Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
That said, I would not turn you down if you wanted to post a flashable back-out zip. :)
Alright, I'll try to get to it in a bit. OK, here it is:
orig_framework-SRF110.zip

In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle.
Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?

I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem.
It's not clear to me exactly how widespread the EC05 GPS problems are. Before I wrote this, I only had bad fixes a good three or so times. I probably wouldn't have thought much of it except other folks were reporting issues too.

In which case, it wouldn't surprise me that no Bonsai users have experienced the issue. That's not quite the same as definitively saying that Bonsai users can't sufffer from it.

It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28--I'm actually rather curious to know if this helps them or not.
 
Last edited:

jdelano

Senior Member
Sep 10, 2010
3,004
1,983
Buford, GA
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.

Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.


Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.

yes aLogCat has a start and stop logging option. with active recording.

my gps locks but its not very close and if i have use networks it grabs the next town over.

Thanks for the zip; I'll give it a go (doing a backup before hand of course) ...
 

slwelsh

Senior Member
Mar 30, 2011
50
4
Alright, I'll try to get to it in a bit. OK, here it is

Thanks.

Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?
I've tried it both ways and problems happen either way.

My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time. When it fails, not only do I not get a fix, but I see no birds, either. The symptom is almost as if the GPS receiver is powered off. As near as I can tell, it does not matter how long I leave the GPS on after this happens, it will never see a single bird.

Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.

Neither toggling GPS nor using the tools in GPS Status to reset the A-GPS state or download assistance data fixes it. GPSCLRX has no effect. And I have tried various configurations of /etc/gps.conf and /data/secgps.conf all with no success.

It's not clear to me exactly how widespread the EC05 GPS problems are. ... It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28 ...

I've had this problem since the day I got my phone. It came with DI18 on it, and I was told that FroYo was going to fix it. The OTA EB13 rollout had been suspended the day before I got the phone, so I patiently waited for the rollout to resume, resisting the temptation to flash a ROM or even root the phone until I had the OTA FroYo update from Sprint.

Of course, when Sprint resumed the OTA rollout it was with EC05. My problem did not go away. A quick check of the forums revealed that users who had the EB13 upgrade had their GPS problems resolved under EB13, only to have them return under EC05. By this time, I only had a day or two left under the 30-day return policy to make a decision, and I figured that if they had fixed the problems under EB13 that surely there would eventually be a way to fix them under EC05. I am beginning to regret that decision, since I use LBS apps constantly and they are a key reason for me to have a smartphone in the first place.

Thanks so much for all your assistance. I have given up on Sprint/Samsung fixing this in any kind of reasonable timeframe and I have high hopes that the development community will figure this out and resolve it soon.

-Sean
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
829
My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time.
OK, I've seen that before. I've also had problems where the GPS will eventually see satellites and fix, but it takes a rather long time, upwards of five minutes. The latter mostly happened under DI18, I don't think I've waited around long enough to differentiate between the two problems the few times it's happened in EC05.

Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.
This is actually quite interesting.

To my knowledge, a "reboot" only reboots the Hummingbird CPU. I suspect (but have not confirmed) that the baseband CPU actually stays running throughout. Or at least, when I have had occasional wonky-radio issues, a simple "reboot" would not clear them. It requires a full device powerdown, which should reset the baseband as well.

It's relevant because, the stock EC05 behaior is to download XTRA data on reboot. It wasn't clear to me before whether GPS issues were being resolved as a function of receiving new XTRA data, or as a function of a baseband reset. However, if you find that a "reboot" doesn't always fix the GPS problems, that suggests that once it's in a sad state, it's possible that only a baseband reset will fix it. Alternatively, it may also be that a "reboot" doesn't always download new XTRA data, if it's attempted before a network connection is fully up.

I suppose we'll find out in a day or two, but if it is the case that the GPS won't recover from it's "sad state" without a power cycle, we might be able to keep it from ever reaching its sad state by keeping the assistance data fresh before attempting fixes. This would require consciously toggling the GPS before attempting a fix if one hasn't been performed in a long time. So, if you do run into a problem in the next day or two, this might be worth trying next.

I've had this problem since the day I got my phone.
I suppose it's also possible that some Epics just have bad GPS chips. If so, the existence of a separate assistance problem that was present in DI18 for so long makes it difficult to differentiate between the two. Hopefully this isn't the case.

Anyways, let's see what logcat says.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 12
    4/20/11 Update: Added a second workaround for the libsecgps synchronization bug that otherwise allows multiple GPS requests to be sent to the RIL, causing the GPS to crash on assistance downloads (via GPS Status & Toolbox) and on application switch/exit. Details on this and the assistance workarounds, which are complementary to each other, follow below.

    To folks with GPS problems:

    If your GPS reliably works after a reboot, but ceases to work after appreciable uptime, it's quite likely that one or both of these workarounds will address the issue. Try the crash workaround first, as all EC05 Epics are vulnerable to the libsecgps synchronization bug, whereby the GPS crashes and is only recoverable by a full power cycle. If you continue to have issues, the assistance workaround may further help by keeping your assistance data fresh.

    If your GPS rarely or never works in EC05, even outdoors with clear skies, even after a reboot, it's quite possible the assistance workaround will help. But please post in the thread or PM me first, as I'm interested in obtaining a boot-time logcat that would confirm the exact issue you're suffering.

    Summary of issues discovered and/or resolved in this thread:
    • NTP/XTRA data doesn't download/inject on boot (jdelano; addressed by assistance workaround).
    • Synchronization bug with RIL that causes the GPS to crash (slwelsh; addressed by crash workaround).
    • Stale ephemeris (from XTRA data) after a few hours to a day of uptime. Possibly addressed by assistance workaround, needs confirmation (aero1, buggerritt, slwelsh?).
    • Time until ephemeris becomes stale differs across devices. Unknown cause, although a separate workaround exists to improve this to a day or longer (buggerritt).

    4/11/11 Update: Fixed the update.zips so they actually flash in ClockworkMod. Apparently /system needs to be mounted, which it already is in stock recovery.

    GPS assistance workaround:

    Attached is a platform source patch against android-cts-2.2_r2 that, hopefully, works-around most assistance-related EC05 GPS problems by modifying the GPS location provider to download & inject time (NTP) and assistance (XTRA) data every time the "Use GPS satellites" setting is enabled. Also attached is a smali patch against EC05's /system/framework/framework.odex that implements this workaround in bytecode.

    Finally, attached are testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including modified a modified framework.odex or framework.jar for: (i) the EC05 stock ROM, (ii) deodexed (framework-unmodified) ROMs, (iii) SyndicateROM Frozen 1.1.0 and (iv) midNIGHT ROM 5.2. All three implement the GPS workaround, and the first two also contain the TWS bug fix and ringer volume control mod. I'll try to take requests for additional ROMs as I can.

    Assistance workaround directions:

    Once flashed, keep the "Use GPS satellites" setting/notification widget toggle off until you're ready to use GPS. While having (any) active data connection, toggle GPS on and wait about five seconds before attempting a GPS fix.

    Alternatively, if you always keep the GPS toggle on, toggle it off & on again to download new assistance data when you have difficulty getting a fix.

    Assistance background:

    In Froyo, the Epic GPS works in "standalone mode" with various types of supplemental assitance data pushed ("injected") by the GPS location provider if they're available. This includes:
    • XTRA (ephemeris & almanac) data: Downloaded and pushed automatically on reboot after a network connection is established.
    • NTP time: Nominally pushed after reboot and every four hours thereafter.
    • Location: Location data from other providers (e.g., cellular, wifi, etc.).

    The XTRA ephemeris data, combined with a rough estimate of current location and an accurate (NTP-synced) clock, provides the GPS receiver with precise orbital positions of each satellite, allowing the receiver to quickly lock onto them even in weak signal (e.g., indoor) conditions or in the present of multipath (e.g., high-rise buildings). The gpsonextra servers appear to update XTRA data every hour at half-past. It's ephemeris data is (to the best I can discern) supposed to be valid for one week, although it's speculated that the Epic GPS may consider this data stale after a much shorter period of time, perhaps a few days, and in some cases, no more than a few hours.

    The almanac data provides the GPS receiver with coarse orbital parameters of each satellite, allowing the receiver to locate the satellites reasonably quickly when outdoors with clear sky visibility. However, in absence of recent ephemeris (e.g., from XTRA or a previous fix), the receiver must download the current ephemeris from each satellite. Satellites broadcast their own ephemeris every 30 seconds, and thus, the receiver requires 30-60 seconds of strong signal from each satellite in order to obtain its ephemeris and lock onto it. The ephemeris broadcast from the satellite is valid for five hours, much less than that of the XTRA data. Each satellite also broadcasts the almanac data for the entire constellation every 12.5
    minutes, and this data is valid for a few months.

    This all means that, an Epic with recent XTRA data, NTP sync, and location estimate should be able to lock onto any visible satellite quickly (less than 10 seconds), possibly even indoors, whereas an Epic with stale ephemeris will fall back to using almanac data and should fix within a minute outdoors with clear sky visibility. Thus, Epics that take a long time to fix or can't fix indoor likely suffer from stale ephemeris. However, as long as these phones retain a GPS fix for at least fifteen minutes once every month or so, their almanac data will be fresh enough to operate indefinitely in this degraded mode.

    Assistance workaround details:

    XTRA data is downloaded automatically on boot, but it isn't downloaded again unless requested by the GPS receiver. Although this data is supposed to be valid for one week, folks report that their Epics take a long time to fix (30+ seconds) after a day, or even just a few hours of uptime, suggesting that the ephemeris downloaded at boot data becomes stale.

    I don't know the root cause of why this data becomes stale, although it seems that temporarily downgrading and obtaining fixes in DI18 will improve the amount of time the ephemeris is considered valid to a day or longer in instances where it's only good for a few hours.

    The idea behind this workaround is to exploit a simple heuristic: by activating the GPS toggle the user intends to use GPS for a while, so that's (probably) the best time to download new assistance data. Even if the toggle is left on all the time, it's an intuitive means to "reset" the GPS that most users will try, so it should download new assistance data every time. So while this might not directly fix the stale-ephemeris issue, hopefully this workaround will make the current and future assistance problems less relevant since they're easily bypassed.

    A second issue is that NTP time and/or XTRA data often fails to be acquired on boot. The GPS location provider waits until there's an available network connection before connecting to the NTP and XTRA servers. However the "network available" notification doesn't quite work right, and the initial NTP request may happen before DNS resolvers are registered and the NTP request fails hostname lookup. While I never observed a failed XTRA download on my phone due to lookup failure, this seems to be the case with others. If you have trouble acquiring a fix even after a reboot, failed XTRA downloads may be to blame.

    Since this workaround doesn't attempt to do NTP/XTRA until the GPS is enabled, this should no longer be an issue. However, to ensure it works in most instances when the GPS is left enabled across a reboot, I've added a network-notification settle delay of 5 seconds, which should be long enough (2.5 seconds is the longest it took my phone to settle) that NTP/XTRA will work on boot in that instance.

    GPS crash workaround:

    Attached is a platform source patch against android-cts-2.2_r2's liblog that avoids the GPS crash that happens when multiple GPS requests are sent via libsecgps to the RIL, which occurs during assistance downloads (via GPS Status & Toolbox) and on application switch/exit.

    Also attached is a testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including a patched liblog.so for all EC05 (stock, deodexed, and custom) ROMs. I've also attached a "backout" update.zip that replaces liblog.so with the original EC05 version, should anyone wish to revert to it.

    Crash workaround directions:

    None, it works automatically once flashed.

    Crash background:

    The Epic's GPS receiver is integrated into the baseband, and communication with it is done via the Radio Interface Layer (RIL). The native library, libsecgps.so, implements various GPS-oriented commands (open, stop, location_fix, inject_time, xtra_set_data, and others) as requests, via the RIL, to be performed by the baseband processor and GPS receiver.

    When a GPS app runs, location_fix requests are issued (synchronously) by a native library timer once every second while the app is actively seeking fixes. When a GPS app is closed or suspended, a stop request is issued to the GPS to cease fixing on satellites. Regarding these stop requests, it's important to note that: stops are often asynchronous, being the result of user action; and there appears to be no locking to ensure that a stop request is performed outside a location_fix cycle.

    That is, a stop may come: (i) just prior to a location_fix request being issued, (ii) just after a request is issued but before it's sent to the baseband, (iii) after the baseband receives the request and performs the fix, and (iv) after the resulting location data is sent back (which completes a location_fix cycle).

    A stop performed outside a location_fix cycle (iv) is most preferable, but due to the length of a location_fix cycle (~0.7 s) this happens only a third of the time. Most often, a stop if performed while a fix is actively being performed (iii) which results in a harmless recoverable error. However, if a stop is performed just before a location_fix is issued (i) or just after (ii), before the baseband can fully receive it, then the two requests may collide, throwing the baseband-side GPS functionality into an unrecoverable error state that is resolved only by a power cycle.

    The critical window here is approximately 60 ms wide, meaning that the GPS crashes with 5% probability during a stop, or any other asynchronous request that occurs while the GPS is actively fixing. In other words, on average, every 20 GPS app closes/suspsends results in a GPS crash. For folks who use the GPS once or twice the day during a long navigation session, a crash may rarely be observed. For folks who use various GPS-utilizing apps throughout the day, crashes happen regularly after a day or two of uptime on average.

    It's also worth noting that an XTRA download issues 40 xtra_set_data requests in a short window of time (~7 s). While these are safe outside an active fix (e.g., on boot or GPS toggle w/assistance workaround), if an assistance download is performed during active GPS use, e.g., via GPS Status & Toolbox, the GPS almost always crashes and the download fails. This is actually why GPS Status's assistance features appear not to work in Froyo, although with the crash workaround, I believe they do.

    GPS workaround details:

    Ultimately the GPS crash is due to insufficient locking in libsecgps that enables the interleaving of simultaneous requests to the RIL. Although we've observed instances where libsecgps appears to defer requests, it's locking behavior is insufficient to prevent interleaving in many instances.

    For illustrative purposes, here's an excerpt of the log statements produced by libsecgps when properly processing a location_fix request:
    Code:
    ...
    D/libgps  ( 2931): send_ril_gps_location_fix_req: start_mode 1
    D/libgps  ( 2931): newGpsRequest: new gps req 0x4303c8 cmd 5, idx 1
    D/libgps  ( 2931): send_ril_gps_request: cmd 0x05 plen 18
    D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x4303c8 wait 1000
    D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
    D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302648124 tv_nsec 519263548
    D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302648125 tv_nsec 519263548
    D/libgps  ( 2931): onRawReqComplete: oem_function_id 0x0E cmd 0x05 len 4
    D/libgps  ( 2931): process_response: req 0x4303c8 cmd 0x05 plen 1
    D/libgps  ( 2931): recv_ril_gps_location_fix_req: status 0
    D/libgps  ( 2931): ril_gps_wakeup: 0x4303c8
    D/libgps  ( 2931): ril_gps_wakeup: Entered critsec
    D/libgps  ( 2931): ril_gps_wakeup: Left critsec
    D/libgps  ( 2931): ril_gps_wait_for_ril: (n=0, r=0)
    D/libgps  ( 2931): removeGpsRequest : removed req with cmd 5
    ...
    The newGpsRequest function is called by the issuing thread for each request. Requests are then sent to the RIL (send_ril_gps_request) and the issuing thread waits on a condition varible (ril_gps_wait_for_ril). The RIL wakes up (ril_gps_wakeup), sends the request to the baseband, and signals the issuing thread to wake again. The issuing thread then deletes the request (removeGpsRequest).

    For comparison, here's an excerpt of the log when a stop request interleaves a location_fix:
    Code:
    ...
    D/libgps  ( 2931): send_ril_gps_stop_req:
    D/libgps  ( 2931): newGpsRequest: new gps req 0x3900f8 cmd 6, idx 2
    D/libgps  ( 2931): send_ril_gps_location_fix_req: start_mode 1
    D/libgps  ( 2931): newGpsRequest: new gps req 0x390958 cmd 5, idx 1
    D/libgps  ( 2931): send_ril_gps_request: cmd 0x05 plen 18
    D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x390958 wait 1000
    D/libgps  ( 2931): ril_gps_wait_for_ril: req 0x3900f8 wait 1000
    D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
    D/libgps  ( 2931): ril_gps_wait_for_ril: +++entering
    D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 191173085
    D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 191173085
    D/libgps  ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 210846213
    D/libgps  ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 210846213
    D/libgps  ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
    E/libgps  ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
    E/libgps  ( 2931): RIL Request: ERROR 1 (n=110, r=0)
    D/libgps  ( 2931): removeGpsRequest : removed req with cmd 6
    D/libgps  ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
    E/libgps  ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
    E/libgps  ( 2931): RIL Request: ERROR 1 (n=110, r=0)
    D/libgps  ( 2931): removeGpsRequest : removed req with cmd 5
    ...
    This time, a second newGpsRequest (location_fix) appears before the first (stop) request completes. Both threads appear to send their requests to the RIL, but the RIL never wakes up (no ril_gps_wakeup). Although it likely does, sees invalid data in its request buffer, and dies or something. Meanwhile the two issuing threads wait on the condition variable, which is never signaled. Eventually the condition variable times out and the request fail. At this point, the GPS has effectively crashed, as any subsequent GPS request to the RIL fails with the same error.

    Fixing this synchronization bug involves either repairing the existing libsecgps locking logic, or adding new logic to prevent the interleaving of two or more requests. Unfortunately it's quite difficult to diagnose, repair, patch, and subsequently maintain said patch for source-code-less native libraries.

    However, as libsecgps frequently makes use of logging statements, as illustrated above, during the processing of GPS requests, we can instrument the logging library to hijack the log calls and provide the necessary synchronization. Since libsecgps uses the logging routines provided by liblog, a library unmodified-by-Samsung for which we have source code, this is where the workaround code is placed.

    Specifically, this workaround modifies liblog's __android_log_print's to look for logging messages made by libsecgps (libgps). Each newGpsRequest log statement signifies the creation of a request. When a second request (newGpsRequest statement) is encountered before an outstanding request completes, liblog defers the request by forcing the issuing thread to wait on a condition variable that's later signaled by the completion of RIL receiving the first request (ril_gps_wakeup). This prevents two requests from interleaving, and provides the necessary synchronization to prevent a GPS crash.

    Final notes:

    At this point the assistance workaround has been tested by multiple parties, some of whom have reported an improvement in GPS fix times, and none of whom have reported side-effects or adverse behavior.

    The crash workaround has been tested by myself and slwelsh for three days now without either of us experiencing a crash or side-effects. At this point, I invite others to test the crash workaround, particularly if you experience them on a frequent basis as well.

    As usual, please keep a copy of Odin and a stock/custom ROM tar file on hand, just in case something silly happens and your phone is bricked.

    Also, while we've had a lot of feedback on folks's GPS issues already in this thread, I'd still appreciate feedback on whether these workarounds help you, or if you have a different GPS-related problem that you believe is not yet addressed by these.

    Assistance workaround (mirror links, do not require forum login):
    platform_gps_xtra_on_enable.diff
    platform_gps_xtra_on_enable_smali.diff
    tws_fix_ringer_vib_silent_gps-EC05-odex.zip
    tws_fix_ringer_vib_silent_gps-EC05-deodex.zip
    gps_xtra_on_enable-SRF110.zip
    gps_xtra_on_enable-midNIGHT52.zip

    Crash workaround (mirror links, do not require forum login):
    platform_gps_request_sync.diff
    gps_request_sync-EC05.zip
    orig_liblog-ECO5.zip (to backout the crash workarond)
    1
    Isn't this just doing what the app GPS status already does?
    I'm not sure exactly what GPS Status & Toolkit does, but this suggests that the "Download Assistance Data" approach should be the similar. Although it's possible that the API GPS Status uses to do that doesn't work for other reasons.

    One difference might be that GPS Status downloads new assistance data after attempting to start a fix, which happens when starting the application. Whereas this workaround (can) download assistance data before attempting a fix. I don't know if this is the case, but I understand how new assistance data might be ignored by the GPS while a fix is attempted, and even shortly thereafter.

    Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
    I believe the XTRA data is downloaded on boot regardless of that setting, although I've not confirmed that. However, what may be different is that with that setting disabled, location data is never injected.

    Are you consistently getting fixes without "Wireless networks" and not with it? Is this when using 3G data, 4G data, wifi, or all of the above?

    If it's with wifi, is the location data for your access point accurate? That is, if you pull up Maps with "Wireless networks" enabled, wifi on, and GPS disabled, is your location on the map accurate or far off?

    I thought the GPS app doesn't work properly for our phones? I could be wrong though
    It definitely didn't under DI18/Eclair, although I don't believe Eclair supported the XTRA download interface. I've not tried it since upgrading to Froyo.

    Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
    Have you tried them under Froyo, or just in Eclair?

    This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.

    Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
    If you're running EC05 stock, before installing this, make a backup copy of "/system/framework/framework.odex" to "/data/local/tmp". If nothing else, this can be done with an "adb shell":
    Code:
    cat /system/framework/framework.odex > /data/local/tmp/framework.odex
    sync
    then go ahead and install the appropriate update.zip.

    If you wish to backout the modification, make sure "USB debugging" is enabled and reboot into ClockworkMod. Connect the USB cable, pull up an "adb shell", and run:
    Code:
    cat /data/local/tmp/framework.odex > /system/framework/framework.odex
    sync
    then reboot. Once rebooted, feel free to delete the backup /data/local/tmp/framework.odex.

    If you're running a deodexed ROM instead of stock, replace "framework.odex" with "framework.jar" in the above directions. Note that replacing "framework.jar/odex" is best done in recovery since it's not used then. If you replace it while the phone is running under a normal boot, it should still take, but it might cause your phone to panic and reboot.

    Alternatively, you can replce "framework.odex" or "framework.jar" in one of the update.zips with the copy from your phone and install that update.zip from ClockworkMod. Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
    1
    midNight v5.2 + this = NICE

    Ok well I went ahead and put this bad boy on my phone. Using the midnight version of the zips at the bottom of post 1. It made a stark difference in speed of lock and accuracy for me.

    I tested before application (I ran aLogCat to capture the background info) then flashed and ran the same test. Much nicer for sure.

    EDIT: after further review; my phone gets a great lock after reboot and then it slowly gets worse. We also confirmed that the midNight update didn't change anything. mkasick is looking at the jars and logs I sent him.
    1
    Meanwhile, slwelsh and I successfully debugged the problem he's been running into. It's due to a synchronization bug that results in the GPS crashing on occasion. I've put together a second workaround to fix it that he's been testing, and I'll update the OP in the next day or two with the second workaround and a detailed description of that problem.
    Updated the OP with the crash workaround and revised content.

    Feel free to test the crash workaround, particularly if you encounter GPS crashes on a regular basis.
    1
    ok so my gps won't work any more.
    What were the circumstances under which the GPS stopped working? Was it just after an upgrade, or randomly?

    Can you try GPS Test and report what happens with that?

    If you can't get a fix under any cirumstance, I'm nor sure a whole lot can be done. If you can at least grab a boot-time logcat using the directions in this post, I'll take a look to see if there's anything out of the ordinary.