Doubao libera gradualmente a automação de aplicativos no celular, enquanto grandes plataformas recusam acesso

Prazo de aviso de 30 dias termina, mas grandes aplicativos continuam fora do alcance

Em 14 de outubro, o Doubao Phone Assistant anunciou que começaria a liberar gradualmente o acesso de aplicativos de terceiros à automação de tela, após concluir um período de aviso público de 30 dias sobre seu Protocolo de Execução de Automação de Tela (SAEP). Os desenvolvedores ainda podem recusar o acesso após esse período, e o assistente não operará aplicativos que tenham rejeitado explicitamente a automação.

A lista de recusas inclui muitos serviços que tornariam um assistente de celular útil para tarefas do dia a dia. Entre os aplicativos do ecossistema Alibaba estão Taobao, Tmall, Cainiao, Alipay, DingTalk e Ele.me. Do ecossistema Tencent, constam WeChat, QQ, Honor of Kings e League of Legends: Wild Rift. A lista também inclui Meituan, Pinduoduo, Kuaishou, Xiaohongshu, Zhihu, China Merchants Bank e Industrial and Commercial Bank of China.

A mudança, portanto, amplia o acesso, mas não dá controle irrestrito sobre o celular. Ela substitui a exigência temporária de que os desenvolvedores aceitem ativamente a automação por um mecanismo que libera gradualmente os aplicativos elegíveis, a menos que seus desenvolvedores tenham recusado o acesso ou configurado restrições. As regras de segurança do sistema, a autorização do usuário e as verificações próprias de cada aplicativo continuam valendo.

O Doubao afirma que os desenvolvedores podem enviar uma recusa a qualquer momento e que a plataforma responderá em até três dias úteis. Esse compromisso de resposta não equivale a uma garantia publicada de que todos os pedidos serão implementados nesse prazo. O anúncio diz que as operações relevantes serão desativadas prontamente, mas não estabelece um prazo universal separado para a implementação.

Para os usuários, a questão prática é quais etapas de uma tarefa o assistente consegue concluir. Um aplicativo pode estar totalmente indisponível, uma página sensível pode ser bloqueada ou a etapa final pode exigir que o usuário assuma o controle. O SAEP prevê mecanismos para os três casos.

O que muda após o período de aviso?

Durante o período de aviso público, o Doubao limitou a automação a aplicativos do sistema, aplicativos da ByteDance e serviços de terceiros que tivessem concordado explicitamente em participar por meio do SAEP ou de comunicação por e-mail oficial. Por padrão, os demais aplicativos não eram operados.

Após o período de aviso, aplicativos cujos desenvolvedores não tenham apresentado uma recusa pelos canais oficiais nem configurado uma política de desativação passam a ser candidatos ao acesso gradual. A explicação do plano divulgada em setembro dizia que essa liberação dependeria dos níveis de risco, em vez de ocorrer simultaneamente em todos os aplicativos.

Essa distinção é importante para interpretar uma tarefa que não foi concluída. Antes de 14 de outubro, um aplicativo poderia estar inacessível simplesmente porque seu desenvolvedor não havia concordado ativamente em participar. Depois da mudança, o acesso ainda pode falhar por causa de uma recusa, de uma restrição de página, de uma verificação de identidade, da exigência de confirmação do usuário ou dos próprios controles de segurança do aplicativo.

A versão para consumidores do assistente foi lançada em 14 de setembro, com a função de operar o celular em fase beta. Outras funções, como os serviços inteligentes do Doubao, a assistência em compras, os resumos de gravações e as tarefas de trabalho, são independentes da permissão de cada aplicativo externo para automação de tela.

Como a implementação chegou a 14 de outubro

A mudança na política vem após conflitos anteriores entre a operação automatizada do celular e os sistemas de segurança dos aplicativos. Em dezembro de 2025, a primeira prévia da tecnologia de celular do Doubao enfrentou problemas de login no WeChat, desafios de verificação no Taobao e aplicativos bancários que interromperam operações de login ou pagamento ao identificar um ambiente de risco.

O lançamento posterior para consumidores estabeleceu um processo formal de declaração antes de ampliar o acesso. Os principais acontecimentos foram:

