0.2.3's manifest pinned the sha256 of one Android build's focal64
(16.82.0, the build the dev phone runs). Fairphone re-signs the trustlet
every release, so that pin matched exactly one of the six builds seen,
and two of two field reports had no sensor: one user on 16.100.0 edited
the manifest by hand, another ended up with a file QTEE refuses.
The manifest now carries '-' instead of a hash and depends on
fp6-vendor-blobs 1-r3, which tries the active slot first and verifies the
image's structure; QTEE's signature check is the gate it always was (one
flipped byte -> ERROR_ELF_SIGNATURE_ERROR, measured 2026-09-03 and again
today).
post-install reassembles the trustlet right away, so 'apk add' no longer
needs a boot for it. post-upgrade re-derives it from the active slot,
which replaces a hand-placed or wrongly pinned file, and then restarts
the daemon -- a plain restart, so a daemon that exited on a refused
trustlet comes back up on the re-derived one.
loadFromBuffer failures name the loader's verdict. The field's first
report was a bare result=12; it now reads ERROR_ELF_SIGNATURE_ERROR with
what to do about it. Probed on the phone with this build: a one-byte
tampered image and 100000 random bytes both print it, the pristine image
loads, and the suites pass 8/8.
The phone is one SoC, 4x Cortex-A520 + 4x Cortex-A720, and the package is
built for nothing else, so build for it: -march=armv8.6-a+fp16fml+aes+sha3+sm4
-mtune=cortex-a720 instead of the generic Armv8 baseline, for the daemon, the
agent and libqcomtee alike. That is gcc's own -march=native expansion on the
phone, re-based on armv8.6-a so clang can express the same set; 8.6 is the
highest level whose mandatory set the phone exposes (8.7 would assume WFxT,
9.x SVE2 - neither is in its hwcaps, and SVE2 code would SIGILL). Same string
as the fp6-img aports and kernel.
fp6-vendor-blobs learned the mbn directive in 1-r2. The extractor before it
exits on an unknown directive, so a fresh flash with 1-r1 and our
20-focal64.manifest processes the audio fragment and then fails the blobs unit
on ours: a red unit, no trustlet, and nothing in the daemon's own logs to say
why. Saying >=1-r2 makes apk refuse a combination that cannot work instead of
installing one that fails at first boot. Existing installs never saw this --
the old fast path only checks file lines and exits before the dispatcher.
apk also swaps the binary on disk and leaves the running daemon alone, which is
how 0.2.2's FingerMatched signal first presented: a clean MATCH in the journal
and nothing downstream, because the boot's 0.1.3 was still answering. A
post-upgrade try-restart closes that. A daemon that is not running stays not
running, and a build chroot without systemd is left alone.
0.2.3, so the package CI publishes it.
The daemon announces every matched finger on the system bus and stops there,
because root has no session bus, no display and no business starting your
applications. fingerprintd-agent is the other half: it runs as you, subscribes
properly rather than parsing gdbus monitor output, filters by uid because the
signal is visible to every local user, and maps fingers to commands from a file
you own and can edit without restarting anything.
It is a separate binary and a separate subpackage because it is a separate
trust domain. /etc/fingerprintd/actions.conf is a root shell and is guarded
like one; ~/.config/fingerprintd/fingers.conf runs your commands as you, so it
is an ordinary dotfile.
Demonstrated on the phone: one press of the unlock finger both unlocks it and
opens plasma-camera.
An aport, the units, and everything a phone needs to come up with a working
sensor without a single command being run by hand. Verified on the dev phone
across two reboots: modules-load.d loads qcomtee, tmpfiles builds the SFS
root, the mount unit brings up persist, and the daemon is ready 51 seconds
into the boot, owning net.reactivated.Fprint with the enrolled finger
visible.
The packaging shape is the one imsd uses for 81voltd. A versioned
provides="fprintd=..." satisfies plasma-workspace -- its Users KCM is the
enrolment UI and speaks exactly this bus name -- and excludes the real
fprintd, which is not tidiness: fprintd is D-Bus-activatable, so a client
call would otherwise start it and fight us for the name. The cost is the
fprintd-* CLIs, which go with the package.
fprintd-pam is an install_if subpackage pinned to the exact fprintd version,
so the provides breaks its condition and apk purges it -- taking pam_fprintd,
which is the entire point of the daemon, with it. Depending on it explicitly
is what keeps it, and it has no dependency on fprintd itself.
Two things the packaging exposed in the daemon:
The transcript is for experiments, not for a shipped daemon. A file per start
in an unrotated directory, recording the time of every unlock, to say what
the journal already has. It is now opt-in behind --log-dir, which is what
deploy-dev.sh passes since fplearn.sh reads it.
Taking it off the daemon path also took away the setvbuf it was doing as a
side effect of dup2'ing fd 1, and under systemd stdout is a pipe, which means
full buffering: the daemon started, worked, answered D-Bus calls, and printed
nothing. A working daemon that looks hung. stdout is now line-buffered from
the first line of main.
The config ships as generated by fp6fpcfg.py --daemon --verbose, sha256
b205c756914a66f1, because that is the file every accuracy number was measured
on. The quieter variant is untested and switching is a measurement.
The trustlet is not here and never will be: focal64.mbn is a proprietary
OEM-signed blob, and the unit's ConditionPathExists is what keeps the package
inert without it -- as it does on a kernel with no CONFIG_QCOMTEE.
