Android Studio's debugger not stopping at breakpoints within library modules
Asked Answered
H

6

79

At the moment I'm developing an Android app that is based on third party code. I started to set breakpoints for understanding the code and soon ran into a problem. Suddenly I couldn't get Android Studio to stop at breakpoints anymore.

I tried to set the breakpoints within onCreate methods, within buttons' OnClickListeners - nothing worked. Now I found out that the only place it works is inside the app module. As the project just has one single activity class in the app module and everything else is provided within library modules in fact I can't debug at all.

I assume there's something wrong in the AndroidManifest.xml or more likely in the build.gradle file. As I just switched from Eclipse to Android Studio, all of this gradle stuff is pretty new to me.

If I hover over a library breakpoint while the app is running, it tells me that "no executable code [is] found at line ...". I assume this is the cause of my problem, but I have no idea about how to fix it.

Are there any "usual suspects" among the entries in build.gradle that could cause my problem?

I already did clean my project and invalidated the cache without success. I even tried the suggestion to add <activity> entries inside the library module for the fragments inside.

Edit: I'm using the most current version of Android Studio (version 1.1.0 from February 18) which should have the similar bug fixed that existed some time ago.

The contents of build.gradle in the app module:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 19
    buildToolsVersion project.ANDROID_BUILD_TOOLS_VERSION

    defaultConfig {
        minSdkVersion Integer.parseInt(project.MIN_SDK)
        targetSdkVersion  Integer.parseInt(project.ANDROID_BUILD_TARGET_SDK_VERSION)
    }

    signingConfigs {
        release {
            keyAlias 'xxx'
            keyPassword 'xxx'
            storeFile file('xxx')
            storePassword 'xxx'
        }
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
            signingConfig signingConfigs.release
            debuggable false
            jniDebuggable false
            zipAlignEnabled true
        }
        debug {
            minifyEnabled false
            debuggable true
        }
    }

    packagingOptions {
        exclude 'META-INF/DEPENDENCIES'
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE.txt'
    }
    productFlavors {
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile project(':firebase_plugin')
}

And the build.gradle of library module:

apply plugin: 'com.android.library'
android {

    compileSdkVersion 19
    buildToolsVersion project.ANDROID_BUILD_TOOLS_VERSION
    defaultConfig {
        minSdkVersion Integer.parseInt(project.MIN_SDK)
        targetSdkVersion Integer.parseInt(project.ANDROID_BUILD_TARGET_SDK_VERSION)
    }

    buildTypes {
        release {
            minifyEnabled true
            zipAlignEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt'
        }
        debug {
            minifyEnabled false
            debuggable true
        }
    }

    productFlavors {
    }

}

dependencies {
    // Facebook SDK
    compile project(':facebook')

    // Used for StringUtils
    compile files('libs/commons-lang3-3.3.2.jar')
    // Bug tracking
    compile files('libs/bugsense-3.6.1.jar')
    compile fileTree(include: ['*.jar'], dir: 'libs')
    //Google Play Services - For Google Maps
    compile('com.google.android.gms:play-services:5.0.89') {
        exclude group: 'com.google.android', module: 'support-v4'
    }
    // Support Library.
    compile 'com.android.support:support-v13:18.0.+'

    compile('com.android.support:appcompat-v7:19.1.0') {
        exclude group: 'com.google.android', module: 'support-v4'
    }
    // Volley - Networking library from google.
    compile('com.mcxiaoke.volley:library:1.0.0') {
        exclude group: 'com.google.android', module: 'support-v4'
    }
    // Has is own support library in it so need to exclude it so no TOP_LEVEL_EXCEPTION will occur.
    compile('de.greenrobot:greendao:1.3.0') {
        exclude group: 'com.google.android', module: 'support-v4'
    }
    // Firebase
    compile('com.firebase:firebase-simple-login:1.4.2') {
        exclude group: 'com.android.support', module: 'support-v4'
    }
    // Super Toast
    compile('com.github.johnpersano:supertoasts:1.3.4@aar') {
        exclude group: 'com.android.support', module: 'support-v4'
    }
    // Croping images
    compile('com.soundcloud.android:android-crop:0.9.10@aar') {
        exclude group: 'com.android.support', module: 'support-v4'
    }
    compile('com.github.chrisbanes.actionbarpulltorefresh:library:0.9.9') {
        exclude group: 'com.android.support', module: 'support-v4'
    }
}


    packagingOptions {
        exclude 'META-INF/DEPENDENCIES'
        exclude 'META-INF/NOTICE'
        exclude 'META-INF/LICENSE'
        exclude 'META-INF/LICENSE.txt'
        exclude 'META-INF/NOTICE.txt'
    }
    productFlavors {
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile project(':firebase_plugin')
}

