The app knew about bonded devices only in passing - syncPairedDevices marked
them tracked and threw the bond state away - so nothing downstream could tell
a paired device from one merely seen. Adds devices.paired (schema 17), set
from ACTION_BOND_STATE_CHANGED and from the bonded list at startup, and sends
it as a `paired` column on every uploaded row.
The flag is its own column rather than inferred from is_tracked, which answers
a different question: a device can be tracked without ever having been paired.
syncPairedDevices clears the flag before re-asserting it from getBondedDevices.
A device unpaired while the service was dead never broadcast BOND_NONE, so the
bonded list is the only reliable answer at startup, and without the clear such
a device would stay marked paired forever.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Yes, the scanner was duplicating. refreshCategoryOptions(),
updateRadar() and pairedAdapter.notifyDataSetChanged() ran from
acceptSignal on every advertisement AND from pruneTask once a second
- the same three calls either way.
Worse, the whole persist path ran per advertisement, and ScanCallback
is delivered on the main looper: a hex dump of the advertisement,
lookupCompany(), get(), lookupOui(), then telemetry(),
setDetectedCategory(), recordObservation() and setVendor(). Eight
database operations on the UI thread per beacon, at
SCAN_MODE_LOW_LATENCY, times every transmitter in range. The radar
sweep re-posts itself every 33ms and was competing for that thread,
which is why it dragged.
A device already on the radar now only gets its RSSI and last-seen
stamp refreshed until PERSIST_INTERVAL_MS (3s) is up. A device's
first sighting still takes the full path and refreshes at once.
The radar view also allocated per frame at 30fps: a six-stop
RadialGradient plus two arrays, and a fresh ArrayList and Comparator
for the target sort. Both reused now. setTargets no longer
invalidates while scanning, since onDraw already re-posts itself.
Left setLayerType(SOFTWARE) alone - setShadowLayer only works on text
under hardware acceleration, so removing it would drop the ring glow.
Separately, history points now say why they exist. location_history
had no event column, so schema 16 adds one; connected() and
disconnected() stamp it and a plain position refresh leaves it null.
The popup shows a linked or broken-link line for the two states and
stays quiet for older rows that predate the column.
History points also render as the device's own marker at half size
rather than a plain circle, sharing one divIcon per device so a long
trail does not build a DOM node per point.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MAragon