48

After upgrading Samsung Galaxy S5 SM-G900F to Lollipop (Android 5.0) I noticed strange behavior:

not all breakpoints are being caught within Android Studio.

Here is environment description and my observations

  • Windows 8.1 x64
  • Android Studio 1.0.2 with SDK Tools 24.0.2
  • Sun jdk1.7.0_55
  • under SDK emulator all breakpoints are caught
  • under Genymotion all breakpoints are caught
  • under Galaxy S3 with 4.4.4 all breakpoints are caught
  • under Galaxy S5 SM-G900F with 5.0 not all exceptions are caught

I tried rebooting phone, rebooting dev machine, turning on/off debugging in dev options, using USB drivers from Samsung and Google, invalidating cache in Android Studio, doing full clear and rebuild and so on.

Breakpoints that work have ticks inside red icons. I don't know the rule, which classes do have working breakpoints and which don't.

The same thing happens with this device on three different devboxes.

screenshots from Android Studio

Help!

Hossein Narimani Rad
  • 31,361
  • 18
  • 86
  • 116
tomash
  • 12,742
  • 15
  • 64
  • 81
  • Also factory wipe of Galaxy S5 did not help. – tomash Jan 15 '15 at 08:24
  • Ticket filled here: https://code.google.com/p/android/issues/detail?id=97748 – tomash Jan 15 '15 at 18:22
  • 2
    I can confirm this, happens for me too. – darken Jan 17 '15 at 19:14
  • Reported to Samsung: http://developer.samsung.com/forum/thread/android-studio-does-not-stop-on-some-breakpoints-when-connected-to-samsung-galaxy-s5-with-lollipop-5/202/277622?boardName=General&listLines=15&startId=zzzzz~ – tomash Jan 17 '15 at 19:42
  • 1
    As mentioned on the google bugtracker, for me this only happens for non main thread breakpoints. UI thread breakpoints do trigger as far as I've tested. – darken Jan 17 '15 at 19:44
  • Something changed with LRX21T.G900FXXU1B0A3 update my phone installed via OTA yesterday. My simple example now works but it may be a side effect of some other changes. More complex project still has issues. Main activity breakpoints worked properly, one Fragment had issues (only breakpoints added after debug session started were working), other Fragment visible on screen still didn't stop at breakpoints at all. Also no breakpoint from dependent project was working. I even got a situation, where caught breakpoint had stacktrace with frames from files where other breakpoint did not work. – tomash Feb 03 '15 at 12:54
  • Yep, also happened to me. Some classes had valid breakpoints, some others just didn't stop. Had to go back to other older phone to be able to debug. – evaristokbza Feb 12 '15 at 12:34
  • Happens on Eclipse too. http://stackoverflow.com/questions/28832996/some-breakpoints-not-hit-eclipse-adt – tmanthey Mar 04 '15 at 08:17
  • configuration in your gradle debug library module: minifyEnabled false debuggable true – Make it Simple Mar 04 '15 at 12:35
  • @MakeitSimple unfortunately, flag "debuggable true" doesn't make any difference - in my sample project still only random subset of classes have working breakpoints – tomash Mar 04 '15 at 15:56
  • A have the same issue with Samsung Galaxy S III Neo and also Galaxy S5. – JerabekJakub Mar 17 '15 at 12:12

2 Answers2

7

Last update of Samsung S5 this week solves the problem with Eclipse IDE. Android French version G900FXXU1BOC7

Pierre Jean
  • 366
  • 2
  • 9
  • I didn't accept this answer yet, as unbranded XEO region still has access only to G900FXXU1OA3 firmware (as reported by Kies) – tomash May 05 '15 at 11:45
  • Thanks for this. Was having same issue in Android Studio. Nuts! Updated to G900FXXU1BOD3 – the_new_mr May 13 '15 at 11:17
  • Aaaaaand finally XEO (Poland) received firmware update with working debugger. Took a little over 5 months... – tomash Jun 25 '15 at 11:01
1

I found this out: Breakpoints don't work on allocations in some versions of Android. An allocation (second image) isn't executable code but the Fabric init code is, so it can break at that point. It seems to be a sort of check if the code is executable or not.

matthijs2704
  • 110
  • 1
  • 13
  • 1
    Unfortunately, this is not this issue. In my sample problematic project (available at https://code.google.com/p/android/issues/detail?id=97748) there are whole classes where breakpoints don't work at all, no matter if it is an allocation, assignment, method call or returning value. – tomash Mar 16 '15 at 09:05
  • Hmm thats really weird – matthijs2704 Mar 16 '15 at 18:15