As it says on the tin, if you're reading this you've probably encountered a bootloop on your device with the notification "system_server has crashed" stacking repeatedly across reboots. From what I've read and experience, this generally renders your device basically unusable since you'll get maybe 10-20 seconds of functionality before the device reboots (and indeed in my case, on successive reboots I got even less and less time to the point that I was barely able to enter my pin before the device crashed).

Now, not every bootloop caused by system_server crashing is caused by this specific issue, so to be unambiguous I'll add the call stack produced by this crash. If you do indeed have this particular issue, your own call stack (which you can see by hitting the notification, if you can get into the os for long enough) should look something like this:

type: crash
flags: dev options enabled

SystemUptimeMs: 461852
Process: system_server
Timestamp: 2025-09-25 20:02:39.400-0600
Build: google/cheetah/cheetah:16/BP2A.250805.005/2025091900:user/release-keys
Crash-Handler: com.android.internal.os.RuntimeInit$KillApplicationHandler
Loading-Progress: 1.0
Dropped-Count: 0

java.lang.OutOfMemoryError: Failed to allocate a 40 byte allocation with 3353488 free bytes and 3274KB until OOM, target footprint 536870912, growth limit 536870912; giving up on allocation because <1% of heap free after GC.
at com.android.server.usage.IntervalStats.deobfuscateEvents(IntervalStats.java:592)
at com.android.server.usage.IntervalStats.deobfuscateData(IntervalStats.java:615)
at com.android.server.usage.UsageStatsDatabase.readLocked(UsageStatsDatabase.java:1176)
at com.android.server.usage.UsageStatsDatabase.readLocked(UsageStatsDatabase.java:1126)
at com.android.server.usage.UsageStatsDatabase.readLocked(UsageStatsDatabase.java:1108)
at com.android.server.usage.UsageStatsDatabase.getLatestUsageStats(UsageStatsDatabase.java:762)
at com.android.server.usage.UserUsageStatsService.loadActiveStats(UserUsageStatsService.java:923)
at com.android.server.usage.UserUsageStatsService.rolloverStats(UserUsageStatsService.java:874)
at com.android.server.usage.UserUsageStatsService.reportEvent(UserUsageStatsService.java:317)
at com.android.server.usage.UsageStatsService.reportEvent(UsageStatsService.java:1295)
at com.android.server.usage.UsageStatsService.onUserUnlocked(UsageStatsService.java:562)
at com.android.server.usage.UsageStatsService.-$$Nest$monUserUnlocked(UsageStatsService.java:0)
at com.android.server.usage.UsageStatsService$H.handleMessage(UsageStatsService.java:2162)
at android.os.Handler.dispatchMessage(Handler.java:110)
at android.os.Looper.loopOnce(Looper.java:248)
at android.os.Looper.loop(Looper.java:338)
at android.os.HandlerThread.run(HandlerThread.java:85)
at com.android.server.ServiceThread.run(ServiceThread.java:49)

This particular issue has apparently affected different Pixel models running different builds because as far I can tell, this isn't actually an issue with GrapheneOS at all but rather one it has inherited from stock Android. But enough burying the lede here- how do you fix it?

Set your clock forward by a couple of years.

This solution comes from https://github.com/GrapheneOS/os-issue-tracker/issues/5590, where a user who had experienced the same issue noted that after 2-3 weeks, the issue resolved itself. When another user by the name of boomboompsh experienced the same issue, instead of waiting they just manually set the clock forward, which achieved the same effect. I'm not going to pretend to know exactly why this works, but another user in this thread speculates that this occurs due to a corrupted entry in usage-stats database which the OS is unable to parse. Instead of skipping it, the OS repeatedly tries parsing the same entry in an infinite loop which quickly eats up all of your memory and crashes the device. Setting the clock to the future makes it so that whatever entry causing the issue is old enough that the OS does not attempt to parse it, resolving the issue.

I'll also note here that your mileage may vary with this technique- the initial user who tried it said they got it to work by setting their clock one year to the future, but the next user said they needed to set it five years to achieve the same effect. I myself didn't get it to work until I had set it forward eight years, so if it doesn't work for you at first, just keep going.

You might also wonder how exactly you are supposed to do this if your device is trapped in a bootloop, to which my primary advice is: be fast. No but for real, it did dawn on me even as I got this to work that if the bootloop was even just a little more aggressive with the pace that it crashed my device, or if my touchscreen was damaged or sluggish for some reason, then this would be borderline impossible to pull off. I myself actually only got the clock far enough over several hard shutdown's and reboots, since it seemed that coming out of a shutdown gave me just a few more seconds in the OS, and even with that small boost I still didn't have enough time to set the date forward far enough in one go. Either way, I would advise just trying to do it until you know exactly where you have to tap and navigate in settings so that you don't waste even a second.

Also, while this is little tangential I'll add that I was running 2025121701 stable when the issue occurred, and tried sideloading 2025122500 beta in the course of trouble shooting. This didn't solve the issue, but it did seem to give me just a smidge more time in the OS before the crash occurred, which may have made the overall process of quickly navigating through my settings to set the date a little easier. If you really find yourself unable to get into your settings long enough to set the date though, you could try setting them via adb. I didn't try this myself, but it should be possible, here an article that should explain how to do it https://www.repeato.app/setting-date-and-time-on-android-using-adb-shell/

Finally I'll leave a link to the original discussion I joined where this solution was brought to me. Big thanks to @other8026 for linking the github issue with the ultimate solution, and @de0u and @Novalissoide for offering help as well.

https://discuss.grapheneos.org/d/19140-system-server-crash-leading-to-recurring-reboots