I have an app that also has a NotificationListenerService. When I add breakpoints in that NotificationListenerService, it appears that the breakpoints halt the execution, but the debugger does not recognize it.
The debugger does not seem to see that the execution has paused, and does not activate the continue button nor does it show anything in the service as far as variables. Once this happens the first time, it appears that the service is stopped permanently.
A reboot seems to get things going again sometimes but only if you run the app in normal mode (not debugger mode) before you shut the device off. I tried reattaching the debugger as well, and that does not seem to work. Strangely, I did get it working once or twice. Not sure how.
Does anyone know how to attach the debugger correctly so you can debug the NotificationListenerService?
I found this potentially related question:
NotificationListenerService stopping and can't be restarted without a reboot
Why is this NotificationListenerService not working
, but neither have good answers and neither discuss using the debugger.
The NotificationListenerService runs on your main application thread. So to debug first set the debug points and then from Android studio toolbar select "Attach debugger to Android process".
Select your application main process. Now you will be able to debug your service. Hope it helps!
Cheers
Related
I am using Eclipse. I have a breakpoint on onCreate that I want to catch in debug mode when my application is restarted by android because of multitasking. I can connect the Eclipse debugger to my restarted app on the DDMS perspective, but I am never fast enough to catch the breakpoint in onCreate. How to automatically connect the Eclipse debugger when the android app is restarted on the device?
Run the app in debug mode. Right click on project there will a option Debug as below Run as.
Run the app in debug mode. But don't forget to add break point first before running app in debug mode
is restarted by android because of multitasking
Not sure what you really mean by this, but if this imprecise description refers to asynchronous operations (i.e. using AsyncTask) then you may want to add this line before your breakpoint set in code that is run on other than main task:
Debug.waitForDebugger();
Please note that to make it work you need to launch your app in debugging mode (F11)
I am investigating some issues which happen during my app's startup process, but DDMS won't start the debug mode until the process has started, is there a way I can capture the events earlier?
I know that this is a couple of years late, but for any future searches:
Putting WaitForDebugger into your code is one way.
Unlocking developer options (by tapping on the build number in system information on the android device) in Settings allows us to select an application for debugging and then opt to wait for a debugger whenever the program is launched. This allows us do the equivalent of adding and removing WaitForDebugger without modifying and reinstalling the code each time.
For Android Studio, here is what worked for me:
Add
android.os.Debug.waitForDebugger();
Where you want to start debugging.
Then add a breakpoint just after it in your code
Compile your app and pass it to your device
Restart your device
Once it's up, attach the debugger:
Start debugging
You should implement your own Application class which extends
Application and override the methods onCreate and so.. . This class will be your starting point of your app.
also set it as your application in the manifest.
Android can wait for the debugger to attach to your application before the app gets launched. This is a developer option called Wait for debugger.
Steps
Enable developer options (tap build version 7 times)
Enable USB debugging
Install your application onto your device using debug mode
In developer options: Press Select debug app and select the app
Enable Wait for debugger, as shown in screenshot:
Launch your app:
e.g. If testing app launch from terminated state from a push notification, send that push notification to the device.
e.g. If testing app launch from Google Assistant, use the Google Assistant to trigger this.
The app would not launch yet, instead a dialog would show up:
Attach the debugger, by pressing the Attach Debugger to Android Process button
My situation
For anyone interested/ for my future reference: I wanted to debug my Android application receiving a push notification message when the app was in the terminated state. It was actually a Flutter app running on Android, so this is relevant for both Android and Flutter.
I have revoked the API key revealed in this GIF.
Tip
If Wait for debugger is enabled, sometimes you need to detach or close Android Studio's debugger and re-attach it if you want to handle a subsequent application launch successfully. Otherwise, the app would never launch.
Notice, I send a push notification from a device (left device, iOS), and the push notification causes the app to launch on the (right device, Android). Then I attach the debugger, and the program pauses at the breakpoint I set inside FirebaseMessagingReceiver.
I wrote another version of these steps here.
I am testing the onsave/onrestore mthods of my android application.
To do this I phone my device and see that it kills the process and then I hang up. :)
I see that it restarts the application.
Question is: how do I cause it to restart in debug mode so I can step through the restore process?
Is there a way to tell it to automatically attach to the debugger when starting up?
Use android.os.Debug.waitForDebugger();
Basically, start via debugging. Exit out of your app. Set some break points. Enter back into your app (make sure that this line is hit, so put it in your onCreate or somewhere else) and it will re-attach to the running debugger.
I don't think there is a way to ensure the app restarts in debug mode. But if you are debugging your own app and don't mind adding debug code for testing you might want to add a Thread.sleep(5000) or something like this at an appropriate place in your startup methods. This should give you enough time to reconnect the debugger via the DDMS. Remove when you are done, of course ;)
There is a configuration option in Android settings > developer options > debugging > select app to be debugged. What it does is calling the eclipse debugger every time certain application is opened, if it's connected to the adb and the app's project is open.
Programmatically: Use waitForDebugger(). Documentation here.
Note that the method returns as soon as the debugger attaches, so it's best practice to place a breakpoint right after that call. Additionally, you can test the debugger attachment status using isDebuggerConnected().
In Eclipse: Open the DDMS perspective of eclipse, select the freshly-restarted app on your device, and then select the debug option. This will attach the debugger to the restarted instance.
On the Device: There is a configuration option under some* handsets that allows you to select an app to be debugged when USB debugging is configured. It's under the Developer Options in your device settings. This will attach the debugger automatically.
*For example, my Galaxy S4 has it, my HTC Rezound does not. I believe it might be a Jelly Bean specific option.
I've set up Eclipse (3.7.2) with the Android Development Toolkits (16.0.1), including Dalvik Debug Monitor Service (16.0.1), as directed in different more or less official tutorials.
If I write a "standard" Android application, with a launcher Activity, then I can set breakpoints in my code, run it on a Virtual Android Device, and the break points break as expected, and I can spend my whole night debugging code if I want.
The problem comes when instead of a "standard" Android application, I start playing around with an Android home screen widget, which does not have a launcher Activity. If I want to debug my code, I still can set breakpoints easily. Let's say I put a breakpoint straight in the onUpdate of my implementation of my AppWidgetProvider, and I test it by adding an instance of my widget to the AVD. The breakpoint doesn't break. I figure, this is because in the Debug Configurations, the launch action for my widget is "do nothing", as there is no Activity I can select.
Googling around, I found that when my AVD was running, I could go to the DDMS view in Eclipse, and in its Devices tab, I could select my widget process, and click on a cute green bug "debug selected process". If after that, I create an instance of my widget in the AVD, then the execution does break on my breakpoint.
But here comes my next problem: when this happens, I have about a few seconds in the debugger, before Android decides that my widget process has hung (which is true), and should be shot (which is not true)! Therefore my question is: how to prevent the system from shooting my process stopped at a breakpoint?
Note: In the log I get that sort of notification:
06-11 17:02:19.900: W/ActivityManager(59): Scheduling restart of crashed service [...]
Start a service that doesn't run on the main thread (such as IntentServcie) from your widget receiver (onUpdate()). Do all your work there.
I am quite new to Android and have a debugging issue. I know what an ANR is for, and do not see them when I run my app normally. However, when I try to debug my BoradcastReceiver, I am too slow and get the ANR message.
Is there a way to switch off ANR during debug sessions? I could use log statement to see what's happening, but this is annoying....
edit: actually, I don't want to supress the ANRs in the LogCat, I want to tell android not to throw ANRs during debugging. I mean to allow Broadcast receivers to take longer than 5 seconds to run. But I guess it will not be possible and instead I should delegate to a service, which is allowed to run longer, which I also can debug easier.
Thanks in advance!
greets
Go to Settings -> Developer options and check Show all ANRs.
This will show an App Not Responding dialog for apps running in the background. You can click the Wait button in the dialog to prevent the system from killing your process. Note that the dialog is opened automatically for apps running in the foreground. For background apps, you have to enable this option.
No. This message is handled through the Android OS, not your application, and there is no way to hide it on the Emulator. If you don't want to see it and your BroadcastReceiver receives the call correctly, just doesn't run successful code, you can use a try-catch block, and instead of your application crashing, the catch will be handled, wherein you can make a Toast message or whatever you wish.
You may find this resource useful for your problem. Key points:
Use -w to make process wait until debugger is attached. This one actually helps to stop on breakpoints on onCreate()'s. Debug flag is cleared after you attach debugger. Next time app starts in a regular way.
Use --persistent to wait for debugger every time process starts.
Use adb shell am clear-debug-app your.app.package to undo --persistent