[Draft] Add option to install the server as an APK

[rom1v]

To get shell permissions, the server must execute a java main() executable from adb shell.

The jar/apk containing the executable can be either pushed to any location (/data/local/tmp), or installed on the device.

Since the beginning of the project, scrcpy just pushed the server to /data/local/tmp, because it's faster and simpler.

However, scrcpy might benefit from a companion Android app for supporting new features:

• provide an IME (to inject non-ASCII text);
• forward audio (a proper integration of what sndcpy does);
• optionally mirror camera instead of the screen (which requires a user authorization from an app)…

Instead of building a separate Android app to manage (install/reinstall), this PR makes possible to install the server directly as an APK (and execute the server from there):

scrcpy --install
scrcpy --reinstall

This paves the way to easily integrate Android component and start activities or services embedded in the server.

As a consequence, the server is now named scrcpy-server.apk (which is a drawback IMO, since people will want to install it manually instead of letting the client manage it) and is apk-signed so that it can be installed.

Refs #1722
Refs #1880 (comment)

[rom1v]

@yangfl This might impact Debian packaging: with this PR, the APK is signed. I updated build_without_gradle.sh do perform these tasks manually (without gradle). Please let me know if it's ok for you (but it's not urgent).

[yangfl]

It's ok, since we can ask users to download and install apk from android side, or just sign it with a random key.

[rom1v]

I am a bit worried about security implications though.

If someone manage to make you install a malicious app having package com.genymobile.scrcpy, then the next time the scrcpy client is executed, it will execute the java "executable" embedded in this package with shell permissions. This is a form of privilege escalation.

Maybe the server (executed by adb shell) and the companion APK to install should be a separate APK in the end. That would prevent this problem (no code from the APK could be executed with shell permissions).

When the app is pushed to /data/local/tmp, this is ok because no app can write to /data/local/tmp/ (to replace the server just after it is pushed but before it is executed).

[yangfl]

I think we can check signature of preinstalled apk and stop (or at least warn users and let them choose) running of unknown apk.

Maybe checking hash of apk file is a better choice, but I can't find how to do it...

[quyleanh]

Sorry for asking but is there any progress of this PR?

[rom1v]

Sorry for asking but is there any progress of this PR?

Due to #3517 (comment), I think it would be better to use a companion app instead. This PR is a good base but it is not intended to be merged as is.

[quyleanh]

Thank you for explaining.
It's sad when an other approach of injecting non-ASCII text goes nowhere...

[rom1v]

It's sad when an other approach of injecting non-ASCII text goes nowhere...

HID keyboard (over USB) should work pretty well.

[quyleanh]

HID keyboard (over USB) should work pretty well.

Actually this feature doesn't fit my need. I would like a faster switch for mouse and keyboard.
Sometimes it also cannot detect my keyboard hardware.

[rom1v]

Now, there is audio, camera and HID without the need for an app. Closing.