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

4am ❧

@mcc "ExecException is not an Exception" makes me long for the simplicity of assembly language.