Hello.
I found that my GPS location service works incorrect after 6 april 2019 GPS rollover
I use GPS Test app to check it, and it looks like my phone finds few satellites, fixes my position just fine for some time, and then after a minute or two just resets all GPS connection and loses all satellites at once. All signal bars just disappear at one moment. Then it starts finding satellites again, and this circle goes over and over again. Also, if I check Time tab in GPS Test app, it shows incorrect date and time, like 2-Sep-01. So it looks like our phone was affected by GPS rollover. Or is the problem only with my phone? I'm not sure is it software or hardware problem.
I tried to: flash a new ROM, backup stock ROM 4.1.2, clear and tighten GPS antenna contacts, update gps.conf file with my local NTP server address. Nothing worked.
If you have any suggestions about what is happening with my phone, please let me know. Also it will be great if you could say whether your Note 2 GPS works fine or you experiencing the same problem.
Thanks!
esseth said:
Hello.
I found that my GPS location service works incorrect after 6 april 2019 GPS rollover
I use GPS Test app to check it, and it looks like my phone finds few satellites, fixes my position just fine for some time, and then after a minute or two just resets all GPS connection and loses all satellites at once. All signal bars just disappear at one moment. Then it starts finding satellites again, and this circle goes over and over again. Also, if I check Time tab in GPS Test app, it shows incorrect date and time, like 2-Sep-01. So it looks like our phone was affected by GPS rollover. Or is the problem only with my phone? I'm not sure is it software or hardware problem.
I tried to: flash a new ROM, backup stock ROM 4.1.2, clear and tighten GPS antenna contacts, update gps.conf file with my local NTP server address. Nothing worked.
If you have any suggestions about what is happening with my phone, please let me know. Also it will be great if you could say whether your Note 2 GPS works fine or you experiencing the same problem.
Thanks!
Click to expand...
Click to collapse
Hi, a relative has exactly the same problem on an N7100 Galaxy Note II.
As of the 6th April it struggles to hold GPS lock. On a cycle ride it could stop logging position for 14 minutes. Then it would get a few positions then lose it again. His strada track was like he was in a very slow helicopter.
The data it does get is recorded as being in 1999, which made it disappear when loaded onto a cycling site. Eventually we found it loaded as circa 20 years ago! In theory you can record position and edit the data to correct the dates - perhaps more trouble than its worth - BUT the very intermittent position makes it almost useless.
There's a similar report on phonandroid (in French). They had samsung actually acknowledge the "date bug" but everyone is surprised at the loss of gps lock.
My hypothesis is either:
a. the device is using the gps-date to optimise some calculations - so they go wrong.
b. the device notices the mismatch between the gps-date and the more detailed parts of the gps data, which probably have the real date. So it resets itself to clear the anomaly (maybe thinking its been turned off for a long time!). But each time the mismatch occures.
I've just read that the full set of GPS data frames are quite big and take something like 12.5 minutes to arrive at 50 bits/second. This might fit with the 14 minute gap we saw.
ReaderK said:
Hi, a relative has exactly the same problem on an N7100 Galaxy Note II.
As of the 6th April it struggles to hold GPS lock. On a cycle ride it could stop logging position for 14 minutes. Then it would get a few positions then lose it again. His strada track was like he was in a very slow helicopter.
The data it does get is recorded as being in 1999, which made it disappear when loaded onto a cycling site. Eventually we found it loaded as circa 20 years ago! In theory you can record position and edit the data to correct the dates - perhaps more trouble than its worth - BUT the very intermittent position makes it almost useless.
There's a similar report on phonandroid (in French). They had samsung actually acknowledge the "date bug" but everyone is surprised at the loss of gps lock.
My hypothesis is either:
a. the device is using the gps-date to optimise some calculations - so they go wrong.
b. the device notices the mismatch between the gps-date and the more detailed parts of the gps data, which probably have the real date. So it resets itself to clear the anomaly (maybe thinking its been turned off for a long time!). But each time the mismatch occures.
I've just read that the full set of GPS data frames are quite big and take something like 12.5 minutes to arrive at 50 bits/second. This might fit with the 14 minute gap we saw.
Click to expand...
Click to collapse
Thanks for your reply. Now I see that the problem is not only for my phone, but for Note 2 model in general.
How do you think, is it any way to make some kind of fix for this? I hope there may be a way to make few changes in our GPS firmware, but I need an advice or instruction from somebody who knows exactly how this things work.
I have galaxy note 2 international model. I have Stock rom but rooted. Same problem with here.wego navigation app.
Samsung says navigations app developers are responsible for : https://www.samsung.com/us/support/troubleshooting/TSG01200843/
Please fix this hateful issue.
Hi to all!
Does anybody find a solution for the GPS bug?
Is there a suitable ROM to fix the problem?
I'm a software developer, so its possible for me to help for some reviews in the sources.
But my experience in the android system is very poor.
Did anybody knows the difference to the GPS of the Samsung Galaxy S III i9300?
The problem doesn't occur on the i9300.
Thanks in advance
From my point of view it's just the problem of the GPS device inside the phone, namely its firmware (which I don't know anybody can access or fix). I think there is no way any custom ROM can fix this since this is out of reach of the ROM.
N7100 as it is is useless as a GPS since the april 2019 due to the rollover bug. The only solution is to use external GPS module (connected through USB or bluetooth) until someone is able to fix it (which in my opinion will not ever happen). I have several N7100s and all of them is affected by this bug regardless of the rom installed (I tried many). And I have an old Mio GPS from 2003 or so and it still works - is not affected by the rollover bug). I am therefore moving to another phone and use those old N7100s as some special devices (sort of small tablets for kids, security cameras or so). No more usable as a phone with working GPS (withou additional hardware attached). Sad but that's just the way it is.
I would like to keep my good old trustworthy note2 as a fully functional tool and don´t want to buy one of those shiny glas-things with all that blingbling.
I found this post with a java script
https://stackoverflow.com/questions/56147606/wrong-date-returned-from-location-gettime-after-6-april-2019-week-number-rollov/57339828#57339828
In my view this leads into the right direction ...
Adapt the gps-time to the system-time.
Is this possible for a rooted phone ?
Although I have no clue about coding at all ..
I think the code is not correct ... logically and technically ...
You cannot always add constant 1024 weeks to the actual gps-time.
If you are for example one week away from the switching-date you have to add one week less
to get to the correct system-time ... correct ?
There are already apps which adpat the system-time to the gps-time.
But in this case we would need it the other way round ... i think.
I already tried to implement the java-script from above with droidscript.
But as I´ve said ... I have really no clue what I am doing
Maybe tasker could also be a way .... to start a fixing-routine always before using a navigation app
Maybe we could pile up some donations for a good programmer who is willing to take on the quest
to keep the note2 alive ?!
Let me know
what do you think ...
This cannot be the end of the NOTE2 !
Cheers ...
Christian
This code from stackexchange would have to be implemented into the navigation app. Also, I do think it is as simple as just adding 1024 weeks.
From what I know from other devices, Broadcom (Note2 uses BCM47521 GPS chip) uses an external wrapper/binary blob to translate the GPS data into time and location data. Therefor, to fix the root issue, one would need a fixed wrapper from Broadcom. Maybe this could be extracted from other devices, maybe wrappers from newer chips could also work with the old one?
On a TomTom PNA I was able to write second wrapper that redirects the output of the original wrapper, then corrects the date and writes it to the correct location. However, a smartphone with internet connection probably interacts a bit more with the chip. Not sure if my solution could work on the Note2 as well.
EDIT: /bin/gpsd seems to be the responsible wrapper. Though the name suggests to be the open source GNU gpsd, it seems this is a special Broadcom closed-source file just by the same name. Or...maybe it's in the sources of the Note2 open source files.
I write the problem and simple solution (add 1024 week) to here.wego, maps.me, google maps and yandex maps developers. And also to all note 2 rom developers on xda ( @dr.ketan, @transi1 , @makorn645 , @ComicoX , @ibrahimal63 @hgunduz295 ...). Still no solution for gps rollover. I think solution is simple for our developers but our phones and rom's sources are old and maybe can be ignored for them.
Please fix this issue by wrapper or anyway and be a hero @treysis
Now that I think about it, maybe even the app developers are out of luck. I think they will just rely on some location api provided by the phone. So it has to be in the firmware. I.e. even one level higher than the ROM. But like I said, maybe it's possible to fix this with a wrapper. Unfortunately, I don't own a Note2, so it's difficult for me to test.
You could try to find an app that logs NMEA messages on your Note2 and see what date is presented inside them. That would be already a bit helpful.
I think actually our rom developers should make corrections simple by adding 1024 week to wrong date.
However, location app developers can still fix it by adding 1024 week to wrong date provided by the rom inside their apps.
it's not necessary logs for NMEA messages, already it seems wrong date at gps testing app on our Note 2's.
Maybe you can help to our developers for wrapper method on their roms by xda private messages.
thanks a lot.
xda-dvlprs said:
I think actually our rom developers should make corrections simple by adding 1024 week to wrong date.
Click to expand...
Click to collapse
The question is, how easy is that to do? Where do you add those 1024 weeks? In "LocationManager.java"? Where does LocationManager.java take the date from? Does it do the conversion itself from binary data or does it rely on NMEA to extract the date? Does a wrong date already confuse the LocationManager enough to drop the GPS fix? Why does it drop the fix in the first place? Is there a comparison between GPS date and mobile network date?
However, location app developers can still fix it by adding 1024 week to wrong date provided by the rom inside their apps.
Click to expand...
Click to collapse
They can't! They just take the data from the LocationProvider. And if the LocationProvider says that the GPS signal is lost, the app can't do much about it. Unless it reads NMEA data from the GPS chip itself. I don't know if this is even possible with the permission framework.
it's not necessary logs for NMEA messages, already it seems wrong date at gps testing app on our Note 2's.
Click to expand...
Click to collapse
What do you mean with GPS testing app? Which app exactly are you referring to? How do you know it doesn't read NMEA?
Maybe you can help to our developers for wrapper method on their roms by xda private messages.
Click to expand...
Click to collapse
I don't know if there are any developers still active for NoteII and if they actually compile the java android stuff at all or just take it precompiled?
yes, we have active developers as i said before. for example @ComicoX . maybe help you this source code by crdroid rom for .java wrapper. https://github.com/crdroidandroid
thanks a lot.
xda-dvlprs said:
maybe help you this source code by crdroid rom for .java wrapper. https://github.com/crdroidandroid
thanks a lot.
Click to expand...
Click to collapse
Seems the right place to look, but I have no idea where exactly you would have to insert the patch.
I'm not android developer but I thinks to place the patch you need to look at line 538 and below.
https://github.com/crdroidandroid/a.../location/java/android/location/Location.java
@xda-dvlprs I had a bit a look around...I was even provided with some NMEA logfiles from the Note2. It seems to me this is the direct output of the /bin/gpsd driver. This is a proprietary closed source binary by Broadcom and has nothing to do with the open source BSD-licensed gpsd project. And the unfortunate thing is that the problem already exists at that level. So, we would need to find a working gpsd, and I doubt Broadcom would do anything in that direction, and furthermore it would have to be adapted by Samsung as well, which is even more unlikely. F*** Broadcom. This is exactly why OpenMoko decided to back away from using Broadcom back in 2007/2008.
WNRO 2019
Firstly thank @treysis for effort about WNRO. I see the gps date error before gps is reset when I look at the crdroid logs. So I think it is still a situation that can be corrected at the android operating system level.
Hopefully a good note 2 developer will take the time and correct it maybe simple by adding 1024 weeks.
treysis said:
@xda-dvlprs I had a bit a look around...I was even provided with some NMEA logfiles from the Note2. It seems to me this is the direct output of the /bin/gpsd driver. This is a proprietary closed source binary by Broadcom and has nothing to do with the open source BSD-licensed gpsd project. And the unfortunate thing is that the problem already exists at that level. So, we would need to find a working gpsd, and I doubt Broadcom would do anything in that direction, and furthermore it would have to be adapted by Samsung as well, which is even more unlikely. F*** Broadcom. This is exactly why OpenMoko decided to back away from using Broadcom back in 2007/2008.
Click to expand...
Click to collapse
Thanks ... for looking into it.
xda-dvlprs said:
Firstly thank @treysis for effort about WNRO. I see the gps date error before gps is reset when I look at the crdroid logs. So I think it is still a situation that can be corrected at the android operating system level.
Hopefully a good note 2 developer will take the time and correct it maybe simple by adding 1024 weeks.
Click to expand...
Click to collapse
Adding 1024 weeks doesn't help: if there is no satfix, there is no date to add 1024 weeks to. I compared with S3, which has predecessor GPS chip (BCM47511, Note2 uses BCM4752) and it also supplies a wrong date, but doesn't lose satfix.
But you day you see the error before WNRO in crdroid logs? Can you give me a link?
WNRO log
treysis said:
Adding 1024 weeks doesn't help: if there is no satfix, there is no date to add 1024 weeks to. I compared with S3, which has predecessor GPS chip (BCM47511, Note2 uses BCM4752) and it also supplies a wrong date, but doesn't lose satfix.
But you day you see the error before WNRO in crdroid logs? Can you give me a link?
Click to expand...
Click to collapse
here is my log : (attention this : GL_STOP_BAD_TIME)
---- Oct 15, 2019 17:57:09 ----
10-15 17:53:51.709 2395 3265 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:53:52.026 2395 2405 I art : Background partial concurrent mark sweep GC freed 5935(297KB) AllocSpace objects, 3(148KB) LOS objects, 33% free, 11MB/17MB, paused 2.181ms total 175.842ms
10-15 17:53:52.786 2395 3256 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:53:52.811 2395 2866 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]b7a)
10-15 17:53:52.820 2395 2416 I libgps : disarming wakeLockTimer
10-15 17:53:52.841 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]b7a)
10-15 17:53:53.110 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:53:53.110 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:53:53.110 2395 7663 I libgps : [proxy_gps_acquire_wakelock_cb][line = 696]: acquire_wakelock(1)
10-15 17:53:54.255 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:53:56.062 2395 2498 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:53:56.237 2395 3255 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]c34)
10-15 17:53:56.286 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]c34)
10-15 17:53:56.335 2607 2623 I art : Background partial concurrent mark sweep GC freed 23236(1303KB) AllocSpace objects, 3(236KB) LOS objects, 39% free, 9MB/15MB, paused 1.105ms total 144.787ms
10-15 17:53:56.381 2395 2405 I art : Background partial concurrent mark sweep GC freed 6326(392KB) AllocSpace objects, 6(296KB) LOS objects, 33% free, 11MB/17MB, paused 2.288ms total 216.223ms
10-15 17:53:57.202 2395 3247 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:53:59.862 2395 3249 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:54:00.176 2395 2405 I art : Background partial concurrent mark sweep GC freed 5049(291KB) AllocSpace objects, 5(276KB) LOS objects, 33% free, 11MB/17MB, paused 2.130ms total 155.934ms
10-15 17:54:00.288 2607 2607 W IInputConnectionWrapper: reportFullscreenMode on inexistent InputConnection
10-15 17:54:00.951 2395 2406 E ActivityManager: applyOptionsLocked: Unknown animationType=0
10-15 17:54:00.972 2395 3256 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]72a)
10-15 17:54:00.974 2395 2416 I libgps : disarming wakeLockTimer
10-15 17:54:00.983 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:54:01.007 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]72a)
10-15 17:54:02.193 2395 7663 I libgps : OnGpsExtensionMessage: MSG_REQUEST_LOCATION_ID
10-15 17:54:17.026 8302 8307 I art : Do full code cache collection, code=100KB, data=118KB
10-15 17:54:17.028 8302 8307 I art : Starting a blocking GC JitCodeCache
10-15 17:54:17.028 8302 8307 I art : After code cache collection, code=81KB, data=80KB
10-15 17:54:31.756 2078 2078 I perfprofd: profile collection skipped (missing semaphore file)
10-15 17:55:04.452 2395 2420 E BatteryStatsService: power: Missing API
10-15 17:55:04.462 2395 2420 E BatteryStatsService: no controller energy info supplied
10-15 17:55:04.462 2395 2420 E BatteryStatsService: no controller energy info supplied
10-15 17:55:06.464 2395 2420 W BatteryStatsService: Timeout reading modem stats
10-15 17:55:09.925 2079 2079 E gpsd : ASSERT in /tmp/12818784_188647/customers/samsung/T0EVOandroid/../../../proprietary/deliverables/android/gps_interface/../gpsd/common/GlGpsdInterface.cpp:953: GL_STOP_BAD_TIME
10-15 17:55:09.927 2079 2079 E gpsd : LogJava: Cannot flush log buffer. Skipped bytes: 307
10-15 17:55:09.934 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:55:09.934 2395 7663 I libgps : [proxy_gps_release_wakelock_cb][line = 706]: release_wakelock(0)
10-15 17:55:09.934 2395 7663 I libgps : [reset_wakelock][line = 720]: release_wakelock. reset acq_count
10-15 17:55:09.970 8564 8564 W sh : type=1400 audit(0.0:58): avc: denied { read } for name="overcommit_memory" dev=proc ino=73244 scontext=u:r:gpsd:s0 tcontext=ubject_rroc:s0 tclass=file permissive=0
10-15 17:55:10.008 8565 8565 W linker : Non position independent executable (non PIE) allowed: /system/bin/gpsd
10-15 17:55:10.034 8565 8565 W linker : /system/bin/gpsd has text relocations. This is wasting memory and prevents security hardening. Please fix.
10-15 17:55:10.114 8565 8565 W linker : /system/lib/libsec-ril.so has text relocations. This is wasting memory and prevents security hardening. Please fix.
10-15 17:55:10.145 8565 8565 W gpsd : type=1400 audit(0.0:59): avc: denied { read } for name="overcommit_memory" dev=proc ino=73244 scontext=u:r:gpsd:s0 tcontext=ubject_rroc:s0 tclass=file permissive=0
10-15 17:55:10.157 8565 8565 I libdmitry: Nexus 10 GPS interposition library loaded. Your GPS should work in M now.
10-15 17:55:10.163 2395 7663 I libgps : Restore: type=1, hostname=supl.google.com, port=7276, ssl=0, ssl_version=0, ssl_type=0
10-15 17:55:10.163 2395 7663 I libgps : Save: type=1, hostname=supl.google.com, port=7276, ssl=0, ssl_version=0, ssl_type=0
10-15 17:55:10.160 8565 8565 W gpsd : type=1400 audit(0.0:60): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:11.160 8565 8565 W gpsd : type=1400 audit(0.0:61): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:12.160 8565 8565 W gpsd : type=1400 audit(0.0:62): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:13.165 8565 8565 W gpsd : type=1400 audit(0.0:63): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:14.165 8565 8565 W gpsd : type=1400 audit(0.0:64): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:15.165 8565 8565 W gpsd : type=1400 audit(0.0:65): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:16.165 8565 8565 W gpsd : type=1400 audit(0.0:66): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:17.165 8565 8565 W gpsd : type=1400 audit(0.0:67): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:18.170 8565 8565 W gpsd : type=1400 audit(0.0:68): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:19.165 8565 8565 W gpsd : type=1400 audit(0.0:69): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:20.170 8565 8565 W gpsd : type=1400 audit(0.0:70): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:21.170 8565 8565 W gpsd : type=1400 audit(0.0:71): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:22.170 8565 8565 W gpsd : type=1400 audit(0.0:72): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:23.175 8565 8565 W gpsd : type=1400 audit(0.0:73): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:24.170 8565 8565 W gpsd : type=1400 audit(0.0:74): avc: denied { connectto } for path=004D756C7469636C69656E74 scontext=u:r:gpsd:s0 tcontext=u:r:rild:s0 tclass=unix_stream_socket permissive=0
10-15 17:55:25.449 2395 7663 I libgps : disarming wakeLockTimer
10-15 17:55:25.449 2395 7663 I libgps : [proxy_gps_acquire_wakelock_cb][line = 696]: acquire_wakelock(1)
10-15 17:55:29.685 2395 3249 I ActivityManager: START u0 {flg=0x10804000 cmp=com.android.systemui/.recents.RecentsActivity} from uid 10037 on display 0
10-15 17:55:29.843 2395 3265 I GnssLocationProvider: WakeLock acquired by sendMessage(3, 0, [email protected]eda)
10-15 17:55:29.856 2395 2416 I GnssLocationProvider: WakeLock released by handleMessage(3, 0, [email protected]eda)
10-15 17:55:29.976 2395 2405 I art : Background partial concurrent mark sweep GC freed 47812(2MB) AllocSpace objects, 10(392KB) LOS objects, 33% free, 11MB/17MB, paused 2.440ms total 149.816ms
10-15 17:55:31.177 2395 3255 E ActivityManager: applyOptionsLocked: Unknown animationType=0
---- Oct 15, 2019 17:57:09 ----
Related
Hi
i have a weird thing , dont know if its rom related but defenetly noticed it after rooting my device and installing cosutm roms. well i only used ARHD since 2.0.09 and i love it.
but , what happens is that suddenly and out of nothing (after like hours/days and the rom running smooth and ultra fast) , system cpu usage jumps to 100% and never bugs off only through a restart, and this seems to happen with all the different versions of ARHD i had, even though i install most of them with full wipes. but this i don't understand and it annoyes me cos it uses this cpu amount and drains battery and it happens suddenly and randomly , dunno what triggers it, and no matter how i tried to track it to see the error but couldn't find a thing.
i just hope u can help me by taking a look at this log i saved from android systeminfo app registering some errors (3 min log and it drained 14% battery ) , it shows something about "activity manager", im not a developer and i know nothing about those codes, but would be awesome if someone helps me out with any tip please.
thank you.
I am not a DEV but i don't think your log file includes any clue of what is causing your problem. Do you have sense account on? or any types of account that let you track your phone?
Activate usb debugging
Seems to be the bug with the .init process.
Sent from my Desire HD using Tapatalk
thank you for the replies , i already have usb debugging on. dunno what is causing this, its totally random and its driving me nuts.
can you see a process that uses 100% cpu in android system info? If yes, try to kill it and look at your cpu usage.
CPUNotify is a great tool. It shows cpu usage in the notification bar
Sent from my Desire HD using Tapatalk
the process showing 100% cpu usage (not always but randomly, no idea what triggers it ) is system , and u can't force close or end that task
Hmm strange... i can't even find a process called activity manager on my phone...
Well i don't know but maybe it's related to the DroidDream malware. Some apps in the market were infected with this virus. And i've read that the virus gains root access and can download other apps in the background.
Here's a link: http://forum.xda-developers.com/showthread.php?t=977154
I really don't know if it's related to this but it just came to my mind
Sent from my Desire HD using Tapatalk
thx for the help mate , but i dont think its related to droidream cos ive been having this issue since a while (long time before droidream was up )
im still monitoring to find out what is causing this issue.
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
Activate usb debugging
Seems to be the bug with the .init process.
Click to expand...
Click to collapse
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
wow , cheers mate for the help , sounds a bit complicated for me but at least we know what it is now and how to get over it.
but how come mike1986 doesnt know about this bug and its fix ? he could incorporate this into his next build so it saves us that command run every 15 mins. or it cant be incorporated ?
someone should tell him to be honest
but cheers for explanation mate, thank you
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
walda said:
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
Click to expand...
Click to collapse
i have no idea about that , if he does then im sure he will fix it
As I read in mikes 3.0 thread, he is informed. Fine...
sent from my DHD via Tapatalk
further to this.
in ProcessStats.java (im not sure if this is a kernel file or if it sits just outside the kernel).
mBuffer looks to me to be the main problem.
1. in apaches rom, which is overclocked he defines 23 CPU speeds..ProcessStats.java only allows 20
Code:
private long[] getCpuSpeedTimes(long[] out) {
long[] tempTimes = out;
long[] tempSpeeds = mCpuSpeeds;
final int MAX_SPEEDS = 20;
if (out == null) {
tempTimes = new long[MAX_SPEEDS]; // Hopefully no more than that
tempSpeeds = new long[MAX_SPEEDS];
this is a minor issue..as this overflow is trapped in the loop anyway:
Code:
if (speed == MAX_SPEEDS) break; // No more
however, the definition of mBuffer is too small:
Code:
private byte[] mBuffer = new byte[256];
my file at the moment is 300 bytes. the readFile reads only once instead of looping until end of file:
Code:
int len = is.read(mBuffer);
is.close();
so only the first 256 bytes are ever read.
My assumption is that IF the files first 256 bytes ends up cutting off the last read line (and that line lies in the first MAX_SPEEDS lines of the file) before the speed time element..this causes a NoSuchElementException to throw..as the last line will be like
921600 255
960000 750
998400 8042
10368
ie the line
1036800 3089
was cut off too soon and this code
Code:
long val = Long.parseLong(token);
tempSpeeds[speed] = val;
token = st.nextToken(); <-- here
val = Long.parseLong(token);.
in getCpuSpeedTimes() fails as it cant see the timing?
would then fail on the second nextToken().
the big question is who owns that code in our custom ROM? is it the same as the original android code so we are at the mercy of Google to fix it or is this something Mike / Apache will be able to patch up ..assuming i'm making sense
the only workaround is as i said before: to chmod this file to 700 and ensure it stays there (avoid using setcpu as it changes the permissions).
You can probably also reduce this by limiting the CPU frequency range your phone uses (ie keep the filesize smaller)..if you have profiles that span 200mhz to 1.2ghz then you will probably hit this sooner
i did a test.
1. rebooted my phone..ensured time_in_state had permissions -r--r--r--
2. manipulated CPU frequency using cpu tuner to make all frequencies have at least 5 bytes per line.
once the first 20 lines were > 256 bytes and the 256nd byte sat between <cpu speed> and <time spent at that speed> i get the loop.
eg just before the issue arose i saw:
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 9937
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
i had my cpu pinned to 960 mhz.
the 256 at this point lies here:
Code:
1075200 1560
1113600 1
ie line 20 is cut off after 1..this is still "valid" in terms of the data in mBuffer..but once 960 rolled into five digits
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 10288
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
the 256 byte now meant the last line shifts to:
Code:
1036800 6864
1075200
the 2nd word is now totally missing!
as soon as this happened..my logcat started issuing
Code:
Unexpected exception collecting process stats
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:272)
at com.android.server.ProcessStats.getCpuSpeedTimes(ProcessStats.java:596)
at com.android.server.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:568)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1657)
at com.android.server.am.ActivityManagerService$4.run(ActivityManagerService.java:1583)
errors.
something later on then causes this behavior to go into a full tight loop (as once the issue starts..it just issues this every few seconds..so most uses wont notice it).
didnt mike fixed it with his latest release (ARHD 3.1) ?
Goodm7sn said:
didnt mike fixed it with his latest release (ARHD 3.1) ?
Click to expand...
Click to collapse
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
DazzaL said:
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
Click to expand...
Click to collapse
Thanks mate, your solution is really effective on my DHD with revolution 3.0.
I am going to reflash with revolution 3.1, hopefully 3.1 will cure the cpu 100% usage
im on android revolution HD and i can confirm this , 100% system cpu of death is still here, didnt get fixed , had to change setcpu frequency and it stopped
meh phone cant last 12 hrs without a restart, frustrating.
DazzaL said:
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
Click to expand...
Click to collapse
if setcpu changed the range once the gui is opened , what do u recommend us to use for overclocking ? something safer
thx for helping
I read that it happens with CPU tuner and even without anything also!
The only solution I see is to fix the frequency file.
sent from my DHD via Tapatalk
ro.ril.power.collapse=1 or 0
I googled it . Some use 1 and some use 0
Which is best option for better battery life?
Anyone?
From "marvel-s-gb-mr-2.6.35-696f19b\arch\arm\mach-msm\acpuclock-arm11.c"
Code:
unsigned long acpuclk_power_collapse(int from_idle)
{
int ret = acpuclk_get_rate();
[B]ret *= 1000;[/B]
if ([B]ret > drv_state.power_collapse_khz[/B]) {
if (from_idle)
acpuclk_set_rate([B]drv_state.power_collapse_khz * 1000[/B],
SETRATE_PC_IDLE);
else
acpuclk_set_rate([B]drv_state.power_collapse_khz * 1000[/B],
SETRATE_PC);
}
return ret;
}
I don't know what the power collapse is and I don't care. But it seems that when that **** is enabled the cpu clock rate will be always lesser than the standard one in the something called "power collapse state". It means the less power consuption.
So: IMHO
ro.ril.power.collapse=1 or ro.ril.disable.power.collapse=0
Ok dears, I accidentally came across this. Now there is nothing smart about smartreflex.
voltage.h contains values about min and max range for smartreflex calibrations for CORE IVA and MPU, that we already knew...
Now I found this:
http://gitorious.org/pandroid/kerne...a10c87d6445/arch/arm/mach-omap2/smartreflex.c
Let's quit fooling around:
/* Default steps added for 1G volt is 5 in uV */
static unsigned long sr_margin_steps_1g = 62500;
/* Default steps added for less than 1G OPP's is 3 in uV*/
static unsigned long sr_margin_steps = 37500;
Click to expand...
Click to collapse
Does this explain enough for you? Below 1ghz each step is 3.7500, above it is 6.25
You don't get it?
static void sr_add_margin_steps(struct omap_sr *sr)
{
int i;
/*
* Add 5 steps for 1g and 3 steps for other OPP's by default
* REVISIT: Make it configurable through sysfs dynamically
*/
for (i = 1; i <= 3; i++)
sr1_opp_margin = sr_margin_steps;
sr1_opp_margin[4] = sr_margin_steps_1g;
for (i = 1; i <= MAX_VDD1_OPP; i++) {
printk(KERN_INFO "sr1_opp_margin[%d]=%ld\n", i,
sr1_opp_margin);
mpu_opps.sr_vsr_step_vsel = 0x0;
mpu_opps.sr_adjust_vsel = 0x0;
}
printk(KERN_INFO "steps added, volt will be"
"recaliberated automatically\n");
}
Click to expand...
Click to collapse
How did that translate for you? Is that just hardcoded to read the OPP table??? The first three elements in the MPU OPP table are below 1GHZ: 350, 700, 920
The rest is above...
I hope I helped some developers with this.
Since I'm no programmer I'm having a hard time to understand this.
Does it mean smartreflex is not good at all?
For me I hate smartreflex. I always get better battery uptime (especially in standby I get around 0.5% usage per hour) when I undervolt by myself.
When I use smartreflex my usage in standby is about 3 to 5%.
In my opinion smartreflex is for noobs who don't wanna fool around themselves...
Gesendet von meinem Galaxy Nexus mit Tapatalk 2
I've noticed some users have reported inferior signal on Android 4.2 on the LTE Gnex. This is actually not true. In fact below is the related function that changed from 4.1.2 to 4.2.
Jellybean 4.1.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -95) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -105) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -115) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else levelLteRsrp = SIGNAL_STRENGTH_POOR;
if (mLteRssnr == INVALID_SNR) levelLteRssnr = 0;
else if (mLteRssnr >= 45) levelLteRssnr = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 10) levelLteRssnr = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= -30) levelLteRssnr = SIGNAL_STRENGTH_MODERATE;
else levelLteRssnr = SIGNAL_STRENGTH_POOR;
int level;
if (mLteRsrp == -1)
level = levelLteRssnr;
else if (mLteRssnr == INVALID_SNR)
level = levelLteRsrp;
else
level = (levelLteRssnr < levelLteRsrp) ? levelLteRssnr : levelLteRsrp;
if (DBG) log("Lte rsrp level: "+levelLteRsrp
+ " snr level: " + levelLteRssnr + " level: " + level);
return level;
}
JB 4.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp > -44) rsrpIconLevel = -1;
else if (mLteRsrp >= -85) rsrpIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -95) rsrpIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -105) rsrpIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -115) rsrpIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRsrp >= -140) rsrpIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
/*
* Values are -200 dB to +300 (SNR*10dB) RS_SNR >= 13.0 dB =>4 bars 4.5
* dB <= RS_SNR < 13.0 dB => 3 bars 1.0 dB <= RS_SNR < 4.5 dB => 2 bars
* -3.0 dB <= RS_SNR < 1.0 dB 1 bar RS_SNR < -3.0 dB/No Service Antenna
* Icon Only
*/
if (mLteRssnr > 300) snrIconLevel = -1;
else if (mLteRssnr >= 130) snrIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 45) snrIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= 10) snrIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRssnr >= -30) snrIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRssnr >= -200)
snrIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
As far as I can tell looking at the code (this is responsible for the number of bars displayed), that it's only LTE that changed from mr0 to mr1.
Probably new radios coming with 4.2 that play into this somehow. Can't imagine they would arbitrarily change the method of displaying signal strength in the notification bar.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
Probably new radios coming with 4.2 that play into this somehow. Can't imagine they would arbitrarily change the method of displaying signal strength in the notification bar.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
Doubt it. Not sure but they changed the mechanism a bit I think. Also this was 4.0.2:
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -90) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -100) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -110) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -118) levelLteRsrp = SIGNAL_STRENGTH_POOR;
else levelLteRsrp = 0;
which was more lenient about showing more bars than 4.2 and 4.0.4 introduced the first signal change for LTE.
As I posted this on rootzwiki I thought I'd share the commit related as someone there posted it for me:
https://github.com/android/platform_frameworks_base/commit/a44b137648c44cc29a8ce43f44a7934ff8045135#telephony/java/android/telephony/SignalStrength.java
Basically it's only a change to signal strength reporting. Would new radios help? I doubt it as signal is hardware/surroundings related.
tiny4579 said:
Basically it's only a change to signal strength reporting. Would new radios help? I doubt it as signal is hardware/surroundings related.
Click to expand...
Click to collapse
If the new radio firmware is interpreting reporting signal levels differently, then the dB values sent to the OS would need a different interpretation. I'm not an expert, but this is my only logical explanation.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
If the new radio firmware is interpreting reporting signal levels differently, then the dB values sent to the OS would need a different interpretation. I'm not an expert, but this is my only logical explanation.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
The change is simply a change in reporting bars. Signal never changed at all. There's no code in any ROM that affects signal itself. What changed I thought was clear in the commit.
The calculations based on SNR and RSRP were adjusted for determining number of bars for LTE. The lowest value wins. This is actually more to unify the different network modes. Also the 3g/CDMA signal uses the weaker of the two for bar reporting instead of always reporting CDMA.
tiny4579 said:
The change is simply a change in reporting bars. Signal never changed at all. There's no code in any ROM that affects signal itself. What changed I thought was clear in the commit.
The calculations based on SNR and RSRP were adjusted for determining number of bars for LTE. The lowest value wins. This is actually more to unify the different network modes. Also the 3g/CDMA signal uses the weaker of the two for bar reporting instead of always reporting CDMA.
Click to expand...
Click to collapse
I read your post and understand what you are saying. What I'm saying is that new radio firmware may "hear" signal levels differently, necessitating a change in the OS code that tells how many signal bars to display for a corresponding perceived signal strength. It's a logical explanation for that change in the android code. I have no doubt that new radio firmware will be pushed with the Toro update when it gets released in another few months.
Sent from my Xoom using xda premium
tiny4579 said:
I've noticed some users have reported inferior signal on Android 4.2 on the LTE Gnex. This is actually not true. In fact below is the related function that changed from 4.1.2 to 4.2.
Jellybean 4.1.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp == -1) levelLteRsrp = 0;
else if (mLteRsrp >= -95) levelLteRsrp = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -105) levelLteRsrp = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -115) levelLteRsrp = SIGNAL_STRENGTH_MODERATE;
else levelLteRsrp = SIGNAL_STRENGTH_POOR;
if (mLteRssnr == INVALID_SNR) levelLteRssnr = 0;
else if (mLteRssnr >= 45) levelLteRssnr = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 10) levelLteRssnr = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= -30) levelLteRssnr = SIGNAL_STRENGTH_MODERATE;
else levelLteRssnr = SIGNAL_STRENGTH_POOR;
int level;
if (mLteRsrp == -1)
level = levelLteRssnr;
else if (mLteRssnr == INVALID_SNR)
level = levelLteRsrp;
else
level = (levelLteRssnr < levelLteRsrp) ? levelLteRssnr : levelLteRsrp;
if (DBG) log("Lte rsrp level: "+levelLteRsrp
+ " snr level: " + levelLteRssnr + " level: " + level);
return level;
}
JB 4.2:
https://github.com/android/platform...ny/java/android/telephony/SignalStrength.java
Code:
if (mLteRsrp > -44) rsrpIconLevel = -1;
else if (mLteRsrp >= -85) rsrpIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRsrp >= -95) rsrpIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRsrp >= -105) rsrpIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRsrp >= -115) rsrpIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRsrp >= -140) rsrpIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
/*
* Values are -200 dB to +300 (SNR*10dB) RS_SNR >= 13.0 dB =>4 bars 4.5
* dB <= RS_SNR < 13.0 dB => 3 bars 1.0 dB <= RS_SNR < 4.5 dB => 2 bars
* -3.0 dB <= RS_SNR < 1.0 dB 1 bar RS_SNR < -3.0 dB/No Service Antenna
* Icon Only
*/
if (mLteRssnr > 300) snrIconLevel = -1;
else if (mLteRssnr >= 130) snrIconLevel = SIGNAL_STRENGTH_GREAT;
else if (mLteRssnr >= 45) snrIconLevel = SIGNAL_STRENGTH_GOOD;
else if (mLteRssnr >= 10) snrIconLevel = SIGNAL_STRENGTH_MODERATE;
else if (mLteRssnr >= -30) snrIconLevel = SIGNAL_STRENGTH_POOR;
else if (mLteRssnr >= -200)
snrIconLevel = SIGNAL_STRENGTH_NONE_OR_UNKNOWN;
As far as I can tell looking at the code (this is responsible for the number of bars displayed), that it's only LTE that changed from mr0 to mr1.
Click to expand...
Click to collapse
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
mb3030 said:
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Weird. My LTE signal and download speeds didn't change a bit. What band is VZW using where you are?
Sent from my Nexus 7 using Tapatalk 2
mb3030 said:
You can say this and it might be true, but to flat out say that nothing going on is short sighted. Were you also someone that claimed the n4 could never hold lte BC it lacked an amplifier?
I may not be a Dev for android, but I'm no tech idiot. I code SAS, STATA and a few other stats and db languages. I've been on android since day one and always tinkered around.
I've eliminated every variable possible between the a 4.1 build and a 4.2 build and I can tell you, for me, without a doubt I am getting slower DL speeds on 4.2.
I have flashed back and forth about five times now checking locations where I know the average speeds (my work, my home, my in laws etc...) And in every single location my download speeds are approximately half when using 4.2.
I'm not saying I have the answers, but its not a placebo effect with the way the bars are presented. Something is definitely affecting DL speeds for me on 4.2.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
I'm not saying download speeds are not affected just that there's hard evidence that the signal bars changed to a new algorithm and signal didn't change for me. Can you point in 4.2 an actual change that would affect more than just bars?
I made no claims on the n4. That statement sounds a bit rude.
Sent from my Galaxy Nexus using Tapatalk 2
raw snr value
Is there a mod that displays the raw snr value in the navbar instead of bars?
Maybe I sound a bit rude BC you came into the muzzy thread dismissed my claims and then referred me to this thread, which also dismisses the claims. You then show some code as "proof". I've tested this on my buddy's gnex as well and it has the same issue.
I live in NY and I'm picking up band 13 to answer the other question.
Sent from my Nexus 4 using xda app-developers app
My claims were only to address the change in signal speed and I was trying to give assurance that people's signals did not get worse. Now download speeds could be a result of not having full 4.2 binaries as you know that the binaries Google releases aren't all that's needed for a build of a ROM. Probably the proprietaries from verizon need to be updated to be more compatible. I can see how that may be the case. However my initial post was about the signal and signal only. I didn't mean to start an argument and apologize.
tiny4579 said:
My claims were only to address the change in signal speed and I was trying to give assurance that people's signals did not get worse. Now download speeds could be a result of not having full 4.2 binaries as you know that the binaries Google releases aren't all that's needed for a build of a ROM. Probably the proprietaries from verizon need to be updated to be more compatible. I can see how that may be the case. However my initial post was about the signal and signal only. I didn't mean to start an argument and apologize.
Click to expand...
Click to collapse
This. ^^^^^^
New radios will be packaged with the Verizon approved OTA. New OS + new binaries + old radio firmware= suboptimal results.
Sent from my Galaxy Nexus using xda premium
Winesnob said:
This. ^^^^^^
New radios will be packaged with the Verizon approved OTA. New OS + new binaries + old radio firmware= suboptimal results.
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
We actually may not even have all the new binaries but I'm not an expert on that. What I do know is good things should come from a Verizon OTA to 4.2 - if they release it.
I wonder if anyone's tried tweeting verizonwireless or vzwsupport about Android 4.2. Since I refuse to get a twitter account I haven't done it yet.
tiny4579 said:
We actually may not even have all the new binaries but I'm not an expert on that. What I do know is good things should come from a Verizon OTA to 4.2 - if they release it.
I wonder if anyone's tried tweeting verizonwireless or vzwsupport about Android 4.2. Since I refuse to get a twitter account I haven't done it yet.
Click to expand...
Click to collapse
You can Tweet until your battery is dead, and it won't do any good. Expect the official update in late January, and a leaked OTA sometime late December or early January.
Sent from my Galaxy Nexus using xda premium
Glad to hear its a software fix that's making me believe I have bad signal...come on Verizon bring on ota 4.2
tiny4579 said:
...good things should come from a Verizon OTA to 4.2 - if they release it.
Click to expand...
Click to collapse
http://www.randomphantasmagoria.com/myths-about-android-updates-on-the-verizon-galaxy-nexus/ - Myth #3.
mb3030 said:
Maybe I sound a bit rude BC you came into the muzzy thread dismissed my claims and then referred me to this thread, which also dismisses the claims. You then show some code as "proof". I've tested this on my buddy's gnex as well and it has the same issue.
I live in NY and I'm picking up band 13 to answer the other question.
Sent from my Nexus 4 using xda app-developers app
Click to expand...
Click to collapse
Strange. I'm on AWS LTE and wasn't affected at all, I'll be on a different band this weekend and I'll check again, seems it might be a band issue related to location.
Sent from my Nexus 7 using Tapatalk 2
So I just did a speed test on cm10.1 and for 3g I got 1.5mbps down and for 4g I got 13mbps down. That's about normal for my area. I can link a post explaining how little effect the ROM has on speed but from a testing perspective I don't see anything speed related broken by 4.2.
Sent from my Galaxy Nexus using Tapatalk 2
Well, one of the graphical glitches we've been experiencing with KitKat on the Galaxy Nexus is black boxes appearing in the AOSP browser and anything using the rendering engine the browser uses. I looked through some logs and found this:
Code:
E/IMGSRV (31385): :0: gralloc_module_map: Mismatching lock usage bits 0xP...FHWR=0x00000033 vs requested usage bits 0xP...FHWR=0x00000100
E/IMGSRV (31385): :0: MapBufferObtainParams: Mapping buffer failed
E/IMGSRV (31385): :0: WSEGL_GetDrawableParameters: Failed to obtain buffer parameters
E/chromium(31385): [ERROR:gl_image_egl.cc(36)] Error creating EGLImage: 12300
that file is at external/chromium_org/ui/gl/gl_image_egl.cc in my AOSP directory. This seemed to pop up in the logs whenever a black box appeared. Figuring out exactly what's causing the problem is a little over my head, I don't have much experience with OpenGL ES/EGL/whatever, but I figured some other dev might have a better idea as to what's going on.
Another thing that has been happening is complete lock-ups of the phone, some kernels requiring a battery pull to reboot and other kernels just do a reboot anyways. This is some stuff I pulled from logcats when the screen completely froze, linebreaks represent random junk being removed:
Code:
W/SurfaceFlinger( 139): setTransactionState timed out waiting for previous animation frame
### Screen is now completely frozen here.
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
W/ManagedEGLContext(31146): doTerminate failed: EGL count is 3 but managed count is 1
E/ActivityManager( 462): ANR in com.android.systemui
E/ActivityManager( 462): PID: 588
E/ActivityManager( 462): Reason: Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
E/ActivityManager( 462): Load: 4.38 / 2.79 / 2.31
E/ActivityManager( 462): CPU usage from 3613ms to -2817ms ago with 99% awake:
E/ActivityManager( 462): 84% 788/com.google.android.googlequicksearchbox: 0% user + 84% kernel / faults: 30 minor
E/ActivityManager( 462): 24% 462/system_server: 15% user + 9.3% kernel / faults: 1862 minor 29 major
E/ActivityManager( 462): 5.1% 151/adbd: 0.6% user + 4.5% kernel / faults: 16 minor
E/ActivityManager( 462): 3.7% 737/com.android.phone: 1.8% user + 1.8% kernel / faults: 1612 minor 5 major
E/ActivityManager( 462): 0.9% 588/com.android.systemui: 0.6% user + 0.3% kernel / faults: 662 minor 10 major
E/ActivityManager( 462): 0.9% 5101/com.google.android.apps.plus: 0.6% user + 0.2% kernel / faults: 1185 minor 2 major
E/ActivityManager( 462): 1.3% 753/com.sec.android.internal.ims: 0.6% user + 0.7% kernel / faults: 1740 minor 2 major
E/ActivityManager( 462): 1.3% 2411/kworker/1:2: 0% user + 1.3% kernel
E/ActivityManager( 462): 0.1% 768/com.android.nfc: 0.1% user + 0% kernel / faults: 2029 minor 1 major
E/ActivityManager( 462): 0.9% 5267/com.google.android.youtube: 0.3% user + 0.6% kernel / faults: 189 minor
E/ActivityManager( 462): 0.3% 31385/com.android.browser: 0.3% user + 0% kernel / faults: 240 minor
E/ActivityManager( 462): 0.7% 4410/android.process.media: 0.3% user + 0.4% kernel / faults: 45 minor
E/ActivityManager( 462): 0.7% 5180/com.google.android.music:main: 0.6% user + 0.1% kernel / faults: 9 minor
E/ActivityManager( 462): 0.6% 4053/kworker/0:0: 0% user + 0.6% kernel
E/ActivityManager( 462): 0.6% 31500/com.facebook.katana: 0.1% user + 0.4% kernel / faults: 42 minor
E/ActivityManager( 462): 0.4% 2724/com.google.process.gapps: 0.3% user + 0.1% kernel / faults: 10 minor
E/ActivityManager( 462): 0% 96/mmcqd/0: 0% user + 0% kernel
E/ActivityManager( 462): 0% 5247/com.google.android.setupwizard: 0% user + 0% kernel / faults: 9 minor
E/ActivityManager( 462): +0% 5510/logcat: 0% user + 0% kernel
E/ActivityManager( 462): 70% TOTAL: 13% user + 55% kernel + 1.5% iowait
E/ActivityManager( 462): CPU usage from 1773ms to 2326ms later:
E/ActivityManager( 462): 94% 788/com.google.android.googlequicksearchbox: 0% user + 94% kernel
E/ActivityManager( 462): 90% 788/equicksearchbox: 0% user + 90% kernel
E/ActivityManager( 462): 16% 462/system_server: 7.2% user + 9% kernel / faults: 3 minor
E/ActivityManager( 462): 5.4% 474/HeapTrimmerDaem: 5.4% user + 0% kernel
E/ActivityManager( 462): 5.4% 483/ActivityManager: 0% user + 5.4% kernel
E/ActivityManager( 462): 1.8% 567/ConnectivitySer: 1.8% user + 0% kernel
E/ActivityManager( 462): 1.8% 783/Binder_4: 1.8% user + 0% kernel
E/ActivityManager( 462): 1.8% 737/com.android.phone: 1.8% user + 0% kernel / faults: 4 minor
E/ActivityManager( 462): 1.1% 5101/com.google.android.apps.plus: 1.1% user + 0% kernel / faults: 1 minor
E/ActivityManager( 462): 1.1% 5116/Binder_2: 1.1% user + 0% kernel
E/ActivityManager( 462): 1.2% 5267/com.google.android.youtube: 1.2% user + 0% kernel / faults: 13 minor
E/ActivityManager( 462): 56% TOTAL: 7.2% user + 49% kernel
I/ActivityManager( 462): Killing 588:com.android.systemui/u0a7 (adj -12): background ANR
I/art ( 5267): Wrote stack traces to '/data/anr/traces.txt'
W/SurfaceFlinger( 139): setTransactionState timed out waiting for previous animation frame
E/ActivityManager( 462): ANR in com.android.settings (com.android.settings/.Settings)
E/ActivityManager( 462): PID: 30674
E/ActivityManager( 462): Reason: Input dispatching timed out (Waiting because the touched window has not finished processing the input events that were previously delivered to it.)
E/ActivityManager( 462): Load: 4.33 / 2.83 / 2.33
E/ActivityManager( 462): CPU usage from 7196ms to 0ms ago:
E/ActivityManager( 462): 95% 788/com.google.android.googlequicksearchbox: 0% user + 95% kernel
E/ActivityManager( 462): 8% 462/system_server: 6.8% user + 1.2% kernel / faults: 870 minor 3 major
E/ActivityManager( 462): 1.6% 5267/com.google.android.youtube: 1.1% user + 0.5% kernel / faults: 204 minor 5 major
E/ActivityManager( 462): 0.8% 31500/com.facebook.katana: 0.2% user + 0.5% kernel / faults: 28 minor 8 major
E/ActivityManager( 462): 0.5% 2724/com.google.process.gapps: 0.2% user + 0.2% kernel / faults: 5 minor
E/ActivityManager( 462): 0.5% 4410/android.process.media: 0.2% user + 0.2% kernel / faults: 24 minor
E/ActivityManager( 462): 0.4% 737/com.android.phone: 0.1% user + 0.2% kernel / faults: 7 minor
E/ActivityManager( 462): 0.4% 753/com.sec.android.internal.ims: 0.4% user + 0% kernel / faults: 156 minor
E/ActivityManager( 462): 0.4% 5180/com.google.android.music:main: 0.4% user + 0% kernel / faults: 7 minor
E/ActivityManager( 462): 0.2% 151/adbd: 0.1% user + 0.1% kernel
E/ActivityManager( 462): 0% 118/irq/206-mms_ts: 0% user + 0% kernel
E/ActivityManager( 462): 0% 136/netd: 0% user + 0% kernel / faults: 8 minor
E/ActivityManager( 462): 0.1% 4053/kworker/0:0: 0% user + 0.1% kernel
E/ActivityManager( 462): 0.1% 5101/com.google.android.apps.plus: 0% user + 0.1% kernel / faults: 3 minor
E/ActivityManager( 462): 0.1% 5247/com.google.android.setupwizard: 0.1% user + 0% kernel / faults: 4 minor
E/ActivityManager( 462): 0% 31146/ru.mail.games.android.JungleHeat: 0% user + 0% kernel / faults: 148 minor
E/ActivityManager( 462): 56% TOTAL: 5% user + 50% kernel + 1.1% iowait
E/ActivityManager( 462): CPU usage from 1729ms to 2249ms later:
E/ActivityManager( 462): 96% 788/com.google.android.googlequicksearchbox: 0% user + 96% kernel
E/ActivityManager( 462): 98% 788/equicksearchbox: 0% user + 98% kernel
E/ActivityManager( 462): 11% 462/system_server: 5.7% user + 5.7% kernel / faults: 1 minor
E/ActivityManager( 462): 5.7% 474/HeapTrimmerDaem: 5.7% user + 0% kernel
E/ActivityManager( 462): 3.8% 483/ActivityManager: 0% user + 3.8% kernel
E/ActivityManager( 462): 52% TOTAL: 2.8% user + 50% kernel
I/art ( 788): Wrote stack traces to '/data/anr/traces.txt'
I/Process ( 462): Sending signal. PID: 462 SIG: 3
I/art ( 462): Thread[3,tid=469,WaitingInMainSignalCatcherLoop,Thread*=0x414c3250,peer=0x64d4a238,"Signal Catcher"]: reacting to signal 3
I/art ( 462): Wrote stack traces to '/data/anr/traces.txt'
I/DEBUG ( 137): timed out waiting for tid=139 to die
I/DEBUG ( 137): ptrace detach from 139 failed: No such process
I/DEBUG ( 137): debuggerd committing suicide to free the zombie!
I/DEBUG ( 5560): debuggerd: Nov 15 2013 13:07:12
I/Process ( 462): Sending signal. PID: 462 SIG: 3
I/art ( 462): Thread[3,tid=469,WaitingInMainSignalCatcherLoop,Thread*=0x414c3250,peer=0x64d4a238,"Signal Catcher"]: reacting to signal 3
I/Process ( 462): Sending signal. PID: 737 SIG: 3
I/art ( 737): Thread[3,tid=744,WaitingInMainSignalCatcherLoop,Thread*=0x41557b08,peer=0x64d52a60,"Signal Catcher"]: reacting to signal 3
I/art ( 462): Wrote stack traces to '/data/anr/traces.txt'
I/art ( 737): Wrote stack traces to '/data/anr/traces.txt'
I/DEBUG ( 5560): timed out waiting for tid=139 to die
I/DEBUG ( 5560): ptrace detach from 139 failed: No such process
I/DEBUG ( 5560): debuggerd committing suicide to free the zombie!
I/DEBUG ( 5573): debuggerd: Nov 15 2013 13:07:12
I/Watchdog_N( 462): dumpKernelStacks
I/Process ( 462): Sending signal. PID: 462 SIG: 9
W/Watchdog( 462): *** WATCHDOG KILLING SYSTEM PROCESS: Blocked in monitor com.android.server.wm.WindowManagerService on foreground thread (android.fg), Blocked in handler on ActivityManager (ActivityManager)
W/Watchdog( 462): foreground thread stack trace:
W/Watchdog( 462): at com.android.server.wm.WindowManagerService.monitor(WindowManagerService.java:10695)
W/Watchdog( 462): at com.android.server.Watchdog$HandlerChecker.run(Watchdog.java:147)
W/Watchdog( 462): at android.os.Handler.handleCallback(Handler.java:733)
W/Watchdog( 462): at android.os.Handler.dispatchMessage(Handler.java:95)
W/Watchdog( 462): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 462): at android.os.HandlerThread.run(HandlerThread.java:61)
W/Watchdog( 462): ActivityManager stack trace:
W/Watchdog( 462): at android.view.SurfaceControl.nativeCreate(Native Method)
W/Watchdog( 462): at android.view.SurfaceControl.<init>(SurfaceControl.java:238)
W/Watchdog( 462): at com.android.server.wm.WindowStateAnimator.createSurfaceLocked(WindowStateAnimator.java:686)
W/Watchdog( 462): at com.android.server.wm.WindowManagerService.relayoutWindow(WindowManagerService.java:2885)
W/Watchdog( 462): at com.android.server.wm.Session.relayout(Session.java:190)
W/Watchdog( 462): at android.view.ViewRootImpl.relayoutWindow(ViewRootImpl.java:5114)
W/Watchdog( 462): at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1412)
W/Watchdog( 462): at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:998)
W/Watchdog( 462): at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:5582)
W/Watchdog( 462): at android.view.Choreographer$CallbackRecord.run(Choreographer.java:749)
W/Watchdog( 462): at android.view.Choreographer.doCallbacks(Choreographer.java:562)
W/Watchdog( 462): at android.view.Choreographer.doFrame(Choreographer.java:532)
W/Watchdog( 462): at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:735)
W/Watchdog( 462): at android.os.Handler.handleCallback(Handler.java:733)
W/Watchdog( 462): at android.os.Handler.dispatchMessage(Handler.java:95)
W/Watchdog( 462): at android.os.Looper.loop(Looper.java:137)
W/Watchdog( 462): at com.android.server.am.ActivityManagerService$AThread.run(ActivityManagerService.java:1848)
W/Watchdog( 462): *** GOODBYE!
### Bunch of services just die here, no more logs come in after.
Also attached is the /data/anr/traces.txt, pulled from the device once the logcats stopped coming in.
I just haven't really seen much for logs in attempts to debug this, so hopefully I've been able to get something substantial here to work with. I'm doing what I can to look through the logs, grep my AOSP directory for things in it to find where stuff is messing up, and checking the git logs to see what's changed in those files and related files since 4.3. I know there are lots of people here much more talented and skilled than myself, and I feel confident that we can all figure this stuff out before December, or at least the middle of it.
EDIT: Based on feedback from some users of my ROM, other ROMs, and some experience with the freezes myself, it seems to happen when doing one thing and then quickly trying to do something else, one thing that usually ends up triggering it for myself is unlocking the phone and then nearly immediately pressing the Dialer icon to open the Dialer app. The app doesn't even open, the screen freezes with the little glow around the icon and that's it. Looks to be related to the:
Code:
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
part of the log. Seems an extra EGL Context is being created, but the maximum allowable is 1? Something like that? Again, not a lot of experience with OpenGL ES for me.
I'm also now attaching a couple logcats from a user of my ROM who was able to get a couple of them, @sonic147862, so thanks to him. The second logcat has some very interesting GL stuff at the bottom of it as well.
not sure if this helps but
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
seems to come from the code in https://github.com/android/platform...gl/java/android/opengl/ManagedEGLContext.java
lines 111- 126
Code:
// Need to check how many EGL contexts are actually running,
// to compare with how many we are managing.
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display = egl.eglGetDisplay(EGL_DEFAULT_DISPLAY);
if (display == EGL_NO_DISPLAY) {
Log.w(TAG, "doTerminate failed: no display");
return false;
}
if (EGLImpl.getInitCount(display) != sActive.size()) {
Log.w(TAG, "doTerminate failed: EGL count is " + EGLImpl.getInitCount(display)
+ " but managed count is " + sActive.size());
return false;
}
so what exactly might happen if that was removed? I'm not a coding expert but it might at least get us past that particular error and show other ones that might need fixed
metalspring said:
not sure if this helps but
W/ManagedEGLContext(31385): doTerminate failed: EGL count is 2 but managed count is 1
seems to come from the code in https://github.com/android/platform...gl/java/android/opengl/ManagedEGLContext.java
lines 111- 126
Code:
// Need to check how many EGL contexts are actually running,
// to compare with how many we are managing.
EGL10 egl = (EGL10) EGLContext.getEGL();
EGLDisplay display = egl.eglGetDisplay(EGL_DEFAULT_DISPLAY);
if (display == EGL_NO_DISPLAY) {
Log.w(TAG, "doTerminate failed: no display");
return false;
}
if (EGLImpl.getInitCount(display) != sActive.size()) {
Log.w(TAG, "doTerminate failed: EGL count is " + EGLImpl.getInitCount(display)
+ " but managed count is " + sActive.size());
return false;
}
so what exactly might happen if that was removed? I'm not a coding expert but it might at least get us past that particular error and show other ones that might need fixed
Click to expand...
Click to collapse
looks like the managed EGL count does not exceed 1 at any case, so we need to find the code for setting sActive.size() .
i think removing this part of the code well lead to even further errors and freezes, but lets wait for some experienced developers for their comments.
gh0stslayer said:
looks like the managed EGL count does not exceed 1 at any case, so we need to find the code for setting sActive.size() .
i think removing this part of the code well lead to even further errors and freezes, but lets wait for some experienced developers for their comments.
Click to expand...
Click to collapse
sActive is an array.
sActive.size() depends on how may times sActive.add(this); is called.
sActive.size() increase any time a new ManagedEGLContext is created.
I think the error is not in sActive,size() being 1, but in EGLImpl.getInitCount(display) returning 2, while only 1 ManagedEGLContext has been created.
I'm trying to see where EGLImpl.getInitCount() is defined...
UPDATE: can't understand where those "native" functions can be found for GNex...Which is the correct repo for C stuff for GNex?
http://review.cyanogenmod.org/#/c/54291/
Looks like it was tracked down, Google basically had us just beta testing this stuff for them, lol.
I know this is an old thread.
But all other ROMs except for CM still experience rare freezes/reboots(even on 4.4.2 which has the Refactor gpuMemoryBuffer patch included already).
Can anyone please list out all the commits that eventually let to complete eradication of the freeze/reboot issue on CM?
Thanks Guys!
sd3993 said:
I know this is an old thread.
But all other ROMs except for CM still experience rare freezes/reboots(even on 4.4.2 which has the Refactor gpuMemoryBuffer patch included already).
Can anyone please list out all the commits that eventually let to complete eradication of the freeze/reboot issue on CM?
Thanks Guys!
Click to expand...
Click to collapse
I am also still wondering about this. This is the only thread I've found with accurate, concise information concerning the lockup->reboot behavior that almost all of the Galaxy Nexus KitKat ROMs are experiencing, except for CM. I don't want to just rip off CM's code, but I'd like to actually see if we could figure out what's going on and how it could be fixed. I've also isolated these few lines consistently from logs right before reboots occur:
Code:
E/IMGSRV ( 5116): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=6)
W/GraphicBufferMapper( 5116): registerBuffer(0x46168508) failed -22 (Invalid argument)
E/GraphicBuffer( 5116): unflatten: registerBuffer failed: Invalid argument (-22)
I/ActivityManager( 454): Process com.android.musicfx (pid 5313) has died.
I/Choreographer( 5116): Skipped 35 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
I/Choreographer( 454): Skipped 294 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
baldwinguy77 said:
I am also still wondering about this. This is the only thread I've found with accurate, concise information concerning the lockup->reboot behavior that almost all of the Galaxy Nexus KitKat ROMs are experiencing, except for CM. I don't want to just rip off CM's code, but I'd like to actually see if we could figure out what's going on and how it could be fixed. I've also isolated these few lines consistently from logs right before reboots occur:
Code:
E/IMGSRV ( 5116): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=6)
W/GraphicBufferMapper( 5116): registerBuffer(0x46168508) failed -22 (Invalid argument)
E/GraphicBuffer( 5116): unflatten: registerBuffer failed: Invalid argument (-22)
I/ActivityManager( 454): Process com.android.musicfx (pid 5313) has died.
I/Choreographer( 5116): Skipped 35 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
I/Choreographer( 454): Skipped 294 frames! The application may be doing too much work on its main thread.
W/SurfaceFlinger( 128): setTransactionState timed out waiting for previous animation frame
Click to expand...
Click to collapse
I've been hunting around the a little and i narrowed down the error to these two files
/frameworks/native/libs/ui/GraphicBuffer.cpp & /frameworks/native/libs/ui/GraphicBufferMapper.cpp
I've tried a few things to fix the errors but I wasn't successful.
Also I have no idea where IMGSRV or 'gralloc_register_buffer' are located? Do you know where they are?
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
metalspring said:
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
ill look around in there tonight..never know what cm has up their sleeve.
pattyboi:) said:
ill look around in there tonight..never know what cm has up their sleeve.
Click to expand...
Click to collapse
metalspring said:
I'm starting to wonder if the fix for the reboots is hidden somewhere completely unexpected, I know I've personally tried pulling in just about everything related to graphics in cm's frameworks_native repo and still getting the reboots on omnirom
Let's just hope the fix isn't hidden in frameworks/base (since that's one of the repos that gets the most commits)
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse
I scanned through the commits in /harware/libhardware too and pulled almost all commits related to graphics since 1st Nov but none really helped :/
I guess it's time to take a deep breath and dive into /frameworks/base then!
---------- Post added at 11:17 AM ---------- Previous post was at 10:29 AM ----------
I took a quick look through the commits in external/chromium_org/
Here the commits I found interesting.
https://github.com/CyanogenMod/andr...mmit/18760af88a405ded53cf524d9a273b217e759807
https://github.com/CyanogenMod/andr...mmit/294545aa54ddff00ccb2f1188f231ff0ebbd9386
https://github.com/CyanogenMod/andr...mmit/e1049c797e39f4f9f9753731b3c7054473db1b45
https://github.com/CyanogenMod/andr...mmit/e31b3128a419654fd14003d6117caa8da32697e7
Plus can anyone verify that this commit https://github.com/CyanogenMod/andr...mmit/dd37648c2dfb0405e11028c264ef37200ef75001 is already included in AOSP 4.4.2? Because i THING that all reboot/freeze issues were fixed right after CM merged in this commit into 4.4 (4.4.1 and 4.4.2 weren't released back then.
Allright guys, @akash3656 built an Omnirom using metalspring's device trees and a commit found by @steven676 (http://forum.xda-developers.com/showpost.php?p=49009667&postcount=574) that really worked against graphic glitches & reboots.
I've been messing around and those gralloc buffers still got messed up but It will not make the device reboot or display weird graphical glitches. However, the affected app become choppy. just kill that thread for now
Loureiro said:
Allright guys, @akash3656 built an Omnirom using metalspring's device trees and a commit found by @steven676 (http://forum.xda-developers.com/showpost.php?p=49009667&postcount=574) that really worked against graphic glitches & reboots.
I've been messing around and those gralloc buffers still got messed up but It will not make the device reboot or display weird graphical glitches. However, the affected app become choppy. just kill that thread for now
Click to expand...
Click to collapse
No. I managed to trigger freezes even with the fix. Glitch is still there :/
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
sd3993 said:
No. I managed to trigger freezes even with the fix. Glitch is still there :/
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Dammit. Guess I didn't stressed the rom that much. I was able too see throught adb logcat the buffers not being registered properly and all those IMGSRV errors, and none of those glitches appear.
I'll continue trying to trigger a freeze.
Loureiro said:
Dammit. Guess I didn't stressed the rom that much. I was able too see throught adb logcat the buffers not being registered properly and all those IMGSRV errors, and none of those glitches appear.
I'll continue trying to trigger a freeze.
Click to expand...
Click to collapse
Open G+. Click on a link that will open in a browser. One the page loads fully navigate a little. Then click on recents button and choose G+. You'll see the GraphicBufferMapper errors in logcat and the black boxes in G+.
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
I'm trying to trigger, but without success so far.
got
E/IMGSRV gralloc_register_buffer: Cannot register a buffer twice (ID=6)
E/GraphicBuffer unflatten : registerBuffer failed: Invalid argument (-22)
and a warning related to GraphicBufferMapper
registerBuffer(...) failed -22 (Invalid argument)
But didn't saw any black boxes. I'm still jumping between aosp browser / dialer / G+ / tapatalk / settings using recents button. Those 2 erros keep showing on logcat but there's no graphical glitches nor reboots.
As far as I understood, it's normal that GraphicBuffer unflatten() still throws that error. But now with that commit, it clears the buffer when the error occurs, not poiting to anywhere else, that was causing graphic corruption.
The reboots are rare. But i don't think that error should occur at all. If i had a Nexus 4 or 5 i could test it on those. Do you know anyone with those devices? Maybe you could ask them to see id these occurs on their devices?
Sent from my Galaxy Nexus using XDA Premium 4 mobile app
sd3993 said:
Plus can anyone verify that this commit https://github.com/CyanogenMod/andr...mmit/dd37648c2dfb0405e11028c264ef37200ef75001 is already included in AOSP 4.4.2? Because i THING that all reboot/freeze issues were fixed right after CM merged in this commit into 4.4 (4.4.1 and 4.4.2 weren't released back then.
Click to expand...
Click to collapse
No, it is not part of AOSP at the moment -- that comes from Chromium sometime around the Chrome 31 development cycle, and AOSP is still on Chrome 30.
To be clear, black boxes in WebView is a different bug than the one causing device crashes and screen corruption in random apps, and the workaround for one will not fix the other -- you'll need both patches applied.
steven676 said:
No, it is not part of AOSP at the moment -- that comes from Chromium sometime around the Chrome 31 development cycle, and AOSP is still on Chrome 30.
To be clear, black boxes in WebView is a different bug than the one causing device crashes and screen corruption in random apps, and the workaround for one will not fix the other -- you'll need both patches applied.
Click to expand...
Click to collapse
Yes i figured it out with a little bit of research
BTW the patch(the one that modifies GraphicBuffer.cpp & IGraphicBufferProducer.cpp) which you linked in the Nexus S didn't work. Reboots are still an issue.
I'm still hunting around.
So I merged in this commit that other people have been talking about quite a lot and my users haven't reported any reboots yet.