Google Android App Functions ha costruito una gabbia di sicurezza, ma la maggior parte degli agenti AI resta fuori

Google ha creato per gli agenti Android un percorso controllato verso altre app, ma la maggior parte degli utenti continua a non poter vedere, gestire o utilizzare davvero quel percorso. Google Android App Functions definisce ora il modo in cui gli assistenti approvati possono scoprire ed eseguire azioni specifiche tra le applicazioni. Il contrasto è che l'architettura di sicurezza è arrivata prima di un ecosistema di agenti esteso.

Non si tratta semplicemente dell'ennesima funzione Android incompleta. Google sta decidendo chi può agire all'interno delle applicazioni, cosa questi soggetti possono scoprire e quali operazioni gli sviluppatori espongono. Queste scelte definiscono il piano di controllo per i futuri agenti che creano note, trovano foto, avviano contenuti multimediali o compongono carrelli della spesa.

Separano inoltre l'approccio di Google dagli agenti che operano sui telefoni interpretando schermate e imitando tocchi. I sistemi che guidano lo schermo possono funzionare senza una profonda integrazione con le app, ma restano sensibili ai cambiamenti di layout e ai contenuti ingannevoli. App Functions offre un percorso più pulito, anche se possono usarlo soltanto agenti approvati e app partecipanti.

Google ha già dimostrato integrazioni limitate, tra cui Gemini che recupera foto tramite Samsung Gallery. Android 17 amplia ulteriormente il framework. Tuttavia, un normale proprietario di Android non troverà una dashboard universale degli agenti piena di assistenti di terze parti e azioni compatibili.

Questo divario spiega l'apparente contraddizione. La gabbia non è letteralmente vuota, ma al suo interno ci sono ancora pochi soggetti, controllati e difficili da ispezionare per gli utenti comuni. Google ha messo in sicurezza l'ingresso prima di aprire il mercato che lo circonda.

Google Android App Functions ha cambiato il modo in cui gli agenti entrano nelle app

App Functions sostituisce il controllo simulato dello schermo con operazioni dichiarate e strutturate che Android può identificare e limitare.

Una funzione dell'app è un'azione distinta che un'applicazione rende disponibile a un chiamante approvato. Un'app per note potrebbe esporre “crea nota”, mentre un'app multimediale potrebbe esporre “riproduci brano”. L'agente invia parametri strutturati anziché navigare nell'interfaccia visibile dell'app.

Il framework ufficiale App Functions framework descrive due parti. Un'app provider dichiara un'azione, mentre un agente affidabile la scopre e la esegue. Android media lo scambio tramite AppFunctionManager e servizi correlati.

Questa architettura è importante perché un'interfaccia visiva è progettata per il giudizio umano. Una persona nota che un pulsante è stato spostato, che un destinatario sembra errato o che il totale di un acquisto è cambiato. Un sistema automatizzato può invece proseguire dopo aver interpretato male lo schermo o aver seguito istruzioni ostili incorporate nei contenuti visualizzati.

Le funzioni strutturate restringono l'azione disponibile. L'agente non riceve un controllo illimitato soltanto perché può chiedere a un'app di eseguire un'operazione. Il provider definisce la funzione, i suoi input e il risultato restituito.

Android tiene inoltre traccia dello stato di attivazione di una funzione. Una richiesta di esecuzione può fallire se la funzione non esiste, non viene trovata o non è disponibile. Questo crea un confine più chiaro rispetto a concedere a un agente l'accesso generale all'interfaccia dell'applicazione.

Il framework è arrivato sulla piattaforma al livello API 36, la versione associata ad Android 16. La documentazione di Google continua a descrivere App Functions come una preview beta o sperimentale. Android 17 aggiunge la registrazione a runtime, funzioni limitate a un'attività, livelli di accesso aggiornati e controlli di scoperta più dettagliati.

