Verificación de desarrolladores Android 2026: fechas y pasos

Casi todo lo que se escribió sobre la verificación de desarrolladores de Android en 2025 hoy es incorrecto en al menos un punto importante, y una cantidad sorprendente de lo escrito a principios de 2026 también. El diseño del programa cambió después del anuncio original, la fecha exacta de aplicación no llegó hasta junio de 2026 y el alcance se acotó por escrito el 22 de julio de 2026. Mientras tanto, la pregunta que los desarrolladores escriben de verdad en el buscador no es "¿qué es la verificación de desarrolladores?" Es: Google dice que fallé, ¿qué está mal exactamente, qué pasa ahora y no había hecho yo esto ya?

Por eso este artículo está escrito como respuesta a incidentes y no como comentario de políticas. Responde primero a la pregunta "¿ya lo tengo hecho?", te da la navegación exacta de Play Console en vez de consejos vagos, separa las dos capas de aplicación que las demás páginas funden en una sola frase alarmante y es explícito en los puntos donde Google no ha publicado nada. También traza una línea firme entre la verificación y la regla aparte de la prueba cerrada con 12 testers, porque esa confusión llega a la bandeja de entrada de PrimeTestLab casi cada semana. Cada fecha y cada cifra de abajo se contrastó con las propias páginas de Google el 9 de agosto de 2026.

La verificación de desarrolladores de Android son dos tareas, no una

Si publicas en Google Play, la verificación de desarrolladores de Android te pide dos cosas distintas: verificar tu identidad y registrar los nombres de paquete de tus apps. La mayoría de los desarrolladores de Play que ya existen cumplen la primera y, en la inmensa mayoría de casos, la segunda ocurrió sola. Para muchas cuentas el trabajo que queda es revisar dos pantallas, aunque Google no publica un tiempo de resolución universal y un problema de documentos o de cuenta puede llevar bastante más.

Qué establece de verdad cada puerta

Las dos tareas responden a dos preguntas diferentes, y superar una no le dice nada a Google sobre la otra. Mantenerlas separadas es lo más valioso que puedes sacar de esta página, porque los modos de fallo, las soluciones e incluso las pantallas de Play Console son distintos.

Una cuenta puede estar entonces verificada por completo en identidad y seguir teniendo un paquete sin registrar tranquilamente en la lista. Esa combinación es justo la que sale mal en una fecha límite, porque el desarrollador miró la pantalla que dice "verificado" y nunca abrió la que enumera las apps.

La respuesta en un minuto para desarrolladores de Play Console que ya existen

Si ya publicas en Google Play, este es todo el camino de cumplimiento en el orden en que conviene revisarlo. La mayoría de lectores se queda en el paso dos.

1. 01

   Confirma tu estado de identidad

   Abre Cuenta de desarrollador en Play Console. La guía de verificación de Google describe la ruta como Configuración › Cuenta de desarrollador, mientras que su documentación más reciente de gestión de cuentas usa Cuenta de desarrollador › Acerca de ti. En cualquier caso, Google indica que si ya completaste la verificación de identidad con éxito no tendrás que repetir ese paso. Verificado

2. 02

   Confirma que todos los paquetes están registrados

   Abre la página Verificación de desarrolladores de Android en Play Console y mira el estado de registro de cada app. La página de inicio de Play Console también puede mostrar información de registro de apps. Si todos tus nombres de paquete se registraron automáticamente, Google indica que no hace falta ninguna acción de registro adicional para esas apps. Verificado

3. 03

   Reclama lo que quede antes del 30 de septiembre

   Para un paquete que no se registró automáticamente, sigue el registro manual de Google. Qué forma toma depende del nombre de paquete: un nombre que Android nunca ha visto solo necesita los datos del paquete y tu certificado público de firma, mientras que un nombre que ya tiene instalaciones necesita un APK de comprobación firmado que demuestre que posees la clave privada. Los dos flujos están en la sección 05.

Si publicas en Google Play, usa Play Console

Esta es la trampa que manda a los desarrolladores a un desvío de una hora. En este programa hay dos consolas. Play Console es donde los desarrolladores de Google Play completan las dos tareas. La Android Developer Console es una superficie aparte para quienes distribuyen fuera de Google Play, y sus páginas de ayuda describen un flujo distinto, incluida la verificación del sitio web de la organización mediante Google Search Console. Los dos conjuntos de instrucciones posicionan para las mismas búsquedas.

