Cómo crear una cuenta de desarrollador de Google Play en 2026

La prueba de 14 días es la única parte de esta lista que depende de otras personas, y es donde se atascan los desarrolladores en solitario. Es la parte que hace por ti PrimeTestLab, y se explica en cómo ayudamos, al final de este artículo.

La mayoría de las guías para esta búsqueda se detienen en la confirmación del pago, y casi todas eran correctas cuando se escribieron. El problema es lo que Google añadió después: una verificación de identidad que compara tus documentos con un perfil de pagos que quizá no miras desde hace años, una tarea de verificación de dispositivo para las cuentas Personales nuevas y un requisito de producción al que te arrastra la fecha en la que creaste la cuenta y que luego tienes que cumplir app por app. El resultado es una secuencia conocida de mensajes en los foros, y todos empiezan igual: pagué los 25 dólares, ¿por qué no puedo publicar nada?

Este artículo está escrito en el orden en que las decisiones aprietan de verdad: qué tener listo antes de pagar, qué debe aportar cada tipo de cuenta, qué te pide la consola y en qué orden, qué datos deben coincidir con qué registro y qué le debe a Google una cuenta Personal nueva cuando ya tiene el recibo. Donde Google publica una cifra, se cita junto con la respuesta de ayuda de la que sale. Donde Google no publica nada, aquí lo decimos, en vez de tomar prestado un número de la página de un proveedor que tampoco lo sabe. Todo lo que aparece aquí se contrastó con la documentación del propio Google y está actualizado a 13 de agosto de 2026.

Qué preparar antes de pagarle a Google

El pago de $25 se vive como el momento del compromiso porque es el único paso que toca tu cuenta bancaria. Es lo que menos debería preocuparte. Los pasos realmente difíciles de deshacer son los que no cuestan nada: la Cuenta de Google con la que estés conectado pasa a ser la propietaria de la cuenta y, aunque Google ya documenta una vía restringida para entregarle la propiedad a otra persona, no está disponible para todas las cuentas y no es un interruptor de configuración. La identidad legal que escribas se convierte en aquello con lo que se compara cada documento que subas después, y una parte de ella se publica en Google Play. Ninguna de las dos cosas te pide que confirmes que estás seguro.

Sobre la tarifa en sí, este artículo dice una cosa y sigue: son 25 USD, cobrados una vez por cuenta de desarrollador, no una membresía anual y no por app. El desglose completo de lo que cubre y lo que no cubre esa tarifa está en el artículo sobre los requisitos para publicar en Google Play.

Qué mostrará Google públicamente

Esta es la parte de la decisión que se salta todo el mundo, y es a la que la gente vuelve arrepentida. Parte de lo que escribes en el formulario de registro se muestra en tu ficha de Google Play para que lo lea cualquiera. Una cuenta Personal no es una cuenta anónima y, si monetizas, se publica todavía más.

Desplaza la tabla hacia los lados para ver todas las columnas

La lista previa al registro

La lista de abajo son los requisitos de Google reordenados por cuándo los necesitas y no por la página de ayuda en la que viven, y está dividida en tres etapas a propósito. La etapa 01 es lo que pide el formulario de registro, y es la única etapa que puntúa el veredicto. Las etapas 02 y 03 son requisitos reales que llegan después que tu dinero, y una lista que los mezcla todos en una sola puntuación te dice que no puedes registrarte hasta tener 12 testers, lo cual es sencillamente falso. Dos filas llevan tiempo de espera real, y las dos son filas de organización, que es la razón práctica por la que un registro de organización nunca debería empezarse el mismo día en que se decide.

Inspector de preparación antes de pagar

Las tres decisiones difíciles de deshacer

Todo lo demás de esa lista se puede corregir con un formulario. Estas tres no, o no sin pagarlo caro.

