[Bug] system_server soft reboot: IllegalStateException in LocationEventLog$AggregateStats — identical trace to #26, still present in v0.1.3

[godadom]

Summary

system_server dies with an unhandled IllegalStateException in
LocationEventLog$AggregateStats.markRequestBackground, causing a soft reboot
(framework restart — the kernel stays up). The stack trace is byte-identical
to the one in #26 apart from vendor line-number offsets, but on completely
different hardware and a different OEM framework, and it still occurs on
v0.1.3, the current release.

#26 was closed without a stated fix and its reporter was on v0.0.8/0.0.9. Filing
separately to establish that the bug is (a) not device- or OEM-specific and
(b) still present in the latest version.

Related: #49 (a separate, reproducible hook bug in the same subsystem on this
device).

Environment

Device	Redmi K90 Pro Max (25102RKBEC, codename myron)
Build	Redmi/myron/myron:16/BP2A.250605.031.A3/OS3.0.306.0.WPMCNXM:user/release-keys
Android	16 (SDK 36), HyperOS 3
XposedFakeLocation	v0.1.3 (versionCode 103)
Root	KernelSU ksud 4.1.3
Xposed	LSPosed v2.1.1 (7790), ZygiskNext 1.4.3
Module scope	System Framework + several apps

The crash

Happened once, ~14 hours into uptime, with the device lightly used but under
moderate load (load average 11.85). Not reproducible on demand.

FATAL EXCEPTION IN SYSTEM PROCESS: android.fg
java.lang.IllegalStateException
	at com.android.internal.util.Preconditions.checkState(Preconditions.java:222)
	at com.android.internal.util.Preconditions.checkState(Preconditions.java:207)
	at com.android.server.location.eventlog.LocationEventLog$AggregateStats.markRequestBackground(LocationEventLog.java:728)
	at com.android.server.location.eventlog.LocationEventLog.logProviderClientBackground(LocationEventLog.java:202)
	at com.android.server.location.provider.LocationProviderManager$Registration.onForegroundChanged(LocationProviderManager.java:776)
	at com.android.server.location.provider.LocationProviderManager.lambda$onAppForegroundChanged$14(LocationProviderManager.java:2749)
	at com.android.server.location.provider.LocationProviderManager$$ExternalSyntheticLambda26.test(D8$$SyntheticClass:0)
	at com.android.server.location.listeners.ListenerMultiplexer.updateRegistrations(ListenerMultiplexer.java:525)
	at com.android.server.location.provider.LocationProviderManager.onAppForegroundChanged(LocationProviderManager.java:2749)
	at com.android.server.location.provider.LocationProviderManager$$ExternalSyntheticLambda11.onAppForegroundChanged(D8$$SyntheticClass:0)
	at com.android.server.location.injector.AppForegroundHelper.notifyAppForeground(AppForegroundHelper.java:71)
	at com.android.server.location.injector.SystemAppForegroundHelper.lambda$onAppForegroundChanged$0(SystemAppForegroundHelper.java:59)
	at com.android.server.location.injector.SystemAppForegroundHelper$$ExternalSyntheticLambda1.run(D8$$SyntheticClass:0)
	at android.os.Handler.handleCallback(Handler.java:1029)
	at android.os.Handler.dispatchMessage(Handler.java:107)
	at android.os.Looper.loopOnce(Looper.java:274)
	at android.os.Looper.loop(Looper.java:369)
	at android.os.HandlerThread.run(HandlerThread.java:85)
	at com.android.server.ServiceThread.run(ServiceThread.java:49)

Confirmed as a framework restart, not a kernel reboot: DropBox recorded
SYSTEM_RESTART (not SYSTEM_BOOT), sys.runtime.reboot.reason.last was
je#system_server#<ts>#unhandled, and /proc/uptime showed the kernel up
continuously for 13h51m across the event. No kernel panic, no pstore record, no
native tombstone.

Ruled out: thermal (status NONE, 36 °C battery, 54–60 °C CPU), battery/power
loss, storage, and native crashes.

Identical to #26 across two unrelated devices