Cuatro rutas de distribución, cuatro respuestas. Busca tu fila antes de leer una palabra más de la documentación de Google, porque la fila equivocada te cuesta una tarde:

Correspondencia de rutas tomada de la guía de verificación de Play Console y de la guía de distribución limitada de Google, consultadas el 13 de agosto de 2026. Verificado

La cronología de verificación de 2026 y la fecha que los artículos siguen equivocando

La verificación no llegó en un anuncio. Llegó en cinco, y cada uno acotó o corrigió al anterior. La cronología de abajo toma el material de Google de junio y julio de 2026 como fuente de referencia, algo que importa porque la muy citada previsión de marzo quedó superada.

Cómo llegó el programa de verdad, hito a hito

Cada entrada empareja lo que Google publicó con lo que un desarrollador de Play debería sacar de ahí, porque varias de estas fechas se citan sueltas en otros sitios y se leen muy distinto cuando la secuencia está a la vista.

1. noviembre de 2025

   Se abre el acceso anticipado

   Los desarrolladores invitados al acceso anticipado pudieron empezar a verificar apps distribuidas fuera de Google Play.

   Qué inferir: solo un hito histórico. Nada de aquí crea una obligación para un desarrollador de Play hoy.

2. 30 de marzo de 2026

   Empieza el despliegue a todos los desarrolladores

   Google anunció que empezaba a desplegar la verificación de desarrolladores de Android a todos los desarrolladores, tanto en Play Console como en la Android Developer Console, y pidió a los desarrolladores de Play que estuvieran atentos al acceso en las semanas siguientes. Verificado

   Qué inferir: no leas esto como "todas las cuentas de Play recibieron la verificación el 30 de marzo". La propia redacción de Google es que el despliegue empezó ese día.

3. junio de 2026

   Se despliega el servicio del sistema Android Developer Verifier

   La cronología actualizada de Google sitúa el despliegue del servicio del sistema de verificación en junio de 2026. Verificado

   Qué inferir: usa junio. La entrada del 30 de marzo había pronosticado abril, y varios artículos de terceros actuales siguen repitiendo esa previsión como si fuera historia.

4. 18 de junio de 2026

   Llega la fecha exacta de aplicación

   Google anunció el 30 de septiembre de 2026 como primera fecha de aplicación, nombró las siete tiendas participantes y dijo que más del 99% de las apps de los desarrolladores de Play ya estaban registradas. Verificado

   Qué inferir: es la fuente única más sólida tanto para la fecha como para la cifra de registro automático. Todo lo publicado antes está adivinando la fecha.

5. julio de 2026

   Herramientas: la ID Status API y la Console API

   La Android Developer ID Status API se desplegó a todo el mundo, con la Console API y la distribución limitada en acceso anticipado.

   Qué inferir: relevante para equipos de automatización y herramientas, no para quien publica por primera vez y avanza a mano por Play Console.

6. 15 de julio de 2026

   Se publican las guías actuales

   La guía general de verificación de Google y su guía de Play Console se actualizaron, incluyendo el alcance inicial por tiendas y las instrucciones de registro de paquetes de Play. Verificado

   Qué inferir: trata esas dos páginas como la documentación actual de referencia para todo lo operativo.

7. 22 de julio de 2026

   Las preguntas frecuentes acotan el alcance por escrito

   Las preguntas frecuentes de Google aclararon que las tiendas fuera de la lista participante y la instalación directa de APK no entran en la fase del 30 de septiembre. Verificado

   Qué inferir: esta es la frase que jubila el relato de 2025 de que "Google acaba con el sideloading en esa fecha". Es un límite de primera fase, no una exención permanente.

8. agosto de 2026

   Programado para disponibilidad global: distribución limitada y flujo avanzado

   La página de verificación de Google lista las cuentas de distribución limitada, la API de Android Developer Console y el flujo de instalación avanzado como lanzamientos de agosto de 2026. A 13 de agosto de 2026 su propia guía de distribución limitada sigue diciendo que el registro al acceso anticipado está cerrado y que habrá más información en agosto de 2026, así que esta fila se dibuja como programada, no entregada. Parcial, lanzamiento no confirmado

   Qué deducir: es el punto que más rápido cambia de toda la página, y que el calendario haya entrado en agosto no prueba que se haya lanzado. Consulta la página de verificación de Google para ver el estado actual en lugar de fiarte de cualquier artículo publicado a mitad de mes, incluido este.

