Scrcpy: Create scrcpy-server.jar from source in the tree

[faezebax]

Hi. I want to create a rpm package of scrcpy. I have to have scrcpy-server source and generate its jar file. I don't know how to do it. Can you please tell me how to create scrcpy-server.jar from source tree?

[rom1v]

The build instructions also build the server.

Alternatively, you could call gradle directly:

./gradlew -p server assembleRelease
cp server/build/outputs/apk/release/server-release-unsigned.apk scrcpy-server.jar

Alternatively, you can also build without gradle, using build_without_gradle.sh on dev branch. I wrote it recently because building the current version was a problem for Debian (ref).

[faezebax]

I tried both methods, both need android sdk. first method says SDK location not found. Define location with an ANDROID_SDK_ROOT environment variable or by setting the sdk.dir path in your project's local properties file at '/home/username/scrcpy/local.properties'. and second one says ./build_without_gradle.sh: line 39: /build-tools/29.0.2/aidl: No such file or directory which again is looking after android sdk.

[faezebax]

I built scrcpy by downloading scrcpy-server.jar into build system but it is an ugly way. it is better to have a way to generate server file without need to use android sdk because android sdk is not available natively in any distro means that scrcpy never goes to any distro official repo. is it possible to generate it without android sdk?

https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_pre_built_dependencies

[rom1v]

is it possible to generate it without android sdk?

The Android SDK is required to build the server:

1. to provide the build system (gradle) and the Android plugin
2. to "dex" the class, so that they can be executed on the Android device
3. to link against android.jar
4. to generate some Java source from aidl

We can now avoid (1) by using build_without_gradle.sh.
If required, we could avoid (3) by either using reflection or providing a stub for all framework methods we actually use.
We could easily avoid (4) by just providing the generated code from aidl (there is only IRotationWatcher).

But anyway, the build-tool dx from the Android SDK is necessary.

android sdk is not available natively in any distro means that scrcpy never goes to any distro official repo

android-sdk is packaged in Debian.

A new RFS have been submitted by Yangfl: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944334

In other words, there is a package in a state acceptable by Debian. It just requires a sponsor to be uploaded.

[leigh123linux]

@rom1v Why can't you provide the server in google play store instead?

[rom1v]

@leigh123linux The server is not an Android app (just a Java app compiled for Android which executes a public static void main(String... args) method).

Moreover, the server and client must be compatible, this would be difficult to make it work.

For example, if debian stable uses scrcpy 1.9 and debian sid uses 1.10 (with an incompatible server), which server version should be published on the playstore?

[kwizart]

Could you publish both versions on the playstore ?

[Vascom]

Can you publish latest release version of it on F-Droid?
We promise always package the same version in Fedora.

[faezebax]

As you stated for scrcpy/server, server binary pushed to Android device. Well many users don't want something pushed from the host to their phones. So it would be a good idea to separate server from client. Server side could be build for Android and client side could be build for client machines. It has two obvious advantages: first it causes scrcpy easily built and shipped to distros. Second, paranoia users can't criticize about its insecurity. Anyway they don't want something pushed to their phones. I know it requires more effort but it's a clean and standard way.

[rom1v]

Can you publish latest release version of it on F-Droid?

No, this isn't even an Android application.

We promise always package the same version in Fedora.

This is not feasible. F-Droid/Google Play and Fedora distribute at their own pace. And why would the F-Droid package match the Fedora version instead of the Debian stable version? Or another?

The only possibility would be to make the server backward (and forward?) compatible (I don't want that).

Well many users don't want something pushed from the host to their phones.
Second, paranoia users can't criticize about its insecurity.

This would not change anything from a security point of view: the client would still have the possibility to inject whatever it wants on the device (it would just choose not to).

it causes scrcpy easily built and shipped to distros

That's definitively the main point (and a valid argument, it's not a coincidence that the author of the RFS asked the same thing).

But even with the client/server compatibility mess that would introduce, not requiring an app is an important "feature" of scrcpy: you can plug any device, and start it immediately.
So such a packaged version would be a degraded version of scrcpy, only for packaging issues, and people would need to compile it manually to use the non-degraded version.

I wish it could be built without the Android SDK for simplicity (even for users who build it manually), but unfortunately (currently) it's not possible. Nevertheless, since the Android SDK is packaged in Debian, I guess it can be packaged in other distros too.

[leigh123linux]

Can you publish latest release version of it on F-Droid?

No, this isn't even an Android application.

The server app isn't linux so your argument is invalid.

We promise always package the same version in Fedora.

This is not feasible. F-Droid/Google Play and Fedora distribute at their own pace. And why would the F-Droid package match the Fedora version instead of the Debian stable version? Or another?

The only possibility would be to make the server backward (and forward?) compatible (I don't want that).

Well many users don't want something pushed from the host to their phones.
Second, paranoia users can't criticize about its insecurity.

This would not change anything from a security point of view: the client would still have the possibility to inject whatever it wants on the device (it would just choose not to).

Yes it would, it shifts the responsibly from us if you server app ruins the android device.

it causes scrcpy easily built and shipped to distros

That's definitively the main point (and a valid argument, it's not a coincidence that the author of the RFS asked the same thing).

But even with the client/server compatibility mess that would introduce, not requiring an app is an important "feature" of scrcpy: you can plug any device, and start it immediately.
So such a packaged version would be a degraded version of scrcpy, only for packaging issues, and people would need to compile it manually to use the non-degraded version.

I wish it could be built without the Android SDK for simplicity (even for users who build it manually), but unfortunately (currently) it's not possible. Nevertheless, since the Android SDK is packaged in Debian, I guess it can be packaged in other distros too.

I will refuse to process any review request for fedora if it includes it.

[srevinsaju]

Pushing the scrcpy-server.jar causes a lag in the startup of scrcpy right? Allowing scrcpy-server to be preinstalled might make scrcpy even more faster and better. (A suggestion, doesn't know if it's feasible)

This is not feasible. F-Droid/Google Play and Fedora distribute at their own pace. And why would the F-Droid package match the Fedora version instead of the Debian stable version? Or another?

What about a GitHub asset release APK? 🤔

_Sent from my Galaxy Note2 using FastHub_