Discussion:
app causes reboot on DroidX after activity gets destroyed - anybody having similar issues?
(too old to reply)
mot12
2011-02-04 21:12:36 UTC
Permalink
Hello group,

My app seem to cause reboots on DroidX phones. No force close or
unusual behavior before the reboot is reported. Closing the last
activity seems to cause the reboot. Unfortunately, there's no log as
the log data gets cleared with the reboot. I have supplied a special
version to one DroidX user that writes all log data into a file; this
allowed me to see that the app seemingly ended correctly with the last
activity's OnDestroy being called.

Does anybody experience similar issues?

I will now give this user a stripped down version to see if the
problem still exists, then add code piece by piece until the problem
reappears or the user gets fed up, whichever comes first.

Any suggestion as to why a phone may reboot are highly welcome.

Martin
mobitobi
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Shane Isbell
2011-02-04 21:23:08 UTC
Permalink
From my experience, the DroidX doesn't call onMemory, it just starts
destroying and restarting apps when the device gets low. There is no FC when
it does this. I'd start there with checking your usage. Of course, that
shouldn't cause the entire device to reboot, but DroidX doesn't handle
resources like other devices.

Shane
Hello group,
My app seem to cause reboots on DroidX phones. No force close or
unusual behavior before the reboot is reported. Closing the last
activity seems to cause the reboot. Unfortunately, there's no log as
the log data gets cleared with the reboot. I have supplied a special
version to one DroidX user that writes all log data into a file; this
allowed me to see that the app seemingly ended correctly with the last
activity's OnDestroy being called.
Does anybody experience similar issues?
I will now give this user a stripped down version to see if the
problem still exists, then add code piece by piece until the problem
reappears or the user gets fed up, whichever comes first.
Any suggestion as to why a phone may reboot are highly welcome.
Martin
mobitobi
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-04 21:28:36 UTC
Permalink
Thanks. I don't use onMemory and the app seems to finish all the way
as onDestroy gets called. So it doesn't seem like it killed my app to
free up memory. But the issue gets always triggered when the app is
closed via the back button or if the app calls finish on itself (after
receiving the onDestroy even in that case).
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Mark Murphy
2011-02-04 21:35:57 UTC
Permalink
Anything unusual about your app? (e.g., you use the camera)
Post by mot12
Thanks. I don't use onMemory and the app seems to finish all the way
as onDestroy gets called. So it doesn't seem like it killed my app to
free up memory. But the issue gets always triggered when the app is
closed via the back button or if the app calls finish on itself (after
receiving the onDestroy even in that case).
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

Android App Developer Books: http://commonsware.com/books
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-04 21:57:27 UTC
Permalink
No camera.

List of possibly unusual things:
- disabling keyguard
- holding wakelock
- transparent background theme
- manipulation of screen brightness
- media player
- various intents sent to other apps upon closing so that apps
manipulating the lockscreen can resume their beastly work

However, the log file written by my app to a file shows that all these
activities ended. The media player stopped, the keyguard was
reenabled, the wakelock was released.

Maybe that last point about intents warrants further clarification:
Some apps manipulate the lock screen, e.g. replacing it with emergency
info or disabling the lockscreen. These apps tend to cause problems
when I disable the keyguard and the developers have acknowledged these
problems. To counter them, they introduces various open intents to
temporarily disable their apps while I disable the keyguard. When I
reenable the keyguard, I tell these apps to resume whatever they do.
As this would happen right after my app shuts down, this will be one
of my first targets for further investigation.

My app is an alarm clock, known as Gentle Alarm.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
String
2011-02-05 04:38:58 UTC
Permalink
Do the users experiencing the problem have one of those other apps installed? The ones you're sending the intent to on exit. If so, it may be that it's this app causing the problem, not you. You're just triggering it.

String
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-05 19:41:56 UTC
Permalink
Update: My fantastically helpful DroidX user reports that the stripped
down version works without a glitch. So there's hope. Unless it is
some side-effect like a memory issue, I hope to establish cause and
effect soon and will report here in case anybody else runs into
something similar.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 11:48:43 UTC
Permalink
Possibly found the culprit. In several activities, I call this:

