AppFunctions: Wie Android Ihre App für AI-Agenten aufrufbar macht

Mit AppFunctions führt Google die Infrastruktur ein, über die AI-Agenten wie Gemini Funktionen Ihrer Android-App direkt aufrufen können: ohne UI, im Hintergrund und app-übergreifend. Dieser Beitrag erklärt, was hinter der API steckt, wie reif sie ist und welche Architektur-Entscheidungen technische Teams jetzt treffen sollten.

„Erinnere mich daran, heute um 17:00 Uhr mein Paket bei der Arbeit abzuholen.“ Bisher bedeutete dieser Satz: App öffnen, durch die UI navigieren, Task anlegen. In Googles Zielbild für die „agentic era“ von Android erledigt das künftig ein Assistent. Er ruft dafür eine Funktion Ihrer App direkt auf, mit sauber typisierten Parametern und ohne dass die App im Vordergrund ist.

Die Technologie dahinter heißt AppFunctions: eine Android-Plattform-API (ab Android 16, @RequiresApi(36)) mit zugehöriger Jetpack-Bibliothek (androidx.appfunctions). Google beschreibt sie als das mobile Äquivalent zu Tools im Model Context Protocol (MCP), also dem Standard, über den auch ChatGPT- und Claude-Integrationen mit externer Software sprechen. Anders formuliert: Ihre App wird zum MCP-Server auf dem Gerät, und Agenten wie Gemini werden zu ihren Clients.

Für technische Entscheider ist das mehr als ein weiteres API-Feature. Es ist die Antwort auf die Frage, wie Apps relevant bleiben, wenn Nutzer zunehmend mit einem Assistenten statt mit einzelnen Apps interagieren. In unserem Beitrag zu GEO für Apps haben wir gezeigt, wie AI-Assistenten Apps empfehlen. AppFunctions ist die Ebene darunter: Sie entscheidet, ob ein Agent Ihre App bedienen kann.

Was AppFunctions technisch sind

Eine AppFunction ist eine Kotlin-Funktion, die per Annotation als Werkzeug für Agenten deklariert wird. Das Grundprinzip besteht aus drei Bausteinen.

1. Deklaration per Annotation. Funktionen werden mit @AppFunction markiert, Datenklassen für Parameter und Rückgabewerte mit @AppFunctionSerializable, der umgebende Service mit @AppFunctionServiceEntryPoint:

/**
 * Create a new task or reminder with a title, due time, and location.
 *
 * @param title The descriptive title of the task (e.g., "Pick up my package").
 * @param dueDateTime The specific date and time when the task should be completed.
 * @param location The physical location associated with the task (e.g., "Work").
 * @return The created Task
 */
@AppFunction(isDescribedByKDoc = true)
suspend fun createTask(
    title: String,
    dueDateTime: LocalDateTime? = null,
    location: String? = null,
): Task

2. KDoc als API-Vertrag. Der Kommentar über der Funktion ist hier keine interne Doku, sondern Teil der Schnittstelle. Mit isDescribedByKDoc = true wird er zur Beschreibung, anhand derer das Sprachmodell entscheidet, ob und mit welchen Parametern es die Funktion aufruft. Google formuliert es im Android Developers Blog deutlich: KDoc-Kommentare sind ein „compiled API asset“, und ihre Qualität bestimmt direkt die Ausführungsgenauigkeit des Agenten. Vage Doku führt zu falschen oder ausbleibenden Aufrufen.

3. Schema-Generierung und Indexierung. Die Jetpack-Bibliothek generiert aus den annotierten Funktionen eine XML-Schemadatei, die das Betriebssystem indexiert. Über diesen zentralen Katalog entdecken Agenten zur Laufzeit, welche Funktionen auf dem Gerät verfügbar sind. Das funktioniert ganz ähnlich wie bei einem MCP-Client, der die Tools eines Servers auflistet.

Auch die Fehlerbehandlung ist auf Agenten ausgelegt. Vordefinierte Exceptions wie AppFunctionInvalidArgumentException oder AppFunctionElementNotFoundException geben dem Agenten maschinenlesbar zurück, warum ein Aufruf gescheitert ist. So kann er korrigieren, statt stumm zu scheitern.

Das Sicherheitsmodell: Wer darf Ihre App steuern?

Die naheliegende Sorge lautet: „Dann kann ja jede App meine Funktionen aufrufen.“ Genau das verhindert Android auf Plattformebene. Aufrufer benötigen die Berechtigung android.permission.EXECUTE_APP_FUNCTIONS, um AppFunctions überhaupt zu entdecken und auszuführen. Diese Berechtigung ist privilegierten, genehmigten Agenten vorbehalten. Die Ausführung läuft über den AppFunctionManager der Plattform und nicht über direkte App-zu-App-Kommunikation. Zusätzlich können Sie pro Funktion steuern, ob sie aktiviert ist; Aufrufer prüfen das via isAppFunctionEnabled().

Wichtig für die Governance-Diskussion im Unternehmen: Die Nutzerintention bleibt der Auslöser. Der Agent handelt auf einen Prompt des Nutzers hin. Welche Funktionen er dafür nutzen darf, definieren Sie über Ihre Metadaten und die Auswahl der exponierten Funktionen.

AppFunctions vs. MCP: on-device statt Cloud

