Feat/android 17

[Devasy]

• Upgrades the Android SDK version to 37 ie android 17
• Upgrades the Java version to J17
• Updates the Flutter build version to 3.44.4 from 3.41.6

Summary by CodeRabbit

• Updates
  • Updated the Android build tooling and compile/target SDK versions.
  • Raised the Java and Kotlin compilation target to Java 17.
  • Updated the Flutter SDK requirement to version 3.44.4.
  • Updated Gradle wrapper and plugin versions to newer releases.
  • Bumped several Dart/Flutter dependencies and the Android launcher icons package.
• Documentation
  • Refreshed README links and metadata to point to the new repository location.

[coderabbitai]

Walkthrough

The project updates its Flutter SDK constraint, Android build toolchain, and package dependencies. Android configuration adopts newer Gradle, Kotlin, Java, and SDK versions. Documentation and Android metadata now reference the RepForge repository.

Changes

Toolchain alignment

Layer / File(s)	Summary
Flutter and Gradle foundation workout-logger/pubspec.yaml, workout-logger/android/gradle/wrapper/gradle-wrapper.properties, workout-logger/android/settings.gradle.kts	Flutter, Gradle, Android Gradle Plugin, and Kotlin version constraints are updated.
Android build configuration workout-logger/android/gradle.properties, workout-logger/android/app/build.gradle.kts	Built-in Kotlin and the new DSL are enabled; compilation and targeting move to Android SDK 37 with Java and Kotlin JVM targets set to 17.
Flutter dependency refresh workout-logger/pubspec.yaml	intl, package_info_plus, file_picker, share_plus, and flutter_launcher_icons versions are updated.

Repository references

