Android Studio: guía completa para dominar el desarrollo de apps

Inicio >> Guías y Tutoriales >> Android Studio: guía completa para dominar el desarrollo de apps

Si estás buscando una guía completa de Android Studio para desarrollo y no quieres perderte entre ventanas, menús raros y errores de compilación, quédate por aquí. Vamos a recorrer todo el ecosistema de Android Studio, desde la instalación y la estructura de un proyecto básico hasta temas más avanzados como Gradle, depuración, perfiles de rendimiento, apps empresariales, perfiles de trabajo y hasta cómo usar adb y control de versiones.

No hace falta que seas un experto para empezar, pero sí te vendrá bien tener ganas de cacharrear, algo de base en programación (idealmente en Kotlin o Java) y un ordenador decente. A partir de ahí, usaremos Android Studio como punto de entrada para crear tu primera app, entender cómo se compilan y prueban, y cómo puedes llevarlas a un entorno profesional, tanto de consumo como empresarial.

Qué es Android Studio y por qué es el IDE clave para Android

Android Studio es el entorno de desarrollo integrado oficial de Google para crear aplicaciones Android. Está basado en IntelliJ IDEA, lo que significa que hereda un editor muy potente y un montón de herramientas avanzadas, pero adaptadas a las necesidades específicas del desarrollo móvil.

Entre las funciones estrella de Android Studio encuentras un sistema de compilación flexible basado en Gradle, emuladores rápidos con muchas opciones, un entorno unificado para desarrollar para móviles, tablets, TV, Wear y demás, ediciones en vivo para Jetpack Compose, integración con GitHub, herramientas de testing y de análisis de rendimiento, además de soporte para C++ y NDK.

Este IDE está pensado para acompañarte en todo el ciclo de vida de la app: diseño de la interfaz, escritura de código, gestión de dependencias, ejecución en emulador o dispositivo físico, depuración, optimización y generación del APK o App Bundle para subirlo a Google Play.

Requisitos y preparación antes de instalar Android Studio

Antes de descargar Android Studio conviene comprobar que tu equipo aguanta el tirón. Aunque el IDE funciona en máquinas modestas, si vas justo de recursos vas a notar lentitud, sobre todo al usar el emulador.

Requisitos recomendados para trabajar con comodidad suelen ser sistema operativo moderno (Windows 10 o superior, macOS 10.14+ o una distro Linux reciente), al menos 8 GB de RAM (16 GB muy recomendable), unos cuantos gigas de disco libre para SDKs, emuladores y proyectos, y un procesador multicore tipo Intel i5 o Ryzen 5 en adelante.

También necesitarás conexión a internet para descargar el propio Android Studio, los componentes del Android SDK, imágenes de sistema para emuladores, librerías de soporte y futuras actualizaciones del IDE y del plugin de Android para Gradle.

Instalación y primer arranque de Android Studio

La instalación de Android Studio está guiada paso a paso. Descargas el instalador desde la web oficial, lo ejecutas y sigues el asistente. Por defecto, se instalan el IDE, el SDK de Android, el emulador (Android Virtual Device Manager) y las herramientas de línea de comandos básicas.

En el primer arranque, Android Studio te pedirá configurar algunos detalles: tipo de tema (claro u oscuro), ubicación del SDK y selección de componentes. Lo normal es dejarlo tal cual viene salvo que tengas necesidades especiales. El asistente también se encarga de descargar las imágenes de sistema necesarias para los emuladores básicos.

Con el IDE ya operativo, es buena idea revisar si hay actualizaciones tanto del propio Android Studio como del plugin de Android y del SDK. Esto te evita encontrarte ejemplos de documentación que no compilan por usar versiones más nuevas de dependencias o herramientas.

Crear tu primer proyecto y entender su estructura

