KitKat: Fixing The "Black Boxes", among other things - Samsung Galaxy Nexus

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.

Related

[Q] HTC Desire Lags alot,any Fix?

Hi,for the past two weeks,i discovered my HTC desire (unrooted,unbranded and unlocked,on froyo) has been laging like crazy not just web browsing but the entire OS.for example,the smooth transition between each screen (Home screen and the rest) is gone.Also,accessing menus and apps tend to lag, basically everything.You can easily tell that the device is definitely buggy.
Could anyone please recommend a fix different from hard/factory reset?As I've put so much work into device i.e. customizing screens,sorting out apps,and most importantly getting all my email accounts functioning.
It would be a big shame if I have to do a complete factory reset and if that's the only solution for now,will a future software update resolve this issue (lags)? And if i decide to go ahead with the hard reset,will the device let me do automatic backup of the following details:
* Text and multimedia messages
* Settings in the Messages application
* Web bookmarks
* Keyboard dictionary
* Settings in your phone that fall under these categories:
o Wireless & networks
o Sound & display
o Location
o Applications
o Date & time
o Language & keyboard - only the Locale setting
Thanks
what have you done to it?!?!
since day 1, I had loads of apps, no lag, loads of music, movies, pictures etc.. no lag. now, counting.. counted.. 48 rows x 4 columns of apps.. = 192 apps including all the sense ones.. still NO LAG! do a factory reste and see if that works, if not, try flashing a different ROM laterz.
Are you using a task killer?
Invisible Elf said:
Are you using a task killer?
Click to expand...
Click to collapse
I used one called Advanced Task pro but uninstalled it immediately as soon as I found out 'task killers' are more damaging .
Sent from my Archos5 using XDA App
Im underclocking my desire to 700mhz and even then, the only time it lags is the first few minutes after boot....
Sent from my HTC Desire using Tapatalk
Checked RAM usage?
Hi nasimdejai!
I have a similar problem after a day or two, when I have often browsed the web, searched for something and watched youtube vids in browser.
Is the problem after a reboot gone?
Have you checked if you are running out of mem? (Install e.g. Temp+CPU V2 from market and put the widget on your homescreen)
Because in my case, there are running a few instances of the android browser which are eating up my mem and don't get killed by the process managment.
To check this, install Terminal emulator and type in ps.
When there are more processes like com.android.browser or FP_DoPlay you have the same issue like I do. (see attachments)
I kill the unwanted/older instances with the command kill 5920 (PID number from process, see 1st attachment).
You can easily tell that the device is definitely buggy.
Click to expand...
Click to collapse
There is no "Galaxy S lag" type problem/bug that affects all Desires, so I think it is your configuration/setup, not the device itself per se!
My advice to you would be to take a Nandroid backup and then factory reset, so see if this "cures" your problem. If it does, chances are you have a rogue app that is causing your problems rather than a "system" setting, so you then have two realistic options.
1. Restore your Nandroid backup and start de-installing applications until performance becomes acceptable again. If you have something like Titanium Backup, you can always backup the app+data you wish to de-install, so that you can bring it back again easily if you require.
2. Start setting your device up from scratch again.
Note that if your phone is not rooted, you won't be able to make a Nandroid backup anyway, so you'll be left with option 2 only!
Regards,
Dave
hi floyd0815,thanks for the suggestions.I've got this app that displays memory (RAM) each time i use the device for any task be it browsing,youtube vids.And I could tell that some of these tasks do eat up memory but after completing said tasks,i immediately go into the "manage application" setting,clear the cache for each process/app used and then the RAM usually goes back to the previous size.Presently i've got 71MB of RAM and execution of processes/applications usually shaves 2MB or 3MB at most,off the current memory size.Alot of people tend to have way less RAM on their devices and still have fully function phones without lags.The reason for me being a bit worried.I'll either wait for the rumoured december update or do a factory reset if the problem persists.I'll try downloading Terminal emulator.Cheers
71MB of RAM????????? My Desire usually had 200MB of ram free before i rooted! Use a task Killer. Its nessecary. those things that tell you they are not are not always true. Get a good task killer like quick process killer or such. that should solve your problem.
Hi nasimdejai!
After a fresh boot, I have got about 120mb of free mem with the browser opened, but after 1-2 days it's going down to 70-40mb and stays there. Then it's sluggish. (e.g. FolderOrganizer onscreen-folder links open slowly,...) There I first started to clean the caches and logs, but that gave only a few mb's and the system stayed slow. Then I have seen those multiple browsers in the terminal.
I don't understand, why the android-process-managment doesn't kill the old browser instances but other processes that provide widgets?!
When I kill that old instances, I have up to 160mb+ of free RAM and the system is snappy again.
Do you have Astro (file manager) installed? If so, you can open it and press menu -> Tools -> Process manger -> Processes and look for FP_DoPlay (thats the browser). There it's shown how much RAM those processes need. (look at my 1st posts 2nd attachment)
Keep me updated about your Terminal emulator result! (ps)
P.S.: I don't use a task killer for killing running processes, only if something has crashed or as list of running apps.
shockem said:
Its nessecary. those things that tell you they are not are not always true. Get a good task killer like quick process killer or such. that should solve your problem.
Click to expand...
Click to collapse
Not again!
No task killers are *not* necessary. Some people perceive some benefit from using them, but in general as long as you don't have an errant app they are most certainly not necessary!
Also - the amount of free memory you have is not an good indicator of performance! Remember than by default Android does not "swap" and just because memory is being consumed doesn't mean that CPU cycles are.
If anything, freeing up memory by killing processes can actually slow the system down because the process might not be consuming any CPU cycles but may well be required later and so keeping it in memory will actually allow it to resume far quicker than it would do otherwise.
Regards,
Dave
Hi Dave!
I am not a killer too! ;-)
But my system gets really slow after a while. (1-2 days, depending on how often I use the browser)
Before I have seen the multiple browser instances, I tried to make it faster by clearing caches and logs with no big change.
I know "the amount of free memory you have is not a good indicator of performance" but it was the only thing I noticed when the system was getting sluggish.
And as you can see in the attachments of my 1st post here, the android browser needs A LOT OF RAM (4 instances: 150mb+) and doesn't get killed by the android process managment.
PLEASE type in a terminal ps > /sdcard/ps.txt to save the output onto your sd-card and then post it here, so we can see if your system does the same! (your desire should have been runing for a while)
THX in advance!
My ps attached. Note that I hadn't used the browser this morning (last time was last night), so I started it and opened all 4 windows to different sites before running ps.
It definitely sounds to me like the Android memory management is not running correctly on your device - have you done anything to it, or set up swap etc?
Regards,
Dave
@Dave
THX for the quick response!
In your system are 2 running browser processes (and some FP_DoPlay = flash?), which could be normal, but one of them (PID 4734) is old and maybe should have been closed by the system.
Would be nice to check later again, when a task manager tells you, that there is no running browser.
And no, I haven't done anything to the memory management or something else.
Leedroid 2.2d + sdfix kernel + bright silence theme
Radio ***09.05.30_2
This also happend on PinkyROM, after that I did a full wipe.
THX
EDIT: In /system/etc/sysctl.conf is standing "vm.swappines=1", so on my system is swapping enabled?!
floyd0815 said:
n your system are 2 running browser processes (and some FP_DoPlay = flash?), which could be normal, but one of them (PID 4734) is old and maybe should have been closed by the system.
Click to expand...
Click to collapse
I wouldn't expect the system to kill a process just because it is old if there is sufficient memory available.
EDIT: In /system/etc/sysctl.conf is standing "vm.swappines=1", so on my system is swapping enabled?!
Click to expand...
Click to collapse
Have you partitioned your SD card with a swap partition?
Regards,
Dave
I wouldn't expect the system to kill a process just because it is old if there is sufficient memory available.
Click to expand...
Click to collapse
Thats true and I don't know if your sys is running out of mem, but in my case, android should close those processes. (only ~40mb left)
I also read, that the "vm.oom_kill_allocating_task=1" in the sysctl.conf means, android kills the processes with the highest mem usage, but it doesn't! (in my case)
And I haven't made a swap partition or customized the sysctl.conf. (stock from LeeDroid 2.2d) Just read, that ...swappines=1 doesn't take an effect if you haven't got swap.
But now I changed "vm.oom_kill_allocating_task=0" and rebooted.
Lets see what happens!
floyd0815 said:
Thats true and I don't know if your sys is running out of mem, but in my case, android should close those processes. (only ~40mb left)
Click to expand...
Click to collapse
40mb left is nowhere near running low on resources IMO - killing at 40mb free is just a waste of 40mb memory.
And I haven't made a swap partition or customized the sysctl.conf. (stock from LeeDroid 2.2d) Just read, that ...swappines=1 doesn't take an effect if you haven't got swap.
Click to expand...
Click to collapse
I don't have a sysctl.conf file at all, so "stock" isn't always stock!
Regards,
Dave
T
foxmeister said:
40mb left is nowhere near running low on resources IMO - killing at 40mb free is just a waste of 40mb memory.
Click to expand...
Click to collapse
But I see the android process manager working to free RAM, kicking out apps but not the browser, which is huge?! With the sysctl.conf "vm.oom_kill_allocating_task=1"?!
I don't understand that and I don't care anymore.
I make me a script like:
Code:
#!/bin/sh
ps|grep com.android.browser|grep -v grep|awk '{print $1}'|xargs -r kill
exit
und Pasta!
I have the same problem, but i can't kill browsers through terminal emulator. Nothing happens when I enter kill *pid*
And fp_doplay isn't listed there it is listed in astro with 78mb! But i can't kill it there.
My terminal emulator ps after browser closing:
export PATH=/data/local/bin:$PATH
$ $ps
PID USER TIME COMMAND
1 0 0:03 /init
2 0 0:00 [kthreadd]
3 0 0:22 [ksoftirqd/0]
4 0 0:24 [events/0]
5 0 0:00 [khelper]
6 0 0:00 [ksmartass_up/0]
7 0 0:05 [ksmartass_down/]
8 0 0:00 [async/mgr]
9 0 50:24 [suspend]
10 0 0:00 [sync_supers]
11 0 0:01 [bdi-default]
12 0 0:01 [kblockd/0]
13 0 0:02 [kmmcd]
14 0 0:00 [bluetooth]
15 0 0:01 [smd_tty]
16 0 0:00 [qmi]
17 0 0:00 [rpcrouter]
18 0 0:00 [krpcserversd]
19 0 0:00 [microp_work_q]
20 0 0:00 [detection/0]
21 0 0:00 [button/0]
22 0 0:00 [detect/0]
23 0 0:00 [button/0]
24 0 0:06 [kswapd0]
25 0 0:00 [aio/0]
26 0 0:00 [kslowd000]
27 0 0:00 [kslowd001]
28 0 0:00 [crypto/0]
41 0 0:59 [panel_on/0]
42 0 0:00 [msm_serial_hs]
43 0 0:00 [mtdblockd]
50 0 0:00 [msm_hsusb]
51 0 0:00 [usb_mass_storag]
52 0 0:00 [gs_tty]
53 0 4:37 [synaptics_wq]
54 0 0:00 [proximity_wq]
55 0 0:01 [ls_wq/0]
56 0 0:03 [curcial_wq]
57 0 0:00 [w1_bus_master1]
58 0 0:00 [kstriped]
59 0 0:00 [kondemand/0]
60 0 0:00 [kconservative/0]
61 0 0:00 [kinteractive_up]
62 0 0:00 [knteractive_dow]
63 0 0:00 [binder]
64 0 0:00 [krfcommd]
65 0 3:33 [ds2784-battery.]
66 0 2:59 [mmcqd]
85 0 0:00 [kjournald]
129 1000 0:04 /system/bin/servicemanager
130 0 0:04 /system/bin/vold
131 0 0:04 /system/bin/netd
133 1001 0:33 /system/bin/rild
136 1002 0:01 /system/bin/dbus-daemon --syst
137 0 0:01 /system/bin/installd
138 1017 0:01 /system/bin/keystore /data/mis
139 0 0:01 /system/bin/ipd
140 1008 3:40 /system/bin/akmd
391 0 0:06 [loop0]
393 0 0:00 [kdmflush]
407 0 0:00 [kcryptd_io]
408 0 0:47 [kcryptd]
891 0 0:00 [loop1]
892 0 0:00 [kdmflush]
893 0 0:00 [kcryptd_io]
894 0 0:03 [kcryptd]
897 0 0:00 [loop2]
898 0 0:00 [kdmflush]
899 0 0:00 [kcryptd_io]
900 0 0:00 [kcryptd]
901 0 0:00 [loop3]
902 0 0:00 [kdmflush]
903 0 0:00 [kcryptd_io]
904 0 0:00 [kcryptd]
905 0 0:00 [loop4]
906 0 0:00 [kdmflush]
907 0 0:00 [kcryptd_io]
908 0 0:06 [kcryptd]
923 0 0:04 [loop6]
924 0 0:00 [kdmflush]
925 0 0:00 [kcryptd_io]
926 0 0:31 [kcryptd]
4864 0 0:00 [loop5]
4865 0 0:00 [kdmflush]
4866 0 0:00 [kcryptd_io]
4867 0 0:03 [kcryptd]
5370 0 0:00 /system/bin/debuggerd
10069 10007 0:00 com.android.browser
10074 10007 0:00 com.android.browser
11135 10014 0:36 com.htc.android.htcime
11142 10024 0:26 com.google.process.gapps
11489 10049 0:00 com.android.mms
12799 10005 0:06 com.android.htccontacts
15240 9999 0:31 com.htc.launcher
15403 10105 1:21 com.zomut.watchdoglite
15759 10010 0:07 com.htc.bgp
15988 10010 0:11 com.htc.bg
16748 10121 0:00 com.handyapps.easymoney
16769 0 0:00 [flush-179:0]
16906 10040 0:00 com.esmertec.android.jbed
16932 0 0:00 [iscan_sysioc]
16933 0 0:00 [dhcp_sysioc]
16934 0 0:00 [dhd_watchdog]
16935 0 0:00 [dhd_dpc]
16936 0 0:00 [dhd_sysioc]
16937 1007 0:00 /system/bin/logwrapper /system
16939 1010 0:00 /system/bin/wpa_supplicant -Dw
16955 1014 0:00 /system/bin/dhcpcd -ABKL eth0
17048 10088 0:00 org.peterbaldwin.client.androi
17079 10123 0:02 com.google.code.appsorganizer
17090 10067 0:02 com.android.vending
17110 10121 0:00 com.handyapps.easymoney:remote
17119 10096 0:08 com.thedeck.android.app
17136 0 0:00 [flush-31:0]
17147 10076 0:01 com.google.android.googlequick
17175 10039 0:00 com.htc.WeatherWallpaper
17198 10093 0:00 jackpal.androidterm
17205 10093 0:00 /system/bin/sh -
17210 10131 0:02 com.estrongs.android.taskmanag
17228 10093 0:00 /system/bin/sh -
17231 10093 0:00 ps
22931 1013 2:49 /system/bin/mediaserver
22932 0 0:16 zygote /bin/app_process -Xzygo
22937 1000 80:34 system_server
23034 1001 5:06 com.android.phone
23043 10085 0:25 sg.ruqqq.quickdesk
24864 10005 3:22 android.process.acore
27354 10007 0:00 com.android.browser
$
Hi Vukis!
Seems that we are the only ones having this problem, maybe because others are flashing/restarting there Desire daily so they don't have/get it.
Try:
Code:
su
kill -9 10069
kill -9 10074
...
It's an aggresive killing, but the only way I know to get rid of these "zombies".
Regards,
Floyd

[Q] Starts to lag, system_server near 100%

It seems like once a day, my phone will become super sluggish, to the point of no longer being usable. A simple reboot will clear up the problem, but there seems to be a larger issue as this is happening every day.
ROM - Myn's Warm 2.2 RL2
Kernel - Ziggy's 10/26
Code:
# top -m 5 -n 1
User 92%, System 7%, IOW 0%, IRQ 0%
User 278 + Nice 0 + Sys 23 + Idle 0 + IOW 0 + IRQ 0 + SIRQ 0 = 301
PID CPU% S #THR VSS RSS PCY UID Name
106 98% S 67 303536K 50328K fg system system_server
76 2% S 3 2764K 304K fg compass /system/bin/akmd
21278 1% R 1 940K 416K fg root top
5 0% S 1 0K 0K fg root events/0
21238 0% S 10 165336K 20484K fg app_124 jackpal.androidterm
Is this just an issue of needing to find a new kernel or rom? I am just not sure where to start looking for the culprit.
Thanks
I was having that issue as well and even sluggishness as well when touching the screen. I ended up reading about other people having that issue on his thread with his rom so check there. Might have to do alot of reading though. But I ended up leaving and going back to Baked Snack 1.9
Globetrahter said:
I was having that issue as well and even sluggishness as well when touching the screen. I ended up reading about other people having that issue on his thread with his rom so check there. Might have to do alot of reading though. But I ended up leaving and going back to Baked Snack 1.9
Click to expand...
Click to collapse
Yeah, I tried to read through the thread, but it turned in to a clusterF pretty quickly, just like every other rom thread.
This issue only started on Thursday, the 28th, so like I said I wasn't sure how to figure out where the real problem was. Guess I'll grab some beer and start reading through Myn's thread again.
If anyone has an idea of how to track down the culprit, please let me know.

