The (non-daemon) threads were not interrupted on video stream stopped,
leaving the server process alive.
Interrupt them to wake up their blocking call so that they terminate
properly.
Refs #1992 <https://github.com/Genymobile/scrcpy/issues/1992>
This commit in AOSP framework_base added a parameter "attributionTag" to
the call() method:
12ac3f406f%5E%21/#F17
As a consequence, the method did not exist, so scrcpy used the legacy
call() method (using the authority "unknown") as a fallback, which fails
for security reasons.
Fixes#1468 <https://github.com/Genymobile/scrcpy/issues/1468>
The behavior of some methods do not depend on the user-provided options.
These methods can be static. This will allow to call them directly from
the cleanup process.
To avoid possible copy-paste loops between the computer and the device,
the device clipboard is not set if it already contains the expected
content.
But the condition was wrong: it was not set also if it was empty.
Refs 1223a72eb8Fixes#1658 <https://github.com/Genymobile/scrcpy/issues/1658>
Do not explicitly set the clipboard text if it already contains the
expected content. This avoids possible copy-paste loops between the
computer and the device.
When the client requests to set the clipboard, it may request to press
the PASTE key in addition. To be a bit generic, it was stored as a flag
in ControlMessage.java.
But flags suggest that it represents a bitwise union. Use a simple
boolean instead.
To power the device on, inject KEYCODE_WAKEUP to avoid a possible
race condition (the device might become off between the test
isScreenOn() and the POWER keycode injection).
In theory, this was expected to only happen when a touch event is sent
just before the device is rotated, but some devices do not respect the
encoding size, causing an unexpected mismatch.
Refs #1518 <https://github.com/Genymobile/scrcpy/issues/1518>
In practice, it does not change anything (it just avoids a spurious
wake-up), but semantically, it makes no sense to call
pushClipboardText() with a null value.
Clean up has been broken by 3df63c579d.
The verbosity was correctly initialized for the Server process, but not
for the CleanUp process.
To avoid the problem, initialize a default log level.
Only the main injection method was exposed on Device, the convenience
methods were implemented in Controller.
For consistency, move them all to the Device class.
The Android device listens for clipboard changes to synchronize with the
computer clipboard.
However, if the change comes from scrcpy (for example via Ctrl+Shift+v),
do not notify the change.
Scroll events were sent with a mouse input device. When scrolling on a
list, this could cause the whole list to be focused, and drawn with the
focus color as background.
Send scroll events with a touchscreen input device instead (like motion
events).
Fixes#1362 <https://github.com/Genymobile/scrcpy/issues/1362>
Now that the server can access the Android settings and clean up
properly, handle the "show touches" option from the server.
The initial state is now correctly restored, even on device
disconnection.
Expose methods to access the Android settings using private APIs.
This allows to read and write settings values immediately without
starting a new process to call "settings".
Romain Vimont
Tzah Mazuz
brunoais
xeropresence