Layer / File(s)	Summary
Repository link updates README.md, workout-logger/fastlane/metadata/android/en-US/full_description.txt	README links, clone instructions, badges, developer profile, issue link, and Android metadata reference Devasy/RepForge.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title is concise and clearly points to the Android 17 upgrade, which is the main theme of the PR.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@workout-logger/android/app/build.gradle.kts`:
- Around line 5-22: Replace the kotlinOptions block in the android module
configuration with the Kotlin 2.x compilerOptions DSL, preserving the Java 17
JVM target. Do not re-add the org.jetbrains.kotlin.android plugin; keep the
existing built-in Kotlin setup and surrounding compileOptions unchanged.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 555cf4b0-3fea-4724-aa58-626b533089c1

📥 Commits

Reviewing files that changed from the base of the PR and between 5624818 and 5f606b2.

⛔ Files ignored due to path filters (1)

• workout-logger/pubspec.lock is excluded by !**/*.lock

📒 Files selected for processing (5)

• workout-logger/android/app/build.gradle.kts
• workout-logger/android/gradle.properties
• workout-logger/android/gradle/wrapper/gradle-wrapper.properties
• workout-logger/android/settings.gradle.kts
• workout-logger/pubspec.yaml

[Devasy]

@coderabbitai with this auto update tags do we have to remove the kotlin dep from the Buildgradle.kts or similar file ?
android.builtInKotlin
check for the other flag as well

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
fd build.gradle.kts -a
echo "---app build.gradle.kts---"
cat -n workout-logger/android/app/build.gradle.kts
echo "---settings.gradle.kts---"
cat -n workout-logger/android/settings.gradle.kts
echo "---gradle.properties---"
cat -n workout-logger/android/gradle.properties
echo "---search for kotlin references---"
rg -n "kotlin" workout-logger/android --iglob '*.kts' --iglob '*.properties'

Length of output: 7313

---

🤖 web_search executed:

Android Gradle Plugin android.builtInKotlin gradle property what does it do, does it remove need for kotlin-android plugin declaration

Length of output: 2459

---

🤖 web_search executed:

Android Gradle Plugin android.newDsl gradle property meaning AGP 8.x

Length of output: 6629

---

🤖 web_search executed:

Migrate to built-in Kotlin Android Studio - what is minimum AGP version required for android.builtInKotlin gradle property (AGP 8.x support)?

Length of output: 4403

---

🤖 web_search executed:

Does Flutter's dev.flutter.flutter-gradle-plugin automatically apply the org.jetbrains.kotlin.android plugin to app module, independent of AGP built-in Kotlin support?

Length of output: 4401

---

🤖 web_search executed:

Flutter "Built-in Kotlin migration for app developers" docs.flutter.dev - does Flutter's flutter-gradle-plugin apply kotlin-android plugin based on android.builtInKotlin property regardless of AGP version, and is AGP 9 required?

Length of output: 10136

---

@Devasy, good catch — I dug into this and here's the full picture:

Short answer: no, you don't need to remove the Kotlin plugin from settings.gradle.kts (or anything else) right now. Your current setup is actually correct for where you are in the migration.

Why:

• android.builtInKotlin and android.newDsl are AGP 9.0+ features. Android's own docs state: "You need AGP 9.0 or higher to have built-in Kotlin support."
• This PR only bumps AGP to 8.11.1 (in workout-logger/android/settings.gradle.kts), not to 9.0+.
• I checked Flutter's Gradle plugin source directly (the isBuiltInKotlinEnabled check added in [AGP 9] Support Enabling Built-in Kotlin flutter/flutter#188543). It explicitly does:

  if (agpVersion == null || agpVersion.major < 9) {
      return false
  }

  So with AGP 8.11.1, Flutter's Gradle plugin ignores android.builtInKotlin=true entirely and falls back to auto-applying the legacy kotlin-android (Kotlin Gradle Plugin) itself — exactly like before.
• That auto-apply still needs the org.jetbrains.kotlin.android plugin version to be resolvable, which is why settings.gradle.kts still declares:

  id("org.jetbrains.kotlin.android") version "2.2.20" apply false

  If you remove that declaration now, the build would break because FGP wouldn't be able to resolve/apply the Kotlin plugin version.

So, to summarize both flags:

Flag	Status on AGP 8.11.1
android.builtInKotlin=true	Inert — requires AGP 9.0+
android.newDsl=true	Inert — also requires AGP 9.0+

They were added automatically by the Flutter migrator as forward-looking placeholders, and they don't cause any harm sitting in gradle.properties at 8.11.1. The app/build.gradle.kts comment ("kotlin-android is injected automatically by Flutter's built-in Kotlin support") is slightly misleading right now — technically it's injected by FGP's legacy auto-apply behavior, not true built-in Kotlin, since that isn't active yet.

If you want built-in Kotlin to actually activate, that would require a separate, larger effort: bumping AGP to 9.0+ in settings.gradle.kts, adopting the new DSL (ApplicationExtension/LibraryExtension instead of the android {} block extension functions), and checking plugin compatibility (e.g., android.applicationVariants usage in your app/build.gradle.kts for ABI version codes is part of the legacy variant API and would need migrating too). I'd recommend treating that as a follow-up PR rather than bundling it into this SDK/JDK/Flutter bump.

Let me know if you'd like me to open a follow-up issue to track the AGP 9 / built-in Kotlin migration.

(⁠•‾⁠_⁠•⁠) — curious to see how the AGP 9 migration shakes out when you're ready for it.

---

✏️ Learnings added

Learnt from: Devasy
URL: https://github.com/Devasy/RepForge/pull/59

Timestamp: 2026-07-15T15:47:23.404Z
Learning: In Devasy/RepForge's workout-logger Flutter app (workout-logger/android), `android.builtInKotlin` and `android.newDsl` gradle.properties flags only take effect when AGP >= 9.0.0. Flutter's Gradle plugin (FlutterPluginUtils.isBuiltInKotlinEnabled) explicitly forces built-in Kotlin to false when the detected AGP major version is below 9, falling back to auto-applying the legacy `org.jetbrains.kotlin.android` plugin. The project currently pins AGP to 8.11.1 in workout-logger/android/settings.gradle.kts, so these flags (added automatically by the Flutter migrator) are currently inert placeholders, and the `org.jetbrains.kotlin.android` plugin version declaration in settings.gradle.kts must be kept until an actual AGP 9.0+ upgrade is done.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[Devasy]

@coderabbitai nice catch what would be the changes for moving to latest AGP? 9.00 or above, what changes in the gh action would come?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
fd -e yml -e yaml . .github/workflows 2>/dev/null
echo "---workflows---"
for f in $(fd -e yml -e yaml . .github/workflows 2>/dev/null); do
  echo "=== $f ==="
  cat -n "$f"
done
echo "---app build.gradle.kts full---"
cat -n workout-logger/android/app/build.gradle.kts
echo "---settings.gradle.kts---"
cat -n workout-logger/android/settings.gradle.kts

Length of output: 16350

---

🤖 web_search executed:

Android Gradle Plugin (AGP) 9.0 release status 2026, stable release, minimum JDK version required, minimum Gradle version required

Length of output: 5339

---

🤖 web_search executed:

Android Gradle Plugin 9.0 new DSL migration guide ApplicationExtension LibraryExtension breaking changes variant API

Length of output: 8400

---

@Devasy, here's the breakdown based on the official AGP 9.0.1 release notes and compatibility tables:

1. Version bumps required

File	Current	Needed for AGP 9
workout-logger/android/settings.gradle.kts	com.android.application 8.11.1	9.1.1+ (see note below, not just 9.0.1)
workout-logger/android/gradle/wrapper/gradle-wrapper.properties	Gradle 8.14.1	Gradle ≥9.1.0 (AGP 9.0's own minimum)
JDK	17	17 (already satisfied — no change needed)

Important catch: The official compileSdk/AGP compatibility table lists API level 37 as requiring minimum AGP 9.1.1, not the base 9.0.1. Since this PR already sets compileSdk = 37 / targetSdk = 37 while pinning AGP to 8.11.1, you're technically already ahead of AGP's official support window for that API level (Gradle usually just emits a suppressible warning rather than failing, but worth being aware of). So if/when you move to AGP 9, target 9.1.1+ directly rather than 9.0.1.

2. settings.gradle.kts changes

• Bump com.android.application to 9.1.1+.
• Remove the org.jetbrains.kotlin.android plugin declaration entirely — AGP 9's release notes explicitly state "The org.jetbrains.kotlin.android plugin is not compatible with the new DSL." With android.builtInKotlin=true now actually activating (AGP ≥9), Kotlin compilation is handled internally.

3. app/build.gradle.kts changes

• The android.applicationVariants.configureEach { ... } block used for your ABI-specific versionCodeOverride logic is exactly the deprecated API called out in the AGP 9 migration guide. It must be rewritten using the new androidComponents.onVariants(...) API — this is the biggest actual code change, not just a version bump.
• The kotlinOptions { jvmTarget = ... } block is part of the legacy Kotlin Gradle Plugin DSL; with built-in Kotlin, JVM target config typically moves under kotlin { compilerOptions { jvmTarget = ... } } or an equivalent built-in-Kotlin DSL surface — worth double-checking against Flutter's migration docs once you're actually on AGP 9, since the exact API may still be evolving.
• Any other legacy android {} block usage should still work for now (old classes are deprecated but present) unless you also flip android.newDsl=false as a safety valve during transition — but that would defeat the purpose of adopting android.newDsl=true.

4. Third-party plugin compatibility (the real risk)

• Flutter's flutter-gradle-plugin needs to explicitly support AGP major version 9 (recall: if (agpVersion.major < 9) return false gating built-in Kotlin). AGP 9.0 only shipped in January 2026, so Flutter's stable-channel support maturity for it is worth verifying directly against your target Flutter version (3.44.4 per this PR) before committing to the bump — I don't have high confidence this has been battle-tested yet.
• F-Droid build server compatibility for your signing-block-stripping trick (the comment in app/build.gradle.kts about signingConfig needing to stay on one line) should also be re-verified, since the new DSL/variant API could change how that block is structured internally.

5. GitHub Actions impact

Actually pretty minimal:

• .github/workflows/release.yml already sets java-version: '17' via actions/setup-java@v4 — no change needed there (17 remains AGP 9's minimum too).
• Neither workflow pins a Gradle or AGP version explicitly — both are driven by gradle-wrapper.properties / settings.gradle.kts, so the CI workflow YAML itself likely needs no changes. The version bump is fully contained to the Gradle/AGP config files.
• .github/workflows/test.yml doesn't invoke Gradle/Android build directly (only flutter analyze/flutter test), so it's unaffected either way.

Recommendation

Given the DSL/variant-API rewrite (item 3) and the Flutter-compatibility unknown (item 4), I'd still treat this as a separate, carefully-tested follow-up PR rather than bundling it here. Want me to open a tracking issue for it?

(⁠｀⁠_⁠´⁠) — this one's got some real teeth to it, happy to help scope the follow-up whenever you're ready.

---

✏️ Learnings added

Learnt from: Devasy
URL: https://github.com/Devasy/RepForge/pull/59

Timestamp: 2026-07-15T15:50:48.798Z
Learning: In Devasy/RepForge's workout-logger app (workout-logger/android/app/build.gradle.kts), the ABI-specific versionCode logic uses the legacy `android.applicationVariants.configureEach { ... }` API (casting output to `ApkVariantOutputImpl`) to set `versionCodeOverride` per ABI. This API is deprecated under AGP 9.0's new DSL/variant API model and must be migrated to the `androidComponents.onVariants(...)` API before upgrading AGP to 9.0+. Additionally, the official Android compileSdk/AGP compatibility table lists API level 37 as requiring minimum AGP 9.1.1 (not just 9.0.1), and AGP 9.0 requires minimum Gradle 9.1.0 and removes compatibility with the standalone `org.jetbrains.kotlin.android` plugin (which must be dropped from workout-logger/android/settings.gradle.kts) in favor of built-in Kotlin.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[Devasy]

@coderabbitai open a separate issue for this, to be tracked in another pr

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo="Devasy/RepForge"

body=$(cat <<'EOF'
## Summary

Follow-up to `#59`: migrate `workout-logger/android` to Android Gradle Plugin (AGP) 9.0+ to actually activate the `android.builtInKotlin` and `android.newDsl` gradle.properties flags that were added automatically by the Flutter migrator in `#59`. On the current AGP version (8.11.1), these flags are inert placeholders because Flutter's Gradle plugin only enables built-in Kotlin support when AGP major version >= 9.