Nada de esto hace segura la aprobación. Lo que hace es eliminar los fallos que Google documenta de verdad, que es algo distinto y más útil. Lo que no puede eliminar es la espera: Google publica tiempos precisos para las partes acotadas del proceso y nada en absoluto para la revisión de identidad en su conjunto, algo que se trata más abajo en la sección de verificación.

Personal u Organización al registrarte

Lo primero que hay que saber es que esto no es un sistema de niveles. Google dice que los dos tipos de cuenta tienen acceso a la misma funcionalidad general, y las dos pueden monetizar a través de un perfil de pagos. Nadie compra una Play Console mejor por registrar una organización. Lo que cambia es lo que tienes que aportar para entrar y las obligaciones que te siguen después.

Cuatro categorías en las que Google elige por ti

Google nombra cuatro clases de app cuyos desarrolladores deberían usar una cuenta de Organización, con independencia de cómo se vea a sí mismo el desarrollador:

Si tu app está en uno de esos grupos, la pregunta del tipo de cuenta ya está respondida y el plazo del D-U-N-S pasa a formar parte de tu calendario de desarrollo en lugar de ser una idea de última hora.

Qué tiene que aportar cada tipo

Esta tabla trata solo del mostrador de registro: qué le pide Google a cada tipo y qué arrastra cada tipo después. Si vale la pena constituir una empresa para tener una cuenta de Organización es otra pregunta, con otra respuesta para casi todo el mundo, y se trata como es debido en cuentas Personales frente a cuentas de Organización.

Desplaza la tabla hacia los lados para ver todas las columnas

¿Puedes cambiar el tipo de cuenta después?

Este es el dato que con más probabilidad está mal en lo demás que hayas leído. Durante años el consejo habitual fue que el tipo de cuenta se elige una vez y para siempre, y que un desarrollador que se constituía como empresa después tenía que registrar una segunda cuenta desde cero. La documentación actual de Google no dice eso. Describe una ruta de conversión y distingue con claridad entre la dirección que admite y la que no.

Qué implica realmente la conversión

El mecanismo es un cambio de perfil de pagos y no un interruptor de Play Console, y por eso pasa desapercibido en la documentación. Creas un perfil de pagos de Google de tipo organización o cambias a uno, completas la verificación que ese perfil exige, que en una organización significa el número D-U-N-S y la documentación de la organización, y lo vinculas a la cuenta de desarrollador. El plazo del D-U-N-S se aplica aquí igual que en el registro, así que convertir la cuenta tampoco es una operación del mismo día.

Y el propietario, que antes era el dato permanente

Esta es la afirmación que más conviene actualizar en tu cabeza, porque fue cierta durante mucho tiempo y se repite en todas partes, incluidas versiones anteriores de este artículo. Google ya documenta una transferencia de propietario en autoservicio. Solo el propietario actual de la cuenta puede iniciarla, y la ruta es Play Console, Users and permissions, buscar a la persona a la que quieres entregar la cuenta, Manage y luego Make account owner. La transferencia queda entonces retenida siete días antes de completarse, y al futuro propietario se le puede pedir que verifique su identidad y aporte la información de su perfil de pagos.

Donde sigue apretando es en la elegibilidad. Google limita el proceso directo a las cuentas de Organización y a las cuentas Personales que no monetizan, y dice que los desarrolladores individuales que monetizan sus apps no son elegibles por ahora. Así que el desarrollador con más probabilidades de querer esto, el que publica en solitario, se registró a título personal, empezó a generar ingresos y ahora quiere que la cuenta la tenga la empresa, es justo el que queda fuera. Su ruta no cambia: una cuenta de desarrollador nueva, verificada desde cero, con las apps transferidas a ella.

Una advertencia más en la misma línea: elegir un tipo de organización al que no tienes derecho no es un atajo de papeleo. Una cuenta de Organización se verifica contra un registro empresarial real que mantiene un tercero, y falsear eso es un problema de políticas, no una jugada astuta.

Registro en Play Console, paso a paso

