The emulator bridges a guest's vsock to a host UNIX socket, which
Windows has none of, so the guest is reached over the virtio-serial
hostlink there whatever its kernel offers. That channel is opened
through QMP, which QEMU serves over a named pipe on Windows -- and it
holds the machine still until something connects to that pipe, then
gives the pipe up for good once the connection goes.
So the pipe is opened here, as soon as QEMU is spawned and before the
guest is waited on, and held for the barebone backend to adopt by
handle. Waiting for adb first would have deadlocked: the guest cannot
boot until the pipe is answered.
The transport carries the QMP address as a string now rather than a
socket URL, since each host spells it differently.
Also drops the single-core launch, which nothing turned out to need.
Add the androidEmulator debug stub and the pipe-over-vsock agent
transport, and map both onto their barebone config: the connection
carries the hosting QEMU's pid so the backend can instrument its
gdbstub, and the guest dials out to a host socket for the hostlink.
QEMU's virt machine puts PCI configuration space where nobody
can guess, so the agent is told where; the kernel's own console
driver takes the port the hostlink wants, so it is kept out.
Work on frida-core itself is picked up through FRIDA_SWIFT_ROOT,
the way the Pharo VM and the shader toolchain already are.
Add a machine abstraction to LumaCore, with QEMU as its first
backend: templates mirroring frida-core's test guests, a QMP client,
and a display that maps QEMU's surface over D-Bus rather than
copying frames.
Leave readiness to the user: drive the guest, mark it ready, and come
back to that snapshot later. Keep the machine in the project, so
booting it again resumes where it was marked. Hand the stub to
addBareboneDevice, so it joins the picker beside the other devices.
Show the display while booting, and afterwards in a Machines panel,
which the side panel now models as an enum to share its slot.
Ole André Vadla Ravnås