Doubao’s Second-Gen Mobile Agent: A New Architecture for App Permissions and Privacy
On December 1, 2025, the nubia M153, featuring a preview version of Doubao's mobile assistant technology, was released in limited quantities as an engineering sample for RMB 3,499 and sold out quickly. In official demonstrations, it could search for products based on a recommendation post, compare prices across platforms, organize travel itineraries, mark restaurants on a map, and then continue processing subsequent tasks based on the schedule.
For many, it was the first time they saw visually that AI in smartphones is no longer just answering questions but can truly "take action." It reads text and buttons on the screen, plans steps on its own, and then completes tasks across different apps by clicking, swiping, and typing.
But the novelty quickly hit reality. Some users encountered login restrictions, risk interceptions, or anti-cheat flags on WeChat, Alipay, and in games. The outside world summarized this as a round of "industry-wide bans." Public information cannot prove that different platforms acted in unison, but the outcome was clear: the most attractive cross-App operation of its generation ran up against the security and permission boundaries of third-party platforms.
Less than a year later, the Doubao mobile assistant has entered the consumer preview phase and will first be integrated into the nubia NaviX Ultra. The official plan also includes a simultaneous OTA push for the first-generation Doubao phone M153.
So, the real question this time is: what specific changes has it made in response to its previous setbacks?
Restructuring the AI execution pipeline at the foundational framework level
The first generation of Doubao phones primarily relied on GUI Agents to complete tasks.
After the user makes a request, the model interprets the intent, the vision model reads the screen, and then it generates click, swipe, and input commands. Its advantage is generality: even if an app has not been specifically adapted, as long as the AI can recognize the page, it can attempt to operate.
This is also where the generation makes its most significant impact. It does not need to wait for all apps to open their interfaces; instead, it uses a single visual solution to cover as many scenarios as possible.
This raises a critical issue: GUI Agents rely heavily on screen-reading capabilities, requiring elevated system permissions to read and operate across different applications. To third-party apps, this behavior—continuous screen reading, automated input, and batch clicking—closely resembles scripts, cheats, or group-control tools.
Thus, the "ban" faced by the first generation stems from both ecosystem interests and inherent issues within its execution architecture.
On the second-generation Doubao phone, GUI Agent is not abandoned. The official page still marks "phone operation" as Beta and explicitly states that this feature will complete tasks through "simulated clicks and tool invocation." The real change is that GUI no longer handles all the work.
The official application development integration documentation includes an image outlining the new system architecture for the second-generation Doubao phone.
Simplifying this new architecture reveals three execution paths:
The first is system tool invocation.
Capabilities such as phone, calendar, alarm clock, and voice recorder can directly receive structured instructions. For example, when creating multiple alarms in batch, the AI does not need to repeatedly tap within the clock interface; instead, it passes the time, date, and recurrence rules to the system for processing.
This addresses issues with GUI-based steps, including high latency, slow execution, and vulnerability to interface changes. As long as the system provides the capability, the model no longer needs to mimic human operation processes.
The second path is standard service interfaces.
The consumer preview version’s official website currently specifies that Doubao has integrated services such as CaoCao Mobility and mapping applications, handling lifestyle service requests through lightweight, standardized interfaces. Applications determine which data and capabilities to expose, while Doubao invokes them within agreed-upon boundaries.
This path directly addresses third-party app integration challenges. The platform knows the source of the request and can verify whether the invocation complies with its business rules. Tasks no longer rely on full-page interactions, so updates or redesigns by apps do not directly disrupt the execution flow.
For services that have already completed API integration, the past conflict—where AI simulated human clicks in the foreground while apps intercepted it as a script in the background—can be largely eliminated at the execution level.
The third approach remains the GUI Agent.
In reality, it is impossible to require all applications to undergo interface modifications simultaneously. To cover long-tail scenarios lacking system tools or open service APIs, Doubao still needs to understand graphical interfaces and simulate operations.
However, this time SAEP has been added around the GUI Agent, which is the 'Screen Automation Execution Protocol' officially released by Doubao.
According to official documentation, third-party applications can declare the operational boundaries for agents across three levels: App, Activity pages, and Intent business intents.
An application can allow AI to browse standard pages while prohibiting screenshots and input on login pages; it can enable product search but prevent payment confirmation; and it can require users to take over personally when publishing content, deleting files, or modifying account information.
Before executing an operation, the system synthesizes the agent's identity, device trust status, system security baseline, application declaration policies, and user authorization for the current task, then returns results such as allowing execution, direct blocking, or recalling the user.
The most critical change is that the system no longer relies solely on the model’s own judgment; instead, it establishes strict rules upfront.
SAEP places constraints at system entry points such as screenshots, accessibility reading, clicks, and input. If an application has already blocked an operation, the Agent cannot bypass it through an alternative channel. Similarly, restrictions set by the system security baseline cannot be lowered by either the model or the application. The Agent’s identity, target page, operational intent, triggered policies, and execution results are all recorded.
Above the execution layer, task orchestration has been added. After a user states their need, the system breaks down the task and determines whether each step should call system tools, third-party services, or a GUI Agent. When tasks have sequential dependencies, they enter a queue; when information is insufficient, the system asks the user for clarification; and when sensitive operations are involved, the process pauses and returns control to the user.
Therefore, the new architecture is no longer simply "large model plus simulated clicks," but a more complete pipeline:
"Intent Understanding — Task Orchestration — Path Selection — Permission Adjudication — Execution and Audit."
However, has this architecture truly solved the "App blocking issue"? The answer depends on the situation.
For applications that have opened standard interfaces, conflicts have been significantly mitigated at the execution mechanism level. For applications willing to integrate with SAEP but still requiring GUI operations, previously ambiguous authorization relationships can now become explicit rules. For platforms that neither open interfaces nor accept Agent operations, the original problems remain.
Currently, the official statement indicates that "mobile phone operation" support covers system apps, ZTE apps, ByteDance ecosystem apps, and some third-party apps that have already integrated. No complete list has been published, nor has it been announced that WeChat, Alipay, and other previously controversial apps are fully open.
So while NaviX Ultra has a workaround for restrictions on third-party apps, there is still a long way to go before they are fully lifted.
Doubao has answered the question of 'how to open the door': deeply integrated apps use interfaces, while those requiring GUI operations negotiate boundaries through SAEP. As for how many apps are willing to open up, that decision does not rest entirely with Doubao.
The Critical Privacy Issue
Another concern in the industry regarding the Doubao phone is its access to large amounts of personal information in order to understand and operate the screen.
According to the official white paper, the consumer preview version uses cloud-edge collaboration rather than keeping all data locally on the device.
OCR, text vectorization, named entity recognition, content recognition, and multimodal models are deployed on the device to process some highly sensitive data. The TEE (Trusted Execution Environment) and system file encryption protect the models, personal memories, and data generated during inference.
When complex tasks require cloud-based models, some data is still sent to the cloud. According to the white paper, these requests are transmitted with encryption, partial user and device identifiers are replaced with pseudonyms, and information that can be linked to specific individuals is desensitized before entering the model.
Regarding screen content, Doubao previously committed to a 'no storage, no training' principle for cloud processing. Global memory is prioritized for on-device processing; users can control the recording scope by app, time, and location, or disable the feature at any time, delete specific records, or clear all data.
These measures primarily address how data is collected, transmitted, stored, and deleted.
SAEP and high-sensitivity operation confirmation handle the other half of the issue: whether AI can take action based on the information it obtains. For payments, account authentication, and irreversible operations, users can be required to take over control. When invoking advanced capabilities while the screen is locked, fingerprint authentication via an AI key is required.
For standard chatbots, privacy concerns mainly focus on what the AI sees. For agents capable of operating a phone, one must also ask what it does after seeing.
This is why the security design in the consumer preview version warrants closer attention. Privacy is no longer just a data processing statement; it begins to enter the processes of task planning, permission checking, and action execution.
However, what can currently be confirmed remains the officially disclosed design. The white paper does not specify the exact retention periods for all data types, nor does it provide independent security test results for the consumer preview version in real-world environments. The architecture is in place, but actual effectiveness still requires verification.
A Different Path from Apple
From an industry perspective, Doubao and Apple are charting two distinct routes for AI-powered smartphones.
Apple’s Siri AI relies on App Intents and App Schemas as its core.
Developers first organize actions, content, and entities within their apps into structured formats that the system can recognize. A music app might expose a “play song” action, a calendar app could allow “create event,” and a travel app might convert flight details into retrievable entities.
Siri AI locates these capabilities through the system orchestrator, Spotlight indexing, and App Toolbox, then invokes them based on user intent.
Although Apple provides screen understanding and personal context, the primary entry point for third-party apps to execute tasks remains the structured capabilities proactively provided by developers. If an app does not expose specific actions, Siri AI generally cannot compensate by simulating clicks.
This approach features apps paving the way first, with AI then following predefined routes.
Doubao, by contrast, retains a secondary path.
When system tools or service interfaces are available, it employs structured calls; in their absence, GUI Agents can still attempt to complete tasks from application interfaces. SAEP adds identity management, rules, and auditing to this more flexible but harder-to-control path.
Apple’s route offers higher stability and deterministic permissions, though its capability scope depends on developer adaptation. Doubao can reach uninterface-optimized scenarios faster but incurs additional costs from UI changes, model misjudgments, platform risk controls, and permission conflicts.
At the model execution layer, both approaches are similar, combining on-device and cloud computing.
Apple uses Private Cloud Compute when device compute power is insufficient. Beyond stating that personal data is not retained after requests end, Apple provides select security-critical components, transparent logs, and research environments, allowing external researchers to verify whether the cloud system complies with public commitments.
Doubao employs TEE, device-to-cloud encryption, pseudonymization, confidential computing, and data cleanup after task completion. The current distinction lies in Doubao primarily publishing security whitepapers and access protocols, whereas Apple has established a more comprehensive external verification mechanism.
So, both approaches have moved from concept to product, but they remain at different stages of deployment and maturity.
What is still needed for the system to operate reliably over the long term?
The deep collaboration between nubia’s NaviX Ultra and Doubao raises a question: can it help build a durable technical moat?
First, GUI Agents are not exclusive to Doubao; system tools and service interfaces can be built by other vendors. SAEP proposes a more complete framework for declarations, adjudication, and auditing, but the protocol can be studied and referenced, and documentation alone does not naturally become a barrier.
What is truly difficult to replicate is integrating these modules into a stable, functioning system.
The model must understand user intent, decompose complex requests into tasks, select the appropriate GUI, system tool, or service interface for each step, and then apply safety policies to determine whether execution is permitted. If a task fails, the system must replan, explain the cause, and retain an auditable trail.
This requires not only model capabilities but also operating system modifications, hardware security environments, third-party service partnerships, and engineering experience derived from a large volume of real-world tasks.
Apple’s advantage lies in its simultaneous control over chips, the operating system, cloud security architecture, and developer frameworks, enabling App Intents to become a long-term standard across the entire ecosystem.
Doubao does not control the complete Android ecosystem; it must partner with smartphone manufacturers to access system-level layers and then drive various applications to integrate via service interfaces or SAEP. Its potential barrier stems from this cross-platform coordination capability: if the same Agent execution layer can enter more Android brands and enable third-party apps to declare permissions in a relatively unified manner, Doubao has the opportunity to become a new platform between smartphone makers and applications.
NaviX Ultra demonstrated that GUIs, tools, service interfaces, task orchestration, and SAEP can be integrated into a single consumer product. What remains unproven is how many applications this architecture can stably cover, whether third-party vendors are willing to maintain long-term integration, and whether high-privilege operations can withstand continuous security scrutiny.
The problem has not been completely resolved
Returning to the initial question, the most significant change in Doubao Phone from Beta to Consumer Preview is a shift from relying on a single path of GUI Agents to using task orchestration to uniformly schedule GUIs, system tools, and service interfaces, while managing third-party application boundaries through SAEP.
This architecture mitigates issues such as unstable GUI operations, applications failing to recognize Agents, and a lack of constraints on high-risk actions. It also provides a negotiation mechanism for the previous "App bans."
But this is only the beginning. How many applications the interface can cover, and whether SAEP will be accepted by mainstream platforms—these unresolved questions still determine the upper limit of Doubao Phone’s capabilities.
Therefore, Doubao needs to convince more applications to see the value in integration: preserving control over their own business and data while gaining new user insights through AI. This path is difficult, but it is a threshold that truly intelligent agent phones must cross.
Consequently, the consumer preview version serves as the starting point for Doubao Phone’s maturation. It has already proposed a method for models, systems, and applications to work together; the next step is to prove whether this approach remains effective across more applications, more users, and longer periods.
Author: Hope
Editor: Yisong
Source: Future Devices