Questi cambiamenti mostrano che Google considera l'azione tra app una questione del sistema operativo. Non sta lasciando a ogni sviluppatore di assistenti il compito di inventare un livello di integrazione privato. La piattaforma fornisce identificatori comuni, metadati, gestione dello stato, richieste, risposte e controlli delle autorizzazioni.

La distinzione risulta più chiara in un semplice scenario di presa di note. Un agente riceve l'istruzione: “Salva l'indirizzo dell'hotel nelle mie note di viaggio”. Cerca una funzione compatibile, identifica l'app di destinazione, fornisce titolo e contenuto e riceve un risultato.

Un agente che guida lo schermo aprirebbe invece l'app, individuerebbe un pulsante, sceglierebbe un taccuino, selezionerebbe un campo di testo, inserirebbe il contenuto e premerebbe salva. Ogni transizione visiva aggiunge un altro punto in cui ambiguità o manipolazione possono entrare nella sequenza.

App Functions non garantisce che un agente abbia compreso la richiesta originale. Non dimostra neppure che un'app abbia implementato la propria azione in modo sicuro. Riduce la superficie di rischio sostituendo un percorso aperto nell'interfaccia con un'operazione esplicitamente dichiarata dagli sviluppatori.

Questo è il primo cambiamento importante. Android ora dispone di un vocabolario nativo per gli agenti che agiscono all'interno delle applicazioni, anziché limitarsi a parlare di tali applicazioni o ad avviarne le schermate.

Il secondo cambiamento è meno visibile. Android colloca l'esecuzione tra app dietro autorizzazioni che le applicazioni comuni non possono semplicemente presumere di avere. Questa decisione trasforma App Functions da una comoda API in un sistema di controllo degli accessi.

Il modello di autorizzazioni mette Google e i produttori di dispositivi al comando

Il vantaggio di sicurezza deriva dal limitare i chiamanti capaci, ma la stessa restrizione mantiene gli agenti Android indipendenti fuori dai cancelli.

Un'applicazione può eseguire le proprie funzioni senza un'autorità speciale. L'esecuzione tra pacchetti è diversa. AppFunctionManager richiede che l'agente chiamante disponga di un'autorizzazione Android abilitata alla scoperta o all'esecuzione di funzioni in altre app.

Il lavoro iniziale sul framework Android assegnava EXECUTE_APP_FUNCTIONS alle applicazioni preinstallate o di sistema che detenevano il ruolo di assistente. Un'autorizzazione affidabile correlata serviva componenti di intelligenza di sistema strettamente controllati. La cronologia delle autorizzazioni mostra quanto esplicitamente Android abbia legato l'esecuzione degli agenti a ruoli privilegiati.

Il framework attuale si sta evolvendo verso livelli di accesso più granulari. Gli sviluppatori possono contrassegnare le funzioni per l'app stessa, per i chiamanti di sistema o per chiamanti certificati da Android. Tuttavia, la certificazione non equivale a un'ordinaria autorizzazione a runtime che qualsiasi assistente scaricato riceve dopo aver mostrato una richiesta.

Questa distinzione spiega perché la funzione sembra assente su un telefono normale. Gli utenti sono abituati ad approvare l'accesso a fotocamera, microfono, contatti e posizione. Non possono necessariamente installare un assistente arbitrario e concedergli un'ampia autorità su App Functions da una schermata delle impostazioni standard.

Google sta prevenendo una pericolosa corsa al ribasso. Se qualsiasi applicazione potesse richiamare ogni funzione esposta dopo un unico e vago consenso, gli assistenti aggressivi cercherebbero un'autorità estesa. Gli utenti potrebbero approvarla senza comprendere quante azioni rilevanti diventerebbero disponibili.

Gli agenti tra app comportano un rischio diverso dai chatbot passivi. Una risposta errata è scomoda. Un'azione errata può inviare un messaggio alla persona sbagliata, divulgare un documento privato, modificare un record o avviare una transazione.

