Skip to content

Fix Play verification file generation #150

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

timkimadobe
Copy link
Contributor

@timkimadobe timkimadobe commented Jul 17, 2025

Note

This change will bump the AEPSDK Gradle Plugin version from gp-3.4.0 to gp-3.4.1

Description

What changed

  • Moved the call to generatePlayConsoleVerificationFile(..) from when AEPLibraryPlugin was applied to the project.afterEvaluate { … } block.

Caution

This approach makes it so that if you turn the flag on, you need the token locally to even build the project which may not be an optimal development experience

Why it was needed

generatePlayConsoleVerificationFile() depends on user-supplied DSL values:

  • aepLibrary { enablePlayConsoleVerification = true }
  • namespace = "com.example.sdk"
  • GOOGLE_TOKEN / PLAY_CONSOLE_VERIFICATION_TOKEN

When the plugin executed at apply time those properties were not yet set
(the build script hadn’t been evaluated), so:

  • enablePlayConsoleVerification was still false → file never generated.
  • The expected “missing GOOGLE_TOKEN” error was never thrown, hiding
    configuration problems.

By deferring the generation to afterEvaluate we guarantee:

  • The build script has already populated all extension fields.
  • The verification file is generated (or a clear error is raised) whenever
    enablePlayConsoleVerification is true.
  • Behaviour is now consistent whether the task is run locally or in CI.

Testing locally, now when the enablePlayConsoleVerification = true the process fails at the build stage with a missing token error as expected

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

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.

1 participant