[Droid Eris General] bftb0:
Probably a good idea, as the dalvik-cache dex files are what are being used by the apps for framework class code after Android has its legs underneath itself. I go so far as to wipe the entire dalvik-cache before the first reboot. (Android also compiles the framework .jar files into the dalvik-cache).

I suppose that Android is diligent about checking all .jar and .apk file sigs during booting as a security/consistency precaution - but I've never verified whether or not it actually catches this stuff and rebuilds the corresponding dalvik-cache entries. Stretching my limits of knowledge, I suppose it is possible that changing a framework file should cause a cascade of dalvik-cache rebuilds (because the dalvik-cache entries for the apps need to reference/call the framework classes.) Again, though: I haven't checked to see if this happens, so I just delete all the dalvik-cache entries as an abundance of caution. (Note: I do this manually using an adb shell with the recovery running, as I use xtr's CM cache2cache. I'm not sure that the "wipe dalvik-cache" menu item in Amon_RA does the correct thing in this case... but I'm positive that it gets done when I do it manually.)

On other matters, I should point out that the title of this thread is "Navigation on GSB". No offense is intended to klobkelosh, as he/she is clearly putting a lot of effort in to this - for folks who are willing to leave GSB for a different ROM, the information klobkelosh provide is no doubt useful as a alternative. (And, given the small number of testers active in the forum, I'm glad he/she is putting in the testing effort - it is very time consuming).

On even other matters - yesterday I (full-wipe) installed GSB v3.7 (non-Odexed) using very old Gingerbread gapps (20110120), and an old Maps (v 5127, or "5.1.0"). I got the same system_server segfault (SIGSEGV) after about 1 hour of "on top of the desk navigation". I call shenanigans - Maps may be causing the problem, but the root cause of the trouble is not Maps.

I'm absolutely convinced that there is something wrong *someplace* in GSB 3.5 - 3.7, but it is quite mysterious what the locus of the problem is. Simply put, the "system_server" application (started from com.android.internal.os.ZygoteInit) should never, never segfault - no matter what Maps does. And as far as the deadlock condition that occurs when you just get a Nav ANR - I'm clueless there. If I had to wager a guess, it would be something revolving around a graphics issue - the main thread in .driveabout seems to hang up waiting for something in opengl:

Cmd line: com.google.android.apps.maps:driveabout

DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 WAIT
| group="main" sCount=1 dsCount=0 obj=0x400221a8 self=0xce40
| sysTid=602 nice=10 sched=0/0 cgrp=[no-cpu-subsys] handle=-1345006528
| schedstat=( 116467224012 309347473275 69103 )
at java.lang.Object.wait(Native Method)
- waiting on <0x406cfdf8> (a android.opengl.GLSurfaceView$GLThreadManager)
at java.lang.Object.wait(Object.java:358)
at android.opengl.GLSurfaceView$GLThread.surfaceDestroyed(GLSurfaceView.java:1446)
at android.opengl.GLSurfaceView.surfaceDestroyed(GLSurfaceView.java:483)
at android.view.SurfaceView.reportSurfaceDestroyed(SurfaceView.java:587)
at android.view.SurfaceView.updateWindow(SurfaceView.java:481)
at android.view.SurfaceView.setVisibility(SurfaceView.java:221)
at com.google.android.maps.driveabout.app.bw.onAnimationEnd((null):-1)
...

I've sort of punted on this - last night I (full-wipe) installed GSB v3.3 and gapps-gb-20110613-signed.zip, and updated to the the most recent Maps (v5.7.0). I started my usual "desktop navigation testing" three hours ago, and no ANRs or soft-restarts. If things continue OK, I'm just going to revert to GSB v3.3 as a daily driver.

Yeah, GSB v3.3 has the annoying downloader bug; but at least Maps (the latest version) seems to work OK (so far). At this time, I'd rather have an annoying download problem than a Maps app that makes the phone explode.

bftb0