enter image description here

Hail answered 3/3, 2015 at 15:59 Comment(11)
No, I am mainly using the simulator (genymotion)Hail
Ok, I was asking this because mainly in S5 with lollypop there is a bug that produces this bad behavior. Please post some of your code / gradle file so we can find out what is wrong. Also the android studio version could be usefulPaederast
I just tested on my Sony device just to be sure it's not related to the simulator. It didn't work there either. I'll update the question with the contents of the two main build.gradle files in a minute.Hail
Try to put the 'debuggable' to true. Putting it to false prevents from debugging the project in your app module. If this works for you I will post the answer for you to accept itPaederast
You mean the one in the top file, right? I changed it, but it didn't help. I didn't take this into account as it is inside the app module and inside the release configuration. So I thought it would only matter of I run (^R) instead of 'debug' (^D). But even if it would apply in debug mode, wouldn't it make the app module undebuggable instead of the library? Thank you for your help!Hail
You are partially right. Running thing in eclipse is not the same way as in AS. When you run in debug mode the only thing that is happening is that you are attaching the debugger to your device. It does not mean you are necessary running the debug build type, depends on your AS configuration. Provide a capture of the values you have in the "build variants" tab (it is in bottom left border)Paederast
I see also you have the minifyEnabled in debug library flavor. This is also a bad practice since your stacktraces in the library will be obfuscated by proguard, and if your configuration of proguard is not correct can lead in this kind of problems with the debugger.Paederast
Ah I understand, I automatically thought in "eclipse patterns". I'll update the post with a screen shot of the build variants.Hail
As you can see from the image, the AS is running the build debug for all the configurations of your library. I recommend you only the following configuration in your gradle debug library module: minifyEnabled false debuggable truePaederast
I added the options to both debug build configurations (app and sdk), sadly it didn't help. I found out something else though: I can step from my Application object into the initialization code inside the library module. I also can set breakpoints there and they are hit right away. I'm totally confused now, as this means it's not related to the module and not to the build.gradle file. It seems like I can only hit break points on an execution path reachable from Application.onCreate().Hail
@Feantury could you add the hint with minifyEnabled false to disable ProGuard as an answer so I can accept it? It is the hint that lead to the right direction and presumably would have helped if I had done everything right ;-)Hail
P
109

As stated in the comments of this issue, setting minifyEnabled false in the debug build is the best practice. By setting this variable in the app module you are disabling the entire proguard build process. It is useful when optimizing the release build, but gives some problems if you are testing and developing.

Paederast answered 4/3, 2015 at 17:27 Comment(4)
Keep in mind that breakpoints will not work for empty lines or comments.Lakin
I've lost hours on this issue. minifyEnabled worked for me if also setting useProguard false on Android Studio 3.3, but after upgrading to 3.4 R8 is enabled by default instead of proguard so it might be a problem with it. thank youMultifid
I spent too many hours trying to figure out why the debugger is not stopping!!! you saved me from wasting much more, thanks :)Piston
Thank you so much.Opened my project after 6 months and spent hours and finally found your solution.Thine
H
17

I kind of solved it, although I don't fully understand it yet. The problem was that ProGuard still was active like @Feantury suggested. I don't know why that was the case as I had specified minifyEnabled false in every build.gradle position I could imagine, but it seems it didn't have any effect.

