Android Could Let Trusted Apps See and Control Your Screen While Locked [APK Teardown]

Contents hide

What to know
From vague to blunt
A PIN-gated pairing handshake
Setting the stage for agents
What we don’t know yet

What to know

Google is rewriting Companion Device Manager’s permission wording to name exactly what an app can do: see and interact with your screen content.
One permission now says an app can do this “even if the screen is locked,” where the old text only mentioned vague “screen automation.”
A new PIN-confirmed pairing flow gates this trusted access, reading like groundwork for on-device assistants.

Letting an app act on your behalf is about to come with much blunter warnings. While digging through the Android 17 QPR2 Beta 1 build (cp41.260701.005), we found Google rewriting the consent screens in the Companion Device Manager — the system component that governs paired devices and assistant apps — to state plainly that an approved app can read and act on your screen, even while the phone is locked.

About APK teardowns — We examine code and resources bundled inside app builds to find features that have not shipped publicly. These works in progress can change, remain inactive, or disappear before they become available to users.

From vague to blunt

Two permission summaries used to describe a mood rather than a mechanism. The QPR2 build swaps that soft wording for concrete descriptions of what actually happens, and adds that it can occur behind the lock screen.

trust_type_screen_automation_summary (old) = “Allow this device to run screen automation based on your activity”

trust_type_screen_automation_summary (new) = “See and interact with the screen content of apps you’ve allowed to help you complete tasks even if the screen is locked.”

trust_type_proactive_assistance_summary (new) = “Uses an app’s screen content so you can see suggestions.”

Naming the capability this directly — an app reading and acting on what is on your screen, and doing it while locked — is a meaningful shift from “proactive assistance.”

A PIN-gated pairing handshake

The build also adds a pairing flow built around a PIN. A prompt titled “Confirm PIN to pair the app [name] with [device]?” gates the association, with the explainer beneath it laying out the access being granted.

trust_pairing_initiator_title = “Confirm PIN to pair the app %1$s with %2$s?”

trust_pairing_initiator_summary = “The app will be able to see and interact with your devices to use features like helping you complete tasks even when the device is locked. You can turn features on or off in your Android settings.”

Requiring a PIN raises the bar for granting this level of access, and the text points people to Android settings to switch the individual features on or off afterward.

Setting the stage for agents

Companion Device Manager already underpins Android’s app-streaming role, where a paired device can display and control apps running on your phone. This rewording pushes that groundwork toward on-device assistants that watch the screen and take actions for you. Putting the capability behind a PIN and spelling out the locked-screen caveat reads like Google preparing a consent layer for agentic features rather than shipping a single new toggle.

What we don’t know yet

As always, this is teardown-stage work. The strings are in the build, but the flow is not switched on, so the final wording, the apps that will use it, and the rollout timing all remain open.