I imagine his workflow consists of a mobile device (that stays awake without user input) is plugged in to the dev machine which is running scrcpy. The scrcpy screen is then on the dev machine screen next to the editor so that code can be deployed/hot-reloaded/applied to the device as it changes. The emulator is too slow, and Jetpack Compose previews do not handle complex situations well, so a device is always the most preferred method.
This has at least been my way of developing for Android over the years.
Yes, appropriate description. This way you can use your mouse to navigate your app instead of switching between mobile device and mouse all the time. I was surprised that there is no noticeable lagging.
If you like you can turn the device screen of via option --turn-screen-off, and the scrcpy screen will still be available. Furthermore, option --max-size 1024 is handy to customize the size of the scrcpy screen accordingly.
This is fantastic. It's so smooth. I've been looking for something like this for a while.
It didn't register my mouse and keyboard inputs at first. It worked after I enabled "Allow granting permissions and simulating input via USB debugging" option on my phone.
Great piece of software. Used it a couple months ago when I wanted to keep eyes on an app, but didn't want to keep looking down at my phone. Worked flawlessly.
I do a fair amount of physical unplugging and replugging of Android devices over USB while debugging. I used to get occasional hangs when doing that, so I run scrcpy thusly in a bash wrapper script on Linux hosts:
#!/bin/bash
# Update: January 2, 2021
#
# script to permit an end user to mirror an android device's GUI
# on a Linux GUI desktop in a window of its own with
# mouse and keyboard interactivity
#
# Prerequisites:
#
# android device with adb debugging enabled
# adb (i.e. android-tools-adb)
# scrcpy (android screen mirror tool)
# USB connection between Android phone and Linux machine
#
# Setup:
#
# Log in as root and do the following:
#
# 1. use visudo to create or edit the file /etc/sudoers.d/adbmount
# with the following entries (use suitable paths to
# the binaries) to authorize the end user for fuser
# and adb use:
#
# %users ALL=(myth) NOPASSWD: /bin/fuser
# %users ALL=(myth) NOPASSWD: /bin/adb
#
# 2. create a new group or add an entry in /etc/group
# for "plugdev" with the end user as member, such as:
#
# plugdev:x:46:mythical
#
# 3. connect the android device to the Linux machine via
# a USB cable and use the lsusb command to get the
# android device's identifying info, such as:
#
# Bus 001 Device 012: ID 18d1:XXXX Google Inc.
#
# 4. create the file /etc/udev/rules.d/51-adbmount.rules
# with the following line, using the id from step 3:
#
# SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", ATTR{idProduct}=="XXXX", MODE="0666", GROUP="plugdev"
#
# 5. run the following command to load the new rules so
# that udev will now allow members of group "plugdev"
# to access the android device:
#
# udevadm control --reload-rules
#
# 6. test this script as the specified end user instead
# of as root
# first kill any hanging adb tcp port 27183:
sudo /bin/fuser -k -n tcp 27183 2>/dev/null
# force any running adb server process to stop:
sudo /bin/adb kill-server 2>/dev/null
# force the adb server to start and scan USB bus:
sudo /bin/adb devices
# start the scrpy app:
/bin/scrcpy
It would be useful to hook on the frame-received event and send to an hosted webrtc page, so that you can share your tablet screen instantly to co-workers.
Anyone tried a similar setup?
> This application provides display and control of Android devices connected via USB (or over TCP/IP). It does not require any root access. It works on GNU/Linux, Windows and macOS.
Nice job self-promoting though, almost didn't notice.
