androidx.startup en 2026: ordenar la inicialización de librerías sin una pila de ContentProviders

Toda librería que necesita ejecutar código antes de que arranque tu primera Activity lo hace de la misma manera: un ContentProvider sin lógica de consulta, cuyo único trabajo es dispararse durante el arranque de la app. WorkManager lo hace. Firebase lo hace. Cualquier SDK de analítica o reporte de fallos que añadas también lo hace. Cada uno es invisible en tu propio código, y cada uno está realizando una inicialización completa de componente —registro de binder, una nueva llamada a ContentResolver— antes de que tu app haya dibujado un solo píxel. androidx.startup existe para condensar todo eso en un único ContentProvider, con un grafo de dependencias explícito en lugar de uno accidental.

Me topé con esto mientras recortaba el tiempo de arranque en frío en Mintly, donde WorkManager, una pequeña capa de logging y mi propio paso de precarga registraban cada uno su propio provider. Esto es lo que App Startup realmente aporta, y dónde la inicialización perezosa manual sigue ganando.

El problema que resuelve

ContentProvider.onCreate() se ejecuta en el hilo principal, antes de que Application.onCreate() retorne, para cada provider declarado en el manifiesto —en un orden que Android no garantiza. Eso está bien cuando hay uno. Deja de estarlo en cuanto tres o cuatro librerías envían cada una el suyo, porque:

• Cada provider es un componente completo que el sistema tiene que instanciar y registrar, con su propio coste fijo.
• No tienes control sobre el orden. Si tu capa de logging necesita que la Configuration de WorkManager ya exista, estás confiando en el orden de fusión del manifiesto, que no es un contrato.
• No puedes desactivar fácilmente uno para una variante de build —un build de debug que no necesita el reporte de fallos igualmente paga el coste del onCreate() de ese provider.

Multiplica el coste fijo de instanciar un provider por cada SDK en tu build.gradle, y se acumula justo en la métrica —el arranque en frío— que normalmente intentas proteger.

Lo que App Startup pone en su lugar

androidx.startup define un único InitializationProvider, y tu librería o app registra implementaciones de Initializer<T> en él en lugar de enviar su propio provider. El propio WorkManager migró a este modelo hace años —su WorkManagerInitializer pasa por el mismo InitializationProvider que tus propios initializers, no por uno separado.

Un initializer para una pequeña configuración de logging se ve así:

class LoggingInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        Log.setLogLevel(if (BuildConfig.DEBUG) Log.VERBOSE else Log.WARN)
    }

    override fun dependencies(): List<Class<out Initializer<*>>> = emptyList()
}

Declarado una vez en el manifiesto, bajo el único punto de fusión InitializationProvider:

<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    android:exported="false"
    tools:node="merge">
    <meta-data
        android:name="com.mfkapps.mintly.LoggingInitializer"
        android:value="androidx.startup" />
</provider>

Cada librería que usa App Startup fusiona sus entradas <meta-data> en este mismo bloque de provider mediante la fusión de manifiestos. Terminas con una única instancia de ContentProvider haciendo el trabajo que antes requería una por librería.

Declarar dependencias reales

La parte que la suerte del orden del manifiesto solía disimular es dependencies(). Si un initializer de seguimiento de sesión necesita que WorkManager esté configurado primero, dilo explícitamente:

class SessionTrackingInitializer : Initializer<Unit> {
    override fun create(context: Context) {
        WorkManager.getInstance(context).enqueue(sessionHeartbeatRequest())
    }

    override fun dependencies(): List<Class<out Initializer<*>>> =
        listOf(WorkManagerInitializer::class.java)
}

App Startup construye un grafo de dependencias a partir de estas declaraciones y lo ordena topológicamente, de modo que WorkManagerInitializer.create() siempre termina antes de que se ejecute SessionTrackingInitializer.create() —independientemente del orden de fusión, independientemente de qué módulo de Gradle declaró qué dependencia primero. Esa garantía es la característica real; consolidar providers es solo el mecanismo que la hace posible.

Desactivar uno sin borrar la librería

La otra necesidad común es desactivar un initializer específico para una variante de build —un build de debug que no debería arrancar un pipeline de analítica de producción, por ejemplo. No bifurcas la dependencia; eliminas su entrada <meta-data> en el manifiesto de esa variante:

<!-- src/debug/AndroidManifest.xml -->
<provider
    android:name="androidx.startup.InitializationProvider"
    android:authorities="${applicationId}.androidx-startup"
    tools:node="merge">
    <meta-data
        android:name="com.mfkapps.mintly.analytics.AnalyticsInitializer"
        tools:node="remove" />
</provider>

El código de la librería queda intacto; solo desaparece el disparador que lo ejecuta en el arranque para esa variante.

Dónde no ayuda

App Startup solo elimina el coste de tener un provider. No hace nada respecto al coste de lo que el método create() del initializer realmente hace —y create() sigue ejecutándose de forma síncrona en el hilo principal por defecto, igual que hacía el antiguo ContentProvider.onCreate(). Si la inicialización de un SDK realmente no necesita terminar antes de tu primer frame, App Startup no es la solución; diferir ese trabajo a una corrutina en segundo plano lanzada desde Application.onCreate(), o de forma perezosa en el primer uso, sí lo es. Moví el initializer de seguimiento de sesión de Mintly fuera del modelo Initializer por completo, a una solicitud única de WorkManager que se dispara después de dibujarse el primer frame —necesitaba ocurrir pronto, no antes que todo lo demás.

La regla a la que llegué: usa androidx.startup para todo lo que una librería deba configurar antes de que otro código pueda tocarla con seguridad —el caso del propio WorkManager, o un contenedor de inyección de dependencias que otros initializers asumen que existe. Usa inicialización diferida, perezosa o en segundo plano para todo lo que simplemente es conveniente arrancar temprano. Consolidar providers y ordenar los que deben ejecutarse temprano es valor real; tratar App Startup como un lugar donde meter el código repetitivo de cada SDK solo traslada el mismo coste del hilo principal a un único provider distinto en lugar de varios.