[tool] Add initial non-plugin package support for Kotlin Gradle

[stuartmorgan-g]

This adds support for non-plugin Gradle validation of packages that use Kotlin Gradle files rather than Groovy gradle files. More work will need to be done to be able to validate plugins that use Kotlin Gradle files, but this is enough for just Android apps.

As a test case for this new validation, this also migrates the animations example app to Kotlin Gradle. Rather than doing a manual migration, this was done by:

• Deleting the entire example android/ directory
• Recreating it on stable
• Restoring android/.pluginToolsConfig.yaml (without changes)
• Adding a Kotlin version of the Artifact Hub configuration
• Removing the TODO comments that are part of the template Gradle files

Part of flutter/flutter#176065

Pre-Review Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter.
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I followed the version and CHANGELOG instructions, using semantic versioning and the repository CHANGELOG style, or I have commented below to indicate which documented exception this PR falls under¹.
• I updated/added any relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or I have commented below to indicate which test exemption this PR falls under¹.
• All existing and new tests are passing.

Footnotes

1. Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩²

[stuartmorgan-g]

version/chaneglog override: modernizing the example build files is not relevant to clients.

[stuartmorgan-g]

Assuming this looks good, I can do a follow-up PR to repeat this for all the other non-plugin examples (which are presumably all simple), and then we can tackle plugins one at a time (updating the tooling further when we do the first one).

[gemini-code-assist]

Code Review

This pull request introduces initial support for validating non-plugin packages that use Kotlin Gradle files (.gradle.kts) in the gradle-check tool. This is achieved by updating the tool to recognize .kts files and apply specific validation logic for the Kotlin DSL. As a test case, the animations example's Android project is migrated from Groovy to Kotlin Gradle files. The changes include updating build logic, namespaces, and dependencies to conform to Kotlin DSL syntax and modern Gradle practices. The validation tool's tests are also expanded to cover these new Kotlin-based scenarios.

[gemini-code-assist]

To reduce code duplication, the logic for finding a .gradle or .gradle.kts file could be extracted into a shared helper function.

  // Returns a Gradle file in the given directory, preferring .kts if it exists.
  File _getGradleFile(Directory dir, String baseName) {
    final File ktsFile = dir.childFile('$baseName.kts');
    if (ktsFile.existsSync()) {
      return ktsFile;
    }
    return dir.childFile(baseName);
  }

  // Returns the gradle file in the given directory.
  File _getBuildGradleFile(Directory dir) => _getGradleFile(dir, 'build.gradle');

  // Returns the settings gradle file in the given directory.
  File _getSettingsGradleFile(Directory dir) =>
      _getGradleFile(dir, 'settings.gradle');

[stuartmorgan-g]

🤷🏻

I didn't worry much about optimal structure in any of these changes since once we convert everything over we'll rip out all the non-Kotlin paths.

[stuartmorgan-g]

This conversion from Groovy was done by Gemini. It recommended the get-and-null-check pattern rather than a direct conversion of the check-for-key-then-read Groovy code, because this is null safe rather than requiring a force unwrap. That seemed entirely reasonable to me.

The uri part I trusted it on 🤷🏻

[stuartmorgan-g]

I didn't see any reason not to just adopt the current template defaults here.