The more AI can do, the easier it is for the phone to get distracted.
A phone gaming while running data in the background—once the scenario engineers least wanted to see, is now a norm that manufacturers deliberately design for long-term support. The Nubia NaviX Ultra, released on September 16 and equipped with the consumer version of the Doubao Phone Assistant, was officially defined as "the world's first AI agent phone," exactly nine months after the debut of the technical prototype Nubia M153 last December.
Ni Fei, President of ZTE's Terminal Business Unit, said something candid at the launch event: "This road is really hard. Several times, even our own team wasn't sure we could make it through. Commercialization means making a technology withstand users' hundreds or thousands of real uses every day."
Behind this statement lies a problem the phone industry hasn't truly encountered in the past two decades. When flagship phones compete on performance, there has always been a default premise: only one task is truly consuming computing power at any given moment. You don't edit photos while gaming, and you don't export 4K edits while scrolling videos.
Manufacturers compete on "single-task burst power"—whose chip scores higher, whose cooling can withstand peak power consumption—and that's the only account being kept. That premise is now broken. At the launch event, the manufacturer mentioned a design that isn't flashy but deserves a second thought: what the "AI Performance Engine" aims to do is let the Doubao Phone Assistant execute multi-step tasks in the background without competing for computing power with the foreground interface.
This sounds like standard system optimization rhetoric, but it points to a problem the phone industry has never truly faced: when an AI agent starts continuously operating apps on your behalf in the background, the phone's computing power ledger must, for the first time, keep two accounts at once—one for the foreground smoothness you can see, and one for the background execution power you can't see. These two accounts are inherently in conflict: whichever takes a bigger bite of computing power leaves less for the other.
Android's "power-saving philosophy" is the exact opposite of an agent's "continuous work"
Over the past decade, the core logic of Android's background optimization has been to "kill" background tasks to save power. From Doze power-saving mode to app standby buckets, Android's official design approach has always been: the quieter the background apps, the better. Unless the user is actively viewing an app, the system has the authority to limit its power consumption, restrict its wakeups, and constrain its location and network requests. This logic is reasonable for social app push notifications and music player background playback, because these background tasks are "lightweight and persistent."
Viewed within the framework of two accounts, the Android system of the past basically only needed to keep the foreground account—the background one was perpetually suppressed to the minimum, and the more aggressively it was suppressed, the better the power savings. But the background tasks of a GUI agent are not lightweight persistence; they are heavy, foreground-level operations that continuously read the screen, continuously make judgments, and continuously simulate clicks—just relocated to an invisible place for execution. The route taken by Nubia's previous generation M153: an industry review by OFweek previously mentioned a detail—relying on on-device visual recognition plus simulated clicks to "understand the interface before moving fingers" to operate third-party apps that haven't opened their APIs.
The plug-and-play nature of this route is a genuine advantage: regardless of whether the other app opens its interface, as long as the screen can be understood, it can be operated—naturally broader in coverage than standard interfaces. But from an engineering logic perspective, the cost is equally real: every step requires redoing screen content recognition and decision inference, rather than getting results directly from a single API call. Computing power consumption is continuous and fluctuates with the complexity of the app interface.
This account isn't settled in one go, either. If an app undergoes a redesign, recognition difficulty may suddenly increase. Manufacturers can't achieve permanent solution through a one-time adaptation—they must continuously invest computing power and engineering resources to chase changes in the app ecosystem.
In other words, the computing power bill for the simulated-click route is a long-term liability that requires constant additional investment in the background. This is why "scheduling" is a life-or-death matter for this route, not a bonus point. Here's a number that can serve as a reference, but first let's be clear about how imprecise it is: a testing column from a digital media outlet cited a set of data claiming that phone agents on the market achieved only a 20% overall success rate across 70 task tests, with 39% of tasks interrupted after starting. The testing methodology and sample size were not disclosed in detail and cannot be used as an industry conclusion.
But it at least suggests a direction: a task interrupted midway may not be because the model misunderstood the intent, but because the execution chain was broken by system resource limitations.
Putting this back into the framework of two accounts, this means the background account wasn't balanced. No matter how smart the model is, if during execution the CPU is judged by the system as low-priority background, computing power is throttled, or the process is frozen, the task still won't complete.
Hardware provides the space, but the scheduling algorithm is the real answer
The hardware foundation this time is the Snapdragon 8 Elite Gen 5, built on a 3nm process. Qualcomm's official figures state that Hexagon NPU performance has improved 37% compared to the previous generation, supporting on-device large model decoding speeds of 220 tokens/second. There's also a less prominent but relevant design in the chip: the sensor hub's power consumption is reduced by 33% compared to the previous generation. Officially positioned as the "agent's entry point," it handles lightweight persistent tasks like voice wake-up and environmental sensing, completing basic perception without waking the main SoC.
These specifications address the "ceiling" of computing power—a faster, more power-efficient NPU can theoretically feed both foreground rendering and background inference simultaneously, equivalent to enlarging the total credit line of the ledger. But a larger credit line doesn't mean both accounts can be balanced at once. What truly determines user experience is how the operating system allocates this computing power in real time between the foreground interface and background agent tasks.
Nubia's public statement this time is that when both foreground and background have tasks, computing power prioritizes ensuring foreground smooth operation while allocating a portion to background AI tasks for "steady trickle" execution.
This allocation logic currently remains only in the manufacturer's own description. At what concurrent load level will foreground frame drops occur? To what degree are background tasks throttled? After several hours of continuous operation, will thermal control policies sacrifice background task execution speed? These metrics are all still blank—no third party has published measured data. This is not to deny the value of this work. On the contrary, system-level resource arbitration is, from an engineering perspective, genuinely hard—far harder than stacking a bigger battery or swapping in a brighter screen.
It's just that between "a direction worth recognizing" and "a verified effect," there's still the step of third-party testing.
How others solve this problem: the same question, different workarounds
This "foreground-background concurrency" problem has several different solutions in the industry, which can help us see where Nubia's route stands and see the different solutions each company has offered for the two accounts. Honor's approach focuses on opening up ecosystem protocols. This year it integrated the A2A protocol, allowing the phone assistant to send task "work orders" directly to agents in apps like WeChat, which execute them and return results.
This way, the phone side doesn't need to rely on simulated clicks to operate others' interfaces, and the background account barely needs to be kept by the phone itself. This path has been mentioned in reports by multiple tech media outlets.
OPPO's Agent Matrix and vivo's continuous investment in on-device lightweight solutions also follow the direction of converting tasks into structured calls as much as possible and reducing the burden of visual recognition. Essentially, they're all trying to keep the background account lighter rather than trying to make the total computing power larger. Comparing these routes together yields a judgment: solutions relying on standard interface calls turn the background account into a one-time, predictable small expense;
solutions relying on visual recognition plus simulated operations make the background account a continuous, long-term expense that keeps expanding with changes in the app ecosystem.
Nubia chose the latter—coverage in exchange for bill uncertainty. This is why dynamic allocation mechanisms like the "AI Performance Engine" are not icing on the cake for this route, but a necessity without which it goes bankrupt.
This problem will become a required course for the entire industry. Industry data can help ground this judgment in reality rather than resting on technical intuition alone. CITIC Securities analogized the Doubao-Nubia partnership to a "Huawei + Seres" style model, where large model companies provide capabilities and ecosystem support to hardware manufacturers. This shows that even capital markets have made "whether AI capabilities can run stably" a key variable in valuing such partnerships, not just a decorative promotional point.
Everbright Securities takes a more direct angle, arguing that against the backdrop of expected global smartphone shipment declines, AI capability is already the only differentiating card manufacturers can play. This means that poor computing power scheduling isn't just an experience flaw—it directly affects whether this differentiating card can be played at all.
Market size figures point in the same direction: IDC predicts that China's new-generation AI phone shipments will reach 147 million units in 2026, accounting for 53% of the overall market. Counterpoint Research's global figure states that phones with generative AI capabilities will account for 45% of 2026 shipments. These two figures use different scopes—one for China, one for global—but together they indicate that in the next year or two, more than half the phones on the market will face the same two-account problem. Whoever balances the accounts first will be first to create an experience gap.
Battery, thermal control, experience: there's still no standard answer for balancing these three
Back to the original question: how well computing power scheduling is done—there isn't much that can be verified right now. Manufacturers have announced principles and directions, not data from third-party stress tests. An honest judgment is that the direction itself is correct and necessary, but "to what degree it's been achieved" can currently only be taken from the manufacturer's own account.
What will truly test it should be independent media or review institutions conducting measured tests in long-duration, multi-task concurrent scenarios—for example, simultaneously running navigation, executing a complex cross-app task in the background, and scrolling videos normally on screen. After two continuous hours, how much does the phone heat up? How many frames are dropped? Is the background task completion time stable? No public data from such tests has been seen yet.
Final thoughts
Android has spent the past decade exhausting its efforts teaching developers that "the quieter the background, the better." Now agents are forcing the system to learn the opposite: "the background also needs to work properly." The conflict between these two design philosophies may more profoundly determine how far the AI phone category can ultimately go than parameter wars over screen size or camera megapixels. Manufacturers being willing to put this problem on the table is already progress, but the next question to ask is: when all phones start competing on "background scheduling," should this be solved uniformly at the system level, or should each company continue writing its own private algorithms?
If it's the latter, what about the small and medium-sized manufacturers that lack the ability to rewrite scheduling logic themselves?