Tracelet-ൽ എന്താണ് പുതിയത്

tracelet

3.8.7

FIX: (Android, iOS) the events that explain a background tracking failure are recorded on the always-on lifecycle channel, so a release build can report them. A released app runs at the default logLevel, where every debug line is discarded — which is why diagnosing the last round took repeated captures and a source read rather than one report. Now recorded regardless of level, and all per-session rather than per-fix: the continuous location stream starting and stopping (the transition the OS location indicator follows, so "the icon disappeared" is answerable); the app moving to background and to foreground — iOS never observed the background edge at all, so a report could show the app coming back but never leaving; foreground-service promotion and demotion, naming the demotion window in which a task removal is fatal; a pace machine refused a stale fix's speed, and the moment it gets a current one again; and a session start that declined to seed the pace machine because no fix had been resolved yet. The stale-fix lines are emitted once per run rather than once per fix, so a long run of them costs one line.

FIX: (Android, iOS) a stale cached fix can no longer stand a session down the moment it wakes. Both platforms deliver a cached last-known fix as soon as location updates restart, carrying the speed from whenever it was taken — which, on a session the accelerometer has just woken, is from before the device stopped. The field trace shows the wake and the stand-down in the same second: speed-motion: STATIONARY -> MOVING — manual pace change immediately followed by MOVING -> SLOWING — speed=0.10 m/s, then STATIONARY again 30 s later. Walking with the app backgrounded or killed therefore produced a cycle — the accelerometer wakes the stream, a stale reading stands it down, the stream stops — rather than tracking, with the location indicator flickering off and staying off. Only a fix less than ten seconds old may now drive the pace machine. Persistence and dispatch are untouched: a cached fix is still a real position, and the processor's own gates decide whether to keep it; it is only its speed that says nothing about the present.

FIX: (Android, iOS) tracking survives being backgrounded or killed while moving. On startup the speed state machine was seeded with LocationEngine.lastEffectiveSpeed, which is 0.0 on a process that has not yet handled a fix — exactly the state a killed-state relaunch or a background takeover begins in. A session that had just resumed as MOVING was therefore told it was stopped: it dropped to SLOWING immediately and, speedStationaryDelay later, to STATIONARY, which switches off the continuous stream. The device had not moved differently and nothing else had changed; the location indicator simply disappeared shortly after the app left the screen. A field trace shows it twice in one minute — boot-tracking: bootstrapping … speedState=MOVING followed within the same second by MOVING -> SLOWING — speed=0.00 m/s, and 30 s later SLOWING -> STATIONARY — countdown expired. 0.0 means "no speed reported", not "stopped", so the machine is now seeded only when this process has actually resolved a speed. The same fabricated zero is gone from the periodic-fix path, which fed 0.0 into the machine whenever a periodic fix arrived without a speed.

FIX: (Android, iOS) a walking user is no longer classified as stationary. MotionConfig.speedMovingThreshold defaulted to 1.5 m/s — above an average walking pace of ~1.4 m/s — and a single threshold governed both directions with no band between them, so an ordinary walk straddled it: wake at 1.50-1.55 m/s, drop to SLOWING a second later at 1.31-1.48, run the countdown to STATIONARY with 26-28 consecutive fixes just below, wake again. Reaching STATIONARY switches the session to periodic fixes, which is what a walking user reports as "tracking stopped on its own". The entry threshold is now 0.9 m/s, comfortably below a slow walk and well above the 0.1-0.3 m/s a parked device reports from GPS noise, and leaving MOVING uses a separate, lower threshold — the new MotionConfig.speedStationaryThreshold, defaulting to 65 % of the entry one and clamped to it if set higher. The gap between the two is a hysteresis band, so a pace that varies either side of the entry threshold no longer oscillates. Both values are configurable; apps that tuned speedMovingThreshold themselves are unaffected.

FIX: (Android) a stationary session that declines a wake can still be woken by the next one. TYPE_SIGNIFICANT_MOTION is a one-shot trigger sensor — firing consumes the registration — and the wake path tore down both wake sources before asking the motion coordinator what to do with the event. When the coordinator declined it (returning no action, leaving the session stationary), nothing re-armed either one: significant motion was consumed, shake monitoring had been stopped, and the accelerometer had been switched to stillness detection, which by construction only notices the device stopping. In the foreground that self-heals, because the CPU stays awake and a later shake or periodic fix rescues it; backgrounded it does not, since TYPE_ACCELEROMETER is a non-wakeup sensor and delivers nothing while the device is suspended. The session stayed stationary until tracking was restarted by hand. A declined wake now restores stationary monitoring, re-arming both sources, and says so on the lifecycle channel.

