Cómo funciona

#El flujo de descarga

1. Autenticar. Consigue un token, ya sea anónimo desde el dispensador (rotando perfiles de dispositivo hasta que uno funcione) o desde tu cuenta de Google. Ver autenticación.
2. Obtener detalles. Lee los metadatos de la app (versión, tamaño, splits) de la API protobuf de Google Play.
3. Comprar. "Compra" la app gratuita para obtener autorización de descarga.
4. Obtener la entrega. Pide las URLs de descarga del APK base, los split APKs, los archivos OBB y los asset packs.
5. Descargar. Descarga los archivos en paralelo desde la CDN de Google, con barras de progreso. Los paquetes de Play Asset Delivery se descomprimen (gzip) sobre la marcha.

#Pool de tokens

download y latest sacan los tokens de un pool de 5 tokens anónimos por arquitectura, país y perfil fijado, guardado en token-pool-{arch}[-{country}][-profile-{key}].json dentro del directorio de configuración (~/.config/goopdl salvo que definas GOOPDL_CONFIG_DIR o XDG_CONFIG_HOME, mira dónde se guardan los tokens).

• Antes de cada llamada, goopdl cuenta los tokens sin caducar y pide solo los que faltan. Con el pool lleno no se hace ninguna llamada al dispensador.
• Los tokens caducan a los 50 minutos.
• Si Google rechaza un token a mitad de una petición (HTTP 401), goopdl lo sustituye, o usa otro token válido del pool si el dispensador no puede darle uno nuevo.
• Los tokens se reparten por turnos (round-robin) y la posición se conserva entre ejecuciones.
• Varios procesos de goopdl pueden compartir un pool: las actualizaciones se hacen con bloqueo y se escriben de forma atómica.
• Si el dispensador responde HTTP 429, goopdl deja de probar otros perfiles en lugar de insistir. Mientras queden tokens válidos en el pool, goopdl los usa. Solo falla, con el código de salida 5, cuando no queda ninguno.
• Tras ese 429, el proceso deja de pedir a ese dispensador, a través de ese proxy, durante lo que indique su cabecera Retry-After, hasta 15 minutos. Sin una cabecera válida espera 60 segundos, una estimación: el dispensador no dice cuánto dura su límite. Mientras tanto el pool no se completa y, sin tokens válidos, una llamada falla al momento, con el tiempo que falta y sin hacer ninguna petición. La espera solo vive en memoria, así que cada nuevo comando goopdl empieza sin ella; importa en los comandos que necesitan varios tokens y en programas de larga duración que usan goopdl como biblioteca.

El pool mantiene a goopdl por debajo del límite de Aurora, de unas 20 peticiones por hora. En el modo cuenta de Google no hay pool: cada proceso inicia sesión una vez y reutiliza el dispositivo que registró y guardó.

#Encontrar la última versión

Google publica las actualizaciones por fases, por grupos (cohortes) de dispositivos. La cohorte depende del GSF ID (Google Services Framework ID) del dispositivo, que se asigna al emitir el token. Dos dispositivos pueden ver el mismo día versiones distintas de la misma app, por ejemplo la 434 y la 435.

Por eso latest pregunta con varios GSF IDs y se queda con el código de versión más alto:

• Cada sondeo usa un GSF ID distinto, así que puede caer en otra cohorte.
• El sondeo para cuando el código de versión más alto se mantiene durante --stable sondeos seguidos.
• El perfil de dispositivo fija el nivel de SDK que ve Google. Los perfiles con SDK más reciente suelen recibir antes las versiones nuevas, y por eso latest usa por defecto el perfil mejor clasificado.

download --version 434.0.0.44.74 funciona igual: sondea GSF IDs hasta que uno ve la versión pedida.

#Perfiles de dispositivo

goopdl incluye perfiles de dispositivo como archivos .properties en goopdl/profiles/. Describen un dispositivo real (modelo, versión de Android, ABI, versión de Play Store) para que Google sirva la build correcta.

Durante la autenticación anónima, goopdl va rotando perfiles hasta que el dispensador acepta uno. Lista los perfiles con goopdl profiles y fija uno con --profile.

#Arquitecturas

download acepta varias separadas por comas (-a arm64,armv7) y las descarga una tras otra.