La prompt injection rende questa distinzione più netta. Un agente può incontrare testo progettato per sovrascrivere l'intento dell'utente durante la lettura di una pagina web, un messaggio, un documento o un'immagine. Una recente ricerca sugli agenti mobili esamina specificamente il modo in cui gli agenti Android basati sull'accessibilità possono essere esposti a prompt injection indirette.

Un confine basato sulle autorizzazioni non può rendere il modello immune dalla manipolazione. Può limitare quali applicazioni agiscono come agenti e quali funzioni tali agenti possono raggiungere. Offre inoltre alle app provider un percorso di esecuzione definito, nel quale possono validare gli argomenti e applicare i propri controlli.

Tuttavia, il controllo centralizzato crea un altro problema. Google e i produttori di dispositivi Android diventano gli arbitri pratici di quali assistenti ricevono un accesso di prima classe. Un agente indipendente può costruire un pianificatore sofisticato e continuare a non avere l'autorizzazione per orchestrare app di terze parti tramite il framework ufficiale.

Questa pressione ricade su tre gruppi.

In primo luogo, gli sviluppatori di assistenti devono qualificarsi per il percorso affidabile di Android o fare affidamento su tecniche meno dirette. Possono usare deep link nelle applicazioni, intent esistenti, operare tramite servizi di accessibilità o simulare interazioni attraverso strumenti di sviluppo. Nessuno offre lo stesso accesso standardizzato.

In secondo luogo, gli sviluppatori di applicazioni devono decidere quali funzioni valga la pena esporre. Ogni funzione richiede implementazione, test, convalida degli input, gestione del ciclo di vita e lavoro di compatibilità. Un piccolo team potrebbe esitare finché un numero sufficiente di utenti non dispone di un agente in grado di richiamare quelle funzioni.

In terzo luogo, gli utenti devono fidarsi di entrambi i lati della transazione. Devono avere fiducia che l'assistente abbia interpretato correttamente la richiesta e che l'app provider non eseguirà un'operazione inaspettatamente ampia.

Questo produce un noto avvio a freddo della piattaforma. Gli agenti hanno bisogno di funzioni utili prima di attrarre utilizzo. Gli sviluppatori di app hanno bisogno di agenti attivi prima che l'integrazione meriti tempo di sviluppo. Google può spezzare il ciclo con Gemini e partner di rilievo, ma i partecipanti indipendenti restano dipendenti dalle sue politiche di accesso.

Il design è quindi sia una gabbia di sicurezza sia un cancello di distribuzione. Limitare l'esecuzione riduce gli abusi immediati, mentre certificazione e privilegi della piattaforma modellano chi può costruire un'automazione Android significativa.

Il design di Google incentrato sulla sicurezza si scontra con un problema di adozione

Il compromesso centrale è semplice: un controllo più rigido rende gli agenti Android più sicuri da distribuire, mentre un accesso più lento rende il framework meno utile oggi.

Google ha portato pubblicamente App Functions oltre gli oscuri riferimenti API nel febbraio 2026. Il suo team di sviluppatori Android ha definito le capacità in fase iniziale e ha descritto privacy e sicurezza come priorità fondamentali del progetto.

L'azienda ha inoltre presentato un'implementazione concreta. Gemini poteva interpretare una richiesta, attivare un'App Function in Samsung Gallery e restituire foto selezionate nell'interfaccia di Gemini. Secondo l'integrazione Samsung, questa esperienza è iniziata sulla serie Galaxy S26, con un'espansione pianificata per altri dispositivi Samsung.

Questo esempio dimostra che il framework non è un guscio di codice vuoto. Rivela anche quanto limitata resti l'implementazione. La dimostrazione coinvolge l'assistente di Google, un importante produttore Android, un'applicazione galleria di prima parte e dispositivi selezionati.

Un ecosistema ampio apparirebbe diverso. Gli utenti potrebbero scegliere tra agenti qualificati. Migliaia di applicazioni esporrebbero operazioni documentate. Android mostrerebbe quale agente ha richiamato quale funzione, quali dati sono stati trasferiti e quali azioni richiedono conferma.

