Google Android App Functions haben einen Sicherheitskäfig gebaut, doch die meisten KI-Agenten bleiben draußen

Google hat Android-Agenten einen kontrollierten Weg in andere Apps geschaffen, doch die meisten Nutzer können diesen Weg weiterhin weder sehen noch verwalten oder sinnvoll nutzen. Google Android App Functions definieren inzwischen, wie zugelassene Assistenten bestimmte Aktionen appübergreifend entdecken und ausführen können. Der Konflikt besteht darin, dass die Sicherheitsarchitektur vor einem breiten Agenten-Ökosystem angekommen ist.

Das ist mehr als nur eine weitere unfertige Android-Funktion. Google entscheidet, wer innerhalb von Anwendungen handeln darf, was diese Akteure entdecken können und welche Vorgänge Entwickler offenlegen. Diese Entscheidungen bilden die Steuerungsebene für künftige Agenten, die Notizen erstellen, Fotos finden, Medien starten oder Warenkörbe zusammenstellen.

Sie unterscheiden Googles Ansatz zudem von Agenten, die Telefone bedienen, indem sie Bildschirme interpretieren und Tippgesten nachahmen. Bildschirmsteuernde Systeme können ohne tiefgreifende App-Integration funktionieren, bleiben jedoch anfällig für Layout-Änderungen und irreführende Inhalte. App Functions bieten einen klareren Weg, auch wenn ihn nur zugelassene Agenten und teilnehmende Apps nutzen können.

Google hat bereits begrenzte Integrationen demonstriert, darunter Gemini, das über Samsung Gallery Fotos abruft. Android 17 erweitert das Framework weiter. Dennoch wird ein typischer Android-Nutzer kein universelles Agenten-Dashboard mit Drittanbieter-Assistenten und kompatiblen Aktionen finden.

Diese Lücke erklärt den offensichtlichen Widerspruch. Der Käfig ist nicht buchstäblich leer, doch seine Bewohnerzahl bleibt klein, kontrolliert und für gewöhnliche Nutzer schwer zu überprüfen. Google hat den Zugang gesichert, bevor es den Markt darum herum geöffnet hat.

Google Android App Functions haben verändert, wie Agenten auf Apps zugreifen

App Functions ersetzen simulierte Bildschirmsteuerung durch deklarierte, strukturierte Vorgänge, die Android identifizieren und beschränken kann.

Eine App Function ist eine einzelne Aktion, die eine Anwendung einem zugelassenen Aufrufer bereitstellt. Eine Notiz-App könnte „Notiz erstellen“ anbieten, während eine Medien-App „Song abspielen“ bereitstellen könnte. Der Agent sendet strukturierte Parameter, statt durch die sichtbare Benutzeroberfläche der App zu navigieren.

Das offizielle App Functions framework beschreibt zwei Parteien. Eine Provider-App deklariert eine Aktion, und ein vertrauenswürdiger Agent entdeckt und führt sie aus. Android vermittelt den Austausch über AppFunctionManager und zugehörige Dienste.

Diese Architektur ist wichtig, weil eine visuelle Benutzeroberfläche für menschliches Urteilsvermögen entwickelt wurde. Ein Mensch bemerkt, dass sich eine Schaltfläche verschoben hat, ein Empfänger falsch aussieht oder sich eine Kaufsumme geändert hat. Ein automatisiertes System könnte nach einer Fehlinterpretation des Bildschirms oder dem Befolgen feindlicher Anweisungen, die in angezeigte Inhalte eingebettet sind, fortfahren.

Strukturierte Funktionen begrenzen die verfügbare Aktion. Der Agent erhält nicht unbegrenzte Kontrolle, nur weil er eine App bitten kann, einen Vorgang auszuführen. Der Provider definiert die Funktion, ihre Eingaben und das zurückgegebene Ergebnis.

Android verfolgt außerdem, ob eine Funktion aktiviert ist. Eine Ausführungsanfrage kann scheitern, wenn die Funktion nicht existiert, nicht gefunden werden kann oder nicht verfügbar ist. Das schafft eine klarere Grenze, als einem Agenten allgemeinen Zugriff auf die Anwendungsoberfläche zu gewähren.

