templates and availability spawned `emulator -list-avds` on every
render, so opening the boot sheet -- and clicking a template, which
re-queries them all -- stuttered for seconds. Cache the listing and
warm it off the main thread when the picker or sheet appears.
Collapse the two per-architecture Android entries into one; the
chosen AVD now decides the architecture, retiring the message that
wrongly claimed Frida could only instrument the other one.
frida-core now reads a kernel once and answers what it names, so the
image config carries that rather than a path, and the vsock probe asks
it for the symbol instead of searching the image for the word.
That probe was never a symbol lookup: kallsyms stores its names
compressed, so the match came from whatever else in the kernel happens
to spell vsock. It took an LZ4 inflater of its own to look, which goes
with it.
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.
Keep a stopping machine listed until its shutdown returns, guard
against a second stop, and let the button say so and go quiet
instead of firing again.
The device took whichever id Frida handed out, so it changed every
time a machine was stopped and started, and a persisted session could
no longer find the device it named. Derive the id from the machine, so
it is the same one across a restart of the machine or of Luma.
A ready snapshot held two things that belong to the session that took
it, not to the machine, and a boot resuming from it could carry
neither.
The agent connection plugs a virtio-serial port into the guest for the
hostlink. QEMU cannot load a snapshot holding that port into a machine
that has yet to make one, so a resuming boot died the moment the state
came back and the debugger it hosts refused every connection. Pull the
port before savevm, the way the restore path already pulls it before
loadvm.
The agent itself lives in guest memory. A snapshot that kept it would
have a resuming boot inject a second agent on top of the first. Let
the agent leave and reclaim its memory before the snapshot, then give
the machine a fresh one, so what comes back is a clean guest.
The three Alpine templates said the same thing three times. Fold them
into one Linux template whose architecture is a parameter, defaulting
to the machine's own. A template now carries a variant per
architecture -- its agent flavor and starter images -- and resolves
the right one from the chosen parameters, so the boot dialogs offer
the starter kit and agent that fit the selection.
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