9. 30 de septiembre de 2026

   Pasan dos cosas el mismo día

   El registro de apps pasa a ser obligatorio para las instalaciones mediante las siete tiendas participantes en Brasil, Indonesia, Singapur y Tailandia. Por separado, según los requisitos de Play Console, todos los paquetes de Play deben estar registrados, y Google dice que las apps que no lo estén se retirarán de Google Play. Verificado

   Qué inferir: una fecha, dos consecuencias independientes. La sección 03 las separa como corresponde.

10. 2027 en adelante

    Ampliación mundial, fecha sin anunciar

    Google dice que las protecciones se amplían a todo el mundo en 2027. Al 9 de agosto de 2026 no se ha anunciado ninguna fecha mundial exacta ni ningún calendario adicional de países. Verificado

    Qué inferir: trata cualquier "1 de enero de 2027" o "principios de 2027" que leas en otro sitio como una predicción. Google no ha publicado ninguna.

¿El 30 de septiembre de 2026 es una fecha límite mundial?

No para la aplicación a nivel de dispositivo Android, y sí para la fecha límite de registro de paquetes de Google Play. Son dos reglas distintas que casualmente comparten fecha, y casi todos los artículos sobre este programa las mezclan. La regla de dispositivo arranca en cuatro países mediante siete tiendas. La regla de Play afecta a tu ficha de Play, y Google describe la consecuencia de incumplirla como retirada mundial de Google Play.

Los cuatro países y las siete tiendas

Google nombra las dos listas con precisión, así que no hay nada que interpretar. La primera etapa de aplicación cubre instalaciones de apps en estos cuatro países:

Y se aplica a las instalaciones mediante estas siete tiendas de apps participantes:

Las dos listas están tomadas del anuncio de Google del 18 de junio de 2026 y de su guía de verificación del 15 de julio de 2026, consultadas el 9 de agosto de 2026. Google puede añadir tiendas o regiones, así que vuelve a revisar la fuente antes de actuar sobre esta lista cerca de la fecha.

¿El 30 de septiembre te aplica? Resuelve tu propia vía

Responde dos preguntas y la herramienta de abajo aplica las dos capas a tu vía de distribución concreta. Es deliberadamente franca con los casos en los que la respuesta de Google es "todavía no", porque "todavía no" no es lo mismo que "nunca".

Cómo saber si ya estás verificado

Dos pantallas responden a toda la pregunta. Cuenta de desarrollador lleva tu identidad y los datos de la cuenta. La página Verificación de desarrolladores de Android lleva el estado de registro de cada app. Si solo abres la primera, puedes aprobar una auditoría que en realidad no has aprobado.

Los cuatro sitios donde puede aparecer un estado

Del estado a la acción, sin inventar etiquetas

Google publica dónde mirar y qué hacer. Lo que no publica es un glosario exhaustivo de etiquetas de estado de identidad de Play, así que este artículo no se inventa ninguno. La tabla de abajo está organizada por qué estás revisando y cómo se ve "hecho", que es justo la parte que Google sí documenta.

Navegación y definiciones de "hecho" tomadas de la ayuda de Play Console respuesta 16984799, de la guía de verificación de Play Console de Google y de la página de ayuda sobre los datos de la cuenta de desarrollador; la fila de la prueba cerrada, de la ayuda de Play Console respuesta 14151465. Todas consultadas el 9 de agosto de 2026. Las propias páginas de Google usan hoy dos redacciones distintas para la ruta de identidad, la navegación de Play Console cambia a menudo y aquí las etiquetas van en español mientras que tu Console puede mostrar un texto algo distinto: trata cada ruta como válida a esta fecha y no como permanente.

Qué significa exactamente "registrado automáticamente"

El registro automático trata de una relación muy concreta: el vínculo entre el nombre de paquete de una app y las credenciales de firma que demuestran quién la controla. Google dice que las apps elegibles que usan Play App Signing forman parte del proceso de registro automático, porque Google ya tiene la información de propiedad y de firma que necesita.

Si todos tus nombres de paquete se registraron automáticamente con éxito, Google dice que no hace falta ninguna acción de registro adicional para esas apps de Play. Esa frase hace exactamente el trabajo que dice y ni un gramo más.