Das Framework kam auf Plattformebene 36, der mit Android 16 verbundenen Version, in die Plattform. Googles Dokumentation beschreibt App Functions weiterhin als Beta- oder experimentelle Vorschau. Android 17 ergänzt die Laufzeitregistrierung, aktivitätsbezogene Funktionen, aktualisierte Zugriffsebenen und detailliertere Entdeckungssteuerungen.

Diese Änderungen zeigen, dass Google appübergreifende Handlungsfähigkeit als Betriebssystemaufgabe behandelt. Das Unternehmen überlässt nicht jedem Assistentenentwickler die Erfindung einer privaten Integrationsschicht. Die Plattform stellt gemeinsame Kennungen, Metadaten, Zustandsverwaltung, Anfragen, Antworten und Berechtigungsprüfungen bereit.

Der Unterschied wird in einem einfachen Notizszenario deutlicher. Ein Agent erhält die Anweisung: „Speichere die Hoteladresse in meinen Reisenotizen.“ Er sucht nach einer kompatiblen Funktion, identifiziert die Ziel-App, übermittelt Titel und Inhalt und erhält ein Ergebnis.

Ein bildschirmsteuernder Agent würde stattdessen die App öffnen, eine Schaltfläche finden, ein Notizbuch auswählen, ein Textfeld fokussieren, Inhalte eingeben und auf Speichern drücken. Jeder visuelle Übergang fügt der Abfolge eine weitere Stelle hinzu, an der Mehrdeutigkeit oder Manipulation eindringen kann.

App Functions garantieren nicht, dass ein Agent die ursprüngliche Anfrage verstanden hat. Sie beweisen auch nicht, dass eine App ihre Aktion sicher implementiert hat. Sie verringern die Angriffsfläche, indem sie eine offene Reise durch die Oberfläche durch einen Vorgang ersetzen, den Entwickler ausdrücklich deklariert haben.

Das ist die erste wichtige Veränderung. Android verfügt nun über ein natives Vokabular für Agenten, die innerhalb von Anwendungen handeln, statt lediglich über diese Anwendungen zu sprechen oder deren Bildschirme zu starten.

Die zweite Veränderung ist weniger sichtbar. Android stellt die appübergreifende Ausführung hinter Berechtigungen, die gewöhnliche Anwendungen nicht einfach voraussetzen können. Diese Entscheidung macht App Functions von einer Komfort-API zu einem Zugangskontrollsystem.

Das Berechtigungsmodell gibt Google und Geräteherstellern die Kontrolle

Der Sicherheitsvorteil entsteht durch die Beschränkung handlungsfähiger Aufrufer, doch dieselbe Einschränkung hält unabhängige Android-Agenten vor dem Tor.

Eine Anwendung kann ihre eigenen Funktionen ohne besondere Autorisierung ausführen. Die paketübergreifende Ausführung ist anders. AppFunctionManager verlangt, dass der aufrufende Agent über eine Android-Berechtigung verfügt, die für das Entdecken oder Ausführen von Funktionen in anderen Apps autorisiert ist.

Die ursprüngliche Android-Framework-Arbeit wies EXECUTE_APP_FUNCTIONS vorinstallierten oder Systemanwendungen zu, die die Assistentenrolle innehatten. Eine damit verbundene vertrauenswürdige Berechtigung diente streng kontrollierten Systemintelligenz-Komponenten. Die permission history zeigt, wie ausdrücklich Android die Ausführung durch Agenten an privilegierte Rollen gebunden hat.

Das aktuelle Framework entwickelt sich hin zu granulareren Zugriffsebenen. Entwickler können Funktionen für die App selbst, Systemaufrufer oder von Android zertifizierte Aufrufer markieren. Eine Zertifizierung entspricht jedoch keiner gewöhnlichen Laufzeitberechtigung, die jeder heruntergeladene Assistent nach einer Aufforderung erhält.