Il framework esistente fornisce diversi elementi di quel futuro, ma non ancora la sua esperienza pubblica completa. Gli sviluppatori possono definire metadati, pubblicare funzioni, osservare lo stato ed elaborare richieste di esecuzione. Android 17 introduce inoltre una registrazione più dinamica e comportamenti specifici per attività.

L'aggiornamento Android 17 di Google include un'applicazione agente di test e comandi ADB per lo sviluppo. ADB, o Android Debug Bridge, è un'interfaccia per sviluppatori destinata al controllo e all'ispezione dei dispositivi. Questi strumenti aiutano i programmatori a convalidare le funzioni prima che gli agenti per consumatori le supportino ampiamente.

Il supporto ai test è necessario, ma non equivale all'adozione. Uno sviluppatore può dimostrare che “crea nota” restituisce la risposta prevista senza sapere quanti assistenti reali la invocheranno. Una funzione compatibile può restare inattiva su milioni di dispositivi.

Il framework necessita anche di schemi condivisi. Due app per prendere appunti possono esporre azioni simili con nomi, argomenti e formati dei risultati diversi. Se ogni provider inventa il proprio contratto, gli agenti devono comprendere una raccolta sempre più ampia di interfacce proprietarie.

Gli schemi standard consentono agli agenti di cercare per capacità anziché memorizzare ogni singola applicazione. Il modello di metadati di Android supporta informazioni sugli schemi, ma un'interoperabilità utile dipende comunque dalla convergenza degli sviluppatori su definizioni coerenti.

Il controllo dell'utente rappresenta un ulteriore livello irrisolto. Un'app può mantenere lo stato di abilitazione delle proprie funzioni, e metadati più recenti possono esprimere diversi livelli di accesso. Tuttavia, gli utenti comuni hanno bisogno di un modello comprensibile che risponda a domande pratiche.

Gemini può creare note ma non eliminarle? Un altro agente certificato può cercare foto senza condividerle esternamente? L'approvazione si applica una volta sola, per app, per funzione o per ogni richiesta sensibile? Un utente può consultare una cronologia delle azioni dopo che qualcosa è andato storto?

Google deve bilanciare questi controlli con l'attrito. Confermare ogni azione innocua annulla la comodità di un agente. Approvare categorie troppo ampie può nascondere i rischi. Un sistema utile deve consentire alle operazioni di routine di procedere rapidamente, fermandosi però prima dei passaggi irreversibili o sensibili.

Questo problema ricorda la progettazione delle autorizzazioni, ma l'intento dell'agente cambia durante un'attività. Un'autorizzazione per la fotocamera concede accesso a un sensore noto. Un agente può iniziare leggendo un elenco, dedurre diversi sotto-compiti, consultare più app e proporre un acquisto. Il confine con conseguenze rilevanti emerge a metà del flusso di lavoro.

Per questo la policy è più importante di una singola autorizzazione. Android deve combinare identità del chiamante, ambito della funzione, regole del provider, preferenze dell'utente, sensibilità della transazione e contesto attuale.

La metafora della gabbia coglie soltanto una parte di questa progettazione. Android non sta isolando un singolo processo non affidabile dentro una scatola. Sta coordinando chiamanti affidabili attraverso porte esposte in modo limitato, mentre ogni applicazione mantiene la responsabilità di ciò che avviene dietro la propria porta.

Per gli sviluppatori, il calcolo immediato resta incerto. Supportare Google Android App Functions offre a un'app un posto nei futuri flussi di lavoro degli agenti. Significa però anche investire in un'interfaccia beta la cui distribuzione, certificazione e domanda degli utenti sono ancora in evoluzione.

Gli agenti che controllano lo schermo sono più rapidi da lanciare e più difficili di cui fidarsi

Il principale avversario di Google non è un'altra piattaforma mobile; è la scorciatoia di lasciare che gli agenti usino gli schermi come le persone.

