Skip to content

Instantiate default integrations conditionally instead of eagerly #5705

Description

@runningcode

Problem

AndroidOptionsInitializer.installDefaultIntegrations (sentry-android-core/src/main/java/io/sentry/android/core/AndroidOptionsInitializer.java:352-445) allocates ~17 integration objects before the user's options callback runs — including for features that end up disabled — because integrations must not read options in their constructors. Each instantiation also triggers class loading + verification. SentryAndroid.deduplicateIntegrations then scans the whole list with instanceof to drop duplicates (SentryAndroid.java:232-277).

Proposal

Investigate a descriptor model: register lightweight (enabled-predicate, supplier) pairs and instantiate only enabled integrations at register time. Saves allocations and class loads for disabled features, and makes deduplication cheaper.

Constraints

  • options.getIntegrations() is public API; users add/remove instances in the configuration callback — needs a compatible path (e.g. descriptors resolved into the list before the callback sees it, or a parallel lazy list).

Metadata

Metadata

Assignees

No one assigned

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions