O prazo de 30 dias termina, mas as principais aplicações continuam inacessíveis
O Doubao Phone Assistant anunciou, a 14 de outubro, que iria começar a permitir gradualmente o acesso de aplicações de terceiros à automatização do ecrã, após concluir um período de consulta pública de 30 dias sobre o seu Protocolo de Execução de Automatização do Ecrã (SAEP). Os programadores ainda podem recusar o acesso após esse período, e o assistente não irá operar aplicações que tenham rejeitado explicitamente a automatização.
Índice
- O prazo de 30 dias termina, mas as principais aplicações continuam inacessíveis
- O que muda após o período de consulta?
- Como se chegou a 14 de outubro
- Que aplicações recusaram o acesso?
- O que controla realmente o SAEP
- Uma ação permitida continua a exigir autorização
- As restrições têm de funcionar para além das promessas do assistente
- Os registos de auditoria documentam as ações, com limites de conservação
- A escolha do utilizador e o controlo dos programadores continuam em tensão
- O que podem esperar os utilizadores
- Pontos principais
A lista de recusas abrange muitos dos serviços que tornariam um assistente telefónico útil nas tarefas do dia a dia. Entre as aplicações do ecossistema Alibaba estão Taobao, Tmall, Cainiao, Alipay, DingTalk e Ele.me. O ecossistema Tencent inclui WeChat, QQ, Honor of Kings e League of Legends: Wild Rift. A lista inclui ainda Meituan, Pinduoduo, Kuaishou, Xiaohongshu, Zhihu, China Merchants Bank e Industrial and Commercial Bank of China.
A alteração representa, portanto, uma expansão do acesso, não um controlo irrestrito do telemóvel. Substitui a exigência temporária de aceitação ativa da automatização por parte dos programadores por um mecanismo que permite gradualmente o acesso às aplicações elegíveis, salvo recusa dos respetivos programadores ou configuração de restrições. Continuam a aplicar-se as regras de segurança do sistema, a autorização do utilizador e os controlos próprios de cada aplicação.
A Doubao afirma que os programadores podem apresentar uma recusa a qualquer momento e que a plataforma responderá no prazo de três dias úteis. Esse compromisso de resposta não equivale a uma garantia publicada de que todos os pedidos serão executados nesse prazo. O anúncio diz que as operações relevantes serão desativadas rapidamente, sem estabelecer um prazo universal de implementação.
Para os utilizadores, a questão prática é saber que partes de uma tarefa o assistente consegue concluir. Uma aplicação pode estar totalmente indisponível, uma página sensível pode ser bloqueada ou a etapa final pode exigir que o utilizador assuma o controlo. O SAEP prevê mecanismos para estes três casos.
O que muda após o período de consulta?
Durante o período de consulta pública, a Doubao limitou a automatização às aplicações do sistema, às aplicações ByteDance e a serviços de terceiros que tivessem concordado explicitamente em participar através do SAEP ou de comunicações por correio eletrónico oficial. Por defeito, as restantes aplicações não eram operadas.
Após o período de consulta, as aplicações cujos programadores não tenham apresentado uma recusa por canais oficiais nem configurado uma política de desativação tornam-se elegíveis para acesso gradual. A explicação do plano, divulgada em setembro, indicava que essa abertura dependeria dos níveis de risco, em vez de consistir numa ativação simultânea em todas as aplicações.
Esta distinção é importante para interpretar uma tarefa que não foi concluída. Antes de 14 de outubro, uma aplicação podia estar inacessível simplesmente porque o respetivo programador ainda não tinha concordado ativamente em participar. Após a alteração, o acesso pode continuar a falhar devido a uma recusa, a uma restrição numa página, a uma verificação de identidade, à necessidade de confirmação do utilizador ou aos próprios controlos de segurança da aplicação.
A versão para consumidores do assistente foi lançada a 14 de setembro, com a funcionalidade de operação do telemóvel em versão beta. Outras funções, incluindo os serviços inteligentes da Doubao, a assistência em compras, os resumos de gravações e as tarefas profissionais, são independentes da autorização de uma aplicação externa específica para automatização do ecrã.
Como se chegou a 14 de outubro
A alteração da política surge na sequência de conflitos anteriores entre a operação automatizada do telemóvel e os sistemas de segurança das aplicações. Em dezembro de 2025, a primeira prévia tecnológica do telemóvel Doubao deparou-se com problemas de início de sessão no WeChat, desafios de verificação no Taobao e aplicações bancárias que interrompiam o início de sessão ou os pagamentos ao detetar um ambiente de risco.
O lançamento posterior para consumidores estabeleceu um processo formal de declaração antes de alargar o acesso. Os principais desenvolvimentos foram:
- Dezembro de 2025: O Nubia M153 introduziu a automatização do telemóvel Doubao, seguida de restrições e desafios de segurança em várias aplicações importantes.
- 14 de setembro de 2026: O assistente para consumidores lançou a versão beta da funcionalidade de operação do telemóvel e teve início o período de consulta de 30 dias. Alguns utilizadores do M153 disseram ter perdido tarefas automatizadas que estavam anteriormente disponíveis.
- 16 de setembro: O Nubia NaviX Ultra chegou ao mercado com o assistente para consumidores. As notícias referem esta data como a do lançamento ou do início das vendas.
- 17 de setembro: A Doubao esclareceu que os programadores ainda poderiam recusar a automatização após o período de consulta.
- 14 de outubro: A Doubao anunciou o fim do período de consulta e a abertura gradual do acesso elegível a aplicações de terceiros.
Para os utilizadores existentes, as restrições de setembro podem ter parecido uma perda de funcionalidades. As notícias descreveram proprietários do M153 que deixaram de poder recorrer a tarefas automatizadas habituais, como chamar um veículo, encomendar comida e realizar outras operações. Essas restrições refletiam as regras temporárias de autorização, não provando que todos os programadores afetados tivessem rejeitado o assistente.
Que aplicações recusaram o acesso?
A lista de recusas de 14 de outubro vai além da Alibaba e da Tencent. As notícias também identificam a DeepSeek, a WPS e a Vipshop, além de aplicações de compras, redes sociais, serviços bancários e serviços locais. As aplicações da China Mobile, China Unicom e China Telecom também foram referidas como recusando o acesso.
Estas restrições afetam o Nubia M153 e o Nubia NaviX Ultra. A sua importância reside menos no número bruto de aplicações do que nos serviços abrangidos. Uma tarefa de compras pode deparar-se com um mercado indisponível, uma tarefa de comunicação pode ficar bloqueada numa aplicação de mensagens e uma tarefa financeira pode estar sujeita tanto a uma recusa do programador como a requisitos de segurança do sistema.
As descrições publicadas não constituem uma contagem completa de todas as aplicações acessíveis e inacessíveis. Uma notícia anterior afirmava que 90% das aplicações usadas com frequência tinham vindo a suportar progressivamente o agente GUI da Doubao, mas não identificava o método de medição nem o universo considerado. Esse número não permite determinar a proporção de aplicações acessíveis ao abrigo das regras de outubro.
As descrições de setembro dos serviços suportados mencionavam a Cao Cao Mobility, a Qishui Music e o Feishu Minutes. A inclusão de um serviço numa lista de suporte à operação do telemóvel não prova, por si só, que o respetivo programador tenha concluído todas as fases da integração técnica do SAEP. O suporte a uma tarefa e a adoção do protocolo são questões relacionadas, mas distintas.
O que controla realmente o SAEP
O guia oficial de integração da Doubao descreve o SAEP como um protocolo através do qual as aplicações Android definem os limites de um agente GUI. Um agente GUI compreende uma interface gráfica e executa ações, como carregar em botões ou introduzir texto, em vez de depender exclusivamente de uma interface de software específica da aplicação.
O guia indica suporte para ObricUI versão 2.2 e posteriores. Isto não significa que o SAEP funcione em todos os telemóveis Android. Os programadores têm de verificar se a funcionalidade está presente e ativada no dispositivo de destino. Se essa verificação falhar, as aplicações têm de continuar a depender dos seus próprios controlos de segurança.
As restrições aplicam-se a três níveis: App, que abrange toda a aplicação; Activity, que abrange um ecrã ou página Android específico; e Intent, que abrange uma ação comercial, como publicar ou eliminar conteúdo. Neste contexto, intent significa a finalidade de uma operação, não apenas o botão visível em que o assistente toca.
Esta estrutura permite que uma aplicação autorize alguma assistência, protegendo ao mesmo tempo etapas sensíveis. Pode proibir toda a atividade do agente através de global_disable, impedir capturas de ecrã através de screenshot_disable ou bloquear cliques simulados e a introdução de texto através de input_disable. Outros controlos abrangem a alteração de conteúdo, a publicação final, a eliminação e as recompensas ou vantagens promocionais.
Uma ação permitida continua a exigir autorização
O guia oficial estabelece uma distinção fundamental entre a permissão da aplicação e a decisão final do sistema. O resultado depende da identidade do agente e do seu estatuto de confiança, da base de segurança do sistema, da política declarada pela aplicação e da autorização do utilizador para a tarefa em curso.
As aplicações não podem enfraquecer a base de segurança do sistema. Se o sistema exigir o bloqueio ou a intervenção do utilizador, uma aplicação não pode converter esse resultado numa autorização. Quando várias regras aplicáveis entram em conflito, prevalece o resultado mais restritivo. Se a interpretação da política falhar, o sistema recorre à política predefinida utilizável da aplicação e regista o motivo.
O guia descreve três resultados principais. ALLOW autoriza a capacidade do sistema em causa, mas não elimina os requisitos de autenticação da aplicação ou de autorização do utilizador. BLOCK interrompe a ação e não deve levar o assistente a procurar outra forma de contornar a restrição. CALL_USER pausa a automatização para pedir uma confirmação do sistema ou a intervenção manual do utilizador.
Uma confirmação aplica-se apenas à etapa específica apresentada ao utilizador. Não constitui uma autorização geral para todas as ações seguintes. Pagamentos, transferências, autenticação de contas, publicação, eliminação e alterações de permissões estão entre as atividades sensíveis para as quais o sistema pode exigir confirmação, a intervenção do utilizador ou uma recusa.
Uma quarta designação, CLARIFY, surge na documentação para pedidos de esclarecimento ou restrições menos rígidas. O seu significado preciso e a sua disponibilidade dependem do pacote de software de destino. O guia também alerta os programadores para não presumirem que a ordem das regras App, Activity e Intent permite que uma regra posterior se sobreponha a uma restrição anterior.
As restrições têm de funcionar para além das promessas do assistente
A principal afirmação técnica do SAEP é que as restrições devem ser aplicadas nos pontos de controlo do sistema, em vez de dependerem apenas de o agente optar por as respeitar. O acesso a capturas de ecrã, a leitura através de acessibilidade, os cliques e a introdução simulada de dados devem passar por vias de execução controladas.
O guia apresenta exemplos concretos. Uma proibição ao nível da aplicação pode impedir que a aplicação visada seja apresentada no ecrã virtual do agente. Uma restrição a capturas de ecrã pode recorrer a uma camada de ecrã segura. Os limites à introdução de dados podem bloquear ações simuladas no percurso de gestão de entrada do Android.
Há uma ressalva importante: a aplicação integral de restrições relativas à intenção comercial depende da versão do sistema de destino. Os programadores não devem considerar suficiente a declaração de um agente de que cumpriu as regras para concluir que uma restrição à publicação, eliminação ou atribuição de recompensas está tecnicamente aplicada.
A integração básica recomendada consiste numa política estática incluída no pacote da aplicação. O sistema lê-a e guarda-a em cache quando a aplicação é instalada ou atualizada, sem exigir que o processo da aplicação esteja em execução. As atualizações dinâmicas opcionais permitem alterar as regras em função do estado do utilizador ou das condições comerciais. Estas atualizações têm de usar números de versão crescentes, e uma atualização falhada tem de preservar a política válida anterior.
Os registos de auditoria documentam as ações, com limites de conservação
O protocolo disponibiliza interfaces para as aplicações consultarem os agentes registados e os registos de auditoria relativos à própria aplicação. As informações de identidade podem incluir o identificador, o nome do pacote, a assinatura, o tipo, o estatuto de confiança e a versão do agente. O simples registo não significa que um agente esteja autorizado a executar todas as ações comerciais.
O sistema de auditoria regista tanto a decisão sobre a política como o resultado efetivo da execução. Isto permite aos programadores distinguir uma ação autorizada que falhou de uma ação rejeitada seguida de uma tentativa de contornar as regras. Os registos podem associar um agente a uma sessão, etapa da tarefa, aplicação de destino, página, tipo de ação, versão da política e código do motivo.
O guia recomenda limitar a divulgação: os registos de auditoria não devem conter capturas de ecrã em bruto, informações pessoais sensíveis introduzidas pelos utilizadores ou árvores completas de controlos da interface. As aplicações só podem consultar registos associados ao seu próprio pacote, sem aceder ao histórico de outras aplicações.
Os registos são guardados numa área segura do dispositivo e conservados por defeito durante 60 dias. A eliminação rotativa também tem início quando a base de dados ultrapassa os 100 MB ou o número de registos excede os 100 000. Estes são critérios alternativos, pelo que um dispositivo com muito movimento pode perder registos antigos antes de passarem 60 dias. As capacidades efetivas de consulta, exportação e conservação dependem da versão do sistema.
A Doubao descreveu separadamente a preferência por tratar informações sensíveis no dispositivo. A equipa afirma que os dados que têm de chegar à nuvem são encriptados localmente com uma proteção adicional, sendo a chave correspondente destruída após a sessão. Trata-se de práticas de conceção declaradas, não de uma confirmação independente de que todos os fluxos de trabalho implementados as cumprem.
A escolha do utilizador e o controlo dos programadores continuam em tensão
O SAEP dá aos programadores uma forma estruturada de recusar ou limitar a automatização, mas não resolve o debate jurídico sobre se um assistente que atua em nome do utilizador precisa de autorização separada de cada aplicação. As regras de funcionamento do protocolo e o estatuto jurídico da autorização do utilizador são questões distintas.
Ge Jiangqiu, professor associado da Faculdade de Direito da Universidade Fudan, defende que um agente essencialmente auxilia o utilizador ou atua em seu nome, cabendo a este os efeitos jurídicos das suas ações. Wu Peicheng, investigador da Faculdade de Direito Guanghua da Universidade de Zhejiang, apoia uma abordagem assente numa única autorização do utilizador e argumenta que exigir autorização adicional das plataformas restringiria o uso quotidiano e aumentaria os custos do setor.
Zhai Wei, diretor executivo do Centro de Investigação de Direito da Concorrência da Universidade de Ciência Política e Direito da China Oriental, aborda o acesso entre aplicações em termos do controlo do utilizador sobre os dados pessoais, incluindo a portabilidade e a eliminação. Huang Yinxu, professor associado da Faculdade de Direito da Universidade Renmin da China, defende igualmente que uma autorização válida do sistema não deve exigir permissões repetidas de plataformas externas quando um agente executa com precisão as instruções do utilizador.
Estas são posições académicas, não uma decisão judicial que anule as restrições dos programadores. Na prática, a abordagem anunciada pela Doubao respeita as recusas explícitas. Assim, as instruções do utilizador não se sobrepõem à proibição de uma aplicação no âmbito das regras de funcionamento do assistente.
O que podem esperar os utilizadores
A versão do NaviX Ultra com 12 GB de memória e 512 GB de armazenamento custava 5 999 yuans, com um preço inicial de 5 499 yuans após o subsídio nacional. Trata-se de uma redução de 500 yuans, ou cerca de 8,3% do preço anunciado. A compra do dispositivo não garante o acesso a todas as aplicações nem a conclusão de todas as tarefas.
As demonstrações da Doubao mostram a experiência pretendida: um assistente que usa a câmara para encontrar um armário com dimensões e orçamento definidos, ou que usa uma morada conhecida para chamar um veículo. Estas demonstrações ilustram fluxos de trabalho previstos, não provam que todos os serviços de compras ou transporte os permitam ao abrigo das regras atuais.
Não foi anunciado um calendário detalhado para tornar acessíveis aplicações específicas após 14 de outubro. As descrições publicadas também não estabelecem uma taxa de aceitação definitiva, um calendário completo de implementação ou uma aplicação técnica uniforme de todas as restrições relativas a intents nas versões suportadas.
O próximo teste prático é saber se os utilizadores recebem explicações previsíveis quando uma tarefa é interrompida: recusa do programador, página protegida, regra de segurança do sistema ou pedido de confirmação pessoal. A abertura gradual alarga o alcance possível do assistente, enquanto o SAEP determina onde esse alcance deve terminar.
Pontos principais
- A Doubao anunciou a abertura gradual da automatização do ecrã em aplicações de terceiros a 14 de outubro, após um período de consulta de 30 dias.
- O assistente não irá operar aplicações que recusem explicitamente o acesso.
- A lista de recusas inclui serviços importantes da Alibaba e da Tencent, bancos, plataformas de compras e outras aplicações populares.
- Os programadores ainda podem recusar o acesso, e a Doubao compromete-se a responder no prazo de três dias úteis.
- O SAEP permite aplicar restrições a aplicações inteiras, páginas específicas e ações comerciais concretas.
- Os requisitos de segurança do sistema e a autorização do utilizador continuam a ser necessários mesmo quando uma aplicação permite a automatização.
- O guia oficial especifica ObricUI 2.2 e versões posteriores, sendo algumas capacidades dependentes da versão de destino.
- Não foi anunciado um calendário detalhado para a abertura de aplicações específicas.






