Source-linked AI summary
AOHP: An Open-Source OS-Level Agent Harness for Personalized, Efficient and Secure Interaction
Shanhui Zhao, Jiacheng Liu, Guohong Liu, Jichao Yan, Jialei Ye, Yuhao Yang, Hao Wen, Shizuo Tian, Yizhen Yuan, Yuxuan Chen, Yunxin Liu, Ju Ren, Ya-Qin Zhang, Chao Huang, Yao Guo, Yuanchun Li
TL;DR
Conventional app-centric operating systems are poorly matched to efficient and safe agent-mediated workflows. AOHP adds agent-oriented mechanisms to Android, and preliminary cross-app task experiments show higher completion with lower execution burden than stock Android.
Problem
Conventional app-centric operating systems provide limited support for agent workflows, whose structured, parallel, persistent, and rapid tool-mediated operation creates efficiency and safety gaps.
Method
AOHP extends AOSP with personalized service composition, efficient agent interfaces, and secure information flow while preserving Android compatibility.
Results
21.12 points higher completion separates AOHP from stock Android, alongside 44.64% fewer tool calls and 44.21% shorter duration on commonly solved tasks.
Takeaways & Limitations
AOHP provides an open, Android-compatible harness for studying agent-native personal computing with higher task completion and lower execution cost than stock Android.
Takeaways & Limitations
AOHP’s background execution must still respect mobile resource, thermal, and memory limits, motivating fuller scheduling policies.
Abstract
from arXiv · showhide
AI agents are driving a new software paradigm, with the ability to autonomously call tools, extract information, manage memory, and complete tasks that span applications and data sources. Most existing end-user operating systems, however, are designed for application-centric workflows and offer little native support for AI agents. This mismatch limits the wider adoption of agents and leads to execution overhead and safety risks when running agents on conventional systems. While the concept of agent-native operating systems is emerging, the research community lacks an open testbed to explore the architectural primitives desired for agent-mediated interaction. We present AOHP (Android Open Harness Project), an OS-level agent harness built on the Android Open Source Project (AOSP). The core design principle of AOHP is to treat agents as first-class OS actors, enabling adaptive user interfaces and agent-friendly runtime environments. AOHP preserves the mature Android software and hardware ecosystem while introducing three agent-oriented system mechanisms: personalized service composition, efficient agent interfaces, and secure information flow. Based on preliminary experiments on challenging tasks covering key capabilities of OS agents, AOHP shows clear advantages in task completion (+21.12% completion rate), execution cost (-51.55% token cost), and security-policy compliance.
1. Introduction
Conventional app-centric operating systems create execution overhead and security gaps for agent-mediated work because their interfaces, lifecycles, and permissions are not designed for agents. AOHP redesigns Android as an agent-native harness that preserves ecosystem compatibility while adding OS-level support for personalized, efficient, and auditable agent interaction.
- Motivation: App-centric operating systems impose execution overhead and security gaps because fixed interfaces target direct human use, lifecycles assume one active app, and permissions do not track sensitive data across agent contexts.These assumptions hinder agent-mediated workflows involving graphical interfaces, application APIs, command-line tools, and multi-step coordination.
- AOHP approach: AOHP redesigns Android through OS-level abstractions and framework modifications while preserving hardware support, the open-source framework, and app compatibility.The harness makes services composable, efficient, and auditable for OS-level agents.
- Personalized interaction: AOHP enables the OS to generate personalized service interfaces around user intent instead of requiring users to adapt to predefined operating-system and application interfaces.This shifts interaction toward high-level task concepts while the OS agent handles service discovery, invocation, and multi-service coordination.
- System mechanisms: AOHP introduces personalized service composition, efficient agent interfaces, and secure information flow as core mechanisms for agent-native operation.The implementation includes task-level entrances, parallel background execution, and OS management of cross-application personalization and sensitive state.
2. Background & Motivation
Conventional app-mediated operating systems constrain users and are not efficient or safe for agent-mediated interaction. AOHP addresses this gap by building an adaptive, agent-oriented harness over Android, reusing its mature ecosystem while enabling deeper system redesign.
- Problem: Traditional operating systems expose app-defined interfaces that force users to passively adapt to developer-selected services and workflows.This can be tedious, distracting, and increasingly problematic as applications grow larger and more dominant.
- Motivation: Adaptive operating systems can personalize interfaces around user intent and aggregate capabilities from multiple services into unified task-specific entrances.A shopping entrance could combine search, comparison, coupons, delivery constraints, and purchase actions across marketplaces.
- Motivation: AI agents can execute adaptive interactions by operating applications, invoking system functions, transferring data across services, and acting over time.They can serve as an execution layer between user intent and app-level operations.
- Problem: Conventional OS designs cannot make agent execution efficient or safe by construction because agents process structured text, parallelize tasks, retain long-lived context, and rapidly issue tool calls.Existing systems assume app-mediated interaction, whereas agents have different operational properties.
- AOHP rationale: AOHP therefore builds an agent-mediated adaptive-interface harness over Android, redesigning selected system and framework components while reusing others.Android is chosen as the substrate because its mature platform can support practical systems research and rich custom services.
3. System Design
AOHP treats agents as first-class OS actors through on-demand personalized service composition, unified efficient interfaces, and secure information flow. Its architecture preserves Android compatibility while organizing agent capabilities into layered, task-specific interaction surfaces.
- Design principles: AOHP defines three design principles: on-demand personalized service composition, efficient interface-neutral agent interaction, and secure information flow.The principles aim to break application silos, provide a unified interaction substrate, and protect agent-mediated execution.
- Layered architecture: The four-layer architecture retains Android apps, services, hardware, and APIs as its compatibility base while adding agent-oriented layers above it.The unified interaction interface normalizes traditional and emerging agent interfaces into API, CLI, Structured UI, and Rendered GUI modes.
- AOHP capabilities layer: AOHP organizes reusable capabilities into system memory, skills, and UI utilities for preferences, task state, histories, policy decisions, service routines, and generated interaction surfaces.These capabilities are supplied by apps, system components, and agent tools rather than being confined to a single application.
- Personalized service composition: Personalized service composition assembles capabilities into task-specific application surfaces while the OS agent resolves the underlying service graph and execution path.Users interact with a personalized service entrance tailored to the current task.
- Cross-layer mechanisms: Efficient agent interfaces reduce visual-processing overhead, avoid unnecessary foreground serialization, and lessen dependence on brittle GUI navigation across system resources and app state.The mechanism also covers files, events, and isolated execution substrates.
4. Personalized Service Composition
AOHP replaces predefined app interaction with personalized, agent-generated service entrances organized around recurring user goals. These entrances compose capabilities across service channels while enforcing policies and supporting OS-mediated personalization across app boundaries.
- Personalized Service Entrances: AOHP lets the OS agent synthesize personalized service entrances around recurring goals, shifting interaction from app navigation to task-level service access.Unlike conventional apps, which expose developer-chosen functions, AOHP generates interaction surfaces around user tasks.
- Personalized Service Entrances: Each entrance combines a task schema, service graph, and presentation policy to map user goals to capabilities and control which intermediate results users see.Examples include comparing shoes under a budget or refilling household supplies.
- Cross-Channel Composition: AOHP discovers capabilities across API, CLI, and GUI channels, representing schemas, preconditions, side effects, and policy labels for higher-level workflow composition.GUI export allows legacy apps to participate, while newer services can expose more direct APIs.
- Policy-Constrained Composition: Generated entrances enforce composition policy: product search may run in parallel, but purchase submission requires explicit confirmation and address use for shipping estimates is sandboxed.Thus, the entrance functions as both a convenience layer and a policy-enforcement surface.
- OS-Mediated Personalization: OS-mediated memory carries preferences across app boundaries while distinguishing persistent profile, task-local, and sensitive memory to support sharing, auditing, revocation, and privacy controls.Sensitive values are stored through sandbox indices, preventing personalization from becoming an uncontrolled accumulation of private context.
5. Efficient Agent Interfaces
AOHP provides agent-native interfaces that reduce visual-processing, sequential-execution, and cross-app handoff overhead. Its abstractions support background execution, structured GUI reasoning, sandboxed computation, first-class files, and event-driven interaction.
- Agent-native primitives: AOHP exposes execution environments, UI semantics, storage, and events as agent-native primitives.These abstractions reduce visual-processing overhead, rigid sequential execution, and brittle cross-app handoffs.
- Background execution: Lightweight virtual displays decouple execution from the physical screen, enabling background workflows without preempting the active foreground session.This supports waiting-heavy or independent workflows on conventional mobile systems.
- Structured interfaces: AOHP represents GUIs with lower-redundancy, richer-semantic structures while retaining rendered GUI fallback for visual components.This removes rendering details unnecessary for agent reasoning.
- Sandbox runtime: An OS-managed sandbox lets agents execute code, process data, and host long-running services independently of app-facing interfaces.Agents can reset the sandbox and return structured results without placing intermediate steps in the agent context.
- Task objects and event streams: AOHP treats files as first-class task objects and provides an Event Stream abstraction for subscribing to continuous data sources.The event system supports notification capture and sensor streaming, separating event generation from consumption so agents can react without repeated polling.
6. Secure Information Flow
AOHP secures information flow by keeping sensitive plaintext under OS control while agents operate on typed references. Runtime policies, trusted execution, sanitization, and taint tracking govern private-data use, transfers, and auditability across system boundaries.
- Secure Information Flow: AOHP replaces private plaintext with typed references before agent exposure and preserves sensitive values in a data vault managed by trusted system components.Supported sources include application pages, files, event streams, API responses, system memory, and user interactions.
- Secure Information Flow: AOHP evaluates each sensitive operation by data source, purpose, destination, action sensitivity, and approval state, allowing ordinary flows while requiring consent or blocking risky actions.The policy layer governs runtime data use rather than only static permissions or application identities.
- Secure Information Flow: AOHP explains approval requests using the private data’s source, purpose, destination, and downstream effect instead of an opaque permission prompt.This ties enforcement to the concrete use of private data in the task.
- Secure Information Flow: Trusted vault executors perform formatting, comparison, validation, composition, and approved transfers without returning sensitive results to the agent as plaintext.They can fill approved GUI fields or substitute plaintext at API and CLI boundaries while keeping values out of agent context.
- Secure Information Flow: Taint metadata follows sensitive values through copying, transformation, composition, and transfer, preserving provenance across indirect multi-step task use.At policy-relevant boundaries, AOHP checks tainted data before display, storage, submission, or transmission and records an auditable source-to-sink path.
7. Evaluation
AOHP is evaluated against stock Android using the same OpenClaw agent on 30 real-world mobile tasks spanning GUI, non-GUI, event, retrieval, memory, and hybrid capabilities. AOHP improves completion and execution efficiency while evaluating information-flow security through annotated payment-app tests.
- Evaluation setup: AOHP compares OpenClaw with stock Android, adding generated service entrances, structured UI observations, system CLIs/APIs, virtual execution, and sandboxed information flow.Stock Android provides conventional GUI observations and ordinary app interactions, while AOHP is the agent-native setting.
- Benchmark: The benchmark contains 30 real-world mobile tasks across GUI operation, non-GUI operation, event capture, multi-source retrieval, memory management, and hybrid workflows.The hybrid category composes primitives into longer cross-capability workflows for service composition.
- Completion: 75.56% average completion on AOHP versus 54.44% on stock Android, a 21.12-point gain with seven more tasks fully solved.AOHP fully solves 20 tasks and partially completes 5, compared with 13 fully solved and 7 partially completed on stock Android; scoring uses objective checkpoints.
- Execution cost: 51.55% fewer total tokens and 47.62% fewer LLM requests on the 11 commonly solved tasks, with totals of 3.44M versus 7.10M tokens and 143 versus 273 requests.AOHP reduces execution steps and returns more compact observations, shrinking prompt length and round-trips.
- Information-flow security: AOHP’s security evaluation uses an annotated payment application and case-driven tests covering sanitization, mediation, vault tokens, taint propagation, files, events, and fail-closed behavior.The application exposes account information, payment credentials, transfers, confirmations, invoices, and transaction-related event streams.
8. Related Work
Prior GUI agents, mobile automation systems, and security defenses improve agent operation or constrain tool use, but generally retain app-centric execution assumptions. AOHP instead redesigns operating-system interfaces and enforcement mechanisms for personalized interaction, agent-aware execution, and mobile information-flow control.
- GUI Agents: GUI agents span modular architectures that combine planning, retrieval, memory, and grounding with end-to-end policies that directly infer interface actions.Examples include AutoDroid, Agent S, OS-Copilot, AppAgent, UI-TARS, Mobile-Agent, and SeeAct.
- OS-Level Design: AOHP differs by treating the execution environment as a design target, redesigning OS interfaces and enforcement mechanisms rather than only strengthening agent policies.Existing GUI-agent systems mainly treat the operating system as a fixed substrate.
- OS-Level Design: AOHP relocates screen understanding and interaction support into OS abstractions, adding personalized service entrances, agent-aware UI enhancement, parallel background interaction, and system-managed task traces.Earlier automation and GUI-grounding systems inherit app-centric rendering paths, foreground-oriented execution assumptions, and app-defined interaction surfaces.
- Security: Security research documents prompt-injection and tool-use risks, while FIDES and f-secure LLM systems apply deterministic information-flow controls at agent execution boundaries.These defenses use labels, taint propagation, and policy checks; AOHP moves the enforcement boundary to the mobile OS and builds on TaintDroid’s mobile taint-tracking lineage.
9. Conclusion and Future Work
AOHP is an agent-native Android fork that preserves compatibility while adding mechanisms for personalized service composition, efficient agent interfaces, and secure information flow. Future work targets compatibility coverage, capability discovery, resource scheduling, and policy usability.
- Conclusion: AOHP preserves Android compatibility while adding personalized service composition, efficient agent interfaces, and secure information flow.Preliminary OpenClaw results show higher task completion and lower execution cost than stock Android, while a security case study demonstrates redaction, tracking, and mediation at system boundaries.
- Compatibility coverage: Future compatibility work targets custom rendering, antiautomation logic, and undocumented app behavior.The proposed remedies are stronger structured UI extraction, predictable rendered-GUI fallback, and clearer compatibility guidelines for app developers.
- Capability discovery: AOHP should combine developer-provided descriptors with automatic capability inference to integrate legacy apps with less manual annotation.Accurate service descriptions, side-effect labels, and policy metadata remain prerequisites for capability discovery.
- Resource scheduling: Future resource scheduling must respect mobile resource, thermal, and memory limits.A fuller prototype should expose policies for virtual displays, sandbox runtimes, event streams, and foreground user activity.
- Policy usability: Future policy usability work should make fine-grained information-flow approvals understandable without excessive interruption.Improvements include approval UI, trace review, and explanations covering purpose, destination, retention, and consent.
A. Benchmark Tasks
The benchmark contains 30 real-world mobile tasks spanning five core capability categories and a hybrid category that composes them. Memory-management tasks additionally test both task execution and memory-related question answering.
- Benchmark composition: 30 real-world mobile tasks are organized into five core capability categories plus a hybrid composition category, with five tasks per category.The benchmark lists tasks in capability order.
- Memory management: Memory-management tasks use two stages: first executing the task, then answering memory-related questions.This design evaluates both task performance and memory handling within the same task.
- Category 6 — Hybrid (Capability Composition): Hybrid tasks compose capabilities across applications, such as changing a Calendar meeting and setting a Clock alarm before its start.The task requires coordinating Calendar and Clock operations around the same meeting.
- Category 6 — Hybrid (Capability Composition): Other benchmark tasks require cross-application coordination, including messaging a colleague, updating a Calendar event from the reply, and scheduling or declining an event based on availability.These tasks combine SMS interaction, notification handling, Calendar inspection, and conditional responses.