Un agente che controlla lo schermo può iniziare con meno partnership. Legge i pixel o un albero di accessibilità, decide dove interagire e genera tocchi, scorrimenti e input di testo. Se un essere umano può completare un'attività tramite l'interfaccia, l'agente può tentare lo stesso percorso.

Questa generalità è allettante. Gli sviluppatori non hanno bisogno che ogni applicazione target pubblichi una funzione. I ricercatori possono testare gli agenti su software esistente, e le startup possono dimostrare un'ampia copertura prima di negoziare integrazioni.

La stessa ricerca Android di Google ha contribuito a consolidare questo approccio. Il dataset Android in the Wild contiene 715.000 episodi che coprono 30.000 istruzioni su più versioni di Android e tipi di dispositivo. Riflette la scala necessaria per addestrare o valutare sistemi che agiscono attraverso interfacce diverse.

Tuttavia, il controllo visivo esteso sostituisce i contratti espliciti con l'inferenza. L'agente deve stabilire il significato di ogni schermata, se il contenuto è affidabile e se un'interazione ha prodotto il risultato previsto.

L'etichetta di un pulsante può cambiare dopo un aggiornamento dell'app. Una finestra di dialogo può coprire il target previsto. Una pagina dannosa può inserire istruzioni nel punto in cui il modello le leggerà. Un flusso di checkout può aggiungere una commissione o modificare un articolo prima della conferma finale.

Anche gli esseri umani commettono errori in queste situazioni, ma gli agenti possono ripeterli più rapidamente e su scala maggiore. Possono operare in background, proseguire tra diverse applicazioni e gestire informazioni che l'utente non esamina mai direttamente.

App Functions sposta l'interpretazione su un livello diverso. L'agente continua a interpretare la richiesta dell'utente, ma non deve dedurre la meccanica di ogni schermata. Sceglie un'operazione dichiarata e fornisce informazioni tipizzate.

È simile alla differenza tra l'uso di un'interfaccia di programmazione applicativa e l'automazione di un sito web tramite browser. Le API offrono di norma maggiore stabilità e input più chiari. L'automazione del browser raggiunge servizi senza API, ma deve gestire modifiche al layout, alla sessione e ai contenuti.

Il percorso strutturato migliora anche la responsabilità. Android può identificare il pacchetto chiamante, la funzione target, la richiesta e il risultato. Le app provider possono rifiutare argomenti non validi o richiedere una propria conferma. Le policy della piattaforma possono trattare le funzioni sensibili in modo diverso da quelle ordinarie.

Nulla di tutto ciò elimina la necessità di difese a livello di modello. Un agente compromesso può chiamare una funzione consentita per il motivo sbagliato. Un provider poco attento può esporre un'operazione con una validazione debole. Un chiamante affidabile può comunque fraintendere istruzioni ambigue.

Le operazioni strutturate possono anche rendere più affidabili le azioni dannose. Un agente malevolo che raggiunge una funzione di “invio pagamento” non deve orientarsi in un'interfaccia confusa. Il valore per la sicurezza dipende dal limitare l'accesso, verificare l'intento e richiedere conferma nel momento corretto.

Ecco perché aprire EXECUTE_APP_FUNCTIONS in modo troppo ampio cancellerebbe gran parte del vantaggio architetturale. Google non può semplicemente inserire l'autorizzazione in una finestra di dialogo standard e considerare il problema risolto. La piattaforma necessita di regole di qualificazione e comportamenti osservabili che gli utenti possano comprendere.

Allo stesso tempo, mantenere l'accesso limitato crea pressione a ricorrere all'automazione dello schermo. Gli assistenti indipendenti seguiranno il percorso che consente loro di distribuire il prodotto. Se la porta ufficiale resta indisponibile, alcuni sviluppatori torneranno ai servizi di accessibilità, agli strumenti basati su ADB o all'automazione del dispositivo.