• Dezembro de 2025: O Nubia M153 apresentou a automação de celular do Doubao, seguida por restrições e desafios de segurança em vários grandes aplicativos.
• 14 de setembro de 2026: O assistente para consumidores lançou a versão beta da operação do celular, e começou o período de aviso de 30 dias. Alguns usuários do M153 relataram ter perdido tarefas automatizadas que antes estavam disponíveis.
• 16 de setembro: O Nubia NaviX Ultra chegou ao mercado com o assistente para consumidores. Reportagens descrevem essa data como o lançamento ou o início das vendas.
• 17 de setembro: O Doubao esclareceu que os desenvolvedores ainda poderiam recusar a automação após o período de aviso.
• 14 de outubro: O Doubao anunciou o fim do período de aviso e a liberação gradual do acesso de terceiros elegíveis.

Para quem já usava os recursos, as restrições de setembro podem ter parecido uma perda de funcionalidade. Reportagens descreveram proprietários do M153 que já não conseguiam usar tarefas automatizadas conhecidas, como chamar um carro, pedir comida e outras. Essas restrições refletiam as regras temporárias de permissão, não eram prova de que todos os desenvolvedores afetados haviam rejeitado o assistente.

Quais aplicativos recusaram o acesso?

A lista de recusas divulgada em 14 de outubro vai além de Alibaba e Tencent. Reportagens também mencionam DeepSeek, WPS e Vipshop, além de aplicativos de compras, redes sociais, bancos e serviços locais. Aplicativos da China Mobile, China Unicom e China Telecom também foram descritos como tendo recusado o acesso.

Essas restrições afetam o Nubia M153 e o Nubia NaviX Ultra. Sua importância está menos no número total de aplicativos e mais nos serviços que abrangem. Uma tarefa de compra pode chegar a um marketplace indisponível, uma tarefa de comunicação pode parar em um aplicativo de mensagens e uma tarefa financeira pode enfrentar tanto a recusa do desenvolvedor quanto requisitos separados de segurança do sistema.

As descrições publicadas não contabilizam completamente todos os aplicativos acessíveis e inacessíveis. Uma reportagem anterior afirmou que 90% dos aplicativos usados com frequência haviam passado a oferecer suporte progressivo ao agente de interface gráfica do Doubao, mas não informou o método de medição nem o grupo completo considerado. Esse dado não permite determinar a proporção de aplicativos acessíveis pelas regras de outubro.

As descrições de setembro dos serviços compatíveis mencionaram Cao Cao Mobility, Qishui Music e Feishu Minutes. A presença de um serviço em uma lista de compatibilidade com a operação do celular não comprova, por si só, que seu desenvolvedor tenha concluído todas as etapas da integração técnica ao SAEP. O suporte a uma tarefa e a adoção do protocolo são questões relacionadas, mas distintas.

O que o SAEP realmente controla

O guia oficial de integração do Doubao descreve o SAEP como um protocolo por meio do qual aplicativos Android definem limites para um agente de interface gráfica. Um agente de interface gráfica interpreta uma interface e executa ações, como clicar em botões ou inserir texto, sem depender exclusivamente da interface de software dedicada do aplicativo.

O guia informa que há suporte a ObricUI versão 2.2 ou superior. Isso não significa que o SAEP funcione em todos os celulares Android. Os desenvolvedores precisam verificar se o recurso está disponível e ativado no dispositivo de destino. Se essa verificação falhar, os aplicativos devem continuar dependendo de seus próprios controles de segurança.

As restrições funcionam em três níveis: App, que abrange o aplicativo inteiro; Activity, que abrange uma tela ou página específica do Android; e Intent, que abrange uma ação de negócio, como publicar ou excluir conteúdo. Aqui, intent significa a finalidade de uma operação, não apenas o botão visível tocado pelo assistente.

Essa estrutura permite que um aplicativo autorize alguma assistência enquanto protege etapas sensíveis. Ele pode proibir toda atividade do agente usando global_disable, impedir capturas de tela com screenshot_disable ou bloquear cliques simulados e a inserção de texto com input_disable. Outros controles abrangem alterações de conteúdo, publicação final, exclusão e benefícios promocionais ou recompensas.

Uma ação permitida ainda exige autorização

O guia oficial destaca uma distinção central entre a permissão do aplicativo e a decisão final do sistema. O resultado depende da identidade e do status de confiança do agente, dos requisitos básicos de segurança do sistema, da política declarada pelo aplicativo e da autorização do usuário para a tarefa em questão.

