This has been plaguing me for a few days now. Any time I try to use a breakpoint to debug into anything other than an activity (background service, broadcast receiver, input method) my breakpoint will be hit normally, but then about five seconds later the device will terminate the process and disconnect from the debugger. It isn't enough time to gather any meaningful information so debugging has proven extremely difficult.
Well it turns out I was finally able to figure it out after setting a bounty on this question...
For me it was because of threading, it seems threads were timing out when a breakpoint has been hit in a background thread. To solve this, I changed how the breakpoint suspends the app. Instead of just suspending the thread we're currently in I changed it to suspend all instead.
Right mouse click the break point and set it to suspend all, you can also set this as default as shown below.
I have just had the same problem
What happened for me was that I was in the middle of debugging when my phone (a ZTE blade) recieved a call. I took the call and when I came back to debugging again afterwards, I found that no matter what code I put on one particular line (probably the one where I had paused / had a break point when I recieved the call), the activity crashed (silently / without error message) when it hit that line.
After some messing around, I found if I added and removed a breakpoint on the offending line and added another in a different method later on, that the new breakpoint paused and after running the app through once, the whole thing was fine
Related
I have some code that I run during onPause of an activity. I'd also like that code to run when I press stop in Android Studio, or press play and it automatically shuts down the activity before launching the new one. Is this possible?
No. The proper debugger is transparent to the code being controlled and the fact it's being stopped. stepped, paused or resumed should be 100% unnoticed by the code being tapped. Otherwise it would simply make rather little sense for 99,9% of cases.
You may however plant some code that will i.e. ensure that debugger is connected, like methods from Debug class, which often come handy as waitForDebugger() or isDebuggerConnected(). You can then ensure this code is stripped from release build with use of ProGuard.
The more similar thing to what you're asking is to detect if the debugger is attached, but as #Marcin-Orlowski says, aside from this debugger should be transparent.
This will return if debugger is attached:
android.os.Debug.isDebuggerConnected()
For some strange reason, which I'm not entirely sure why, I'm getting not only an ANR for my application, but also of the entire systemui. It's so bad that I HAVE to reboot, and after rebooting it has to "Optimize" all of my apps like it corrupted something (anyone have an explanation as to why this happens?).
I'm assuming that parts of my code are so bad that they're causing this, but should even malicious code be able to overload the systemui? Anyway...
What I am doing is that I'm attempting to launch a service to handle screen recording. The activity (from a fragment) asks for permission (which is obtained, and I see the Screencast icon in the top right corner of the screen), then it binds a service which handles any state changes. What I mean by state changes is this...
States:
Dead - Means it needs to be initialized and prepared
Alive - Means it needs to be start and is fully initialized/prepared
Started - Means it is currently recording.
Paused - Means it will start a new video after starting again, which it will combine all temporary videos into one (haven't worked out that details yet).
Stopped - Means combine any and all files into one, then send the URI through an intent in a broadcast (haven't gotten this far yet).
It goes from Dead -> Alive -> Started <-> Paused -> Stopped -> Dead. At least that's the overall plan. I plan on having a floating button that acts as remote for controlling the service, and hence broadcasting on a receiver (local) to my fragment which is waiting for it to be finished.
Now, enough of what I intend to have, lets get into what I have right now. It's kind of a mess, I've never done this stuff before, hence why I'm asking on here. Trust me when I say that I have tried a lot of stuff, and the unfortunate bit is, the only way to test out a new solution is to reboot and wait 15 minutes while Android optimizes everything again. Now I understand it's a "Long" code-segment, but I'll say that one place it crashes is stopRecording(), at line 216.
Code here.
Let me know if I should make any changes.
Lastly: Should any of this be run on another thread? Could that be the issue? Why doesn't the app crash only instead of systemui?
I am currently compiling and executing some C++ code on a rooted Android device. I use adb (adb shell). To compile my code, I don't use the NDK, but I cross-compile with CMake
I'm using the function sleep(seconds) of unistd.h.
I've experienced some curious behaviors with that function on Android: Basically, I have a for loop in which I std::cout something and then call sleep(x).
If I call sleep(1), the behavior is the one expected: The program waits 1 second, and then executes the next instructions.
If I call sleep(2), the behavior isn't the one expected. The program gets stuck on that instruction for ever.... until I hit a key on my PC keyboard (not the device's one), and then it gets stuck on the next sleep(2)... until I hit a key, etc...
This behavior happens only when the device screen is off. As soon as I click on the power button to turn the screen on, the program resumes and has the expected behavior.
N.B: The behavior is the same with usleep(useconds)
I have tried to see where the limit is between 1 and 2 seconds:
1.5s, 1.25s, 1.125s -> always stay blocked | 1.0625s -> ~50% chance of staying blocked.
Obviously, there is something that prevents a thread to wake up if it sleeps more than 1 seconds (at least 2).
So my question would be, does anyone have any idea of why this is happening, and has a detailed explanation of the process ?
Thank you !
Android puts applications in the background when they aren't doing any user interaction - unix sleep and java timers etc. won't wake them up. You have to use an android alarm or runnable postDelayed handler.
I am working on an Android app that displays a continuous custom-rendered animation on the title screen and thus doesn't really enter the idle state when it's done loading. On most devices I've tested, everything runs fine, but Samsung's Galaxy S2 kills the app after a few seconds. I don't get a stack trace or any output of the System.out output that I put into the onPause event handler and the default uncaught exception handler, so it doesn't seem to be a normal exit or an Exception in my code.
The only output I get in LogCat is the following:
Launch timeout has expired, giving up wake lock!
Sending signal. PID: 22344 SIG: 3
handleActivityTimeout pid=[22344] cnt=10
Process ... (pid 22344) has died.
There are several related posts here on SO (1, 2, 3, 4), but they all seem to trigger the issue slightly differently (alarm, recursive loops, network requests in the UI thread, ...). The last one links to a Google Groups discussion that says that this error message can simply be ignored. An approach I'd rather not take since it causes my app to actually crash on the Galaxy S2 (and maybe others?).
Basically what I did was to write a custom View that renders the next animation-frame in its onDraw() method and then calls postInvalidate() right before returning from onDraw(). In case it matters: My first postInvalidate() call happens during onCreate(...).
The rendering is very quick and runs at 40+ frames per second on that device and well over 60 fps on more modern phones. So control goes back to the event loop very frequently and the app is also very responsive. Yet, the Galaxy seems to think that it has crashed and kills it (if that is even the reason for my app dying there). The thing is: If I am quick enough to click on a menu-item in my app to end up on a screen without an animation to break out of the "tail-recursive" postInvalidate() once, everything runs fine. Even if I then go back to the title screen for a long time where the animation runs again.
So, of course, I could probably just use postInvalidateDelayed(...) once to break out of the start-up check, but that seems like a bit of a hacky solution and I don't know if there might be any other devices out there that might consider my app dead at a later stage (not just during start-up) and kill it.
Is there something fundamentally wrong with using postInvalidate() in the way I'm doing? Is there a way to fix it? I would like to avoid having to move to a separate thread since that opens a whole other can of worms as far as passing events back and forth between the UI and that thread. I know it wouldn't be the end of the world and using a SurfaceView, it might even lead to a slight performance improvement, but it's really just not necessary from a user experience point of view (everything runs perfectly smooth), so I'd like to avoid the involved additional opportunities for issues (multi-threading is notoriously difficult to debug).
I don't get this, and it's really frustrating me.
All of my long-running operations happen in AsyncTasks. For example, the user interacts with the app somehow and an item is added to a list. This causes an AsyncTask to fire, the data to be written to an sqlite3 database, and then the list is refreshed.
I've recently bumped my Android support up from 2.3.3 to 4.0. I've created a new 4.0 emulator and, for some reason, all of my AsyncTasks seem to queue up and only fire once the user leaves the screen!
Why is this happening????
The code is pretty simple. I'm not doing anything interesting here. For example, here's an AsyncTask fire example:
Log log = data.mFoodLog;
log.setUserId(getUserId());
log.setDay(mBeginningOfToday.getTimeInMillis()/1000);
log.setStatus(DbDefinitions.STATE_POSTING);
(new SaveLogTask()).execute(new SaveObjectTaskParams(getApplicationContext(), log));
The debugger shows this code being executed. I have another breakpoint inside the doInBackground() method, but that breakpoint never gets hit until I leave the screen. I've also put Log.e messages around this code and ran it without the debugger to make sure the debugger isn't doing anything weird. doInBackground() never gets fired until I leave the Activity.
At first sight seems to be what #Cliffroot says, an async task not ending and queuing the ret of them (due to the behaviour changes in Android).
To execute them on diferent threads use: asyncTask.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
Basically the behaviour of AsyncTask has changed since version 3.0. On 2.3.3 it used to execute AsyncTasks concurrently, but now it does it sequentially.
So your problem might be that you have one AsyncTask that does not finish, and because of that fact the others don't even start (it's hard to say without seeing more of your code).