El registro se abre en play.google.com/console/signup. Antes de hacer clic, fíjate bien con qué Cuenta de Google tienes iniciada la sesión en el navegador, porque esa es la decisión que el flujo nunca te va a pedir que reconsideres.

Los ocho puntos de control

1. 01
   Inicia sesión con la Cuenta de Google que será propietaria de la cuenta

   El propietario tiene que tener al menos 18 años. La propiedad se puede entregar después, pero solo en los casos que Google documenta: cuentas de Organización y cuentas Personales que no monetizan, iniciada por el propietario actual, retenida siete días y con verificación del propietario entrante. Una cuenta Personal que monetiza queda por ahora fuera de ese proceso, así que para muchos desarrolladores la cuenta con la que casualmente estén conectados sigue siendo, en la práctica, la definitiva. Google pide una Cuenta de Google y no dice que tenga que ser una dirección de gmail.com, digan lo que digan los tutoriales.

   Falla cuando: tienes iniciada la sesión en un perfil personal del navegador y registras ahí la cuenta de la empresa.

2. 02
   Elige Personal u Organización

   Personal es la opción de Google para uso personal, incluidos estudiantes, aficionados y desarrolladores amateur. Organización es para empresas y organizaciones. Google dirige cuatro categorías de apps a las cuentas de Organización: productos y servicios financieros, apps de salud, incluidas las médicas y las de investigación con personas, apps aprobadas para usar VpnService y apps gubernamentales.

   Falla cuando: se empieza un registro de organización antes de que exista el número D-U-N-S.

3. 03
   Crea o selecciona un perfil de pagos de Google del tipo que corresponda

   El registro se vincula a un perfil de pagos de Google, y el tipo de perfil tiene que coincidir con el tipo de cuenta que elegiste. Un perfil personal existente no puede sostener un registro de organización. La identidad guardada en ese perfil es la referencia con la que se compara cada documento que subas después, así que ábrelo y léelo antes de seguir.

   Falla cuando: un perfil de pagos antiguo conserva una dirección de la que te mudaste hace años.

4. 04
   Introduce tus datos legales, de contacto y de desarrollador público

   Escribe el nombre legal y la dirección exactamente como los imprime tu documento de identidad. Aportas un correo y un teléfono de contacto que Google usa para localizarte, que se verifican pero no se muestran públicamente, y un correo de desarrollador público que sí se muestra en Google Play. Las cuentas de Organización aportan además un teléfono de desarrollador público. Los números de teléfono van en formato internacional.

   Falla cuando: el correo de desarrollador público es una dirección personal que preferirías no publicar.

5. 05
   Acepta el acuerdo y paga 25 USD, una sola vez

   Aceptas el Acuerdo de Distribución para Desarrolladores de Google Play y pagas la tarifa de registro única. Se cobra por cuenta de desarrollador, no por app, y no se renueva cada año. La página de pagos aceptados de Google enumera las redes de tarjetas que admite, con diferencias por región, e indica que las tarjetas prepago no se aceptan.

   Falla cuando: se paga la tarifa con datos de identidad supuestos en vez de comprobados. Google advierte que, si la información de identidad no es válida, la tarifa puede no reembolsarse.

6. 06
   Verifica tu correo y tu teléfono de contacto

   Google envía un código de seis dígitos al correo y otro código de seis dígitos al teléfono por SMS o llamada de voz. Son los datos de contacto privados, los que Google usa para localizarte, no los que aparecen en tu ficha de Play Store.

   Falla cuando: el SMS no llega. La respuesta documentada de Google es la opción de llamada de voz y luego comprobar la cobertura y el operador, no crear una cuenta nueva.

7. 07
   Completa la verificación de identidad

   A una cuenta Personal se le puede pedir un documento oficial de identidad si el perfil de pagos vinculado no está ya verificado. A una cuenta de Organización se le pueden pedir el número D-U-N-S, un documento oficial de la organización y el documento de identidad de un representante, y las cuentas de Organización creadas recientemente tienen un requisito adicional de verificación del sitio web. Todo lo que envíes tiene que coincidir con el perfil de pagos.

   Falla cuando: el documento y el perfil difieren en una línea. Google señala esa coincidencia como requisito, y es el fallo que llena más hilos de la Comunidad de Ayuda sobre este tema.