Os aplicativos não podem enfraquecer os requisitos básicos do sistema. Se o sistema exigir bloqueio ou intervenção do usuário, um aplicativo não poderá transformar esse resultado em permissão. Quando várias regras aplicáveis entram em conflito, prevalece a mais restritiva. Se houver falha na interpretação da política, o sistema recorre à política padrão utilizável do aplicativo e registra o motivo.

O guia descreve três resultados principais. ALLOW permite o recurso de sistema pertinente, mas não elimina os requisitos de autenticação do aplicativo nem a autorização do usuário. BLOCK interrompe a ação e não deve levar o assistente a buscar outra maneira de contornar a restrição. CALL_USER pausa a automação para uma confirmação do sistema ou para que o usuário assuma o controle manualmente.

Uma confirmação vale apenas para a etapa específica exibida ao usuário. Ela não é uma autorização geral para todas as ações posteriores. Pagamentos, transferências, autenticação de conta, publicação, exclusão e mudanças de permissões estão entre as atividades sensíveis para as quais o sistema pode exigir confirmação, intervenção do usuário ou recusa.

Uma quarta indicação, CLARIFY, aparece na documentação para pedidos de esclarecimento ou restrições mais flexíveis. Seu significado e sua disponibilidade exatos dependem do pacote de software de destino. O guia também alerta os desenvolvedores para não presumirem que a ordem das regras App, Activity e Intent permita que uma regra posterior substitua uma restrição anterior.

As restrições precisam funcionar além das promessas do assistente

A principal afirmação técnica do SAEP é que as restrições devem funcionar nos pontos de controle do sistema, em vez de depender apenas de o agente decidir obedecê-las. O acesso a capturas de tela, a leitura por acessibilidade, os cliques e a entrada simulada devem passar por fluxos de execução controlados.

O guia apresenta exemplos concretos. Uma proibição definida pelo aplicativo pode impedir que ele seja aberto na tela virtual do agente. Uma restrição a capturas de tela pode usar uma camada de exibição segura. Limites de entrada podem impedir ações simuladas no fluxo de gerenciamento de entrada do Android.

Há uma ressalva importante: a aplicação integral das restrições sobre a finalidade da operação depende da versão do sistema de destino. Os desenvolvedores não devem aceitar como prova suficiente de aplicação técnica de uma restrição a publicação, a exclusão ou a recompensa a afirmação do agente de que a cumpriu.

A integração básica recomendada é uma política estática incluída no pacote do aplicativo. O sistema a lê e armazena em cache quando o aplicativo é instalado ou atualizado, sem exigir que o processo do aplicativo esteja em execução. Atualizações dinâmicas opcionais permitem que as regras mudem conforme o status do usuário ou as condições de negócio. Elas devem usar números de versão crescentes, e uma atualização malsucedida precisa preservar a política válida anterior.

Registros de auditoria documentam as ações, mas têm prazo de retenção limitado

O protocolo oferece interfaces para que os aplicativos consultem os agentes registrados e os registros de auditoria relacionados ao próprio aplicativo. As informações de identidade podem incluir identificador do agente, nome do pacote, assinatura, tipo, status de confiança e versão. O simples registro não significa que um agente esteja autorizado para todas as ações de negócio.

O projeto de auditoria registra tanto a decisão da política quanto o resultado real da execução. Isso permite que os desenvolvedores diferenciem uma ação permitida que falhou de uma ação rejeitada seguida por uma tentativa de contornar a restrição. Os registros podem associar um agente a uma sessão, etapa de tarefa, aplicativo de destino, página, tipo de ação, versão da política e código do motivo.

O guia recomenda limitar as informações divulgadas: os registros de auditoria não devem conter capturas de tela sem tratamento, informações pessoais sensíveis inseridas pelos usuários nem árvores completas de controles da interface. Os aplicativos só podem consultar registros associados ao próprio pacote, sem inspecionar o histórico de outros aplicativos.

Os registros ficam armazenados em uma área segura do dispositivo e são mantidos por padrão durante 60 dias. A exclusão rotativa também começa quando o banco de dados ultrapassa 100 MB ou o número de registros passa de 100 mil. Esses são critérios alternativos; por isso, em um dispositivo com uso intenso, os registros antigos podem ser apagados antes dos 60 dias. Os recursos de consulta, exportação e retenção dependem da versão do sistema.