Il risultato è un paradosso di policy. Google vuole che gli agenti usino il percorso strutturato più sicuro, ma deve rendere quel percorso sufficientemente accessibile da sostituire alternative più rischiose.

I concorrenti e i progetti open source possono sfruttare il divario offrendo agenti che sembrano più capaci sulle app esistenti. Le loro demo possono coprire più attività perché non aspettano l'integrazione da parte dei provider. Il sistema di Google può apparire vincolato proprio perché applica dei limiti.

I consumatori non valuteranno queste architetture attraverso la documentazione API. Noteranno se un agente riesce a completare una richiesta. Se un concorrente che controlla lo schermo gestisce dieci app mentre il percorso strutturato di Gemini ne supporta due, nella decisione d'acquisto la capacità potrebbe prevalere sulla sicurezza astratta.

Gli sviluppatori affrontano la stessa tensione quando progettano flussi di lavoro con l'AI. Un'automazione affidabile dipende da input prevedibili, azioni controllate e punti di revisione visibili. Il controllo generalizzato dell'interfaccia offre ampiezza, mentre le funzioni strutturate offrono garanzie più chiare.

Google deve colmare questo divario di capacità senza trasformare gli agenti Android in telecomandi remoti senza restrizioni. App Functions fornisce il meccanismo, ma l'adozione e la policy di accesso determinano se gli sviluppatori lo utilizzeranno davvero.

Il vero test è se la gabbia diventerà un marketplace

La fase successiva dipende dalla partecipazione delle app, dall'accesso degli agenti e dal controllo visibile all'utente, più che da altre classi del framework.

Il primo segnale da osservare è il numero e la varietà delle applicazioni di produzione che espongono App Functions. Samsung Gallery è una dimostrazione utile perché il recupero delle foto implica dati personali e un'attività utente riconoscibile. Non dimostra un supporto esteso tra comunicazione, produttività, finanza, shopping, viaggi e media.

Le principali applicazioni devono esporre più di azioni dimostrative promozionali. Flussi di lavoro ripetuti e pratici mostreranno se il framework fa risparmiare agli utenti uno sforzo significativo. Creare una nota, trovare una foto specifica, avviare una playlist e aggiungere articoli a un carrello sono test iniziali.

L'adozione rafforza l'approccio di Google se diversi sviluppatori di app indipendenti annunciano integrazioni funzionanti. Ne indebolisce invece il caso se il supporto resta concentrato nel software Google, nelle applicazioni dei produttori di dispositivi e nei partner di lancio selezionati.

Il secondo segnale è l'accesso per gli agenti non Google. I metadati più recenti di Android fanno riferimento a chiamanti certificati da Android, suggerendo un percorso più ampio di un singolo assistente proprietario. La domanda decisiva è cosa richieda la certificazione e se agenti terzi qualificati possano competere a condizioni ragionevoli.

Un programma credibile necessita di criteri pubblicati, obblighi di sicurezza, procedure di revoca e revisioni prevedibili. Gli sviluppatori dovrebbero sapere come un agente ottiene l'accesso e quale comportamento gli fa perdere tale accesso.

Senza questi dettagli, il sistema di autorizzazioni rischia di trasformarsi in un vantaggio di distribuzione privato per Gemini. Google può sostenere che un accesso rigoroso protegga gli utenti, mentre i rivali possono sostenere che le stesse regole proteggano la posizione di Google quale agente predefinito di Android.

La presenza di più agenti certificati rafforzerebbe l'interpretazione orientata alla sicurezza. Un'esclusività persistente della prima parte rafforzerebbe l'interpretazione di controllo dell'accesso. La legittimità del framework dipende dal distinguere i requisiti di fiducia dall'accesso preferenziale.

Il terzo segnale è un'esperienza di controllo e audit rivolta agli utenti. Il più ampio rilascio di Gemini Intelligence di Google promette automazione proattiva su telefoni e altri dispositivi. Più azioni in background rendono la visibilità sempre più importante.

