perf(instrumentation): Inject manifest metadata at build time

[romtsn]

📜 Description

Parse resolved io.sentry.* entries from the merged Android manifest and inject
their typed values into ManifestMetadataReader during bytecode instrumentation.
The optimization uses the existing runtimeOptimizations.enabled flag and only
runs with sentry-android-core 8.54.0 or newer.

Resource references, unresolved placeholders, and unsupported SDK versions keep
using the existing runtime manifest lookup.

Companion SDK PR: getsentry/sentry-java#5963

💡 Motivation and Context

Sentry Android initialization currently retrieves application metadata through
PackageManager and lazily unparcels its Bundle. Resolving manifest metadata at
build time removes both operations from the startup path.

Refs JAVA-531

💚 How did you test it?

• ./gradlew spotlessApply
• Parser and ASM visitor unit tests
• Integration tests for resolved values and resource-reference fallback
• Validated all 98 supported manifest keys in a real app in injected and fallback modes
• Confirmed in Perfetto that both startup getApplicationInfo calls disappear when injected
• Compared 24 cold starts per mode; direct-map init median improved from 32.987 ms to 30.835 ms

📝 Checklist

• I reviewed the submitted code
• I added tests to verify the changes
• I updated the docs if needed
• No breaking changes

🔮 Next steps

Merge the SDK support in getsentry/sentry-java#5963 before releasing this optimization.

[linear-code]

JAVA-531

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0d32407. Configure here.}

[cursor]

Shared cache key reuses injected metadata

High Severity

buildTimeMetadataCacheKey now comes from SentryModulesService, a single registerIfAbsent build service shared by every project and variant. The isolation key is therefore identical across apps and flavors, so AGP can reuse ManifestMetadataReader bytecode injected for a different variant. Product flavors and debug/release often have different io.sentry.* metadata, including DSNs.

Additional Locations (1)

• plugin-build/src/main/kotlin/io/sentry/android/gradle/services/SentryModulesService.kt#L25-L26

 

^{Reviewed by Cursor Bugbot for commit 0d32407. Configure here.}

[sentry]

Bug: The buildTimeMetadata() function is called twice without caching. A transient failure on the second call will crash the build due to an unchecked null.
_{Severity: MEDIUM}

Suggested Fix

Cache the result of the buildTimeMetadata() call within the factory instance. The result from the first invocation in isInstrumentable should be stored and reused in createClassVisitor. This avoids re-reading the file from disk and eliminates the race condition where a transient I/O error could cause a build crash.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location:
plugin-build/src/main/kotlin/io/sentry/android/gradle/instrumentation/SentrySdkOptimizationClassVisitorFactory.kt#L56

Potential issue: The `buildTimeMetadata()` function, which reads and parses the merged
manifest file, is called independently in `isInstrumentable` and `createClassVisitor`
without caching the result. The Android Gradle Plugin (AGP) guarantees that if
`isInstrumentable` returns true, `createClassVisitor` will be called. However, if the
first file read succeeds but the second one fails due to a transient I/O error, the
`checkNotNull(buildTimeMetadata())` call in `createClassVisitor` will throw an
`IllegalStateException`, causing the build to crash. This creates a potential for rare,
hard-to-diagnose build failures.

Also affects:

• plugin-build/src/main/kotlin/io/sentry/android/gradle/instrumentation/SentrySdkOptimizationClassVisitorFactory.kt:69~72

[romtsn]

Superseded by a generated app-class design. The replacement makes the SDK bytecode rewrite identical for every app and puts variant-specific manifest values in a normally generated app class, avoiding synthetic cache keys and cross-app transform reuse.