El desarrollo de aplicaciones Android ya no consiste solo en crear pantallas y subir un paquete. Una aplicación sostenible debe funcionar en teléfonos, tabletas, plegables, ChromeOS, automóviles, Wear OS y frente a requisitos de plataforma que cambian con el tiempo. Las reglas de API objetivo de Google Play, los cambios de comportamiento de Android 16 y la compatibilidad con páginas de 16 KB pueden generar retrabajo si se dejan para la semana de publicación.
Este artículo organiza las comprobaciones prácticas que conviene abordar al iniciar una nueva aplicación Android o al modernizar una existente. La pregunta no es solo si usar Kotlin o Jetpack Compose, sino si la calidad, la accesibilidad, la preparación para la tienda y el mantenimiento forman parte del mismo plan de desarrollo.
Puntos clave
- Kotlin y Jetpack Compose son opciones sólidas para el desarrollo Android moderno, pero la arquitectura, la propiedad del estado, las revisiones y las pruebas determinan la calidad.
- La preparación para Android 16 debe incluir revisión de cambios de comportamiento, configuración del SDK y pruebas en dispositivos reales o emuladores.
- Publicar en Google Play requiere planificar nivel de API objetivo, permisos, privacidad, presentación en la tienda y despliegue gradual.
- Las aplicaciones con código nativo o SDKs con bibliotecas nativas deben verificar pronto la compatibilidad con páginas de 16 KB.
- El mantenimiento por actualizaciones de OS, cambios de SDK, corrección de fallos y soporte debe formar parte del alcance del proyecto.
Empiece por la calidad, no solo por las funciones
Los proyectos Android rara vez fallan por una sola elección de framework. Fallan cuando el equipo no define quién usa la aplicación, en qué dispositivos, en qué contexto y qué resultado debe completarse de forma fiable. Las aplicaciones con reservas, pagos, notificaciones, inicio de sesión, ubicación, cámara, APIs externas o datos personales necesitan algo más que pantallas cómodas: manejo de errores, reintentos, explicación de permisos y rutas de soporte.
Android Developers presenta el trabajo Android a través de interfaz, arquitectura, calidad, seguridad, herramientas, categorías de dispositivos y Google Play. Es un buen modelo operativo. Producción de pantallas, integración con APIs, envío a la tienda y monitorización deberían compartir un mismo estándar de calidad. Cuando se tratan como tareas aisladas, los problemas suelen aparecer tarde, durante la revisión o después del lanzamiento.
Kotlin y Compose son un inicio, no sustituyen el diseño
La documentación oficial de Google describe Kotlin como plenamente compatible con Android y destaca el soporte de primera clase en Android Studio. El SDK de Android también incluye anotaciones de nulabilidad desde Android 9 para ayudar a reducir el riesgo de NullPointerException. Para muchas aplicaciones nuevas, Kotlin es una opción práctica; en bases Java existentes, la migración puede hacerse por etapas con límites claros.
Jetpack Compose se presenta como el conjunto moderno de herramientas de Android para interfaces nativas. Permite describir la UI con APIs de Kotlin y suele reducir código repetitivo, pero no elimina la necesidad de arquitectura. Si la propiedad del estado no está clara, aparecen problemas en recomposición, navegación, conservación de entradas y mensajes de error. Para cada pantalla, separe estado mostrado, acciones del usuario, actualizaciones de datos y comportamiento ante fallos. ViewModels u otros contenedores de estado deben conservar los datos que sobreviven a cambios de configuración y navegación.
Android 16 no debe esperar a la semana de publicación
La página de Android 16 indica que los desarrolladores deben preparar un entorno de ejecución, configurar el SDK y las herramientas de Android 16, revisar los cambios de comportamiento para todas las aplicaciones, revisar los cambios para aplicaciones que apuntan a Android 16 y probar los flujos de usuario. Por tanto, la preparación de plataforma no es solo cambiar una configuración de compilación. Notificaciones, trabajo en segundo plano, acceso a medios, permisos, tamaños de pantalla y SDKs de terceros pueden requerir revisión.
En la práctica, la preparación para versiones mayores de OS debe estar dentro del sprint y del plan de mantenimiento. Revisar dependencias, Android Gradle Plugin, uso de NDK, dispositivos de prueba, registros de fallos y comentarios de revisión de Play ayuda a estimar mejor las actualizaciones de API objetivo.
Los requisitos de Google Play pertenecen al plan de producto
La guía de Google Play sobre nivel de API objetivo indica que, desde el 31 de agosto de 2025, las aplicaciones nuevas y las actualizaciones deben apuntar a Android 15, nivel de API 35, o superior. También existen requisitos de disponibilidad para aplicaciones existentes, por lo que conviene comprobar la guía oficial más reciente antes de cada publicación.
Subir el nivel de API objetivo no es solo cambiar una línea de configuración. Puede afectar permisos, notificaciones, ejecución en segundo plano, almacenamiento, acceso a medios, compatibilidad de SDK, declaraciones de privacidad, ficha de tienda y textos sensibles para revisión. En desarrollos por encargo, el contrato debería definir quién atiende futuros cambios de requisitos, ventanas de soporte y mantenimiento posterior.
La compatibilidad con 16 KB empieza por las dependencias nativas
Android Developers explica que, desde el 1 de noviembre de 2025, las aplicaciones nuevas y actualizaciones enviadas a Google Play y dirigidas a dispositivos Android 15 o posteriores deben admitir tamaños de página de 16 KB en dispositivos de 64 bits. Las aplicaciones escritas solo en Kotlin o Java generalmente ya admiten dispositivos de 16 KB, pero las que usan bibliotecas NDK directamente o mediante SDKs necesitan verificación.
Mapas, pagos, publicidad, analítica, procesamiento de imágenes, juegos, audio, cifrado y SDKs propietarios pueden incluir bibliotecas nativas. Use APK Analyzer para comprobar archivos .so y pruebe en un entorno de 16 KB mediante emulador o dispositivo compatible. Si hay NDK antiguo o bibliotecas precompiladas, revise el soporte del proveedor y planifique recompilaciones o reemplazos.
No retrase la UI adaptativa ni la accesibilidad
Los dispositivos Android varían mucho en tamaño y postura. Un diseño solo para teléfono vertical puede dejar tabletas y plegables con experiencias estiradas, vacías o difíciles de operar. Planifique desde el inicio diseños compactos, medios y expandidos. Decida cómo cambian navegación, pantallas lista-detalle, formularios, imágenes, diálogos y entrada según el ancho disponible.
La accesibilidad merece la misma disciplina. Escalado de texto, contraste, etiquetas para lectores de pantalla, orden de foco, áreas táctiles y mensajes de error son más baratos de resolver en el sistema de componentes que al final. Compose ofrece semántica y APIs de prueba que ayudan a estructurar el significado de la UI para tecnologías asistivas y pruebas automatizadas. Es un tema de calidad y mantenibilidad.
Lista práctica
| Área | Qué revisar | Evidencia |
|---|---|---|
| Planificación | Usuarios, casos de uso, dispositivos, distribución | Historias de usuario, métricas de éxito, restricciones |
| Diseño | Navegación, permisos, modo sin conexión, propietario de datos, recuperación ante fallos | Flujos de pantalla, diseño de API, transiciones de estado, política de errores |
| Implementación | Kotlin, Compose, arquitectura, SDKs dependientes, estrategia de pruebas | Código, registros de revisión, pruebas unitarias, pruebas de UI |
| Compatibilidad | Android 16, API objetivo, páginas de 16 KB, tamaños de pantalla | Matriz de dispositivos, notas de compatibilidad, registros de fallos |
| Publicación | Requisitos de Google Play, ficha de tienda, privacidad, despliegue gradual | Lista de publicación, notas de versión, plan de monitorización |
| Operación | Actualizaciones de OS, SDKs, soporte, incidentes, alcance de mantenimiento | Procedimientos, límites de responsabilidad, plan de actualización |
FAQ
¿Una aplicación Android nueva debería usar Kotlin y Compose?
En muchos proyectos, sí. Kotlin está bien soportado en Android Studio, y Compose encaja con interfaces modernas y adaptativas. Aun así, activos existentes, experiencia del equipo, SDKs necesarios y plazos pueden justificar mantener algunas pantallas basadas en Views e introducir Compose gradualmente.
¿Qué revisar primero para Android 16?
Revise los cambios de comportamiento oficiales, el impacto del SDK objetivo, los flujos principales en dispositivos reales o emuladores y el soporte de SDKs de terceros. Notificaciones, permisos, trabajo en segundo plano, acceso a medios y tamaños de pantalla pueden variar por aplicación.
¿Todas las aplicaciones necesitan trabajo específico para páginas de 16 KB?
Las aplicaciones incluidas en el requisito de Google Play deben verificar compatibilidad. Las aplicaciones solo Kotlin o Java generalmente ya admiten dispositivos de 16 KB, pero las que incluyen código nativo o SDKs con bibliotecas nativas necesitan revisión de compilación y pruebas.
¿Qué se pasa por alto en el desarrollo Android por encargo?
La responsabilidad después del lanzamiento. Actualizaciones de OS, requisitos de API objetivo, actualizaciones de SDK, problemas de revisión de tienda, corrección de fallos y soporte deben tener propietarios y alcance claros antes de publicar.
Referencias
- Android Developers: Develop for Android
- Android Developers: Kotlin and Android
- Android Developers: Jetpack Compose
- Android Developers: Android 16
- Android Developers: Google Play target API level requirement
- Android Developers: Support 16 KB page sizes
- Android Developers: Android Studio and app tools