Only Slow Right After Install — Cutting Android Cold-Start Time with Baseline Profiles, Measured

Compare before and after with CompilationMode

This is the crux. CompilationMode.None() is the worst-case baseline that uses no profile at all; CompilationMode.Partial(BaselineProfileMode.Require) represents the app with the Baseline Profile bundled and required. Run the same test under both modes and you isolate exactly the difference the profile made.

Specifying Require is deliberate. With BaselineProfileMode.Enable (the default), measurement passes silently even when no profile is present — so you can "measure" a state where nothing was actually bundled. During measurement, use Require so you only ever measure a state where the profile truly applied. I once misjudged a run as "no effect" because the profile wasn't applied, and lost half a day to it.

You can run it from the Android Studio gutter or the command line. For CI, the command is easier to wire up.

./gradlew :macrobenchmark:connectedBenchmarkAndroidTest \
  -P android.testInstrumentationRunnerArguments.class=com.example.wallpaper.macrobenchmark.StartupBenchmark

Generate the Baseline Profile

Once you can measure, generate the profile itself. Generation also happens in a dedicated com.android.test module, handled by the androidx.baselineprofile plugin.

// build.gradle.kts of the :baselineprofile module
plugins {
    id("com.android.test")
    id("org.jetbrains.kotlin.android")
    id("androidx.baselineprofile")
}
 
dependencies {
    implementation("androidx.test.ext:junit:1.2.1")
    implementation("androidx.test.uiautomator:uiautomator:2.3.0")
    implementation("androidx.benchmark:benchmark-macro-junit4:1.3.3")
}

The generator reproduces the routes real users take. Launch, scroll the grid a little, open a detail — trace your busiest path honestly. Whatever you enumerate here becomes the target for AOT compilation.

// BaselineProfileGenerator.kt
@RunWith(AndroidJUnit4::class)
class BaselineProfileGenerator {
    @get:Rule val rule = BaselineProfileRule()
 
    @Test fun generate() = rule.collect(
        packageName = "com.example.wallpaper",
        // also optimize dex layout for the startup classes
        includeInStartupProfile = true,
    ) {
        pressHome()
        startActivityAndWait()
 
        // reproduce the actual primary route
        val grid = device.findObject(By.res(packageName, "wallpaper_grid"))
        grid.fling(Direction.DOWN)
        grid.fling(Direction.UP)
        device.findObject(By.res(packageName, "thumbnail_0")).click()
        device.wait(Until.hasObject(By.res(packageName, "detail_image")), 5_000)
    }
}

Adding includeInStartupProfile = true also produces a Startup Profile that pulls startup-route classes toward the front of the dex. That is a separate axis from AOT: it improves the on-disk locality of the classes read at launch. It's subtle, but it helps most on low-end devices.

Here is the generation command. When it finishes, a text-form profile is written into the release source set.

./gradlew :app:generateReleaseBaselineProfile
# example output: app/src/release/generated/baselineProfiles/baseline-prof.txt

Bundle the generated profile into the app

You add only two things on the app side. One is androidx.profileinstaller, which is responsible for handing the profile to ART at install time. Many Jetpack libraries pull it in transitively, but declaring it explicitly is safer.

// app/build.gradle.kts
plugins {
    id("com.android.application")
    id("org.jetbrains.kotlin.android")
    id("androidx.baselineprofile")
}
 
dependencies {
    implementation("androidx.profileinstaller:profileinstaller:1.4.1")
    baselineProfile(project(":baselineprofile"))
}
 
baselineProfile {
    // auto-merge the generated artifact into the release source set
    automaticGenerationDuringBuild = false
}

Setting automaticGenerationDuringBuild to false is an indie-developer call. Regenerating the profile on every build makes a physical device mandatory and slows both CI and local builds. I regenerate by hand only before a release and commit the artifact. With baseline-prof.txt in Git, even builds that skip regeneration always bundle the latest profile.

With that in place, build the release AAB and confirm assets/dexopt/baseline.prof is present. If it isn't, nothing you measure will show an effect.

./gradlew :app:bundleRelease
unzip -l app/build/outputs/bundle/release/app-release.aab | grep baseline.prof
# seeing base/assets/dexopt/baseline.prof and baseline.profm means it bundled

How much it shrank in my wallpaper app

For one of the wallpaper apps I run, the kind that assembles a grid on launch, I measured cold start 15 times each on a physical Pixel 6a. The numbers are the median (P50) of Time To Initial Display, plus P90 to show the spread.

What stands out is that the "brand new" number with a Baseline Profile (503ms) nearly matched the well-used device whose profile had matured (486ms). In other words, the Baseline Profile front-loads, from the first install, the state Cloud Profiles take time to reach. The P90 shrank a lot too, and that calmer worst case is what directly answered the "heavy the first time" review.

One caveat about the numbers. The TTID from StartupTimingMetric is "until the first frame," so if you want to measure until the app is genuinely usable — images loaded — call reportFullyDrawn() from the screen and watch Time To Full Display as well. I treat TTFD as the primary metric only on screens where thumbnail loading is heavy.

Where I tripped, and how I keep it going solo

The first thing that stumped me was a profile that looked bundled but had no effect. The cause was running measurement with CompilationMode.Partial(BaselineProfileMode.Enable), which passed through even with no profile applied. Always use Require during measurement and you avoid it.

The second is profile freshness. If you don't regenerate after a big change to a screen, you optimize the old hot paths and leave the new route cold. I forgot this after rebuilding the wallpaper detail screen, and took the long way around when a startup I thought I'd fixed felt heavy again. Since adding one line — "regenerate the Baseline Profile" — to my pre-release checklist, it's been stable.

Roll out gradually while confirming you haven't broken startup metrics. I always start at 5% and widen to 25% → 50% → 100% while watching Play Console startup time and ANR rate. Profile-related defects are rare, but profileinstaller can fail to install on a small subset of devices, and staged release lets you stop there. For the same family of release-only Android pitfalls, walking through tracking down a release-only R8 and Gson crash alongside this covers the obfuscation-side traps. If you're adding localization, switching the app's language independently of device settings touches the startup route too, so include it in the generator's path.

If you try just one thing, add a measurement module and run CompilationMode.None and Partial(Require) 15 times each to see how far apart your app's P50 sits. That gap is the headroom a Baseline Profile can win back. Thanks for reading.