Dieser Unterschied erklärt, warum die Funktion auf einem normalen Telefon kaum sichtbar wirkt. Nutzer sind daran gewöhnt, Kamera-, Mikrofon-, Kontakte- und Standortzugriff zu genehmigen. Sie können jedoch nicht unbedingt einen beliebigen Assistenten installieren und ihm über einen üblichen Einstellungsbildschirm weitreichende App-Functions-Befugnisse erteilen.

Google verhindert einen gefährlichen Wettlauf nach unten. Wenn jede Anwendung nach einer vagen Einwilligungsaufforderung jede freigegebene Funktion aufrufen könnte, würden aggressive Assistenten nach umfassender Autorität streben. Nutzer könnten zustimmen, ohne zu verstehen, wie viele folgenschwere Aktionen dadurch verfügbar werden.

Appübergreifende Agenten bergen ein anderes Risiko als passive Chatbots. Eine falsche Antwort ist unbequem. Eine falsche Aktion kann der falschen Person eine Nachricht senden, ein privates Dokument offenlegen, einen Datensatz verändern oder eine Transaktion beginnen.

Prompt Injection verschärft diesen Unterschied. Ein Agent kann beim Lesen einer Webseite, Nachricht, eines Dokuments oder Bildes auf Text treffen, der die Absicht des Nutzers außer Kraft setzen soll. Aktuelle mobile-agent research untersucht ausdrücklich, wie Android-Agenten auf Basis von Bedienungshilfen indirekter Prompt Injection ausgesetzt sein können.

Eine Berechtigungsgrenze kann ein Modell nicht immun gegen Manipulation machen. Sie kann einschränken, welche Anwendungen als Agenten handeln und welche Funktionen diese Agenten erreichen. Sie gibt Provider-Apps außerdem einen definierten Ausführungspfad, auf dem sie Argumente validieren und eigene Prüfungen anwenden können.

Zentrale Kontrolle schafft jedoch ein weiteres Problem. Google und Android-Gerätehersteller werden zu den faktischen Instanzen, die entscheiden, welche Assistenten erstklassigen Zugang erhalten. Ein unabhängiger Agent kann einen anspruchsvollen Planer entwickeln und dennoch nicht die Berechtigung haben, Drittanbieter-Apps über das offizielle Framework zu orchestrieren.

Dieser Druck trifft drei Gruppen.

Erstens müssen Assistentenentwickler sich für Androids vertrauenswürdigen Weg qualifizieren oder auf indirektere Techniken setzen. Sie können Deep Links in Anwendungen nutzen, vorhandene Intents verwenden, über Bedienungshilfen arbeiten oder Interaktionen über Entwicklungswerkzeuge simulieren. Keine dieser Optionen bietet denselben standardisierten Zugriff.

Zweitens müssen Anwendungsentwickler entscheiden, welche Funktionen sich überhaupt zur Freigabe lohnen. Jede Funktion erfordert Implementierung, Tests, Eingabevalidierung, Lifecycle-Verarbeitung und Kompatibilitätsarbeit. Ein kleines App-Team könnte zögern, bis genügend Nutzer einen Agenten besitzen, der diese Funktionen aufrufen kann.

Drittens müssen Nutzer beiden Seiten der Transaktion vertrauen. Sie brauchen die Gewissheit, dass der Assistent die Anfrage korrekt interpretiert hat und dass die Provider-App keinen unerwartet weitreichenden Vorgang ausführt.

Dadurch entsteht ein bekanntes Plattform-Kaltstartproblem. Agenten benötigen nützliche Funktionen, bevor sie Nutzung anziehen. App-Entwickler benötigen aktive Agenten, bevor sich die Integration technisch lohnt. Google kann den Kreislauf mit Gemini und prominenten Partnern durchbrechen, doch unabhängige Teilnehmer bleiben von seinen Zugriffsrichtlinien abhängig.

Das Design ist daher zugleich ein Sicherheitskäfig und ein Vertriebsgate. Die Beschränkung der Ausführung verringert unmittelbaren Missbrauch, während Zertifizierung und Plattformprivilegien bestimmen, wer sinnvolle Android-Automatisierung entwickeln darf.

Googles sicherheitsorientiertes Design stößt auf ein Akzeptanzproblem

