Thanks for your interest in my problem. I read (and reread) that blog
article early on and took its recommendations to heart. The
possibility that I still have activity lifecycle bugs is of course
real, but I've scrubbed it pretty clean with the Memory Analyzer and
Allocation Tracker. One thing I o
On Jan 21, 3:17 pm, OldSkoolMark wrote:
> Yes, the OOM is related to 'external allocations'. I googled
> 'dalvikvm external allocation' and there's plenty to pore over. Is
> there an update on this issue in general?
If it's happening after orientation changes, there's a good chance
it's a memory
No effect here.
On Jan 21, 6:11 pm, Matt Kanninen wrote:
> I had a similar issue, randomly getting the external allocation too
> large for this process error.
>
> For me, it started when I added android:targetSdkVersion="4" to the
> manifest, and went away when I removed that bit.
>
> On Jan 21,
I had a similar issue, randomly getting the external allocation too
large for this process error.
For me, it started when I added android:targetSdkVersion="4" to the
manifest, and went away when I removed that bit.
On Jan 21, 3:17 pm, OldSkoolMark wrote:
> Yes, the OOM is related to 'external a
Yes, the OOM is related to 'external allocations'. I googled
'dalvikvm external allocation' and there's plenty to pore over. Is
there an update on this issue in general?
Here's the relevant logcat excerpt:
01-21 13:04:49.140: INFO/WindowManager(79): onOrientationChanged,
rotation changed to 1
01
On Jan 21, 12:58 pm, OldSkoolMark wrote:
> Is this telling me something useful? If forcing a GC with DDMS
> reclaims the memory used by now-defunct instances of my activity, I
> would have thought the VM would have garbage collected some, if not
> all of these defunct activities automatically. Do
6 matches
Mail list logo