Ese último punto merece una pausa. El registro va por paquete, así que una cuenta con seis apps puede estar hecha en cuatro sextos y no mostrar nada alarmante en ningún sitio salvo en la única página que las enumera. Google además presenta la verificación como una confirmación de quién es el desarrollador y la describe como separada del filtro de seguridad que se aplica al contenido de las apps, así que nada de esto dice si tu app cumple las políticas de Play.

Qué hacer cuando una app no se registró automáticamente

El registro manual tiene dos formas, y cuál te toca depende del nombre de paquete, no de ti. Para un nombre de paquete que Android nunca ha visto, aportas los datos del paquete y el certificado público de tu clave de firma. Para un nombre de paquete que ya tiene instalaciones, además demuestras que posees la clave privada correspondiente subiendo un APK que contenga un fragmento que te da Google. Solo el segundo caso necesita un APK de comprobación firmado, y ninguno de los dos necesita tu APK de producción real.

Primero, averigua en qué caso estás

Cinco filas, y hoy perteneces exactamente a una. Equivocarte aquí es el error más caro de esta sección, porque la ruta del APK de comprobación es trabajo de compilación y tres de estas filas no la necesitan en absoluto.

Separación de casos tomada de la ayuda de Play Console, "Registering Android package names" (respuesta 16761053), consultada el 13 de agosto de 2026. Verificado

A. Registrar un nombre de paquete nuevo

La ruta corta. Todo ocurre dentro de Play Console, nada se acerca a tu entorno de compilación y no hay ningún APK que producir.

1. 01

   Abre la página Verificación de desarrolladores de Android

   En Play Console, abre la página Verificación de desarrolladores de Android y revisa el estado de registro de cada nombre de paquete de la cuenta. La página de inicio de Play Console también puede mostrar información de registro de apps.

2. 02

   Elige Registrar nombre de paquete

   Esto inicia un registro nuevo en lugar de una reclamación sobre un nombre que ya existe.

3. 03

   Introduce el nombre de paquete y un nombre descriptivo

   El nombre descriptivo es una etiqueta interna para tu propia lista. No es lo que ven los usuarios en tu ficha de Store.

4. 04

   Elige Añadir clave

   Aquí empieza la asociación entre una clave de firma que controlas y el nombre de paquete que estás registrando.

5. 05

   Aporta el certificado público de firma

   Entrega el certificado público del par de claves de firma de tu app. Como Android nunca ha visto este nombre de paquete, el certificado es todo lo que Google necesita. Tu clave privada no sale nunca de tu equipo.

6. 06

   Envía y espera la confirmación

   Google envía un correo cuando el nombre de paquete queda registrado correctamente, y el estado actualizado se ve en Play Console.

B. Registrar un nombre de paquete existente

Es la ruta larga, y la que todos los artículos describen como si fuera la única. Se aplica cuando el nombre de paquete ya tiene instalaciones en Android, porque entonces Google no se fía de tu palabra: tienes que demostrar el control de la clave privada. Dos de estos pasos ocurren fuera de Play Console, así que ten abierto tu entorno de compilación antes de empezar.

1. 01

   Introduce los datos del paquete

   En la página Verificación de desarrolladores de Android, inicia el registro del nombre de paquete que reclamas.

2. 02

   Abre Seleccionar clave

   Google ofrece los certificados que considera elegibles para ese nombre de paquete, según las pruebas de instalación.

3. 03

   Elige una huella de certificado público elegible

   Coge la huella de la clave que realmente posees. Si no aparece nada elegible, párate aquí y lee las reglas de elegibilidad más abajo antes de intentar otra cosa.

4. 04

   Inicia el flujo de propiedad y copia el fragmento de Google

   Google genera un fragmento único para esta reclamación. Cópialo exactamente. Es el valor que demuestra que el APK que vas a compilar se hizo para este reto concreto.

5. 05

   Crea assets/adi-registration.properties

   Dentro de la carpeta assets de un proyecto de APK, crea un archivo llamado exactamente adi-registration.properties. La ruta y el nombre son literales. Una errata aquí es la forma más habitual de que este paso falle.

6. 06

   Pega el fragmento en ese archivo

   No hace falta nada más dentro. El archivo existe solo para llevar la cadena.

7. 07

   Compila un APK de versión

   Google dice que puedes compilarlo desde la aplicación real o desde un proyecto vacío que use el mismo nombre de paquete. El proyecto vacío suele ser más rápido y más seguro, porque no interviene nada de tu código de producción.

8. 08

   Fírmalo con la clave privada correspondiente

   Ese es todo el sentido del ejercicio. La prueba es la firma, no el contenido.