8. 08
   Verifica un dispositivo Android real, en una cuenta Personal nueva

   Las cuentas Personales nuevas completan una comprobación de dispositivo en la app móvil de Play Console antes de que una app pueda estar disponible en Google Play. Google exige un dispositivo físico, sin root y con Android 10 o posterior, y dice que la comprobación en sí tarda menos de un minuto.

   Falla cuando: desarrollas siempre en un emulador y no tienes ningún teléfono que sirva. Google permite que el mismo dispositivo verifique más de una cuenta, así que pedir uno prestado es una opción documentada.

Qué viene después del octavo punto de control

Esos ocho terminan la cuenta. No terminan el camino hasta una app publicada, y conviene ser preciso con el orden de lo que sigue, porque muchas páginas dan a entender que la prueba de 12 testers es algo que debes saldar antes de que se te permita crear una app. Es justo al revés. Primero creas la app, completas su configuración, su ficha de Play Store y sus declaraciones, subes un build y publicas una versión en un canal cerrado, porque la prueba que califica corre sobre esa versión. Solo entonces arranca el contador de 14 días. Cuando termina, quedas en condiciones de solicitar el acceso a producción, Google revisa la solicitud y la versión de producción sale después de que se conceda ese acceso.

Hay una salvedad de orden, y es la diferencia entre preparar una prueba y ejecutarla. La verificación de la cuenta sigue bloqueando la publicación en sí: Google dice que una cuenta de desarrollador tiene que estar verificada antes de poder enviar apps a revisión, y en una cuenta Personal nueva hay que completar la comprobación del dispositivo real antes de que una app pueda estar disponible en Google Play. Así que crear la app, configurarla y escribir la ficha de Play Store son cosas que puedes hacer mientras la revisión de identidad sigue en marcha. Publicar la versión en canal cerrado sobre la que corre el contador de 14 días, no. Planifica con el solapamiento que realmente tienes, que es preparación, no días de prueba transcurridos. Verificado

Hay dos afirmaciones que te encontrarás por ahí y que conviene nombrar para que puedas descartarlas de un vistazo. La primera es que el registro exige una dirección terminada en @gmail.com: la página de registro de Google pide una Cuenta de Google, que se puede crear con una dirección que ya tengas. La segunda es que Google “suele activar” una cuenta de desarrollador en un plazo de 24 a 48 horas. Ese compromiso no aparece en ninguna parte de la documentación actual de Google, y montar un plan de lanzamiento sobre él es la forma de acabar retrasando en público una fecha de salida. Sin plazo publicado

Documentos, reglas de coincidencia y las demoras que nadie publica

La verificación es el punto en el que el proceso deja de ser un formulario y pasa a ser una comparación. Google no lee tu documento para saber quién eres. Está contrastando tu documento con un registro que ya tiene y, cuando hay una organización de por medio, con un segundo registro que guarda Dun and Bradstreet. Google enuncia el requisito con claridad: lo que envíes debe coincidir con la información de tu perfil de pagos vinculado. En los hilos de la Comunidad de Ayuda revisados para este artículo, los rechazos con una causa diagnosticable se reducían a que esos registros no coincidían en un nombre, en una dirección o en una sola línea de la dirección que faltaba.

Qué se le pide a cada tipo de cuenta

Desplaza la tabla hacia los lados para ver todas las columnas

La regla de coincidencia exacta, antes de subir nada