Warum nicht einfach einen klassischen MCP-Server betreiben? Die Doku zieht die Grenze klar: MCP ist plattformunabhängig, läuft aber typischerweise als externer Dienst mit Netzwerk-Roundtrips. AppFunctions sind Hooks auf Betriebssystemebene. Die Ausführung bleibt lokal auf dem Gerät, mit direktem Zugriff auf den vorhandenen App-State, ohne zusätzliche Infrastruktur und mit entsprechend niedriger Latenz. Für Mobile-Anwendungsfälle wie einen Nutzer, der beim Autofahren einen Task diktiert, ist das der entscheidende Unterschied: kein Backend-Call, keine separate Service-Verwaltung, kein zweites Auth-System.

Die strategische Pointe: Wer seine Geschäftslogik ohnehin schon als MCP-Tools für Desktop- und Web-Agenten denkt, bekommt mit AppFunctions das passende Android-Pendant und sollte idealerweise dieselbe Funktionsaufteilung verwenden.

Reifegrad: bewusst früh, aber ernst gemeint

Hier ist Präzision wichtig, denn AppFunctions ist noch nicht produktionsreif.

Die API befindet sich in einer experimentellen Vorabversion, und Google sagt explizit, dass sich die API-Oberfläche noch ändern kann. Die Jetpack-Bibliothek liegt in Alpha-Versionen vor (Stand Juli 2026: 1.0.0-alpha10). Die Gemini-Integration läuft seit Mai 2026 in einer privaten Preview mit Trusted Testern; für End-to-End-Tests können sich ausgewählte Apps über ein Early-Access-Programm registrieren. Zudem begrenzt die Mindestanforderung Android 16 die erreichbare Gerätebasis vorerst.

Warum sich trotzdem jetzt damit beschäftigen? Weil die Vorlaufzeit real ist. Funktionen identifizieren, Geschäftslogik sauber von der UI trennen, KDoc-Qualität etablieren, Testprozesse aufbauen: Das ist Architekturarbeit über mehrere Releases. Teams, die erst starten, wenn Gemini-Integration und API stabil sind, laufen der Konkurrenz hinterher, die dann bereits gelernte, getestete Funktionen ausliefert. Apple verfolgt mit App Intents auf iOS dieselbe Richtung, dort schon heute stabil und von Siri, Spotlight und Apple Intelligence genutzt. Eine plattformübergreifende „Agent-Surface“-Strategie sollte deshalb beide Plattformen zusammen denken.

Was technische Entscheider jetzt konkret tun sollten

Funktionskandidaten identifizieren, und zwar nach Googles eigenem Kriterium. Exponieren Sie nicht wahllos Features, sondern Aufgaben, bei denen ein Sprach- oder Textbefehl objektiv schneller ist als die Navigation durch die UI. Googles Beispiel-Cluster aus der Doku: Tasks und Reminder anlegen, Playlists aus einer Beschreibung erzeugen, Kalendereinträge erstellen sowie app-übergreifende Ketten („Suche das Rezept in der Mail und setze die Zutaten auf die Einkaufsliste“). Drei bis fünf hochwertige Funktionen schlagen zwanzig halbherzige.

Architektur prüfen. AppFunctions rufen Geschäftslogik ohne UI auf. Wenn Kernfunktionen heute nur über Activities und Fragments erreichbar sind, ist das der eigentliche Umbau: Repository-Schicht und Use-Cases müssen standalone aufrufbar sein. Das Code-Beispiel der Doku zeigt das Muster. Der AppFunctionService injiziert ein TaskRepository und arbeitet direkt darauf.

Doku-Qualität als Engineering-Disziplin etablieren. Da KDoc genau das ist, was das Modell liest, gehören Funktionsbeschreibungen in Code-Reviews, inklusive Beispielwerten in den Parameterbeschreibungen, wie Google sie selbst vorführt.

Tooling nutzen. Google stellt eine AppFunctions-Agent-Skill bereit, die die Codebasis nach geeigneten Funktionen analysiert, Kotlin-Implementierungen generiert und KDocs optimiert. Getestet wird lokal per ADB, etwa mit adb shell cmd app_function list-app-functions zum Prüfen der Registrierung und Metadaten. Ein offizielles Beispielprojekt liegt auf GitHub.

Früh Zugang sichern. Wer einen relevanten Use Case hat, sollte die Aufnahme ins Early-Access-Programm prüfen. Dort finden die End-to-End-Tests mit der Gemini-Integration statt.

Fazit: Die zweite Schnittstelle Ihrer App

Zwanzig Jahre lang hatte eine App genau eine Schnittstelle zum Nutzer: ihre UI. AppFunctions etabliert eine zweite, die von Agenten bedient wird und über die ein wachsender Teil der Interaktionen laufen dürfte. Noch ist die API experimentell, aber die Richtung ist eindeutig, und Apple bewegt sich mit App Intents parallel. Die Entscheidung, die jetzt ansteht, ist keine über ein Feature, sondern über Architektur: Ist Ihre Geschäftslogik bereit, ohne UI aufgerufen zu werden?

Sie wollen bewerten, welche Funktionen Ihrer App sich als AppFunctions und App Intents lohnen und was das für Ihre Architektur bedeutet? Wir entwickeln Apps für iOS und Android und begleiten Sie von der Analyse bis zur Umsetzung. Sprechen Sie uns an.

Quellen

• AppFunctions - Übersicht (Android Developers, offizielle Dokumentation)
• Build intelligent Android apps: Integrate into Android’s intelligence system using AppFunctions (Android Developers Blog, Juli 2026)
• The Intelligent OS: Making AI agents more helpful for Android apps (Android Developers Blog, Februar 2026)
• AppFunctions-Beispielprojekt (GitHub)
• Model Context Protocol - Einführung