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 hap
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 wa
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 doe
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 m
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
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
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 bef
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 p
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, jason_ga
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 try/cat
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 no
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
> 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 Fri
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
13 matches
Mail list logo