> Have you used StrictMode to confirm that you are not using networking > or file I/O here? There may be file I/O under the covers in some > Android API calls you're using.
That is a good call, I will try that. I was thinking no. > Also, bear in mind that referring to classes other than the > BroadcastReceiver itself may involve file I/O. We know that > unreferenced classes are not loaded into the Dalvik VM, which is why > we can conditionally load classes based on Build.VERSION.SDK_INT. What > isn't clear to me is whether the class is already in RAM when the > process started but just wasn't hooked into Dalvik, or whether the > class is loaded off of flash at the time we refer to it. Anybody know > what the rule is here? Yes, but if this theory holds water, then the only solution is that you must always use a service, or never reference classes or APIs outside of the BroadcastReceiver (which isn't documented). A broadcast receiver would have to either access files, the network, or Android APIs; otherwise it's just a waste of CPU. > > Now, BroadcastReceivers are supposed to have 10,000 milliseconds to > > complete (10 seconds). And yet we _still_ see ANRs. So, I'm curious, > > are we supposed to start a service for EVERY broadcast received? > > Not that I'm aware of. > > Well, the process will already be set up, since your BroadcastReceiver > is running. 100ms seems plausible, though I haven't run those sorts of > tests yet either. > I think we're coming to the conclusion that there is nothing that should be done about the occasional random ANR in a broadcast receiver that takes at most 100 ms and has 10,000 ms to complete. It's randomness. I suspect that the Android platform is simply architected in a way to where it is expected that .1% of users monthly to experience ANRs without the application doing anything wrong. I suppose that's what you get when you have an OS using garbage collection.* Unfortunately, I think it casts a bad light on Android phones. This means that regular Android phones running properly written apps will still get ANRs. :( -Matt * Remember how the old Java sources always used to have the odd warning: "not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility." -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
