mastodon.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
The original server operated by the Mastodon gGmbH non-profit

Administered by:

Server stats:

366K
active users

This code tutorial tells you which lines to add to your build script to import the library, and tells you what classes to use, but does not tell you what imports to use to get the classes into scope *starts throwing things*

Update: Android Studio is now informing me it cannot find "the file".

What file?

Meh

Every day I do Android development is a bad day

What I think was happening here

- There is a tab in current Android Studio, "Build Analyzer", and they moved the full gradle logs (such as would allow you to debug an error in your build.gradle) there

- However if the failure in build.gradle occurs "too early", for example if there is a toplevel variable def which throws an exception, then Build Analyzer does not appear

- Shrug emoji the size of the moon

Looks like this is still not fixed.

A "cool" thing about building for Android is that if there is an error in your gradle script, the backtrace doesn't show where in *your gradle code* the error occurred, instead it shows where in the Java code of the gradle executable you can find the place where the error is printed out.

My hatred for Android Studio only grows every day. The only program I hate more, I think, is git, which makes today's problem, *which is about the interaction between Android Studio and git*, all the more infuriating

(Android Studio is failing because it is invoking git, which is not installed, and I cannot fix the problem because Android Studio cannot tell me why it is invoking git. Humiliatingly, I have lost an entire workday to this.)

Incidentally, re: the problem here mastodon.social/@mcc/109842751 where it appears(?) to be cutting off the stacktrace before actually telling me where in my code the error is occurring, it turns out there's a --full-stacktrace option if you use the Gradle command line. --full-stacktrace causes it to print out *slightly more* of the stacktrace, but not the full stacktrace or even enough to identify where the problem is occurring

Okay. The problem is solved. The problem is org.gradle.process.internal.ExecException is not an Exception, it is an Error, and it was escaping my try { } catch (Exception e) { }. This is a rookie mistake I should not have made, but in my defense, somehow the same basic code was throwing a different exception during `gradle sync` than it was during `gradle build` (?!), so since the try { } worked in sync I assumed the problem had to be some other git invocation somewhere else I had not yet found

Final update: The note about ExecException above is wrong. The problem was that, somehow, during some stages of build, gradle/Android Studio were executing the wrong version of the code. I thought that changing "Exception" to "Throwable" had fixed it, but in fact what fixed it was making a change (any change) to build.gradle in Android Studio. Renaming "git" to "lit" also fixes the problem, in testing. This somehow does something a gradle sync & clean build didn't.

Android Studio is TERRIFYING.

…no…no, no it's not over. It's even stranger and more unfathomable than I thought.

On the first build after checkout, clean, git clean, or any change to build.gradle, it works.

On the *second* build, it fails, with an exception that's clearly, unambiguously, inside a try-catch that should catch it. Catching "Throwable" instead of "Exception" doesn't help. This is the Terminator Exception, it can't be caught, it can't be stopped, and it only flags on every *other* build.

In the *build script*.

What an infuriating, miserable loss of a day this was.

I have a reproducible build failure that I can *only* explain if there is a bug in gradle.

Trying to make a minimal test case, I make a new Android Studio project and copy all apparently relevant bits from the gradle file. The bug doesn't reproduce in the new project.

I think I need to file a bug and move on, but I can't make a minimal test case, so they'll probably disregard my complex test case— and maybe they should! I dunno!

@mcc sleep on it. That's my answer for most of these.

mcc

@Flux I guess, but I actually don't believe it's my bug at this point.

@Flux I would also really, *really* like to not wind up expending a second day on this, especially since this was supposed to be a "break" day— I decided instead of working on my "real" project today I was gonna do some work on Tusky's video player. Which never got started because instead I've been fighting with Gradle…

@mcc my sympathies. One thing that continually annoys me about software development, still after 40 years of it, is how build systems require regular sacrifices of senior talent to keep them working.

@Flux I don't like Rust, but I kind of want to just move all my development over to Rust because it's the only thing I've found where the packaging ecosystem/build tooling actually works without problems.

@mcc that's why I mostly golang. But I haven't rusted properly yet.

@mcc @Flux I had a surprisingly positive experience with Golang's environment recently, despite expecting it to be the usual build nightmare. Humans can learn! It's amazing!