Template learning, the half of the algorithm this daemon never ran. Every match
rate measured against this device -- 1/10, 2/10, 3/10, 7/10 -- was measured
against a day-zero template that no stock user lives with, because a stock
template is rewritten on every successful press and ours never moved a byte.
HarvestTemplate mirrors stock's post-match loop: while the finger is still on
the sensor, capture and fold, sending no event so the matcher cannot re-run and
revise a verdict the client already has. A quick tap pays almost nothing, since
the finger is gone by the time a verdict lands and the first capture reads the
idle floor; a held press contributes the frames it was actually held for.
That last property is why this subsumes the enrolment-tuning thread. The working
hypothesis after the strict-threshold and 30-sample failures was that enrolment
conditions have to resemble verification conditions. Learning is exactly that,
done by the algorithm from real unlock presses instead of by coaching a user
into positions they never use.
FlushTemplate issues the SAVE_DATA, and the worker calls it after the verdict is
posted rather than before. Persisting a learned template is roughly 350 ms of
gpfile and RPMB traffic and it does not belong on an unlock path; stock defers it
the same way, with a lazy-updater timer.
--learn=0 turns the whole thing off, which is the only way the comparison is
single-variable: learning is cumulative, so an A/B needs one binary and one
template lineage rather than two builds. --learn-frames bounds what one press may
contribute, because the template body moves as a single gpfile op against a
516084-byte listener buffer and a 30-sample body already measured 386402.
--probe-learn sends one UPDATE_TEMPLATE with no finger and then ENUMERATEs to
prove the trustlet survived it, which is the part a bare return code cannot say.
Jorijn van der Graaf
e2033ed26d