Requisitos para publicar en Google Play para nuevos desarrolladores en 2026

Google Play no otorga una sola aprobación. Retiene cada lanzamiento detrás de una cadena de controles independientes, y cada control tiene su propia regla de aplicabilidad, así que buena parte de lo que sigue no te va a aplicar.

Cada requisito de abajo trae las mismas cuatro cosas: a quién le aplica, qué tienes que hacer, qué demuestra que está cumplido y la página oficial de la que sale. Donde las propias páginas de Google se contradicen, y aquí ocurre en dos puntos, te damos las dos versiones en lugar de nuestra suposición.

Los requisitos para publicar en Google Play, de un vistazo

Abajo están todos los controles, con la regla que decide si te alcanza y la señal en Play Console que demuestra que está listo. Algunos desarrolladores se saltan por completo las filas marcadas como condicional.

El orden real en que ocurren

Ocho etapas, y el orden no es una preferencia: tres de ellas son requisitos estrictos de la que viene después.

1. Elige y verifica tu cuenta de desarrollador Tipo de cuenta, la tarifa, la identidad y la comprobación de dispositivo cuando Play Console la muestra.
2. Crea la app y prepara una compilación conforme Registro de la app e ID de aplicación, App Bundle y firma, nivel de API objetivo, comprobaciones previas de la compilación.
3. Comprueba el registro de desarrollador de Android Una comprobación de estado en Play Console cuando ya existen la app y el paquete.
4. Completa la ficha de la tienda y los recursos Límites de texto, gráficos obligatorios, la máscara del icono, declaraciones de recursos generados con IA.
5. Completa Contenido de la app y el acceso para revisores Privacidad, Seguridad de los datos, eliminación, clasificación, público, anuncios, las dos declaraciones universales e instrucciones de inicio de sesión.
6. Ejecuta la prueba cerrada que califica Solo para cuentas personales creadas después del 13 nov 2023: 12 testers que aceptaron participar durante 14 días continuos.
7. Solicita el acceso a producción El cuestionario de tres partes sobre tu prueba, tu app y tu preparación.
8. Envía y publica la versión de producción Países, precios, el bundle, las notas de la versión, el envío a revisión y luego la publicación.

1. Elige y verifica tu cuenta de desarrollador

Necesitas una Cuenta de Google con la verificación en dos pasos activada, y al registrarte aceptas el Acuerdo de Distribución para Desarrolladores y las Condiciones del Servicio de Play Console. Después hay tres cosas que deben quedar resueltas antes de que puedas publicar: la tarifa, tu identidad y, cuando Play Console la muestra, una comprobación de dispositivo.

Qué es la tarifa de US$25 y qué no es

La tarifa se paga solo con tarjeta de crédito o débito. Los tipos de tarjeta aceptados varían según la ubicación, y Google es explícito en que no se aceptan tarjetas prepagadas.

Personal o de organización, y cuándo la decisión ya está tomada

Empieza por la pregunta de la categoría, porque para algunas apps no hay nada que elegir.

Si ninguna de esas categorías te alcanza, la decisión es tuya. Los dos tipos pueden publicar y monetizar, así que parte de la diferencia está en lo que Google verifica sobre ti, pero no es solo papeleo. Una cuenta personal creada después del 13 de noviembre de 2023 además debe hacer una prueba cerrada que califique, el elemento fijo más largo de esta guía. Comparación más completa: cuentas personales frente a cuentas de organización.

Qué exige la verificación de la cuenta y por qué los plazos varían

Google verifica quién eres a nivel de cuenta antes de que puedas publicar. Una cuenta personal aporta un documento de identidad oficial; una organización aporta los datos de la organización junto con uno. Lo que te pidan puede depender de lo que tu perfil de pagos ya tenga verificado, y por eso a dos personas que siguen la misma guía les piden cosas distintas. Verifica la información de identidad de desarrollador

Google no publica ningún tiempo de procesamiento garantizado para la revisión de identidad de una cuenta de Play, y el famoso «hasta 5 días» no lo es: esa cifra viene de la documentación de pagos de Google, no de la página de identidad de Play. Completa las tareas que muestra Play Console y deja margen para comprobaciones adicionales de documentos. La verificación del método de pago es otra cosa distinta: una comprobación de comerciante ligada a cobrar pagos, no un paso que todo desarrollador de apps gratuitas tenga que iniciar. Información de la cuenta y verificaciones de comerciante