La regla es fácil de enunciar y fácil de incumplir: la identidad legal del documento, la identidad del perfil de pagos de Google vinculado y, en una organización, la identidad del registro de Dun and Bradstreet tienen que coincidir. No parecerse lo bastante como para reconocer a la misma persona. Coincidir. Un segundo nombre que falta, una calle abreviada en un lado y escrita entera en el otro, un número de apartamento que está en el documento pero nunca llegó al perfil, un acento que se cayó porque un formulario no lo aceptaba: cada una de esas cosas basta para que te devuelvan el documento.

La herramienta de abajo es una comparación de texto, no una comprobación de aprobación ni un modelo de la revisión de Google. Google publica el requisito de que los registros coincidan; no publica la comparación que ejecuta en realidad, ni cómo trata las abreviaturas o la puntuación, ni cómo translitera, ni qué más valora. Así que esto lee las dos cadenas que le des y te dice la diferencia que alcanza a ver. Todo lo que te cuenta es sobre tu propio texto.

Comprobador de coherencia del perfil

Lo que Google cronometra y lo que deja abierto

Aquí es donde las páginas de la competencia se inventan cifras. Varios de los tutoriales mejor posicionados hoy hablan de una revisión de identidad de “unas horas a dos días hábiles” o de una cuenta “activada normalmente en 24 o 48 horas”. Ninguna de esas cifras aparece en la documentación actual de Google. Lo que Google sí publica es mucho más acotado, y mucho más útil, porque cada cifra publicada se refiere a una acción concreta y no al proceso entero.

Desplaza la tabla hacia los lados para ver todas las columnas

La comprobación del dispositivo Android

Esta comprobación toma por sorpresa a un grupo concreto y cada vez más numeroso: quienes desarrollan en un emulador, en un equipo de la empresa o en un dispositivo rooteado precisamente porque son la clase de persona que desarrolla apps de Android. No hay ruta desde el escritorio. La comprobación se hace en la app móvil de Play Console, sobre hardware real.

Aquí el momento importa de una forma muy concreta: esto es un requisito para poner una app a disposición del público, no para crear la cuenta. Puedes registrarte, verificar tu identidad y compilar la app sin él, y descubrirlo en el momento menos oportuno. Cuesta un minuto si tienes el hardware y cuesta una semana si tienes que buscarlo, y ese es todo el argumento para hacerlo el primer día.

Qué hereda una cuenta Personal nueva

Esta es la parte que sorprende a la gente, y sorprende porque funciona en dos niveles a la vez. Que la regla te afecte siquiera lo decide tu cuenta: personal y creada después de la fecha de corte. Pero lo que tienes que hacer en la práctica lo decide la app, porque Google lo formula así: debes realizar una prueba cerrada para tu app, y la solicitud de acceso a producción pregunta después por esa app, por la prueba que hiciste para ella y por si está lista. Así que puedes construir la app primero, hacerlo todo bien, superar la revisión y aun así encontrarte con que producción no está disponible, porque la obligación llegó con la cuenta y hay que saldarla en la app. La fecha de corte está vigente desde el 13 de noviembre de 2023, hace 1.027 días, así que a menos que trabajes con una cuenta de desarrollador que abriste hace años, te aplica.

Cómo llegó la regla a los 12

Circulan dos cifras, y solo una está vigente. Si estás leyendo una página que dice 20 testers, estás leyendo una página escrita antes de diciembre de 2024 o una que copió de ella.

1. 13 nov 2023
   La fecha de corte

   Las cuentas de desarrollador Personales creadas después de esta fecha entran en los requisitos de pruebas. La fecha sigue en la página de políticas actual de Google, sin cambios.

2. Finales de 2023
   Empezó con 20 testers

   El requisito arrancó con un mínimo de 20 testers durante 14 días. La propia documentación comunitaria de Google recoge la cifra original, junto con hilos de la Comunidad de Ayuda de aquella época. Histórico

3. 11 dic 2024
   Reducido a 12 testers

   Google anunció la reducción en una publicación de la Play Developer Community titulada «Reduced testing requirements for Personal developer accounts». La duración de dos semanas se mantuvo. Contexto: por qué Google pasó de 20 testers a 12.