9. 09

   Súbelo a través de Play Console

   Sube el APK de comprobación firmado dentro del flujo de propiedad. No es una publicación, no llega a ningún usuario y tu artefacto de producción real se queda fuera.

10. 10

    Vigila el estado y el correo de confirmación

    Google envía un correo cuando el nombre de paquete queda registrado correctamente, y el estado actualizado se ve en Play Console.

C. Si tu clave de firma la tiene otra tienda de apps

Algunas tiendas firman en nombre del desarrollador, con lo que no puedes producir tú mismo un APK de comprobación correctamente firmado. Google documenta una ruta específica para eso, y es corta:

1. 01

   Compila la versión y súbela a esa tienda

   Pasa la compilación que lleva el fragmento por el proceso de publicación normal de esa plataforma.

2. 02

   Descarga de esa tienda el APK final firmado

   Necesitas el artefacto tal y como lo firmó la tienda, no el que subiste tú.

3. 03

   Sube ese APK firmado por la tienda a Play Console

   La firma de la tienda es lo que satisface la comprobación de propiedad.

Pasos del flujo tomados de la ayuda de Play Console, "Registering Android package names" (respuesta 16761053), consultada el 13 de agosto de 2026. Verificado

Añadir más claves después

Un nombre de paquete puede tener más de una clave de firma asociada. Google dice que la consola permite añadir y verificar varias claves de firma para un mismo paquete, y el procedimiento repite la ruta B: crear assets/adi-registration.properties con el fragmento de esa clave, compilar y firmar un APK de versión con la clave privada correspondiente, y subirlo. Registra primero el nombre de paquete y añade después las claves extra.

Si no te ofrece ninguna clave elegible: las reglas de prioridad

La mayoría de los desarrolladores no ve esto nunca. Importa cuando un nombre de paquete ha sido firmado por más de una clave a lo largo de su vida, o cuando más de una parte tiene una reclamación plausible sobre él. Google lo resuelve con una jerarquía basada en instalaciones.

Jerarquía de elegibilidad tomada de la ayuda de Play Console respuesta 16761053, consultada el 13 de agosto de 2026. Verificado

La lectura práctica, dicha con cuidado: si tu clave de firma cumple con claridad la jerarquía de arriba, debería aparecer como directamente elegible para la reclamación. Eso decide si Google te deja registrar directamente en lugar de pasar por una solicitud revisada. No completa el registro por ti. Un paquete que se quedó fuera del registro automático sigue teniendo que pasar por la ruta B a mano. El nivel de por orden de llegada es en el que hay que moverse rápido, porque se decide por quién actúa, no por quién tiene razón.

Qué tienen que enviar las cuentas personales de desarrollador

Dos capas: información universal y documentos por país. La parte universal es que tus datos de identidad legal y de dirección deben coincidir exactamente con el perfil de pagos de Google vinculado a la cuenta. La parte documental depende por completo del país o la región de ese perfil, y por eso ningún artículo honesto puede darte una única lista mundial.

La parte que es igual en todas partes

Las cuentas personales aportan información de identidad legal y de la cuenta, y la ayuda actual de Play menciona entre ellas el nombre legal y la dirección legal. El proceso de verificación usa el perfil de pagos de Google vinculado, y la página de requisitos de documentos de Google establece que los datos de identidad personal, el nombre de la organización cuando corresponda y la información de dirección deben coincidir exactamente con lo que hay en tu perfil de pagos.

Esa palabra "exactamente" sostiene toda esta sección, y es la razón de que exista la siguiente herramienta.

La parte que no es igual en todas partes

La propia página de Google dice que los documentos aceptados dependen de tu ubicación geográfica. El selector de país de esa página es la autoridad para tu caso, no ninguna lista reproducida en otro sitio. Para que la forma del requisito quede concreta sin fingir que es universal, esto es lo que la página de Estados Unidos de Google pide hoy a las personas físicas:

Los requisitos de imagen que Google dice sin rodeos

Se aplican a la identificación con foto y no dejan lugar a dudas, lo que los convierte en los fallos más baratos de eliminar antes de subir nada:

• La identificación oficial con foto debe estar vigente y no vencida.
• La imagen debe estar en color.
• La imagen debe ser nítida y estar bien iluminada.
• La imagen no debe ser una fotocopia.

