IssueTracker

You mention that this happens with ./gradlew assembleDebug. Do you get the same when building the release version (./gradlew assembleRelease)?

Baseline Profile Gradle Plugin shouldn't ever add a source directory with profiles (startup or baseline profiles) to a debug variant.

Are you using the Baseline Profile Gradle Plugin to generate and store these files?

Are you customizing where your startup profiles are in your project?

Jerome/Soren/Rahul - for the AGP side, it seems like it would be reasonable for AGP to always ignore startup profiles in debuggable builds, just like baseline profiles, since they would likely interfere with incremental builds (would they break per-module dex files?). Was this behavior intentionally decided? Could this have changed in 8.4?

That's correct - we're also seeing the same when building our benchmarking app (which effectively is assembleNonMinfiedRelease).

So actually I might be at fault here, as this is was my setup (using the plugin):

baselineProfile {
  saveInSrc = true
  automaticGenerationDuringBuild = false

  // effectively app/src/main/baselineProfiles
  baselineProfileOutputDir = "../../src/main/baselineProfiles"

  baselineProfileRulesRewrite = true
  dexLayoutOptimization = true
}

Adopted profiles early and that was the initial path - I suppose now it should be src/main/generated/baselineProfiles.

baselineProfileOutputDir is by default generated/baselineProfiles in src/<variant>, i.e. src/<variant>/generated/baselineProfiles/.

When setting it as ../../src/main/baselineProfiles you're placing in src/<variant>/generated/baselineProfiles/../../src/main/baselineProfiles, i.e. after resolution src/main/baselineProfiles, losing the variant information. As a result each profile generated (in case you've multiple variants) will overwrite that same file.

The correct way to do this and place it into main is setting mergeIntoMain = true:

baselineProfile {
  saveInSrc = true
  automaticGenerationDuringBuild = false

  mergeIntoMain = true

  baselineProfileRulesRewrite = true
  dexLayoutOptimization = true
}

This will ensure that all the variants are merged into src/main/generated/baselineProfiles, avoiding overwriting. Note that this is different from src/main/baselineProfiles, that is the default srcset for baseline profiles. While src/main/generated/baselineProfiles is added as srcset specifically to the release variants by the baseline profile gradle plugin, src/main/baselineProfiles always exists for all the variants (including debug). As a result, when building debug the startup profiles in src/main/baselineProfiles are always considered.

This probably doesn't need to happen for debug variants (no reason to slow down debug build). It's a bit of an odd case that shouldn't happen when using baselineProfileOutputDir and mergeIntoMain properly.

Thank you for clarifying this. I opened up the issue as this was behaving without a hitch in AGP 8.3.

Now I remember that, given that I have three different flavors - dev, stage and prod, I explicitly didn't want to set mergeIntoMain = true as then this would generate baseline profiles for all of the variants, which I don't need. I specifically run ./gradlew generateProductionBaselineProfile only.

Is there a better way to set it up?

You can enable automatic generation for a single build type or even flavor. Here's an example to enable automatic generation for a prod flavor and disable it for other builds.

android {
  buildTypes {
    prod {
      initWith("release")
      baselineProfile.automaticGenerationDuringBuild = true
    }
  }
}

baselineProfile {
  automaticGenerationDuringBuild = false
  // Other global config for baseline profile generation.
}

Thank you, but I don't want to automatically generate baselines during builds. It would be great if I could disable specific baselineProfiles generation variant tasks when using mergeIntoMain.

You can do disable specific baseline profiles with example I posted here:

// In app/build.gradle

dependencies {
    baselineProfile(project(":baselineprofile"))  <-- REMOVE
}

baselineProfile {
    ...
    variants {
        release {
            from(project(":benchmark:integration-tests:baselineprofile-producer"))
        }
        releaseLibrariesOnly {
            // No dependency set
        }
    }
}

The global dependency automatically connects each variants to the baseline profile generator module. But if you want to connect some specific variants only you can do it with the variants block in baselineProfile. Simply remove the baselineProfile dependency from the dependencies block and add from configurations in the variants blocks.

You can also configure some variants only to mergeIntoMain, as well as automaticGenerationDuringBuild.

Example:

baselineProfile {

    // Global properties, applied to all the variants.
    mergeIntoMain = true
    ...

    variants {

        // `release` only properties, override global properties.
        release {
            from(project(":benchmark:integration-tests:baselineprofile-producer"))
            // Inherits global mergeIntoMain (i.e. `true`).
            automaticGenerationDuringBuild = true
        }

        // `anotherRelease` only properties, override global properties.
        anotherRelease {
            // Without a `from` config, it won't pull baseline profiles from the baseline profile generator module.

            // Overrides global merge into main
            mergeIntoMain = false
        }
    }
}

Properties that are specified per variant (or build type) override the global configuration that is outside the variants block.

A fix for this has been submitted, which removes the startup profile tasks from being run for debug builds.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Koala Feature Drop | 2024.1.2 Canary 3
• Android Gradle Plugin 8.6.0-alpha03

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Will the fix also be backported to AGP 8.4.x ?

There are no current plans to backport this change.