4. 13 ago 2026
   Regla vigente: 12 testers, 14 días continuos

   Al menos 12 testers que hayan aceptado participar de forma continua durante al menos los últimos 14 días, antes de que una cuenta Personal afectada pueda solicitar el acceso a producción. Qué significa eso en el día a día se explica en la regla de los 14 días consecutivos.

Por qué los demás canales no cuentan

Un intento habitual de esquivar esto es usar un canal más fácil de llenar. No funciona, y la razón está en la redacción: la política pide expresamente una prueba cerrada.

Desplaza la tabla hacia los lados para ver todas las columnas

La comparación completa de los tres canales de pruebas (segmento de pruebas, en la consola en español latinoamericano), incluido cuándo cada uno es de verdad la herramienta adecuada, está en prueba interna, cerrada o abierta. Lo que importa en el momento de crear la cuenta es más acotado: solo el canal cerrado cumple el requisito, y exige un mínimo de dos semanas de calendario real que no se pueden comprimir.

Lo que te cuesta de verdad una baja

La versión que más se repite de esta regla es que basta con bajar una vez de 12 para romper la ventana y tener que empezar de cero. No es lo que dice la condición de Google, y la diferencia vale dinero de verdad en semanas perdidas.

La comprobación se hace en el momento en que solicitas: entonces debe haber al menos 12 testers que hayan aceptado participar, y cada uno de esos 12 debe llevar los últimos 14 días participando de forma continua. Google es explícito en que los testers que aceptan participar, prueban menos de 14 días, se dan de baja y luego vuelven a darse de alta no cuentan, porque los 14 días tienen que ser consecutivos. Leído en conjunto, eso produce tres consecuencias que la mayoría de las páginas cuentan mal:

• Tener más de 12 es un colchón, no vanidad. Si califican 15 testers y uno se va, siguen calificando 14 y no se retrasa nada. Solo cuando hay menos de 12 capaces de acreditar cada uno los 14 días completos e ininterrumpidos tienes que esperar.
• Un sustituto empieza desde cero. El tester nuevo no hereda los días que completó quien se fue. Sus propios 14 días consecutivos empiezan el día en que acepta participar.
• Los testers que se quedaron conservan su historial. Que una persona se vaya no reinicia el contador de nadie más, y eso es lo que peor cuenta la versión de que “vuelve a empezar de cero”.

Qué pasa cuando se cumplen los 14 días

Pasas a estar en condiciones de solicitarlo. Google te pregunta entonces por la prueba que hiciste: cómo interactuaron los testers con la app, qué comentarios recogiste, qué cambiaste como consecuencia, para quién es la app y por qué está lista. Es una solicitud escrita con una revisión humana detrás, no un contador que salta a medianoche del día catorce. Las preguntas en sí, y cómo responderlas sin rellenar, se explican en el artículo sobre el cuestionario de acceso a producción.

Una nota sobre la participación de los testers, porque aquí es donde se multiplican las reglas inventadas. El umbral medible es la participación continua: 12 testers participando durante 14 días ininterrumpidos. Google no publica ninguna cuota de uso diario en la página de políticas actual, y cualquier página que te diga que cada tester debe abrir la app un número determinado de minutos al día está describiendo algo que Google no ha escrito. La participación se valora aparte, a través de lo que cuentas en la solicitud, y no como un umbral numérico añadido al recuento. Verificado

Sobre de dónde salen los testers, cuidado también con la versión rotunda de esto. El requisito publicado de Google no prescribe una única fuente de reclutamiento, y sus propias indicaciones apuntan primero a las redes personales y profesionales, nombrando a amigos, familia, colegas y compañeros de clase, y después a las comunidades donde ya están tus posibles usuarios. Eso es orientación, no una lista cerrada, así que un proveedor de pruebas legítimo no queda excluido por ella. Lo que no es, es un “a Google le da igual quiénes sean tus testers” sin matices: Google pide un grupo diverso y representativo y espera participación y comentarios genuinos, y manipular instalaciones, calificaciones o reseñas es un problema de políticas venga de donde venga la gente. Verificado

