Respuesta rápida
A 13 de agosto de 2026, tus testers todavía pueden instalar un APK que compartas directamente con ellos. La entrada en vigor del 30 de septiembre de 2026 en Brasil, Indonesia, Singapur y Tailandia solo alcanza al principio a siete tiendas de aplicaciones participantes, y las preguntas frecuentes de Google del 15 de julio dicen que la instalación directa todavía no está cubierta. Google planea aplicar la norma de forma más amplia en dispositivos certificados con Android 7 o superior en 2027, sin anunciar una fecha exacta. Cuando eso ocurra, las apps registradas con un desarrollador verificado conservan la ruta de instalación habitual, mientras que las apps no registradas se pueden seguir instalando con ADB o con el flujo avanzado de Google. Firebase App Distribution sigue siendo útil para QA, pero no realiza la verificación de desarrolladores de Android y no cuenta como la prueba cerrada de Google Play, que exige 12 testers participando durante 14 días de forma continua.
Cómo califica este artículo cada afirmación
- Verificado significa que la afirmación sale directamente de una página actual de Google, Android o Firebase. La mayor parte de este artículo está verificada. Verificado
- Parcial significa que las fuentes primarias respaldan la conclusión pero hace falta un paso de inferencia, o que las páginas de Google dejan el caso límite sin responder. Parcial
- Reportado por la comunidad significa relatos repetidos de desarrolladores en Stack Overflow, Reddit o los foros de Google. Útil para diagnosticar, no para políticas. Comunidad
- No documentado significa que Google no ha publicado nada sobre ese caso exacto, y lo decimos en vez de adivinar. No documentado
La historia que se extendió en 2025 era simple: Android acaba con la instalación directa. La postura que Google documenta de verdad en agosto de 2026 es más estrecha, más precisa y mucho menos útil como titular. Google precisó y afinó el alcance de la primera fase en junio y julio de 2026, y el 15 de julio de 2026 dejó esa acotación por escrito en una sola frase: la fecha del 30 de septiembre "solo se aplica a las tiendas participantes concretas". Buena parte de la cobertura de 2025 y principios de 2026 que sigue circulando se publicó antes de que esa frase existiera y describe un primer despliegue más amplio que el que Google está aplicando.
Por eso este artículo está organizado alrededor de la decisión que de verdad tienes que tomar y no alrededor de la polémica. Tienes doce amigos, compañeros o testers (en la documentación oficial de Google en español, verificadores; algunos textos de la comunidad dicen probadores) y un build que tiene que llegar a sus teléfonos. ¿Todavía puedes mandar el APK por correo? ¿Hace falta ADB? ¿Funciona Firebase App Distribution? Y la pregunta que llega casi todas las semanas al buzón de PrimeTestLab: ¿algo de eso cuenta para la prueba cerrada de 12 testers que Google exige antes del acceso a producción? Cada fecha, cifra y mecanismo de más abajo se comprobó contra las propias páginas de Google el 13 de agosto de 2026, y donde Google no ha publicado nada, este artículo señala el hueco en vez de rellenarlo.
¿Tus testers todavía pueden instalar tu APK después del 30 de septiembre de 2026?
Sí. Con las reglas actuales de Google, un tester todavía puede instalar un APK que le envíes directamente después del 30 de septiembre de 2026. La fecha es real, los cuatro países son reales y la aplicación de la norma es real, pero las preguntas frecuentes actuales de Google dicen que la fecha "solo se aplica a las tiendas participantes concretas". Para una instalación directa, esas mismas preguntas frecuentes dicen que "todavía no se aplicará a tu app".
Las palabras exactas de Google, fragmento a fragmento
La fecha "solo se aplica a las tiendas participantes concretas" · para una instalación directa "todavía no se aplicará a tu app" · la aplicación alcanza a "dispositivos Android certificados con Android 7 o superior" · Google va a "ampliar el requisito de verificación de Android a todo el mundo" en 2027
Fragmentos citados uno a uno desde las preguntas frecuentes de Google sobre la verificación de desarrolladores de Android (actualizadas el 10 de agosto de 2026) y el anuncio del 18 de junio de 2026, ambos consultados el 13 de agosto de 2026. Las páginas de origen están en inglés: la redacción en español de arriba es traducción nuestra. Verificado
Qué toca el 30 de septiembre y qué no
Tres filas resuelven la pregunta para casi cualquier lector. La fila del medio es la que se aparta de buena parte de la cobertura anterior sobre esta fecha.
Afectado el 30 de septiembre de 2026
Instalar a través de una de las siete tiendas participantes en Brasil, Indonesia, Singapur o TailandiaLa app tiene que estar registrada con un desarrollador verificado para que la instalación normal salga adelante. Google indica que la parte fuera de Play de esta aplicación regional inicial alcanza a los formatos de móvil y tablet.
Todavía no cubierto por la primera fase
Un APK directo: por correo, descargado de tu web, compartido en Drive o instalado con ADBLas preguntas frecuentes de Google del 15 de julio dicen que la fecha del 30 de septiembre todavía no se aplica a la instalación directa. Las tiendas fuera de la lista de participantes también quedan fuera de esta primera fase. La palabra que hace todo el trabajo en ambas frases es todavía. Un APK de Firebase App Distribution debería heredar la misma respuesta, porque es distribución directa de un APK firmado, pero Google no ha publicado ninguna resolución específica sobre Firebase. Parcial, inferencia
Igual en cualquier caso
Las reglas de publicación propias de Google PlayPlay exige por separado que cada paquete de Play esté registrado, y la prueba cerrada de 12 testers para las cuentas personales nuevas afectadas no la toca nada de esto. La verificación no la acorta, no la elimina ni la sustituye.
Alcance según las preguntas frecuentes de Google sobre la verificación de desarrolladores de Android (actualización del 10 de agosto de 2026) y el anuncio del 18 de junio de 2026 que nombra la fecha, los cuatro países y las siete tiendas. El requisito de prueba cerrada de Play, según la respuesta 14151465 de la ayuda de Play Console. Todo consultado el 13 de agosto de 2026.
Por qué esto no es un resquicio
"Todavía no cubierto" describe una fase de despliegue, no una exención permanente, y tomarlo por una exención es la imagen especular del error que este artículo corrige. Google ha dicho que el requisito se amplía a todo el mundo en 2027. La reacción correcta a esta sección es alivio con septiembre y preparación para el año siguiente, que es exactamente para lo que sirve la checklist del final. Verificado
Qué cambia de verdad el 30 de septiembre de 2026
Google fijó la fecha el 18 de junio de 2026 y luego la acotó por escrito el 15 de julio. Desde el 30 de septiembre, una instalación a través de una de las siete tiendas nombradas en los cuatro países nombrados pasa por una comprobación: la app tiene que estar registrada con un desarrollador verificado. Las preguntas frecuentes actuales de Google dicen que esa primera fase alcanza a las tiendas participantes nombradas, y que la instalación directa y las tiendas no participantes todavía no están cubiertas.
Si publicas en Google Play
Registra cada paquete pendiente antes del 30 de septiembre de 2026. La guía de Play Console de Google dice que registres las apps que quieras seguir distribuyendo para "evitar la retirada global de Google Play". Esta obligación es global. No tiene nada que ver con los cuatro países y se aplica aunque ninguno de tus usuarios viva allí.
Lo que viven los usuarios el 30 de septiembre
La aplicación en el dispositivo empieza solo en cuatro países. La primera comprobación al instalar cubre las siete tiendas participantes en Brasil, Indonesia, Singapur y Tailandia. No alcanza ni a la instalación directa ni a tiendas fuera de esa lista.
Son dos obligaciones distintas del 30 de septiembre, y mezclarlas es la forma más común de malinterpretar esta fecha. El registro de paquetes en Play es global y decide si tu ficha sigue publicada; la aplicación en la instalación es regional y decide qué pasa en el teléfono de un usuario. Verificado
Las siete tiendas participantes
Nómbralas con exactitud. Describir esto como una restricción a todas las tiendas de aplicaciones es demasiado amplio con la redacción actual de Google para la primera fase: según la lista que Google ha publicado, una tienda que no aparezca aquí queda fuera del despliegue del 30 de septiembre.
| Empresa | Tienda participante | ¿Se comprueba desde el 30 sept. en los cuatro países? |
|---|---|---|
| Google Play | Sí | |
| HONOR | HONOR App Market | Sí |
| OPlus | OPPO App Market | Sí |
| Samsung | Galaxy Store | Sí |
| Transsion | Palm Store | Sí |
| vivo | V-Appstore | Sí |
| Xiaomi | GetApps | Sí |
| Tú, directamente | Correo, enlace de descarga, tu web, Drive y, por inferencia, un APK de Firebase App Distribution | No, todavía no |
| Cualquier otro | Cualquier tienda de aplicaciones no nombrada arriba | No, todavía no |
Lista de tiendas y países según el anuncio de Google del 18 de junio de 2026; la exclusión de la instalación directa y de las tiendas no participantes, según las preguntas frecuentes de verificación actualizadas el 10 de agosto de 2026. Consultado el 13 de agosto de 2026. Verificado
Los cuatro países y los formatos de dispositivo dentro de ellos
Dos detalles acotan esto todavía más y vale la pena llevárselos. Para la distribución fuera de Google Play, las preguntas frecuentes de verificación de Google indican que la aplicación en las regiones seleccionadas alcanza a los formatos de móvil y tablet. Esas mismas preguntas frecuentes dicen que las protecciones llegan a través de Google Play services en dispositivos Android certificados con Android 7 o superior, que es el alcance final de dispositivos y no un límite exclusivo de septiembre.
Lo que no cambia en septiembre
La lista de abajo es corta, pero cubre cómo mueve un build de verdad la mayoría de los equipos pequeños. A nada de esto le afecta la fase del 30 de septiembre.
Una instalación directa. No la cubre la primera fase.
También es instalación directa, con la misma respuesta.
Distribución directa de un APK firmado a testers invitados. El cuadro completo está en la sección 08. Google no publica ninguna resolución específica sobre Firebase, así que es una inferencia a partir de la regla de instalación directa, no una exención declarada. Parcial, inferencia
Google dice que no hay cambios en cómo funciona ADB. Sección 05.
Fuera de la primera fase, según esa misma respuesta de las preguntas frecuentes.
Ese es un requisito de Play por derecho propio, y es mundial. Google dijo el 18 de junio de 2026 que más del 99% de las apps de los desarrolladores de Play ya se habían registrado automáticamente.
La cifra del 99% lleva fecha
El más del 99% de registro automático viene de la actualización de Google del 18 de junio de 2026. Algunos textos todavía repiten una cifra anterior de aproximadamente el 98%. Usa la más reciente, y cítala con su fecha en vez de como un dato atemporal, porque Google actualiza las estadísticas de adopción según avanza el despliegue. La página de resumen actual de Google sobre la verificación de desarrolladores ahora redondea esa misma cifra a 99%, así que cita cualquiera de las dos con su fuente y su fecha en lugar de como una constante exacta. Verificado
Qué pasa cuando la verificación se amplía a todo el mundo en 2027
Google dice que el requisito se amplía a todo el mundo de 2027 en adelante, a apps en dispositivos Android certificados con Android 7 o superior, a través de Google Play services. No ha anunciado una fecha mundial exacta ni un calendario país por país. Trata cualquier fecha concreta de 2027 como no oficial mientras Google no la publique.
La cronología, y qué le hace cada fecha a un APK compartido
-
30 de marzo de 2026
La verificación empieza a desplegarse a todos los desarrolladores
Google empezó a desplegar la verificación de desarrolladores de Android a todos los desarrolladores en Play Console y en la Android Developer Console.
APK en crudo Solo por esta fecha no cambia nada en la instalación para el usuario. App no verificada Se sigue pudiendo instalar con el comportamiento actual de Android. -
Agosto de 2026
El flujo avanzado y las cuentas de distribución limitada llegan a todo el mundo
Google programó el lanzamiento mundial del flujo de instalación avanzado y de las cuentas de distribución limitada para este mes. A 13 de agosto de 2026 las fuentes revisadas nombran el mes pero no un día exacto, y no demuestran que el flujo haya llegado ya a todos los usuarios. Parcial
APK en crudo Sigue disponible. App no verificada El flujo avanzado es el mecanismo pensado para preservar su instalación. -
30 de septiembre de 2026
Empieza la aplicación del registro en siete tiendas, cuatro países
Las instalaciones a través de Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore y Xiaomi GetApps en Brasil, Indonesia, Singapur y Tailandia exigen que la app esté registrada con un desarrollador verificado. Verificado
APK en crudo Todavía no cubierto por esta fase inicial. App no verificada Una instalación desde una tienda participante se puede restringir; la ruta directa queda intacta en esta fase. -
2027 en adelante
Expansión mundial a dispositivos Android certificados
La verificación se amplía a todo el mundo para apps en dispositivos Android certificados con Android 7 o superior. Esta es la fase en la que cambia la respuesta sobre la instalación directa. Verificado
APK en crudo App registrada: la ruta de instalación habitual. App no registrada: flujo avanzado o ADB según el modelo anunciado. App no verificada El flujo avanzado o ADB sigue siendo la ruta anunciada. -
Fecha exacta de 2027
Sin anunciar a 13 de agosto de 2026
El calendario publicado por Google dice 2027 en adelante, y nada más preciso. Tampoco se ha comunicado ninguna secuencia por países. No documentado
APK en crudo No hagas planes en función de un día concreto. App no verificada No hagas planes en función de un día concreto.
Cronología según la publicación de despliegue de Google del 30 de marzo de 2026, el anuncio del 18 de junio de 2026 y las preguntas frecuentes sobre la verificación de desarrolladores de Android actualizadas el 10 de agosto de 2026. Consultado el 13 de agosto de 2026.
La fecha límite que no existe
El "1 de enero de 2027" aparece en coberturas de segunda mano y en respuestas de asistentes de IA. No está en ninguna fuente de Google revisada para este artículo. Google se ha comprometido a 2027 en adelante sin nombrar un día. Si algún plan tuyo depende de conocer esa fecha, el estado honesto es que nadie fuera de Google la conoce todavía, y la precaución práctica es tener tus paquetes registrados bastante antes de que empiece el año. No documentado
APK verificado frente a no verificado: qué comprueba Android de verdad
"¿Estoy verificado?" es, por sí sola, la pregunta equivocada. La verificación de desarrolladores de Android crea lo que Google llama un vínculo formal y comprobable entre una identidad de desarrollador, el nombre de paquete de una app y la clave o claves de firma de ese paquete. La verificación de identidad es un eslabón de esa cadena, no la cadena entera.
La cadena, eslabón a eslabón
Quién eres, confirmado una sola vez desde Play Console o la Android Developer Console.
Una vez por cuentaEl identificador de la app, por ejemplo com.example.app, registrado con esa identidad verificada.
La propiedad se demuestra entregando un APK firmado con tu clave privada. La Console permite añadir y verificar varias claves para un mismo paquete.
Por clave, no por buildCuando la cadena está completa, Google dice que la experiencia de instalación habitual de los usuarios se preserva una vez que se aplica la norma más amplia.
El resultado que buscasCadena según las guías de Google sobre la verificación de desarrolladores de Android, incluida la descripción de la prueba de propiedad, y el soporte de varias claves de firma documentado en las preguntas frecuentes de verificación. Consultado el 13 de agosto de 2026. Verificado
Google es explícito en que la instalación directa es fundamental para Android y en que los desarrolladores verificados pueden seguir distribuyendo directamente. El matiz que esconde esa frase es que una instalación limpia depende de que la app esté registrada, y no solo de que tú hayas pasado un control de identidad. Por eso este artículo dice "registrada con un desarrollador verificado" cada vez, en vez del atajo más laxo "app verificada".
¿Y si usas una clave de depuración o una clave de firma de QA aparte?
Aquí es donde tropiezan los equipos de QA reales, porque es completamente normal mandar un build firmado en depuración a los testers internos y un build firmado de versión a la tienda. Son certificados distintos sobre el mismo nombre de paquete.
Auditoría de claves de firma, cuatro preguntas
- ¿Qué certificado firma de verdad el APK que instalan tus usuarios? Ese es el que hay que registrar. Con Play App Signing, la clave de firma de la app firma el APK instalado desde Google Play, mientras que la clave de subida solo autentica el artefacto que subes a Play y no es automáticamente el certificado de la versión instalada. Una clave de depuración, de CI, de QA o de subida solo cuenta para la distribución directa si es la que firma el APK que entregas a los testers.
- ¿Las claves relevantes están registradas para el paquete? Google permite añadir y verificar varias claves de firma para un mismo nombre de paquete, así que no estás obligado a reducirlo todo a una sola clave.
- No des por hecho que la verificación de identidad cubre todas las claves. Pasar el paso de identidad no bendice en silencio cada certificado que hayas usado alguna vez.
- Dos APK que comparten nombre de paquete pero no firma no son intercambiables. Ese es el comportamiento normal de la firma de apps de Android y es muy anterior a la verificación, pero se confunde con facilidad con un problema de verificación. Mira la sección 12.
Cinco casos límite que Google sí ha respondido
Estas cinco preguntas salen constantemente y todas tienen respuesta publicada, así que no hace falta adivinar.
Preguntas de alcance con respuesta documentada
- ¿Android 6 o anterior? Fuera del alcance declarado. Google dice que la aplicación cubre dispositivos Android certificados con Android 7 o superior, a través de los servicios de Google Play. Verificado
- ¿Dispositivos no certificados o ROMs personalizadas sin servicios de Google Play? Google describe esta aplicación para dispositivos Android certificados, mediante los servicios de Play. No generalices la regla a cualquier ROM personalizada o dispositivo no certificado, porque quedan fuera del mecanismo que Google documenta. No documentado para esos dispositivos
- ¿Apps de empresa en dispositivos gestionados? Las apps distribuidas por la tienda de tu organización a dispositivos gestionados no necesitan completar la verificación, porque tu administrador de TI ya las ha revisado. Google recomienda registrarlas igualmente por si la app se instala también desde otra fuente o en un dispositivo no gestionado. Verificado
- ¿Dónde compruebo si un paquete está registrado? Desarrolladores de Play: la página de verificación de desarrolladores de Android en Play Console, que muestra el estado junto a cada app. Desarrolladores fuera de Play: la pestaña Nombres de paquete de la Android Developer Console, con Registrado, No registrado o Borrador. Android Studio Panda 4 y superiores también muestran el estado al generar un APK o App Bundle firmado. Verificado
- ¿Los desarrolladores fuera de Play pagan 25 dólares? La cuenta de Android Developer Console de distribución completa cuesta 25 dólares. La cuenta de distribución limitada es gratuita, no pide documento oficial y se limita a 20 dispositivos autorizados. Si ya publicas en Google Play, gestionas la verificación en Play Console en lugar de abrir una cuenta aparte. Confirma antes la disponibilidad: a 13 de agosto de 2026 el acceso anticipado seguía cerrado. Disponibilidad parcial
Firebase también exige firma, pero por otro motivo
Firebase App Distribution exige que un APK esté firmado con una clave de depuración o una clave de firma de app antes de repartirlo. Ese es un requisito de Firebase sobre la validez del build, no un paso de la verificación de desarrolladores de Android. Los dos sistemas usan la palabra "registrar", y distinguirlos es una diferencia importante en todo este tema. La sección 08 los separa. Verificado
La distinción entre clave de subida y clave de firma también explica el ticket de Firebase más habitual. Una copia de tu app instalada desde Play puede estar firmada con la clave de firma de Google Play, mientras que el APK de Firebase que le das al mismo tester está firmado en local con una clave de subida, de release o de depuración. Android no puede instalar uno encima del otro si las identidades de firma aceptadas no coinciden, así que el tester ve un fallo que parece un problema de verificación y no lo es. Verificado
ADB sigue permitido, pero es un flujo de trabajo de desarrollo
El compromiso más claro de Google en todo este programa, de sus preguntas frecuentes de verificación: no hay cambios en cómo funciona ADB. Los desarrolladores y los usuarios avanzados pueden seguir instalando así, y la espera de 24 horas del flujo avanzado no se aplica a las instalaciones con ADB. Es la ruta técnica más duradera de este artículo y también la menos adecuada para testers normales.
Bueno para
- Tú, en tu propio dispositivo, todo el día
- Un equipo de QA técnico que ya tiene Android Studio instalado
- Pipelines de integración continua y granjas de dispositivos
- Instalar un build no registrado sin aguantar la espera de un día del flujo avanzado
- Un compañero sentado a tu lado con un cable USB
Malo para
- Doce amigos, familiares o testers reclutados
- Cualquiera al que no puedas guiar por las opciones de desarrollador por teléfono
- Testers remotos en otros países, sin cable y sin portátil
- Iterar rápido: cada build nuevo necesita acceso al dispositivo y otro comando de instalación, aunque el tester no repita toda la configuración
- Cualquier cosa que quieras que cuente para Google Play. Las instalaciones con ADB son invisibles para los requisitos de pruebas de Play
Lo que tiene que hacer antes un tester
La documentación de herramientas de Google es tajante con el requisito previo: para usar ADB por USB, hay que activar la depuración por USB en las opciones de desarrollador del dispositivo. En un teléfono moderno eso significa encontrar el número de compilación, tocarlo siete veces para desbloquear las opciones de desarrollador, y luego activar la depuración por USB en una pantalla de ajustes que muestra un diálogo de advertencia. Ese recorrido es viable para un tester técnico y una carga para alguien que solo se ofreció a probar tu app.
La configuración no se repite en cada build, y ese es el detalle que casi todos los artículos se saltan. Una vez que el tester ha autorizado tu equipo, esa autorización sigue vigente hasta que la revoque u olvide el dispositivo. Así que un build nuevo cuesta otro adb install -r y acceso al teléfono, no otro paseo por las opciones de desarrollador. Android 11 y superiores admiten además la depuración inalámbrica: el tester vincula el teléfono con el equipo una sola vez mediante un código QR o un código de vinculación, y a partir de ahí instalas por la red mientras ambos dispositivos estén en ella, sin cable. Eso elimina el cable, no el requisito técnico.
Los tres comandos que cubren casi cualquier instalación en un tester. Aquí no hay nada nuevo de 2026; es el flujo de trabajo que Google dice que no cambia.
adb devicesadb install app-release.apkadb install -r app-release.apkEl que sorprende: -r solo funciona cuando el APK nuevo está firmado con el mismo certificado que el instalado. Un build firmado con otra clave hay que desinstalarlo primero, y eso se lleva los datos de la app por delante. Ese es el comportamiento estándar de la firma de apps de Android, no una regla de verificación.
Usa ADB como plan B, no como plan
En el modelo anunciado por Google, ADB es un plan B documentado para instalar apps no verificadas, incluso durante el despliegue más amplio previsto. Es la ruta que sigue funcionando cuando un build no está registrado y el tester no va a esperar un día entero. Aun así, conviene volver a revisar la política antes de apoyarse en ese supuesto en 2027. Lo que no es: una forma de incorporar a doce personas normales, y nunca va a satisfacer el requisito de pruebas de Google Play para el acceso a producción. Verificado
¿Qué es el flujo avanzado de Android para apps no verificadas?
Google construyó una ruta deliberada para los usuarios que quieren instalar igualmente una app de un desarrollador no verificado. Es una configuración única con un paso de fricción en medio: activar el modo de desarrollador, confirmar que nadie te está guiando, reiniciar, esperar un día, autenticarse y luego permitir instalaciones no verificadas durante 7 días o de forma indefinida. La espera de 24 horas forma parte de esa configuración, no es un retraso antes de cada APK.
-
01
Activar el modo de desarrollador
El usuario activa el modo de desarrollador o el ajuste equivalente en su dispositivo.
Google: evita activaciones accidentales y los saltos de un toque usados en estafas a presión -
02
Confirmar que nadie le está guiando
El usuario confirma que ninguna otra persona le está guiando en este cambio de seguridad.
Google: una comprobación rápida de que nadie te está convenciendo de desactivar tu seguridad -
03
Reiniciar y volver a autenticarse
El dispositivo se reinicia y el usuario vuelve a iniciar sesión.
Google: corta el acceso remoto o la llamada activa con la que un estafador te observa -
04
Esperar 24 horas, una sola vez
Google lo describe como una espera única de un día. Ocurre durante la configuración, y es el paso que todo el mundo cuenta mal.
No son 24 horas antes de cada APK. Una vez, por cuenta. -
05
Verificar la identidad en el dispositivo
El usuario confirma el cambio con biometría o con el PIN del dispositivo.
Google: la biometría o el PIN confirma que es el dueño del dispositivo quien hace el cambio -
06
Permitir instalaciones no verificadas durante 7 días o de forma indefinida
Configuración terminada. El usuario elige la duración y luego puede pasar el aviso de desarrollador no verificado al instalar.
Su elección, su riesgo, su dispositivo
Secuencia, redacción y opciones de duración según las preguntas frecuentes de Google sobre la verificación de desarrolladores de Android, consultadas el 13 de agosto de 2026. Google publica un motivo para cada paso de este flujo, así que las notas de arriba recogen su justificación en lugar de deducirla. Verificado
Tres cosas que se entienden mal
"¿Entonces cada instalación necesita una espera de 24 horas?"
No. Google describe una espera única de un día dentro de la configuración. Después, el usuario elige 7 días o de forma indefinida para el tiempo que siguen permitidas las instalaciones no verificadas.
"¿Hay que repetirlo en cada teléfono nuevo?"
Google dice que no. Las preguntas frecuentes describen la configuración como única por cuenta, y se mantiene al cambiar de dispositivo.
"¿ADB también necesita la espera?"
No. Google indica explícitamente que la espera de 24 horas no se aplica a las instalaciones con ADB. Sección 05.
Las opciones de desarrollador no tienen que seguir activadas
Un tester puede volver a desactivar las opciones de desarrollador una vez habilitado el flujo avanzado. Las preguntas frecuentes de Google lo dicen directamente: no hace falta mantener activadas las opciones de desarrollador, porque en cuanto haces el cambio en el dispositivo el ajuste queda activo. Importa para testers cuyas apps bancarias o corporativas protestan si las opciones de desarrollador se quedan encendidas. Google también dice que la configuración se completa una vez por cuenta y se traslada a un dispositivo nuevo, así que no se repite en cada app ni en cada teléfono. Verificado
¿Está activo ahora mismo?
Estado honesto a 13 de agosto de 2026
Google programó el lanzamiento del flujo avanzado a todo el mundo en agosto de 2026. Las fuentes revisadas para este artículo nombran el mes pero no un día exacto, y ninguna demuestra que el flujo haya llegado ya a todos los usuarios. Así que lo correcto hoy es decirle a un tester que la ruta existe y está programada, no que seguro que la puede usar esta tarde. Consulta las páginas de verificación de Google antes de montar un guion de soporte en torno a ella. Parcial
La lectura práctica para quien desarrolla: el flujo avanzado es una respuesta real y documentada a "¿un usuario todavía puede instalar mi app no verificada?" y una mala respuesta a "¿cómo llevo un build a doce testers esta semana?". Un retraso de seguridad de un día en mitad de la incorporación añade fricción real para testers ocasionales o remotos. Si tus testers son usuarios normales, los métodos que respetan su tiempo se comparan en la sección 09.
¿Qué pasa con los APK que ya están instalados?
La documentación de Google cubre instalar y actualizar. Una vez que se aplica la norma, una app no registrada no se puede instalar ni actualizar con normalidad, y Google dice que una actualización ordinaria "fallará" sin el flujo avanzado o ADB. Lo que la documentación revisada no dice es que las copias que ya están en los teléfonos de la gente se vayan a eliminar o a bloquear al arrancar.
| Situación una vez que se aplica la norma más amplia | Resultado documentado | Evidencia |
|---|---|---|
| La app ya está instalada y el usuario simplemente la abre | La documentación de Google revisada no anuncia eliminación forzada ni bloqueo en tiempo de ejecución. Habla de instalación y de actualizaciones. | Parcial |
| Un usuario intenta instalar una app no registrada por la vía normal | La instalación normal está restringida. | Verificado |
| El usuario ha activado el flujo avanzado | La app no registrada se puede instalar. | Verificado |
| La instalación va por ADB | La app no registrada se puede instalar. No se aplica ninguna espera del flujo avanzado. | Verificado |
| Una app no registrada ya instalada recibe una actualización ordinaria, con el flujo avanzado desactivado | Google dice que la actualización falla. | Verificado |
| Esa misma app se actualiza con ADB | Permitido, según la excepción anunciada por Google. | Verificado |
Comportamiento según las preguntas frecuentes de Google sobre la verificación de desarrolladores de Android, consultadas el 13 de agosto de 2026. La primera fila constata la ausencia de un mecanismo anunciado, que no es lo mismo que una promesa de que ese comportamiento no pueda cambiar nunca.
No escribas "tu app se va a borrar"
Es la afirmación más viral de este tema y no está respaldada. La redacción exacta, la que se usa en todo este artículo, es: Google documenta restricciones de instalación y actualización; no ha anunciado que las copias ya instaladas se vayan a retirar de los dispositivos ni a impedir que arranquen. Reportar la ausencia de una fuente es honesto. Convertir esa ausencia en una garantía de tranquilidad o en una predicción de borrado masivo, no. Parcial, ausencia de fuente
Esa distinción cambia lo que deberías hacer de verdad. Una actualización bloqueada es un problema operativo real y documentado: un tester afectado se puede quedar en un build antiguo porque la actualización no entra por la vía normal, y puede que nunca lo reporte, porque desde su lado no pasó nada. Una desinstalación masiva sería una emergencia de un tipo completamente distinto y exigiría una comunicación completamente distinta. Solo una de las dos consta en las fuentes.
Dónde encaja Firebase App Distribution después de la verificación
Firebase App Distribution sirve para poner builds de preproducción en los dispositivos de tus testers. No es un sistema de verificación, no es un canal de pruebas de Google Play, y no exime de nada de la verificación de desarrolladores de Android. Lo que hace bien es quitar el trabajo manual de entregarle un build firmado a una lista de personas.
Cómo funciona de verdad el flujo de APK
Subes un APK firmado a la consola de Firebase. Firebase exige que esté firmado con una clave de depuración o una clave de firma de app.
Seleccionas grupos de testers o testers concretos para esa versión.
Los testers reciben una invitación e instalan el build repartido.
Los builds repartidos siguen disponibles 150 días. Las invitaciones a testers caducan a los 30 días, y Firebase avisa 5 días antes.
Flujo, requisito de firma, retención de builds de 150 días y caducidad de invitaciones de 30 días según la documentación de Android de Firebase App Distribution, consultada el 13 de agosto de 2026. Verificado
Dos relojes de caducidad, dos tickets de soporte distintos
La caducidad de la invitación a los 30 días y la retención del build durante 150 días son cosas separadas. Un tester que ignora el correo cinco semanas tiene una invitación caducada aunque el build siga perfectamente vivo. Eso produce un mensaje confuso del tipo "el enlace está roto" que no tiene nada que ver con la verificación, la firma ni Android. Verificado
¿Firebase sigue funcionando durante la fase de septiembre?
Casi con seguridad sí, e importa cómo se llega a esa conclusión. El flujo de APK de Firebase es distribución directa de un APK firmado a testers invitados. Las preguntas frecuentes de Google dicen que la instalación directa no está cubierta por la fase del 30 de septiembre. Junta esos dos hechos y la distribución de APK con Firebase debería seguir siendo utilizable durante toda esa primera fase.
Esa conclusión es una inferencia, y va etiquetada como tal
Ninguna fuente de Google nombra a Firebase App Distribution para concederle una exención. La conclusión de arriba se deduce de dos hechos verificados: las instalaciones directas quedan fuera de la aplicación inicial de septiembre, y el flujo de APK de Firebase es distribución directa. Es una inferencia sólida y sigue siendo una inferencia, y por eso este artículo la califica en vez de afirmarla sin más. Parcial, inferencia
La distribución con Firebase en APK y en AAB no es lo mismo
Este es el matiz que casi todos los artículos aplanan. Firebase admite las dos, y toman caminos distintos hasta el teléfono del tester.
| Flujo de Firebase | Cómo llega el build al tester | Cómo pensarlo para la verificación |
|---|---|---|
| APK | Firebase reparte el APK firmado directamente a los testers invitados. | Distribución directa. Se comporta como la vía de instalación directa, también en septiembre. Parcial |
| Android App Bundle (AAB) | El flujo de AAB de Firebase se integra con el uso compartido interno de apps de Google Play. | Una ruta conectada a Play, así que no razones sobre ella como si fuera la vía del APK en crudo. Google no ha dicho cómo se trata bajo la aplicación de septiembre. Integración verificada Aplicación no documentada |
Un AAB no se puede instalar directamente
Antes de que importe cualquier pregunta sobre verificación, hay otra más simple con la que mucha gente tropieza: un Android App Bundle no se puede instalar directamente en un teléfono. Un archivo .aab es un formato de publicación, no un paquete listo para el dispositivo. Google Play, el flujo AAB de Firebase conectado a Play, o bundletool tiene que convertirlo antes en APK. Así que si necesitas un archivo para enviar por correo, subir a Drive o entregar directamente a un tester, compila un APK. La propia documentación de compilación de Android dice que un app bundle no se puede desplegar directamente en un dispositivo. Verificado
Así que "¿Firebase sigue funcionando?" tiene dos respuestas según el artefacto que subas. Cuando escribas sobre esto, o cuando le preguntes a alguien del equipo, di explícitamente distribución de Firebase en APK o distribución de Firebase en AAB. El atajo esconde un detalle que cambia el análisis de forma importante.
¿Firebase App Distribution cuenta para la regla de los 12 testers?
No. El requisito de acceso a producción de Google para las cuentas afectadas pide un mínimo de 12 testers que hayan aceptado participar en una prueba cerrada de Google Play, de forma continua, durante los 14 días anteriores. Los testers de Firebase no están participando en una prueba cerrada de Play, así que probar con Firebase no cumple ese requisito por muchas personas que participen ni por muy a fondo que prueben.
| Pregunta | Firebase App Distribution | Prueba cerrada de Google Play |
|---|---|---|
| ¿Para qué sirve? | Llevar builds de preproducción a los testers rápido | Cumplir el filtro de preproducción de Play y probar en la tienda |
| ¿Dónde aceptan participar los testers? | En un correo de invitación de Firebase | En un enlace de la prueba de Play, en el canal cerrado |
| ¿Registra tu app para la verificación de desarrolladores de Android? | No el "registrar tu app" de Firebase es un proceso completamente distinto | No el registro de paquetes es una tarea aparte |
| ¿Cumple el requisito de 12 testers durante 14 días de forma continua? | No | Sí para testers y cuentas que califiquen |
| ¿Merece la pena igualmente? | Sí como canal de QA, junto a la prueba cerrada | Sí es la ruta exigida |
Requisito de Play según la respuesta 14151465 de la ayuda de Play Console; comportamiento de Firebase según la documentación de Firebase App Distribution. Ambos consultados el 13 de agosto de 2026. Los dos productos definen procesos distintos que comparten la palabra "registrar". Verificado
El patrón que esto crea merece un nombre, porque cuesta dos semanas. Alguien hace una prueba de Firebase de verdad rigurosa con quince testers implicados, da por hecho que la casilla de pruebas está marcada, abre Play Console para solicitar el acceso a producción y descubre que el reloj de 14 días no ha arrancado. La sección 10 pone los dos requisitos uno al lado del otro para que eso no te pase.
La mejor forma de llevar un build a 12 testers en 2026
No hay un único ganador, porque los métodos resuelven problemas distintos. Un APK en crudo es lo más simple que funciona hoy. ADB es lo más duradero y lo menos usable. Firebase es el mejor canal puro de QA. Y solo un método de esta página cumple el requisito de acceso a producción de Google Play, que es lo que de verdad decide tu fecha de lanzamiento.
Comprobador de método de distribución
No se envía nada a ninguna parte. La lógica corre en tu navegador con el alcance publicado por Google, la documentación de Firebase y la regla de acceso a producción de Play.
1 ¿Cómo les haces llegar el build?
2 ¿Dónde están tus testers?
3 ¿La app está registrada con un desarrollador verificado?
Alcance según las preguntas frecuentes de verificación de Google (10 de agosto de 2026), la documentación de Firebase App Distribution y la respuesta 14151465 de la ayuda de Play Console. Consultado el 13 de agosto de 2026.
Los siete métodos, uno al lado del otro
La herramienta responde a una situación. Esta tabla responde a todas, incluidas las dos columnas que la gente se salta hasta que es tarde: el comportamiento anunciado para 2027, y si el método sirve de algo para tu solicitud de acceso a producción en Play.
| Método | Qué tiene que hacer el tester | Primera fase del 30 sept. de 2026 | Modelo anunciado para 2027 | ¿Cuenta para los 12/14 de Play? | Veredicto práctico |
|---|---|---|---|---|---|
| APK en crudo por correo, Drive o web | Descargar el APK y permitir la instalación desde esa fuente | Sigue siendo viable la instalación directa todavía no está cubierta | App registrada: se instala con normalidad; app no registrada: se espera que necesite el flujo avanzado o ADB | No | Perfecto para QA improvisada hoy. No es la prueba de acceso a producción. |
| ADB | Activar las opciones de desarrollador y la depuración por USB, conectar, instalar con herramientas de desarrollo | Sí | Sí Google preserva ADB explícitamente | No | Duradero, pero demasiado técnico para testers normales. |
| Firebase App Distribution, APK | Aceptar el correo de invitación e instalar el build repartido | Probablemente no afectado según la regla de instalación directa. Ninguna resolución específica sobre Firebase. Parcial | Un paquete registrado debería seguir yendo fino; uno no registrado sigue el modelo más amplio de instalación directa | No | Flujo de QA excelente. No sustituye a la prueba de Play. |
| Firebase App Distribution, AAB | Recibir el build por un flujo integrado con el uso compartido interno de apps de Play | No documentado conectado a Play por el uso compartido interno; Google no ha dicho cómo se trata esa ruta No documentado | Depende de Play y del registro del paquete | No | Útil, y merece su propia explicación en vez de meterlo en el mismo saco que Firebase APK. |
| Pruebas internas de Google Play | Unirse a la prueba interna e instalar desde Play | Viable para una app de Play registrada correctamente | Viable | No no sustituye a la prueba cerrada exigida | Buena QA rápida basada en Play. Hasta 100 testers. |
| Prueba cerrada de Google Play | Aceptar participar por el enlace de la prueba cerrada y seguir dentro | Viable | Viable | Sí para testers y cuentas que califiquen | La ruta exigida para las cuentas personales nuevas afectadas que buscan acceso a producción. |
| Distribución limitada de Android | Tener un dispositivo autorizado en el sistema de distribución limitada | Programada para agosto de 2026, acceso anticipado aún cerrado Parcial | Diseñada como ruta duradera para público pequeño | No | Para aficionados que comparten con hasta 20 dispositivos. Gratis, sin documento oficial de identidad, no permite publicar en Play. |
Fuentes: las preguntas frecuentes y las guías de verificación de Google, la documentación de la herramienta ADB, la documentación de Firebase App Distribution, la distribución limitada, la ayuda de Play Console sobre pruebas internas y sobre los requisitos de pruebas para el acceso a producción. Todo consultado el 13 de agosto de 2026.
La recomendación honesta
Lleva dos vías en paralelo, porque responden a preguntas distintas. Usa lo que ponga un build en dispositivos más rápido para QA de verdad: un APK en crudo para un compañero, Firebase para un grupo, ADB cuando necesites saltártelo todo. Y aparte, empezando lo antes posible, monta la prueba cerrada de Play si tu cuenta está sujeta al requisito de acceso a producción, porque esa se mide en días de calendario y no se comprime trabajando más.
El error que hay que evitar es tratarlas como si fueran secuenciales. Terminar una prueba de Firebase a fondo no adelanta el contador de 14 días ni un solo día.
La verificación de desarrolladores no sustituye a la prueba cerrada de Google Play
Son dos requisitos sin relación que la gente funde en una sola casilla mental. La verificación responde a "¿quién creó y firmó este paquete?" La prueba cerrada responde a "¿esta cuenta completó la prueba de preproducción de Google?" Cumplir uno no hace absolutamente nada por el otro.
Modelo de verificación según las guías de Google sobre la verificación de desarrolladores de Android; requisito de pruebas según la respuesta 14151465 de la ayuda de Play Console y la página de pruebas internas (respuesta 9845334). Consultado el 13 de agosto de 2026.
Por qué "las pruebas internas cuentan, siguen siendo pruebas de Play" es falso
Google permite hasta 100 testers en una prueba interna, lo que la hace parecer la opción más seria. Pero el requisito de acceso a producción está escrito alrededor de un canal concreto: los testers que cuentan tienen que haber aceptado participar en una prueba cerrada durante los últimos 14 días de forma continua. Las pruebas internas son otro canal, así que no cumplen esa frase.
Una nota sobre de dónde sale esta afirmación
Google no publica una frase que diga "las pruebas internas no cuentan". Lo que publica es un requisito que especifica una prueba cerrada. La conclusión sale de la definición y no de una cita, y este artículo lo formula así en vez de poner palabras en boca de Google. Verificado por la definición del requisito
Las cifras, y de dónde salen
Dos apuntes de historia aclaran preguntas que salen constantemente. Google anunció el requisito el 9 de noviembre de 2023, y la política actual lo aplica a las cuentas personales creadas después del 13 de noviembre de 2023: dos fechas distintas que significan dos cosas distintas. Y el mínimo era originalmente de 20 personas durante al menos dos semanas; la propia guía de la comunidad de Google dice que la bajada a 12 ocurrió en diciembre de 2024. Reportes de desarrolladores de la época sitúan el cambio en Play Console el 11 de diciembre de 2024, pero no se ha podido localizar ningún anuncio fechado de Google para ese día exacto, así que trata el día como reportado y no como oficial. Parcial
Las cuentas de organización quedan fuera de este filtro concreto: el requisito se dirige a las cuentas personales que califican. Y la cuota no cambia en ningún caso, un pago único de 25 USD para registrarse en Google Play. Si quieres la comparación completa de tipos de cuenta en vez de un párrafo, está en cuenta personal frente a cuenta de organización.
Diez afirmaciones sobre esto que ya no están al día
Buena parte de lo que se escribió sobre la verificación de desarrolladores de Android se publicó antes de que Google acotara la primera fase en junio y julio de 2026. Las afirmaciones de abajo no son mentiras; varias eran exactas cuando se publicaron. Simplemente describen una versión de la norma que ya no coincide con las páginas actuales de Google.
Afirmación Toda instalación directa de APK se bloquea desde el 30 de septiembre en los cuatro países.
Regla actual Falso según las preguntas frecuentes de Google del 15 de julio de 2026. El 30 de septiembre alcanza a siete tiendas participantes. Las instalaciones directas todavía no están cubiertas. Verificado
Afirmación La verificación de desarrolladores significa que ya no puedes instalar una app de un desarrollador no verificado.
Regla actual Demasiado absoluto. ADB sigue disponible, y Google construyó el flujo avanzado precisamente para las apps no verificadas. Verificado
Afirmación La fecha límite mundial es el 1 de enero de 2027.
Regla actual Sin respaldo. Google ha anunciado "2027 en adelante" y ninguna fecha mundial exacta. No documentado
Afirmación Una vez verificada tu identidad, cualquier APK que firmes va bien.
Regla actual Incompleto. El nombre de paquete y las claves de firma relevantes también tienen que estar registrados. Verificado
Afirmación Firebase App Distribution verifica tu app de Android.
Regla actual Confusión. El "registrar tu app" de Firebase y el registro de la verificación de desarrolladores de Android son sistemas distintos. Verificado
Afirmación Los testers de Firebase cuentan para los 12 testers de Google.
Regla actual Falso. Google exige 12 testers que hayan aceptado participar en la prueba cerrada de Play. Verificado
Afirmación Las pruebas internas de Play cuentan, porque siguen siendo pruebas de Play.
Regla actual Para este filtro no. El requisito de acceso a producción nombra concretamente una prueba cerrada. Verificado por definición
Afirmación Las apps no verificadas que ya están instaladas se van a borrar.
Regla actual Sin respaldo. Google documenta restricciones de instalación y actualización y no anuncia ninguna retirada automática de las copias instaladas. Parcial, ausencia de fuente
Afirmación El flujo avanzado ya está activo en todas partes seguro, porque estamos en agosto.
Regla actual Demasiado tajante. Google programó un lanzamiento mundial en agosto de 2026 sin publicar un día exacto de puesta en marcha. Parcial
Afirmación Alrededor del 98% de las apps de Play se registraron automáticamente.
Regla actual Desfasado. La actualización de Google del 18 de junio de 2026 dice más del 99%. Verificado
Dónde parecen contradecirse las dos páginas de Google
Vale la pena nombrarlo, porque un lector atento se lo va a encontrar. La redacción general de la ayuda de Google dice que las apps cuyos desarrolladores no hayan cumplido el requisito dejan de estar disponibles para instalaciones nuevas en los países afectados, lo que suena más amplio que la excepción limitada a tiendas. Las preguntas frecuentes, más específicas y actualizadas el 10 de agosto de 2026, dicen que la fecha del 30 de septiembre solo alcanza a las tiendas participantes y todavía no llega a la instalación directa.
Cómo lo resuelve este post, y por qué es un criterio editorial
Interpretación editorial. Para la primera fase del 30 de septiembre, este post sigue la respuesta de las preguntas frecuentes, más reciente y específica del escenario, porque nombra de forma explícita la instalación directa y las tiendas no participantes en lugar de darlas por implícitas, y porque su respuesta sobre instalación directa lleva fecha del 15 de julio de 2026. El texto de ayuda general describe el programa en conjunto. Google no ha publicado ninguna regla formal que diga que una fuente prevalece sobre la otra, así que es nuestra decisión editorial, dicha abiertamente en lugar de escondida. Conviene leer las dos páginas como descripciones de capas distintas del mismo despliegue, no como una contradicción. Interpretación editorial
Del síntoma a la solución: qué falla de verdad
Busca la frase que de verdad dijiste tú o dijo tu tester. Una causa habitual de que falle una instalación o una actualización en un tester es un conflicto de certificados de firma, que es comportamiento normal de Android, no tiene nada que ver con la verificación de desarrolladores y es una década anterior a ella.
"Mi amigo no puede instalar el APK desde lo de la verificación"
Explicación probable. Casi seguro que no es la verificación de desarrolladores. Antes del despliegue amplio de 2027, un fallo al instalar un APK directo no lo causa la regla del 30 de septiembre, porque esa regla todavía no alcanza la ruta directa. La causa real más habitual es un desajuste de certificado de firma: el teléfono ya tiene una copia de la app firmada con otro certificado.
La comprobación más segura, en este orden. Repasa primero los fallos de instalación normales de Android: una copia instalada firmada con otro certificado, un versionCode menor que el instalado, una versión de Android o una arquitectura de CPU no compatibles, una descarga truncada o corrupta, falta de almacenamiento, el permiso de origen de instalación no concedido a la app que entrega el archivo, o un aviso de Play Protect que el tester descartó. Después, y solo si la instalación va por una tienda participante o ya ha empezado la aplicación amplia, comprueba el registro del paquete y de la clave de firma.
Concepto verificado
"Firebase dice que falló la instalación sobre mi versión de Play"
Explicación probable. Un tester que ya tiene instalado un build firmado por Play no lo puede actualizar en el sitio con un APK de Firebase firmado con otro certificado. Hay desarrolladores que han reportado justo esto, y los testers rara vez entienden el mensaje de error.
Comprobación más segura. Compara los certificados de firma de los dos artefactos. O usas una ruta de firma compatible, o el tester desinstala primero el build antiguo, cosa que se lleva sus datos por delante: avísale.
Ejemplo reportado por la comunidad
"¿Tengo que esperar 24 horas para instalar con ADB?"
Respuesta. No. Google indica que la espera de 24 horas del flujo avanzado no se aplica a las instalaciones con ADB.
Siguiente paso. Usa el flujo de trabajo normal de ADB. La sección 05 tiene los comandos.
Verificado
"Mi app no registrada ya estaba instalada pero no se actualiza"
Explicación probable. Una vez que la norma se aplica a esa ruta de instalación, Google dice que las actualizaciones de una app no registrada exigen el flujo avanzado o ADB, y que una actualización ordinaria falla.
Comprobación más segura. Registra el paquete como corresponde. Mientras tanto, el tester puede activar el flujo avanzado o puedes enviar la actualización por ADB.
Verificado
"Probé con 12 personas en Firebase pero Play sigue sin dejarme solicitar producción"
Explicación probable. Los testers de Firebase no están participando en un canal de pruebas cerrado de Play, así que nada de esas pruebas cuenta para el requisito de acceso a producción.
Comprobación más segura. Monta la prueba cerrada de Play: un mínimo de 12 testers que califiquen, que acepten participar y sigan dentro, durante 14 días de forma continua. El reloj arranca cuando están inscritos de verdad, no cuando empezaste a probar.
Verificado
"Usé 12 personas en pruebas internas de Play pero producción sigue bloqueada"
Explicación probable. Las pruebas internas no son el canal que nombra el requisito de acceso a producción. La regla pide una prueba cerrada.
Comprobación más segura. Mueve la prueba que cuenta a un canal cerrado de Play. Las pruebas internas siguen siendo útiles para una QA rápida en paralelo.
Verificado por la definición de la regla
"Mi tester nunca recibió la invitación de Firebase, o dice que el enlace está muerto"
Explicación probable. Las invitaciones a testers de Firebase caducan a los 30 días, con un aviso 5 días antes. Alguien que dejó el correo aparcado un mes tiene una invitación caducada aunque el build siga disponible 150 días.
Comprobación más segura. Reenvía la invitación antes de suponer nada sobre la firma, la verificación o el dispositivo. Los fallos de incorporación en App Distribution se reportan a menudo como problemas de cuenta, de invitación o de origen de instalación en vez de como problemas del build.
Verificado Patrón reportado por la comunidad
"Un artículo dice que toda instalación directa se acaba el 30 de septiembre"
Explicación probable. Se apoya en cobertura de 2025 o de principios de 2026, escrita antes de que Google acotara el alcance inicial.
Comprobación más segura. Lee directamente las preguntas frecuentes de verificación de Google. La respuesta actual es que la fecha del 30 de septiembre alcanza a las tiendas participantes y todavía no cubre la instalación directa.
Corrección verificada
La regla que más tiempo de soporte ahorra
Dos APK con el mismo nombre de paquete pero firmas sin relación no son intercambiables, y nunca lo han sido. Antes de diagnosticar algo como un problema de verificación de desarrolladores, comprueba si simplemente le estás pidiendo a Android que sustituya una app por un impostor de sí misma firmado de otra forma. La arquitectura de la verificación refuerza por qué importa la identidad de firma, pero este fallo se confunde con facilidad con un problema de verificación cuando no es ni nuevo ni tiene relación.
Qué deberías hacer de verdad antes del 30 de septiembre
Si solo distribuyes APKs de forma directa, la primera fase del 30 de septiembre no aplica la verificación de desarrolladores en esa ruta. Es temporal, no permanente: Google recomienda completar la verificación antes de que empiece el despliegue global en 2027. Si publicas en Google Play, te pide una cosa: todos los paquetes registrados. Y aparte de las dos, si tu cuenta se enfrenta al filtro de acceso a producción, el reloj de 14 días es lo que decide tu fecha de lanzamiento, así que ya debería estar corriendo.
Seguimiento antes de la fecha límite
Doce puntos en el orden en que pasan de verdad. Ve marcando; no se guarda nada, así que termínalo de una sentada o deja la pestaña abierta.
0 / 12 completados
Nada marcado todavía. Empieza por averiguar en qué vía estás.
Cuándo se queda desfasado este artículo
Este es un artículo inusualmente perecedero y sería deshonesto presentarlo como atemporal. Abajo están las cosas que más probablemente cambien primero, y qué haría que cada una dejara de ser cierta.
El disparador de actualización más importante de la página. Si Google reformula la respuesta de las preguntas frecuentes que ahora dice que la instalación directa todavía no está cubierta, cambia toda la primera mitad de este artículo.
Siete tiendas, cuatro países. Google puede añadir tiendas o aclarar el comportamiento ese mismo día. Vale la pena revisarlo el 29 de septiembre, el día en sí y una semana después.
Los dos estaban programados para un lanzamiento mundial en agosto de 2026 sin día publicado. Su estado puede cambiar sin ningún cambio de política.
En cuanto Google nombre países o fechas de 2027, este artículo va a necesitar una tabla por países que hoy, con razón, no tiene.
Las documentaciones de APK y de AAB de Firebase se mueven de forma independiente, y el requisito de Play de 12 testers durante 14 días vive en una página de ayuda que Google revisa sin anunciarlo.
Ritmo de actualización elegido para este artículo: semanal hasta el 30 de septiembre de 2026, luego el día de la entrada en vigor y aproximadamente una semana después para aclaraciones de implementación, y después mensual hasta que Google publique un calendario concreto para 2027. Ese ritmo es una decisión editorial basada en la frecuencia con la que Google revisó este programa durante 2026, no un calendario oficial de Google.
Dónde encaja PrimeTestLab y dónde no
Primero el límite, porque es la parte honesta. PrimeTestLab no verifica tu identidad, no registra tus nombres de paquete ni convierte una prueba de Firebase en una prueba cerrada de Play. Eso es tuyo, y este artículo es toda nuestra contribución. Lo que sí cubrimos es el único requisito de esta página hecho de tiempo de calendario y no de papeleo: 12 testers reales que acepten participar durante 14 días de forma continua en un canal de pruebas cerrado de Play. Google sí publica APIs y delegación OAuth con las que una plataforma autorizada puede ayudar a un desarrollador con el registro, pero ese acceso tendrías que concederlo tú y la responsabilidad de la cuenta y de la identidad de la app sigue siendo tuya.
Esa distinción tiene exactamente la forma del problema que este artículo existe para arreglar. Alguien reparte sus builds de maravilla: grupos de Firebase, notas de versión ordenadas, testers comprometidos, reportes de errores reales. Después abre Play Console para solicitar el acceso a producción y descubre que nada de eso contó. Repartir es un problema resuelto. La ventana de 14 días de participación es la parte que no puedes comprimir organizándote mejor.
Llevar la prueba cerrada por tu cuenta o delegarla
Google decide sobre el registro de paquetes, la verificación de identidad y el acceso a producción. Ninguno de los tres es algo que hagamos por ti. Lo que quita una prueba gestionada es el riesgo de reclutamiento y de continuidad de los testers, que es el paso en el que de verdad se atasca la mayoría de quienes publican por primera vez. Tasa de éxito en 7,400+ apps probadas: 99.9%, en 120+ países.
Tres planes, un solo pago
Starter
12 testers $19.99 +5% de tarifa de servicioExactamente el mínimo de Google, para una sola app que necesita pasar el requisito.
Professional
20 testers $29.99 +5% de tarifa de servicioMargen por encima del mínimo, para que una baja no termine con la prueba.
Enterprise
25 testers $27.99 +5% de tarifa de servicioPara más cobertura de dispositivos y regiones durante los 14 días.
Todos los planes usan testers reales en dispositivos reales durante el periodo completo de 14 días, la prueba suele arrancar en 4-6 horas, y si una prueba no da resultado tienes repetición gratis o reembolso completo. No prometemos la aprobación de Google, porque nadie puede.
Preguntas frecuentes
¿Mis amigos todavía podrán instalar un APK que les envíe por correo después del 30 de septiembre de 2026?
Sí, con las reglas actuales del despliegue inicial de Google. La fecha del 30 de septiembre en Brasil, Indonesia, Singapur y Tailandia alcanza a siete tiendas de aplicaciones participantes, y las preguntas frecuentes de Google del 15 de julio de 2026 dicen explícitamente que la instalación directa todavía no está cubierta. El requisito más amplio sigue previsto para ampliarse a todo el mundo en 2027, así que tómalo como un límite de la primera fase y no como una exención permanente.
¿Google bloquea toda instalación directa en Brasil, Indonesia, Singapur y Tailandia el 30 de septiembre?
No, y esta es la corrección más importante a las noticias más antiguas. La aplicación inicial se limita a Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore y Xiaomi GetApps. La instalación directa y las tiendas fuera de esa lista quedan explícitamente fuera de la primera fase. Para la distribución fuera de Play, Google indica que la aplicación en las regiones seleccionadas alcanza al principio a los formatos de móvil y tablet.
¿Podré seguir instalando APKs directamente después del despliegue mundial?
Para una app registrada correctamente con un desarrollador verificado, Google dice que la experiencia de instalación habitual de los usuarios no debería cambiar. Para una app no verificada o no registrada, Google ha preservado dos rutas: ADB y un flujo avanzado por el que un usuario puede elegir deliberadamente instalarla. Google no ha anunciado ninguna fecha mundial exacta para esa fase más amplia, solo 2027 en adelante.
¿Necesito la verificación de desarrolladores de Android para usar ADB?
No. Google dice que los desarrolladores y los usuarios avanzados pueden seguir usando ADB para instalar apps no verificadas, y que la espera de 24 horas del flujo avanzado no se aplica a ADB. Eso sí, ADB por USB exige tener activadas las opciones de desarrollador y la depuración por USB en el dispositivo, así que encaja mucho mejor con desarrolladores y testers técnicos que con usuarios ocasionales.
¿El flujo avanzado me obliga a esperar 24 horas por cada APK?
No. Google describe el retraso de 24 horas como parte de la configuración única del flujo avanzado. Cuando esa configuración termina, el usuario puede permitir la instalación de apps de desarrolladores no verificados durante siete días o de forma indefinida. Google también describe la configuración como única por cuenta, y se mantiene al cambiar de dispositivo.
¿Android va a borrar una app no verificada que ya esté instalada?
La documentación de Google que hemos revisado no dice que las copias existentes se vayan a desinstalar automáticamente ni que se les vaya a impedir arrancar. Lo que sí dice es que, una vez que la norma se aplica, una app no registrada no se puede instalar ni actualizar con normalidad sin el flujo avanzado o ADB, y que una actualización ordinaria fallará. La forma correcta de describirlo es como restricciones de instalación y actualización, no como borrado.
¿Firebase App Distribution salta la verificación de desarrolladores?
No. Firebase es un servicio de distribución de builds de prueba, y registrar una app en Firebase no es lo mismo que la verificación de desarrolladores de Android, que vincula a un desarrollador verificado con nombres de paquete y claves de firma. La distribución de APK con Firebase debería quedar fuera de la aplicación inicial de septiembre en tiendas, porque las preguntas frecuentes de Google dicen que la instalación directa todavía no está cubierta, pero eso es una inferencia a partir de la regla de la instalación directa y no una exención específica de Firebase: prepara igualmente el registro de tus paquetes para el despliegue de 2027.
¿Los testers de Firebase App Distribution cuentan para el requisito de 12 testers de Google?
No. Google exige a las cuentas afectadas un mínimo de 12 testers (verificadores, en la documentación oficial en español) que hayan aceptado participar en una prueba cerrada de Google Play durante los 14 días anteriores de forma continua antes de solicitar el acceso a producción. Firebase App Distribution es útil para encontrar errores, pero esos testers no están participando en un canal de pruebas cerrado de Play y no cumplen ese requisito.
¿Las pruebas internas de Play cuentan para los 12 testers?
No, las pruebas internas no sustituyen a la prueba cerrada exigida. Google permite hasta 100 testers en una prueba interna, pero el requisito de acceso a producción dice concretamente que los testers que cuentan tienen que haber aceptado participar en una prueba cerrada durante 14 días de forma continua. Las pruebas internas siguen siendo útiles para control de calidad rápido junto a la prueba cerrada.
Ya verifiqué mi identidad. ¿Cualquier APK que compile está automáticamente bien?
No lo des por hecho. La verificación de desarrolladores de Android también implica registrar el nombre del paquete y su clave o claves de firma, y Google permite añadir y verificar varias claves de firma para un mismo paquete. Esto importa sobre todo cuando los builds de QA o de depuración y los builds de versión usan certificados de firma distintos, un montaje completamente normal que la verificación de identidad por sí sola no cubre.
¿La verificación significa que mi APK instalado directamente ahora tiene que cumplir todas las políticas de Google Play?
La documentación de verificación de Google describe una confirmación de identidad y un registro de paquetes, no una extensión de todas las políticas de publicación de Play a cualquier distribución directa. Google también distingue entre verificar quién es un desarrollador y el control de seguridad que se aplica al contenido de las apps. Establecer una identidad no es lo mismo que aprobar lo que has publicado, así que no trates la distribución fuera de Play como equivalente a una revisión en Play Store.
Conclusión
Resumen
A 13 de agosto de 2026, tus testers todavía pueden instalar un APK que compartas directamente. La aplicación de la norma desde el 30 de septiembre de 2026 en Brasil, Indonesia, Singapur y Tailandia solo alcanza al principio a siete tiendas de aplicaciones participantes, y las preguntas frecuentes de Google del 15 de julio dicen que la instalación directa todavía no está cubierta. Google planea aplicar la norma de forma más amplia en dispositivos certificados con Android 7 o superior en 2027, sin anunciar una fecha mundial exacta. Cuando eso ocurra, las apps registradas con un desarrollador verificado conservan la ruta de instalación habitual, mientras que las apps no registradas se pueden seguir instalando con ADB, que no tiene espera de 24 horas, o con el flujo avanzado de Google, cuyo retraso de 24 horas es un paso de configuración que se hace una sola vez. Firebase App Distribution sigue siendo un gran canal de QA, pero no realiza la verificación de desarrolladores de Android, sus flujos de APK y AAB se comportan distinto, y no es la prueba cerrada de Google Play que exige 12 testers participando durante 14 días de forma continua. Si ese paso de pruebas es lo que de verdad bloquea tu lanzamiento, PrimeTestLab pone 12 testers reales desde $19.99 más 5% de tarifa de servicio. Ver planes de precios →
Fuentes primarias usadas para este artículo
Última revisión de políticas: 13 de agosto de 2026. La página de preguntas frecuentes de Google sobre la verificación de desarrolladores se actualizó por última vez el 10 de agosto de 2026, la respuesta sobre la instalación directa que contiene tiene fecha del 15 de julio de 2026, y la documentación de Android de Firebase App Distribution se actualizó por última vez el 11 de agosto de 2026. La verificación de desarrolladores de Android se está desplegando activamente, así que el alcance del 30 de septiembre, la lista de tiendas participantes, la disponibilidad del flujo avanzado y el calendario de 2027 se deberían volver a comprobar en las páginas de Google antes de actuar. Este artículo tiene programada una nueva verificación semanal hasta el 30 de septiembre de 2026, otra el día en que entra en vigor y aproximadamente una semana después, y luego mensual hasta que Google publique una geografía o una fecha concretas para 2027.