1

I’m confused by the Debugger. It seems to pause the app and show the Debug window for some breakpoints and not for other breakpoints. It still ticks the breakpoints, though it doesn’t pause the app. And when I open the Debug window I see no frame so I couldn’t look at variables. I’ve looked at many documents and they haven’t cleared my problem. So what I’d like to know are:

  • how frame and thread are related
  • does breakpoint work differently in different place or different class in the app?
reducing activity
  • 1,985
  • 2
  • 36
  • 64
user67265
  • 249
  • 1
  • 2
  • 4
  • 1
    There are lots of reasons that debugger stop working, can you please provide an example with a piece of code and any log related to it? – Keivan Esbati Apr 30 '18 at 04:58
  • @KeivanEsbati The debugger doesn’t stop working. It’s just like what I wrote above. I think I haven’t comprehend the way the debugger works. And maybe I would after knowing the two points above. – user67265 Apr 30 '18 at 07:34
  • Have you study the https://developer.android.com/studio/debug/? It's pretty comprehensive guide to debugging android application. – Keivan Esbati Apr 30 '18 at 07:53
  • @KeivanEsbati As comprehensive as it may be, the guide doesn’t tell the relation between frame and thread, nor the different icons of breakpoints and their allowed places. – user67265 Apr 30 '18 at 08:08
  • I added extra explanation, hope it helps. – Keivan Esbati Apr 30 '18 at 08:37

1 Answers1

1

As it seems the Guide provided by Google doesn't answer your question, I will add an extra explanation, hope it helps:

1- The Frame is directly related to application process which can be consisted of multiple thread used by application, means that as long as application process is up and running the frame is available too.

However this doesn't mean that you can watch variables whenever you want, the Variables window frame become available once the debugger hits a breakpoint.

2- Yes, for the debugger to hit a breakpoint few criteria should be met. It's a long list but here is the more important ones:

  1. App must be debuggable in the first place, if the app is defined as not debuggable (like release builds) then the debugger won't work.
  2. The code must be readable hence executable to debugger, that means codes that are obfuscated or tampered with won't cause the debugger to stop at breakpoints..
  3. Code must be executable, that means codes that aren't executable like variable declaration or codes that are unreachable won't cause debugger to stop.

P.S: Of course these are only few major causes and there are lots of others like instant run that can make a piece of code undebuggable.

Keivan Esbati
  • 3,376
  • 1
  • 22
  • 36
  • 4. You must have the source code of the installed app; i.e. after editing but before starting to debug be sure to do a build + install! – JimmyB Apr 30 '18 at 13:09
  • Now I see threads in the Frames pane. But what about the Threads pane? And you seem to misunderstand that variable declaration won’t cause the debugger to stop. I put a field breakpoint to a variable, and it hit. The confusion is when or where it works. – user67265 Apr 30 '18 at 21:10
  • @JimmyB I think that 2nd one covers that, but that is a great example about what you can debugs and what you can't – Keivan Esbati May 01 '18 at 04:44
  • @user67265 If you mean what frame panel does, it is connected to the application process showing task log. The thread panel is like frame one but showing events per specific thread. Also variables can hit breakpoint but it must be definition or assignment, the declaration itself won't trigger it. – Keivan Esbati May 01 '18 at 04:51