Fallos en el registro y cómo resolverlos

Diez síntomas, con la solución documentada para cada uno

Las situaciones de abajo son aquellas para las que Google publica soluciones, formuladas como las describen los desarrolladores en la Comunidad de Ayuda y no como las etiquetan las páginas de políticas. Si tu síntoma no está aquí, eso también es información útil: suele significar que la respuesta no está documentada, y el siguiente paso honesto es el soporte de Play Console y no una conjetura de foro.

Localizador de bloqueos

Cuando la respuesta no está en esa lista

Hay un patrón en los hilos de la Comunidad de Ayuda de 2026 que ninguna lista de soluciones puede resolver: desarrolladores que describen un bloqueo de verificación, en el que la cuenta no consigue verificarse y los tickets de soporte se cierran sin una respuesta de fondo. Esos casos son reales y salen con la frecuencia suficiente como para mencionarlos con honestidad, pero también se autoseleccionan, porque quien completa la verificación con normalidad no escribe sobre ello. Nada de este artículo puede prometerte una salida de ese bucle. Lo que sí puede es mantenerte fuera de los bucles que tienen causas documentadas, que son la mayoría. Reportado por la comunidad

Una última distinción que conviene tener presente, porque provoca toda una categoría de pánicos mal dirigidos: la verificación de identidad de tu cuenta de desarrollador no es lo mismo que el programa de verificación de desarrolladores de Android para todo el ecosistema, que tiene su propio calendario de 2026. Este artículo trata de completar la verificación en Play Console. El otro programa, y lo que significa para las instalaciones fuera de Google Play, se explica en el artículo sobre la verificación de desarrolladores de Android.

Requisitos clave de 2026 que pueden bloquear tu primer lanzamiento

La creación de la cuenta y los requisitos de la app son sistemas distintos, y es fácil terminar uno mientras incumples el otro sin darte cuenta. Puedes tener una cuenta de desarrollador perfectamente verificada y aun así no poder publicar, porque el build en sí no cumple algún requisito vigente. Las filas de abajo son las que alcanzan a una cuenta recién creada; cuáles te aplican depende de lo que haga tu app.

• 31 ago 2026
  Las apps nuevas y las actualizaciones deben apuntar a Android 16 (API 36)

  Se aplica a los envíos para teléfonos, tanto apps nuevas como actualizaciones de las existentes. Otros formatos de dispositivo tienen sus propios niveles. El desglose completo por tipo de dispositivo está en el artículo sobre el nivel de API objetivo.

  En vigor
• 31 ago 2026
  Las apps que usan Google Play Billing deben estar en Billing Library 8 o posterior

  El calendario de baja de Google fija en esta fecha el plazo de Play Billing Library 7 para apps nuevas y actualizaciones, con una prórroga que termina el 1 de noviembre de 2026. Solo alcanza a los APK que requieren el permiso com.android.vending.BILLING, así que si tu primera app no tiene compras dentro de la app ni suscripciones, no te aplica. Si las tiene, es una dependencia del build que conviene descubrir ahora y no en el momento del envío.

  En vigor
• 30 sep 2026
  Registro del nombre de paquete en Play

  Todos los paquetes de Play tienen que estar registrados, pero las apps nuevas creadas en Play Console suelen registrarse de forma automática, así que normalmente esto es un estado que confirmar y no una tarea que hacer. Confírmalo en lugar de darlo por hecho. Es algo distinto del programa de verificación de desarrolladores de Android para todo el ecosistema, que se explica en el artículo sobre la verificación de desarrolladores de Android.

  Normalmente automático