Freezes and SYSCTL config

Hi,
My "defy" always had freezing and lag problems when I try to run heavy applications, such as 3D games, or Gmaps, etc.. in every ROM I've tried (CM7, MIUI, stock froyo, stock gb, etc.)
I read that a solution could be setting the minimum values of memory with an application called SYSCTL CONFIG (it's in the Market)
Anyone also has this problem? What values ​​do you use? Increasing this value, can cause problems?
Code:
Mine are:
Min Free Kbytes: 8192
Dirty Ratio: 95
Dirty Background Ratio: 60
Pressure VFS Cache: 20
PD: This is the post I found: http://forum.xda-developers.com/archive/index.php/t-1047153.html
Same here ... : )
I had to use Sysctl config to set the min free Kbytes to 8192.
But all remaining parameters are left in default values.
Dirty Ratio = 20
Dirty Backgr. = 5
VFS Cache Pressure = 100

[ROM][28 August] Virtuous Infinity 1.35.0 Is Out! [FULL Sense 4+Working Camera!]

Note: I am not a developer. I am merely informing the community about this rom. I take no credit for this rom. All credits for this rom go to the Virtuous Team for such an amazing rom I will post updates as the rom gets updated
Click to expand...
Click to collapse
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Virtuous Infinity
We are pleased to announce the first release of Virtuous Infinity.This ROM is the first ever which brings the full Sense 4 experience to your favorite WVGA device.Thanks to great effort of our M10 team (including Cypis, Diamondback and Flemmard) we finally cracked the new m10 format to bring you the lastest HTC software!It is based on the 1.11.401.110 release RUU of VilleC2. We would like to give special thanks to Football for the RUU.This build currently is a X-Series release, however, it is suitable for use as a daily driver if you can live with a few minor bugs.We hope to have the ROM feature complete as soon possible. Check bellow for a full list of what is working and what is not.
Primo is the result of a collaborative, team effort by the following developers:
Flemmard
Diamondback
rmk
chrisch
mdj
seo
eViL_Dee
cypis
cjward
tbalden
Features
Based on the VilleC2 ROM (1.11.401.110).
"Full" Sense 4 resized for WVGA resolution
Tweaks app build with latest HTC SDK 15
Fully Deodexed
Ported for almost full functionality on all of supported devices
Heavily optimized for fluid performance and usability.
Market-sourced applications (Gmail, Maps, Voice, etc) automatically installed on first boot into /data/app for easy removal.
Bloatware and unnecessary applications removed.
Working
Camera
HW Acceleration
WiFi
Bluetooth
Mobile Data, SMS, MMS & Voice Calls
GPS
Sensors
Audio
USB Storgage (No 3rd Party App Required)
FM Radio
Not Working
Rosie: Folder isn't perfectly resized in landscape
Rosie: Mail widget is force closing
Weather: Weather animation in landscape mode broken
Weather :Full screen weather animation broken
Camera: Not all effects are working
You tell us
Screenshots:
Devices Supported:
Desire Z / G2
Desire HD
Inspire 4G
My Touch 4G
Desire S
Incredible S
My Touch 4G Slide
Incredible 2
Credits and Acknowledgements
Virtuous Team - For an amazing rom
Bangincrazy – For testing on MT4G
lowveld – For pointing us in the right direction to fix WiFi
Football – For the RUU
xvicdice – For music playback fix
Download Link:Bug Tracker​
Since you made a link here I'll go ahead and attach some stuff.
Wifi, Data, Music Player working.
Camera works rather nicely in both default app and third party apps (instagram etc)
Attached are some screen shot with the default camera app, actually doing special effects smoothly in live preview.
It's a bit slow, especially if you're multitasking, but I'm impressed with how far they got with the camera.
When initially setting up, the setup stage can seem painfully slow (i.e.: on screen keyboard taking a sec or two to register a key, or the next/confirm dialog taking just as long).
Also wake by trackpad doesn't work even though the option is there.
The power menu requires a longer than normal long-press to activate (noticed this when getting the screenshots).
Also Infinity appears to install some apps to the SD Card via it's own custom folder (screen shot also attached).
by the way in terms of 'not all effects', I haven't come across a single effect on the list of effects that didn't seem to crash (maybe not rendered, but didn't die either).
I've switched back to EliteMod in the meantime (normal working hours have approached), I haven't had much time to test extensively how multitasking behaves (i.e.: Facebook, twitter, etc) or any graphical type of games etc.
The free ram at just bout any time is around 10MB, and uptime showing loads around 5.0 on average. The launcher can lag a bit on redraw even if you got the device clocked to 1400mhz (I believe it's more a ram issue than anything, so between supercharger V6 and swap, it might be bearable.)
---------- Post added at 08:07 AM ---------- Previous post was at 08:05 AM ----------
Oh also adb connectivity is somewhat glitchy. Devices never showed up during the initial boot, and had to mess with the power menu a couple of times (between charge only, HTC sync, and disk) to get it to show up and be able to do stuff with adb shell. Switching between various USB modes tends to be laggy.
Though one nice thing about the preview is that I did not receive a single force close or crash, just lags, and some functionality not occurring at all (i.e.: trackpad wake, FM radio).
Desire HD (ace), Desire Z (vision), Inspire 4G bugs
When phone goes into sleep you need to make a long press of the power button to wake it up
Mic doesn't work in some apps like Voice Search, Soundhound, ...
Camera isn't working on some phones
Camcorder only works with disabling sound in the video settings
I have a funny feeling it's going to turn into a bit of a 'can you port Sense Camera to XXX ICS Rom?', when it was the other way around.
FM Radio appears to be broken on both the included FM app, and the FM Radio Widget.
Though fine with SpiritFM Free Edition (which of course requests root permission).
Also the stock FM Radio app, seems to never turn off, it's always "Turning Off", and when the dialog does go away, it's still "On" (showing the icon in the status bar)
How's video recording, 720p?
The above mention of 10MB of free RAM is scaring me away from trying it though. Hell with CM7 as soon as it hits 70MB's, I feel like its lagging too much.
Tried some games with this, with supercharger, swap and 1.4ghz o/c:
Temple Run: Without swap it closes immediately, with swap its getting huge lags while playing, but when theres no lags its smoother then previous kernels.
Death Rally: Smooth as s..t.
Helicopter 3D: Smooth as f..k.
these games rather heavy considering their 3d natures. so its a good thing that this rom can run them smoothly.
generally speaking, if you make this your dd, it will drive you crazy time to time because the interface is slower then most of the roms out there. hope it will get better tho.
edit: with swap and supercharge i get 100-120 mb free ram ( at least it shows that way on the task manager)
boost3d23 said:
How's video recording, 720p?
The above mention of 10MB of free RAM is scaring me away from trying it though. Hell with CM7 as soon as it hits 70MB's, I feel like its lagging too much.
Click to expand...
Click to collapse
I find this pretty common of just about every ICS rom though (mostly cached it would seem). i.e.: free ram is wasted ram.
I'll try out the video soon as TiB does some app restores (I kind of doubt it's full 720, but maybe it'll surprise me).
---------- Post added at 10:15 AM ---------- Previous post was at 10:13 AM ----------
By the way home screen lag ain't so bad once you replace HTC Sense with the Apex Launcher (though I guess some people want the whole experience )
---------- Post added at 10:24 AM ---------- Previous post was at 10:15 AM ----------
720p is Selectable (though 1080p is also shown, obviously won't record at that though), however when you finish recording and had audio turned on, it's the forever-saving-video issue.
With audio off... did saving video for a while, and then force closed, and also a very funky buffer issue (like the screen split in half and scrolled up while recording.
The result from both are files with thumbnails with exclamation marks.
Now if I set the Video quality to 800x480 Wide (default), and audio off, it saves fine.
I respect your work.I'm about to try.
Can't even get it working it lag badly after the setup and hot reboot more than 6 times =\ anyway,good job to them as they get the camera working make me looking forward for updates XD
Sent from my Desire Z using xda app-developers app
Steven How said:
Can't even get it working it lag badly after the setup and hot reboot more than 6 times =\
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
Would help if your hboot/radio/etc info was in your signature
kbeezie said:
Would help if your hboot/radio/etc info was in your signature
Click to expand...
Click to collapse
Ah...I forget abt radio and all those... does it effect the performance? And I'm using a Italian dz not g2
Sent from my Desire Z using xda app-developers app
Steven How said:
Ah...I forget abt radio and all those... does it effect the performance? And I'm using a Italian dz not g2
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
As long as it's a DZ hboot it should be fine (i.e.: because the G2 hboot only has a ~400MB /system which is way too small, as this preview takes up about 96% of /system on DZ hboot).
Also depending on what rom you're coming from (i.e.: /system, etc may still be formatted as ext3 instead of ext4).
And far as radio... I don't know if this requires 26.13.04.19 or equivalent.
I guess if you can attempt a logcat output, might be helpful to someone who knows how to read those things.
kbeezie said:
As long as it's a DZ hboot it should be fine (i.e.: because the G2 hboot only has a ~400MB /system which is way too small, as this preview takes up about 96% of /system on DZ hboot).
Also depending on what rom you're coming from (i.e.: /system, etc may still be formatted as ext3 instead of ext4).
And far as radio... I don't know if this requires 26.13.04.19 or equivalent.
I guess if you can attempt a logcat output, might be helpful to someone who knows how to read those things.
Click to expand...
Click to collapse
I'm using 4ext recovery and I only left 20mb in my system space..I have restore back to ARHD 6.3.3.. until infinity become more rock stable perhaps? hope so
Sent from my Desire Z using xda app-developers app
Steven How said:
I'm using 4ext recovery and I only left 20mb in my system space..I have restore back to ARHD 6.3.3.. until infinity become more rock stable perhaps? hope so
Sent from my Desire Z using xda app-developers app
Click to expand...
Click to collapse
Hence why it NEEDs the DZ hboot
it is an alpha/preview
I enabled swap with this script http://dl.dropbox.com/u/1169731/swap_enabler.sh (ie: pop it on /data/local/tmp, chmod 775 , run it, reboot). So will see how SD-swap helps it.
I would remove some unesacary apps from the Rom to free up space
Sent from my HTC Sensation 4G using xda premium
I DO know how to enable swap lol, but it still lag badly.. after opening an app it hang there and finally reboot...lol I understand it's an alpha build so I'm not that demanding for the best performance for now
Sent from my Desire Z using xda app-developers app
evilcuber said:
I would remove some unesacary apps from the Rom to free up space
Sent from my HTC Sensation 4G using xda premium
Click to expand...
Click to collapse
Seems kind of pointless since the /system partition isn't normally going to change after installation. So removing those apps from /system doesn't really give you much benefits in 'freeing up space'. If it were on /data/app that'd be a different story, but it's pretty light in that department upon start.
Now you *could* disable some system apps (if it won't break anything) to improve some degree of performance, but then again what would be the point of testing/previewing if you didn't take it as is.
---------- Post added at 11:26 AM ---------- Previous post was at 11:15 AM ----------
So with 128MB swap on, overall it does seem smoother. However for any *new* item, there can be occasional freezes for a few seconds, in which time I'll notice the swap usage (via adb shell) will jump 20-30MB at a time, eventually once the phone has unfrozen it'll be quite smooth after that. In the last 3 freezes I've jumped from about 30MB to 60MB to 96MB.
Right now it's down to 87MB after about a minute since the last freeze (added a power widget to the desktop, taped the brightness, froze for about 15-20 seconds, changed the brightness, was smooth after that).
Also I'm not using the launcher that came with it, but rather Apex Pro and fancy widgets.
current memory usage, uptime and top:
Code:
[email protected]:/ # free
total used free shared buffers
Mem: 370420 360300 10120 0 600
-/+ buffers: 359700 10720
Swap: 131580 88232 43348
[email protected]:/ # uptime
15:25:04 up 34 min, load average: 2.69, 3.22, 3.40
Code:
Mem: 360772K used, 9648K free, 0K shrd, 1020K buff, 57144K cached
CPU0: 5.7% usr 5.7% sys 0.0% nic 88.4% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.18 2.93 3.29 2/680 8348
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
316 104 1000 S 425m117.2 0 2.3 com.android.systemui
209 104 1000 S 403m111.3 0 1.1 system_server
7173 104 10148 S 378m104.5 0 0.0 com.facebook.katana
421 104 10165 S 373m103.0 0 0.0 com.anddoes.launcher
467 104 10141 S 372m102.7 0 0.0 com.htc.idlescreen.shortcut
513 104 10018 S 351m 97.0 0 0.0 android.process.acore
3783 104 10017 S 334m 92.2 0 1.1 com.google.process.gapps
501 104 1001 S 329m 91.0 0 2.3 com.android.phone
760 104 9999 S 322m 89.0 0 0.0 com.htc.launcher
7847 104 1000 S 313m 86.4 0 0.0 com.android.settings:remote
1323 104 10018 S 310m 85.6 0 0.0 com.android.htccontacts
482 104 10163 S 310m 85.5 0 0.0 com.touchtype.swiftkey
7394 104 10106 S 309m 85.3 0 0.0 com.android.mms
7882 104 10017 S 301m 83.0 0 0.0 com.google.android.gsf.login
8235 104 10014 S 301m 83.0 0 0.0 com.htc.calendar
8192 104 10014 S 301m 83.0 0 0.0 com.htc.bg
8163 104 9996 S 300m 82.9 0 0.0 com.htc.notes
7862 104 10153 S 300m 82.8 0 0.0 com.google.android.googlequicksear
8214 104 10146 S 300m 82.7 0 0.0 com.dropbox.android
5568 104 10162 S 298m 82.3 0 0.0 com.mhuang.overclocking.ProfilesSe
kbeezie said:
Seems kind of pointless since the /system partition isn't normally going to change after installation. So removing those apps from /system doesn't really give you much benefits in 'freeing up space'. If it were on /data/app that'd be a different story, but it's pretty light in that department upon start.
Now you *could* disable some system apps (if it won't break anything) to improve some degree of performance, but then again what would be the point of testing/previewing if you didn't take it as is.
---------- Post added at 11:26 AM ---------- Previous post was at 11:15 AM ----------
So with 128MB swap on, overall it does seem smoother. However for any *new* item, there can be occasional freezes for a few seconds, in which time I'll notice the swap usage (via adb shell) will jump 20-30MB at a time, eventually once the phone has unfrozen it'll be quite smooth after that. In the last 3 freezes I've jumped from about 30MB to 60MB to 96MB.
Right now it's down to 87MB after about a minute since the last freeze (added a power widget to the desktop, taped the brightness, froze for about 15-20 seconds, changed the brightness, was smooth after that).
Also I'm not using the launcher that came with it, but rather Apex Pro and fancy widgets.
current memory usage, uptime and top:
Code:
[email protected]:/ # free
total used free shared buffers
Mem: 370420 360300 10120 0 600
-/+ buffers: 359700 10720
Swap: 131580 88232 43348
[email protected]:/ # uptime
15:25:04 up 34 min, load average: 2.69, 3.22, 3.40
Code:
Mem: 360772K used, 9648K free, 0K shrd, 1020K buff, 57144K cached
CPU0: 5.7% usr 5.7% sys 0.0% nic 88.4% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 2.18 2.93 3.29 2/680 8348
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
316 104 1000 S 425m117.2 0 2.3 com.android.systemui
209 104 1000 S 403m111.3 0 1.1 system_server
7173 104 10148 S 378m104.5 0 0.0 com.facebook.katana
421 104 10165 S 373m103.0 0 0.0 com.anddoes.launcher
467 104 10141 S 372m102.7 0 0.0 com.htc.idlescreen.shortcut
513 104 10018 S 351m 97.0 0 0.0 android.process.acore
3783 104 10017 S 334m 92.2 0 1.1 com.google.process.gapps
501 104 1001 S 329m 91.0 0 2.3 com.android.phone
760 104 9999 S 322m 89.0 0 0.0 com.htc.launcher
7847 104 1000 S 313m 86.4 0 0.0 com.android.settings:remote
1323 104 10018 S 310m 85.6 0 0.0 com.android.htccontacts
482 104 10163 S 310m 85.5 0 0.0 com.touchtype.swiftkey
7394 104 10106 S 309m 85.3 0 0.0 com.android.mms
7882 104 10017 S 301m 83.0 0 0.0 com.google.android.gsf.login
8235 104 10014 S 301m 83.0 0 0.0 com.htc.calendar
8192 104 10014 S 301m 83.0 0 0.0 com.htc.bg
8163 104 9996 S 300m 82.9 0 0.0 com.htc.notes
7862 104 10153 S 300m 82.8 0 0.0 com.google.android.googlequicksear
8214 104 10146 S 300m 82.7 0 0.0 com.dropbox.android
5568 104 10162 S 298m 82.3 0 0.0 com.mhuang.overclocking.ProfilesSe
Click to expand...
Click to collapse
This rom didn't come with virtuous oc?
Sent from my Desire Z using xda app-developers app

GPS problem, losing all satellites at once

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 ----

Categories

Resources