Google también indica que su página actual de requisitos de documentos señala los documentos no admitidos como la razón principal de los fallos de verificación de desarrolladores, y que los documentos falsos o alterados pueden derivar en sanciones graves, incluida la eliminación de la cuenta y de las apps. Nada de esta página vale ese riesgo.

La revisión que hay que hacer antes de subir nada

Google no publica cuántos intentos de verificación tienes, y los desarrolladores cuentan una y otra vez que llegan a un punto donde el control para reintentar simplemente ya no está visible. Esa combinación hace que un envío descuidado salga caro de verdad. Haz primero esta auditoría.

El error que conviene revisar antes de subir nada

Si de este artículo te llevas una sola instrucción, que sea esta: abre tu perfil de pagos de Google y compara el nombre legal y la dirección con tus documentos, campo por campo, antes de tocar el botón de subir. Google exige que la información coincida; no publica una regla al nivel del carácter ni de la puntuación, así que toma el "campo por campo" como la forma práctica de cumplir el requisito y no como una regla en sí.

La primera mitad de eso es el requisito que Google enuncia. La segunda mitad es de lo que están llenos los foros de soporte de 2026. Los hilos de abril, junio, julio y agosto de 2026 siguen todos la misma forma: un desarrollador está seguro de que sus documentos son correctos, la verificación falla sin un motivo concreto y la respuesta de la comunidad apunta de vuelta a una diferencia entre la identidad enviada y el perfil de pagos. En varios de esos hilos el desarrollador descubrió el problema de nombre del perfil después de una apelación fallida.

Qué necesitan las cuentas de organización

Las organizaciones se verifican con datos legales de la empresa en vez de con una identidad personal y suelen necesitar un número D-U-N-S: un identificador único de nueve dígitos emitido por Dun and Bradstreet. La documentación de Play de Google recoge excepciones para ciertas entidades públicas. Google dice que quien no lo tenga puede obtenerlo gratis, pero avisa de que puede tardar semanas, lo que lo convierte en el único punto de esta página con un plazo real. Las propias páginas de Google se contradicen en cuánto: sus preguntas frecuentes de verificación de Android dicen hasta 28 días y la ayuda actual de la cuenta de Play Console dice hasta 30. Este artículo planifica con 30.

Qué más prepara una organización

• Datos legales de la organización que coincidan con tus registros mercantiles, además del representante autorizado y la información de la cuenta.
• El número D-U-N-S de nueve dígitos, gratuito en Dun and Bradstreet y sujeto a las excepciones que Google recoge para ciertas organizaciones públicas. Esas excepciones son estrechas: no significan que las organizaciones públicas se salten la verificación.
• Documentación pertinente de la organización y documentación de identidad del representante, con las mismas reglas por país y de coincidencia exacta que se aplican a las cuentas personales.
• Un sitio web verificado, si eres una organización con distribución completa fuera de Google Play. La guía de verificación de Google dice que las organizaciones aportan un sitio web que debe verificarse mediante Google Search Console. Ese paso pertenece a la vía de la Android Developer Console, no a Play Console.

Una cosa que una cuenta de organización no cambia: si además publicas en Google Play, esto sigue siendo trabajo de Play Console. Y si estás decidiendo entre personal y organización para una cuenta nueva, las compensaciones van mucho más allá de la verificación, una decisión que la comparación entre cuenta personal y cuenta de organización desarrolla como corresponde.

Qué pasa de verdad si no estás verificado el 30 de septiembre

Cuatro cosas distintas, según cómo llegue tu app a sus usuarios. Google documenta restricciones a la nueva instalación, a las actualizaciones donde rigen los controles, y la retirada de Google Play para los paquetes de Play sin registrar. No documenta desinstalar por la fuerza apps que ya están en los teléfonos de la gente.

Consecuencias tomadas de la ayuda de Play Console respuesta 16984799, la guía de verificación de Play Console de Google, la entrada de despliegue del 30 de marzo, la cronología de la ayuda de la Android Developer Console y las preguntas frecuentes del 22 de julio. Todas consultadas el 9 de agosto de 2026.

La afirmación con la que hay que tener más cuidado

Esa distinción no es puntillismo. Cambia lo que deberías hacer este mes. Una retirada de Play es una emergencia de distribución que se arregla registrando un paquete. Una hipotética desinstalación masiva sería una emergencia de relación con los clientes que exigiría una comunicación completamente distinta. Solo una de las dos está documentada.

Cómo funciona de verdad el flujo avanzado