Listo cuando: Play Console deja de mostrar la tarea de verificación de identidad de tu cuenta. Trata «enviado» y «aprobado» como dos estados distintos: un documento enviado no desbloquea la publicación.

Verificación de dispositivo: el control que casi todas las guías se saltan

Las cuentas personales de desarrollador nuevas tienen una tarea de dispositivo aparte. Verificas el acceso a un dispositivo Android móvil físico, sin root y con Android 10 o posterior, usando la app móvil de Play Console con la sesión iniciada como titular de la cuenta. Requisitos de verificación de dispositivo

Lo que no es: la verificación de identidad, la prueba cerrada que califica ni una regla sobre tus testers; aquí nada dice que las 12 personas de tu prueba cerrada necesiten ese tipo de dispositivo. Es un elemento propio en la página de inicio de Play Console, y un emulador no lo resuelve.

Listo cuando: La tarea de verificación de dispositivo desaparece de la página de inicio de tu Play Console.

Cambiar el tipo de cuenta más adelante

Puedes convertir una cuenta personal de desarrollador en una cuenta de organización con el flujo de verificación de Google: verifica el sitio web de la organización, crea o selecciona y verifica su perfil de pagos, y luego completa el cambio dentro de la cuenta existente. Google recomienda esperar al menos 72 horas después de la conversión antes de enviar apps nuevas. En sentido contrario, de organización a personal, sí hace falta una cuenta nueva. Conversión del tipo de cuenta

2. Crea tu app y prepara una compilación conforme

Son dos mitades: el registro de la app que creas en Play Console y el artefacto que subes a ese registro. Una de las decisiones de aquí acompaña a la app durante toda su vida, así que vale la pena dedicarle treinta segundos ahora.

Las decisiones que son permanentes

Crear la app en Play Console fija su nombre, el idioma predeterminado, si es app o juego y si es gratuita o de pago. El ID de aplicación es otra cosa: vive en la configuración de tu compilación, no en ese formulario de Play Console, y los dos se encuentran cuando subes el archivo. Así que revisa el ID de aplicación en tu compilación antes de subirla, en lugar de suponer que un registro vacío en Play Console ya lo dejó fijado. Crea y configura tu appID de aplicación

Android App Bundle y los dos roles de firma

Para una app pública nueva y corriente, Google Play acepta el Android App Bundle (.aab) en lugar de un APK, y la app usa Play App Signing. Vale la pena enunciar ese alcance una vez, en lugar de presentarlo como algo absoluto: las apps antiguas que siguen siendo elegibles conservan sus flujos con APK, los App Bundles son obligatorios para todas las apps de Android TV desde junio de 2023, y la distribución privada de apps de empresa funciona de otra forma. App BundlesApps privadas

Play App Signing divide dos roles, que no es lo mismo que dos claves físicas en tu poder. La clave de firma de la app la gestiona Google y firma lo que instalan los usuarios. La clave de carga firma tu bundle antes de subirlo, para que Google sepa que viene de ti. Los dos roles pueden apoyarse en la misma clave o en claves distintas; una clave de carga separada es la configuración recomendada, porque se puede restablecer si la pierdes. Firma tu app

Nivel de API objetivo, por tipo de dispositivo

Es el requisito que con más probabilidad bloquea una subida de golpe, y no es un solo número: varía según lo que estés enviando.

Google documenta ventanas de prórroga que llegan hasta el 1 de noviembre de 2026 en algunas circunstancias, pero la elegibilidad se decide para tu app concreta dentro de Play Console. Requisitos de nivel de API objetivo El detalle de la migración está en la guía del nivel de API objetivo.

Comprobaciones previas: qué puede rechazar un bundle aparentemente válido

Dos comprobaciones atrapan proyectos que por lo demás parecen terminados. Las dos son condicionales: si ninguna alcanza a tu app, sáltate esto y sigue adelante.

Bibliotecas nativas: 64 bits y tamaño de página de 16 KB

