Vendored from scrcpy v4.1 (Apache-2.0), commit tagged v4.1, from server/src/main/java/. Package names are deliberately unchanged, so that a diff against upstream is a diff and not a translation.

23 files, 2,347 lines kept. 67 files, 9,660 lines dropped.

The brief estimated 32 files / ~3.9k lines. That estimate was right for a fork that keeps Options; dropping it, and then the ServiceManager facade, takes another 13 files out. Every change below exists to remove a dependency, not to change behaviour.

Three files. Each modification is marked PATCHED: at the site.

Constructor took an Options; now takes the three values it read out of it.

- public AudioEncoder(AudioCapture capture, Streamer streamer, Options options)
+ public AudioEncoder(AudioCapture capture, Streamer streamer, int bitRate,
+                     List<CodecOption> codecOptions, String encoderName)

Options is 707 lines of command-line parsing that also references the video, camera, display and orientation types. Keeping it to supply three fields would have dragged roughly half of scrcpy back in, to parse a command line this fork does not have.

Three LogUtils.buildAudioEncoderListMessage() calls were dropped from error messages. LogUtils is 299 lines reaching into Device, DisplayInfo, VideoCodec, DeviceApp and DisplayManager to build a listing. Two of the three sites are unreachable here anyway, since this fork always passes a null encoderName.

Reduced from nine service getters to one, getActivityManager().

The audio path uses ActivityManager in exactly two places: the foreground workaround in AudioDirectCapture (startActivity, forceStopPackage) and FakeContext.getContentProviderExternal. Every other getter was reachable only from video, control or display code that is not here. Keeping them would have pulled in WindowManager, DisplayManager, InputManager, PowerManager, StatusBarManager, ClipboardManager, ContentProvider, SurfaceControl and DisplayControl - about 1,300 lines, none of it ever executed.

createSettingsProvider() removed. It was the only reference to the ContentProvider wrapper, and its only upstream caller was util.Settings. This fork does not touch settings. getContentProviderExternal() is kept, because FakeContext uses it.

device/Streamer.java is untouched. It wants a FileDescriptor, which upstream comes from DesktopConnection's LocalSocket. Main gets an equivalent one from a TCP socket with ParcelFileDescriptor.fromSocket(), so the wire format and the streaming code are exactly upstream's.

The whole audio/ package is kept, including AudioPlaybackCapture, which this fork never instantiates. It is 138 lines, AudioSource refers to it, and keeping the package whole makes future rebases against upstream simpler than saving those lines would.

Server.prepareMainLooper() had to be carried into Main. This is the one piece of Server.java that is not optional. Workarounds' static initialiser constructs an android.app.ActivityThread, whose constructor builds a Handler and therefore needs a prepared Looper on the calling thread. Dropping Server.java drops that preparation, and the failure is opaque: the shell prints only Killed, because the crash handler itself then fails trying to reach the activity manager to report the crash. The real cause is only visible in logcat:

java.lang.RuntimeException: Can't create handler inside thread Thread[main,5,main]
  that has not called Looper.prepare()
    at android.app.ActivityThread.<init>
    at com.genymobile.scrcpy.Workarounds.<clinit>

1. Re-run the closure analysis rather than trusting this file's list.
2. Re-apply the three patches; each is marked PATCHED: in place.
3. Check Streamer's wire format has not changed, or the app's parser breaks.
4. Check whether Workarounds still needs a prepared Looper.