Google Android App Functions Construíram uma Gaiola de Segurança, mas a Maioria dos Agentes de IA Continua do Lado de Fora
O Google criou para os agentes Android uma rota controlada para outros apps, mas a maioria dos usuários ainda não consegue ver, gerenciar ou usar essa rota de forma significativa. As Google Android App Functions agora definem como assistentes aprovados podem descobrir e executar ações específicas entre aplicações. O conflito é que a arquitetura de segurança chegou antes de um ecossistema amplo de agentes.
Isso é mais do que outro recurso inacabado do Android. O Google está decidindo quem pode agir dentro das aplicações, o que esses atores podem descobrir e quais operações os desenvolvedores expõem. Essas escolhas estabelecem o plano de controle para futuros agentes que criam notas, encontram fotos, iniciam mídia ou montam carrinhos de compras.
Elas também diferenciam a abordagem do Google de agentes que operam telefones interpretando telas e imitando toques. Sistemas que controlam a tela podem funcionar sem integração profunda com apps, mas continuam sensíveis a mudanças de layout e conteúdos enganosos. As App Functions oferecem um caminho mais limpo, embora apenas agentes aprovados e apps participantes possam utilizá-lo.
O Google já demonstrou integrações limitadas, incluindo o Gemini recuperando fotos por meio do Samsung Gallery. O Android 17 amplia ainda mais a estrutura. Ainda assim, um proprietário típico de Android não encontrará um painel universal de agentes repleto de assistentes de terceiros e ações compatíveis.
Essa lacuna explica a contradição aparente. A gaiola não está literalmente vazia, mas sua população continua pequena, controlada e difícil de ser inspecionada por usuários comuns. O Google protegeu a porta antes de abrir o mercado ao seu redor.
Google Android App Functions Mudaram a Forma como os Agentes Entram nos Apps
As App Functions substituem o controle simulado de telas por operações declaradas e estruturadas que o Android pode identificar e restringir.
Uma função de app é uma ação discreta que uma aplicação disponibiliza a um solicitante aprovado. Um app de notas pode expor “criar nota”, enquanto um app de mídia pode expor “reproduzir música”. O agente envia parâmetros estruturados em vez de navegar pela interface visível do app.
A estrutura oficial de App Functions descreve duas partes. Um app provedor declara uma ação, e um agente confiável a descobre e executa. O Android intermedeia a troca por meio de AppFunctionManager e serviços relacionados.
Essa arquitetura importa porque uma interface visual foi projetada para o julgamento humano. Uma pessoa percebe que um botão mudou de lugar, que o destinatário parece errado ou que o total de uma compra foi alterado. Um sistema automatizado pode continuar após interpretar mal a tela ou seguir instruções hostis incorporadas ao conteúdo exibido.
Funções estruturadas restringem a ação disponível. O agente não recebe controle ilimitado apenas porque pode pedir a um app que realize uma operação. O provedor define a função, suas entradas e o resultado que ela retorna.
O Android também acompanha se uma função está habilitada. Uma solicitação de execução pode falhar se a função não existir, não puder ser encontrada ou estiver indisponível. Isso cria um limite mais claro do que conceder a um agente acesso geral à interface da aplicação.
A estrutura chegou à plataforma no nível de API 36, a versão associada ao Android 16. A documentação do Google continua descrevendo as App Functions como uma prévia beta ou experimental. O Android 17 adiciona registro em tempo de execução, funções vinculadas a atividades, níveis de acesso atualizados e controles de descoberta mais detalhados.
Essas mudanças mostram que o Google trata a autonomia entre apps como uma preocupação do sistema operacional. A empresa não está deixando que cada desenvolvedor de assistentes invente uma camada privada de integração. A plataforma fornece identificadores comuns, metadados, gerenciamento de estado, solicitações, respostas e verificações de permissão.
A distinção fica mais clara em um cenário simples de anotações. Um agente recebe a instrução: “Salve o endereço do hotel nas minhas notas de viagem.” Ele procura uma função compatível, identifica o app de destino, fornece o título e o conteúdo e recebe um resultado.
Um agente que controla a tela, por sua vez, abriria o app, localizaria um botão, escolheria um caderno, selecionaria um campo de texto, inseriria o conteúdo e pressionaria salvar. Cada transição visual adiciona outro ponto em que ambiguidade ou manipulação pode entrar na sequência.
As App Functions não garantem que um agente tenha entendido a solicitação original. Elas também não comprovam que um app implementou sua ação com segurança. Elas reduzem a superfície de ataque ao substituir uma jornada de interface aberta por uma operação que os desenvolvedores declararam explicitamente.
Essa é a primeira mudança importante. O Android agora possui um vocabulário nativo para agentes que agem dentro das aplicações, em vez de apenas falar sobre essas aplicações ou abrir suas telas.
A segunda mudança é menos visível. O Android coloca a execução entre apps atrás de permissões que aplicações comuns não podem simplesmente assumir. Essa decisão transforma as App Functions de uma API de conveniência em um sistema de controle de acesso.
O Modelo de Permissões Coloca Google e Fabricantes de Dispositivos no Controle
A vantagem de segurança vem da limitação de solicitantes capazes, mas a mesma restrição mantém agentes Android independentes do lado de fora do portão.
Uma aplicação pode executar suas próprias funções sem autoridade especial. A execução entre pacotes é diferente. O AppFunctionManager exige que o agente solicitante tenha uma permissão Android autorizada para descobrir ou executar funções em outros apps.
O trabalho original da estrutura Android atribuiu EXECUTE_APP_FUNCTIONS a aplicações pré-instaladas ou de sistema que detêm o papel de assistente. Uma permissão confiável relacionada atendia componentes de inteligência do sistema rigidamente controlados. O histórico de permissões mostra o quanto o Android vinculou explicitamente a execução de agentes a funções privilegiadas.
A estrutura atual está evoluindo para níveis de acesso mais granulares. Desenvolvedores podem marcar funções para o próprio app, solicitantes do sistema ou solicitantes certificados pelo Android. No entanto, a certificação não equivale a uma permissão comum de tempo de execução que qualquer assistente baixado recebe após exibir um aviso.
Essa distinção explica por que o recurso parece ausente em um telefone comum. Os usuários estão acostumados a aprovar acesso à câmera, ao microfone, aos contatos e à localização. Eles não podem necessariamente instalar um assistente arbitrário e conceder a ele ampla autoridade sobre App Functions em uma tela padrão de configurações.
O Google está evitando uma perigosa corrida para o nível mais baixo. Se qualquer aplicação pudesse chamar todas as funções expostas após um único aviso vago de consentimento, assistentes agressivos buscariam autoridade ampla. Os usuários poderiam aprová-la sem compreender quantas ações relevantes se tornam disponíveis.
Agentes entre apps apresentam um risco diferente de chatbots passivos. Uma resposta equivocada é inconveniente. Uma ação equivocada pode enviar uma mensagem à pessoa errada, divulgar um documento privado, modificar um registro ou iniciar uma transação.
A injeção de prompts torna essa distinção mais nítida. Um agente pode encontrar texto projetado para substituir a intenção do usuário ao ler uma página da web, mensagem, documento ou imagem. Uma recente pesquisa sobre agentes móveis examina especificamente como agentes Android orientados por acessibilidade podem ficar expostos à injeção indireta de prompts.
Um limite de permissão não pode tornar o modelo imune à manipulação. Ele pode limitar quais aplicações agem como agentes e quais funções esses agentes alcançam. Também oferece aos apps provedores um caminho de execução definido, no qual podem validar argumentos e aplicar suas próprias verificações.
Ainda assim, o controle central cria outro problema. O Google e os fabricantes de dispositivos Android tornam-se os árbitros práticos de quais assistentes recebem acesso de primeira classe. Um agente independente pode criar um planejador sofisticado e ainda não ter permissão para orquestrar apps de terceiros pela estrutura oficial.
Essa pressão recai sobre três grupos.
Primeiro, os desenvolvedores de assistentes precisam se qualificar para o caminho confiável do Android ou depender de técnicas menos diretas. Eles podem usar deep links para aplicações, usar intents existentes, operar por meio de serviços de acessibilidade ou simular interações com ferramentas de desenvolvimento. Nenhuma delas oferece o mesmo acesso padronizado.
Segundo, os desenvolvedores de aplicações precisam decidir quais funções vale a pena expor. Cada função exige implementação, testes, validação de entradas, tratamento de ciclo de vida e trabalho de compatibilidade. Uma pequena equipe de app pode hesitar até que usuários suficientes tenham um agente capaz de chamar essas funções.
Terceiro, os usuários precisam confiar nos dois lados da transação. Eles precisam ter confiança de que o assistente interpretou corretamente a solicitação e de que o app provedor não executará uma operação inesperadamente ampla.
Isso produz uma partida a frio familiar de plataforma. Agentes precisam de funções úteis antes de atraírem uso. Desenvolvedores de apps precisam de agentes ativos antes que a integração mereça tempo de engenharia. O Google pode quebrar o ciclo com o Gemini e parceiros de destaque, mas participantes independentes continuam dependentes de suas políticas de acesso.
Portanto, o design é ao mesmo tempo uma gaiola de segurança e um portão de distribuição. Restringir a execução reduz abusos imediatos, enquanto a certificação e o privilégio de plataforma moldam quem pode criar automação Android significativa.
O Design de Segurança em Primeiro Lugar do Google Colide com um Problema de Adoção
A principal troca é simples: um controle mais rígido torna os agentes Android mais seguros para implantação, enquanto um acesso mais lento torna a estrutura menos útil hoje.
O Google levou publicamente as App Functions além de referências obscuras de API em fevereiro de 2026. Sua equipe de desenvolvedores Android chamou os recursos de iniciais e descreveu privacidade e segurança como prioridades fundamentais de design.
A empresa também apresentou uma implantação concreta. O Gemini poderia interpretar uma solicitação, acionar uma App Function no Samsung Gallery e devolver fotos selecionadas dentro da interface do Gemini. Segundo a integração da Samsung, essa experiência começou na série Galaxy S26, com expansão planejada para mais dispositivos Samsung.
Esse exemplo prova que a estrutura não é uma casca de código vazia. Ele também revela o quanto a implementação ainda é limitada. A demonstração envolve o assistente do Google, um grande fabricante Android, uma aplicação de galeria própria e dispositivos selecionados.
Um ecossistema amplo seria diferente. Os usuários poderiam escolher entre agentes qualificados. Milhares de aplicações exporiam operações documentadas. O Android mostraria qual agente chamou qual função, quais dados foram transferidos e quais ações exigem confirmação.
A estrutura existente fornece várias partes desse futuro, mas não toda a sua experiência pública. Os desenvolvedores podem definir metadados, publicar funções, observar estado e processar solicitações de execução. O Android 17 também introduz registro mais dinâmico e comportamento específico por atividade.
A atualização do Android 17 do Google inclui uma aplicação de agente de teste e comandos ADB para desenvolvimento. ADB, ou Android Debug Bridge, é uma interface de desenvolvedor para controlar e inspecionar dispositivos. Essas ferramentas ajudam programadores a validar funções antes que agentes de consumo as ofereçam amplamente.
O suporte a testes é necessário, mas não equivale à adoção. Um desenvolvedor pode provar que “criar nota” retorna a resposta esperada sem saber quantos assistentes reais a invocarão. Uma função compatível pode permanecer inativa em milhões de dispositivos.
O framework também precisa de esquemas compartilhados. Dois aplicativos de anotações podem expor ações semelhantes com nomes, argumentos e formatos de resultado diferentes. Se cada provedor inventar seu próprio contrato, os agentes precisam entender uma coleção crescente de interfaces proprietárias.
Esquemas padronizados permitem que agentes pesquisem por capacidade, em vez de memorizar cada aplicação. O modelo de metadados do Android oferece suporte a informações de esquema, mas uma interoperabilidade útil ainda depende de os desenvolvedores convergirem em definições consistentes.
O controle do usuário apresenta outra camada ainda não resolvida. Um aplicativo pode manter o estado ativado de suas funções, e metadados mais recentes podem expressar diferentes níveis de acesso. No entanto, usuários comuns precisam de um modelo compreensível que responda a perguntas práticas.
O Gemini pode criar notas, mas não excluí-las? Outro agente certificado pode pesquisar fotos sem compartilhá-las externamente? A aprovação vale uma única vez, por aplicativo, por função ou por solicitação sensível? Um usuário pode revisar o histórico de ações depois que algo dá errado?
O Google precisa equilibrar esses controles com a fricção. Confirmar toda ação inofensiva anula a conveniência de um agente. Aprovar categorias amplas pode ocultar riscos. Um sistema útil precisa permitir que operações rotineiras avancem rapidamente, enquanto pausa antes de etapas irreversíveis ou sensíveis.
Esse problema se assemelha ao design de permissões, mas a intenção do agente muda durante uma tarefa. Uma permissão de câmera concede acesso a um sensor conhecido. Um agente pode começar lendo uma lista, inferir várias subtarefas, consultar múltiplos aplicativos e propor uma compra. O limite de maior consequência surge no meio do fluxo de trabalho.
Isso torna a política mais importante do que uma única permissão. O Android precisa combinar a identidade do chamador, o escopo da função, as regras do provedor, as preferências do usuário, a sensibilidade da transação e o contexto atual.
A metáfora da gaiola captura apenas parte desse design. O Android não está isolando um processo não confiável dentro de uma caixa. Ele está coordenando chamadores confiáveis por portas estreitamente expostas, com cada aplicação mantendo a responsabilidade pelo que acontece atrás de sua porta.
Para os desenvolvedores, o cálculo imediato continua incerto. Dar suporte ao Google Android App Functions garante a um aplicativo um lugar nos futuros fluxos de trabalho de agentes. Isso também significa investir em uma interface beta cuja distribuição, certificação e demanda dos usuários ainda estão em desenvolvimento.
Agentes que Controlam Telas São Mais Rápidos de Lançar e Mais Difíceis de Confiar
O principal adversário do Google não é outra plataforma móvel; é o atalho de deixar agentes operarem telas como pessoas.
Um agente que controla telas pode começar com menos parcerias. Ele lê pixels ou uma árvore de acessibilidade, decide onde interagir e gera toques, deslizamentos e entradas de texto. Se um humano consegue concluir uma tarefa pela interface, o agente pode tentar a mesma rota.
Essa generalidade é atraente. Os desenvolvedores não precisam que cada aplicação-alvo publique uma função. Pesquisadores podem testar agentes em softwares existentes, e startups podem demonstrar ampla cobertura antes de negociar integrações.
A própria pesquisa do Google no Android ajudou a estabelecer essa abordagem. O conjunto de dados Android in the Wild contém 715.000 episódios que abrangem 30.000 instruções em múltiplas versões do Android e tipos de dispositivos. Ele reflete a escala necessária para treinar ou avaliar sistemas que atuam por meio de interfaces variadas.
No entanto, o amplo controle visual troca contratos explícitos por inferência. O agente precisa determinar o que cada tela significa, se o conteúdo é confiável e se uma interação produziu o resultado pretendido.
O rótulo de um botão pode mudar após uma atualização do aplicativo. Uma caixa de diálogo pode cobrir o alvo esperado. Uma página maliciosa pode colocar instruções onde o modelo irá lê-las. Um fluxo de checkout pode adicionar uma taxa ou alterar um item antes da confirmação final.
Humanos também cometem erros nessas situações, mas os agentes podem repeti-los mais rapidamente e em maior escala. Eles podem operar em segundo plano, continuar entre aplicativos e lidar com informações que o usuário nunca revisa diretamente.
App Functions transferem a interpretação para outra camada. O agente ainda interpreta a solicitação do usuário, mas não precisa inferir a mecânica de cada tela. Ele escolhe uma operação declarada e fornece informações tipadas.
Isso se assemelha à diferença entre usar uma interface de programação de aplicações e automatizar um site por meio de um navegador. APIs normalmente oferecem maior estabilidade e entradas mais claras. A automação de navegador alcança serviços sem uma API, mas precisa lidar com mudanças de layout, sessão e conteúdo.
A rota estruturada também melhora a responsabilização. O Android pode identificar o pacote chamador, a função-alvo, a solicitação e o resultado. Aplicativos provedores podem rejeitar argumentos inválidos ou exigir sua própria confirmação. A política da plataforma pode tratar funções sensíveis de forma diferente das comuns.
Nada disso elimina a necessidade de defesas no nível do modelo. Um agente comprometido pode chamar uma função permitida pelo motivo errado. Um provedor descuidado pode expor uma operação com validação fraca. Um chamador confiável ainda pode interpretar mal instruções ambíguas.
Operações estruturadas também podem tornar ações prejudiciais mais confiáveis. Um agente malicioso que alcança uma função de “enviar pagamento” não precisa navegar por uma interface confusa. O valor de segurança depende de limitar o acesso, verificar a intenção e exigir confirmação no momento correto.
É por isso que abrir EXECUTE_APP_FUNCTIONS de forma ampla demais apagaria grande parte do benefício arquitetural. O Google não pode simplesmente colocar a permissão em uma caixa de diálogo padrão e considerar o problema resolvido. A plataforma precisa de regras de qualificação e comportamento observável que os usuários possam entender.
Ao mesmo tempo, manter o acesso limitado cria pressão para usar automação de telas. Assistentes independentes seguirão a rota que lhes permita lançar produtos. Se a porta oficial permanecer indisponível, alguns desenvolvedores voltarão aos serviços de acessibilidade, ferramentas baseadas em ADB ou automação de dispositivos.
O resultado é um paradoxo de política. O Google quer que os agentes usem o caminho estruturado mais seguro, mas precisa tornar esse caminho acessível o suficiente para substituir alternativas mais arriscadas.
Concorrentes e projetos de código aberto podem explorar essa lacuna oferecendo agentes que parecem mais capazes em aplicativos existentes. Suas demonstrações podem cobrir mais tarefas porque não esperam pela integração dos provedores. O sistema do Google pode parecer restrito justamente porque impõe limites.
Os consumidores não avaliarão essas arquiteturas por meio da documentação de API. Eles perceberão se um agente consegue concluir uma solicitação. Se um rival que controla telas lida com dez aplicativos enquanto a rota estruturada do Gemini oferece suporte a dois, a capacidade pode superar a segurança abstrata na decisão de compra.
Os desenvolvedores enfrentam a mesma tensão ao projetar fluxos de trabalho de IA. A automação confiável depende de entradas previsíveis, ações controladas e pontos visíveis de revisão. O controle geral de interfaces oferece alcance, enquanto funções estruturadas oferecem garantias mais claras.
O Google precisa fechar essa lacuna de capacidade sem transformar agentes Android em controles remotos irrestritos. App Functions fornecem o mecanismo, mas a adoção e a política de acesso determinam se os desenvolvedores realmente o utilizarão.
O Verdadeiro Teste É Saber se a Gaiola se Torna um Marketplace
A próxima fase depende da participação dos aplicativos, do acesso dos agentes e de controles visíveis aos usuários, e não de mais classes de framework.
O primeiro sinal a acompanhar é o número e a variedade de aplicações em produção que expõem App Functions. Samsung Gallery é uma demonstração útil porque a recuperação de fotos envolve dados pessoais e uma tarefa reconhecível para o usuário. Ela não estabelece suporte amplo em comunicação, produtividade, finanças, compras, viagens e mídia.
As principais aplicações precisam expor mais do que ações promocionais de demonstração. Fluxos de trabalho repetidos e práticos mostrarão se o framework poupa esforço significativo aos usuários. Criar uma nota, localizar uma foto específica, iniciar uma playlist e adicionar itens a um carrinho são testes iniciais.
A adoção fortalece a abordagem do Google se vários desenvolvedores independentes de aplicativos anunciarem integrações funcionais. Ela enfraquece o argumento se o suporte continuar concentrado entre softwares do Google, aplicativos de fabricantes de dispositivos e parceiros de lançamento selecionados.
O segundo sinal é o acesso para agentes não pertencentes ao Google. Os metadados mais recentes do Android fazem referência a chamadores certificados pelo Android, sugerindo uma rota mais ampla do que um único assistente próprio. A questão decisiva é o que a certificação exige e se agentes qualificados de terceiros podem competir em termos razoáveis.
Um programa confiável precisa de critérios publicados, obrigações de segurança, procedimentos de revogação e revisão previsível. Os desenvolvedores devem saber como um agente obtém acesso e qual comportamento faz com que ele o perca.
Sem esses detalhes, o sistema de permissões corre o risco de se tornar uma vantagem privada de distribuição para o Gemini. O Google pode argumentar que o acesso rigoroso protege os usuários, enquanto rivais podem argumentar que as mesmas regras protegem a posição do Google como agente padrão do Android.
Evidências de múltiplos agentes certificados fortaleceriam a interpretação centrada na segurança. A exclusividade persistente da primeira parte fortaleceria a interpretação de controle de acesso. A legitimidade do framework depende de distinguir requisitos de confiança de acesso preferencial.
O terceiro sinal é uma experiência de controle e auditoria voltada ao usuário. A expansão mais ampla do Gemini Intelligence promete automação proativa em telefones e outros dispositivos. Mais ações em segundo plano tornam a visibilidade cada vez mais importante.
Os usuários precisam ver quais funções existem, quais agentes podem chamá-las e quais permissões continuam ativas. Também precisam de um histórico que explique o que um agente solicitou e o que cada aplicação retornou.
Uma superfície de controle útil deve separar a conveniência de baixo risco da autoridade com consequências. Tocar uma música não merece a mesma fricção que enviar uma mensagem ou enviar um pedido. A plataforma deve comunicar essa diferença antes que ocorra um erro.
O design de confirmações será a parte mais difícil. Muitos avisos condicionam os usuários a aprovar tudo. Poucos avisos deixam os usuários surpresos com ações que não pretendiam realizar. As aprovações contextuais precisam permanecer claras sem transformar cada fluxo de trabalho em uma sequência de interrupções.
O Google também deve explicar onde ocorre o processamento. Algumas funções podem ser executadas sobre o estado local da aplicação, enquanto o raciocínio do assistente pode envolver serviços em nuvem. Os usuários precisam entender quando seus dados deixam o dispositivo e qual parte os recebe.
Os controles de estado do framework poderiam oferecer suporte à revogação de emergência. Se um agente se comportar de forma inesperada, os usuários devem poder desativar sua autoridade entre aplicativos sem procurar nas aplicações individuais. Aplicativos provedores também devem conseguir suspender rapidamente funções sensíveis.
Os desenvolvedores também buscarão ferramentas operacionais. Eles precisam de registros para chamadas com falha, validação de esquema, testes de compatibilidade, relatórios de abuso e comportamento claro entre versões do Android. Um framework se torna um ecossistema apenas quando as equipes conseguem dar suporte a ele em produção.
A implantação gradual do Google é defensável. Lançar uma agência irrestrita entre aplicativos antes que os controles existam convidaria a falhas previsíveis. Em vez disso, a empresa construiu verificações de permissão, contratos de provedores, ferramentas de teste e APIs de plataforma em expansão antes de habilitar o acesso universal.
A visão cética é igualmente defensável. Um framework seguro com poucas funções chamáveis não oferece muito valor ao consumidor. Uma rota rigidamente controlada também pode empurrar desenvolvedores independentes para a própria automação de telas que o framework foi projetado para substituir.
As Google Android App Functions representam, portanto, uma transição importante, mas incompleta. O Android agora conta com um mecanismo nativo para que agentes descubram e executem operações delimitadas. A plataforma ainda não demonstrou que esse mecanismo possa sustentar um mercado de agentes aberto, competitivo e amplamente adotado.
Nos próximos meses, acompanhe integrações em produção além dos parceiros de lançamento, regras de acesso publicadas para agentes externos e um histórico de permissões visível para os usuários. Em conjunto, esses sinais revelarão se o Google construiu uma infraestrutura compartilhada ou uma via protegida para o Gemini.
Para os proprietários de dispositivos Android, a questão prática não é se um agente de IA consegue tocar na tela. Sistemas experimentais já mostraram que consegue. A questão é se o Android pode permitir que agentes ajam em aplicativos pessoais sem exigir que os usuários abram mão de um controle significativo.
Para desenvolvedores, a decisão chega mais cedo. Eles precisam identificar operações seguras e úteis que mereçam exposição estruturada e definir onde a confirmação deve ocorrer. Esperar evita trabalho no curto prazo, mas pode deixar um aplicativo invisível quando os usuários começarem a delegar tarefas em vez de abrir interfaces.
O Google construiu a porta e instalou a fechadura. Agora, precisa provar que agentes confiáveis, desenvolvedores independentes e usuários comuns podem receber as chaves certas.