Der zentrale Zielkonflikt ist einfach: Strengere Kontrolle macht Android-Agenten sicherer für den Einsatz, während langsamerer Zugang das Framework heute weniger nützlich macht.

Google rückte App Functions im Februar 2026 über schwer auffindbare API-Referenzen hinaus öffentlich in den Fokus. Das Android-Entwicklerteam des Unternehmens bezeichnete die Funktionen als noch in einem frühen Stadium und nannte Datenschutz und Sicherheit grundlegende Designprioritäten.

Das Unternehmen präsentierte zudem einen konkreten Einsatz. Gemini konnte eine Anfrage interpretieren, eine App Function in Samsung Gallery auslösen und ausgewählte Fotos innerhalb der Gemini-Oberfläche zurückgeben. Laut der Samsung integration begann dieses Erlebnis auf der Galaxy-S26-Serie; eine Ausweitung auf weitere Samsung-Geräte ist geplant.

Dieses Beispiel beweist, dass das Framework keine leere Codehülle ist. Es zeigt zugleich, wie begrenzt der Rollout weiterhin ist. Die Demonstration umfasst Googles Assistenten, einen großen Android-Hersteller, eine Galerie-App des Erstanbieters und ausgewählte Geräte.

Ein breites Ökosystem sähe anders aus. Nutzer könnten zwischen qualifizierten Agenten wählen. Tausende Anwendungen würden dokumentierte Vorgänge bereitstellen. Android würde anzeigen, welcher Agent welche Funktion aufgerufen hat, welche Daten übertragen wurden und welche Aktionen eine Bestätigung erfordern.

Das bestehende Framework liefert mehrere Bestandteile dieser Zukunft, jedoch nicht das vollständige öffentliche Nutzungserlebnis. Entwickler können Metadaten definieren, Funktionen veröffentlichen, Zustände beobachten und Ausführungsanfragen verarbeiten. Android 17 führt außerdem dynamischere Registrierung und aktivitätsspezifisches Verhalten ein.

Googles Android 17 update umfasst eine Test-Agenten-Anwendung und ADB-Befehle für die Entwicklung. ADB, kurz für Android Debug Bridge, ist eine Entwickleroberfläche zur Steuerung und Überprüfung von Geräten. Diese Werkzeuge helfen Programmierern, Funktionen zu validieren, bevor Verbraucher-Agenten sie breit unterstützen.

Testunterstützung ist notwendig, entspricht aber nicht der Akzeptanz. Ein Entwickler kann nachweisen, dass „Notiz erstellen“ die erwartete Antwort zurückgibt, ohne zu wissen, wie viele echte Assistenten sie aufrufen werden. Eine kompatible Funktion kann auf Millionen von Geräten ungenutzt bleiben.

Das Framework benötigt zudem gemeinsame Schemata. Zwei Notiz-Apps können ähnliche Aktionen mit unterschiedlichen Namen, Argumenten und Ergebnisformaten anbieten. Wenn jeder Anbieter seinen eigenen Vertrag erfindet, müssen Agenten eine wachsende Sammlung proprietärer Schnittstellen verstehen.

Standardisierte Schemata ermöglichen es Agenten, nach Fähigkeiten zu suchen, statt sich jede Anwendung merken zu müssen. Das Metadatenmodell von Android unterstützt Schema-Informationen, doch sinnvolle Interoperabilität hängt weiterhin davon ab, dass Entwickler sich auf konsistente Definitionen einigen.

Die Kontrolle durch Nutzer bildet eine weitere ungelöste Ebene. Eine App kann den Aktivierungszustand ihrer Funktionen verwalten, und neuere Metadaten können unterschiedliche Zugriffsebenen ausdrücken. Gewöhnliche Nutzer benötigen jedoch ein verständliches Modell, das praktische Fragen beantwortet.

Kann Gemini Notizen erstellen, aber nicht löschen? Kann ein anderer zertifizierter Agent Fotos durchsuchen, ohne sie extern weiterzugeben? Gilt eine Genehmigung einmalig, pro App, pro Funktion oder für jede sensible Anfrage? Können Nutzer einen Aktionsverlauf prüfen, nachdem etwas schiefgelaufen ist?

