Dependency updates for v2024.4

[grzesiek2010]

Why is this the best possible solution? Were any other approaches considered?

As usual, I've updated the dependencies for the next release. However, this time, there are some significant changes in addition to the regular updates:

• Switched to Gradle Version Catalog: Dependency management now uses the Gradle Version Catalog, which is the default approach for managing dependencies in new projects. It offers several advantages over the previous buildSrc module, such as faster project builds when dependencies are changed and notifications about new available versions. For details, see this commit.
• Migrated to FusedLocationProviderClient: This migration was necessary to update the play-services-location library. For more information, see this commit.
• Reviewed and Fixed Some PMD Rules: Over the last few dependency updates, we had disabled some new PMD rules. After a review, I re-enabled a few of them. However, others were left disabled as they either don’t make much sense, would require extensive edits across hundreds of classes, or are faulty and don’t work as intended.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

It's often challenging to determine what should be tested when multiple dependencies are updated. However, in this case, I can highlight one area: location recording. As mentioned earlier, we switched to a new location provider, which could be a potential source of bugs. In fact, this is our second attempt at the migration, as the first one failed due to this issue: #6027. Hopefully, everything will go smoothly this time.

Do we need any specific form for testing your changes? If so, please attach one.

A form with a few geopints might be helpful for testing reading locations:
geo5.xlsx

Does this change require updates to documentation? If so, please file an issue here and include the link below.

No.

Before submitting this PR, please make sure you have:

• added or modified tests for any new or changed behavior
• run ./gradlew connectedAndroidTest (or ./gradlew testLab) and confirmed all checks still pass
• added a comment above any new strings describing it for translators
• added any new strings with date formatting to DateFormatsTest
• verified that any code or assets from external sources are properly credited in comments and/or in the about file.
• verified that any new UI elements use theme colors. UI Components Style guidelines

[seadowg]

Loving the change to version catalog! I used it recently on a different app and thought it was so much nicer, but definitely a pain to convert to. Thanks for taking the time to do that.

[seadowg]

Is there a way to declare the plugin versions here so we don't still need these declared in the root build.gradle?

[grzesiek2010]

Yes, I even attempted to do that, but since it was quite complex (requiring a lot of additional changes) and some of the functions I would need to use are still marked as unstable, I decided to hold off for now.

[seadowg]

I'm thinking it might make sense to still declare the compile/target/mid SDKs in as constants in Gradle (example below). It doesn't seem like version catalog lets us define integer values. They're also more like shared configuration than library versions.

buildscript {
    ext {
        minSdkVersion = 21
        targetSdkVersion = 34
        compileSdkVersion = 34
    }
...

[grzesiek2010]

In kotlin DSL this would be like this:

    compileSdk = rootProject.extra["compileSdkVersion"] as Int

so it would also require casting to Int. Given that I don't think this approach would be any better.

[seadowg]

Oh, wow. Kotlin makes that much worse - in Groovy it'd be rootProject.ext.minSdkVersion. Let's leave it as-is then.

[seadowg]

Did any changes get made to GoogleFusedLocationClient or its test? Because the Kotlin version happens in the same commit, the diff doesn't give me any insight into that.

[grzesiek2010]

Ah, yes, there are some changes because the old provider used different listeners, so the file structure has changed slightly. The file isn't large, so hopefully comparing it with the old one shouldn't be difficult.

[seadowg]

@getodk/testers I think it's worth testing location tracking (background, maps etc) before merging this as we've made changes to how we interact with location services.

[dbemke]

@grzesiek2010 Could you send us (in Slack) the apk with access to different maps sources?