Cómo publicar una aplicación Android en Google Play: guía completa

Apps mobile · Por · Publicado el · Actualizado el · 7 min de lectura

Fragmento desenfocado de código colorido en la pantalla de un ordenador con poca profundidad de campo
Ilustra el desarrollo y la preparación de una app antes de publicarla en Play Store. Foto: Godfrey Atima / Pexels

Este paso a paso muestra cómo publicar una aplicación Android en Google Play, desde la preparación del proyecto hasta la revisión y la disponibilidad para usuarios. Generarás la clave de firma, crearás el AAB, completarás la ficha de la tienda, elegirás tracks de prueba y enviarás la versión a producción con seguridad.

Pre requisitos y checklist inicial

Antes de publicar, asegúrate de que la app está lista para release. Ten una cuenta de desarrollador en el Play Console, un identificador único (applicationId), versión actualizada (versionCode/versionName) y una política de privacidad accesible.

Revisa permisos y bibliotecas. Mantén el target SDK actualizado y el soporte a las arquitecturas exigidas. Si la app usa APIs propias, considera seguridad, autenticación y límites de uso.

Para apps que consumen APIs, revisa prácticas de protección y rendimiento del backend. Consulta recursos como APIs seguras con OAuth2 y rate limiting y consejos para reducir la latencia de APIs REST.

  • Cuenta de desarrollador activa
  • applicationId definitivo y único
  • versionCode incrementado y versionName definida
  • Política de privacidad alojada y accesible
  • Icono, capturas de pantalla y descripción preparados
  • Verificación de dependencias y permisos

1) Generar y guardar la clave de firma (keystore)

Necesitas firmar la app para distribuirla. La clave privada identifica tu aplicación para futuras actualizaciones. Si pierdes esa clave, no podrás enviar actualizaciones para el mismo applicationId. Guarda el archivo y las contraseñas con respaldo seguro.

El comando siguiente crea un keystore y un alias. Ajusta nombres, validez y rutas según tu proyecto.

keytool -genkeypair -v \
  -keystore myapp-release.keystore \
  -alias myapp_key \
  -keyalg RSA -keysize 2048 \
  -validity 36500

2) Configurar firma y versión en Gradle

Configura el build de release con firma, minificación y números de versión. No versiones el keystore en Git y usa variables de entorno para las contraseñas. Confirma que el versionCode aumenta en cada envío (obligatorio).

Ejemplo (Groovy) para build.gradle del módulo app:

android {
  defaultConfig {
    applicationId "com.seu.dominio.myapp"
    versionCode 12
    versionName "1.11.0"
  }
  signingConfigs {
    release {
      storeFile file("../keystore/myapp-release.keystore")
      storePassword System.getenv("KEYSTORE_PASSWORD")
      keyAlias "myapp_key"
      keyPassword System.getenv("KEY_PASSWORD")
      v2SigningEnabled true
      v3SigningEnabled true
    }
  }
  buildTypes {
    release {
      minifyEnabled true
      shrinkResources true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
      signingConfig signingConfigs.release
    }
  }
}

3) Generar el Android App Bundle (AAB) para subida

Los nuevos apps en Play Store usan AAB (Android App Bundle). Permite una distribución optimizada por dispositivo. Genera el paquete de release con Gradle. Verifica que el build de release esté firmando correctamente.

El archivo resultante suele estar en app/build/outputs/bundle/release/app-release.aab.

./gradlew clean bundleRelease

4) Políticas, integridad y seguridad de datos

Antes del envío, completa los formularios de Contenido de la app (clasificación por edades, público objetivo), Seguridad de los datos (qué datos recoge/comparte y finalidades) e Integridad (Play App Signing/Integrity API).

Ten una política de privacidad clara y coherente con el comportamiento real de la app. No declares permisos innecesarios y describe el uso de datos de forma transparente. Mantén bibliotecas actualizadas para reducir riesgos.

Si la app depende de APIs, garantiza autenticación robusta, limitación de peticiones y observabilidad en el backend. Recursos como logs estructurados y correlación ayudan en el análisis de fallos post lanzamiento.

  • Completa "Contenido de la app" y "Seguridad de los datos"
  • Activa Play App Signing (recomendado)
  • Revisa permisos sensibles (cámara, ubicación, etc.)
  • Actualiza dependencias y elimina libs obsoletas

