Glosario Android
Los 109 términos que necesitas para entrar al mundo móvil, organizados por categorías y explicados en español claro. Del componente más básico hasta las palabras clave de Compose.
Componentes de una aplicación
7 términos Los bloques de construcciónSon los puntos de entrada que el sistema Android puede
iniciar por su cuenta. Cada uno tiene un propósito distinto y todos se declaran en el
AndroidManifest.xml.
Activity · actividad
Pantalla con interfaz de usuario con la que la persona interactúa. Una aplicación suele tener varias: inicio, detalle, ajustes… El sistema controla cuándo se crea, pausa o destruye (su ciclo de vida). Con Compose una Activity suele contener todo el contenido componible de la app.
Fragment · fragmento
Trozo reutilizable de interfaz y comportamiento que vive dentro de una Activity, con su propio ciclo de vida. Fue la forma clásica de dividir pantallas; con Compose se usa menos porque las funciones componibles cumplen ese papel.
Service · servicio
Componente sin interfaz para trabajos de larga duración en segundo plano: reproducir música, descargar un archivo grande. Los hay «en primer plano» (con notificación obligatoria) y «vinculados» (conectados a un componente).
Broadcast Receiver · receptor de difusiones
Escucha mensajes globales del sistema o de otras aplicaciones y reacciona a ellos: «llegó una llamada», «se agotó la batería», «terminó de cargar». Desde versiones recientes muchos deben registrarse en tiempo de ejecución, no en el manifiesto.
Content Provider · proveedor de contenido
Capa que expone datos de tu aplicación a otras de forma segura y controlada. Es la base de datos compartida del sistema: contactos, fotos y archivos pasan por proveedores de contenido.
Application
Clase base única por aplicación que existe mientras el proceso viva. Se usa para inicializar dependencias globales antes que cualquier pantalla (contenedores de inyección, registro de bibliotecas).
WorkManager
Biblioteca de Jetpack para trabajos diferidos que deben ejecutarse aunque la app cierre: sincronizar datos, subir registros. Garantiza ejecución y respeta restricciones (solo con Wi-Fi, con batería…). Hoy es la opción recomendada frente a los servicios puros.
Comunicación entre componentes
8 términos Cómo se hablan las piezasIntent · intención
Mensaje que solicita una acción: abrir una pantalla, iniciar un servicio, compartir texto. Los hay explícitos (nombran al destinatario exacto) e implícitos (describen la acción y el sistema elige quién atiende: «quiero compartir una imagen»). Es el pegamento entre componentes.
Intent Filter · filtro de intención
Declaración en el manifiesto que anuncia qué intenciones sabe atender un componente. Por ejemplo: «soy la pantalla principal» o «sé abrir enlaces miapp.com». Así otras apps —y el propio sistema— pueden llegar hasta ti.
Bundle · paquete / extras
Saco de pares clave-valor que acompaña a las intenciones para pasar datos pequeños entre pantallas: un identificador, un texto. No sirve para objetos grandes: el sistema lo guarda incluso cuando el proceso muere.
PendingIntent · intención pendiente
Permiso entregado a otra parte (notificaciones, alarmas) para ejecutar una acción en tu nombre más adelante, con tu identidad. Típico: al tocar una notificación se abre tu pantalla gracias a una intención pendiente.
Deep Link · enlace profundo
Enlace que lleva directo a una pantalla interior de la aplicación
(miapp://producto/42 o una dirección web). Se declara con filtros de
intención y Compose Navigation lo resuelve como cualquier otra ruta.
Task · tarea
Secuencia de pantallas que la persona recorrió para lograr algo. Cada aplicación en la barra de aplicaciones recientes representa normalmente una tarea.
Back Stack · pila de retroceso
Pila donde se apilan las pantallas abiertas dentro de una tarea. Al pulsar «atrás» se desapila la actual y reaparece la anterior. Compose Navigation administra su propia pila de destinos siguiendo esta idea.
ActivityResultContracts · lanzadores / launchers
Mecanismo moderno para pedir resultados a otras pantallas o al sistema:
elegir una foto, tomar una imagen, conceder un permiso. En Compose se usan con
rememberLauncherForActivityResult. Reemplazó al veterano
onActivityResult.
Compilación, firma y publicación
10 términos Del código a la tiendaTérminos que aparecerán al construir y distribuir tu aplicación.
Gradle
Sistema de construcción que compila, prueba y empaqueta tu proyecto. Su configuración
vive en archivos build.gradle.kts escritos en Kotlin: ahí declaras la
versión del kit, las bibliotecas de las que dependes y cómo se genera el instalable.
APK · Android Package
Archivo de instalación de Android (como un ejecutable en Windows): contiene el código compilado, recursos y manifiesto. Hoy se genera a partir del paquete siguiente.
AAB · Android App Bundle
Formato moderno de publicación. Subes un único paquete con todo y Google Play genera instalables optimizados por dispositivo (solo los idiomas y densidades necesarios), reduciendo mucho el tamaño descargado.
AAPT2
Herramienta interna del proceso de compilación que procesa y empaqueta los recursos: imágenes, textos traducidos, disposiciones. Casi nunca la llamas tú; Gradle lo hace.
R8 / minificación
Etapa de compilación que reduce y ofusca el código: elimina lo no usado, acorta
nombres y optimiza. Disminuye tamaño y dificulta la ingeniería inversa. Se configura
con reglas proguard-rules.pro.
Firma digital / keystore
Toda aplicación debe firmarse criptográficamente para poder instalarse. La clave
vive en un almacén (.jks/.keystore) que DEBES respaldar: perderla impide
actualizar la app publicada. Para pruebas existe una clave de depuración automática.
versionCode / versionName
Doble identidad de cada publicación: el código es un número interno siempre creciente (1, 2, 3…) y el nombre es el que ve el usuario («1.0», «2.1.4»). Google Play exige códigos nuevos en cada envío.
minSdk / targetSdk / compileSdk
Versions de Android que definen tu ventana de compatibilidad: la mínima soportada, la contra la que diseñaste comportamientos y la con la que compilaste. Ejemplo típico actual: 24 / 35 / 35.
Play Console
Panel web donde gestionas tu aplicación publicada: subir paquetes, ficha de tienda, precios, informes de fallos y estadísticas. Requiere cuenta única de pago inicial.
Pistas de prueba · pruebas internas, cerradas, abiertas
Etapas de distribución antes de producción: interna (equipo), cerrada (grupo de probadores) y abierta (cualquiera). Permiten validar sin exponer la app a todo el mundo.
Entorno y herramientas
7 términos Tu caja de herramientasSDK · kit de desarrollo de software
Conjunto completo para desarrollar para una plataforma: bibliotecas, herramientas, documentación e imágenes del sistema. El de Android se administra desde el propio Android Studio o desde su administrador independiente.
Android Studio
Editor oficial, basado en IntelliJ IDEA. Trae integrados: diseñador de vistas previas, emulador, depurador, inspector de interfaz y asistentes de refactorización. Es la herramienta central del curso.
Emulador / AVD · dispositivo virtual
Máquina virtual que simula un teléfono real en tu computadora: eliges modelo, tamaño de pantalla y versión de Android. Permite probar sin tener decenas de equipos físicos. Un dispositivo físico por cable USB también funciona y es más rápido.
ADB · puente de depuración
Herramienta de línea de comandos que comunica tu computadora con cualquier dispositivo Android (físico o virtual): instalar aplicaciones, leer registros, abrir una consola dentro del equipo. Imprescindible para depurar.
Logcat
Consola unificada de mensajes del sistema y de tu aplicación. Escribes con
Log.d("etiqueta", "mensaje") y filtras por etiqueta o nivel. El primer
lugar donde mirar cuando algo falla.
Layout Inspector
Visor en vivo de la jerarquía de interfaz de tu app corriendo: muestra cada elemento, sus medidas y —en Compose— qué funciones se recomponen. Clave para entender y optimizar pantallas complejas.
Profiler · perfilador
Panel de Android Studio que grafica consumo de procesador, memoria, red y batería en tiempo real. Sirve para detectar fugas de memoria y operaciones lentas antes que tus usuarios.
Interfaz tradicional (Views)
9 términos El sistema anterior a ComposeAún verás estos conceptos en proyectos antiguos y en bibliotecas. Conócelos aunque trabajes con Compose.
View · vista
Bloque básico de la interfaz clásica: un rectángulo que dibuja algo y responde a eventos. Botones, textos y campos son vistas. Equivalente conceptual en Compose: cada función componible.
ViewGroup · grupo de vistas
Contenedor que organiza otras vistas dentro de sí: filas, columnas, superposiciones.
En Compose ese papel lo cumplen Column, Row y Box.
Layout XML · disposición declarativa antigua
Forma anterior de describir interfaces: archivos XML en la carpeta
res/layout que luego se «inflan» en código. Compose reemplaza esto por
funciones Kotlin directamente.
LinearLayout
Contenedor clásico que apila hijos en fila o columna. Simple pero limitado; anidamientos profundos afectaban el rendimiento.
ConstraintLayout · disposición por restricciones
Contenedor potente donde cada vista se posiciona mediante relaciones con otras («centrado respecto a X», «debajo de Y»). El estándar del sistema de vistas antes de Compose.
RecyclerView
Lista eficiente del sistema clásico: recicla las filas que salen de pantalla para reutilizarlas. Requería adaptadores y titulares escritos a mano. Sus sucesores naturales son las listas perezosas de Compose.
dp · píxel independiente de densidad
Unidad virtual para tamaños y espaciados: 160 dp equivalen a una pulgada física cualquiera sea la pantalla. Nunca uses píxeles crudos: en pantallas de alta densidad tus elementos quedarían diminutos.
sp · píxel escalable
Igual que dp pero pensado solo para texto: además de la densidad respeta el tamaño de letra que el usuario eligió en ajustes. Usarlo es respetar la accesibilidad.
Material Design
Sistema de diseño de Google: colores, tipografías, formas, sombras y patrones de
interacción. Su versión actual es Material 3 (o «Material You»), que Compose implementa
mediante MaterialTheme.
Jetpack Compose
17 términos El paradigma declarativoEl vocabulario nuevo que trae Compose. Dominar estos términos equivale a entender el 80 % de la documentación moderna.
Jetpack
Colección oficial de bibliotecas de Google para Android que resuelven problemas comunes con buenas prácticas incluidas: navegación, bases de datos, permisos, inyección de dependencias… Compose es su joya más visible.
Jetpack Compose
Kit para construir interfaces de forma declarativa: describes cómo se ve la pantalla según los datos actuales y el sistema se encarga de actualizarla. Todo es Kotlin; adiós a los XML de disposiciones.
@Composable · función componible
Función Kotlin anotada que describe una parte de la interfaz. Puede recibir datos y
otras funciones componibles como parámetros. Es el ladrillo fundamental:
Text("Hola"), Button(onClick = {...}) { ... }.
Composición
El árbol de interfaz que Compose construye al ejecutar tus funciones componibles por primera vez. Piensa en ella como la «fotografía» actual de tu pantalla derivada de tus datos.
Recomposición
Volver a ejecutar las funciones componibles cuyo estado cambió, para repintar solo lo necesario. Es inteligente y parcial: no redibuja toda la pantalla. Por eso las funciones componibles deben ser rápidas y sin efectos colaterales.
Estado / mutableStateOf
Valor que Compose «vigila»: cuando cambia, dispara recomposición de quien lo lee.
Se crea con mutableStateOf(valor). El equivalente declarativo de «redibujar
cuando cambie algo».
remember
Guarda un valor durante las recomposiciones para que no se reinicie en cada pasada. Sin él, una variable local se recrearía desde cero cada vez que la pantalla se vuelva a dibujar.
rememberSaveable
Como remember, pero además sobrevive a cambios de configuración
(girar la pantalla) e incluso a que el sistema recupere memoria matando el proceso.
Tu aliado para estados pequeños de interfaz.
Elevación de estado · state hoisting
Mover el estado de un componente hacia su llamador para dejarlo «sin memoria».
Patrón estándar: el componible recibe el valor y una función para cambiarlo
(valor: T, onCambiar: (T) -> Unit). Facilita reutilizar y probar.
Flujo unidireccional · UDF
Principio arquitectónico: el estado baja (del modelo hacia la interfaz) y los eventos suben (de la interfaz hacia el modelo). Un solo sentido de circulación = menos errores imposibles de rastrear.
Efectos secundarios · LaunchedEffect, DisposableEffect
Acciones fuera del mundo puro: llamar a la red, iniciar una corrutina, registrarse en
un sensor. Compose ofrece APIs seguras para ejecutarlas: LaunchedEffect(clave)
lanza corrutinas atadas a la composición y DisposableEffect permite limpiar
registros al salir.
Modifier
Cadena de ajustes que decora o configura un elemento: tamaño, relleno, fondo,
clics…Modifier.fillMaxWidth().padding(16.dp).clickable { }.
El orden importa: cada modificador envuelve al anterior.
MaterialTheme / Material 3
Tema global que provee colores, tipografías y formas coherentes en toda la app.
Definiéndolo una vez, componentes como Card o Button adoptan
automáticamente el estilo —incluido el modo oscuro—.
@Preview
Anotación que muestra tu componible directamente en Android Studio sin instalar la app, con varios tamaños y temas a la vez. Acelera muchísimo el diseño.
Listas perezosas · LazyColumn, LazyRow, LazyVerticalGrid
Contenedores que componen únicamente los elementos visibles, cargando bajo demanda al desplazarse. Manejan miles de elementos sin esfuerzo. Son el reemplazo directo de RecyclerView.
Estabilidad · @Stable, @Immutable
El compilador puede omitir recomposiciones si sabe que los parámetros no cambiaron; eso requiere tipos «estables». Las clases de datos inmutables ya lo son; las listas mutables no. Estas anotaciones le aseguran al compilador que puede confiar.
derivedStateOf / key
Herramientas de rendimiento fino: derivedStateOf calcula un valor derivado
que solo avisa cuando realmente cambia (evita recomposiciones innecesarias) y
key(...) ayuda al sistema a identificar elementos entre recomposiciones,
vital dentro de bucles de listas animadas.
Ciclo de vida
11 términos Nacer, vivir, morirEn móvil el sistema decide cuándo tu pantalla aparece, se oculta o desaparece. Estos términos describen ese baile.
onCreate()
Primer latido de una Activity: aquí se infla la interfaz y se prepara todo. Recibe el paquete guardado por si la app está volviendo tras un cierre del sistema.
onStart() / onResume()
La pantalla se vuelve visible y luego recibe el foco para interactuar.
En onResume arranca lo que necesita primer plano: cámara activa,
actualizaciones de ubicación.
onPause() / onStop()
Se pierde el foco y luego la visibilidad (llegó otra app o llamada). Momentos para pausar animaciones y liberar recursos costosos.
onDestroy()
Última llamada antes de que la Activity sea destruida, por decisión del usuario (botón atrás) o del sistema (recuperación de memoria).
onSaveInstanceState()
Instante donde puedes guardar datos pequeños (identificador seleccionado, texto de un
campo) en un Bundle antes de que la pantalla muera. Compose lo automatiza con
rememberSaveable.
Cambio de configuración
Girar la pantalla, cambiar idioma o plegar un plegable: el sistema destruye y recrea la Activity. Todo estado no protegido se pierde. Es LA diferencia con escritorio que más sorprende al empezar.
Muerte del proceso
Con la app en segundo plano, Android puede matarla silenciosamente si falta memoria. Al volver, se recrea desde cero pero restaurando los paquetes guardados. Tu app debe saber renacer con gracia.
LifecycleOwner
Cualquier componente con ciclo observable (Activity, Fragment). Permite que otros (bibliotecas, tus observadores) reaccionen automáticamente a sus estados sin escribir condicionales a mano.
ViewModel
Guardián de datos y lógica de pantalla: sobrevive a los cambios de configuración mientras exista la pantalla. La UI le pregunta «¿qué muestro?» y él responde. Nunca guarda referencias a vistas dentro de él.
viewModelScope
Ambito de corrutinas incluido en cada ViewModel: todo lo lanzado ahí se cancela automáticamente cuando la pantalla muere definitivamente. Evita fugas de memoria.
Recolección consciente del ciclo · repeatOnLifecycle
Patrón seguro para observar flujos desde la interfaz: recolectar solo mientras la pantalla está VISIBLE y cancelar al ocultarse. Evita actualizar pantallas muertas y desperdiciar batería.
Datos y arquitectura
16 términos Del servidor al discoMVVM · Modelo-Vista-ModeloVista
Arquitectura estándar de Android: la Vista (Compose) dibuja; el ViewModel expone estado y procesa eventos; el Modelo son los datos (repositorios, red, base de datos). Separación clara de responsabilidades.
Repositorio
Clase única que decide de dónde vienen los datos: ¿del servidor o de la base local? La interfaz nunca lo sabe. Punto único de verdad de la información.
Caso de uso · UseCase / Interactor
Clase pequeña con UNA regla de negocio («registrar pedido», «calcular envío»). Opcional pero útil cuando la lógica se comparte entre pantallas o crece.
Arquitectura limpia
Ideal de organización en tres anillos: datos (fuentes externas), dominio (negocio puro) y presentación (UI). Las dependencias apuntan siempre hacia adentro: la lógica no conoce detalles de red ni de pantalla.
DTO · objeto de transferencia de datos
Clase que refleja exactamente el JSON que llega del servidor. Se convierte a un modelo interno antes de usarlo: así un cambio en el API no rompe tu aplicación.
Entidad / DAO
Dúo de Room: la entidad es una tabla declarada con anotaciones sobre una clase de datos; el DAO es la interfaz con las consultas. Escribes Kotlin, Room genera el SQL por ti.
Room
Biblioteca oficial sobre SQLite: valida consultas en compilación, devuelve Flows observables y maneja migraciones. La forma moderna de persistencia estructurada local.
Retrofit
Cliente HTTP declarativo: describes el API como una interfaz Kotlin con anotaciones
(@GET("usuarios")) y él genera las llamadas. Estándar absoluto para consumir
servicios web.
OkHttp
Motor HTTP debajo de Retrofit: gestiona conexiones, reintentos e interceptores (añadir token de sesión a cada petición, registrar tráfico).
kotlinx.serialization / Moshi
Bibliotecas que convierten JSON ↔ objetos Kotlin automáticamente. La primera es multiplataforma y se integra muy bien con Retrofit.
DataStore
Sucesor moderno de las preferencias compartidas: guarda pares clave-valor (u objetos completos) de forma asíncrona mediante Flows, sin bloquear la interfaz. Ideal para sesiones y ajustes.
SharedPreferences · legado
Sistema antiguo de preferencias, síncrono y propenso a bloqueos. Aún presente en proyectos veteranos; para código nuevo usa DataStore.
Coil
Cargador de imágenes remotas pensado para Compose y corrutinas: descarga, cachea y
muestra imágenes con una sola línea
(AsyncImage(modelo = url)). Su antecesor era Glide.
Inyección de dependencias
Técnica de entregar las colaboraciones de una clase desde fuera (por constructor) en lugar de crearlas dentro. Facilita pruebas: inyectas un repositorio falso en tests.
Hilt
Inyección de dependencias oficial de Google para Android, construida sobre Dagger.
Con anotaciones (@HiltViewModel, @Inject) conecta ViewModels,
repositorios y bases de datos sin fábricas manuales.
KSP / kapt
Procesadores que generan código en compilación a partir de anotaciones (Room e Hilt los usan). KSP es la generación moderna y rápida; kapt la veterana basada en Java.
Concurrencia
8 términos Varias cosas a la vezYa viste corrutinas en el manual del lenguaje; aquí su aplicación concreta en Android.
Corrutina
Tarea ligera que puede suspenderse sin bloquear el hilo. Miles caben en uno solo. La base de toda operación asíncrona moderna en Android: red, disco, demoras.
suspend
Marca una función que puede pausarse y reanudarse sin congelar la interfaz. El compilador obliga a llamarla desde otra función suspendida o dentro de un ámbito de corrutinas — imposible olvidar que algo es lento.
Job
Manija de una corrutina: permite cancelarla o esperarla. Los trabajos forman árboles padre-hijo: cancelar al padre cancela a todos los hijos.
Dispatchers · despachadores
Deciden en qué hilos corre cada tarea: Main (interfaz),
IO (red/disco) y Default (cálculo intensivo).
Cambiar entre ellos es una línea: withContext(Dispatchers.IO){ }.
Flow
Serie de valores que llegan con el tiempo, asíncrona y «fría» (no arranca hasta que alguien la recolecta). Ideal para respuestas paginadas, sensores o consultas vivas de Room.
StateFlow
Flujo que siempre tiene un valor actual y avisa cuando este cambia. El canal estándar para exponer el estado de pantalla desde un ViewModel hacia Compose.
SharedFlow
Flujo de eventos sin valor inicial ni repetición garantizada: avisos puntuales como mostrar un mensaje emergente o navegar tras guardar. Complementa a StateFlow.
Estructuración de concurrencia · structured concurrency
Regla de oro: toda corrutina nace dentro de un ámbito con dueño y muere con él.
En Android esto significa cero fugas: si la pantalla muere,
viewModelScope cancela todo lo pendiente.
Permisos y hardware
8 términos Pedir antes de usarPermiso en tiempo de ejecución
Mecanismo donde el usuario concede permisos sensibles MIENTRAS usa la app, no al instalarla. Se pregunta con lanzadores de resultados y puede denegarse para siempre: tu interfaz debe sobrevivir a un «no».
Permisos normales vs peligrosos
Los normales (internet) se conceden solos al instalar; los peligrosos (cámara, ubicación fina, micrófono, contactos) exigen diálogo explícito. Cada uno sensible tiene además un interruptor en ajustes que el usuario puede apagar en cualquier momento.
CameraX
Biblioteca oficial para cámara que abstrae las diferencias entre fabricantes: vista previa, captura de foto, análisis de fotogramas y grabación, todo con casos de uso listos para atar al ciclo de vida.
FusedLocationProviderClient
Proveedor fusionado de ubicación de los servicios de Google Play: combina satélite, redes Wi-Fi y antenas para dar posición precisa gastando lo mínimo. La API estándar para GPS.
Sensores
Acelerómetro, giroscopio, brújula, luz ambiental… accesibles vía
SensorManager con registro y liberación conscientes del ciclo de vida.
Base de apps de movimiento, realidad aumentada y utilerías.
Almacenamiento con alcance · scoped storage
Filosofía moderna de archivos: cada app ve SU carpeta privada sin permisos; lo demás pasa por mediadores (selector de archivos, proveedor de multimedia). Adiós a leer todo el disco libremente como hace décadas.
Permiso de notificaciones
Desde Android 13 mostrar notificaciones requiere consentimiento explícito. Buenas prácticas: pedirlo en contexto («quiero avisarte cuando llegue tu pedido») y degradar con elegancia si se niega.
Navegación por gestos
Navegación moderna con deslizamientos desde bordes en lugar de botones. Implica respetar los márgenes del sistema (no poner botones donde vive el gesto) y soportar el gesto atrás en tus pantallas.
Sistema operativo
8 términos Bajo el capóContext · contexto
Llave de acceso al entorno del sistema: recursos, archivos, servicios, lanzar actividades. Hay dos sabores: de aplicación (vive siempre) y de actividad/pantalla (muere con ella — nunca guardes este último en objetos longevos).
AndroidManifest.xml
Cédula de identidad de tu app: componentes existentes, permisos requeridos, hardware necesario, icono y nombre. El sistema la lee ANTES de ejecutar nada.
Recursos (res/) y clase R
Carpeta con todo lo no-código: textos traducidos (values/strings.xml),
imágenes (drawable), colores, temas. La clase generada R
les da identificadores seguros en compilación.
Toast / Snackbar
Mensajes efímeros: el toast flota sobre todo sin interacción; la barra emergente aparece anclada a la pantalla y admite una acción («deshacer»). Para errores serios prefiere estados en pantalla, no avisos volátiles.
Proceso e hilo principal
Cada app corre en su propio proceso Linux aislado. Dentro, el hilo principal dibuja y atiende toques: bloquearlo más de ~5 segundos dispara el temido «ANR» (aplicación no responde). Todo trabajo pesado va a corrutinas.
ART · tiempo de ejecución de Android
Máquina que ejecuta tus aplicaciones: compila el bytecode a código nativo durante la instalación y el uso (compilación anticipada y guiada por perfiles). Es quien recibe el resultado de kotlinc/Gradle.
Administrador de memoria baja · LMK
Juez silencioso que mata procesos cuando falta RAM, priorizando mantener visible lo que el usuario está mirando. Por eso el estado importante debe persistirse, no vivir solo en variables.
Modo oscuro y densidades
El sistema adapta colores automáticamente si usas los tokens del tema (Compose + Material 3 lo hacen gratis) y sirve imágenes distintas por densidad de pantalla. Probar tu app en ambos modos es obligación, no lujo.