On Dec 7, 3:16 am, Bob Kerns <r...@acm.org> wrote: > Kudos to the Android team for this. My experience is that this sort of > checking avoids a lot of problems and really makes a difference in > application quality.
Indeed! We've been using it to fix hundreds of performance glitches across apps and across the system services. > I haven't tried it yet, but I do expect my code to ALMOST pass -- but > are things like preferences and database access considered disk > accesses, in this environment with flash memory instead of "disks"? Yes, the "disk" in this case means the filesystem, whatever it happens to be. (spinning, raw MTD, iNand FTL, etc..) > It would be helpful if the documentation were clear about which system > APIs with implicit file IO would be affected by the policy -- and > perhaps some tuning in this regard. Well, the docs do at least say that it's not guaranteed and that the set may change (get more or get some removed) over time. > Perhaps rather than "any file IO", give the ability to control how much, > either in data size or IO time? The thing to keep in mind for data size is that on filesystems like yaffs (used by the majority of Android devices), the data size doesn't matter... yaffs has a giant lock around the whole filesystem code, so even a tiny stat() can block for seconds if the disk is otherwise being hammered by something else (during boot, heavy sync, etc). And if you're hitting the disk at all, even if it's 8ms one time, you're still hitting the disk in that code path and I'd rather not hide the "good" 8ms cases when the exact same stack could take 30 or 100 ms later and cause a glitch. It's really quite boolean: you hit the disk in a particular stack trace (and are those potentially always gltichy there) or you don't. > > To make it even more useful, can I suggest some overrides: > > * On the device, per application, so developers and concerned users > can investigate already-installed applications. > > * In the AVDs, per AVD, so developers can choose to always test in > this mode. > > * In the launch configurations -- where perhaps the default should be > to be the strictest, complete with crash. > > * In the manifest -- where the manifest editor will help people > discover the option Yes, I'd like to make it easier to use in those ways too. I'll be ramping up its breadth and visibility in future releases. For now consider it a preview. > > And perhaps: > > * In the market, which would give you a hard time about it is your > application does not have a "safe and sane" setting in the manifest? > "Safe and sane" is currently documented to be "off", but I think would > better be some combination of detecting network, ignoring disk, and > not crashing the app. Let's see if users do it on their own, first. I'd also like to let developers easily enable silent performance collection for their users and make the performance data visible on the Market developer site, similar to the crashes and ANRs that are already there. > > I bet we'd see a lot better applications as a result. hope so! It's been working for us so far! > In the meantime, when people ask in this group about ANRs, or post > code that has relevant problems, we should direct them to turn on > StrictMode. Please do. Also, I don't read this group too often, but I'll take questions on stackoverflow.com for anything tagged "strictmode", if you use that site. But I'll also try to poll this group more often now. - Brad -- 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