Gli utenti devono poter vedere quali funzioni esistono, quali agenti possono chiamarle e quali autorizzazioni restano attive. Hanno inoltre bisogno di una cronologia che spieghi cosa ha richiesto un agente e cosa ha restituito ogni applicazione.

Un'interfaccia di controllo utile dovrebbe separare la comodità a basso rischio dall'autorità con conseguenze rilevanti. Riprodurre una canzone non merita lo stesso attrito dell'invio di un messaggio o dell'inoltro di un ordine. La piattaforma dovrebbe comunicare questa differenza prima che si verifichi un errore.

La progettazione delle conferme sarà la parte più difficile. Troppe richieste condizionano gli utenti ad approvare tutto. Troppe poche richieste lasciano gli utenti sorpresi da azioni che non intendevano compiere. Le approvazioni contestuali devono restare chiare senza trasformare ogni flusso di lavoro in una sequenza di interruzioni.

Google dovrebbe anche spiegare dove avviene l'elaborazione. Alcune funzioni possono essere eseguite sullo stato locale dell'applicazione, mentre il ragionamento dell'assistente può coinvolgere servizi cloud. Gli utenti devono comprendere quando i loro dati lasciano il dispositivo e quale parte li riceve.

I controlli di stato del framework potrebbero supportare una revoca d'emergenza. Se un agente si comporta in modo inatteso, gli utenti dovrebbero poter disabilitare la sua autorità tra app diverse senza dover cercare nelle singole applicazioni. Anche le app provider dovrebbero poter sospendere rapidamente le funzioni sensibili.

Gli sviluppatori cercheranno anche strumenti operativi. Hanno bisogno di log per chiamate fallite, validazione degli schemi, test di compatibilità, segnalazione di abusi e comportamento chiaro tra le versioni di Android. Un framework diventa un ecosistema solo quando i team possono supportarlo in produzione.

Il rilascio graduale di Google è difendibile. Rilasciare agenti cross-app senza restrizioni prima che esistano i controlli inviterebbe a fallimenti prevedibili. L'azienda ha invece realizzato controlli delle autorizzazioni, contratti dei provider, strumenti di test e API di piattaforma in espansione prima di abilitare l'accesso universale.

Anche la visione scettica è difendibile. Un framework sicuro con poche funzioni richiamabili non offre molto valore ai consumatori. Un percorso rigidamente controllato può anche spingere gli sviluppatori indipendenti verso la stessa automazione dello schermo che il framework era stato progettato per sostituire.

Le Google Android App Functions rappresentano quindi una transizione importante, ma incompleta. Android dispone ora di un meccanismo nativo che consente agli agenti di individuare ed eseguire operazioni circoscritte. La piattaforma deve ancora dimostrare che questo meccanismo sia in grado di sostenere un mercato degli agenti aperto, competitivo e ampiamente adottato.

Nei prossimi mesi, osservate le integrazioni in produzione oltre i partner di lancio, la pubblicazione delle regole di accesso per gli agenti esterni e una cronologia visibile delle autorizzazioni per gli utenti. Nel loro insieme, questi segnali chiariranno se Google abbia realizzato un'infrastruttura condivisa o una corsia protetta per Gemini.

Per i proprietari di dispositivi Android, la questione pratica non è se un agente IA possa toccare uno schermo. I sistemi sperimentali hanno già dimostrato che può farlo. La domanda è se Android possa permettere agli agenti di agire nelle app personali senza chiedere agli utenti di rinunciare a un controllo significativo.

Per gli sviluppatori, la decisione arriva prima. Devono individuare operazioni sicure e utili che meritino un'esposizione strutturata e definire dove debba intervenire la conferma. Attendere evita il lavoro nel breve termine, ma può rendere un'app invisibile quando gli utenti inizieranno a delegare attività anziché aprire interfacce.

Google ha costruito la porta e installato la serratura. Ora deve dimostrare che agenti affidabili, sviluppatori indipendenti e utenti comuni possano tutti ricevere le chiavi giuste.