Si tu app incluye código nativo, ya sea directamente, a través de un SDK o generado por un creador de apps, revisa que admita 64 bits y que sea compatible con el tamaño de página de 16 KB, y pruébala en un entorno de 16 KB. Las apps escritas solo en Java o Kotlin, dependencias incluidas, ya admiten el tamaño de página correspondiente. Revisa el bundle que de verdad subes: una dependencia puede reintroducir una biblioteca de 32 bits o alineada a 4 KB sin que tú cambies nada. Tamaños de página de 16 KB64 bits

Versión de Play Billing Library

Si tu app integra Play Billing, y solo en ese caso, los envíos nuevos suelen necesitar la versión 8 o posterior de Billing Library. La fecha límite ordinaria de la versión 7 fue el 31 de agosto de 2026, y una prórroga aplicable puede llegar hasta el 1 de noviembre de 2026. Nada de esto alcanza a una app sin esa integración, y tampoco significa que las apps ya instaladas dejen de funcionar. Calendario de baja de versiones de Billing Library

Listo cuando: Un .aab firmado se sube sin errores de nivel de API objetivo ni de formato, el código de versión es mayor que cualquiera que hayas subido antes y, si la app incluye código nativo, pasan tanto tus comprobaciones de compatibilidad como una ejecución en un entorno de 16 KB. Que Play Console valide una subida no es lo mismo que tener tus dependencias probadas: resuelve los problemas bloqueantes y lee las advertencias.

3. Comprueba el registro de desarrollador de Android en Play Console

Esta etapa va después de la anterior porque necesita que la app exista: el registro vincula una app, con su nombre de paquete y la huella de su clave de firma, a una identidad de desarrollador verificada, en todo el ecosistema de Android y no solo en Google Play. Es algo distinto de la verificación de identidad a nivel de cuenta de la etapa 1, que demuestra quién eres para que puedas tener una cuenta.

Para quien publica en Play, la pregunta práctica es muy concreta: ¿está registrada tu app? Consulta su estado en la página de Verificación de desarrolladores de Android de Play Console. Google intenta el registro automático y reutiliza la verificación de identidad que ya completaste, así que para la mayoría de quienes publican en Play esto es una comprobación de estado y no una tarea: no necesitas una cuenta aparte de Android Developer Console y no repites la verificación de identidad. Confirma el registro y completa cualquier acción pendiente que aparezca ahí. Registro de nombres de paquete de Play

Las apps que sigan sin registrar se arriesgan a que las retiren de Google Play en todo el mundo desde el 30 de septiembre de 2026 en adelante, algo fácil de pasar por alto porque casi toda la cobertura de esa fecha describe solo la fase de instalación en cuatro países, que es otra parte del mismo programa. Dos cosas que puedes ignorar: la cuenta gratuita de Distribución Limitada es para aficionados que distribuyen a un puñado de dispositivos y no es una vía gratuita para entrar en Google Play; y la versión mínima de Android del verificador del dispositivo está documentada de forma inconsistente (la FAQ de Android Developers dice 7 o posterior y la Ayuda de Android dice 8 o posterior), lo cual es un conflicto sin resolver entre dos páginas de Google y no un requisito sobre el que tengas que actuar. Ayuda de Android

Listo cuando: La página de Verificación de desarrolladores de Android de Play Console muestra la app como registrada, sin ninguna acción pendiente anotada.

4. Completa tu ficha de la tienda y los recursos

La ficha es lo primero que ven los usuarios y los revisores, y tiene límites estrictos que impiden guardar. La línea útil que conviene trazar está entre lo que Google exige para publicar y lo que recomienda para aparecer destacado; abajo van separados.

Obligatorio para publicar

Google Play Console · captura real

Recomendado, pero no es un control de publicación

La guía de Google sobre recursos de vista previa también describe qué hace que una ficha sea elegible para los espacios de formato grande y de recomendaciones: más capturas de pantalla, resoluciones más altas, conjuntos para las clases de dispositivo en las que quieres aparecer destacado. Que te falte algo de eso no bloquea un lanzamiento. Las fichas de Wear OS, TV y XR tienen además sus propias reglas de recursos. Recursos de vista previa

La máscara de esquinas del icono

Subes un icono cuadrado completo y Google Play aplica una máscara dinámica de esquinas con un radio equivalente al 30% del tamaño del icono, así que todo lo que quede cerca de una esquina se recorta en el resultado final. Esta es la especificación actual y no, como se repite a menudo, un cambio introducido en 2026. La fecha de modificación de una página fuente no es prueba de cuándo empezó a regir una norma. Especificaciones de diseño del icono