• 1 nov 2026
  Fin de la ventana de prórroga para quienes cumplan los requisitos

  El mismo final se aplica a los dos requisitos del 31 de agosto: la migración del nivel de API objetivo y el de Play Billing Library. Las prórrogas se solicitan, no son automáticas, y se gestionan a través del estado de políticas y las notificaciones de Play Console. Si estás registrando una cuenta ahora, da por hecho que compilas para el requisito vigente y no para una prórroga.

  Si se concede
• Condicional
  Permisos de Contactos, solo si tu app lee los contactos

  La nueva política de permisos de Contactos de Google regula el acceso amplio a los contactos del usuario en las apps que apuntan a Android 17 (API 37) o posterior. Las dos superficies de Google dan ahora la misma fecha de entrada en vigor, 27 de enero de 2027: la tabla de plazos de Play Console y la página de políticas de Android Developers coinciden, y ambas se volvieron a consultar el 14 de agosto de 2026. Comunicaciones anteriores de Google difundieron la fecha del 28 de octubre de 2026 para esta política; esa fecha ha quedado sustituida. El registro completo con todas las fechas está en el artículo sobre las actualizaciones de políticas de 2026. Verificado

  La mayoría de las apps: ignóralo

Esas son las fechas de 2026 con más probabilidades de alcanzar a una cuenta recién creada, y este artículo se detiene ahí a propósito, para no convertirse en un calendario de políticas. No significa que nada más del calendario pueda afectarte: a lo largo del año llegan políticas específicas de categorías, y cuáles tocan a tu app depende por completo de lo que haga tu app. Si quieres el registro completo con todas las fechas, para eso está el artículo sobre las actualizaciones de políticas, y es la página que hay que revisar antes de compilar, no después.

Cómo ayuda PrimeTestLab

Vuelve a mirar la lista de preparación del principio de este artículo. Todo lo que hay en ella puedes resolverlo tú solo, a tu ritmo, con una excepción. El documento de identidad, el perfil de pagos, los códigos, la comprobación del dispositivo: todo es trabajo en solitario. Encontrar a 12 personas que instalen una app sin terminar, acepten participar con la cuenta de Google correcta y sigan participando durante dos semanas sin desaparecer no es trabajo en solitario, y es la razón por la que un requisito de dos semanas se convierte una y otra vez en uno de dos meses.

Hacerlo tú mismo frente a delegarlo

Las dos columnas cumplen el mismo requisito de Google. La diferencia está en dónde recaen el trabajo y el riesgo. La primera columna está etiquetada con honestidad: solo las dos primeras filas son condiciones numéricas que Google publica de verdad. La participación es algo que sopesa quien revisa el acceso a producción, no un umbral que puedas alcanzar, y la variedad de dispositivos es una buena práctica de QA que Google recomienda, pero que no convierte en un número de dispositivos que tengas que cumplir.

Desplaza la tabla hacia los lados para ver todas las columnas

Hemos hecho esta prueba para 7,400+ apps en 120+ países, y llevamos 5+ años haciéndolo. Nuestra cifra de 99.9% es una tasa de finalización de pruebas, y conviene ser exactos sobre qué mide: la prueba gestionada mantuvo el número exigido de testers participando, sin interrupciones, durante los 14 días completos. No es una tasa de aprobación. Lo que te da es una prueba cerrada completada que cumple el requisito que Google dejó por escrito. No te da el acceso a producción, y nadie te lo puede vender: Google revisa la solicitud después y decide, y por eso justamente la versión honesta de esta oferta se detiene donde se detiene.

Si prefieres hacer el reclutamiento por tu cuenta, es una opción legítima y este artículo no va a fingir lo contrario. Siete formas legítimas de conseguir 12 testers repasa las vías que funcionan, y si vale la pena un servicio de testers de pago está escrito para ayudarte a decidir que no lo contratas cuando esa sea la respuesta correcta.

Preguntas frecuentes

En resumen

La prueba de 14 días es la única parte de todo esto que necesita a otras personas, y es la parte que PrimeTestLab hace por ti. Ver planes y precios →