As I had a crash just a few minutes ago, I saw lines in the stacktrace that looked like so:

java.lang.NullPointerException
        at com.example.MyClass(Unknown Source)
        ...

That made ProGuard the number one suspect for me. After some searching around, I found another SO question that deals with the Unknown Source problem. I tried the suggested solution for debugging with ProGuard enabled and voilà it worked!

Simply add the following lines to proguard-rules.txt:

-renamesourcefileattribute SourceFile    
-keepattributes SourceFile,LineNumberTable
Hail answered 4/3, 2015 at 14:53 Comment(3)
God Bless you my friend, I have spend my f... days to solve a damn problem, and at last your very nice question and answer helped me see the light on the horizon :) RegardsDrumbeat
I already had a -keepattributes value in my library proguard file which was for 'Signature', to enable breakpoints I changed this to -keepattributes SourceFile,LineNumberTable,Signature and I did not have to add the renamesourcefileattribute. What a frustrating problem!!!Schechter
Yes, add this to the library's proguard-rules.pro works (while minifyEnabled false doesn't work for me). Thanks.Solemn
D
13

in addition to olik79's answer, I would like to add that , these two lines will make your app hit to breakpoints in fragments. otherwise it may baypass fragments

-keep public class * extends android.support.v4.** {*;}
-keep public class * extends android.app.Fragment

here is my complete edit on proguard-android.txt in sdk\tools\proguard

# The support library contains references to newer platform versions.
# Don't warn about those in case this app is linking against an older
# platform version.  We know about them, and they are safe.
-dontwarn android.support.**

-keep class !android.support.v7.internal.view.menu.**,android.support.** {*;}
-ignorewarnings
-renamesourcefileattribute SourceFile
-keepattributes SourceFile,LineNumberTable

-keep public class * extends android.support.v4.** {*;}
-keep public class * extends android.app.Fragment
Drumbeat answered 29/7, 2015 at 8:34 Comment(3)
thank you so so, so, so, so, so, so, so so so so muchAbacist
You saved my life!!!!! Thank you so so so so so so so so so so much!!!!Orthogenic
such a joy to make people happy :)Drumbeat
B
2

I had a problem with trying to debug Kotlin code. The debugger wasn't stoping at any of the breakpoints. It turns out it was an issue with Instant run. I removed all the build directories from my project then I uninstalled the app after that I disabled Instant run.

To disable Instant run go to File > Settings > Build, execution, deployment > Instant run > Uncheck Enable Instant Run

Brunner answered 15/1, 2018 at 20:34 Comment(2)
I ditched Instant run a long time ago after it was starting so fast as to completely ignore my code updates! Personally, and on behalf of the OP, I'm blaming a clash of Android SDK vs Gradle.Story
Actually for me it was also skipping breakpoints of application modules, not only libraries. I had to disable it at the time. It seams they are improving it constantly. I'm using Instant run at the moment and I hardly encounter any issues.Brunner
B
1

In fact, there's a known issue in Android Studio: Gradle plugin does not propagate debug/release to dependencies. It seems to happen in A Studio 1.4 and 1.5 at least.

When an app is compiled in debug, its modules are in fact compiled in release. That's why proguard may be enabled in debug.

I recommend this answer that worked for me.

Bucella answered 22/2, 2016 at 1:40 Comment(1)
Intuitively, this sounds right, I have a hard time with an old project and new AS, or is it that my new project also suffered the same fate and made me dig out this old one? Terminal failure IMO, broken breakpoints, may as well be using VIMStory
C
0

I discovered the problem to be that Android Studio was in offline mode. When I changed from offline mode this allowed debugging to work effectively.

Connacht answered 17/9, 2019 at 12:31 Comment(1)
Offline mode: File > Settings (Ctrl-Alt-S) > Build, Execution, Deployment > Gradle Under Global gradle settings: Offline work checkbox.Undernourished

© 2022 - 2024 — McMap. All rights reserved.