Declaraciones de IA para recursos de la tienda generados

Si generas o editas imágenes, video o material promocional de la ficha con IA, Play Console ahora incluye autodeclaraciones por recurso en sus flujos de creación de contenido, y aplica etiquetas a los recursos que caen dentro del alcance regulatorio correspondiente. La página de ayuda de Google no indica fecha de inicio ni una lista exhaustiva de las normas que cubre, así que no vamos a inventar ninguna de las dos. Esto trata de los recursos de la tienda, algo distinto de la política que rige lo que una app generativa produce para los usuarios. Cómo declarar contenido generado con IA

Reglas de metadatos por las que se rechazan fichas

La guía de Google sobre fichas es estricta con el lenguaje promocional en los campos que aparecen en los resultados de búsqueda y en los estantes: el título, el icono, el nombre del desarrollador y la descripción breve.

Listo cuando: La ficha principal de la tienda se guarda sin errores por recursos faltantes, y los gráficos que subiste se siguen leyendo bien después de la máscara de esquinas.

5. Completa Contenido de la app y el acceso para revisores

Contenido de la app es la parte que quien publica por primera vez subestima, porque nada de eso es ingeniería y todo bloquea. Es una pila de declaraciones, y una respuesta incompleta o inexacta es una de las razones más comunes de que un lanzamiento se frene.

Política de privacidad: en todas las apps y en dos lugares

Toda app necesita una política de privacidad, no solo las dirigidas a menores, que es como se suele contar. Da el enlace en Play Console y un enlace o el texto de la política dentro de la app. Usa una URL activa, pública y sin restricción geográfica, no un PDF. Una app que no recopila datos igual necesita una, y «no recopilamos nada» no es una política: aun así tiene que identificar la app y al desarrollador, dar un contacto de privacidad y describir cómo se tratan y se conservan los datos que sí toca. Política de Datos del Usuario

Seguridad de los datos

Toda app en el segmento cerrado, abierto o de producción completa el formulario de Seguridad de los datos. Las apps que solo llegan a ejecutarse en el segmento de pruebas internas están exentas, una razón real para usar las pruebas internas desde temprano. Una app que no recopila nada igual completa el formulario y lo declara así. Seguridad de los datos

Declara lo que tu app recopila y comparte de verdad, incluido lo que hacen tus SDK en tu nombre. Esa es la parte que más veces está mal: un SDK de analítica, de anuncios o de informes de errores recopila datos hayas escrito tú ese código o no, y la declaración es tuya. Lee la documentación de cada SDK en lugar de suponer que todo un proveedor se comporta igual.

Eliminación de la cuenta y de los datos

Si los usuarios pueden crear una cuenta en tu app, tienes que dejarles solicitar la eliminación desde dentro de la app y también desde fuera, con una URL web accesible públicamente, y eliminar la cuenta debe eliminar los datos asociados. Cuando la ley o una razón comercial legítima te obliguen a conservar algo, decláralo.

Todo lo demás en Contenido de la app

Además de la privacidad, Seguridad de los datos, la eliminación y Acceso a la app que ya vimos, quedan estas. Dos de ellas toman a la gente desprevenida porque sus nombres suenan condicionales: las declaraciones de Apps de salud y de Funciones financieras son obligatorias para una app pública común en el segmento cerrado, abierto o de producción incluso cuando no tiene ninguno de los dos tipos de funciones. Las dos tienen una respuesta de «sin funciones», y completar una no hace que se te apliquen las normas de licencias médicas o financieras. Declaración de apps de saludDeclaración de funciones financieras

Google Play Console · captura real

Dales a los revisores un acceso que funcione

Si alguna parte de tu app está detrás de un inicio de sesión o de otra barrera, completa Acceso a la app. Play Console admite hasta cinco conjuntos de instrucciones, conjuntos de instrucciones y no necesariamente cinco juegos de credenciales, algo que importa si tienes un solo inicio de sesión y varias rutas restringidas. Prepara tu app para la revisión

Antes de enviar, comprueba que las credenciales siguen funcionando y que alguien que no seas tú puede llegar a cada función restringida. Las cuentas vencidas, los códigos de un solo uso que llegan a tu teléfono y las funciones que solo se desbloquean para una cuenta interna son los fallos habituales.

