Plataforma

El modelo de aislamiento: un asiento, una identidad

La razón misma por la que existe una plataforma de Android remoto —en lugar de diez ventanas de emulador en un solo portátil— es la separación. En CloudPhoneHub, cada teléfono en la nube es un asiento autónomo: su propio espacio de usuario de Android, su propio almacenamiento, su propia identidad de dispositivo y su propia salida de red. Los asientos no comparten un pool de huellas, y los asientos de un cliente no se extraen en silencio de la misma plantilla de identidad que los de otro.

Esto importa sobre todo en el trabajo multicuenta. Las plataformas rara vez banean una sola cuenta en el vacío: vinculan cuentas que parecen el mismo dispositivo, la misma instalación o la misma red, y luego actúan sobre el clúster. Si cinco inicios de sesión comparten señales de identidad a nivel de host, una sola verificación puede propagarse en cascada a las cinco. El aislamiento por asiento es lo que mantiene a cada cuenta con el aspecto de su propio móvil en su propio bolsillo. No es un escudo antibaneos —nada lo es—, pero elimina la señal de vinculación más barata y evidente que dejan tiradas las nubes baratas que priorizan la densidad.

La regla que repetimos por todo este sitio: una cuenta, un asiento, una persona de proxy. La plataforma está construida para que ese sea el camino fácil, no la excepción.

Aporta tu propio proxy, enrutado por dispositivo

La identidad de red es la mitad de la batalla, así que el soporte de proxy es de primera clase, no una idea de última hora. Conectas tu propio proxy por asiento —móvil fijo o residencial— y ese asiento se enruta exclusivamente a través de él. No hay salida compartida forzada, ni pool misterioso donde tu cuenta hereda la reputación de desconocidos que usaron la misma IP la semana pasada.

• Enrutamiento por dispositivo: cada teléfono en la nube tiene su propia salida, fijada antes del primer inicio de sesión para que la cuenta nazca en la red en la que vivirá.
• IP móvil preferente: cuando el relato de la cuenta es «una persona con datos móviles», una salida móvil fija encaja con ese relato mucho mejor que una IP de centro de datos.
• Residencial como alternativa: un residencial de alta calidad funciona cuando el móvil no está disponible para la geografía que necesitas.

Deliberadamente no revendemos un pool de proxies propio como solución mágica. Tú controlas la higiene de red porque conoces la geografía y la tolerancia al riesgo de tus cuentas mejor de lo que cualquier valor por defecto podría. Consulta la página de Snapchat para ver por qué esto es innegociable en la app social más difícil.

ADB y API REST: automatiza sin romper la huella

Los operadores serios acaban queriendo automatización: instalaciones, copias de seguridad, configuración por script, chequeos de salud. La plataforma expone acceso ADB y una API REST para que puedas controlar los asientos mediante programación, pero el objetivo de diseño es que la automatización no aplane todos los asientos en la misma máquina.

La trampa de la automatización ingenua es que hace que todos tus dispositivos se comporten de forma idéntica: la misma cadencia, los mismos tiempos, las mismas acciones, el mismo orden. Esa uniformidad es en sí misma una huella. La API está para gestionar inventario y aprovisionamiento; no es una licencia para ejecutar un mismo script al unísono en cincuenta cuentas calentadas. Empujamos a la gente hacia ADB y la API en los planes superiores precisamente porque se debe recurrir a ellos cuando tu proceso esté maduro, después del calentamiento humano, no en su lugar.

En la práctica: usa la API para levantar asientos, conectar proxies y controlar el inventario; usa ADB para instalaciones y mantenimiento; mantén humano el comportamiento que debe parecer humano. La automatización que respeta la huella es una ventaja. La automatización que la ignora es una máquina lenta de baneos.

Una identidad de dispositivo que aguanta semanas y meses

Un teléfono en la nube solo es útil si la cuenta que calentaste el lunes sigue en el mismo dispositivo el mes siguiente. La identidad del asiento está diseñada para ser estable entre reinicios y a lo largo de horizontes largos: las características de dispositivo de las que depende una cuenta calentada no cambian bajo tus pies cada vez que el asiento se reinicia.

Esta es la propiedad más infravalorada cuando la gente compara proveedores. Un asiento que recompone su identidad en silencio parece, para la app, un dispositivo completamente nuevo iniciando sesión en una cuenta establecida, que es exactamente la señal que dispara los bucles de verificación. La estabilidad es lo que permite que una cuenta envejezca con elegancia. Lo único que suele romperla eres tú: restaurar de fábrica un asiento calentado sin un plan de recuperación tira a la basura la identidad que tardaste días en construir. Trata un asiento calentado como infraestructura de producción, no como una máquina virtual desechable.

Versiones de Android y especificaciones por plan

Los recursos escalan con el plan, así que compras el asiento que se ajusta a la carga de trabajo en lugar de pagar de más por una prueba o quedarte corto en producción:

• Spark ($9): el asiento de prueba. Suficiente para confirmar que una app instala y abre sin problemas, hacer experimentos desechables y validar un proxy antes de comprometerte. Recursos de clase compartida; no es donde aparcar diez cuentas calentadas.
• Creator ($19): el asiento social de producción. Recursos dedicados para el trabajo social diario, listo para proxy, dimensionado para una cuenta real que de verdad mantienes abierta y caliente.
• Studio ($34): el asiento de flota. Añade espacio y acceso para la orquestación root/ADB/API cuando tu automatización es real y tu proceso está probado.

La versión exacta de Android y las especificaciones por asiento se detallan en la página de precios junto a cada plan; míralo ahí en lugar de fiarte de una cifra citada en un blog. El principio es simple: Spark para probarlo, Creator para ejecutarlo, Studio para escalarlo.

Disponibilidad siempre activa para sesiones calientes

Los emuladores funcionan mientras tu PC está despierto. Los teléfonos en la nube están hechos para permanecer encendidos. Esa diferencia es la clave para el trabajo social: sesiones calientes, presencia en segundo plano y la posibilidad de que un compañero de otra ciudad tome el control de un asiento sin que tu portátil esté abierto.

La disponibilidad siempre activa es lo que hace que una cuenta calentada se comporte como el móvil siempre encendido de una persona real, en lugar de como un dispositivo que solo existe durante tu horario de trabajo desde una única zona horaria. También es lo que hace posible el traspaso entre agencias: los asientos viven en la plataforma, no en el escritorio de alguien. No citaremos un porcentaje de disponibilidad que no podamos sostener, pero la intención de diseño son asientos duraderos y persistentes que puedes nombrar, dotar de proxy, auditar y traspasar. Explora el modelo completo en la página de dispositivos en la nube.