Android debugging problem

Great news. Sadly my journey to 10x has hit a snag…

I had a whole bunch of issues with different/more strict behaviour in the compiler w.r.t visiblity of classes. Mostly to do with nested classes not being explicitly public when they needed to be and a seemingly more strict behaviour w.r.t handling collisions between a nested type name and a class member with the same name:

 Foo = public class
 Public property Bar := new Foo.Bar;
 End;

 Bar nested in Foo = public class
 End;

In 9.x this was fine… the compiler seemed happy to be able to resolve the difference between a reference to instance.Bar and type.Bar. But 10.x choked. A minor refactoring to provide discriminating names so no big deal, but the actual names in question made this a bit irksome (the names for the nested class and the property refering to an instance of that nested class were both most natural in their previous, common form so the fact that compiler had become more fussy than before was annoying, but not a showstopper).

However after dealing with these issues I then ran into a Null Object Reference error from the compiler. So I reverted to 9.x to a) check that my changes were still 9.x “compatible”, just in case, and b) to make sure that the NOR problem was not endemic to the project/solution as a result of those changes.

This dealt with the NOR error (I was once again able to compile) but I have been struggling for a while with a debugging behaviour problem. In an attempt to resolve that I updated my Android SDK build/platform tools which not only has not fixed my debugging problem but also completely broke my Google Sign In implementation.

This has now become my top priority for this project so the 10.x transition has gone back on hold. :frowning:

Incidentally, the debugging problem is weird: The app builds, deploys on the device (physical, not emu) and launches but then get’s stuck. I have a splash activity which launches my main activity but the debugger freezes (not a breakpoint - there is no “continue” option) before the main activity onCreate completes. Timber logging shows that the onCreate is entered.

I hit STOP in Visual Studio and the app then conntinues normally. I.e. the application instance launched from within VS/debugger is not itself terminated by the STOP, but the debugger session is ended, with the application then continuing to run normally. There are no errors in the adb logcat output.

If I launch the app on the device normally, it goes straight through the splash, into the main activity, with no problems.

This seems something specific to my app because a hello world Android project doesn’t have any similar problem, but I’m at a loss what might cause such behaviour. Any ideas ?

Sorry about that; can we get a test case for this?

Does this one persist with 2295 or later, which has our reworked debug infrastructure?

Good Q. can you reproduce the same behavior in Water (which uses the parts of the newer debug infrastructure, even before 2295 and — more importantly — would allow us to do some better diagnosing on where the debugger gets stuck/caught on)?

Hi Marc,

I’ll try to put together a test case for the NRO error and send it thru.

2295 is a 10.x build right ? It didn’t occur to me to try an experimental 10.x given that the “Stable” 10.x wasn’t even compiling. So no, I haven’t tried with that.

Unfortunately my problems have grown and in trying to resolve the Google Sign In breakage (by ensuring all Android libs/build tools are up-to-date). My entire solution is now borked. Gradle dependencies are no longer being successfully brought in, there are references in the build output to UNC paths not being supported (didn’t used to be a problem).

Bottom line: I don’t currently have a buildable project with which to any testing.

I’m back in the all-too-familiar position of facing potentially many long evenings/weekends trying to divine what particular exotic configuration of SDK, Gradle and other bits and bobs are needed just to get a stable build environment in which to actually do the development I want to do, rather than what Google have decided they want me to do.

Grrrrrrrrrrrrrrrrrrrr.

Lesson learned: Forget trying to keep up-to-date. Once I have tools that work, stay there unless and until I absolutely have to move on!

Agree. Updating Android ecosystems is a nigthmare. Facing also some problems with gradel, signing, and go on.

Thanx!

Yes.

Well, the idea behind this is that when older builds have bugs, newer builds will sometimes have the fix, but never vise-versa. :wink:

It’s always really hard to offer any constructive help with vague information like this. What context does the UNC Paths message show in? Can I maybe see a build log? In general, not much has changed with Gradle resolving for the past few months, so I don’t think there should be any recent breakage…

Note that with any recent v10 build, you no longer need Gradle, as EBuild handles all the package resolving itself. All you need is there JDK and there Android SDK, both of which are usury fairly easy to keep up to date, and to my knowledge have not introduced any recent breakage with out tool chain. But again ‚ really hard to diagnose from value “it ain’t working” messages — if I saw concrete errors or logs, maybe i could be of more help… :frowning:

Hi Marc,

Until I’ve established that this isn’t all something to do with the state of the Android SDK I didn’t want to set you off down a rabbit hole that might prove to be a blind alley. :slight_smile:

And I have some progress: Abandoning the new CLI based SDK Manager as being about as useful as a chocolate teapot, I fired up Android Studio to see what it thought about my current SDK state. And whaddyaknow… where-as “sdkmanager.bat” was quite happy that everything was up-to-date, Android Studio immediately complained about some packages needing required updates.

It’s almost as if Google are trying to force people to use Android Studio ! :stuck_out_tongue:

So I’ve updated things appear to be on a much more stable footing once more. I now have some trouble with my solution having mysteriously lost numerous references so am working through fixing those, but the build errors I am now seeing are at least sensible ones referring to these missing references. At this stage at least.

I am doing all this with .2297 btw.

Hmmm, it just occurred to me … the missing references are the ones from my build.gradle.

When you say “no longer need Gradle”, do you actually mean that Gradle is not actually used any more at all, even if there is a build.gradle ? If so, then presumably this means that once I add explicit references to the project, going back to 9.x is made that much more problematic. :frowning:

This could take a while to fix up as I have some packages in my gradles that are not SDK references so I’m going to have to retrace my steps (almost a year ago now!) and figure out how to identify them to the new build package support.

Once I get to wanting/needing specific questions answered I’ll be sure to provide (hopefully) sufficiently detailed info. :slight_smile:

Meanwhile, an observation on the new package references approach (having already got it working for a couple of packages that are from the SDK). Unless I’m missing something, the package version being referenced isn’t immediately available/visible in the solution explorer, and that can be very useful information, especially when dealing with the minefield of what is, isn’t and should be supported in the Google SDK’s minefields.

I’ve shut my VM down now so can’t check, but is it also possible to specify which version of a package is desired when adding a reference ? When establishing these references in the first place I recall that I had to be quite specific with some of the versions I brought in, not always simply taking the latest.

I’ll check again myself of course, but it won’t be until the weekend now, so thought I’d mention it in case it was useful input in the meantime. :slight_smile:

Marc, to be clear on this, i have the same gradle headache. Must remove all gradle references to my project?

Rigth now just compiling not resolve the dependecies.

I only see valid references listed on gradle references

40

45

All my paths seems correct.

35

Best regards.

We no longer support those in ebuild, only „new style“ GradleReference rags. Fire and Water have an option to (try to) concert the old file for you (VS doesn’t yet).

Will review/reply to the rest when I’m at a proper keyboard…

Right-click the .gradle file and choose Convert.

I delete the file and all works as expected. Willl be good?

FYI: Have started a new topic for the current problem preventing me from upgrading my project to 10.x (2297) as this is not related to my original debugging issue and is more concerned with the new References approach.

1 Like

depends. the .gradle file does nothing, so whether it’s there or not should make no difference.