Google muss diese Kontrollen gegen Reibungsverluste abwägen. Jede harmlose Aktion bestätigen zu müssen, zerstört den Komfort eines Agenten. Die Genehmigung breiter Kategorien kann Risiken verschleiern. Ein nützliches System muss Routinevorgänge schnell ermöglichen und gleichzeitig vor irreversiblen oder sensiblen Schritten anhalten.

Das Problem ähnelt der Gestaltung von Berechtigungen, doch die Absicht eines Agenten verändert sich während einer Aufgabe. Eine Kameraberechtigung gewährt Zugriff auf einen bekannten Sensor. Ein Agent kann damit beginnen, eine Liste zu lesen, mehrere Teilaufgaben ableiten, mehrere Apps konsultieren und einen Kauf vorschlagen. Die folgenreiche Grenze erscheint erst mitten im Ablauf.

Dadurch wird Richtliniensteuerung wichtiger als eine einzelne Berechtigung. Android muss die Identität des Aufrufers, den Funktionsumfang, Anbieterregeln, Nutzereinstellungen, die Sensibilität einer Transaktion und den aktuellen Kontext kombinieren.

Die Käfig-Metapher erfasst nur einen Teil dieses Designs. Android isoliert nicht einen nicht vertrauenswürdigen Prozess in einer Box. Es koordiniert vertrauenswürdige Aufrufer über eng begrenzte Türen, wobei jede Anwendung weiterhin dafür verantwortlich bleibt, was hinter ihrer Tür geschieht.

Für Entwickler bleibt die unmittelbare Kalkulation unsicher. Die Unterstützung von Google Android App Functions verschafft einer App einen Platz in künftigen Agenten-Workflows. Sie bedeutet aber auch Investitionen in eine Beta-Schnittstelle, deren Verbreitung, Zertifizierung und Nutzernachfrage sich noch entwickeln.

Bildschirmsteuernde Agenten sind schneller startklar und schwerer vertrauenswürdig

Googles wichtigster Gegner ist keine andere mobile Plattform; es ist der bequeme Weg, Agenten Bildschirme wie Menschen bedienen zu lassen.

Ein bildschirmsteuernder Agent kann mit weniger Partnerschaften beginnen. Er liest Pixel oder einen Accessibility-Baum, entscheidet, wo er interagiert, und erzeugt Tippen, Wischen und Texteingaben. Wenn ein Mensch eine Aufgabe über die Oberfläche erledigen kann, kann der Agent denselben Weg versuchen.

Diese Allgemeingültigkeit ist attraktiv. Entwickler müssen nicht jede Zielanwendung dazu bringen, eine Funktion zu veröffentlichen. Forschende können Agenten über bestehende Software hinweg testen, und Start-ups können breite Abdeckung demonstrieren, bevor sie Integrationen aushandeln.

Googles eigene Android-Forschung hat zur Etablierung dieses Ansatzes beigetragen. Der Datensatz Android in the Wild enthält 715.000 Episoden mit 30.000 Anweisungen über mehrere Android-Versionen und Gerätetypen hinweg. Er verdeutlicht den Umfang, der nötig ist, um Systeme zu trainieren oder zu bewerten, die über unterschiedliche Oberflächen handeln.

Breite visuelle Kontrolle tauscht jedoch explizite Verträge gegen Schlussfolgerungen ein. Der Agent muss bestimmen, was jeder Bildschirm bedeutet, ob Inhalte vertrauenswürdig sind und ob eine Interaktion das beabsichtigte Ergebnis erzeugt hat.

Die Beschriftung eines Buttons kann sich nach einem App-Update ändern. Ein Dialog kann das erwartete Ziel verdecken. Eine bösartige Seite kann Anweisungen dort platzieren, wo das Modell sie liest. Ein Checkout-Ablauf kann vor der endgültigen Bestätigung eine Gebühr hinzufügen oder einen Artikel ändern.

Auch Menschen machen in solchen Situationen Fehler, doch Agenten können sie schneller und in größerem Maßstab wiederholen. Sie können im Hintergrund arbeiten, anwendungsübergreifend fortfahren und Informationen verarbeiten, die der Nutzer nie direkt prüft.

