21

After upgrading Android Studio to version 3.3 this week, some breakpoints are not being recognized as valid, and are not stopping the thread.

Am I missing anything?

enter image description here

Rafael Nascimento
  • 715
  • 2
  • 8
  • 19
  • Have been on 3.3 for a while, no issues here. Make sure you debugger is attached to the instance and you've done a project resync/clean/rebuild. – em_ Jan 22 '19 at 15:38
  • I had to upgrade gradle as well to clear up other unrelated issues – em_ Jan 22 '19 at 15:38
  • Thanks! Everything is up to date (3.3 and gradle 4.10.1), but still facing the breakpoint issue. :/ – Rafael Nascimento Jan 22 '19 at 15:48
  • those breakpoints are in your code or some SDK code or 3rd parties libs? – pskink Jan 22 '19 at 15:50
  • In my code. One is at an "init" method of a Fragment. The other one is inside a Retrofit request callback. – Rafael Nascimento Jan 22 '19 at 15:51
  • 1
    and what about other breakpoints in the same class? tried to add in the first line of your `Activity.onCreate` where you call `super.onCreate`? is it fired? – pskink Jan 22 '19 at 15:55
  • Yes, I just added one right above the one that's not firing in my "init". It gets fired. When I hit F9, the next (original) one is ignored. This one doesn't have the checkmark when I'm running in debug mode. The above one has it. – Rafael Nascimento Jan 22 '19 at 15:58
  • 1
    hmmmm, are you sure the code goes thru those lines? tried adding `Log.d`? if so, i would simply `rm -rf build` folder and try again – pskink Jan 22 '19 at 16:00
  • Pretty sure. There's a condition on the second breakpoint. The code inside it is executed. I'll try to clean up the build folder. That's something I haven't tried yet. – Rafael Nascimento Jan 22 '19 at 16:03
  • @pskink Have found it. Not exactly what you said, but the breakpoint is not being hit. It's on a "if" statement line. Which used to work does not work anymore. It worked when I added the breakpoint inside the conditional statement. :/ Would you mind to write this answer @pskink? – Rafael Nascimento Jan 22 '19 at 16:11
  • I will add to the weirdness. I am having this behavior only with "if`" inside of lambdas/anonymous. If statement breakpoints work fine within their own classes... Ideas? – MadDim Jan 25 '19 at 01:33
  • Try to add your breakpoint inside the "if" statement. It did work for me. – Rafael Nascimento Jan 25 '19 at 13:34
  • 1
    What I noticed is that the if statements that have complicated logic in them do not work. So an "if (object.getSomething() == something)" will not work, but if you assign that to a value and then use the value in the statement it works fine... mystery deepens. – MadDim Jan 25 '19 at 15:04
  • I filled a bug report to Google. Here you can track it: https://issuetracker.google.com/issues/123651520 – Ognyan Jan 31 '19 at 08:52
  • Does this answer your question? [android debugger does not stop at breakpoints](https://stackoverflow.com/questions/5293415/android-debugger-does-not-stop-at-breakpoints) – TT-- Nov 23 '19 at 16:29

4 Answers4

7

Found the answer with the help of @pskink. "If" statements are "invalid" locales for breakpoints. See the checkmarks below:

enter image description here

Rafael Nascimento
  • 715
  • 2
  • 8
  • 19
  • 1
    What do you mean by invalid? Also I commented on the question about the behavior I am getting. – MadDim Jan 25 '19 at 01:29
  • 1
    "Invalid" means the Debugger won't reach that breakpoint. See the checkmarks on the breakpoints above during the execution. They're valid ones. – Rafael Nascimento Jan 25 '19 at 13:33
  • 4
    I see. Then again your answer does not answer why this works this way now. if's were "valid" before. Now they aren't under circumstances (my comment under the question). Why is that happening? – MadDim Jan 25 '19 at 15:07
  • 6
    I am afraid that the "answer" is somewhat helpful, but does not provide a solution. I second @MadDim, why is that happening, it was working on AS 3.2. This is total bullshit. Probably is caused by some code optimization in the new AS/compiler/JVM... – Ognyan Jan 26 '19 at 08:08
4

The issue is in the build tool chain (gradle, d8/r8). Problem is fixed in Android Studio 3.4 Beta 1 with gradle 3.4.0-beta01.

Or a workaround solution for this issue can be used by locally updating the top-level build.gradle configuration for your project:

buildscript {
    repositories {
        maven {
            url 'http://storage.googleapis.com/r8-releases/raw' // ADD THIS.
        }
    }

    dependencies {
        classpath 'com.android.tools:r8:1.3.55'  // ADD THIS. Must be before the Gradle Plugin for Android.
        classpath 'com.android.tools.build:gradle:3.3'
    } 
}

Once the next point release of Android Gradle Plugins takes place these changes can be removed.

For more information, see: https://issuetracker.google.com/issues/122450679

nhoxbypass
  • 9,695
  • 11
  • 48
  • 71
0

I got the same problem. The problem is solved by upgrading Android Studio from 3.6.2 to 4.0.0

Navjot
  • 1,202
  • 1
  • 11
  • 24
Jack Zeng
  • 1
0

it works for android 4.0.1. there is a button "attach debugger to android process" on top menu bar. click it and select the process. then the debugger will hit the break point.

Jack Zeng
  • 1