Google documenta el flujo avanzado como un camino lento a propósito, no como un interruptor, y la fricción es justo el objetivo: cada paso existe para impedir que alguien te lo dicte por teléfono mientras la llamada sigue abierta.

1. 01

   Activa el modo de desarrollador en los ajustes del sistema

   Un primer movimiento deliberado, para que nada de esto se dispare por accidente ni con un atajo de un toque como los que se usan en estafas.

2. 02

   Confirma que nadie te está guiando

   Una comprobación rápida de que nadie te está presionando para desactivar una protección.

3. 03

   Reinicia el teléfono y vuelve a autenticarte

   Esto corta el acceso remoto o una llamada en curso que alguien pudiera estar usando para ver lo que haces después.

4. 04

   Vuelve tras el periodo de espera de protección

   Google lo describe como una espera de un día, una sola vez. Después confirmas con autenticación biométrica o el PIN del dispositivo.

5. 05

   Instala desde desarrolladores no verificados

   Puedes permitirlo siete días o de forma indefinida. El aviso sigue apareciendo en cada instalación y lo confirmas tú.

Pasos del flujo avanzado tomados de las preguntas frecuentes de verificación de desarrolladores de Android de Google, consultadas el 13 de agosto de 2026. Verificado

La cuestión del sideloading, en un párrafo

La fase del 30 de septiembre todavía no se aplica a la instalación directa de APK ni a tiendas de apps fuera de la lista participante de Google, y Google sigue admitiendo la instalación por ADB además de un flujo avanzado para los usuarios que eligen a sabiendas instalar desde desarrolladores sin verificar. Esa es la posición actual y documentada al 9 de agosto de 2026, y es muy distinta del relato de "Google acaba con el sideloading" que circuló tras el anuncio original de 2025. También es de forma explícita una primera fase, así que tomarla como un resultado cerrado sería el error simétrico. Si lo que te ha traído aquí son las implicaciones para el sideloading y el ecosistema abierto y no una fecha límite de Play, eso merece un tratamiento propio y no un párrafo dentro de un artículo de cumplimiento.

La verificación no sustituye la prueba cerrada de 12 testers

Son dos requisitos sin relación entre sí que hay que cumplir los dos cuando los dos te aplican. La verificación de desarrolladores de Android responde a "¿de quién son esta cuenta y este paquete?" La regla de acceso a producción responde a "¿ha probado esta app gente real?" Puedes superar una a la perfección y seguir completamente bloqueado por la otra.

El requisito de Google para las cuentas personales nuevas que entran en él no cambia por nada del programa de verificación: al menos 12 testers que hayan aceptado participar de forma continua en una prueba cerrada durante los 14 días previos al momento en que solicitas el acceso a producción. En la documentación oficial de Google en español para Latinoamérica, a esos testers se les llama verificadores.

Las columnas de verificación proceden de la guía de verificación de Google y de la ayuda de Play Console respuesta 16984799; las columnas de prueba cerrada, de la ayuda de Play Console respuesta 14151465 y de la página de ayuda sobre la prueba interna. Todas consultadas el 9 de agosto de 2026. Verificado

Por qué esto pilla a la gente

Porque las dos se llaman "requisitos", las dos viven en Play Console y las dos se interponen entre un desarrollador y una app publicada. Así que una cuenta que acaba de superar la verificación de identidad se siente terminada. Después se le niega el acceso a producción y nada en las pantallas de verificación explica por qué, porque esa respuesta no vive ahí.

La secuencia que de verdad pone en marcha una cuenta personal nueva es: identidad verificada, cada paquete registrado y, por separado, una prueba cerrada con al menos 12 testers que hayan aceptado participar de forma continua durante 14 días antes de solicitar el acceso a producción. La regla de los 14 días consecutivos tiene más casos límite de los que espera la mayoría, y es la parte de esta secuencia que no se puede comprimir trabajando más.

¿Cuenta la prueba interna en su lugar?

No, y merece la pena ser preciso con el porqué, porque "la prueba interna no sirve para nada" también es falso. Google permite la prueba interna con hasta 100 testers, y es una manera realmente buena de detectar problemas rápido. Pero el requisito de acceso a producción nombra específicamente una prueba cerrada que cumpla la condición de 12 testers y 14 días. La prueba interna es un canal de pruebas aparte (un "segmento de pruebas" en la documentación de Google para Latinoamérica), así que participar ahí no es la prueba válida para este requisito concreto.