App Functions verlagern die Interpretation auf eine andere Ebene. Der Agent interpretiert weiterhin die Anfrage des Nutzers, muss aber nicht die Mechanik jedes Bildschirms erschließen. Er wählt eine deklarierte Operation und übergibt typisierte Informationen.

Das ähnelt dem Unterschied zwischen der Nutzung einer Programmierschnittstelle und der Automatisierung einer Website über einen Browser. APIs bieten in der Regel höhere Stabilität und klarere Eingaben. Browser-Automatisierung erreicht Dienste ohne API, muss jedoch Änderungen an Layout, Sitzung und Inhalten bewältigen.

Der strukturierte Weg verbessert auch die Nachvollziehbarkeit. Android kann das aufrufende Paket, die Zielfunktion, die Anfrage und das Ergebnis identifizieren. Anbieter-Apps können ungültige Argumente ablehnen oder eine eigene Bestätigung verlangen. Plattformrichtlinien können sensible Funktionen anders behandeln als gewöhnliche.

All dies beseitigt nicht die Notwendigkeit von Schutzmaßnahmen auf Modellebene. Ein kompromittierter Agent kann eine erlaubte Funktion aus dem falschen Grund aufrufen. Ein nachlässiger Anbieter kann eine Operation mit schwacher Validierung freigeben. Ein vertrauenswürdiger Aufrufer kann mehrdeutige Anweisungen weiterhin missverstehen.

Strukturierte Operationen können schädliche Handlungen zudem zuverlässiger machen. Ein bösartiger Agent, der eine Funktion zum „Senden einer Zahlung“ erreicht, muss nicht durch eine verwirrende Oberfläche navigieren. Der Sicherheitswert hängt davon ab, den Zugriff zu begrenzen, die Absicht zu prüfen und im richtigen Moment eine Bestätigung zu verlangen.

Deshalb würde ein zu breites Öffnen von EXECUTE_APP_FUNCTIONS einen Großteil des architektonischen Vorteils zunichtemachen. Google kann die Berechtigung nicht einfach in einen Standarddialog setzen und das Problem als gelöst betrachten. Die Plattform benötigt Qualifikationsregeln und beobachtbares Verhalten, das Nutzer verstehen können.

Gleichzeitig erzeugt ein begrenzter Zugang Druck, Bildschirmautomatisierung zu verwenden. Unabhängige Assistenten werden den Weg wählen, über den sie ausliefern können. Bleibt die offizielle Tür verschlossen, werden einige Entwickler zu Accessibility-Diensten, ADB-basierten Tools oder Geräteautomatisierung zurückkehren.

Das Ergebnis ist ein Richtlinienparadox. Google möchte, dass Agenten den sichereren strukturierten Weg nutzen, muss diesen Weg aber zugänglich genug machen, damit er riskantere Alternativen verdrängt.

Wettbewerber und Open-Source-Projekte können die Lücke nutzen, indem sie Agenten anbieten, die über bestehende Apps hinweg leistungsfähiger wirken. Ihre Demos können mehr Aufgaben abdecken, weil sie nicht auf die Integration durch Anbieter warten. Googles System kann gerade deshalb eingeschränkt erscheinen, weil es Grenzen durchsetzt.

Verbraucher werden diese Architekturen nicht anhand von API-Dokumentationen bewerten. Sie werden bemerken, ob ein Agent eine Anfrage erledigen kann. Wenn ein bildschirmsteuernder Konkurrent zehn Apps bedient, während der strukturierte Weg von Gemini zwei unterstützt, kann Leistungsfähigkeit bei der Kaufentscheidung abstrakte Sicherheit überwiegen.

Entwickler stehen bei der Gestaltung von AI workflows vor derselben Spannung. Zuverlässige Automatisierung hängt von vorhersehbaren Eingaben, kontrollierten Aktionen und sichtbaren Prüfpunkten ab. Allgemeine Oberflächensteuerung bietet Reichweite, während strukturierte Funktionen klarere Garantien bieten.