setContentView(R.layout.main);
switch (Preferences.getPrefOrientation(this, Screen.MAIN))
{
case 0:
if
("1".equals(Settings.System.getString(getContentResolver(),
Settings.System.ACCELEROMETER_ROTATION)))

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR);
break;
case 1:

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
break;
case 2:

setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
break;

Basically this fixes the screen orientation to portrait or landscape,
or tells Android to use the rotation sensor again to determine the
screen orientation. This code works fine except on the DroidX. Even on
the DroidX fixed orientation works fine (protrait only, landscape
only) but if I set the orientation to be tied to the sensor, resuming
such an activity and then changing the sensor orientation causes the
reboot. My app works fine if I take this single line of code out.

Of course, this is completely unsatisfying. The line itself doesn't
cause an immediate blowup but it seems to be the cause for blowups
later. Maybe this is a firmware bug. Maybe it is something entirely
different and all this is just circumstantial. I don't have the
resources to spend more time on this issue now but if anybody has an
idea on how to make sense of this, I would love to learn.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Mark Murphy
2011-02-07 12:39:07 UTC
Permalink
If you can create a reproducible test case, post it on the relevant
MOTODEV forum and see what response you get.
       setContentView(R.layout.main);
           switch (Preferences.getPrefOrientation(this, Screen.MAIN))
{
                   if
("1".equals(Settings.System.getString(getContentResolver(),
Settings.System.ACCELEROMETER_ROTATION)))
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR);
                   break;
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
                   break;
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
                   break;
Basically this fixes the screen orientation to portrait or landscape,
or tells Android to use the rotation sensor again to determine the
screen orientation. This code works fine except on the DroidX. Even on
the DroidX fixed orientation works fine (protrait only, landscape
only) but if I set the orientation to be tied to the sensor, resuming
such an activity and then changing the sensor orientation causes the
reboot. My app works fine if I take this single line of code out.
Of course, this is completely unsatisfying. The line itself doesn't
cause an immediate blowup but it seems to be the cause for blowups
later. Maybe this is a firmware bug. Maybe it is something entirely
different and all this is just circumstantial. I don't have the
resources to spend more time on this issue now but if anybody has an
idea on how to make sense of this, I would love to learn.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9
Available!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Prakash Iyer
2011-02-07 14:47:40 UTC
Permalink
Wow! I don't know if the following is helpful at all. I've seen my DroidX
reboot a bunch of times and in almost all cases the offending app is
probably Google Maps. I say probably because that's the forefront app.
Usually the whole screen freezes - nothing has an impact and then I see that
red circular image!! I wonder if there is a way to pin this down for that
app as well which might then make it a bigger priority for Moto to fix??
Post by mot12
setContentView(R.layout.main);
switch (Preferences.getPrefOrientation(this, Screen.MAIN))
{
if
("1".equals(Settings.System.getString(getContentResolver(),
Settings.System.ACCELEROMETER_ROTATION)))
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_SENSOR);
break;
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
break;
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE);
break;
Basically this fixes the screen orientation to portrait or landscape,
or tells Android to use the rotation sensor again to determine the
screen orientation. This code works fine except on the DroidX. Even on
the DroidX fixed orientation works fine (protrait only, landscape
only) but if I set the orientation to be tied to the sensor, resuming
such an activity and then changing the sensor orientation causes the
reboot. My app works fine if I take this single line of code out.
Of course, this is completely unsatisfying. The line itself doesn't
cause an immediate blowup but it seems to be the cause for blowups
later. Maybe this is a firmware bug. Maybe it is something entirely
different and all this is just circumstantial. I don't have the
resources to spend more time on this issue now but if anybody has an
idea on how to make sense of this, I would love to learn.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 15:35:35 UTC
Permalink
@Mark
Thanks for the hint about the MOTODEV forum. That seems worthwhile
even though my poor test user has already downloaded and run more than
20 versions in helping me isolating offending code. I hope one
additional barebones test won't push him over the edge. Who knows when
I need him again.

