Maps don't (didn't -- this is 4.0.2) need any panning to cause a reboot:
http://www.youtube.com/watch?v=mC4EegjeWZA
-- K
2012/12/29 lbendlin l...@bendlin.us
I can second the map panning effect. That seems to be able to lock up some
older devices (with less RAM, or poorly managed RAM?)
Well, lo and behold, I have a Galaxy Nexus right next to me that is
completely frozen this very minute.
I thought reproducing a hard freeze on a device available to me would be a
huge breakthrough. But no, nothing. The debugger detached without telling
me anything. The logcat gives out with
Hi,
I have 2 suggestions :)
First, I would review my code and make sure I've implemented
try/catch/finally. You get inconsistent results if your application is not
handling exceptions :) E.G. an attempt to use a value. Explicitly validate
the value is not null. Place the block within a
I'm unclear: why is writing your own event logger supposed to help here?
Unfortunately I'm afraid whenever this kind of thing happens it's
because you pushed some device or rom specific buttons (in the
metaphorical sense), making it hard to diagnose.
Kris
On Mon, Jan 7, 2013 at 4:14 PM,
Hi,
No problem :)
1) Collection of an event log. I'm quoting the original post:
I have very little to go on in these reports. After a full reboot, there
is little chance the logcat still has useful information. Since 4.1, we
can't use any external programs to collect the log. I aim for
True, I usually use a utility logging class that is a drop in
replacement for android's `Log`. You can get proguard to compile
these away appropriately easily (for empty methods used in a
production build), and in this case I can simply dump the log to an SD
card type location. I've done this
Not every system-level issue can be caught with app-side logging.
Consider this one as an example:
http://code.google.com/p/android/issues/detail?id=42107
This one is not a freeze or a device reboot, but still --
-- there is no unhandled exception in the application (which could be
trapped and
On Monday, January 7, 2013 1:52:12 PM UTC-8, jason_gates wrote:
Hi,
No problem :)
1) Collection of an event log. I'm quoting the original post:
I have very little to go on in these reports. After a full reboot, there
is little chance the logcat still has useful information. Since
On Monday, January 7, 2013 3:02:56 PM UTC-8, Kostya Vasilyev wrote:
Not every system-level issue can be caught with app-side logging.
Agreed, and I think is one that won't.
All in all, dealing with OS level bugs (and I consider every device
freeze or reboot an OS level bug, no
Hi,
Thank you for the reply.
We are taking apples and oranges. Kostya is a developer who reported an
issue to the Android development team. He gave them a detailed stack trace
and copy of his app. The exception was then analyzed by a professional
development support team. As an aside, it
On Monday, January 7, 2013 4:21:45 PM UTC-8, jason_gates wrote:
Hi,
Thank you for the reply.
We are taking apples and oranges. Kostya is a developer who reported an
issue to the Android development team. He gave them a detailed stack trace
and copy of his app. The exception was then
Of course not, but I never said this, I just said I'd used it to
offload and beat a system level bug before...
Then again, being able to do some logging can help you pinpoint where
your error occurs: if you see tons of crashes where the log just ends,
you can hone in on your error.
I had this
I can second the map panning effect. That seems to be able to lock up some
older devices (with less RAM, or poorly managed RAM?) randomly.
On Friday, December 28, 2012 7:34:05 PM UTC-5, Nathan wrote:
This is a topic that is on my mind once in a while.
What could an app do that would cause a
13 matches
Mail list logo