O Doubao também descreveu separadamente a preferência por processar informações sensíveis no dispositivo. A equipe afirma que os dados que precisam chegar à nuvem recebem criptografia adicional no aparelho e que a chave correspondente é destruída após a sessão. Essas são práticas de projeto declaradas, não uma confirmação independente de que todos os fluxos de trabalho implementados as cumpram.

O direito de escolha do usuário e o controle dos desenvolvedores continuam em tensão

O SAEP oferece aos desenvolvedores uma forma estruturada de recusar ou limitar a automação, mas isso não encerra o debate jurídico sobre se um assistente que age em nome do usuário precisa de autorização separada de cada aplicativo. As regras operacionais do protocolo e a situação jurídica da autorização do usuário são questões diferentes.

Ge Jiangqiu, professor associado da Faculdade de Direito da Universidade Fudan, argumenta que um agente essencialmente auxilia o usuário ou age em seu nome, e que os efeitos jurídicos de suas ações cabem a esse usuário. Wu Peicheng, pesquisador da Faculdade de Direito Guanghua da Universidade de Zhejiang, defende uma abordagem baseada em uma única autorização do usuário e argumenta que exigir permissão adicional das plataformas restringiria o uso cotidiano e elevaria os custos do setor.

Zhai Wei, diretor executivo do Centro de Pesquisa em Direito da Concorrência da Universidade de Ciência Política e Direito da China Oriental, aborda o acesso entre aplicativos pelo prisma do controle do usuário sobre seus dados pessoais, incluindo a portabilidade e a exclusão. Huang Yinxu, professor associado da Faculdade de Direito da Universidade Renmin da China, também argumenta que uma autorização válida do sistema não deveria exigir permissões repetidas de plataformas externas quando um agente executa corretamente as instruções do usuário.

Essas são posições acadêmicas, não uma decisão judicial que elimina as restrições impostas pelos desenvolvedores. Na prática, a abordagem anunciada pelo Doubao respeita recusas explícitas. Portanto, pelas regras operacionais do assistente, uma instrução do usuário não se sobrepõe à proibição de um aplicativo.

O que os usuários podem esperar daqui para a frente

A versão do NaviX Ultra com 12 GB de memória e 512 GB de armazenamento foi anunciada por 5.999 yuans, com preço inicial de 5.499 yuans após o subsídio nacional. A redução é de 500 yuans, ou cerca de 8,3% do preço anunciado. Comprar o aparelho não garante acesso a todos os aplicativos nem a conclusão de todas as tarefas.

As demonstrações do Doubao mostram a experiência pretendida: um assistente usando a câmera para localizar um armário dentro das dimensões e do orçamento especificados, ou usando um endereço conhecido para chamar um carro. Essas demonstrações ilustram fluxos de trabalho planejados, mas não comprovam que todos os serviços de transporte ou compras os permitam segundo as regras atuais.

Não foi divulgado um cronograma detalhado para que aplicativos específicos se tornem acessíveis após 14 de outubro. As descrições publicadas também não estabelecem uma taxa definitiva de aceitação, um calendário completo de implementação nem uma aplicação técnica uniforme de todas as restrições de intent nas versões compatíveis.

O próximo teste prático será saber se os usuários recebem explicações previsíveis quando uma tarefa é interrompida: recusa do desenvolvedor, página protegida, regra de segurança do sistema ou pedido de confirmação pessoal. A liberação gradual amplia o alcance possível do assistente, enquanto o SAEP determina até onde esse alcance pode ir.

Pontos principais

• Em 14 de outubro, o Doubao anunciou a liberação gradual da automação de tela em aplicativos de terceiros, após um período de aviso de 30 dias.
• O assistente não operará aplicativos que recusem explicitamente o acesso.
• A lista de recusas inclui grandes serviços da Alibaba e da Tencent, bancos, plataformas de compras e outros aplicativos populares.
• Os desenvolvedores ainda podem recusar o acesso, e o Doubao se comprometeu a responder em até três dias úteis.
• O SAEP permite impor restrições a aplicativos inteiros, páginas específicas e ações de negócio determinadas.
• Os requisitos de segurança do sistema e a autorização do usuário continuam necessários mesmo quando um aplicativo permite a automação.
• O guia oficial especifica o ObricUI 2.2 ou superior, e alguns recursos dependem da versão de destino.
• Não foi divulgado um cronograma detalhado para a liberação de aplicativos específicos.