Listo cuando: Contenido de la app no muestra ninguna tarea pendiente, y alguien que no seas tú puede iniciar sesión exactamente con lo que escribiste en Acceso a la app.

Declaraciones específicas de categoría

Además de los formularios de arriba, algunas políticas se enganchan a lo que la app hace de verdad. Estas sí son condicionales:

• Apps de salud, más allá de la declaración. Si la app sí tiene funciones de salud, la política de Contenido y Servicios de Salud añade el etiquetado de dispositivo médico y un requisito de aviso legal para las apps de salud no reguladas, y las apps de salud de los tipos especificados exigen una cuenta de organización. Contenido y Servicios de Salud
• Apps de IA generativa. Impide las salidas prohibidas y dales a los usuarios una forma de denunciarlas o marcarlas dentro de la app. Esto trata de lo que la app produce, algo distinto de las declaraciones de recursos de la tienda de arriba, y no es una regla que obligue a etiquetar toda app asistida por IA. Política de Contenido Generado por IA
• Permisos de fotos y video. Pide acceso amplio solo cuando una función principal lo necesite; si no, usa el selector de fotos del sistema.
• Ubicación y contactos. Los dos tienen requisitos próximos de alcance mínimo, con fechas reales y un alcance estrecho: mira fechas límite y cambios condicionales.
• Otras categorías. Noticias y revistas, servicios financieros, apps de gobierno y otras tienen cada una su página de política enlazada desde Contenido de la app.

6. Completa la prueba cerrada obligatoria, si te aplica

A quién aplica: cuentas personales de desarrollador creadas después del 13 de noviembre de 2023. Las cuentas de organización, y las cuentas personales creadas antes de esa fecha, no tienen este requisito en absoluto; si ese es tu caso, salta a enviar la versión.

La regla es corta: ejecuta una prueba cerrada con al menos 12 testers que hayan aceptado participar a lo largo de los 14 días continuos anteriores a tu solicitud de acceso a producción. La reducción de 20 testers a 12 entró en vigor el 11 de diciembre de 2024 y mantuvo los mismos 14 días. Requisitos de pruebasEl cambio de 20 a 12

Google Play Console · captura real

Tres segmentos, y solo uno de ellos cuenta

Las pruebas internas parecen el atajo evidente y son de verdad útiles, solo que no para esto.

Google evalúa dos cosas: tu cantidad de testers y su interacción con la app. Entre sus propios ejemplos de por qué pide más pruebas están los testers que no interactuaron con la app durante la prueba, así que 12 nombres en una lista no son el requisito. Lo que Google no publica es ninguna regla sobre minutos por día ni sobre sesiones: si has leído una cifra diaria concreta, no viene de Google, y tu prueba no debería planificarse en torno a ella.

Cómo cumplirlo de verdad

Todos los demás requisitos de aquí son papeleo o ingeniería que tú controlas. Este necesita 12 personas reales, en dispositivos Android reales, que acepten participar y sigan participando durante 14 días sin interrupción.

Listo cuando: Play Console muestra 12 o más testers que aceptaron participar y la prueba cerrada en marcha durante al menos 14 días continuos, y la acción «Solicitar acceso a producción» pasa a estar disponible en el Panel.

7. Solicita el acceso a producción, si te corresponde

A quién aplica: las mismas cuentas que la prueba cerrada, es decir las cuentas personales creadas después del 13 de noviembre de 2023. Todos los demás pasan directo a la versión.

Cumplir los criterios de la prueba cerrada no te lleva a producción por sí solo. Solicitas el acceso en el panel de Play Console y respondes un cuestionario. Se suele describir como un formulario fijo de diez preguntas; Google cambia la redacción con el tiempo, así que es mejor tenerlo en la cabeza como tres temas.

Escríbelo a partir de la prueba que de verdad ejecutaste. Ninguna forma de redactarlo garantiza la aprobación; lo que ayuda es el detalle concreto sobre pruebas reales y cambios reales. Las respuestas genéricas son una vía conocida a que te pidan más pruebas. Los ejemplos resueltos están para mostrarte cómo describir tu propia prueba, no para darte un guion.

