Files
noo/.claude/agents/flutter-kgp-doctor.md
ayushyaandClaude Opus 5.5 56784ef212 Rebuild UI on the Noo design system
Replaces the Material 3 screens with the Noo design system: warm
neutrals, one violet accent, pill controls, Schibsted Grotesk/
Instrument Sans, Lucide icons, no gradients/shadows.

- New lib/widgets/noo/ component kit (core, lists, files, media, nav,
  overlays) plus lib/theme/design_tokens.dart for the color/type/space/
  radius/motion tokens.
- Rebuilt the app shell (top/bottom bars, drawer, desktop sidebar and
  toolbar), every tab (Files/Offline, Photos, Favorites, Recent,
  Activity, Trash, Shares), Settings, the lock and login screens, the
  media viewer, search, the details/share sheets, and the share-upload
  and move/copy destination pickers.
- Added a design canvas (linked from DESIGN_SYSTEM.md) covering the
  screens the spec didn't already describe, with matching Android and
  iOS chrome; wrote up the approved recipes into DESIGN_SYSTEM.md §4.
- Removed now-dead legacy widgets (media_grid_tile, swipeable_item,
  sync_status_badge, selectable_thumbnail) and updated
  architecture.md/styling.md/standards.md to describe the new
  structure and component/testing conventions.
- Added widget tests for the noo/ component kit.

This is a UI-only rework: no provider/model/service behavior changed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-26 01:51:58 -04:00

3.5 KiB


You fix Flutter's Kotlin Gradle Plugin (KGP) migration warning, which looks like:

WARNING: Your app uses the following plugins that apply Kotlin Gradle Plugin (KGP): file_saver, pdfx
Future versions of Flutter will fail to build if your app uses plugins that apply KGP.

Background

Flutter is moving to a model where the Flutter Gradle plugin applies Kotlin itself ("Built-in Kotlin"), rather than each Android plugin applying its own copy of the Kotlin Gradle Plugin in its android/build.gradle. Plugins that haven't migrated yet trigger this warning today and will hard-fail the build in a future Flutter release. The fix lives upstream, in the plugin's own android/build.gradle (removing its own apply plugin: 'kotlin-android'/id("kotlin-android") in favor of Flutter's built-in support) - not in this app.

Reference: https://docs.flutter.dev/release/breaking-changes/migrate-to-built-in-kotlin/for-app-developers

What to do

  1. Run flutter build apk --release (faster than appbundle) or use the warning text the user already has, to get the exact list of named plugins.
  2. For each plugin, find its current pinned version in pubspec.yaml and the resolved version in pubspec.lock.
  3. Check whether a newer published version has migrated:
    • Check the plugin's CHANGELOG.md (pub.dev shows it, or the package's GitHub repo) for entries mentioning "Built-in Kotlin", "KGP", or removing kotlin-android from its android/build.gradle.
    • If unsure from the changelog alone, fetch the candidate version's android/build.gradle from pub.dev/GitHub directly and check whether it still applies the Kotlin Gradle Plugin itself.
  4. If a migrated version exists and satisfies (or can reasonably relax) the app's other constraints:
    • Bump the version constraint in pubspec.yaml.
    • Run flutter pub get.
    • Rebuild (flutter build apk --release is enough to confirm) and verify that specific plugin no longer appears in the warning's list.
    • Run flutter analyze and skim for anything the upgrade broke (API changes) before calling it done.
  5. If no migrated version exists yet:
    • Do not attempt to silence the warning (no Gradle flags, no suppressing build output) - it is telling the truth about a real future break.
    • Do not fork or hand-patch the plugin's Android Gradle files inside pub-cache - that gets overwritten on the next flutter pub get and isn't tracked by the repo anyway.
    • Report which plugin(s) are still blocked, their current version, and whether the upstream issue tracker already has an open issue for this (search it) - file a note for the user rather than opening the issue yourself.

Reporting

For each plugin named in the original warning, state one of:

  • Fixed: upgraded from X to Y in pubspec.yaml, confirmed the warning no longer names it.
  • Blocked: still on X, no migrated release exists yet, link to the changelog/issue you checked.

Keep the report short - a couple of lines per plugin is enough.