Skip to content

Move aar_init_script off legacy AGP APIs - #9

Open
reidbaker-agent wants to merge 1 commit into
agp-add-to-appfrom
agp-aar-script
Open

Move aar_init_script off legacy AGP APIs#9
reidbaker-agent wants to merge 1 commit into
agp-add-to-appfrom
agp-aar-script

Conversation

@reidbaker-agent

@reidbaker-agent reidbaker-agent commented Jul 22, 2026

Copy link
Copy Markdown
Owner

Phase 9 of 11 of the AGP public-API migration; stacked on #8.

Phase P8 of the AGP public-API migration (flutter#180137,
flutter#166550):

  • The library-project check no longer probes for the legacy
    android.libraryVariants property (absent under the new DSL); it
    checks for the com.android.library plugin. Error message unchanged.
  • The plugin-to-module assembleAar task wiring enumerates published
    variants through the public software components (which the script
    already used for task creation) instead of libraryVariants.
  • The singleVariant dedup guard no longer reads the internal
    publishing.singleVariants collection. Flutter now marks projects it
    configured with an ext property and declares each variant's
    publishing in a try-catch: when the project's own build file already
    declared publishing for a variant, the user's declaration wins and a
    warning explains the situation and the fix. (Previously any
    user-declared variant silently disabled Flutter's publishing setup
    for ALL variants, which broke partially-declared projects at
    publication time with no explanation.)

Verification (CI): flutter build aar with and without flavors for
module and plugin projects; AAR-host add-to-app flow; a scratch module
with a partial user singleVariant declaration; newDsl=true aar flow.

Revert-safe even after P10, but not after P9.

CI must run the FGP unit tests (the Kotlin suite in packages/flutter_tools/gradle could not run in the delivery sandbox: dl.google.com returns 403, so AGP artifacts do not resolve).

Phase P8 of the AGP public-API migration (flutter#180137,
flutter#166550):

- The library-project check no longer probes for the legacy
  android.libraryVariants property (absent under the new DSL); it
  checks for the com.android.library plugin. Error message unchanged.
- The plugin-to-module assembleAar task wiring enumerates published
  variants through the public software components (which the script
  already used for task creation) instead of libraryVariants.
- The singleVariant dedup guard no longer reads the internal
  publishing.singleVariants collection. Flutter now marks projects it
  configured with an ext property and declares each variant's
  publishing in a try-catch: when the project's own build file already
  declared publishing for a variant, the user's declaration wins and a
  warning explains the situation and the fix. (Previously any
  user-declared variant silently disabled Flutter's publishing setup
  for ALL variants, which broke partially-declared projects at
  publication time with no explanation.)

Verification (CI): flutter build aar with and without flavors for
module and plugin projects; AAR-host add-to-app flow; a scratch module
with a partial user singleVariant declaration; newDsl=true aar flow.

Revert-safe even after P10, but not after P9.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants