Jetpack — qué es, componentes de arquitectura

¿Qué es Android Jetpack?

Android Jetpack es una colección de bibliotecas, herramientas y pautas de arquitectura de Google, presentada en 2018 en Google I/O. Jetpack reemplazó a Support Library y Android Architecture Components, fusionándolos en un solo ecosistema. Antes de Jetpack, cada biblioteca de Android se actualizaba de forma independiente, lo que generaba conflictos de versiones. Jetpack sincronizó las versiones bajo un único identificador AndroidX e introdujo un modelo de versiones mayores estables con parches menores.

Las bibliotecas de Jetpack se dividen en cuatro categorías: Architecture (ViewModel, Room, Navigation, WorkManager), UI (Fragment, Compose, Animation, Palette), Behavior (DownloadManager, Media, Permissions, Sharing), Foundation (Android KTX, Multidex, AppCompat). Cada categoría aborda tareas de una capa específica de la aplicación, desde la gestión de datos hasta la interfaz de usuario.

Filosofía de Jetpack

Google promueve tres principios de Jetpack: accelerate development (menos boilerplate, más lógica de negocio), eliminate boilerplate (ViewModel elimina el guardado manual de estado, Room elimina la necesidad de escribir SQLiteOpenHelper) y build with confidence (cada biblioteca pasa más de 15.000 pruebas antes del lanzamiento). Según Android Developers (2026), las aplicaciones con Jetpack tienen un 30% menos de fallos relacionados con el ciclo de vida.

AndroidX como base

Todas las bibliotecas de Jetpack se distribuyen bajo el identificador AndroidX (artefactos como androidx.*). AndroidX reemplazó a Support Library (artefactos como com.android.support.*), dividiendo la biblioteca monolítica en artefactos modulares con versionado independiente. La migración a AndroidX se realiza mediante la opción android.useAndroidX=true en gradle.properties — Android Studio convierte automáticamente las importaciones.

Componentes de arquitectura: ViewModel, Lifecycle, LiveData

ViewModel es el componente central de la arquitectura Jetpack que almacena datos de la UI. A diferencia de una Activity, que se destruye al rotar la pantalla, ViewModel permanece en memoria. El usuario rellena un formulario, gira el teléfono — los datos no se pierden. ViewModel se limpia automáticamente cuando el LifecycleOwner (Activity o Fragment) finaliza su ciclo de vida de forma permanente (finish).

class ProfileViewModel : ViewModel() {

    private val _userName = MutableLiveData<String>()
    val userName: LiveData<String> = _userName

    fun loadProfile(userId: String) {
        viewModelScope.launch {
            val user = repository.getUser(userId)
            _userName.value = user.name
        }
    }
}

@OptIn(ExperimentalLifecycleApi::class)
class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_START)
    fun onStart() {
        println("Pantalla iniciada")
    }
}

LiveData — un contenedor de datos observable que respeta el ciclo de vida. Si la pantalla no es visible (onStop), LiveData no envía actualizaciones, lo que evita fugas de memoria y fallos al intentar actualizar una Activity inexistente. Lifecycle — una clase que almacena el estado actual (CREATED, STARTED, RESUMED) y permite que otros componentes se suscriban a los cambios de estado. Juntos, ViewModel, LiveData y Lifecycle forman la base de la arquitectura reactiva de Android.

ViewModelScope y corrutinas

viewModelScope — un CoroutineScope integrado vinculado al ciclo de vida de ViewModel. Todas las corrutinas lanzadas en este ámbito se cancelan automáticamente al limpiar ViewModel. Esto elimina la gestión manual de Disposable y CompositeDisposable en cada ViewModel. Para trabajar con viewModelScope se requiere la dependencia androidx.lifecycle:lifecycle-viewmodel-ktx.

Room: trabajar con base de datos en Android

Room es una biblioteca ORM de Jetpack que proporciona una capa abstracta sobre SQLite. En lugar de escribir consultas SQL sin procesar y convertir manualmente Cursor a objetos, el desarrollador declara una Entity (tabla), DAO (Data Access Object) y Database (punto de entrada). Room verifica las consultas SQL en tiempo de compilación mediante la anotación @Query — si las tablas o columnas no existen, la compilación falla con un error claro.

@Entity
data class User(
    @PrimaryKey val id: String,
    val name: String,
    val email: String
)

@Dao
interface UserDao {
    @Query("SELECT * FROM User WHERE id = :userId")
    suspend fun getUser(userId: String): User?

    @Insert
    suspend fun insertUser(user: User)
}

@Database(entities = [User::class], version = 1)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

La Entity User describe una tabla con tres columnas. El DAO declara funciones suspend para trabajar con corrutinas — la consulta se ejecuta en un hilo secundario automáticamente. Room admite migraciones mediante la anotación @Migration: el desarrollador describe el script SQL de transición entre versiones y Room lo ejecuta sin pérdida de datos. En ausencia de migración, Room lanza IllegalStateException, protegiendo los proyectos contra la pérdida accidental de datos al actualizar el esquema.

TypeConverters y relaciones

Room almacena solo tipos primitivos y sus envoltorios. Para almacenar listas, Date u objetos personalizados se utiliza @TypeConverter, un método estático que convierte un tipo a String (JSON) o Long (timestamp). Las relaciones entre tablas se modelan mediante objetos anidados con la anotación @Relation y clases POJO auxiliares con @Transaction para consultas join eficientes.

Navigation Component: grafos y argumentos

Navigation Component — una biblioteca de Jetpack para gestionar transiciones entre pantallas. En lugar de llamar manualmente a FragmentTransaction, el desarrollador crea un grafo de navegación (archivo XML con nodos de destino) y el sistema genera una clase Directions con métodos de transición type-safe. Navigation Component garantiza el correcto funcionamiento de la pila de retroceso, los deep links y el paso de argumentos entre pantallas.

// nav_graph.xml
// 
//     android:name=".ProfileFragment">
//     
//         android:defaultValue="-1"
//         app:argType="integer" />
// 

// En el código del fragmento:
class ProfileFragment : Fragment() {
    private val args: ProfileFragmentArgs by navArgs()

    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        loadProfile(args.userId)
    }
}

Los argumentos userId se pasan en el grafo de navegación con especificación de tipo (integer) y valor predeterminado. La clase ProfileFragmentArgs se genera automáticamente mediante el plugin Navigation Safe Args — contiene todos los argumentos con los tipos correctos de Kotlin. Los deep links se configuran en el grafo: app:deepLink="app://profile/{userId}". Navigation Component analiza la URL y crea la pila de retroceso como si el usuario hubiera navegado por la interfaz.

Bottom Navigation y navegación condicional

Navigation Component se integra con BottomNavigationView a través de NavController: cada elemento del menú se vincula a un destino en el grafo. El cambio entre pestañas no recrea el fragmento — Navigation Component conserva el estado mediante NavBackStackEntry. Para la navegación condicional (mostrar inicio de sesión si no está autenticado), se utiliza navController.navigate(condition) con una verificación en onCreate.

AndroidX: la Support Library de nueva generación

AndroidX es una arquitectura rediseñada de Support Library en la que cada biblioteca recibió su propio artefacto con una versión independiente. En lugar de un único com.android.support:appcompat-v7:28.0.0, AndroidX ofrece androidx.appcompat:appcompat:1.7.0, androidx.recyclerview:recyclerview:1.4.0 y así sucesivamente. Esto eliminó el problema de que diferentes dependencias arrastraban distintas versiones de Support Library, causando conflictos.

La migración a AndroidX se realiza automáticamente en Android Studio 3.2+ mediante el menú Refactor → Migrate to AndroidX. El estudio reemplaza todas las importaciones en archivos Java/Kotlin, manifiestos y recursos. La compatibilidad hacia atrás es la principal ventaja de AndroidX: las bibliotecas funcionan en Android 5.0 (API 21) y superior, cubriendo el 97% de los dispositivos activos según Google Play Console (2025).

Artefactos principales de AndroidX

Los artefactos más utilizados: appcompat (tema oscuro, Material Design en APIs antiguas), recyclerview (listas adaptativas con ViewHolder), constraintlayout (contenedor flexible con jerarquía plana), cardview (tarjetas Material Design), preference (pantalla de configuración con estilo Material). Cada artefacto tiene versionado independiente, lo que acelera la entrega de correcciones sin actualizar todo el paquete.

Otras bibliotecas importantes de Jetpack

Además de Architecture y AndroidX, Jetpack incluye muchas bibliotecas especializadas para tareas típicas de desarrollo móvil. WorkManager — para tareas en segundo plano con ejecución garantizada (sincronización, carga de registros), admite tareas periódicas y retardadas, así como restricciones de red y batería. DataStore — un reemplazo de SharedPreferences basado en corrutinas, que admite propiedades tipadas (Preferences DataStore) y Protocol Buffers (Proto DataStore).

• Hilt — un framework de DI basado en Dagger que simplifica la inyección de dependencias mediante las anotaciones @HiltViewModel, @Inject, @Module. Integración integrada con ViewModel y Navigation.
• Paging 3 — una biblioteca para la carga paginada de datos desde red/BD con soporte para RemoteMediator (red + caché), StateFlow y Compose.
• CameraX — una API para trabajar con la cámara, que abstrae las diferencias de los fabricantes (Samsung, Xiaomi, Honor) mediante una interfaz unificada CameraController.
• Security Crypto — cifrado de datos mediante EncryptedSharedPreferences y EncryptedFile basado en AES-256 con una clave maestra en Android Keystore.

Cada biblioteca tiene su propio SDK mínimo y artefacto. Google publica versiones principales una vez al año (coincidiendo con el lanzamiento de Android) y parches de seguridad trimestralmente. Recomendación — incluir solo las bibliotecas necesarias para no aumentar el tamaño del APK. La colección completa de Jetpack (todos los artefactos) pesa más de 20 MB, pero una aplicación típica usa 5–7 bibliotecas, añadiendo 3–5 MB al APK.