FIX: (Android, iOS) tracking no longer freezes mid-walk and then jumps. Three faults compounded into one failure. The battery-budget engine measured drain from a single pair of battery-level readings five minutes apart — a level iOS reports in 5 % steps — so one reporting step read as 60 %/hr against a 3 %/hr budget and throttled a device that was draining normally. It throttled by writing its output into your live configuration, where distanceFilter: 0 (the documented "record every fix" opt-out) multiplied to 0 and was clamped up to 10 m: the processor's protection for a configured zero reads the base tuning that write had just replaced, nothing could ever restore it, and Tracelet.activeConfig began reporting a configuration you had never set. With a distance gate now in play, adaptive sampling multiplied it by an unbounded activity and battery factor — 750 m for a Still classification below 50 % battery — and because the processor's anchor advances only on an accepted fix, once nothing was accepted nothing could be. Four minutes of walking produced 59 rejections, zero locations and a frozen odometer. The jump was the same bug's second act: the implied-speed guard divides by the anchor's age, so a 1.65 km cell fix arriving 196 s later reads as 8.4 m/s and clears any ceiling meant for a car. Now: drain is measured over at least 15 minutes and discounted by one reporting step, so a figure only counts when it beats the budget by more than the measurement can resolve; throttling is a bounded five-rung ladder applied as an overlay that never touches your configuration, moves one rung per two consecutive conclusive windows, throttles sampling cadence before accuracy, relaxes the tracking accuracy gate whenever it does coarsen accuracy, and drops to zero on a charger; adaptive sampling may only delay a fix, with anything clearing the un-inflated distanceFilter admitted after 60 s — which leaves a genuinely parked device silent, since its jitter never clears that filter; and the implied-speed guard measures from the last fix the processor observed rather than the last one it accepted, which turns that same 8.4 m/s jump into 51 m/s. When nothing has been observed at all the anchor is re-seeded: the position is taken, but the span contributes no odometer distance and no derived speed (#393, #394, #395, #396).

FIX: (Android, iOS) a released app can report a stalled location stream. Everything explaining one was logged at debug, which Flutter's default info — and a direct SDK consumer's default off — discards, so the bug report contained none of it; and the rejection line named only a reason and a speed, leaving an 8 m distance gate and an inflated 750 m one indistinguishable in a log. Stalls, recoveries, battery-budget throttle movements, idle-escape admissions and anchor re-seeds now go to the always-on lifecycle channel that bypasses logLevel (the #318 mechanism), staying affordable because all of them are per-session rather than per-fix events. The per-fix rejection line keeps its level and its frequency but now carries the accuracy, the distance moved, the effective gate, the anchor age and the thresholds in force (#397).

FIX: (Dart) the Doctor bug report says which Tracelet produced it. The report opened with a generation timestamp and, optionally, the host app's own version, so triage began by asking — and a report pasted into an issue weeks later could not answer at all. traceletVersion is now exported from package:tracelet and kept in lockstep with the pubspec by the release hook, and the report header carries it. The report also gained a Location stream health section: stalls, recoveries and throttle movements lifted out of the general log, each stall line carrying the rejection histogram, the gate the last fix was measured against, the configured gate beside it and the thresholds in force (#398).

tracelet_doctor

3.8.7

FIX: the bug report names the Tracelet version that produced it, and gained a Location stream health section — stalls, recoveries and battery-budget throttle movements lifted out of the general log, each stall line carrying the rejection histogram, the gate the last fix was measured against, the configured gate beside it and the thresholds in force. These are written on the always-on lifecycle channel, so the section is populated even for an app running at the default logLevel (#397, #398).

tracelet_sync

3.8.7

Version alignment with tracelet 3.8.7.

tracelet_supabase

3.8.7

Version alignment with tracelet 3.8.7.

tracelet_firebase

3.8.7

Version alignment with tracelet 3.8.7.

tracelet_android

3.8.7

FIX: the pinned native SDK carries the pedestrian pace hysteresis, the stationary wake re-arm and the reduced per-fix log volume; no Dart or plugin change.

FIX: the pinned native SDK carries the battery-budget ladder, the adaptive-sampling idle escape and the always-on stream diagnostics (#393–#397); no Dart or plugin change.

tracelet_ios

3.8.7

FIX: the pinned native SDK carries the pedestrian pace hysteresis; no Dart or plugin change.

FIX: the pinned native SDK carries the battery-budget ladder, the adaptive-sampling idle escape and the always-on stream diagnostics (#393–#397); no Dart or plugin change.