Google muss diese Fähigkeitslücke schließen, ohne Android-Agenten in uneingeschränkte Fernbedienungen zu verwandeln. App Functions liefern den Mechanismus, doch Akzeptanz und Zugriffsrichtlinien entscheiden darüber, ob Entwickler ihn tatsächlich nutzen.

Der eigentliche Test ist, ob der Käfig zu einem Marktplatz wird

Die nächste Phase hängt von der Beteiligung von Apps, dem Agentenzugang und für Nutzer sichtbaren Kontrollen ab – nicht von weiteren Framework-Klassen.

Das erste Signal, das es zu beobachten gilt, ist die Anzahl und Vielfalt von Produktionsanwendungen, die App Functions bereitstellen. Samsung Gallery ist eine nützliche Demonstration, weil der Abruf von Fotos persönliche Daten und eine klar erkennbare Nutzeraufgabe betrifft. Sie belegt jedoch keine breite Unterstützung in Kommunikation, Produktivität, Finanzen, Shopping, Reisen und Medien.

Große Anwendungen müssen mehr als werbliche Demo-Aktionen anbieten. Wiederkehrende, praktische Workflows werden zeigen, ob das Framework Nutzern spürbaren Aufwand erspart. Eine Notiz erstellen, ein bestimmtes Foto finden, eine Playlist starten und Artikel in einen Warenkorb legen sind frühe Tests.

Die Akzeptanz stärkt Googles Ansatz, wenn mehrere unabhängige App-Entwickler funktionierende Integrationen ankündigen. Sie schwächt die Argumentation, wenn die Unterstützung auf Google-Software, Anwendungen von Geräteherstellern und ausgewählte Launch-Partner konzentriert bleibt.

Das zweite Signal ist der Zugang für Nicht-Google-Agenten. Neuere Android-Metadaten beziehen sich auf von Android zertifizierte Aufrufer, was einen Weg eröffnet, der über einen einzelnen First-Party-Assistenten hinausgeht. Die entscheidende Frage ist, was die Zertifizierung erfordert und ob qualifizierte Drittanbieter-Agenten zu angemessenen Bedingungen konkurrieren können.

Ein glaubwürdiges Programm benötigt veröffentlichte Kriterien, Sicherheitsverpflichtungen, Verfahren zum Entzug und eine vorhersehbare Prüfung. Entwickler sollten wissen, wie ein Agent Zugang erhält und welches Verhalten dazu führt, dass er diesen Zugang verliert.

Ohne diese Details droht das Berechtigungssystem zu einem privaten Vertriebsvorteil für Gemini zu werden. Google kann argumentieren, dass strenger Zugang Nutzer schützt, während Rivalen argumentieren können, dass dieselben Regeln Googles Position als Standard-Agent von Android schützen.

Nachweise für mehrere zertifizierte Agenten würden die sicherheitsorientierte Interpretation stärken. Anhaltende Exklusivität für First-Party-Angebote würde die Interpretation als Zugangskontrolle stärken. Die Legitimität des Frameworks hängt davon ab, Vertrauensanforderungen von bevorzugtem Zugang zu unterscheiden.

Das dritte Signal ist eine nutzerseitige Kontroll- und Audit-Erfahrung. Googles breiterer Gemini Intelligence rollout verspricht proaktive Automatisierung über Smartphones und andere Geräte hinweg. Mehr Hintergrundaktionen machen Transparenz zunehmend wichtig.

Nutzer müssen sehen können, welche Funktionen existieren, welche Agenten sie aufrufen können und welche Berechtigungen aktiv bleiben. Sie benötigen außerdem einen Verlauf, der erklärt, was ein Agent angefordert hat und was jede Anwendung zurückgegeben hat.

Eine nützliche Kontrolloberfläche sollte Komfort mit geringem Risiko von folgenreicher Befugnis trennen. Einen Song abzuspielen verdient nicht dieselbe Reibung wie eine Nachricht zu senden oder eine Bestellung abzuschicken. Die Plattform sollte diesen Unterschied kommunizieren, bevor ein Fehler auftritt.