La forma más rápida de empezar es crear un proyecto usando una plantilla. Desde la pantalla de bienvenida, eliges “New Project” y verás distintas plantillas (Empty Activity, Activity con Compose, Navigation Drawer, etc.). Para comenzar, suele recomendarse “Empty Activity” o una plantilla Compose sencilla.

En el asistente de creación de proyecto configuras varios campos clave: nombre de la app, nombre del paquete (identificador único del proyecto, algo tipo com.ejemplo.miapp), ubicación en disco, lenguaje (Kotlin recomendado, Java sigue siendo posible) y versión mínima de Android (Minimum SDK) sobre la que tu app podrá ejecutarse.

El Minimum SDK determina qué porcentaje de dispositivos puede instalar tu app. Un nivel como API 24 (Android 7) o superior es una buena referencia actual, aunque puedes ajustarlo en función del público objetivo. Android Studio te muestra estadísticas de adopción para ayudarte a decidir.

Una vez creado el proyecto, en la vista “Android” verás una estructura simplificada organizada por módulos. El módulo principal de app incluye tres carpetas importantes: manifests (con el archivo AndroidManifest.xml), java (o kotlin en algunos casos) donde residen tus clases y tests, y res, con todos los recursos sin código (layouts, imágenes, cadenas de texto, estilos, etc.).

Si cambias la vista del panel de proyecto a “Project” o “Project Source Files” verás la estructura real en el sistema de archivos, con más nivel de detalle. A efectos de trabajo diario, la vista “Android” suele ser la más cómoda, pero conviene saber que ambas representan lo mismo.

Sistema de compilación con Gradle: corazón del build

Android Studio se apoya en Gradle como sistema de compilación, usando el plugin de Android para Gradle para todo lo específico de apps móviles. Gradle se encarga de compilar el código, empaquetar recursos, gestionar dependencias y generar los artefactos finales (APK o AAB).

En cada proyecto encontrarás varios archivos de configuración Gradle: uno a nivel de proyecto y, al menos, uno a nivel de módulo (por ejemplo, el de la app). Suelen llamarse build.gradle.kts si usas DSL de Kotlin o build.gradle si se usa Groovy, pero conceptualmente hacen lo mismo.

Desde estos scripts puedes personalizar casi todo el proceso de compilación: definir variantes de build (debug, release, free, pro…), activar ofuscación y minificación, configurar empaquetado de recursos, establecer opciones de compilador, e incluso automatizar tareas personalizadas.

Android Studio utiliza por defecto Maven Central como repositorio de dependencias, de modo que con una simple línea implementation puedes incorporar librerías de terceros. En proyectos más avanzados puedes añadir repositorios adicionales o módulos propios para reutilizar código entre apps.

Variantes de compilación, múltiples APKs y reducción de recursos

Gradle te permite crear distintas “versiones” de la misma app desde un único proyecto. Combinando tipos de build (build types) y “product flavors” puedes tener, por ejemplo, una versión gratuita con anuncios y otra de pago sin publicidad, ambas compartiendo gran parte del código.

La compatibilidad con múltiples APKs facilita segmentar la distribución por densidad de pantalla o por ABI (arquitectura de CPU). Así puedes generar APKs específicos para hdpi y mdpi o para ARM y x86, optimizando tamaño y rendimiento, pero gestionándolos como una sola variante lógica en tu proyecto.

Otra pieza clave es la reducción de recursos (“resource shrinking”), que elimina de tu APK final todos aquellos recursos no utilizados, tanto de tu proyecto como de librerías dependientes. Trabaja en conjunto con herramientas de reducción de código como ProGuard o R8 para recortar al máximo el tamaño de la app.

Bien configurado, el sistema de build te ahorra mucho peso innecesario y te permite mantener un único código fuente para multitud de escenarios: pruebas internas, producción, demo para clientes, builds para diferentes mercados o partners, etc.

Gestión de dependencias en Android Studio

