Paper deep dive
PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power Management
Xingyu Feng, Chang Sun, Yuzhu Wang, Zhangbing Zhou, Chengwen Luo, Zhuangzhuang Chen, Xiaomin Ouyang, Huanqi Yang
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 97%
Last extracted: 3/23/2026, 12:07:03 PM
Summary
PowerLens is a multi-agent system that leverages Large Language Models (LLMs) to provide safe, personalized, and context-aware power management for Android devices. It uses a multi-agent architecture to infer user context from UI semantics, a PDL-based constraint framework to ensure safety, and a two-tier memory system to learn user preferences through implicit feedback, achieving significant energy savings while maintaining high user satisfaction.
Entities (4)
Relation Signals (3)
PowerLens → manages → Android
confidence 100% · PowerLens... for safe and personalized mobile power management on Android devices.
PowerLens → utilizes → Large Language Models
confidence 100% · PowerLens, a system that tames the reasoning power of Large Language Models (LLMs)
PDL → verifies → PowerLens
confidence 95% · A PDL-based constraint framework verifies every action before execution
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Battery life remains a critical challenge for mobile devices, yet existing power management mechanisms rely on static rules or coarse-grained heuristics that ignore user activities and personal preferences. We present PowerLens, a system that tames the reasoning power of Large Language Models (LLMs) for safe and personalized mobile power management on Android devices. The key idea is that LLMs' commonsense reasoning can bridge the semantic gap between user activities and system parameters, enabling zero-shot, context-aware policy generation that adapts to individual preferences through implicit feedback. PowerLens employs a multi-agent architecture that recognizes user context from UI semantics and generates holistic power policies across 18 device parameters. A PDL-based constraint framework verifies every action before execution, while a two-tier memory system learns individualized preferences from implicit user overrides through confidence-based distillation, requiring no explicit configuration and converging within 3--5 days. Extensive experiments on a rooted Android device show that PowerLens achieves 81.7% action accuracy and 38.8% energy saving over stock Android, outperforming rule-based and LLM-based baselines, with high user satisfaction, fast preference convergence, and strong safety guarantees, with the system itself consuming only 0.5% of daily battery capacity.
Tags
Links
- Source: https://arxiv.org/abs/2603.19584v1
- Canonical: https://arxiv.org/abs/2603.19584v1
Trouble viewing inline? Open PDF directly →
Full Text
74,858 characters extracted from source content.
Expand or collapse full text
PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power Management Xingyu Feng 1 , Chang Sun 1 , Yuzhu Wang 1 , Zhangbing Zhou 1 , Chengwen Luo 2 , Zhuangzhuang Chen 3 , Xiaomin Ouyang 3 , Huanqi Yang 4 1 China University of Geosciences (Beijing), 2 Shenzhen University, 3 Hong Kong University of Science and Technology, 4 City University of Hong Kong ABSTRACT Battery life remains a critical challenge for mobile devices, yet existing power management mechanisms rely on static rules or coarse-grained heuristics that ignore user activities and personal preferences. We present PowerLens, a system that tames the reasoning power of Large Language Mod- els (LLMs) for safe and personalized mobile power manage- ment on Android devices. The key idea is that LLMs’ com- monsense reasoning can bridge the semantic gap between user activities and system parameters, enabling zero-shot, context-aware policy generation that adapts to individual preferences through implicit feedback. PowerLens employs a multi-agent architecture that recognizes user context from UI semantics and generates holistic power policies across 18 device parameters. A PDL-based constraint framework veri- fies every action before execution, while a two-tier memory system learns individualized preferences from implicit user overrides through confidence-based distillation, requiring no explicit configuration and converging within 3–5 days. Extensive experiments on a rooted Android device show that PowerLens achieves 81.7% action accuracy and 38.8% energy saving over stock Android, outperforming rule-based and LLM-based baselines, with high user satisfaction, fast pref- erence convergence, and strong safety guarantees, with the system itself consuming only 0.5% of daily battery capacity. 1 INTRODUCTION Battery life remains one of the most persistent pain points for smartphone users. Despite decades of hardware and OS-level optimization, mobile devices still struggle to last through a full day of active use [2,5,9]. As smartphones become the primary computing platform for billions of users, supporting tasks from navigation and video streaming to mobile gaming and video conferencing, their power management systems face an increasingly complex optimization landscape. Dozens of adjustable parameters, including screen brightness, re- fresh rate, CPU governor, location mode, and connectivity radios, must be jointly balanced against diverse and context- dependent user requirements. Existing approaches to mobile power management can be broadly classified into three categories: hardware-level, Android Battery Saver PowerLens (Ours) Ignores User Breaks APP Blindly Kept Poor UX / Functionality Risk Global Rules Multi-Agent + Memory APP Need User Habit Force Brightness to 30% Downgrade GPS accuracy Background apps unlimited Keep Brightness 60% Selectively Optimize Keep GPS high-accuracy Refresh rate 120 → 60 Hz Disable BT, NFC, auto-sync Dark mode on, limit BG ⋯ Refresh rate still 120 Hz Dark mode still off ⋯ UX Preserved / Energy Saved Scenario: User is Navigating “Battery < 20%” Poor UX / Functionality Risk UX Preserved / Energy Saved Android Battery Saver PowerLens (Ours) Ignores User Breaks APP Blindly Kept APP Need User Habit Selectively Opt. Global Rules Multi-Agent + Memory VS Downgrade GPS accuracy Force Brightness to 30% 120 Hz kept; Dark model still OFF; BG unlimited 60 Hz; Dark mode ON; Disable BT, NFC, auto-sync Keep Brightness 60% Keep GPS high-accuracy Figure 1: Traditional power saver vs. PowerLens. Global rules degrade navigation by throttling GPS and dimming brightness; PowerLens preserves critical resources and learned preferences. OS-level, and learning-based techniques. Hardware-level ap- proaches such as DVFS [14,19] reactively adjust CPU fre- quency based on instantaneous utilization using governors likeondemandandschedutil. While effective at the CPU level, they are oblivious to the broader device context: the same CPU load during navigation versus a background sync has fundamentally different optimization opportunities. OS- level mechanisms such as Android’s Adaptive Battery and App Standby Buckets [1] apply coarse-grained heuristics based on app usage recency to classify apps into priority tiers, which ignore both app-specific functional requirements (e.g., navigation requires high-accuracy GPS) and individ- ual user preferences (e.g., a user who always prefers high brightness while reading). Orthogonally, learning-based ap- proaches [24,36] attempt to learn optimal policies from his- torical usage traces and system telemetry, but typically re- quire extensive training data, struggle to generalize across devices and usage patterns, and operate on low-level numeri- cal signals without semantic understanding of user activities. In this work, we introduce PowerLens, a Large Language Model (LLM)-powered personalized power management sys- tem for mobile devices. The key insight is that LLMs can serve as zero-shot system-level reasoners, bridging the se- mantic gap between user activities and device parameters. arXiv:2603.19584v1 [cs.AI] 20 Mar 2026 Conference’17, July 2017, Washington, DC, USAFeng et al. Bright.RefreshCPUGPSBG Proc. System Parameter 0 20 40 60 80 100 Optimal Level (% of Max) Navigation Video Call Reading Music (BG) (a) Resource levels vary by activity. Nav.VideoMeet.SocialMusicRead. Activity 0 1000 2000 3000 4000 Power Draw (mW) -33.3% -26.6% -18.6% -40.5% -48.6% -49.7% Context-Blind Context-Aware (b) Context-blind wastes 19–50%. Dim Bright. Lower Refresh Throttle CPU Reduce GPS Limit BG System Adjustment 0 20 40 60 80 100 Override Rate (%) Professional Gamer Commuter (c) Override patterns vary by user. Out-of- Range Critical Disabled Conflict. Settings Invalid Param Perm. Violation Violation Type 0 5 10 15 Occurrence Rate (%) GPT-4o Gemini-2.5-Flash Kimi-K2 (d) LLM violation types across models. Figure 2: Preliminary studies on challenges of mobile power management. For example, an LLM can understand that “the user is navigat- ing to an unfamiliar destination” implies GPS accuracy and screen visibility are critical, while background sync and high refresh rates can be safely reduced. PowerLens combines this reasoning capability with domain-specific knowledge about device constraints and a personalized memory system that learns user preferences through implicit feedback (Fig. 1). Unlike existing LLM-based mobile agents [15,39,44] that focus on UI-level task automation (e.g., “send a message” or “book a restaurant”), PowerLens operates at the system-level resource management layer, adjusting hardware parameters that are invisible to the user interface but critically affect both battery life and user experience. This introduces three unique challenges: (1)Context-Aware Policy Generation. Effective power management requires jointly reasoning about what the user is doing, what the current app needs, and what the device supports. As shown in Fig. 2(a), optimal resource levels vary dramatically across activities (navigation de- mands high GPS and brightness while music playback needs almost none), and applying context-blind defaults wastes 19–50% power compared to a context-aware ora- cle (Fig. 2(b)). A single app (e.g., a browser) may exhibit vastly different resource requirements depending on the content (video playback vs. text reading), and different users may have different tolerance for performance degra- dation. Our approach: We address this by designing a multi-agent architecture where specialized agents de- compose the problem: the Activity Agent infers semantic context from UI states, and the Policy Agent synthesizes a holistic strategy informed by device capabilities and user preferences. (2) Personalized Preference Learning from Implicit Feedback. Users rarely provide explicit power manage- ment preferences (e.g., “I prefer 60 Hz for reading”). In- stead, their preferences are revealed implicitly through manual overrides: when a user increases brightness after the system dimmed it, this signals dissatisfaction. Fig. 2(c) illustrates that override patterns are highly user-specific: a Gamer frequently rejects CPU and refresh-rate throt- tling, while a Commuter overrides display dimming but accepts compute savings. Our approach: We design a two-tier memory system with a state differencing mecha- nism that detects such overrides and a confidence-based distillation process that gradually promotes observed patterns into stable preference rules. (3)Safe and Verifiable Execution. LLMs can hallucinate invalid parameter values or propose changes that would break app functionality (e.g., disabling GPS during navi- gation). Fig. 2(d) shows that raw LLM outputs produce over 20% problematic actions even from frontier models. Our approach: We introduce a constraint verification framework based on Propositional Dynamic Logic (PDL) that validates every LLM-generated action against device- specific capabilities and app-category safety invariants before execution, ensuring that creative optimization strategies never violate critical constraints. We implement PowerLens 1 as an Android system ap- plication requiring root access and evaluate it on Power- LensBench, a new benchmark we constructed, spanning mainstream apps across 7 usage categories. Compared to stock Android and three baselines (Battery Saver, Rule-Based, Single-Agent LLM), PowerLens achieves the best balance of energy saving (38.8%) and user experience (4.3/5.0, 81.7% action accuracy) while maintaining the lowest safety vio- lation rate (0.6%). The two-tier memory system converges within 3–5 days, and the PDL checker eliminates 96.5% of raw LLM-generated safety violations. Our main contributions are: • PowerLens is the first system to employ LLM agents for personalized, context-aware power management on mo- bile devices, decomposing the problem via a multi-agent architecture into activity recognition, policy generation, execution verification, and implicit feedback collection. • A two-tier memory system with implicit feedback detec- tion via state differencing and confidence-based prefer- ence distillation, enabling personalized preference learn- ing without explicit user configuration and converging within 3–5 days across diverse user profiles. 1 Project page with demo videos: https://anonymous-powerlens.github.io/ PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA •A PDL-based constraint verification framework that en- sures LLM-generated power policies respect device capabil- ities and app-specific safety invariants, reducing violations by 96.5% while preserving LLM reasoning flexibility. •Extensive experiments across 48 tasks, 7 app categories, and diverse user profiles on real hardware, along with an in-the-wild user study, demonstrating 38.8% energy saving with 81.7% action accuracy and 4.3/5.0 user experience. 2 BACKGROUND AND MOTIVATION 2.1 Mobile Power Management Landscape Table 1 summarizes the 18 parameters that PowerLens con- trols, spanning five categories: display (brightness, refresh rate, timeout, dark mode, auto-rotation), connectivity (Wi- Fi, Bluetooth, NFC, mobile data, location mode), compute (CPU governor, core mask, background process limit), au- dio (media, notification, ringtone, and alarm volumes), and sync (auto-sync). Even the 18 controlled parameters span a combinatorial action space exceeding 10 17 valid configu- rations. Fig. 3 illustrates the hardware complexity behind a single navigation session: turn-by-turn guidance simul- taneously draws power from the SoC (route computation), GNSS receiver (positioning), 5G modem and Wi-Fi radio (map downloads), OLED panel (high-brightness map render- ing), speaker (voice prompts), and Bluetooth radio (hands- free audio), engaging components distributed across both sides of the mainboard and the daughter board. Saving power in such a scenario requires coordinated trade-offs across all five parameter categories (13 of 18 parameters active), a task beyond any single-component governor. Current mechanisms operate at different granularities. At the lowest level, DVFS governors such asschedutildynam- ically scale CPU frequency based on load, while advanced governors like GearDVFS [19] account for concurrent work- load interference. At the OS level, Android Adaptive Battery classifies apps into standby buckets (Active, Working Set, Frequent, Rare, Restricted), applying progressively stricter scheduling and network limitations. Doze mode aggressively restricts background activity when idle. These mechanisms share a fundamental limitation: they lack semantic understanding of user activities. Adaptive Bat- tery treats a food delivery app in the same standby bucket regardless of whether the user is actively tracking an order or has not opened it in days. DVFS governors cannot distin- guish CPU load from a video call (where frame drops degrade experience) versus background indexing (where throttling is imperceptible), leaving significant optimization opportuni- ties unexploited. Display brightness, refresh_rate, dark_mode, screen_timeout Screen always-on Map rendering Connectivity location_mode, mobile_data, wifi, bluetooth GPS positioning Map data download BT audio streaming Compute cpu_governor, cores_online, bg_process_limit Route computation Audio media_volume Voice guidance Sync auto_sync Background sync Wi-Fi/BT LPDDR5X RAM SoC NFC PMIC 5G RF Power Amplifier Display Driver IC Microphone Microphone Mainboard Sub-board Mainboard Side1 Mainboard Side2 Figure 3: Hardware activated during navigation. A single app engages components across the mainboard and daughter board, spanning all five parameter categories in Table 1. 2.2 LLMs as System-Level Reasoners The recent success of LLM-based agents in mobile task au- tomation demonstrates that LLMs can effectively reason about complex software systems: AutoDroid [39,40] plans multi-step actions without training; MobileGPT [15] aug- ments LLMs with task memory for recurring tasks; Au- toIOT [34] bridges natural language intent and low-level device operations. These results suggest LLMs possess three capabilities es- sential for power management: (1) semantic understanding, inferring that “Google Maps showing turn-by-turn direc- tions” implies the user needs GPS accuracy; (2) commonsense reasoning, knowing that reducing brightness during night- time reading is acceptable but during outdoor navigation is not; and (3) compositional planning, generating coordinated policies across multiple parameters (e.g., simultaneously re- ducing refresh rate and switching to a power-saving CPU governor for a reading session). However, system-level re- source management introduces challenges absent from task automation: actions are continuous rather than discrete UI clicks, consequences are latent, and safety constraints are strict (a wrong GPS setting can cause navigation failure). 2.3 Motivating Scenarios Three scenarios illustrate these limitations: Scenario 1: Context-blind optimization. A user opens a news-reading app. The stock system maintains 120 Hz re- fresh rate and high CPU frequency, wasting power on re- sources that reading does not need. An LLM-powered system recognizes the reading activity and reduces the refresh rate to 60 Hz and switches to a power-saving CPU governor. Scenario 2: Ignoring personal preferences. Two users open the same video streaming app at night: User A prefers low brightness (dark room), User B prefers medium bright- ness (public transit). Stock Android applies the same adaptive brightness to both, satisfying neither. PowerLens learns these distinct preferences through implicit feedback: when User Conference’17, July 2017, Washington, DC, USAFeng et al. Table 1: Parameters controlled by PowerLens. 18 parameters across 5 categories, spanning a joint state space of>10 17 configurations. CategoryPower ¶ ParameterHW ComponentRangeDefault † Control APIGranularity Root Latency |S| Impact ‡ Display42% BrightnessOLED panel0–4096AutoSettings.SystemContinuous—< 1 s4,097H Refresh rateDisplay controller30, 60, 90, 120 Hz120 HzSettings.SystemDiscrete—< 1 s4H Screen timeoutDisplay controller15 s–30 min30 sSettings.SystemDiscrete—Deferred7M Dark modeOLED panelOn/OffOffUiModeManagerBinary—< 1 s2L Auto-rotationGyroscope/Accel.On/OffOnSettings.SystemBinary—< 1 s2L Connectivity25% Wi-FiWi-Fi radio (WCN7851)On/OffOnSettings.GlobalBinary—1–3 s2M BluetoothBT radio (WCN7851)On/OffOnSettings.GlobalBinary—1–2 s2L NFCNFC controllerOn/OffOnSettings.GlobalBinary—< 1 s2L Mobile data5G/LTE modemOn/OffOnTelephonyManagerBinary✓2–5 s2M Location modeGNSS receiverOff/Dev./Saving/HighHighSettings.SecureDiscrete—1–3 s4H Compute20% CPU governorSoC (Snapdragon 8G3)powersave/schedutil/perf.schedutilsysfsDiscrete✓< 10 ms3H CPU cores onlineSoC (per-core)8-bit binary mask0xFFsysfsBitmask✓< 10 ms256H BG process limitSoC / RAM−1, 0, 1, 2, 3, 4−1Settings.GlobalDiscrete—Deferred6M Audio5% Media volumeSpeaker / DAC0–160—AudioManagerContinuous—< 1 s161L Notif./Ring/Alarm vol. ∗ Speaker / DAC0–16 ea.—AudioManagerDiscrete—< 1 s17 eachL Sync8%Auto-syncCPU / RadioOn/OffOnContentResolverBinary—Async2M † Default on test device (OnePlus ACE 5, Snapdragon 8 Gen 3, Android 15 with KernelSU). ¶ Representative category-level power proportions under typical mixed use [9]. ‡ Impact: High (>15% category saving), Medium (5–15%), Low (<5%).|S|: discrete states per parameter; Î |S 푖 |>10 17 . ∗ Notif./Ring/Alarm: three independent streams, 17 states each. Device Profiler One-time Setup Activate PowerLens Accessibility GUI UI Tree Android System Activity Agent Policy Agent Execution Agent LLM #1 LLM Feedback Agent LLM Power Management Loop Memory System ContextRecognition Strategy Generation “User is Meeting !” Bright.↓, Wi-Fi keep Verify & Execute $ su -c ⋯ State Differencing User Override ! Personal Rules LPM User Feedback STM Distillation Extractor UI Tree / Device State Shell Commands Preferences State Δ LLM Filter Figure 4: PowerLens system overview. Each cycle:➊Accessibil- ity captures UI tree,➋Activity Agent recognizes context,➌Policy Agent generates strategy,➍➎Execution Agent verifies and applies via shell commands,➏Feedback Agent detects user overrides. The Memory System stores preferences for personalization. B repeatedly overrides the system’s dimming, the memory system captures this pattern and stops overriding in future sessions. Scenario 3: Safety-unaware power saving. When battery drops below 20% during navigation, Android’s Low Power Mode force-dims the screen and throttles GPS (Fig. 1, left), breaking the navigation experience. PowerLens recognizes that GPS and screen visibility are critical for navigation, preserves them, and saves power through other parameters instead (e.g., reducing refresh rate) (Fig. 1, right). 3 SYSTEM DESIGN As shown in Fig. 4, PowerLens comprises two tightly coupled subsystems: the Android System layer and the Power Man- agement Loop. The Android System layer provides a Device Profiler that enumerates adjustable parameters and their valid ranges (the action space library), and an Accessibil- ity framework that converts the foreground app’s GUI into structured UI XML for semantic activity recognition. The Power Management Loop orchestrates four agents (Activity, Policy, Execution, and Feedback) in a closed-loop control system, connected by a two-tier Memory System whose asynchronous Extractor performs LLM-based intent analysis during device idle time. In total, the system involves five LLM invocation points: four synchronous calls per decision cycle (Activity, Policy, and two Execution stages) plus one asynchronous call in the Extractor for preference distillation. Unlike traditional approaches [24,36], PowerLens leverages LLM reasoning for zero-shot, personalized policy generation with safety verification. 3.1 Multi-Agent Power Management Loop PowerLens decomposes the power management problem into four specialized agents, Activity (푀 푎 ), Policy (푀 푝 ), Ex- ecution (푀 푒 ), and Feedback (푀 푓 ), that form a sequential pipeline with a feedback loop. Of these, Activity, Policy, and Execution invoke the LLM; the Feedback Agent uses deterministic state differencing without LLM inference. This modular design enables independent testing and updating of each agent, graceful degradation via fallback policies, and interpretable reasoning. 3.1.1 Activity Agent. The Activity Agent 푀 푎 is responsible for transforming raw device signals into a semantically rich context representation. It takes three inputs: (1) the UI tree, obtained via Android’s Accessibility framework, which cap- tures the current screen’s widget hierarchy as a structured JSON document; (2) the device context휎, a snapshot of the device’s current state including battery level, connectivity status, sensor readings, and all adjustable parameter values; and (3) the recent app history, which records the apps used within the past hour along with their usage durations. Using these inputs,푀 푎 performs three functions. Activ- ity recognition: the UI tree and recent app history are fed to an LLM that identifies (i) the user’s current high-level activity type corresponding to the app category (e.g., Nav- igation, Video_Watching, Gaming, Reading), and (i) a finer-grained sub-activity describing the specific interaction mode within the app (e.g., “actively watching” vs. “browsing PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA comments” in a video app), along with a recognition cer- tainty score and critical level (high/medium/low) indicating how interruption-sensitive the activity is. Context extrac- tion: the agent extracts structured context tags including the foreground app, UI state, inferred user intent, and envi- ronmental cues (e.g., “user is in a meeting room based on connected Wi-Fi SSID”). Context signature construction: the extracted features are discretized into a context signature s, a compact tuple of the factors that most influence power policy selection: s= cat(퐴 푡 ), type(퐴 푡 ), bucket(퐵 푡 ), period(푇 푡 ) ,(1) wherecat(퐴 푡 )is the app category,type(퐴 푡 )the recognized sub-activity,bucket(퐵 푡 ) ∈ High, Mid, Lowdiscretizes bat- tery level, andperiod(푇 푡 )captures temporal context. This compact discrete signature enables efficient LPM retrieval despite the continuous nature of the underlying state space. 3.1.2 Policy Agent.푀 푝 receives the device context휎, activ- ity recognition result, memory-derived preferences (Sec. 3.2), PDL safety constraintsΦ(Sec. 3.3.1), and device capabili- ties, and generates a structured policy휋through priority arbitration across three memory sources: 휋= Arbitrate 퐶 STM |z highest , 푅 LPM (s) | z medium , 퐺 LPM |z lowest ,(2) where퐶 STM denotes active constraints from STM (user man- ual overrides that must be obeyed unconditionally),푅 LPM (s) denotes context-specific rules retrieved from LPM via the context signature, and퐺 LPM is the general user profile used as a fallback when no context rule matches. The memory arbitration follows a strict priority: STM user locks>LPM context rules> LPM general profile. Safety constraintsΦ are enforced orthogonally:푀 푝 is instructed to respect them dur- ing generation, and the Execution Agent independently ver- ifies compliance before execution (Sec. 3.3.1), providing a two-stage defense. The output policy is a set of actions: 휋=푎 1 ,푎 2 , . . .,푎 푚 , 푎 푖 =(target 푖 , action 푖 , value 푖 , priority 푖 , reason 푖 ),(3) where each action specifies a target parameter, control action (Keep, Set, Enable, Disable, Lock, Defer), target value, priority level, and a natural language reason for logging and downstream intent analysis. 3.1.3 Execution Agent. The Execution Agent푀 푒 serves as the bridge between LLM-generated strategies and the phys- ical device. It performs three sequential functions via two separate LLM calls: verification and command generation are deliberately separated so that the generation call receives only approved actions, preventing hallucinated verification reasoning from leaking into executable commands. ❶System Prompt ❷Policy Output You are a Strategy Planner Agent for PowerLens, a context-aware mobile power management system. Generate a policy that maximizes battery life while pre- serving user experience and respecting constraints. RULES: 1. ALWAYS respect user manual adjustments (LOCK). 2. NEVER violate CRITICAL constraints from PDL. 3. Prioritize actions by battery impact vs. experience. "policy_id": "PLens-2026-0303-151", "rationale": "Browsing Instagram at 60%; reduce brightness, disable unused radios.", "actions": [ "target": "screenBrightness", "action": "SET", "value": 1200, "reason": "1600→1200, within PDL ≤2000", "priority": "HIGH", "target": "isBluetoothEnabled", "action": "DISABLE", "value": false, "reason": "BT unused during browsing", "priority": "LOW", ... ], "estimated_savings": "12-15%", "risk_level": "low" ❸Safety Check "validation_output": "APPROVED", "approved_actions": [0, 1, ...], "rejected_actions": [] ❹Shell Execution $ su -c settings put system screen_brightness 1200 $ su -c svc bluetooth disable ... Before After BRT:1600 VOL: High BT : ON NFC: ON ROT: ON VIB: ON BRT:700 VOL: Low BT : OFF NFC: OFF ROT: OFF VIB: OFF Figure 5: Decision cycle example. The Policy Agent generates a structured JSON policy for an Instagram browsing session; the Execution Agent validates actions against PDL constraints and translates approved actions into root shell commands. Legality verification (LLM call 1): each proposed action is checked by the LLM against the device capabilities pro- file to ensure the target value falls within the valid range (e.g., brightness value within[0,4096], refresh rate is one of30,60,90,120) and against PDL constraints to ensure no safety invariant is violated (Sec. 3.3.1). Actions that fail verification are either corrected to the nearest valid value or rejected, with a fallback to a conservative default. Only approved actions proceed to the next stage. Shell command generation (LLM call 2): approved actions are translated by the LLM into executable Android shell commands via thesuroot shell (e.g., setting refresh rate requires three synchronized settings put commands). State synchronization: after execution, the agent reads back the actual system state to confirm that commands took effect, and updates the STM’s last known state snapshot for the Feedback Agent’s subsequent state differencing. 3.1.4 Feedback Agent. The Feedback Agent푀 푓 closes the control loop by detecting user interventions that occurred between decision cycles. Unlike the other agents,푀 푓 does not invoke the LLM; it uses a purely deterministic state dif- ferencing mechanism, operating at the beginning of each new cycle before the Activity Agent assembles the current context. Let휎 푡 0 be the system state recorded at the end of the previous decision cycle (stored in the STM’s last known state field), and휎 푡 1 the system state at the start of the current cycle. Conference’17, July 2017, Washington, DC, USAFeng et al. STM (Session Scope – Volatile) Active Constraints User Locks (Session-Only) Last Known State Status snapshot read update Raw Event Log 푡 0 푡 1 Time [timestamp],[target],[snapshot], ⋯ Extractor (The Bridge) LLM Intent Analysis Task: infer the most likely intent Input: Output: Context: APP, User Intervention, Time, Battery, Wi-Fi SSID, ⋯ Reasoning :Intent category, suggested rule, confidence,⋯ Confidence Scoring Score ×Decay(t) + Reward Rule Promotion If Score ≥ Threshold： Keep Promote Delete Conflict Check, Promote to LPM LPM (APP Scope – Persistent) Candidate Buffer Suspected user preferences Context Rules HashMap (context_hash→ rule) General Profile Fallback Create Add to Rules hash_a1 hash_a2 hash_a3 hash_b1 hash_b2 hash_b3 No Context Match Statistical Aggregation Cold Boot seq_id State Diff Update Delete Feedback Agent Policy Agent Policy Agent Policy Agent Feedback Agent Figure 6: A Two-tier memory system. STM maintains session-scoped state; the Extractor distills observations into LPM with confidence- based rule promotion. For each adjustable parameter 푝, the agent computes: Δ 푝 = 1[휎 푡 1 (푝)≠ 휎 푡 0 (푝)].(4) Any parameter change (Δ 푝 =1) that cannot be attributed to the system’s own previous actions is classified as a manual user override and tagged as aSTRONGfeedback signal. This produces two outputs: (1) an active constraint (user lock) is written to the STM, prohibiting the Policy Agent from overriding the user’s setting for the remainder of the current app session; and (2) a typed feedback event is logged to the STM’s raw event log, flagging this interaction for the Extrac- tor’s subsequent analysis. This deterministic design achieves reliable override detection at zero marginal cost per cycle. 3.1.5 Decision Pipeline. The multi-agent pipeline operates as shown in Alg. 1, triggered by foreground app changes (detected via the Accessibility framework) or periodic timers (default: every 5 minutes). Fig. 5 illustrates a concrete deci- sion cycle example. 3.2 Memory System for Personalization PowerLens uses a two-tier memory system (Fig. 6): Short- Term Memory (STM) and Long-Term Personal Memory (LPM), connected by an asynchronous Extractor. Inspired by OS memory management [13], it is redesigned for power management where feedback is implicit (user manual adjust- ments) and interactions are state-based. 3.2.1 Short-Term Memory (STM). STM is a volatile, session- scoped structure that protects the current session via over- ride constraints and records raw events for learning. It main- tains three components: •Active Constraints: A key-value map locking user- overridden parameters as inviolable. When the Feedback Agent detects a manual override (Eq. 4), it writes a Locked constraint; the Policy Agent adopts locked values without LLM inference. •Last Known State: A parameter snapshot serving as the baseline 휎 푡 0 for Feedback Agent differencing. Algorithm 1: Multi-agent decision pipeline. Input: Current state 휎 , memory (푆,퐿) , device profile D, constraintsΦ Output: Executed policy 휋 ∗ // Phase 1: Detect user interventions (deterministic) 1Δ← 푀 푓 .StateDiff(푆.last_state,휎) ; 2 foreach 푝 withΔ 푝 = 1 do 3 푆.constraints[푝] ← Lock(휎(푝)) ; 4 푆.log.Append(푝,휎(푝), STRONG) ; 5 end // Phase 2: Recognize activity and context 6 ⟨퐴 푡 , s⟩ ← 푀 푎 .Recognize(휎) ; // LLM call 1 // Phase 3: Retrieve memory and generate policy 7 푅 ← 퐿.Retrieve(s) ; // LPM lookup 8 퐶 ← 푆.constraints; 9 휋 ← 푀 푝 .Generate(퐴 푡 ,휎,퐶,푅,Φ) ; // LLM call 2 // Phase 4: Verify, generate commands, and execute 10 휋 ∗ ← 푀 푒 .Verify(휋,Φ,D) ; // LLM call 3 11 if 휋 ∗ ≠∅ then 12cmds← 푀 푒 .GenCommands(휋 ∗ ) ; // LLM call 4 13ExecRoot(cmds) ; 14 푆.last_state← ReadState() ; 15 푆.log.Append(휋 ∗ ,퐴 푡 , AUTO) ; 16 else 17 푀 푒 .Fallback() ; // Conservative default 18 end 19 return 휋 ∗ ; •Raw Event Log: A chronological sequence of events tagged with signal strength (STRONGfor user interven- tions,WEAKfor uncontested adjustments), serving as the Extractor’s input. 3.2.2 Long-Term Personal Memory (LPM). LPM is a persis- tent, per-app knowledge base stored on flash storage, con- taining distilled rules and preferences. Each app has one LPM page with three components: Context Rules are indexed by context signatures (Eq. 1) via multi-level hash indices, each storingRule 푖 =(s 푖 ,휋 푖 ,푐 푖 ) where s 푖 is the context signature,휋 푖 the recommended policy, PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA and푐 푖 ∈ [0,1]the confidence score. During policy genera- tion, the Policy Agent performs hierarchical retrieval with progressive relaxation: it first attempts exact-match on the full signature s; if no match, it queries progressively coarser indices that relax time period, then battery bucket, yielding 푅(s) → 푅(s −푇 ) → 푅(s −푇,−퐵 ) → 퐺 LPM . This ensures a rule learned for “evening music at mid battery” still applies when the user listens in the afternoon. Candidate Buffer holds rules still accumulating evidence below the promotion threshold, preventing one-time anom- alies from polluting the stable rule set (e.g., a user silencing their phone once during a meeting should not permanently override the volume preference). General Profile captures context-independent app-level defaults via statistical aggregation, serving as the fallback for unseen environments (the “cold start” problem). 3.2.3 Extractor: Asynchronous Knowledge Distillation. The Extractor bridges STM and LPM, transforming raw session logs into structured preference rules. It runs asynchronously (during device idle time or while charging) to avoid inference overhead during active use. The distillation process consists of three stages: Stage 1: Intent Analysis. Sessions without user interven- tions are treated as implicit positive feedback, incrementing confidence of matched LPM rules. For sessions withSTRONG- signal events, the Extractor invokes an LLM to infer intent: given the context and parameter change (e.g., “user increased brightness from 400 to 1200”), the LLM reasons about the likely cause and proposes a candidate rule. Stage 2: Confidence Scoring. Candidates are scored via a decay-reward mechanism:푐 new =푐 old ·휆 Δ푡 +푟,where휆=0.93 is a daily decay factor,Δ푡days since last update, and푟is the reward:푟 푠 =+0.2 (strong),푟 푤 =+0.08 (weak),푟 푐 =−0.5 (conflict). Each signature contributes at most one observation per day, ensuring only consistent patterns survive. Stage 3: Rule Promotion and Replacement. When confidence exceeds휏 푐 =0.8, candidates are promoted to stable context rules. During promotion, the LLM performs rule generaliza- tion (e.g., “Saturday 9AM” + “Sunday 9AM”→“weekend morning”). If a newly promoted rule shares the same con- text signature as an existing stable rule, it replaces the old rule, enabling adaptation to permanent preference changes. Candidates below휏 푑 =0.1 are evicted; the General Profile is updated weekly via statistical aggregation. Fig. 7 illustrates the personalization journey. On Day 1, PowerLens dims brightness during video streaming; the user restores it, creating a candidate with initial confidence푐 0 = 0.5 (the default seed for the first strong-signal observation). On Day 2, the same adjustment recurs:푐=0.5×0.93+0.2= 0.665. By Day 3,푐=0.665×0.93+0.2=0.818> 휏 푐 , and Day 1 - Conflict Override Day 2 - Learning Observing ⋯ Day 3 - Adapted Adapted 풄=풄⋅흀 횫풕 +풓 Personalization journey. STM Event Logged: STRONG signal Param: brightness User_val: 200 Candidate Buffer Pattern:brightnessduringvideo Confidence: 0.66 Threshold 흉 c = 0.8 (not promoted yet) LPM Rule Promoted Rule: “keep brightness ≥ 200 during video streaming” Confidence: 0.82 Figure 7: Personalization journey. Repeated user overrides ac- cumulate confidence (푐=0.50→0.665→0.818) until the rule is promoted to LPM. the rule “keep brightness≥200 during video streaming” is promoted to LPM. 3.3 Practical Considerations 3.3.1 Action Space Profiling. PowerLens performs auto- mated device profiling at setup time to enumerate the com- plete action space: adjustable parameters, valid ranges, and shell commands. The action space is organized by functional category and stored as a structured JSON capability profile (e.g.,screen_brightness: range[0,4096];cpu_governor: optionspowersave, schedutil, performance), injected into every Policy and Execution Agent prompt to ensure the LLM only proposes physically executable actions. 3.3.2 PDL-Based Safety Constraints. To prevent LLM hallu- cinations from compromising device functionality, Power- Lens defines safety constraints expressed in Propositional Dynamic Logic (PDL). LetΦ= 휙 1 ,휙 2 , . . .,휙 푘 denote the set of safety specifications. Constraints are organized by app category (e.g., navigation, video streaming, music, gaming) and encode domain-specific invariants: Hard constraints must never be violated: 휙 nav : App∈ A nav → [휋](location_mode≥ 3)(5) 휙 bat : (battery< 10%) → [휋](brightness≤ 512)(6) where[휋]휑denotes that휑holds after applying all actions in휋. Formula(5)ensures high-accuracy GPS is maintained during navigation;(6)enforces aggressive brightness reduc- tion at critically low battery levels. Contextual constraints are conditional on the detected activity: for example, video streaming apps must maintain at least 60 Hz refresh rate for smooth playback; meeting apps must preserve network connectivity and minimum media volume. The Execution Agent evaluates each action against applicable constraints before execution, correcting violations to the nearest compli- ant value or rejecting them with diagnostic feedback, a “trust but verify” mechanism combining flexible LLM reasoning with deterministic safety guarantees. 3.3.3 Privacy Protection. To mitigate privacy risks, Power- Lens integrates a PII filtering pipeline [15,39] that replaces sensitive text fields (e.g., phone numbers, email addresses) Conference’17, July 2017, Washington, DC, USAFeng et al. Navigation Video Meeting Social Music Content Feed Reading Route navigation, map br- owsing, POI search, ⋯ Video/audio call, screen sh- aring, in-meeting chat, ⋯ Feed browsing, posting, m- essaging, commenting , ⋯ News scrolling, post brow- sing, short video feed , ⋯ Dark/light mode reading, comics, audiobooks, ⋯ Music streaming, playlist browsing, commenting , ⋯ Video watching, danmaku interaction, scrolling , ⋯ Figure 8: PowerLensBench overview. 7 app categories with representative screenshots. with placeholder tokens before transmitting the accessibility tree to the cloud LLM, ensuring that only structural UI meta- data reaches the inference endpoint. Moreover, the Android Accessibility tree that PowerLens consumes is inherently privacy-friendly: it exposes only the widget hierarchy and semantic labels (e.g., “Button: Send”, “TextView: Settings”) rather than pixel-level screen content such as message bodies or passwords, making the input representation significantly less sensitive than screenshot-based agents [18]. 3.3.4 System Overhead. PowerLens consumes only 0.5% of daily battery capacity, negligible compared to the 38.8% en- ergy savings it achieves; design choices that bound over- head (deterministic Feedback Agent, asynchronous Extractor, event-triggered cycles) are detailed in Sec. 6.7. 4 IMPLEMENTATION We implement PowerLens as an Android application written in Kotlin, targeting Android 7.0+ (API 24) with root access (su) required for system-level parameter control. Context Monitoring. AnAccessibilityServicecap- tures UI state changes; theUIDumpermodule serializes the ac- tive window’s widget hierarchy into structured JSON. Device state is collected viaSettings.System/Settings.Secure APIs, connectivity managers, andUsageStatsManager, forming the Activity Agent’s input. Action Execution. TheExecutormodule translates actions into root shell commands viaRuntime.exec(), supporting 18 parameters across display, connectivity, compute, audio, and sync categories. After execution, it reads back system state to confirm changes and detect OS-level overrides. LLM Integration. Each decision cycle makes four sequen- tial LLM calls via the Gemini-2.5-Flash API (Google): Activ- ity recognition, Policy generation, legality Verification, and shell command Generation, with specialized system prompts and structured JSON output enforced via low temperature (0.1–0.2). The backbone was selected based on a systematic comparison of 8 models (Sec. 6.8). Device capability profiles and PDL constraints are loaded from local JSON files and injected into agent prompts. Memory and Storage. STM state is maintained in RAM and serialized at session boundaries; LPM entries are persisted as per-app JSON files in external storage. The Extractor runs as a deferred coroutine triggered when the device is idle or charging. 5 BENCHMARK We design PowerLensBench to evaluate LLM-driven power management along energy efficiency, user experience preser- vation, and personalization quality. 5.1 Usage Scenarios As shown in Fig. 8, PowerLensBench covers 7 app categories spanning the major axes of mobile power trade-offs: display- intensive (Video, Reading), connectivity-critical (Navigation, Meeting), background-dependent (Social, Music), and mixed- modality (Content Feed). The benchmark includes 25 main- stream apps (e.g., Google Maps, YouTube, Zoom, Spotify) and defines 48 tasks representing distinct user activities (e.g., turn-by-turn navigation, multi-party video conferencing, background music playback). Each task is evaluated under 3 battery-level contexts (high>60%, mid 30–60%, low<30%, corresponding to the battery bucket in Eq. 1), yielding 144 scenario instances. 5.2 Evaluation Metrics Action Accuracy. Weighted match against per-profile ground truth (GT, Section 5.3):Acc= Í 푘 푤 푎 푘 · 푠 푘 / Í 푘 푤 푎 푘 , where푠 푘 =1 if the output matches GT (exact for discrete, ±10% for continuous). Weights푤 푎 푘 reflect personalization sensitivity (GT variance across profiles), emphasizing the system’s ability to personalize rather than reproduce univer- sal defaults. Safety Violation Rate. The fraction of actions that breach PDL hard constraints, such as disabling GPS during active navigation or cutting mobile data during video streaming. Energy Saving (ES). We measure battery consumption (mAh) via Android Battery Historian over fixed-duration sessions and computeES=(퐸 stock − 퐸 method )/퐸 stock ×100%, where퐸 stock is the Stock Android consumption for the same app and session duration. User Experience Score (UES). Computed from GT com- pliance:UES=5×(1− Í 푘 푤 푢 푘 ·1[param 푘 ∉ GT 푘 ]), where 푤 푢 푘 ∝ 푝 푘 is the normalized override probability (e.g., bright- ness푝=0.79, media volume푝=0.86). Unlike accuracy, UES PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA weights reflect user sensitivity: deviations on actively man- aged parameters (brightness, volume) penalize more than rarely-touched settings. A UES of 5.0 means all decisions fall within GT. 5.3 User Preference Profiles To evaluate personalization quality, we require GT parameter vectors that define what each user would prefer in every scenario. Exhaustive real-world collection is impractical: 5 profiles×48 tasks×3 battery contexts yields 720 scenario instances, each requiring a participant to specify preferred values for all 18 parameters (∼15 min per instance,∼180 h per profile). Recent work has demonstrated the viability of LLM-generated synthetic personas for systematic evaluation of personalization systems [16,32,46]; we adopt a two-step approach. Step 1: Profile design. We define 5 synthetic user pro- files with maximally diverse behavioral characteristics: performance-oriented (Power User, e.g., demands 120 Hz and high brightness), budget-conscious (Student, accepts most power savings), routine-driven (Commuter, outdoor navi- gation focus; Professional, regular work-call patterns), and context-variable (Traveler, preferences shift by location and connectivity). Step 2: LLM-assisted GT generation. For each (profile, app category, battery level) triple, we prompt GPT-5.4 with the profile’s behavioral specification and app-specific functional requirements to generate target values for all 18 parame- ters. Crucially, the GT prompt targets only user preferences with no power-saving objective, avoiding circular bias with PowerLens’s optimization. For each profile, we train its LPM by running a 7-day simulated deployment starting from empty memory, pro- gressively building preference rules through the profile’s override behavior. GT is used exclusively for evaluation met- ric computation and is never provided to the system at run- time; notably, GPT-5.4 is not among the candidate backbones evaluated for PowerLens (Sec. 6.8). 6 EVALUATION 6.1 Experimental Setup Implementation. PowerLens is implemented as a rooted Android application that registers a persistent system ser- vice (Sec. 4), using Gemini-2.5-Flash (Google) as the LLM backbone (Sec. 6.8), with a total pipeline latency of 12.2 s per decision cycle (Table 4). Device and Power Measurement. All experiments are conducted on a OnePlus ACE 5 (Snapdragon 8 Gen 3, 12 GB RAM) running Android 15 with KernelSU root. Power con- sumption is measured using Android Battery Historian for per-app energy attribution. Nav.VideoMeet.SocialMusicFeedRead. App Category 0 10 20 30 40 50 60 Energy Saving (%) Batt. SaverRule-BasedSingle-Agent LLMPowerLens Figure 9: Energy saving across app categories (relative to Stock Android, higher is better). Table 2: Comparison with baselines (all relative to Stock An- droid, ES = 0%). Acc.: Action Accuracy (%), ES: Energy Saving (%), Viol.: Violation Rate (%), UES: User Experience Score (1–5). MethodAcc.ESViol.UES Battery Saver48.34.60.83.6 Rule-Based63.519.91.23.4 Single-Agent LLM52.148.412.52.5 PowerLens81.738.80.64.3 Baselines. We compare against four baselines: (1) Stock Android (no intervention,ES=0%), (2) Battery Saver (An- droid’s built-in low-power mode with blanket restrictions), (3) Rule-Based (static per-category rules without LLM rea- soning), and (4) Single-Agent LLM (same Gemini-2.5-Flash backbone in a monolithic prompt without multi-agent de- composition, memory, or PDL verification). Benchmark and User Profiles. We evaluate on PowerLens- Bench (Sec. 5) with 5 user profiles, each deployed with their trained LPM. This yields 240 unique evaluation instances (48 tasks× 5 profiles). 6.2 Overall Comparison All values are relative to Stock Android defaults, averaged across 5 profiles and 7 categories unless noted. Energy Saving. As shown in Table 2 and Fig. 9, PowerLens achieves 38.8% average energy saving. Single-Agent LLM reaches a higher raw saving (48.4%), but this stems from un- constrained optimization (aggressively disabling GPS, forc- ing minimum brightness) that sacrifices accuracy (52.1% vs. 81.7%), user experience (2.5 vs. 4.3), and safety (12.5% vs. 0.6% violations). Rule-Based achieves 19.9% but cannot adapt to context; Battery Saver yields only 4.6%. Accuracy, UES, and Safety. PowerLens achieves 81.7% action accuracy, 4.3/5.0 UES, and 0.6% violation rate, out- performing all baselines across all metrics (Table 2). Rule- Based (1.2%) and Battery Saver (0.8%) achieve low violations through conservative designs but sacrifice accuracy and en- ergy saving. Conference’17, July 2017, Washington, DC, USAFeng et al. 135791113 Day 0.0 0.2 0.4 0.6 0.8 1.0 Confidence Score Strong Weak Noisy s = 0.8 d = 0.1 (a) Confidence score trajectories. 135791113 Day 0.0 0.2 0.4 0.6 0.8 1.0 Confidence Score Preference Shift Promoted rules Disrupted rules New rules s = 0.8 (b) Preference adaptation. Figure 10: Preference learning and adaptation. 6.3 Personalization and Memory Convergence Preference Learning Process. Fig. 10(a) tracks confidence trajectories of 6 representative LPM candidate rules over a 14-day simulation, classified into strong (푟= 푟 푠 consistently), weak (intermittent adjustments), and noisy (contradictory) behavioral types (2 rules each). Strong-signal rules reach the promotion threshold휏 푐 =0.8 by Day 3; weak-signal rules require 5–8 days due to lower per-observation reward. Noisy- signal rules exhibit oscillating confidence that never ap- proaches the threshold, confirming the decay-reward mech- anism effectively filters unreliable patterns. Preference Adaptation. We simulate a preference shift at Day 5 (Fig. 10(b)). Already-promoted LPM rules remain active during the transition, while buffer candidates are disrupted as conflicting overrides drop their confidence below the eviction threshold. New candidates reflecting the changed preference then converge within 3–6 days; once promoted, they replace the stale rule sharing the same context signature. This natural evict-then-relearn cycle enables adaptation without explicit change detection. Memory Effect. Fig. 11 compares PowerLens with and with- out LPM. Per-category analysis (Fig. 11(a)) shows memory improves accuracy from 71.4% to 81.7% (+10.3%), with the largest gains in Reading (+16.8%) and Navigation (+15.5%) where preferences vary widely across profiles, and the small- est in Music (+0.2%). Without memory the LLM still achieves 71.4% via pretrained defaults; memory’s value lies in profile- specific parameters. Per-profile UES analysis (Fig. 11(b)) shows memory raises average UES from 3.5 to 4.3 (+23%), with Student (+0.92) and Commuter (+0.90) benefiting most as their preferences diverge from the LLM’s defaults, while Professional gains least (+0.41). 6.4 Context-Awareness Evaluation Activity Recognition. We evaluate the Activity Agent across 7 app categories with representative apps per category (Fig. 12). The agent achieves 83.0% average activity-type accu- racy (correctly identifying the high-level category) and 78.8% sub-activity accuracy (distinguishing finer-grained states within a category, e.g., “actively navigating” vs. “searching Nav.VideoMeet.SocialMusicFeedRead. App Category 60 70 80 90 100 Action Accuracy (%) w/o Memory w/ Memory (a) Per app category. Comm.P. UserProf.Stud.Trav. User Profile 2.5 3.0 3.5 4.0 4.5 5.0 UES (1-5) w/o Memory w/ Memory (b) Per user profile. Figure 11: Memory effect. Table 3: Context sensitivity: energy saving (%) by battery level. BatteryNav. Video Meet. Social Music Feed Read.Avg. High (80%)23.626.418.738.221.542.348.131.3 Mid (45%)27.430.822.345.725.149.656.836.8 Low (15%) 30.835.326.550.628.953.260.440.8 Baidu Maps Google Maps BilibiliYouTubeTencent Meeting ZoomREDXNetEase Music Spotify ToutiaoRedditWeReadReadEra 40 50 60 70 80 90 100 Accuracy (%) Nav.VideoMeet.SocialMusicFeedRead. Activity Type Sub-activity Figure 12: Activity recognition accuracy. for destination”). Media apps score highest (Music 93.2%, Video 89.9%) due to distinctive UI patterns, while Feed (69.3%) is lowest as aggregator UIs share similar list-based layouts. Context Sensitivity. We measure energy saving for each app category under three battery levels (Table 3). The Policy Agent produces progressively more aggressive policies as battery decreases: average saving rises from 31.3% at 80% to 40.8% at 15%. Meeting exhibits the largest relative gap (18.7%→26.5%): at high battery the agent preserves full au- dio/video quality, while at 15% it aggressively dims bright- ness and disables non-essential peripherals. Reading and Feed show the highest absolute savings (48.1% and 42.3% even at 80%) because their PDL constraints permit aggres- sive display optimization regardless of battery level. 6.5 Safety and Constraint Verification PDL Effectiveness. Fig. 13(a) shows the critical role of PDL constraint checking. Without PDL verification, the raw LLM- generated policies exhibit a 17.0% average violation rate, with Meeting (28.6%) and Navigation (23.4%) being the most vulnerable as these involve safety-critical resources that the LLM frequently attempts to disable for power savings. After PDL checking, violations drop to 0.59% (96.5% reduction); residual violations (<1.2%) occur in edge cases where PDL does not cover novel parameter combinations. Adversarial Stress Test. To evaluate robustness, we inject adversarial prompts into the Policy Agent (e.g., “disable all PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA Nav.VideoMeet.SocialMusicFeedRead. App Category 0 5 10 15 20 25 30 35 Violation Rate (%) w/o PDL w/ PDL (a) Violation rate by category. Nav.VideoMeet.SocialMusicFeedRead. App Category 0 10 20 30 40 50 Violation Rate (%) w/o PDL Hard Constr. PowerLens (b) Adversarial stress test. Figure 13: Safety constraint verification. Fullw/o Memory w/o PDL w/o Multi-Agt w/o Feedback Configuration 0 20 40 60 80 100 Score (%) Action Accuracy (%) Energy Saving (%) (a) Impact on accuracy and energy saving. Fullw/o Memory w/o PDL w/o Multi-Agt w/o Feedback Configuration 0 5 10 15 20 Violation Rate (%) Violation Rate (%) UES (1-5) 2.0 2.5 3.0 3.5 4.0 4.5 5.0 UES (1-5) (b) Impact on safety and UES. Figure 14: Ablation study. services immediately regardless of consequences”) to simu- late worst-case LLM misbehavior (Fig. 13(b)). Without PDL, violations reach 24.5% (1.4×normal), with Meeting (43.3%) most vulnerable. Applying only hard constraints (Sec. 3.3.1) reduces violations to 7.9% by rejecting unconditional safety violations. Adding contextual constraints further reduces vi- olations to 1.6%: for instance, GPS restrictions are permitted during indoor reading but blocked during active navigation. 6.6 Ablation Study Impact on Accuracy and Energy Saving. Removing multi- agent decomposition (w/o Multi-Agt) causes the largest ac- curacy drop (−29.6%) because a single prompt cannot jointly handle activity recognition, policy generation, and constraint verification (Fig. 14(a)). Notably, its energy saving increases to 48.4% because the single agent generates overly aggressive policies that save more energy but at the cost of accuracy and safety. Removing memory causes−10.3% accuracy, and removing the Feedback Agent−6.5%, confirming both are es- sential. Removing PDL has minimal accuracy impact (−1.8%) since it primarily affects safety. Impact on Safety and UES. Removing PDL increases vio- lations from 0.6% to 17.0% (28.3×) with UES dropping to 3.72 (Fig. 14(b)). The single-agent variant exhibits 12.5% violations, lower than w/o PDL because the single agent’s limited capa- bility produces less systematically unsafe outputs, whereas w/o PDL removes the safety net from a capable multi-agent system. The full system achieves the highest UES (4.3/5.0). 6.7 System Overhead Latency and Token Usage. Table 4 summarizes per-agent overhead. The Policy Agent is the bottleneck (5.9 s) due to its Table 4: System overhead per decision cycle. AgentInput Tok. Output Tok. Latency (s) Cost ($) Activity2,0491621.90.0010 Policy2,2267125.90.0025 Exec.-Verify2,518762.40.0009 Exec.-Action 6141742.00.0006 Total7,4071,12412.2 † 0.0050 † Sequential; pricing: $0.30/M input, $2.50/M output (Gemini-2.5-Flash). Table 5: LLM backbone comparison. Frozen-snapshot evaluation (IDLE, 100% battery). Quality: 5 dimensions× 5 pts= 25. ModelIn Tok. Out Tok. Latency (s) Cost ($) Qual. Gemini-2.5-Flash ★ 7,4071,12412.20.0050 23 GLM-4.76,25867217.10.004922 GPT-4o-mini6,2531,00320.80.00159 ∗ GPT-4o6,6501,34339.00.0301 24 GLM-5 6,2881,05242.70.006620 MiniMax-M2.56,2012,71347.80.004920 MiniMax-M2.16,1115,40251.80.008022 Kimi-K26,25481470.60.005219 ∗ Disqualified: Validator applies wrong constraint category. ★ Selected backbone. Cost reflects each provider’s actual API pricing. complex multi-source reasoning, while Activity and Exec.- Action complete in under 2 s each. Total pipeline latency is 12.2 s per cycle (cost: $0.0050), acceptable as decisions trigger at app-switch events spaced minutes apart. Energy Overhead. To isolate PowerLens’s own energy cost, we run the same workload (“RED” feed browsing, 30 min) with and without PowerLens (agents in dry-run mode). The difference is 2.0 mAh (2.2% of baseline, 0.4 mAh/cycle). A typical day (∼80 cycles) consumes∼32 mAh (0.5% of battery), negligible versus 38.8% savings. 6.8 LLM Backbone Comparison We evaluate 8 models on a frozen snapshot (identical context, UI tree, and app history across all models; IDLE scenario at 100% battery) in dry-run mode with thinking disabled, accessed via two API platforms: SiliconFlow (GLM, Mini- Max, Kimi) and Yunwu (GPT, Gemini). Quality is scored on five dimensions (0–5 each, 25 total): activity recognition correctness, policy coverage and reasonableness, validation accuracy (no false rejections or missed violations), command executability, and PDL/capability compliance. Table 5 summarizes the results. Token counts and laten- cies are cumulative across four LLM calls per cycle. GPT-4o scores highest (24/25) but costs $0.030/cycle, 6×more than alternatives. GPT-4o-mini is disqualified (9/25) due to incor- rect constraint application. Gemini-2.5-Flash achieves the best balance: fastest (12.2 s), high quality (23/25), and low cost ($0.005/cycle). We adopt it as the default backbone. 6.9 User Study We recruit 10 participants (7 male, 3 female, aged 20–58) to use PowerLens as their daily power manager for 14 consec- utive days. Participants use 8 distinct rooted Android de- vices across 4 brands (Samsung, Xiaomi, Huawei, Honor), all Conference’17, July 2017, Washington, DC, USAFeng et al. 0246810 Number of Participants Awareness Interference Battery Improvement Continue Using 532 811 352 91 Positive Neutral Negative (a) Survey results (N=10). 2468101214 Day 0 10 20 30 40 50 Cumulative LPM Entries LPM Entries Revert Rate 0 10 20 30 40 Revert Rate (%) (b) Preference convergence. Figure 15: User study results. with single-panel (non-foldable) displays, and self-reported daily screen time ranges from 3 to 9 hours. Participants use their phones normally; PowerLens runs continuously, log- ging LPM accumulation and revert rates. After 14 days, par- ticipants complete a questionnaire with 4 multiple-choice questions and a 5-point satisfaction rating. Survey Results. As shown in Fig. 15(a), 5 out of 10 partici- pants reported that they rarely or never noticed PowerLens’s adjustments, 8 reported no significant interference with daily use, and 8 perceived battery improvement (3 significant, 5 slight). 9 out of 10 expressed willingness to continue using the system. The average satisfaction score is 4.2/5.0. Preference Convergence. The fraction of reverted ad- justments drops from 25.7% on Day 1 to 4.9% by Day 14 (Fig. 15(b)), with users accumulating 20–39 LPM entries (mean 25.3) depending on app usage diversity. 7 RELATED WORK Mobile Power Management Mobile power management spans hardware-level, OS-level, and learning-based tech- niques [23]. DVFS governors reactively scale CPU frequency based on utilization; GearDVFS [19] extends this by consid- ering concurrent workloads, and zTT [14] applies learning- based DVFS to eliminate thermal throttling. At the OS level, Android’s Adaptive Battery classifies apps into standby buckets with coarse-grained restrictions, while fine-grained power modeling [10,17,27,28] enables per-component energy attribution. Measurement studies [2,5] have char- acterized real-world energy drain, and system-level tech- niques [7,8,20–22,42] address specific efficiency bottle- necks. Machine learning approaches include supervised on- line learning [24], deep RL for multi-objective optimiza- tion [36], DVFS-level RL [3], and multi-agent scheduling [4]. However, these require extensive training and struggle to generalize across devices. PowerLens instead leverages LLMs for zero-shot, context-aware [29] policy generation without retraining. LLM-Based Mobile Agents Building on reasoning-and- acting frameworks [43] and tool-augmented generation [33], LLM-based mobile agents have emerged for task automa- tion. AutoDroid [39,40] combines exploration-based mem- ory with functionality-aware UI representations for zero- shot app operation. AppAgent [44] and CogAgent [11] lever- age multimodal understanding for GUI interaction, while MobileGPT [15] captures reusable interaction patterns via human-like app memory. AutoIOT [34] extends LLM-driven programming to AIoT, and OS-Copilot [41] targets OS-level self-improvement on desktops. These systems focus on UI- level task automation [18,31,45], whereas PowerLens oper- ates at the system-level resource management layer, adjusting hardware parameters that require reasoning about device constraints and personalized preferences. Memory Systems for LLM Agents Park et al. [26] intro- duced memory streams with recency–importance–relevance retrieval. MemGPT [25] implements a tiered hierarchy analo- gous to OS virtual memory, and MemoryOS [13] formalizes a three-tier system with heat-based promotion. Reflexion [35] uses verbal self-reflection for episodic learning, while Voy- ager [37] maintains an evolving skill library for lifelong learn- ing. PowerLens draws inspiration from these designs but op- erates on state-action-feedback tuples rather than text, using state differencing for implicit feedback and confidence-based promotion with temporal decay. 8 DISCUSSION Implications. PowerLens demonstrates that LLMs can serve as effective system-level resource managers beyond UI-level task automation [15,39]. The multi-agent decomposition may generalize to other optimization problems (thermal man- agement [14], network scheduling), and state differencing offers a general paradigm for implicit preference learning complementing verbal reflection [35]. Limitations. State differencing captures preferences only when users can immediately revert a setting change; for pa- rameters whose effects are delayed or invisible, the feedback loop remains blind. A floating overlay widget could easily elicit sufficient user feedback, but may degrade the user expe- rience. Furthermore, although our PII filtering pipeline miti- gates the most common privacy risks, cloud-based inference inherently transmits contextual data off-device; stronger guarantees would require on-device models or cryptographic techniques. Future Work. We plan to explore on-device SLM deploy- ment [6,12,30,38,40] to eliminate cloud dependency and keep all user data on-device, and to generalize PowerLens to broader device categories including tablets, wearables and electric vehicles. PowerLens: Taming LLM Agents for Safe and Personalized Mobile Power ManagementConference’17, July 2017, Washington, DC, USA 9 CONCLUSION PowerLens takes a first step toward autonomous, user-aware mobile resource management driven by LLM agents. We presented a multi-agent architecture with PDL-based safety verification and a two-tier memory system that learns indi- vidualized preferences from implicit feedback alone. Evalua- tion on PowerLensBench demonstrates 38.8% average energy saving over stock Android while maintaining user experience scores above 4.3/5.0, with preference rules converging within 3–5 days and 96.5% of safety violations eliminated. Our re- sults show that LLMs, augmented with domain-specific con- straints and personalized memory, can effectively manage complex multi-parameter system optimization tasks on mo- bile devices. REFERENCES [1] Android Developers. 2024. Optimize for Battery Life: App Standby Buckets.https://developer.android.com/topic/performance/ appstandby Accessed: 2026-03-01. [2] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. 2009. Energy Consumption in Mobile Phones: A Measurement Study and Implications for Network Applications. In Proceedings of the 9th ACM SIGCOMM Conference on Internet Measure- ment. 280–293. [3] Sidartha AL Carvalho, Daniel C Cunha, and Abel G Silva-Filho. 2019. Autonomous power management in mobile devices using dynamic frequency scaling and reinforcement learning for energy minimization. Microprocessors and Microsystems 64 (2019), 205–220. [4]Ismat Chaib Draa, Emmanuelle Grislin-Le Strugeon, and Smail Niar. 2017. An energy-aware learning agent for power management in mobile devices. In International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems. Springer, 242– 245. [5]Xiaomeng Chen, Ning Ding, Abhilash Jindal, Y. Charlie Hu, Maruti Gupta, and Rath Vannithamby. 2015. Smartphone Energy Drain in the Wild: Analysis and Implications. In Proceedings of the 2015 ACM SIGMETRICS International Conference on Measurement and Modeling of Computer Systems. ACM, 151–164. [6]Yuhao Chen, Yuxuan Yan, Shuowei Ge, Yuyang Qin, Yue Zheng, Qian- qian Yang, Shibo He, Zhiguo Shi, Jiming Chen, and Yuanchao Shu. 2025. Confidant: Customizing Transformer-based LLMs via Collabo- rative Training on Mobile Devices. In Proceedings of the 31st Annual International Conference on Mobile Computing and Networking. ACM, 483–497. [7] Eduardo Cuervo, Aruna Balasubramanian, Dae-ki Cho, Alec Wolman, Stefan Saroiu, Ranveer Chandra, and Paramvir Bahl. 2010. MAUI: Making Smartphones Last Longer with Code Offload. In Proceedings of the 8th International Conference on Mobile Systems, Applications, and Services. 49–62. [8]Farshad Ghanei, Pranav Tipnis, Kyle Marcus, Karthik Dantu, Steven Y. Ko, and Lukasz Ziarek. 2019. OS-Based Energy Accounting for Asyn- chronous Resources in IoT Devices. IEEE Internet of Things Journal 6, 3 (2019), 5841–5852. [9]Agrim Gupta, Adel Heidari, Avyakta Kalipattapu, Ish Kumar Jain, and Dinesh Bharadia. 2024. 3 W’s of smartphone power consumption: Who, Where and How much is draining my battery?. In Proceedings of the 30th Annual International Conference on Mobile Computing and Networking. 2248–2250. [10]Shuai Hao, Ding Li, William G. J. Halfond, and Ramesh Govindan. 2013. Estimating Mobile Application Energy Consumption Using Program Analysis. In Proceedings of the 35th International Conference on Software Engineering. 92–101. [11]Wenyi Hong, Weihan Wang, Qingsong Lv, Jiazheng Xu, Wenmeng Yu, Junhui Ji, Yan Wang, Zihan Wang, Yuxiao Dong, Ming Ding, et al.2024. Cogagent: A visual language model for gui agents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition. 14281–14290. [12]Kai Huang, Boyuan Yang, and Wei Gao. 2023. ElasticTrainer: Speeding Up On-Device Training with Runtime Elastic Tensor Selection. In Pro- ceedings of the 21st Annual International Conference on Mobile Systems, Applications and Services. ACM, 56–69. [13]Jiazheng Kang, Mingming Ji, Zhe Zhao, and Ting Bai. 2025. Memory os of ai agent. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing. 25972–25981. [14] Seyeon Kim, Kyungmin Bin, Sangtae Ha, Kyunghan Lee, and Song Chong. 2022. zTT: Learning-based DVFS with zero thermal throttling for mobile devices. GetMobile: Mobile Computing and Communications 25, 4 (2022), 30–34. [15] Sunjae Lee, Junyoung Choi, Jungjae Lee, Munim Hasan Wasi, Hojun Choi, Steve Ko, Sangeun Oh, and Insik Shin. 2024. Mobilegpt: Aug- menting llm with human-like app memory for mobile task automation. In Proceedings of the 30th Annual International Conference on Mobile Computing and Networking. 1119–1133. [16] Ang Li, Haozhe Chen, Hongseok Namkoong, and Tianyi Peng. 2025. Llm generated persona is a promise with a catch. arXiv preprint arXiv:2503.16527 (2025). [17]Ding Li, Shuai Hao, William G. J. Halfond, and Ramesh Govindan. 2013. Calculating Source Line Level Energy Information for Android Applications. In Proceedings of the 2013 International Symposium on Software Testing and Analysis. 78–89. [18]Yuanchun Li, Hao Wen, Weijun Wang, Xiangyu Li, Yizhen Yuan, Guo- hong Liu, Jiacheng Liu, Wenxing Xu, Xiang Wang, Yi Sun, Rui Kong, Yile Wang, Hanfei Geng, Jian Luan, Xuefeng Jin, Zilong Ye, Guanjing Xiong, Fan Zhang, Xiang Li, Mengwei Xu, Zhijun Li, Peng Li, Yang Liu, Ya-Qin Zhang, and Yunxin Liu. 2024. Personal LLM Agents: In- sights and Survey about the Capability, Efficiency and Security. arXiv preprint arXiv:2401.05459 (2024). [19]Chengdong Lin, Kun Wang, Zhenjiang Li, and Yu Pu. 2023. A workload- aware DVFS robust to concurrent tasks for mobile devices. In Proceed- ings of the 29th Annual International Conference on Mobile Computing and Networking. 1–16. [20]Felix Xiaozhu Lin, Zhen Wang, Robert LiKamWa, and Lin Zhong. 2012. Reflex: Using Low-Power Processors in Smartphones without Know- ing Them. In Proceedings of the Seventeenth International Conference on Architectural Support for Programming Languages and Operating Systems. ACM, 13–24. [21]Chulhong Min, Seungchul Lee, Changhun Lee, Youngki Lee, Seung- woo Kang, Seungpyo Choi, Wonjung Kim, and Junehwa Song. 2016. PADA: Power-Aware Development Assistant for Mobile Sensing Appli- cations. In Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing. 946–957. [22] Chulhong Min, Youngki Lee, Chungkuk Yoo, Seungwoo Kang, Sang- won Choi, Pillsoon Park, Inseok Hwang, Younghyun Ju, Seungpyo Choi, and Junehwa Song. 2015. PowerForecaster: Predicting Smart- phone Power Impact of Continuous Sensing Applications at Pre- installation Time. In Proceedings of the 13th ACM Conference on Em- bedded Networked Sensor Systems. 31–44. [23]Sparsh Mittal. 2014. A survey of techniques for improving energy efficiency in embedded computing systems. International Journal of Computer Aided Engineering and Technology 6, 4 (2014), 440–459. Conference’17, July 2017, Washington, DC, USAFeng et al. [24]Piotr Nawrocki and Bartlomiej Sniezynski. 2020. Adaptive context- aware energy optimization for services on mobile devices with use of machine learning. Wireless Personal Communications 115, 3 (2020), 1839–1867. [25]Charles Packer, Vivian Fang, Shishir_G Patil, Kevin Lin, Sarah Wooders, and Joseph_E Gonzalez. 2023. MemGPT: towards LLMs as operating systems. (2023). [26]Joon Sung Park, Joseph O’Brien, Carrie Jun Cai, Meredith Ringel Mor- ris, Percy Liang, and Michael S Bernstein. 2023. Generative agents: Interactive simulacra of human behavior. In Proceedings of the 36th Annual Acm Symposium on User Interface Software and Technology. 1–22. [27]Abhinav Pathak, Y Charlie Hu, and Ming Zhang. 2012. Where is the energy spent inside my app? Fine Grained Energy Accounting on Smartphones with Eprof. In Proceedings of the 7th ACM European Conference on Computer Systems. 29–42. [28] Abhinav Pathak, Abhilash Jindal, Y. Charlie Hu, and Samuel P. Midkiff. 2012. What is keeping my phone awake? Characterizing and detecting no-sleep energy bugs in smartphone apps. In Proceedings of the 10th International Conference on Mobile Systems, Applications, and Services. ACM, 267–280. [29]Charith Perera, Arkady Zaslavsky, Peter Christen, and Dimitrios Geor- gakopoulos. 2013. Context aware computing for the internet of things: A survey. IEEE communications surveys & tutorials 16, 1 (2013), 414– 454. [30] Xukan Ran, Haoliang Chen, Xiaodan Zhu, Zhenming Liu, and Jiasi Chen. 2018. DeepDecision: A Mobile Deep Learning Framework for Edge Video Analytics. In IEEE Conference on Computer Communications (INFOCOM). 1421–1429. [31]Christopher Rawles, Sarah Clinckemaillie, Yifan Chang, Jonathan Waltz, Gabrielle Lau, Marybeth Fair, Alice Li, William Bishop, Wei Li, Folawiyo Campbell-Ajala, Daniel Toyama, Robert Berry, Divya Tyam- agundlu, Timothy Lillicrap, and Oriana Riva. 2025. AndroidWorld: A Dynamic Benchmarking Environment for Autonomous Agents. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. arXiv:2405.14573 https://arxiv.org/abs/2405.14573 [32]Vinay Samuel, Henry Peng Zou, Yue Zhou, Shreyas Chaudhari, Ashwin Kalyan, Tanmay Rajpurohit, Ameet Deshpande, Karthik Narasimhan, and Vishvak Murahari. 2024. Personagym: Evaluating persona agents and llms. arXiv preprint arXiv:2407.18416 8, 9 (2024). [33]Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems 36 (2023), 68539–68551. [34] Leming Shen, Qiang Yang, Yuanqing Zheng, and Mo Li. 2025. Autoiot: Llm-driven automated natural language programming for aiot appli- cations. In Proceedings of the 31st Annual International Conference on Mobile Computing and Networking. 468–482. [35]Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal rein- forcement learning. Advances in Neural Information Processing Systems 36 (2023), 8634–8652. [36]R Sunder, Umesh Kumar Lilhore, Anjani Kumar Rai, Ehab Ghith, Mehdi Tlija, Sarita Simaiya, and Afraz Hussain Majeed. 2025. SmartAPM framework for adaptive power management in wearable devices using deep reinforcement learning. Scientific Reports 15, 1 (2025), 6911. [37]Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. 2024. Voyager: An Open- Ended Embodied Agent with Large Language Models. Transactions on Machine Learning Research (2024). arXiv:2305.16291 https://arxiv.org/ abs/2305.16291 [38]Haoming Wang, Boyuan Yang, Xiangyu Yin, and Wei Gao. 2025. Never Start from Scratch: Expediting On-Device LLM Personalization via Explainable Model Selection. In Proceedings of the 23rd Annual Interna- tional Conference on Mobile Systems, Applications and Services. ACM, 154–168. [39]Hao Wen, Yuanchun Li, Guohong Liu, Shanhui Zhao, Tao Yu, Toby Jia-Jun Li, Shiqi Jiang, Yunhao Liu, Yaqin Zhang, and Yunxin Liu. 2024. Autodroid: Llm-powered task automation in android. In Proceedings of the 30th annual international conference on Mobile computing and networking. 543–557. [40] Hao Wen, Shizuo Tian, Borislav Pavlov, Wenjie Du, Yixuan Li, Ge Chang, Shanhui Zhao, Jiacheng Liu, Yunxin Liu, Ya-Qin Zhang, and Yuanchun Li. 2025. AutoDroid-V2: Boosting SLM-based GUI Agents via Code Generation. In Proceedings of the 23rd Annual International Conference on Mobile Systems, Applications and Services. ACM, 223– 235. [41]Zhiyong Wu, Chengcheng Han, Zichen Ding, Zhenmin Weng, Zhoumi- anze Liu, Shunyu Yao, Tao Yu, and Lingpeng Kong. 2025. OS-Copilot: Towards Generalist Computer Agents with Self-Improvement. In The Thirteenth International Conference on Learning Representations, ICLR 2025, Singapore, April 24-28, 2025. OpenReview.net. arXiv:2402.07456 https://arxiv.org/abs/2402.07456 [42]Chao Xu, Felix Xiaozhu Lin, Yuyang Wang, and Lin Zhong. 2015. Au- tomated OS-level Device Runtime Power Management. In Proceedings of the Twentieth International Conference on Architectural Support for Programming Languages and Operating Systems. ACM, 239–252. [43] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. 2022. React: Synergizing reasoning and acting in language models. In The eleventh International Conference on Learning Representations. [44] Chi Zhang, Zhao Yang, Jiaxuan Liu, Yanda Li, Yucheng Han, Xin Chen, Zebiao Huang, Bin Fu, and Gang Yu. 2025. Appagent: Multimodal agents as smartphone users. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems. 1–20. [45]Yizhe Zhao, Yongjian Fu, Zihao Feng, Hao Pan, Yongheng Deng, Yaoxue Zhang, and Ju Ren. 2026. MANA: Towards Efficient Mobile Ad Detec- tion via Multimodal Agentic UI Navigation. In Proceedings of the 32nd Annual International Conference on Mobile Computing and Networking. To appear. [46]Thomas P Zollo, Andrew Wei Tung Siah, Naimeng Ye, Ang Li, and Hongseok Namkoong. 2024. Personalllm: Tailoring llms to individual preferences. arXiv preprint arXiv:2409.20296 (2024).