After the update the 3g Icon keeps popping up when I am on wifi. going on and off. Its like something is using 3g only even though I have a solid wifi connection.
Anybody else see this?
I don't have 2.3.3 yet, but I know the phone will do that when an app wants to grab a network location or has restrictions on transmitting/receiving data over WiFi; 3G will pop up for a second or two while it uses the connection, then disappear again when it's done.
I had a small problem and then reloaded the network and all is good.
Mine is doing the same thing as we speak... How do you reload the network?
Sent from my Nexus S using XDA App
same. solid wifi signal, yet 3g was also on...
I Did however have issues with a MiFi Dongle with my nexus but I think it might have been the coverage area. Speedtest would give me low latency but ok with my girlfriends blackberry
I have the same issue...
same here
Guys, try switching to a different carrier in network settings, this should fail and kill your connection. Then switch back to the correct one for your sim card.
moon-unit said:
Guys, try switching to a different carrier in network settings, this should fail and kill your connection. Then switch back to the correct one for your sim card.
Click to expand...
Click to collapse
worked for me! thanks
unfortunately doesn't work for me
Happens here as well and it seems it's GPS/NetworkLocation related. That's what comes up in the log about every 20 seconds:
Code:
I/GPS ( 111): on_request_connection: successfully called
...
I/GPS ( 111): assist_gps_data_conn_open: successfully called
I/GPS ( 111): gps_engine_status_update: called acquire_wakelock_cb
I/GPS ( 111): assist_gps_data_conn_closed: called
I/GPS ( 111): on_supl_session_ended: successfully called
I/GPS ( 111): gps_engine_status_update: called release_wakelock_cb
When the screen is off it seems to stop after a while and then doesn't come back until I open an application that uses location (Maps, GPS Status) and then it will again do it every 20 seconds.
I switched to 2g for a while. Now back on 3g and with wifi on it isn't doing it (for now...)
Sent from my Nexus S using XDA App
mine has the same issue..sometimes it just going but coming back again right after..
Same poblem here, sometime it won't even connect to google services (green icons), google need to fix this issue, was this update even tested.
Anyone with this issue/bug could you please report it in the thread linked below over at the google mobile forum.
Nexus S, WiFi/3G issue after updating to Android 2.3.3 / I9020XXKB1 / GRI40
Thanks!
same problem, reported as well
I killed gpsd daemon by kill command and nexus returned to normal operation (gpsd restarted automatically).
Upd. I was one time solution, the bug reappeared after reboot.
The location update request every 20 secs seems be normal.
If you look at the logcat, even with 3g enabled and wifi disabled, you can see that the location request is still happening every 20 secs.
The difference with 2.3.3 is that every time the location request is occurring, the 3g icon pops up.
So I don't think there is anything wrong, but it is annoying and causes the UI to hiccup for a sec, so I hope google can push out a fix for it.
mlotz said:
Happens here as well and it seems it's GPS/NetworkLocation related. That's what comes up in the log about every 20 seconds:
Code:
I/GPS ( 111): on_request_connection: successfully called
...
I/GPS ( 111): assist_gps_data_conn_open: successfully called
I/GPS ( 111): gps_engine_status_update: called acquire_wakelock_cb
I/GPS ( 111): assist_gps_data_conn_closed: called
I/GPS ( 111): on_supl_session_ended: successfully called
I/GPS ( 111): gps_engine_status_update: called release_wakelock_cb
When the screen is off it seems to stop after a while and then doesn't come back until I open an application that uses location (Maps, GPS Status) and then it will again do it every 20 seconds.
Click to expand...
Click to collapse
Nexus S 2.3.3 wi-fi..
..is more powerfull than 2.3.2?
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)
Wow, nice work
Isn't this just doing what the app GPS status already does?
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 thought the GPS app doesn't work properly for our phones? I could be wrong though
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
Sent From My Evo Killer!!!
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Sent From My Evo Killer!!!
Click to expand...
Click to collapse
Huh, not sure.... either way, nicely done
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
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
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.
mrzood said:
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.
Click to expand...
Click to collapse
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?
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Click to expand...
Click to collapse
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.
slwelsh said:
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.
Click to expand...
Click to collapse
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.
slwelsh said:
Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
Click to expand...
Click to collapse
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?
mkasick said:
Have you tried them under Froyo, or just in Eclair?
Click to expand...
Click to collapse
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.
Click to expand...
Click to collapse
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?
Click to expand...
Click to collapse
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
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.
slwelsh said:
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).
Click to expand...
Click to collapse
I don't think it's worth doing that. Eclair's GPS problems are well known, Froyo does things completely differently.
slwelsh said:
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.
Click to expand...
Click to collapse
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.
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.
mkasick said:
... Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?
Click to expand...
Click to collapse
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
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.
Click to expand...
Click to collapse
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
slwelsh said:
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
Click to expand...
Click to collapse
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.
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
Click to expand...
Click to collapse
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.
jdelano said:
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.
Click to expand...
Click to collapse
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.
slwelsh said:
That said, I would not turn you down if you wanted to post a flashable back-out zip.
Click to expand...
Click to collapse
Alright, I'll try to get to it in a bit. OK, here it is:
orig_framework-SRF110.zip
slwelsh said:
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.
Click to expand...
Click to collapse
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?
slwelsh said:
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.
Click to expand...
Click to collapse
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.
mkasick said:
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.
Click to expand...
Click to collapse
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) ...
mkasick said:
Alright, I'll try to get to it in a bit. OK, here it is
Click to expand...
Click to collapse
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?
Click to expand...
Click to collapse
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 ...
Click to expand...
Click to collapse
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
slwelsh said:
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.
Click to expand...
Click to collapse
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.
slwelsh said:
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.
Click to expand...
Click to collapse
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.
slwelsh said:
I've had this problem since the day I got my phone.
Click to expand...
Click to collapse
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.
I was flashing a JB 4.1.2 ROM several days ago when I noticed that my Desire S doesn't connect to my home WiFi network. As I played with the router settings before that and I didn't have the time to troubleshoot it at that time, I ignored the incident. Next day, I saw that I'm not able to connect to my work WiFi network either...then I've started to wonder what happened.
The long story short, is that I frequently flash several ROMs that are all CM10 derivates: CM10 builds from nk111, Andromadus ROM by Flinny, Paranoid by djpbx (current ROM). I usually flash every new release/build and test it to see if I encounter bugs/issues. Now I am not able to connect to any WiFi with ANY ROM...I don't remember the exact moment from which this happened but since then, I've tried with ROMs on which WiFi worked before like IceColdSandwich ported from Lord ClockaN's ROM, several CM10 builds (newer or older), even with Sense based ROMs (I've tried Fallout and Sabsa Prime). With or without full wipe, doesn't make any difference.
On all I got the same thing: WiFi "see"the surrounding networks but doesn't connect...it's not even say "Authenticating" or "Acquiring IP address". I've tried all the settings in Advanced TAB (WiFi frequency band, WiFi region), I tried with different security options (WEP, WPA, WPA2), I tried with hidden network as well as with visible (SSID is transmitted), I even tried with open network. No success at all. Network is saved but that's all. On hidden networks It says network is not in range, on visible ones is not connecting at all.
I've tried to change radio...I've used the last one (20.4801.30.0822U_3822.10.08.04), I've flashed also the one I was using before and which DID WORK (20.48.30.0822U_3822.09.08.20)...nothing.
I've tried with or without a SIM (I read on a thread that it could influence)
I was hoping to solve it but it seems I was not able to do it. Don't know if it's something hardware related either, but since I can see the visible WiFi networks, at least the scanning part is working. Just that it does not connect. And it was working before, at least with some of the ROMs I've flashed
Now I end up with a Desire S without WiFi. Everything else works: BT, sensors, mobile data and so on. I don;t understand what happened, anyone that can give me clues or what else to check, please let me know. Phone is out of warranty and I exclude the "send it to repair center"" option. I'll do that only as last resort and when I'm going to buy a new phone.
NOTE: To avoid extra questions: I am S-Off, current radio 20.48.30.0822U_3822.09.08.20. I've also posted the problem initailly in Andromadus thread and attached a logcat HERE
I have the same problem with my desire s. BT and WIFI don't have mac adres id.
I am not sure it this much related, but I had plenty of such siituations while porting the Wireless driver into my kernel.
It was a permmission issiue (when certain files were created with certain permission another ramdisk with another permissions was not able to start the WiFi.) Usually a full wipe should fix this. Do not restore any wifi data with Titanium. Use 4EXT recovery if you are still on CWM
Once I managed to fix this by starting WiFi hotspot (on Sense 4 ROM) then stop it and start WiFi. Hope this helps
I've gone through the obvious (for me at least) things. I didn't post here without trying them first. Full wipe, gone through initial setup wizard, then first thing added a WiFi network... Nothing restored with TB or anything else, nothing installed, just flashed the ROM + GAPPS + aGPS patch then setup manually everything. When I've flashed Sabsa Prime I've even setup WiFi dirrectly from the initial setup wizard when it was asking how do I connect to internet. Still nothing
Later edit: I've tried to setup a WiFi access point from mobile (WiFi tethering). The access point is created but not visible to any device. It seems like the "emitting" part is not working, only the "reception" is ok.
Code:
[COLOR="Red"]15:25:47.265 Error hostapd 4245 Configuration file: /data/misc/wifi/hostapd.conf
15:25:47.812 Debug Tethering 1670 sendTetherStateChangedBroadcast 1, 0, 0
15:25:47.920 Warning hostapd 4245 wlan0: Could not connect to kernel driver
15:25:47.920 Error hostapd 4245 Using interface wlan0 with hwaddr d4:20:6d:be:66:76 and ssid 'RapierAP'[/COLOR]
15:25:47.920 Debug CommandListener 1431 Setting iface cfg
15:25:47.920 Debug CommandListener 1431 Trying to bring up wlan0
15:25:47.920 Debug Tethering 1670 Tethering wlan0
15:25:47.920 Debug Tethering 1670 InitialState.processMessage what=2
15:25:47.920 Debug Tethering 1670 sendTetherStateChangedBroadcast 0, 0, 0
15:25:47.920 Debug Tethering 1670 Tethered wlan0
15:25:47.920 Debug Tethering 1670 sendTetherStateChangedBroadcast 0, 1, 0
15:25:47.920 Debug Tethering 1670 MasterInitialState.processMessage what=1
15:25:48.030 Debug TetherController 1431 Setting IP forward enable = 1
15:25:48.030 Debug TetherController 1431 Starting tethering services
15:25:48.030 Debug TetherController 1431 Tethering services running
15:25:48.030 Info dnsmasq 4247 started, version 2.51 cachesize 150
15:25:48.030 Info dnsmasq 4247 compile time options: no-IPv6 GNU-getopt no-DBus no-I18N DHCP no-scripts no-TFTP
15:25:48.030 Warning dnsmasq 4247 warning: no upstream servers configured
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.48.2 -- 192.168.48.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.47.2 -- 192.168.47.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.46.2 -- 192.168.46.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.45.2 -- 192.168.45.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.44.2 -- 192.168.44.254, lease time 1h
15:25:48.030 Info dnsmasq 4247 DHCP, IP range 192.168.43.2 -- 192.168.43.254, lease time 1h
15:25:48.031 Info dnsmasq 4247 DHCP, IP range 192.168.42.2 -- 192.168.42.254, lease time 1h
15:25:48.031 Info dnsmasq 4247 read /etc/hosts - 1 addresses
When starting WiFi, I get the following:
Code:
[COLOR="Red"]15:32:47.517 Error WifiHW 1670 Unable to open connection to supplicant on "wlan0": No such file or directory[/COLOR]
15:32:48.171 Verbose SCREEBL 2762 --> ROTATION_0
15:32:48.171 Verbose SCREEBL 2762 --> Orientation IN BOUNDS: 5.0 < 5.00065256449902 < 90.0
15:32:49.596 Debug Tethering 1670 sendTetherStateChangedBroadcast 1, 0, 0
15:32:49.703 Debug Beautiful Widgets 4120000 WIFI_STATE_CHANGED_ACTION
15:32:49.810 Error WifiConfigStore 1670 configuration found for missing network, ignored
It seems a problem with the wlan0 which is not found...
Rapier said:
I've gone through the obvious (for me at least) things. I didn't post here without trying them first. Full wipe, gone through initial setup wizard, then first thing added a WiFi network... Nothing restored with TB or anything else, nothing installed, just flashed the ROM + GAPPS + aGPS patch then setup manually everything. When I've flashed Sabsa Prime I've even setup WiFi dirrectly from the initial setup wizard when it was asking how do I connect to internet. Still nothing
Click to expand...
Click to collapse
I know that you are here from quite some time and into this things and has no intention to offend you. Have you tried a backup and format of the SDcard? I saw this as a solution in one of the official ICS threads.
And what is the logcat saying when you enable WiFi?
Sent from my HTC Desire S
amidabuddha said:
I know that you are here from quite some time and into this things and has no intention to offend you. Have you tried a backup and format of the SDcard? I saw this as a solution in one of the official ICS threads.
And what is the logcat saying when you enable WiFi?
Sent from my HTC Desire S
Click to expand...
Click to collapse
No, no, please, no offence taken. Sorry if it sounded this way. But as you said, I'm here for some time and learned alot (thanks to this wonderful community) and I just wanted to say that I've tried through the "normal" ways. The logcat is as you see in my previous post (last code quote). There are only some rows because the rest are related to other things....
I've taken another logcat while starting up WiFi and then scan. Attached
I'll also try to format sdcard. This indeed is something I didn't try yet (I thought is not related). Wouldn't be the same thing if I just take out the card completely? For the test purpose I don't care what files are there and if some apps won''t work
Rapier said:
No, no, please, no offence taken. Sorry if it sounded this way. But as you said, I'm here for some time and learned alot (thanks to this wonderful community) and I just wanted to say that I've tried through the "normal" ways. The logcat is as you see in my previous post (last code quote). There are only some rows because the rest are related to other things....
I've taken another logcat while starting up WiFi and then scan. Attached
I'll also try to format sdcard. This indeed is something I didn't try yet (I thought is not related). Wouldn't be the same thing if I just take out the card completely? For the test purpose I don't care what files are there and if some apps won''t work
Click to expand...
Click to collapse
From your first logcat:
E/WifiHW ( 1674): Unable to open connection to supplicant on "/data/system/wpa_supplicant/wlan0": No such file or directory
and you have noticed the other one yourself:
Error WifiHW 1670 Unable to open connection to supplicant on "wlan0": No such file or directory
It seems like a permission issue to me not a hardware fault. LIke I mentioned the same happened to me several times (WiFi works, sees the networks but refuses to connect) What is strange that usually a data wipe/clean install solves this.
Actually I think yours is not seeing the networks (scanning):
"configuration found for missing network, ignored"
Not sure is this possible but your /data partition seems not wiped properly. Can you make a factory reset on your current rom?
Hi I see you are posting again "from over the air"
Have you solved it or using another device?
Sent from my HTC Desire S
amidabuddha said:
Hi I see you are posting again "from over the air"
Have you solved it or using another device?
Sent from my HTC Desire S
Click to expand...
Click to collapse
I wish...unfortunately not . I have mobile data (3G/HSDPA) with 1.5 GB traffic and 7.2 Mbps speed. It's enough for browsing the forum, even to download ROMs and updates.
Now I've noticed that not only WiFi is not workind...BT is not working as well. Cannot connect to my car kit and it was working before with almost all the ROMs.Since I first noticed the WiFi problem, I didn't try BT so I think the problem came in the same moment for both. I realy hope that is not something hardware related and it can be fixed. But I just don't know what else to check/do. I wanted to buy an One S but I didn't receive an answer from my carrier yet.
Rapier said:
I wish...unfortunately not . I have mobile data (3G/HSDPA) with 1.5 GB traffic and 7.2 Mbps speed. It's enough for browsing the forum, even to download ROMs and updates.
Now I've noticed that not only WiFi is not workind...BT is not working as well. Cannot connect to my car kit and it was working before with almost all the ROMs.Since I first noticed the WiFi problem, I didn't try BT so I think the problem came in the same moment for both. I realy hope that is not something hardware related and it can be fixed. But I just don't know what else to check/do. I wanted to buy an One S but I didn't receive an answer from my carrier yet.
Click to expand...
Click to collapse
Maybe trying the latest firmware (from the thread that keeps your recovery and hboot). This is the last resort before going for hardware check I suppose...
Sent from my HTC Desire S
Dear all,
I have been noticing the last few days (since I did a wipe + factory reset) that my TF700 (running latest JB) is draining ~3% of battery/h when completely idle (almost as much as my phone, which is on 3G and wifi!) when connected to Wifi. After installing Better Battery Stats, I see they report 90% of kernel wake lock time due to "wlan_rx_wake", which is not normal.This is (I think) consistent with the fact that I always see the arrows of "download" and "upload" blinking on top of the wifi icon...
I've googled around and it looks like a problem with dynamic IP and Ipv6, but I am worried that an app is actually doing this, because when I first got the tablet (a couple of weeks ago) this was not happening. However, I was getting 2 random reboots per day and I suspected that disabling the ASUS apps was causing it, so I did a complete wipe and I flashed the firmware. I think this problem started since then, but I cannot be 100% sure.
I've tried to check if there is any application that is actually using up the network, but the data usage seems reasonable (just a few KB for the system)...
Is anybody else experiencing this? Any proposed hints/solutions/workarounds?
Thanks!
DjKarras said:
Dear all,
I have been noticing the last few days (since I did a wipe + factory reset) that my TF700 (running latest JB) is draining ~3% of battery/h when completely idle (almost as much as my phone, which is on 3G and wifi!) when connected to Wifi. After installing Better Battery Stats, I see they report 90% of kernel wake lock time due to "wlan_rx_wake", which is not normal.This is (I think) consistent with the fact that I always see the arrows of "download" and "upload" blinking on top of the wifi icon...
I've googled around and it looks like a problem with dynamic IP and Ipv6, but I am worried that an app is actually doing this, because when I first got the tablet (a couple of weeks ago) this was not happening. However, I was getting 2 random reboots per day and I suspected that disabling the ASUS apps was causing it, so I did a complete wipe and I flashed the firmware. I think this problem started since then, but I cannot be 100% sure.
I've tried to check if there is any application that is actually using up the network, but the data usage seems reasonable (just a few KB for the system)...
Is anybody else experiencing this? Any proposed hints/solutions/workarounds?
Thanks!
Click to expand...
Click to collapse
You might try to disable some of the the ASUS bloatware, maybe one by one, to see if it isn't one of them causing the wakelock.
okantomi said:
You might try to disable some of the the ASUS bloatware, maybe one by one, to see if it isn't one of them causing the wakelock.
Click to expand...
Click to collapse
Thanks! OK, I'll try this... Maybe I just root and remove the bloatware...
DjKarras said:
Thanks! OK, I'll try this... Maybe I just root and remove the bloatware...
Click to expand...
Click to collapse
So, one update: at home, where I have a wifi with WPA2-PSK, the wlan_rx_wake goes down to 1% (as per BBS), so now the tablet is at a little less than 1%/hour, which is something more reasonable.
At work, where we have an enterprise network with TTLS authentication and so on, the wlan_rx_wake is around 70-80%. It then looks to be related to this, maybe: http://code.google.com/p/android/issues/detail?id=29804
I'll try to post a logcat tomorrow, will it be useful?
Yes, thanks for the update, and for looking into this. I hope there will be a fix now that the issue has been identified.
okantomi said:
Yes, thanks for the update, and for looking into this. I hope there will be a fix now that the issue has been identified.
Click to expand...
Click to collapse
So I'm JB and my tablet is still not rooted. That means no logcat access I'll need to wait until the weekend, I will root the tablet and then on Monday I do a test at work. BTW, I confirm that with the work network I get ~3% batt/hour with 90% wlan_rx_wake...
DjKarras said:
So I'm JB and my tablet is still not rooted. That means no logcat access I'll need to wait until the weekend, I will root the tablet and then on Monday I do a test at work. BTW, I confirm that with the work network I get ~3% batt/hour with 90% wlan_rx_wake...
Click to expand...
Click to collapse
So I did further tests, and I see that the AlarmManager is scheduling a lot of wake ups, for example
Code:
12-07 11:52:18.444 D/AlarmManager( 412): Triggered Alarm 414a0c90 ELAPSED_REALTIME_WAKEUP IntentSender{419d1c18: PendingIntentRecord{41a69780 android broadcastIntent}}
12-07 11:52:19.174 D/AlarmManager( 412): Added alarm Alarm{41b34b20 type 2 android} type:ELAPSED_REALTIME_WAKEUP when: After 0h:14m:24.0s
12-07 11:52:19.214 D/WifiNative-p2p0( 412): SetWifiConnected false
12-07 11:52:19.214 I/WifiStateBroadcastReceiver(11952): connecting or connected to Wifi
12-07 11:52:19.224 D/WifiNative-p2p0( 412): SetWifiConnected true
12-07 11:52:19.224 D/ConnectivityService( 412): ConnectivityChange for WIFI: CONNECTED/CONNECTED
I see a lot of these SetWifiConnected false... I attach the full log for a couple of hours. Anything suspicious?
Thanks!
DjKarras said:
So I did further tests, and I see that the AlarmManager is scheduling a lot of wake ups, for example
Code:
12-07 11:52:18.444 D/AlarmManager( 412): Triggered Alarm 414a0c90 ELAPSED_REALTIME_WAKEUP IntentSender{419d1c18: PendingIntentRecord{41a69780 android broadcastIntent}}
12-07 11:52:19.174 D/AlarmManager( 412): Added alarm Alarm{41b34b20 type 2 android} type:ELAPSED_REALTIME_WAKEUP when: After 0h:14m:24.0s
12-07 11:52:19.214 D/WifiNative-p2p0( 412): SetWifiConnected false
12-07 11:52:19.214 I/WifiStateBroadcastReceiver(11952): connecting or connected to Wifi
12-07 11:52:19.224 D/WifiNative-p2p0( 412): SetWifiConnected true
12-07 11:52:19.224 D/ConnectivityService( 412): ConnectivityChange for WIFI: CONNECTED/CONNECTED
I see a lot of these SetWifiConnected false... I attach the full log for a couple of hours. Anything suspicious?
Thanks!
Click to expand...
Click to collapse
Hi,
a further update on the matter. I used Shark to capture traffic incoming to the tablet, and I see that mainly there are som DHCPv6Client SOLICIT requests. It looks like IPv6 is not being treated well by the tablet (or maybe it's the routers?). I attach the pcap file from Shark, and I would like to ask for your advice on how to go further towards solving the problem. Is there somebody in the forum that can help with this problem? Can I disable IPv6 (I have not been able to find where)? Is there any further debugging I can do?
Many thanks,
Albert
I have the same problem. Google maps causes it for me. I run on clemsyn and cleanrom and stock before. I did factory reset, full wipe, new google accounts etc. Nothing helps.
The tablet consumes the dock and tablet battery in about 2 days of very very mild usage.
I have to know how to stop it.
I even applied all the battery save options and disable the automatic sync. The problem was before and with the new rom, but only appeared last week.
usern ameisval idandnot said:
I have the same problem. Google maps causes it for me.
I have to know how to stop it.
Click to expand...
Click to collapse
Easy. Just disable Google Maps. I did, when it kept reappearing in my running apps list on its own.
But I need it so much
usern ameisval idandnot said:
But I need it so much
Click to expand...
Click to collapse
I find Gmaps pretty useless, as you need a constant Inet connection . Pretty much only use Navfree these days. If I need satimagery, I use Google Earth or the Maps website. And paper maps
Try checking if 'Google Location Service" is enabled under settings --> Location Services. I can't check the maps app (obviously ) but there might also be a similar setting there. (There was a bug with it, that much I do remember. One where it remained on and kept eating battery, even with Maps not running. May very well be the same thing.)
I will test if that helps. Until then I will drop some bread on the streets to find my way back.
@ ShadowLea
It worked. Google maps still uses 80% of all apps but it just used 3% of the battery in 24h.
Thanks
However, I don't thing this has anything to be with the original post, hasn't it? It looks like a different issue...
DjKarras said:
However, I don't thing this has anything to be with the original post, hasn't it? It looks like a different issue...
Click to expand...
Click to collapse
Don't know. Have you checked it? From the name of the process i'd say something is keeping the wifi awake, and that's exactly what location service does.
Might also be the 'keep WiFi during sleep" setting.
It doesn't say so it battery usage (it's just keep awake, no app is waking the tablet up) and Battery Plus tells me it's a Kernel Wakelock. In addition, this only happens on certain wireless network. I think some packets on the network are keeping the tablet to sleep for a long time, and there are similar reports around.
I think I have been able to isolate the issue quite well with the Shark sniffer, but I just don't know how to follow further