Las dependencias se declaran en el script de Gradle del módulo correspondiente. Allí puedes mezclar referencias a módulos internos del proyecto, dependencias binarias remotas (Maven) y bibliotecas locales (JAR/AAR) si las necesitas.

En la sección dependencies de tu build.gradle(.kts) es donde añades líneas tipo implementation "com.developer.package:name:version". Tras modificar este archivo, Android Studio te pedirá sincronizar el proyecto con Gradle para aplicar los cambios y descargar lo que falte.

Algunas librerías exigen ajustes adicionales en otros archivos Gradle (por ejemplo, repositorios, plugins especiales o configuración del namespace). Por eso es fundamental leer la documentación de instalación de cada dependencia, especialmente en librerías grandes como Firebase o soluciones de autenticación.

Interfaz de Android Studio y creación de código e interfaces

Android Studio organiza su interfaz en varias zonas bien diferenciadas: el panel de proyecto a la izquierda, el editor central (código y diseño), y diversas ventanas de herramientas (Logcat, Profiler, Build, Device Manager) que se muestran en pestañas acoplables.

El editor de código ofrece autocompletado inteligente, resaltado de errores en tiempo real, sugerencias rápidas para correcciones, refactorizaciones automáticas y navegación avanzada (ir a declaración, encontrar usos, etc.). Soporta Kotlin, Java y también C++ en caso de usar NDK.

Para el diseño de la interfaz tienes varias opciones: el Layout Editor visual para XML clásico, donde puedes arrastrar y soltar componentes, o la vista de código puro. Con Jetpack Compose, el diseño se hace directamente en código Kotlin usando funciones anotadas con @Composable.

En proyectos con Compose, la función setContent{} dentro de onCreate() se encarga de describir la UI mediante funciones componibles. Estas funciones pueden previsualizarse directamente en el IDE usando anotaciones @Preview, lo que te permite ver cambios al vuelo sin ejecutar la app entera.

Creación de tu primera pantalla con Jetpack Compose

Cuando eliges una plantilla de proyecto basada en Compose, Android Studio genera por ti una actividad principal con una función onCreate() que llama a setContent{} y un tema ya configurado. Dentro del contenido, se suele incluir una función composable de ejemplo que muestra un texto tipo “Hello Android!”.

Una función composable se identifica por la anotación @Composable y su nombre en mayúscula inicial. No devuelve vistas tradicionales, sino que describe la UI declarativamente. Por ejemplo, una función Greeting(name: String) puede mostrar un Text con un saludo personalizado.

Para ver rápidamente el aspecto de una función composable sin lanzar la app, se define otra función con anotaciones @Composable y @Preview. Configurando parámetros como showBackground = true, podrás ver en el panel de vista previa cómo queda el composable con un fondo que lo diferencie del editor.

También puedes enriquecer tu composable con contenedores y modificadores. Por ejemplo, envolver el texto en una Surface para cambiar el color de fondo, o encadenar métodos de Modifier como padding(24.dp) para añadir espacio alrededor del contenido.

Revisión de código, imports y organización

Compose y el resto de APIs de Android requieren varias sentencias de importación. Android Studio ayuda a añadirlas automáticamente, pero también puedes gestionarlas desde el menú Code > Optimize Imports para mantenerlas ordenadas y limpiar las que ya no se usan.

Es recomendable revisar de vez en cuando la cabecera de tus archivos Kotlin para asegurarte de que solo importas lo necesario y de que usas las variantes correctas (por ejemplo, androidx.compose.ui.graphics.Color o androidx.compose.ui.unit.dp). Esto reduce ambigüedades y pequeños errores de compilación.

Una vez configurada la UI básica y el código asociado, puedes lanzar la app en un emulador o dispositivo real desde el botón de “Run” del IDE, eligiendo el dispositivo en el desplegable. Si algo falla en tiempo de ejecución, Logcat será tu mejor aliado para ver excepciones y trazas.