@Prakash
I spent some time on the DroidX forums and at there are many posts
about random reboots even with the stock firmware. Small developers
can't continue chasing issues that may come down to faulty firmware.
My time is better spent getting ready for Android 3.0. But the Moto
guys could do the same thing I did since it is all open source (google
maps may not be open source, I forgot). But this debugging is a pain.
Take 30,000 lines of code (in my case), make an educated guess as to
which parts may be responsible, and strip them out (leaving 22,000 in
my case). Then the app worked. Then I built 5 test versions, each of
them putting an additional 2000 lines of code back in. My user
reported at which point it crashed and the I built 5 new versions
between the last non-crashing and the crashing version. However, we
were fairly lucky in that it all seemed to work. Stuff like this
rarely comes down to a null-pointer or something similar but are often
due to some side-effects that only occur in certain conditions like
low memory. So this type of debugging I just outlined is not
necessarily consistent and the results may even be misleading. We got
lucky. Of course, Moto has access to parts of the device I don't and I
am sure they can make the device log survive the reboot, something
that would have saved me a lot of time.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Prakash Iyer
2011-02-07 15:43:52 UTC
Permalink
Cool, I think what you have done is commendable already. BTW if you want to
run some tests and I can help on my DroidX, I'd be happy to.
Post by mot12
@Mark
Thanks for the hint about the MOTODEV forum. That seems worthwhile
even though my poor test user has already downloaded and run more than
20 versions in helping me isolating offending code. I hope one
additional barebones test won't push him over the edge. Who knows when
I need him again.
@Prakash
I spent some time on the DroidX forums and at there are many posts
about random reboots even with the stock firmware. Small developers
can't continue chasing issues that may come down to faulty firmware.
My time is better spent getting ready for Android 3.0. But the Moto
guys could do the same thing I did since it is all open source (google
maps may not be open source, I forgot). But this debugging is a pain.
Take 30,000 lines of code (in my case), make an educated guess as to
which parts may be responsible, and strip them out (leaving 22,000 in
my case). Then the app worked. Then I built 5 test versions, each of
them putting an additional 2000 lines of code back in. My user
reported at which point it crashed and the I built 5 new versions
between the last non-crashing and the crashing version. However, we
were fairly lucky in that it all seemed to work. Stuff like this
rarely comes down to a null-pointer or something similar but are often
due to some side-effects that only occur in certain conditions like
low memory. So this type of debugging I just outlined is not
necessarily consistent and the results may even be misleading. We got
lucky. Of course, Moto has access to parts of the device I don't and I
am sure they can make the device log survive the reboot, something
that would have saved me a lot of time.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-05 19:42:30 UTC
Permalink
No, this particular user didn't.
Post by String
Do the users experiencing the problem have one of those other apps installed? The ones you're sending the intent to on exit. If so, it may be that it's this app causing the problem, not you. You're just triggering it.
String
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-05 19:42:41 UTC
Permalink
No, this particular user didn't.
Post by String
Do the users experiencing the problem have one of those other apps installed? The ones you're sending the intent to on exit. If so, it may be that it's this app causing the problem, not you. You're just triggering it.
String
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-05 19:42:47 UTC
Permalink
No, this particular user didn't.
Post by String
Do the users experiencing the problem have one of those other apps installed? The ones you're sending the intent to on exit. If so, it may be that it's this app causing the problem, not you. You're just triggering it.
String
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Pepijn Van Eeckhoudt
2011-02-07 17:15:10 UTC
Permalink
Post by mot12
Any suggestion as to why a phone may reboot are highly welcome.
I've only been able to make phones reboot by triggering a
crash/exception in a system process. This is standard Android behavior
as far as I can tell.

This happened to me when I was implementing a SyncAdapter. I had
implemented the account part, but not yet the sync adapter. Creating an
account would cause a NPE in the sync process which instantly rebooted
the phone. This was a real PITA to debug as the phone would reset itself
before I even had a chance to capture any debug information.

Best of luck hunting down this one.

Regards,

Pepijn
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Dianne Hackborn
2011-02-07 17:57:44 UTC
Permalink
Please file bug reports for any such crashes.

