Add --root functionality for secure displays above A11

[Giantvince1]

This pull request is designed to implement a new --root flag without affecting the original functionality of the project; I have tested it myself, and it is fully supported to the best of my knowledge. If you have any suggestions, please provide them; I know I'm not the only one that would benefit from being able to utilize root access to gain a proper secure display on devices running Android 12 or greater.

[rom1v]

Thank you for the PR.

Just for my own understanding, how does it differ from #4127? There were also changes related to audio, and the package name used in FakeContext was different.

[Giantvince1]

Thank you for the PR.

Just for my own understanding, how does it differ from #4127? There were also changes related to audio, and the package name used in FakeContext was different.

The difference here is that I didn't touch audio handling; I'm just letting it continue with stock audio support (A11+ only) instead of trying to hack in root-enabled audio on older devices. And I believe the package used in that was com.android.systemui instead of the metapackage for the core system (android). Edit: the PR you mentioned actually did use android as the new package context like I did here. I went and checked it.

Edit 2: I reverted FakeContext.java completely due to it not affecting the clipboard's sync abilities no matter what I did. I no longer touch this like the other PR did.

[Giantvince1]

I'm setting this as a draft until we can figure out what we need to do in order to get bidirectional clipboard functionality working. Also, I'm considering adding in a check in the client implementation to detect whether --root would even be needed for a secure display, and acting as if it was omitted when the device doesn't prevent AID_SHELL from actually making a secure display; this way, the flag would only actually change how the program operates where necessary for the desired outcome.

[Giantvince1]

Okay, I've got it figured out for real this time; clipboard is truly bidirectional by bypassing the usual Java package checks we obey and pass while shell but fail if we try as system. Instead it now just creates its own direct Binder IPC call in raw form, reusing the exact format that the existing interface provided so that no other code had to be modified for the new clipboard handling while --root is passed. I also tested everything else again just to be sure it all works; even audio support is completely intact.

[rom1v]

Merge branch 'Genymobile:dev' into dev

Please do not put any merge commit in a pull request.

Btw, you could squash all the commits from this PR into a single one here (since your current commits are just chronological changes).

[Giantvince1]

Sorry about that; I'm still trying to figure out getting the clipboard to work. Even using the raw Binder interface via Parcel is returning empty data on reads, and it also refuses to let me instantiate a listener, which made me resort to polling. The only thing I can think of doing to get clipboard access working is to make it a stub sub-helper that talks to the main Java process; otherwise device to PC clipboard sync will just be broken when it runs as UID 1000.

[Giantvince1]

After endless trial and error, I cannot get the clipboard to work bidirectionally. The only option we have is to spawn two processes in this path: one that's spawned without an su call so it gains the context of com.android.shell which has clipboard read/write access unrestricted, and the main server process that handles the rest. The two processes would use some form of IPC internally so that the existing server code can receive and send clipboard data to the helper inside com.android.shell context. If we don't do that, we'll be completely stuck unable to read the clipboard or register the callback listener when using root access to create a secure display. The good part, however, is that refactoring the clipboard manager to support both the existing path and the potential new path is feasible; it would just involve some form of IPC between the existing clipboard manager and the helper stub so it can communicate back to the client side transparently, and that the IPC path is only used when the JAR is ran as UID 1000.

[Giantvince1]

Would we potentially be able to implement this in some form, or would you rather make the --root toggle also explicitly disable clipboard functionality so that we're not attempting to start a subroutine that we know isn't going to work outside of UID 2000?