Depuración y herramientas de análisis de rendimiento

Android Studio incluye un depurador integrado muy completo. Puedes establecer puntos de ruptura (breakpoints), inspeccionar variables, evaluar expresiones y seguir paso a paso la ejecución del código. Además, dispone de una opción para mostrar valores directamente en el editor mientras depuras.

Las llamadas “inspecciones integradas” permiten ver más contexto al depurar: referencias a objetos, valores de retorno de métodos, lambdas evaluadas, etc. Activando “Show Variable Values in Editor” puedes hacer que la depuración sea mucho más visual.

Para el rendimiento, el panel de Android Profiler te da métricas detalladas de uso de CPU, memoria, red y gráficos. Desde ahí puedes detectar cuellos de botella, identificar objetos que no se liberan, fugas de memoria y problemas de consumo excesivo.

Cuando investigas bugs de memoria, puedes generar volcados de montón (heap dumps) en formato HPROF específico de Android. El visor integrado te muestra clases, instancias y árboles de referencia para comprender qué está reteniendo memoria y por qué.

Lint, anotaciones y calidad del código

Cada vez que compilas, Android Studio ejecuta automáticamente comprobaciones de lint y otras inspecciones del IDE. Su objetivo es alertarte de posibles errores de precisión, seguridad, rendimiento, accesibilidad, internacionalización y mucho más.

La herramienta lint revisa tus archivos fuente en busca de patrones problemáticos: recursos no usados, layouts ineficientes, posibles fugas, cadenas sin traducir, permisos mal declarados, etc. Los resultados se muestran en una ventana específica con detalles y sugerencias de solución.

Además, Android Studio soporta ampliamente anotaciones de Jetpack y del propio SDK de Android (por ejemplo, anotaciones de nulabilidad, tipos de recursos o restricciones de hilo). El IDE valida estas anotaciones para avisarte cuando las incumples, evitando errores típicos como null pointer o mal uso de recursos.

Los mensajes de Logcat completan el arsenal de diagnóstico permitiéndote imprimir logs con distintos niveles (verbose, debug, info, warning, error) y filtrar por etiqueta o proceso. Es una herramienta esencial para diagnosticar lo que ocurre en ejecución, especialmente en dispositivos físicos.

Acceso a tu cuenta de desarrollador y funciones conectadas

Desde Android Studio puedes iniciar sesión con tu cuenta de desarrollador de Google para acceder a herramientas que requieren autenticación, como integración con Firebase, Android Vitals dentro de App Quality Insights o Gemini integrado en el IDE.

El acceso se gestiona desde el icono de perfil en la barra de herramientas. Una vez te autenticas, puedes revisar y ajustar los permisos otorgados a través del menú de configuración: en Windows y Linux desde File > Settings > Tools > Google Accounts, y en macOS desde Android Studio > Settings.

Android Studio en entornos empresariales: perfiles de trabajo y dispositivos dedicados

Android para empresas introduce conceptos como perfiles de trabajo y dispositivos de uso específico, que puedes soportar desde tus apps desarrolladas en Android Studio con unas cuantas consideraciones adicionales.

Un perfil de trabajo es un contenedor aislado dentro del dispositivo del usuario donde se instalan las apps y datos corporativos, separados de las aplicaciones y datos personales. Esta separación permite a TI gestionar solo lo empresarial sin invadir el ámbito privado.

En dispositivos con Android 5.0 y posteriores, los perfiles de trabajo ofrecen ventajas importantes: cifrado completo, un único APK para ambos perfiles, un controlador de políticas (DPC) limitado al perfil de trabajo y APIs específicas como DevicePolicyManager para gestionar políticas.

Al desarrollar apps que interactúan con distintos perfiles, debes vigilar los intents que cruzan límites de perfil. Antes de lanzar una actividad con un intent, comprueba que se resuelve correctamente con Intent.resolveActivity(). Si devuelve null, esa acción no será posible en ese contexto y deberías manejarlo adecuadamente.

