Optional root (su, Magisk Zygisk module, etc) for mirroring Android 12+ w/FLAG_SECURE

[digitalcircuit]

• I have checked that a similar feature request does not already exist.

I found #2242 but that seemed to focus on non-root options.

Is your feature request related to a problem? Please describe.
In Android 12+, it is no longer possible to mirror the output of apps expecting a FLAG_SECURE display. The non-root fix scrcpy uses now is to no longer capture secure output on Android 12+.

Describe the solution you'd like
For those with root, it'd be nice if scrcpy could optionally make use of root access to enable mirroring apps that require secure display output.

Brainstorming:

• Directly request root access via su to do what's needed, if possible
• Provide an app .apk to be installed with system privileges (e.g. as a simple Magisk module)
  • Magisk now provides Zygisk to inject code into processes, so it may be possible to revert the shell UID check
• Integration with Sui to provide more natural access to Java APIs as the root user
  • Assuming this may require more effort on scrcpy's side to provide an app (APK?) that requests Sui access

Describe alternatives you've considered
Disable FLAG_SECURE for all apps using the LSposed (modern Xposed), or via a Magisk "Zygisk" code injection to the system framework.

This would unfortunately enable every app to have this access instead of just allowing the shell, unless a module could be made to revert specifically the shell UID FLAG_SECURE check.

Additional context
All of this except for maybe using su directly if possible sounds rather complicated for a niche of scrcpy users. I'd understand if the immediate reaction to this feature request is to close it and go "Nope, not touching that." 🙂

[rom1v]

I have no experience with Magisk, but if it's possible to only allow shell to enable secure flag permissions, then scrcpy could provide an option --secure-flag, which will cause an exception (like #2129) on non-root devices, but will work for root devices with permissions enabled.

[AndroidDeveloperLB]

Wait, it's now possible to use ScrCpy to enable mirroring even protected screens (on rooted devices) ?
Is it under development?

[digitalcircuit]

@AndroidDeveloperLB Not yet, alas. That's why I'm filing this feature request, to prompt discussion about how scrcpy could possibly do this.

@rom1v Noted! Adding a --secure-flag option once a root/Magisk solution is sorted to reverse that permission change sounds like a reasonable low-maintenance approach on scrcpy's side.

Rambling notes

I have much to learn about Magisk's recent Zygisk development and hooking Android functions, but I wanted to jot this down for future reference.

It looks like it'd involve patching the hasCaptureBlackoutContentPermission() function…

static bool hasCaptureBlackoutContentPermission() {
    IPCThreadState* ipc = IPCThreadState::self();
    const int pid = ipc->getCallingPid();
    const int uid = ipc->getCallingUid();
    return uid == AID_GRAPHICS || uid == AID_SYSTEM ||
            PermissionCache::checkPermission(sCaptureBlackoutContent, pid, uid);
}

Adding back in a || uid == AID_SHELL like what used to be there.

Alternatively, if there's a way to use root/Magisk/etc to grant android.permission.CAPTURE_BLACKOUT_CONTENT to scrcpy, that would work. It might involve using the Shizuku API within scrcpy itself via Sui, which is… probably lower level than desired?

(I may have gotten the permission name wrong - the system AndroidManifest.xml seems to describe this as capturing secure content, as if a screenshot.)

Regardless, I'd understand wanting to keep the changes to scrcpy itself as minimal (and therefore as maintainable) as possible.

[AndroidDeveloperLB]

@digitalcircuit What's "CAPTURE_BLACKOUT_CONTENT" ? I don't see it on the docs:
https://developer.android.com/reference/android/Manifest.permission
I wonder if a screenshot app could get this permission (via root).

Anyway, I would love to have ScrCpy be able to show this content, even it if requires root. I find it weird that this restriction is applied even via adb.

[digitalcircuit]

@AndroidDeveloperLB I think it's intentionally not mentioned on that page due to being listed as "Not for use by third-party applications." with an @hide annotation.

frameworks/base/core/res/AndroidManifest.xml found via searching on cs.android.com:

    <!-- Allows an application to take screenshots of layers that normally would be blacked out when
         a screenshot is taken. Specifically, layers that have the flag
         {@link android.view.SurfaceControl#SECURE} will be screenshot if the caller requests to
         capture secure layers. Normally those layers will be rendered black.
         <p>Not for use by third-party applications.
         @hide
    -->
    <permission android:name="android.permission.CAPTURE_BLACKOUT_CONTENT"
        android:protectionLevel="signature" />

As you mentioned, the question I have as well is whether a protection level of signature can be safely granted to just a specific app via root/Sui/Zygisk/etc? And if so, what would be the proper (most maintainable and secure) method of going about it..?

Alternatively, hijacking the hasCaptureBlackoutContentPermission() permission check to allow UID_SHELL (ADB) again might return to pre-Android 12 security level - less specific, but likely an acceptable trade-off.

(It's possible I'm misunderstanding as I'm attempting to make sense of an area of Android that I'm unfamiliar with.)

[AndroidDeveloperLB]

@digitalcircuit According to CommonsWare, it shouldn't allow you to grant it, sadly:
https://stackoverflow.com/questions/29185717/is-there-any-way-to-get-permission-with-protection-level-signature-in-android#comment46586830_29185717

But you can try. Edit some open sourced screenshot app, add the permission, grant it via adb, and see if it helps on protected apps.

He't talking about normal granting of the permission via adb (or root). I don't know the advanced stuff you talk about

[MlgmXyysd]

It's not a good thing to require root permission. Hook (Zygisk/Xposed) is even worse, especially when Xposed is seriously deprecated and destroying the custom Android community (not modern). Why not try to use the normal application to ask for permission of virtual display?

[AndroidDeveloperLB]

@MlgmXyysd You'd have to talk with every application that uses this API to block screenshots/screen-capture...
And it's not guaranteed they will do anything about what you write them.
Not practical.

It's better to have some solution than nothing.

I've requested from Google to add some toggle to turn off this kind of protection in next Android version:
https://issuetracker.google.com/issues/225529536
Please consider starring.

[MlgmXyysd]

I've requested from Google to add some toggle to turn off this kind of protection in next Android version: https://issuetracker.google.com/issues/225529536 Please consider starring.

Starred, but there is no hope that they will do so, just as they added FLAG_SECURE.

[LexNastin]

Any progress or plans on this? Would really love a way to bypass FLAG_SECURE

[MlgmXyysd]

Any progress or plans on this? Would really love a way to bypass FLAG_SECURE

You can use other ROMs that allows the user to ignore FLAG_SECURE, such as KaleidoscopeOS.

[opptimus]

Wait, it's now possible to use ScrCpy to enable mirroring even protected screens (on rooted devices) ? Is it under development?

I also neet this feature!

[AndroidDeveloperLB]

It seems that if your device is rooted with Magisk, you can have "Zygisk - LSPosed" module, and using it, there is a module inside that is called "Disable FLAG_SECURE":

[LexNastin]

It seems that if your device is rooted with Magisk, you can have "Zygisk - LSPosed" module, and using it, there is a module inside that is called "Disable FLAG_SECURE":

Your proposed solution sadly won't work for most use cases, as this would normally be needed for things like banking apps, but they need to be in the DenyList to work, preventing any modifications to them. So this won't work for that, and we need to modify/use a different service which doesn't have to be DenyListed, the secure display being one of them. Root support would be a very nice feature for scrcpy to have, and I don't believe it would take too much effort to implement. Thanks!