Google dice que esta revisión suele tardar siete días o menos, aunque de vez en cuando puede tardar más: planifica siete días y no lo tomes como un techo. Tiempos de revisión del acceso a producción Si se deniega el acceso, el resultado habitual es una petición de más pruebas y no un rechazo, y tu prueba cerrada no tiene por qué detenerse mientras preparas una nueva solicitud. Qué hacer después de «se requieren más pruebas».

Listo cuando: Play Console muestra el acceso a producción concedido. Nada anterior a ese momento, ni una lista de verificación completa ni 14 días cumplidos, es la concesión en sí: la decisión es de Google.

8. Envía y publica la versión de producción

El acceso a producción, donde aplica, desbloquea el segmento, no publica nada. La versión es su propia secuencia, y es donde la gente llega con todo completo y nada en vivo. Prepara y lanza una versión

1. Países y regiones Empieza con pocos y amplía después si quieres.
2. Precios Se fijan antes de la primera versión. Una app gratuita no puede pasar después a ser de pago con el mismo nombre de paquete.
3. Agrega el bundle de la versión Selecciona un bundle elegible que ya hayas subido para las pruebas, o sube una compilación nueva con un código de versión mayor. Pasar un artefacto ya probado a la versión de producción no obliga por sí solo a volver a compilarlo.
4. Nombre de la versión y notas de la versión El nombre es interno; las notas son lo que ven los usuarios para esta versión.
5. Lee los errores y las advertencias Play Console bloquea ante los errores y deja pasar las advertencias. Lee las dos cosas: la advertencia suele ser lo que importa después.
6. Envía los cambios a revisión Nada queda enviado hasta que lo haces. Una página de versión terminada con cambios sin enviar es una de las formas más silenciosas de que se frene un lanzamiento.
7. Síguelo por la revisión y la publicación En revisión, listo para publicar y en vivo son tres estados distintos. Si la publicación administrada está disponible y activada, los cambios aprobados esperan hasta que selecciones «Publicar cambios»: la aprobación por sí sola no es publicación. La ficha puede tardar después en aparecer.

Listo cuando: La descripción general de la publicación no muestra cambios sin enviar, y la versión de producción aparece como en vivo, no solo como aprobada. Donde aplica la publicación administrada, ese último paso lo activas tú. Publicación administrada y estados de publicación

Cuánto tarda publicar y qué se puede solapar

Cerca de la meta hay dos revisiones y son distintas: la revisión del acceso a producción después de tu cuestionario, y la revisión de la versión en sí. Google dice que la revisión del acceso suele tardar siete días o menos pero puede tardar más, y que la revisión de la app también puede superar los siete días en casos excepcionales. Ninguna de las dos tiene un tope de una semana. Tiempos de revisión y publicación Cifras etapa por etapa: la guía de tiempos de revisión.

Qué bloquea de verdad a qué

Casi todo esto se puede trabajar en cualquier orden. Cuatro cosas no, y saber cuáles son esas cuatro es la diferencia entre un lanzamiento de tres semanas y uno de seis.

Una estimación de planificación, señalada con claridad como tal

De tres a cinco semanas o más es un plan razonable para una cuenta personal nueva. Esa es nuestra estimación de planificación, no un nivel de servicio de Google, y da por hecho una app ya bastante construida, testers que aceptan participar pronto y ningún retrabajo importante. Construir la app no está dentro de esa cifra, y una ronda de retrabajo la alarga.

Qué te está diciendo Play Console y dónde arreglarlo

Casi todos los atascos se manifiestan como uno de seis mensajes. Lee cuál te tocó en lugar de reenviar y cruzar los dedos.

Tu lista de verificación según la etapa

Dile qué cuenta tienes y hacia qué estás trabajando. Separa tres cosas que la lista de siempre mezcla: lo que necesitas ahora, lo que se exige más adelante y lo que no te aplica en absoluto. Es un seguimiento para tu propio uso: no puede ver tu Play Console, y terminarla no es una aprobación.

Fechas límite actuales y cambios condicionales de las políticas

Estos son los elementos con fecha que pueden cambiar lo que construyes o cuándo lanzas. La mayoría no alcanzará a tu app: lee la tercera columna antes de actuar sobre cualquiera de ellos.

Requisitos permanentes sin fecha límite asociada