Intercambio de archivos entre perfiles y buenas prácticas de URI

En dispositivos con perfil de trabajo existen sistemas de archivos separados, por lo que usar URIs de archivo (file://) para compartir datos entre perfiles no funciona. Esa ruta solo tiene sentido en el perfil donde se creó, y fallará al intentar accederla desde otro perfil.

La recomendación es usar URIs de contenido (content://) como mecanismo estándar. Estos URIs incluyen autoridad, ruta y un ID de archivo, y puedes generarlos mediante FileProvider. Compartes el URI vía intent y concedes permisos de acceso temporal.

Si usas Context.grantUriPermission() para otorgar acceso, recuerda que solo se aplica a la app destino dentro del mismo perfil. La transferencia de permisos entre perfiles solo se produce si el sistema lo permite mediante intents y reglas de seguridad específicas.

Una vez adaptada tu app a perfiles de trabajo, es vital probarla en ese entorno. Es decir, no basta con que funcione en un dispositivo “normal”; hay que verificar el comportamiento cuando está instalada dentro de un perfil de trabajo gestionado.

Configuraciones administradas y apps corporativas

Las configuraciones administradas permiten a los administradores de TI controlar el comportamiento de tus apps sin intervención manual del usuario, a través de soluciones EMM (Enterprise Mobility Management). Son definiciones estandarizadas que cualquier EMM puede aplicar.

Con estas configuraciones se pueden fijar políticas muy variadas: limitar el uso de datos móviles a favor de Wi‑Fi, definir listas blancas o negras de URLs en un navegador, preconfigurar cuentas de correo, activar o desactivar funciones como impresión o gestión de favoritos, etc.

Al arrancar tu app por primera vez puedes consultar getApplicationRestrictions() en onStart() u onResume() para saber si existen restricciones aplicadas. Este método puede devolverte un conjunto de restricciones completas, un paquete vacío (app no gestionada) o un paquete con la clave KEY_RESTRICTIONS_PENDING indicando que la app está gestionada pero el DPC aún no terminó de configurarla.

Es importante también reaccionar a cambios en las configuraciones administradas. Para ello, tu app debe volver a leer las restricciones en cada inicio y además registrar dinámicamente un receptor para la acción ACTION_APPLICATION_RESTRICTIONS_CHANGED mientras está en ejecución, anulando su registro en onPause().

Dispositivos de uso específico (dispositivos dedicados)

Los dispositivos dedicados se usan como kioscos, terminales de punto de venta, paneles de señalización digital o cualquier caso de uso en el que el dispositivo esté bloqueado a una sola app o a un conjunto muy limitado de aplicaciones.

Cuando un dispositivo se aprovisiona como dedicado, el usuario ve solo la app o conjunto de apps autorizadas, sin acceso a launcher estándar ni conmutador de apps recientes para salir de allí. Esto requiere un perfil de gestión adecuado y políticas de dispositivo específicas.

Desde el punto de vista del desarrollador, conviene conocer las guías de “dispositivo exclusivo” de Android para asegurarte de que tu aplicación se comporta correctamente en este modo, respetando bloqueos de pantalla, reinicios, actualizaciones y políticas de red.

Inicio de sesión único con pestañas personalizadas de Chrome

En entornos empresariales es muy habitual que el usuario necesite autenticarse en varias apps corporativas. Hacerlo con WebView puede obligar a iniciar sesión varias veces y además exponer riesgos de seguridad si el contenido web puede ser inspeccionado o si se mezclan SDKs de terceros poco confiables.

La alternativa recomendada es usar pestañas personalizadas de Chrome (Custom Tabs) para el flujo de autenticación. De esta forma, el login se realiza en el navegador del sistema, con un contexto aislado de la app anfitriona y compartiendo cookies entre aplicaciones que usen el mismo dominio.

Esto ofrece dos ventajas claras: se reduce el número de veces que el usuario tiene que introducir credenciales (SSO real) y se mejora la seguridad al no exponer cookies o formularios a la app o a librerías de terceros.

Google mantiene una librería cliente de OAuth de código abierto llamada AppAuth que utiliza pestañas personalizadas y se alinea con los estándares de OpenID Connect. En su repositorio de GitHub encontrarás ejemplos y documentación para integrarla en tus apps Android.

Pruebas: perfiles de trabajo, dispositivos administrados y entorno EMM

Después de desarrollar tu app, es crucial probarla en escenarios lo más realistas posible. Si trabaja con perfiles de trabajo o dispositivos gestionados, debes validar específicamente esos casos.

Google ofrece una app llamada Test DPC para simular políticas de EMM en un entorno de pruebas. Con ella puedes configurar restricciones, parámetros de configuración administrada y políticas de dispositivo como si fueras un administrador de TI.

Para probar en un perfil de trabajo, primero aprovisionas ese perfil con Test DPC, siguiendo el asistente en el dispositivo. Después instalas tu app y verificas cómo se comporta dentro del perfil de trabajo, usando la copia de Test DPC con insignia corporativa para aplicar políticas.

Si quieres probar en un dispositivo completamente administrado, debes asegurarte de que no haya otros usuarios o perfiles en el dispositivo, ni cuentas configuradas, e indicar mediante un comando adb que Test DPC será el “device owner”. A partir de ahí, podrás comprobar cómo responde tu app en un entorno totalmente gestionado.

Finalmente, para pruebas de extremo a extremo en producción, lo ideal es contar con acceso a una consola EMM real, publicar una versión de prueba de tu app en un canal privado de Google Play vinculado a un dominio de prueba y recorrer todo el flujo: enrolar dispositivos, distribuir la app, aplicar configuraciones administradas y políticas de dispositivo.

Herramientas adicionales: Gradle en profundidad, adb y control de versiones

Más allá del uso básico de Gradle, Android Studio te permite reconstruir y limpiar el proyecto con facilidad desde el menú Build. “Clean Project” elimina artefactos compilados antiguos y “Rebuild Project” fuerza una compilación desde cero, útil cuando aparecen errores extraños tras refactorizaciones o cambios de configuración.

Si persisten problemas raros, existe la opción de “Invalidate Caches / Restart” en el menú File. Esta función borra cachés internos de Android Studio y reinicia el IDE, solucionando muchas veces inconsistencias internas que no se arreglan solo con limpiar y recompilar.

El Android Debug Bridge (adb) es otra herramienta clave del ecosistema. Viene incluida en las platform-tools del SDK y permite comunicarse con dispositivos y emuladores desde la línea de comandos para listar dispositivos, instalar paquetes, ver logs, hacer “pull” y “push” de archivos, configurar conexiones inalámbricas, etc.

Para trabajar cómodo con adb conviene añadir la carpeta platform-tools al PATH del sistema, de manera que puedas ejecutar comandos como adb devices o adb connect desde cualquier directorio. Esto facilita, por ejemplo, conectar de forma inalámbrica a un Control Hub o a un teléfono configurado como controlador de robot.

Android Studio también integra herramientas de control de versiones, con soporte nativo para Git. Puedes inicializar repositorios, hacer commits, crear ramas, resolver conflictos y sincronizar con plataformas como GitHub directamente desde el IDE, lo que resulta especialmente útil para equipos de desarrollo y gestión de historiales de cambios.

Con todo lo que ofrece Android Studio —desde la creación de interfaces con Compose hasta el soporte para entornos empresariales complejos, pasando por Gradle, depuración avanzada, adb y control de versiones— dispones de un entorno completo para llevar una simple idea de app a un producto robusto listo para producción, ya sea orientado al usuario final o a organizaciones con altos requisitos de seguridad y gestión.