Plataforma
O plano de controlo sob os seus assentos sociais.
Assentos que não se misturam
A separação de cliente e conta é o produto.
🧱 Isolamento de instância
Armazenamento e identidade independentes por assento.
👤 Ligação de conta
Assentos pagos aparecem sob o seu login.
🔐 Autenticação de sessão
Cookies HttpOnly, palavras-passe com hash.
Ganchos de operador
Potência para uma mesa, não um demo brinquedo.
🔌 ADB
Automatize quando o processo estiver pronto.
📍 Controlo GPS
Em tiers cloud superiores.
🌐 Anexar proxy
Traga as suas saídas.
🛠 Root / API
Studio e acima.
Faturação crypto-nativa
Sem teatro de cartão.
₿ Faturas OxaPay
Grandes moedas suportadas.
📅 Mensal / anual
Anual poupa dois meses.
💳 Recargas de saldo
Crédito pré-pago na área de cliente.
O modelo de isolamento: um posto, uma identidade
A razão de ser de uma plataforma de Android remoto — em vez de dez janelas de emulador num só portátil — é a separação. Na CloudPhoneHub, cada telemóvel na cloud é um posto autónomo: o seu próprio espaço de utilizador Android, o seu próprio armazenamento, a sua própria identidade de dispositivo e a sua própria saída de rede. Os postos não partilham um pool de fingerprints, e os postos de um cliente não são silenciosamente extraídos do mesmo modelo de identidade dos de outro.
Isto importa sobretudo no trabalho multiconta. As plataformas raramente banem uma única conta no vácuo — associam contas que parecem o mesmo dispositivo, a mesma instalação ou a mesma rede, e depois agem sobre todo o cluster. Se cinco logins partilham sinais de identidade ao nível do host, um único desafio pode alastrar a cinco. O isolamento por posto é o que mantém cada conta com o aspeto do seu próprio telemóvel no seu próprio bolso. Não é um escudo contra banimentos — nada é — mas remove o sinal de associação mais barato e óbvio que as clouds baratas focadas em densidade deixam à vista.
A regra prática que repetimos por todo este site: uma conta, um posto, uma persona de proxy. A plataforma foi construída para tornar esse o caminho fácil, não a exceção.
Traga o seu próprio proxy, encaminhado por dispositivo
A identidade de rede é metade da batalha, por isso o suporte de proxy é de primeira classe e não uma reflexão tardia. Liga o seu próprio proxy por posto — móvel fixo ou residencial — e esse posto encaminha exclusivamente através dele. Não há saída partilhada forçada, nem pool misterioso onde a sua conta herda a reputação de estranhos que usaram o mesmo IP na semana passada.
- Encaminhamento por dispositivo — cada telemóvel na cloud tem a sua própria saída, definida antes do primeiro login para que a conta nasça na rede em que vai viver.
- IP móvel preferível — quando a história da conta é «uma pessoa em dados móveis», uma saída móvel fixa corresponde a essa história muito melhor do que um IP de datacenter.
- Residencial como alternativa — um residencial de alta qualidade funciona quando o móvel não está disponível para a geografia de que precisa.
Deliberadamente não revendemos um pool de proxies da casa como solução mágica. Você controla a higiene de rede porque conhece a geografia e a tolerância ao risco das suas contas melhor do que qualquer predefinição alguma vez conseguiria. Veja a página do Snapchat para perceber porque isto é inegociável na app social mais difícil.
ADB e API REST: automatize sem quebrar a fingerprint
Os operadores a sério acabam por querer automação — instalações, backups, configuração por script, verificações de saúde. A plataforma expõe acesso ADB e uma API REST para poder conduzir os postos programaticamente, mas o objetivo do design é que a automação não achate todos os postos na mesma máquina.
A armadilha da automação ingénua é fazer com que todos os seus dispositivos se comportem de forma idêntica: a mesma cadência, os mesmos tempos, as mesmas ações, a mesma ordem. Essa uniformidade é, ela própria, uma fingerprint. A API existe para gerir inventário e aprovisionamento; não é uma licença para correr um script em sincronia perfeita em cinquenta contas aquecidas. Orientamos as pessoas para o ADB e a API nos níveis superiores precisamente porque devem ser usados quando o processo está maduro — depois do aquecimento humano, não em vez dele.
Na prática: use a API para levantar postos, ligar proxies e acompanhar inventário; use o ADB para instalações e manutenção; mantenha o comportamento de aspeto humano com aspeto humano. A automação que respeita a fingerprint é uma vantagem. A automação que a ignora é uma máquina lenta de banimentos.
Identidade de dispositivo que se mantém durante semanas e meses
Um telemóvel na cloud só é útil se a conta que aqueceu na segunda-feira continuar no mesmo dispositivo no mês seguinte. A identidade do posto foi concebida para ser estável entre reinícios e em horizontes longos — as características de dispositivo de que uma conta aquecida depende não mudam por baixo dos seus pés sempre que o posto reinicia.
Esta é a propriedade mais subestimada quando as pessoas comparam alojamentos. Um posto que, em silêncio, volta a gerar a sua identidade parece, para a app, um dispositivo novinho em folha a iniciar sessão numa conta estabelecida — que é exatamente o sinal que desencadeia os ciclos de verificação. A estabilidade é o que permite que uma conta envelheça com graça. A principal coisa que a quebra é você: fazer reset de fábrica a um posto aquecido sem um plano de recuperação deita fora a identidade que passou dias a construir. Trate um posto aquecido como infraestrutura de produção, não como uma VM descartável.
Versões de Android e especificações por nível
Os recursos escalam com o plano, por isso compra o posto que corresponde à carga de trabalho em vez de pagar demais por um teste ou de subdimensionar a produção:
- Spark ($9) — o posto de teste. Suficiente para confirmar que uma app instala e abre de forma limpa, correr experiências descartáveis e validar um proxy antes de se comprometer. Recursos de classe partilhada; não é onde estaciona dez contas aquecidas.
- Creator ($19) — o posto social de produção. Recursos dedicados para o trabalho social diário, pronto para proxy, dimensionado para uma conta real que mantém mesmo aberta e aquecida.
- Studio ($34) — o posto de frota. Acrescenta espaço e acesso para orquestração root/ADB/API quando a sua automação é real e o seu processo está provado.
A versão exata de Android e as especificações por posto estão listadas na página de preços junto a cada nível — consulte aí em vez de confiar num número citado num blogue. O princípio é simples: Spark para provar, Creator para operar, Studio para escalar.
Disponibilidade permanente para sessões aquecidas
Os emuladores correm enquanto o seu PC estiver ligado. Os telemóveis na cloud são feitos para ficar de pé. Essa diferença é o cerne do trabalho social: sessões aquecidas, presença em segundo plano e a capacidade de um colega noutra cidade assumir um posto sem o seu portátil estar aberto.
A disponibilidade permanente é o que faz uma conta aquecida comportar-se como o telemóvel sempre ligado de uma pessoa real, e não como um dispositivo que só existe durante as suas horas de trabalho a partir de um fuso horário. É também o que torna possível a passagem de testemunho numa agência — os postos vivem na plataforma, não na secretária de alguém. Não vamos citar uma percentagem de uptime que não conseguimos defender, mas a intenção do design são postos duráveis e persistentes que pode nomear, ligar a proxy, auditar e passar a outros. Explore o modelo completo na página de dispositivos cloud.
Perguntas frequentes
Posso usar o meu próprio proxy?
Sim — esse é o modelo pretendido, não um contorno. Liga o seu próprio proxy móvel fixo ou residencial por posto, e esse telemóvel na cloud encaminha exclusivamente através dele. Defina o proxy antes do primeiro login para que a conta nasça na saída em que vai viver. Não forçamos um pool partilhado da casa, porque as saídas em pool são uma das formas mais rápidas de associar acidentalmente contas «não relacionadas» através de um IP comum.
Suportam ADB e automação?
Sim. A plataforma expõe acesso ADB e uma API REST, com root/API orientados para o nível Studio, onde a orquestração de frotas faz sentido. Use-os para aprovisionamento, instalações, backups e inventário. A única ressalva que repetimos: não corra scripts idênticos em sincronia perfeita em muitos postos aquecidos — o comportamento uniforme é, ele próprio, uma fingerprint. Aqueça as contas como um humano primeiro, depois automatize a manutenção à volta disso.
Quão estável é a identidade do dispositivo?
A identidade do posto foi concebida para se manter entre reinícios e ao longo de semanas e meses, para que uma conta aquecida permaneça num dispositivo de aspeto consistente em vez de parecer que inicia sessão de um telemóvel novinho em folha a cada reinício. O que mais frequentemente quebra a estabilidade é um reset de fábrica de um posto aquecido sem um plano de recuperação — por isso trate os postos aquecidos como infraestrutura de produção. Não vamos inventar uma estatística de retenção específica; o objetivo de design é a estabilidade em horizonte longo, e você preserva-a ao não reconstruir os postos sem necessidade.
Use a plataforma em assentos reais
Comece com Creator para produção social.