## Background

- `workout-logger/android/gradle.properties` sets `android.builtInKotlin=true` and `android.newDsl=true`, but Flutter's Gradle plugin (`FlutterPluginUtils.isBuiltInKotlinEnabled`) explicitly forces this to `false` when AGP major version < 9.
- The project currently pins `com.android.application` and `org.jetbrains.kotlin.android` to 8.11.1 / 2.2.20 in `workout-logger/android/settings.gradle.kts`.
- Official AGP compileSdk compatibility tables list API level 37 (already targeted in `#59`) as requiring minimum AGP 9.1.1, not just 9.0.1.

## Required changes

1. **`workout-logger/android/settings.gradle.kts`**
   - Bump `com.android.application` plugin version to `9.1.1`+ (not just `9.0.1`, due to compileSdk 37 compatibility requirements).
   - Remove the `org.jetbrains.kotlin.android` plugin declaration entirely — AGP 9's new DSL is not compatible with the standalone Kotlin Android plugin; built-in Kotlin support handles this instead.

2. **`workout-logger/android/gradle/wrapper/gradle-wrapper.properties`**
   - Bump Gradle distribution to `>= 9.1.0` (AGP 9.0's minimum Gradle requirement).

3. **`workout-logger/android/app/build.gradle.kts`**
   - Rewrite the ABI-specific `versionCodeOverride` logic, currently implemented via the legacy `android.applicationVariants.configureEach { ... }` API (casting output to `ApkVariantOutputImpl`), using the new `androidComponents.onVariants(...)` variant API. This is the biggest non-trivial code change required.
   - Migrate the `kotlinOptions { jvmTarget = ... }` block to the built-in-Kotlin equivalent DSL (e.g., `kotlin { compilerOptions { jvmTarget = ... } }`), verifying against Flutter's built-in Kotlin migration docs at the time of the upgrade.

4. **Compatibility verification (risk items, not pure version bumps)**
   - Confirm Flutter's `flutter-gradle-plugin` (pinned via Flutter SDK `3.44.4`+ per `#59`) has stable-channel support for AGP major version 9 before committing to the bump.
   - Re-verify the F-Droid signing-block-stripping logic in `app/build.gradle.kts` (the comment about `signingConfig` needing to stay on one line) still holds under the new DSL/variant API.

## Affected files

- `workout-logger/android/settings.gradle.kts`
- `workout-logger/android/gradle/wrapper/gradle-wrapper.properties`
- `workout-logger/android/app/build.gradle.kts`
- `workout-logger/android/gradle.properties` (flags already in place from `#59`, will become active)

## Acceptance criteria

- [ ] AGP bumped to `9.1.1`+ in `settings.gradle.kts`, `org.jetbrains.kotlin.android` plugin declaration removed.
- [ ] Gradle wrapper bumped to `>= 9.1.0`.
- [ ] `android.applicationVariants.configureEach` ABI versionCode logic migrated to `androidComponents.onVariants(...)`.
- [ ] `kotlinOptions.jvmTarget` migrated to the built-in-Kotlin equivalent.
- [ ] Flutter Gradle plugin / Flutter SDK version confirmed compatible with AGP 9 on stable channel.
- [ ] F-Droid build (signing block stripping) verified to still work correctly.
- [ ] CI (`.github/workflows/release.yml`, `.github/workflows/test.yml`) confirmed to require no changes (JDK 17 already set via `actions/setup-java@v4`).

## References

- PR: https://github.com/Devasy/RepForge/pull/59
- Discussion: https://github.com/Devasy/RepForge/pull/59#issuecomment (see AGP 9 migration discussion thread)
- Requested by: `@Devasy`
EOF
)

issue_url=$(gh issue create \
  --repo "$repo" \
  --title "Migrate workout-logger/android to AGP 9.0+ for built-in Kotlin / new DSL support" \
  --body "$body" \
  --assignee "Devasy")

echo "Created issue: $issue_url"

Length of output: 4282

---

@Devasy done — I've opened #60 to track the AGP 9.0+ / built-in Kotlin migration as a follow-up, with the required changes, affected files, and acceptance criteria captured from our discussion. It's assigned to you and links back to this PR.

(⁠｀⁠ヘ⁠´⁠)⁠凸 tracking this properly now — good luck when you tackle it!