Están en vigor ahora y no aparecen en ninguna lista de «qué cambió», que es justo por lo que sorprenden a quien aprendió este proceso hace uno o dos años.

• Pruebas cerradas: 12 testers, 14 días continuos, para las cuentas personales creadas después del 13 de noviembre de 2023. La cifra bajó de 20 a 12 el 11 de diciembre de 2024.
• Las transferencias de propiedad de la cuenta pasan por el flujo de transferencia de Play Console. La transferencia directa de propietario cubre las organizaciones y las cuentas personales que no monetizan; una cuenta personal que monetiza usa otra vía, con una cuenta nueva y la transferencia de las apps. Comprar, alquilar o vender cuentas a través de terceros está prohibido. Transferencia de la propiedad
• Las cuentas de organización son obligatorias para determinadas apps de servicios financieros, de salud, de VpnService aprobadas y de gobierno.
• Los permisos de fotos y video ya se exigen. Acceso amplio solo cuando una función principal lo necesite; si no, el selector de fotos del sistema.

PolicyBytes: actualizaciones de políticas de abril de 2026

El equipo de Experiencia del Desarrollador de Google habla sobre las políticas de contactos y de transferencia de cuentas y sobre las actualizaciones de ubicación y de contenido con restricción de edad de arriba. Es opcional; la tabla tiene la versión accionable.

YouTube

Cómo ayuda PrimeTestLab con las pruebas cerradas

Siete de las ocho etapas son papeleo e ingeniería que tú controlas. Una necesita 12 personas reales, en dispositivos Android reales, que acepten participar y estén realmente activas durante 14 días sin interrupción: el paso en el que se atascan los desarrolladores en solitario, y la única parte que hacemos nosotros.

Tú compartes el enlace para participar de tu prueba cerrada. Nosotros nos encargamos de la invitación, de confirmar la participación, del seguimiento diario de la interacción y de la retención completa durante los 14 días, reemplazando a quien abandone. Cualquier idioma de app, segmentación por país flexible.

Paquetes actuales

Garantía de reembolso · Las pruebas suelen empezar en 4-6 horas · Sin suscripción

Preguntas frecuentes

Qué hacer ahora

De dónde sale cada requisito

Cada afirmación de peso de arriba enlaza su fuente en el punto donde se hace; esta es la versión en forma de directorio. Las páginas de ayuda de Google en su mayoría no llevan fecha, así que la fecha de modificación de una página no es prueba de cuándo entró en vigor una política.

Qué cambió en esta revisión

11 de septiembre de 2026

Reconstruido a partir de la documentación de Google consultada el 8 de septiembre, y revisado otra vez tras una nueva auditoría de esa reconstrucción. Corregido: el requisito de nivel de API objetivo (ahora una matriz por tipo de dispositivo); el orden de los requisitos previos de las pruebas cerradas; la conversión de cuenta personal a cuenta de organización; los plazos del D-U-N-S; el alcance de la fecha límite de registro del 30 de septiembre de 2026 y su vía, que es una comprobación de estado en Play Console después de que la app exista; contactos y ubicación al 27 de enero de 2027 con API 37+, con la implementación y la declaración como acumulativas; las especificaciones del icono, de las capturas y del video de vista previa; el acceso para revisores como cinco conjuntos de instrucciones; el ID de aplicación como propiedad de la compilación y no del registro en Play Console; y la mecánica de la versión, donde un bundle ya probado y elegible se puede reutilizar y la aprobación no es publicación cuando se aplica la publicación administrada. Añadido: la verificación de dispositivo, las etapas de creación de la app y de la versión, las comprobaciones previas de código nativo y de Play Billing, las declaraciones de recursos de la tienda generados con IA, las declaraciones de apps de salud y de funciones financieras (obligatorias incluso sin esas funciones), una tabla de bloqueos y una fuente junto a cada afirmación de peso. Eliminado por no estar respaldado: la fecha de migración de cuentas de salud del 28 de enero de 2026, el mito de los «cinco días» de la verificación de identidad, la explicación del ID de desarrollador de Android de abril de 2025, el tope de 1 MB del gráfico de funciones y el ranking del «rechazo evitable #1». La lista de verificación se reconstruyó dos veces: ahora separa «se exige más adelante» de «no te aplica», y ya no interpreta el trabajo enviado como completado.

24 de junio de 2026

Primera publicación.