Note the output of logcat is extremely useful -- in most cases, if the
system crashes, it is due to a Java crash, which will be printed to the log
prior to it rebooting. This may help you understand what is going on; it is
*extremely* helpful in a bug you file since the engineer can very likely
tell what the problem is and how to fix it from the log.

On Mon, Feb 7, 2011 at 9:15 AM, Pepijn Van Eeckhoudt <
Post by mot12
Any suggestion as to why a phone may reboot are highly welcome.
I've only been able to make phones reboot by triggering a crash/exception
in a system process. This is standard Android behavior as far as I can tell.
This happened to me when I was implementing a SyncAdapter. I had
implemented the account part, but not yet the sync adapter. Creating an
account would cause a NPE in the sync process which instantly rebooted the
phone. This was a real PITA to debug as the phone would reset itself before
I even had a chance to capture any debug information.
Best of luck hunting down this one.
Regards,
Pepijn
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 18:56:04 UTC
Permalink
Thanks Dianne,
Without logcat output, I am not sure what I could file as a bug report
without sounding like a rambling idiot. However, when I ask the user
to send me logcat output after the reboot, it always only has data
from the current session, never any data from prior the reboot event.
So Java may have left interesting notes but they get wiped out with
the boot process. Any idea how to get the log data from before the
reboot?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Dianne Hackborn
2011-02-07 19:11:09 UTC
Permalink
Oh sorry, I didn't catch that you were also getting reports from someone
else's device. In that case, it is hard. :}

Ideally the logs would be quiet enough that looking at them after the system
is done rebooting would still have the crash available from the previously
running system. In practice, they seem to be generally too noisy for that.
:/

One thing we should do is have these crashes written somewhere so we can
always give you the stack of the last system crash. I'll try to get that
into the next version of the platform.
Post by mot12
Thanks Dianne,
Without logcat output, I am not sure what I could file as a bug report
without sounding like a rambling idiot. However, when I ask the user
to send me logcat output after the reboot, it always only has data
from the current session, never any data from prior the reboot event.
So Java may have left interesting notes but they get wiped out with
the boot process. Any idea how to get the log data from before the
reboot?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 19:41:19 UTC
Permalink
I know how to catch my own uncaught exceptions and write them into a
file to survive reboot but since it is not my app crashing, I am at a
loss as to what I can do to get more logdata. I gave this user a
version that writes all log output into a file but all the output from
my app seems normal. And the system output is gone after the reboot.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Kostya Vasilyev
2011-02-07 19:47:26 UTC
Permalink
There are programs in Market for browsing logcat output.

One of them (can't remember which one) has an option to save logcat
output to a memory card file backup.

Don't know how "real time" it is, but perhaps it can help.

If not, and you wanted to spend some more time on it, you could make one
like that yourself: execute "logcat" with ProcessBuilder and sit in a
loop reading its output, writing it to a memory card file, flushing
after each write.

-- Kostya
Post by mot12
I know how to catch my own uncaught exceptions and write them into a
file to survive reboot but since it is not my app crashing, I am at a
loss as to what I can do to get more logdata. I gave this user a
version that writes all log output into a file but all the output from
my app seems normal. And the system output is gone after the reboot.
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 19:59:47 UTC
Permalink
Not to be a spoilsport but my expectation would be that whatever
causes the reboot would be the very last thing that happens on this
device before rebooting. I highly doubt that the system, in the middle
of a total meltdown, would be so considerate as to call my process
again, let alone long enough for my process to beat info out of the
logcat.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Kostya Vasilyev
2011-02-07 20:10:09 UTC
Permalink
Yes, very much true. Especially since logcat also relies on kernel
facilities.

But then, with no special facility to help, the logcat is about the only
thing available. Besides, things can go wrong a little before the reboot
occurs, and then there might be some output.

-- Kostya
Post by mot12
Not to be a spoilsport but my expectation would be that whatever
causes the reboot would be the very last thing that happens on this
device before rebooting. I highly doubt that the system, in the middle
of a total meltdown, would be so considerate as to call my process
again, let alone long enough for my process to beat info out of the
logcat.
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 20:21:41 UTC
Permalink
I just uploaded an update of my app and I will see if the 1-star
comments will subside now. If not, I will probably be desperate enough
to try anything short of a fortune teller. Or maybe I should have
someone feng-shui my app :).