Die Gestaltung von Bestätigungen wird der schwierigste Teil sein. Zu viele Aufforderungen gewöhnen Nutzer daran, alles zu genehmigen. Zu wenige Aufforderungen überraschen Nutzer mit Handlungen, die sie nicht beabsichtigt haben. Kontextbezogene Genehmigungen müssen klar bleiben, ohne jeden Workflow in eine Abfolge von Unterbrechungen zu verwandeln.

Google sollte außerdem erklären, wo die Verarbeitung stattfindet. Einige Funktionen können auf Basis des lokalen Anwendungszustands ausgeführt werden, während das Schlussfolgern des Assistenten Cloud-Dienste einbeziehen kann. Nutzer müssen verstehen, wann ihre Daten das Gerät verlassen und welche Partei sie erhält.

Die Statuskontrollen des Frameworks könnten einen Notfallentzug unterstützen. Wenn sich ein Agent unerwartet verhält, sollten Nutzer seine anwendungsübergreifende Befugnis deaktivieren können, ohne einzelne Anwendungen durchsuchen zu müssen. Anbieter-Apps sollten sensible Funktionen ebenfalls schnell aussetzen können.

Auch Entwickler werden nach operativen Werkzeugen suchen. Sie benötigen Protokolle für fehlgeschlagene Aufrufe, Schemavalidierung, Kompatibilitätstests, Missbrauchsmeldungen und klares Verhalten über Android-Versionen hinweg. Ein Framework wird erst dann zu einem Ökosystem, wenn Teams es in der Produktion betreiben können.

Googles schrittweise Einführung ist vertretbar. Uneingeschränkte anwendungsübergreifende Handlungsfähigkeit freizugeben, bevor Kontrollen vorhanden sind, würde vorhersehbare Fehler einladen. Das Unternehmen hat stattdessen Berechtigungsprüfungen, Anbieter-Verträge, Testwerkzeuge und wachsende Plattform-APIs aufgebaut, bevor es universellen Zugang ermöglicht.

Die skeptische Sicht ist ebenso vertretbar. Ein sicheres Framework mit wenigen aufrufbaren Funktionen liefert Verbrauchern keinen großen Wert. Ein eng kontrollierter Weg kann unabhängige Entwickler zudem genau zu der Bildschirmautomatisierung drängen, die das Framework ersetzen sollte.

Die Google Android App Functions befinden sich damit an einem wichtigen, aber unvollständigen Übergang. Android verfügt nun über einen nativen Mechanismus, mit dem Agenten klar abgegrenzte Vorgänge entdecken und ausführen können. Die Plattform muss jedoch noch zeigen, dass dieser Mechanismus einen offenen, wettbewerbsfähigen und breit angenommenen Agentenmarkt tragen kann.

In den kommenden Monaten sollte man auf Produktintegrationen über die Launch-Partner hinaus, veröffentlichte Zugriffsregeln für externe Agenten und eine für Nutzer sichtbare Berechtigungshistorie achten. Zusammen werden diese Signale zeigen, ob Google gemeinsame Infrastruktur geschaffen hat – oder eine geschützte Spur für Gemini.

Für Android-Besitzer lautet die praktische Frage nicht, ob ein KI-Agent einen Bildschirm bedienen kann. Experimentelle Systeme haben bereits gezeigt, dass er dazu in der Lage ist. Die Frage ist, ob Android Agenten erlauben kann, über persönliche Apps hinweg zu handeln, ohne Nutzer zur Aufgabe wesentlicher Kontrolle zu zwingen.

Für Entwickler stellt sich die Entscheidung früher. Sie müssen sichere, nützliche Vorgänge identifizieren, die eine strukturierte Freigabe verdienen, und festlegen, an welcher Stelle eine Bestätigung erforderlich ist. Abzuwarten vermeidet kurzfristige Arbeit, kann eine App aber unsichtbar machen, wenn Nutzer beginnen, Aufgaben zu delegieren, statt Oberflächen zu öffnen.

Google hat die Tür gebaut und das Schloss angebracht. Jetzt muss das Unternehmen beweisen, dass vertrauenswürdige Agenten, unabhängige Entwickler und gewöhnliche Nutzer alle die richtigen Schlüssel erhalten können.