Frame	#26 (Meizu 21 Pro)	Here (Redmi K90 Pro Max)
AggregateStats.markRequestBackground	LocationEventLog.java:728	LocationEventLog.java:728
logProviderClientBackground	LocationEventLog.java:202	LocationEventLog.java:202
Registration.onForegroundChanged	LocationProviderManager.java:668	LocationProviderManager.java:776
ListenerMultiplexer.updateRegistrations	:525	:525
AppForegroundHelper.notifyAppForeground	AppForegroundHelper.java:71	AppForegroundHelper.java:71
SystemAppForegroundHelper.lambda$...$0	SystemAppForegroundHelper.java:59	SystemAppForegroundHelper.java:59

Only LocationProviderManager differs, as expected between vendor framework
builds. Two OEMs, two Android 16 images, same assert, same module.

The #26 reporter also noted the crash was not specific to Douyin and happened
with "all common app I used with location function." That matches here — no
single target app was in use at the moment of my crash.

Proposed mechanism

AggregateStats guards a foreground/background state machine with
Preconditions.checkState, so markRequestBackground throws if the counter is
already in the background state. Counters are keyed by
provider → uid/package[attributionTag] — visible in dumpsys location under
Historical Aggregate Location Provider Data — so a double-mark needs either two
registrations sharing one counter, or a registration whose foreground marker went
stale.

The module produces churn that can strand that marker. From dumpsys location,
it removes and re-adds its registrations within 1 ms, repeatedly:

15:44:57.649  network -registration 10388/com.noobexon.xposedfakelocation/0EE68DF0
15:44:57.649  gps     -registration 10388/com.noobexon.xposedfakelocation/0EE68DF0
15:44:57.650  network +registration 10388/com.noobexon.xposedfakelocation/0EE68DF0   ← 1 ms later
15:44:57.652  gps     +registration 10388/com.noobexon.xposedfakelocation/0EE68DF0

Over a 10-minute sample the module was the second-highest source of location
registration events on the device (14), behind only android itself. If an
app-foreground transition lands inside one of those remove/re-add windows, the
registration is torn down while still marked foreground and rebuilt fresh — so
the next background transition marks background on a counter that already
believes it is in the background. That is exactly the assert that fires.

What I have not proven

Being straightforward about the limits:

• No module frames appear in the fatal stack. It is entirely platform code.
• I could not reproduce on demand; it happened once in ~2 days of uptime.
• I could not capture the crash-time dumpsys location, so I cannot name the
  package whose counter desynced.
• An A/B test (module scoped to System Framework vs not) was inconclusive,
  because the precursor state never occurred in either 10-minute window.

What makes this more than a guess is the cross-device stack match with #26 under
the same module, on unrelated hardware.

Hooks installed into system_server

25 methods on this build, for reference:

LocationProviderManager#onReportLocation
LocationManagerService#{getLastLocation, getCurrentLocation, requestGeofence,
  addGnssMeasurementsListener, addGnssNavigationMessageListener,
  addGnssAntennaInfoListener, registerGnssStatusCallback, registerGnssNmeaCallback}
GnssManagerService#{addGnssMeasurementsListener, addGnssNavigationMessageListener,
  addGnssAntennaInfoListener, registerGnssStatusCallback, registerGnssNmeaCallback}
MiuiBlurLocationManagerImpl#{getBlurryLocation, getBlurryCellLocation,
  getBlurryCellInfos, handleGpsLocationChangedLocked}
SystemServiceManager#loadClassFromLoader          (see #49)
WifiServiceImpl#{getConnectionInfo, getScanResults}
PhoneInterfaceManager#{getAllCellInfo, getCellLocation, getNeighboringCellInfo,
  requestCellInfoUpdateInternal}

Workaround

Un-scoping the module from System Framework in LSPosed (keeping it scoped to
individual target apps) removes all 25 hooks and eliminates the registration
churn from system_server; afterwards the module no longer appears anywhere in
dumpsys location. This disables system-wide spoofing, so it is a mitigation,
not a fix.

Suggested fixes

1. Avoid the remove/re-add cycle when updating the module's own location
   requests — update the existing registration in place, so no window exists in
   which a foreground transition can strand the AggregateStats marker.