Las cuentas de organización también merecen una frase aclaratoria aquí: el requisito de pruebas para el acceso a producción está escrito expresamente para cuentas personales nuevas de desarrollador, así que las cuentas de organización no son la clase de cuenta que cubre esta regla concreta de los 12 testers. Esa es una cuestión distinta de la verificación, que sí alcanza a los dos tipos de cuenta.

Si la verificación falló, revisa esto antes de volver a intentarlo

Los desarrolladores reportan a menudo mensajes de rechazo poco concretos, y Google no documenta la causa de cada rechazo individual. Así que el movimiento útil no es adivinar el mensaje sino repasar los requisitos que Google sí publica. Elige abajo el síntoma que estás viendo. Cada uno lleva a lo primero que hay que revisar, a lo sólida que es la evidencia detrás de ese consejo y a la siguiente acción segura.

Empieza por el síntoma que de verdad puedes ver

Las diez entradas de abajo están redactadas como las redactan los desarrolladores en los foros de soporte de Google, incluidas las escritas a las dos de la madrugada. Seleccionar una te da la revisión más valiosa para ese síntoma en vez de una lista de todo lo que teóricamente podría estar mal.

Qué respalda la evidencia y qué no

Los patrones de fallo de abajo salen de hilos de la comunidad de ayuda para desarrolladores de Google Play a lo largo de 2026, incluidos casos de Brasil, India, Uzbekistán y varios hilos en portugués, además de reportes más antiguos de Reddit y Stack Overflow. Están agrupados por lo sólida que es la evidencia de verdad, porque eso cambia lo que deberías hacer con ellos.

La lista previa a la fecha límite

Cinco estados deciden si el 30 de septiembre es una fecha en tu calendario o un problema en tu bandeja de entrada. Cuatro aplican a todo desarrollador de Play. El quinto solo aplica si tu cuenta está sujeta a la regla de la prueba cerrada, y es el que consume tiempo de calendario real.

Los cuatro puntos que hay que resolver

Márcalos con honestidad y no con optimismo. Cada fila enlaza con la sección que la resuelve, así que una casilla sin marcar es un desvío de dos minutos y no un callejón sin salida. Dos de ellos son condicionales, así que están redactados para poder marcarse cuando nunca te aplicaron: quien tuvo todas sus apps registradas automáticamente no tiene ninguna reclamación manual que cerrar, y quien ya estaba verificado y nunca recibió una consulta sobre documentos no tiene nada que corregir.

Dónde encaja PrimeTestLab y dónde no

Primero el límite, dicho claro: nadie puede verificar tu identidad por ti. Subir tus documentos, cuadrar tu perfil de pagos y reclamar tus nombres de paquete son cosas que solo puede hacer el titular de la cuenta, y este artículo es toda nuestra aportación a eso. Lo que sí cubrimos es el requisito que llega justo después de la verificación para una cuenta personal nueva: los 12 testers reales, participando 14 días seguidos.

Ese es el reparto que llega a nuestra bandeja de entrada siempre con la misma forma. Un desarrollador supera la verificación de identidad, ve un estado verde en Play Console, da por hecho que el camino está abierto y luego descubre que el acceso a producción es una puerta completamente aparte con un suelo de dos semanas colgando de ella. La verificación es papeleo, y lo que tarde depende de tus documentos y de tu cuenta. La prueba cerrada es tiempo de calendario que no puedes comprimir.

Llevar la prueba cerrada tú mismo o delegarla

El orden que cuesta menos tiempo

Si tienes por delante la verificación y la prueba cerrada, llévalas en paralelo y no en secuencia. Los 14 días de participación continua de los testers son tiempo real que solo arranca cuando ya tienes 12 personas inscritas, así que es el punto que decide tu fecha de lanzamiento de verdad. Pon en marcha ese reloj mientras te peleas con los documentos, no después.

Preguntas frecuentes

Conclusión

Última revisión de políticas: 13 de agosto de 2026. El despliegue del 30 de septiembre de Google y su ampliación de 2027 siguen evolucionando, así que las fechas y la cobertura por países deberían volver a comprobarse en la página de verificación de desarrolladores de Android de Google antes de actuar sobre ellas. Este artículo está programado para una nueva verificación el 30 de septiembre de 2026 y justo después de que empiece la aplicación, y otra vez cada vez que Google publique cualquier geografía o fecha de 2027.