I guess I would have to implement it as a separate service since the
problems occurred after my app ended and have it dump the logcat every
50ms or so. Unless that causes the DroidX to reboot...
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Dianne Hackborn
2011-02-07 20:35:22 UTC
Permalink
Could you send me an earlier version of the .apk that crashes the system? I
realized I have a Droid X I can test on.
Post by mot12
I just uploaded an update of my app and I will see if the 1-star
comments will subside now. If not, I will probably be desperate enough
to try anything short of a fortune teller. Or maybe I should have
someone feng-shui my app :).
I guess I would have to implement it as a separate service since the
problems occurred after my app ended and have it dump the logcat every
50ms or so. Unless that causes the DroidX to reboot...
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
***@android.com

Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 20:52:04 UTC
Permalink
Will do so now. Thanks.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Irene
2011-09-15 18:48:51 UTC
Permalink
Hi,

I know this is an old thread, but did you ever figure out exactly what was
causing this? I'm running into the same issue suddenly and would appreciate
any help I can get.

Thanks,
Irene
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Bhoopendra Singh
2011-09-15 18:56:33 UTC
Permalink
Post by Irene
Hi,
I know this is an old thread, but did you ever figure out exactly what was
causing this? I'm running into the same issue suddenly and would appreciate
any help I can get.
Thanks,
Irene
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
lodhi brother
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 19:54:35 UTC
Permalink
I know how to catch my own uncaught exceptions and write them into a
file to survive reboot but since it is not my app crashing, I am at a
loss as to what I can do to get more logdata. I gave this user a
version that writes all log output into a file but all the output from
my app seems normal. And the system output is gone after the reboot.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
mot12
2011-02-07 19:38:35 UTC
Permalink
Thanks Dianne,
Without logcat output, I am not sure what I could file as a bug report
without sounding like a rambling idiot. However, when I ask the user
to send me logcat output after the reboot, it always only has data
from the current session, never any data from prior the reboot event.
So Java may have left interesting notes but they get wiped out with
the boot process. Any idea how to get the log data from before the
reboot?
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Pepijn Van Eeckhoudt
2011-02-08 07:10:38 UTC
Permalink
Hi Diane,

The issue I'm talking about was already logged as issue 5009
<http://code.google.com/p/android/issues/detail?id=5009>.
Logcat does indeed show a useful stacktrace, however I had a very hard
time cross-referencing the stack trace line numbers with the actual
source code. The phone I was testing on was running an eclair build at
the time, so I checked all the eclair revisions but no matter which
revision I looked at, the numbers never seemed to match up. Is there any
way to easily determine which revision of the source code is being used
by a build on a specific device?

Pepijn
Post by Dianne Hackborn
Please file bug reports for any such crashes.
Note the output of logcat is extremely useful -- in most cases, if the
system crashes, it is due to a Java crash, which will be printed to
the log prior to it rebooting. This may help you understand what is
going on; it is *extremely* helpful in a bug you file since the
engineer can very likely tell what the problem is and how to fix it
from the log.
On Mon, Feb 7, 2011 at 9:15 AM, Pepijn Van Eeckhoudt
Any suggestion as to why a phone may reboot are highly welcome.
I've only been able to make phones reboot by triggering a
crash/exception in a system process. This is standard Android
behavior as far as I can tell.
This happened to me when I was implementing a SyncAdapter. I had
implemented the account part, but not yet the sync adapter.
Creating an account would cause a NPE in the sync process which
instantly rebooted the phone. This was a real PITA to debug as the
phone would reset itself before I even had a chance to capture any
debug information.
Best of luck hunting down this one.
Regards,
Pepijn
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
Note: please don't send private questions to me, as I don't have time
to provide private support, and so won't reply to such e-mails. All
such questions should be posted on public forums, where I and others
can see and answer them.
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-***@googlegroups.com
To unsubscribe from this group, send email to
android-developers+***@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
Loading...