2. Consider whether the module needs its own real LocationManager registrations
   inside system_server at all, given it already intercepts the delivery path
   via LocationProviderManager#onReportLocation.
3. If registrations must be recreated, doing so off the android.fg handler, or
   coalescing them, would narrow the race considerably.

I still have full logcat, LSPosed verbose/module logs, and dumpsys location
captures from before and after the crash, and am happy to run further diagnostics
or test a patch.

[Und77c]

Additional reproduction: Android 14 / OUKITEL WP35 / v0.1.4

I can confirm that this failure is still present in XposedFakeLocation v0.1.4 and also affects Android 14. On this device it occurred four times across two days, so this extends the existing reports beyond Android 16.

Environment

Device	OUKITEL WP35 (MediaTek k6835v1_64)
Android	14
Build	OUKITEL/WP35_EEA/WP35:14/UP1A.231005.007/1733833104:user/release-keys
Firmware	OUKITEL_WP35_EEA_V26_20241213
Security patch	2024-11-05
XposedFakeLocation	v0.1.4 (versionCode 104)
Root	Magisk 30.7, Zygisk active
Xposed	LSPosed active

Crash history from DropBox

All timestamps below are local time (UTC+8):

• 2026-09-04 20:15:21 — NullPointerException in Registration.onForegroundChanged
• 2026-09-04 20:35:55 — NullPointerException in Registration.onLocationPermissionsChanged
• 2026-09-04 20:37:39 — NullPointerException in Registration.onForegroundChanged
• 2026-09-05 12:04:57 — the same IllegalStateException reported here

Latest fatal stack:

FATAL EXCEPTION IN SYSTEM PROCESS: android.fg
java.lang.IllegalStateException
    at com.android.internal.util.Preconditions.checkState(Preconditions.java:215)
    at com.android.internal.util.Preconditions.checkState(Preconditions.java:200)
    at com.android.server.location.eventlog.LocationEventLog$AggregateStats.markRequestBackground(LocationEventLog.java:628)
    at com.android.server.location.eventlog.LocationEventLog.logProviderClientBackground(LocationEventLog.java:174)
    at com.android.server.location.provider.LocationProviderManager$Registration.onForegroundChanged(LocationProviderManager.java:626)
    at com.android.server.location.provider.LocationProviderManager.lambda$onAppForegroundChanged$10(LocationProviderManager.java:2479)
    at com.android.server.location.listeners.ListenerMultiplexer.updateRegistrations(ListenerMultiplexer.java:525)
    at com.android.server.location.provider.LocationProviderManager.onAppForegroundChanged(LocationProviderManager.java:2479)
    at com.android.server.location.injector.AppForegroundHelper.notifyAppForeground(AppForegroundHelper.java:71)
    at com.android.server.location.injector.SystemAppForegroundHelper.lambda$onAppForegroundChanged$0(SystemAppForegroundHelper.java:59)
    at android.os.Handler.handleCallback(Handler.java:958)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loopOnce(Looper.java:205)
    at android.os.Looper.loop(Looper.java:294)
    at android.os.HandlerThread.run(HandlerThread.java:67)
    at com.android.server.ServiceThread.run(ServiceThread.java:46)

Confirmed soft reboot

This was a framework restart, not a kernel reboot:

• Kernel uptime was about 4 days 9 hours after the latest incident.
• The replacement system_server/zygote processes had been running only 10 hours 50 minutes, matching the 12:04 crash.
• DropBox recorded SYSTEM_RESTART at 12:05:38 and no SYSTEM_BOOT entry.
• The boot-reason history still points to the earlier normal user-requested reboot on 2026-09-01, not this incident.

After the restart, dumpsys location still showed registrations owned by com.noobexon.xposedfakelocation. No device serial number, IP address, or precise location is included here.

This seems to support the proposed foreground/background aggregate-state desynchronization. The repeated NPE variants in the same LocationProviderManager.updateRegistrations path may be another manifestation of the same registration churn/race. I can collect additional ADB diagnostics or test a patch if needed.