Ok, I found it -- it's my bug. Mark, you were partly right, and that helped. It was related to the configuration. Here is the guilty code, which is in onCreate():
mRes = getResources(); mConfig = mRes.getConfiguration(); mConfig.setToDefaults(); //Error here. There should not be a call to setToDefaults(). I don't remember now what I was thinking at the time, and the Android doc is very uninformative for this method. Possibly I copied an example from somewhere. Removing this line solved the problem. Funny thing is that the bad code works fine pre-2.0 releases. However, once I found it I carefully scoured the logcat on a 1.6 AVD and I did find the same warning log spit out from the system process. Of course, since nothing was broken and there was no way to relate the log to my process, I had no idea. I know now because it breaks in 2.0 by forcing a restart of the activity that resembles a config change. I don't know if the 2.0 behavior is right or wrong since the write-up for setToDefaults() says very little. fadden: I did consider filing a bug, but that seemed premature when I wasn't able to localize the problem. I didn't want to simply point to the app on Android Market. Now the point is moot. Thanks. On Oct 29, 7:04 pm, Nmix <nepean...@gmail.com> wrote: > Apart from a Log.d() that I just added to produce the logcat trace and > the super call, there was just one line of code (an 'if' with a > condition which isn't satisfied) which is pretty boring. Regardless, I > commented that out. No change in behavior. Thanks for the suggestion, > Mark, but I am beginning to think that something quite a bit more > subtle is going on. > > Now I'm getting quite worried about when 2.0 shows up in OTA updates > because it may/will break my app and I have no idea what to do. Up to > 1.6 the app is solid as a rock. > > On Oct 29, 5:30 pm, Mark Murphy <mmur...@commonsware.com> wrote: > > > Nmix wrote: > > > I did some additional testing on the 2.0 AVD, including numerous > > > project cleans, compiling with 1.5, 1.6 and 2.0, and cutting out large > > > swaths of code. The problem persists. Yet other apps I have work fine > > > on 2.0. > > > > I peppered logs in each of the major life cycle methods I implement, > > > and this is what I get: > > > 10-29 20:33:23.561: DEBUG/tag(502): onCreate > > > 10-29 20:33:24.271: DEBUG/tag(502): onResume > > > 10-29 20:33:26.101: DEBUG/tag(502): onSaveInstanceState > > > 10-29 20:33:26.214: DEBUG/tag(502): onPause > > > 10-29 20:33:26.311: DEBUG/tag(502): onCreate > > > 10-29 20:33:26.561: DEBUG/tag(502): onRestoreInstanceState > > > 10-29 20:33:26.571: DEBUG/tag(502): onResume > > > 10-29 20:33:27.081: DEBUG/tag(502): onSaveInstanceState > > > 10-29 20:33:27.130: DEBUG/tag(502): onPause > > > 10-29 20:33:27.211: DEBUG/tag(502): onCreate > > > 10-29 20:33:27.601: DEBUG/tag(502): onRestoreInstanceState > > > 10-29 20:33:27.611: DEBUG/tag(502): onResume > > > 10-29 20:33:28.162: DEBUG/tag(502): onSaveInstanceState > > > 10-29 20:33:28.201: DEBUG/tag(502): onPause > > > 10-29 20:33:28.541: DEBUG/tag(502): onCreate > > > 10-29 20:33:28.951: DEBUG/tag(502): onRestoreInstanceState > > > 10-29 20:33:28.960: DEBUG/tag(502): onResume > > > 10-29 20:33:29.631: DEBUG/FatCalc(502): onPause > > > > I finally kill it with the back key, though it sometimes takes a few > > > tries because the timing is critical. > > > > Elsewhere in the log, I found something in the logs put out by the > > > system process that from their timestamp may be correlated with the > > > uninstall/install process initiated by ADB: > > > > 10-29 20:33:14.391: WARN/ResourceType(55): Resources don't contain > > > package for resource number 0x7f060000 > > > 10-29 20:33:14.461: WARN/ResourceType(55): Resources don't contain > > > package for resource number 0x7f060001 > > > > These correspond to string resources in the app, both of which appear > > > to display normally when the app runs, in the momentary glimpses of > > > the app's UI display before it gets destroyed. > > > > This really has me puzzled. Any help appreciated. > > > Something in your onResume() would appear to be triggering behavior > > reminiscent of a screen rotation or other configuration change. > > > I'd start by commenting out everything in onResume() and seeing if the > > problem persists. > > > -- > > Mark Murphy (a Commons > > Guy)http://commonsware.com|http://twitter.com/commonsguy > > > Android 1.6 Programming Books:http://commonsware.com/books --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