5) Ficha de la tienda (listado): textos y medios

La página de la tienda influye en la conversión y en la conformidad. Prepara los materiales con antelación y optimiza la lectura. Usa un lenguaje directo y muestra beneficios con claridad.

Sigue los requisitos de dimensiones y formatos indicados en el console. Incluye capturas reales de la app y destaca diferencias sin promesas irreales.

  • Título, descripción corta y descripción completa
  • Icono en alta resolución e imágenes promocionales
  • Screenshots por tipo de dispositivo y, si aplica, vídeo
  • Categoría y palabras clave coherentes con la app
  • Política de privacidad e información de contacto

6) Tracks de pruebas, revisión y publicación

Usa tracks para validar la app antes de producción. Añade testers, recopila feedback y corrige crashes antes de lanzarla al gran público. Siempre aumenta el versionCode en cada envío.

Después de subir el AAB, sigue el informe de pre lanzamiento y los avisos de política/seguridad. Cuando esté estable, promueve la versión a producción o realiza un rollout gradual.

Track Uso típico Quién recibe
Internal Validación rápida por equipo y QA Lista restringida de testers
Closed Prueba con grupo controlado (beta cerrada) Conjunto de usuarios invitados
Open Beta pública para recopilar feedback a escala Cualquier usuario que opte por el test
Production Disponibilidad general Todos los usuarios elegibles

Verificación final y solución de problemas comunes

Confirma que la ficha está completa, sin pendientes de política, y que la versión fue promovida al track correcto. Realiza la instalación en un dispositivo real vía Play para validar la actualización firmada.

Errores comunes pueden retrasar la publicación. Usa los mensajes del console para corregir rápido y planifica un proceso repetible. Si quieres automatizar builds y subida, considera una pipeline de CI/CD; los conceptos de CI/CD con GitHub Actions ayudan a estructurar el flujo, incluso para Android.

  • Firma inválida: keystore/alias/contraseñas incorrectos o cambio de clave
  • versionCode repetido: incrementa en cada release
  • applicationId modificado: impide actualizar la app existente
  • Permisos sensibles sin justificación clara: revisa y ajusta el formulario
  • Crashes en dispositivos específicos: verifica arquitecturas y usa el informe de pre lanzamiento
  • APIs lentas/inestables: revisa caching y rendimiento del backend

Preguntas frecuentes

¿Necesito enviar APK o AAB a la Play Store?

Para apps nuevos, usa Android App Bundle (AAB). Permite que Play distribuya solo los recursos necesarios por dispositivo, reduciendo el tamaño de descarga y mejorando la instalación.

¿Puedo cambiar el applicationId después de publicar?

No para la misma app. El applicationId identifica la aplicación en la tienda. Si lo cambias, Play lo tratará como una app nueva y los usuarios no recibirán las actualizaciones automáticamente.

¿Qué pasa si pierdo el keystore de firma?

No podrás firmar futuras actualizaciones con la misma clave. En general, esto impide publicar updates de la app ya publicada. Guarda copias seguras del archivo y las contraseñas y restringe el acceso al mínimo necesario.

¿Cuánto tarda la aprobación de la publicación?

Varía según el contenido y las comprobaciones automáticas/manuales. Apps nuevas y con permisos sensibles pueden tardar más. Planifica tiempo para la revisión y sigue los avisos del console para ajustes rápidos.

¿Cómo hago una actualización de la app ya publicada?

Incrementa el versionCode, genera un nuevo AAB firmado con la misma clave y súbelo. Actualiza las notas de la versión, revisa los formularios de contenido si algo cambió y promueve a la pista deseada.

¿Qué medios son obligatorios en la ficha de la tienda?

Normalmente se solicitan icono, screenshots por tipo de dispositivo y texto descriptivo. Los requisitos exactos y las dimensiones aparecen en el console al crear el listado.

¿Necesitas ayuda con tu publicación Android?

Si quieres revisar la firma, el checklist de políticas, la automatización del build y el flujo de subida a Play Store, hablemos sobre tu caso.

Hablar sobre publicación Android

Ver también