Pixel 7 random crashes on various processes

kohlekind

Hi, I’m looking for some help.

I’m using a Pixel 7. I come from LineageOS where i hav very rare reboots, but after switching to GrapheneOS I’m experiencing frequent crashes (starting directly after installation and keeping strong after 2 month of usage) affecting different processes, leading to various symptoms:

short black screen
“fast reboot” (no yellow bootloader warning shown)
full reboot (Google logo + yellow warning triangle)

The crashes seem completely random:

while the phone is idle
right when opening an app
after using an app for a few minutes

I haven’t found any clear pattern.
I added some crash logs:

I checked some logs and my current suspicion is that this could be related to memory corruption or instability, but I’m not sure.

Are there other likely root causes I should investigate?
If it’s memory-related: are there ways to mitigate or isolate the issue without replacing the device?

I already tried disabling the hardened memory allocator for apps where possible, but this isn’t possible for system apps.

Any additional ideas or debugging approaches would be appreciated.
It doesn’t need to be a perfect fix — reducing crashes significantly would already help.

Thanks!

Logs:

type: crash
flags: dev options enabled
osVersion: google/panther/panther:16/BP4A.251205.006/2026012801:user/release-keys
uid: 1041 (u:r:audioserver:s0)
cmdline: /system/bin/audioserver
processUptime: 0s

signal: 4 (SIGILL), code 1 (ILL_ILLOPC), faultAddr d109c6846308
threadName: audioserver

backtrace:
    /system/lib64/libaudiopolicymanagerdefault.so (android::DeviceVector::operator=(android::DeviceVector&&)+40, pc 3e308)
    /system/lib64/libaudiopolicymanagerdefault.so (android::AudioPolicyManager::checkDeviceMuteStrategies(android::sp<android::AudioOutputDescriptor> const&, android::DeviceVector const&, unsigned int)+804, pc 91594)
    /system/lib64/libaudiopolicymanagerdefault.so (android::AudioPolicyManager::setOutputDevices(char const*, android::sp<android::SwAudioOutputDescriptor> const&, android::DeviceVector const&, bool, int, int*, bool, bool, bool)+1636, pc 301e4)
    /system/lib64/libaudiopolicymanagerdefault.so (android::AudioPolicyManager::onNewAudioModulesAvailableInt(android::DeviceVector*)+4360, pc 97098)
    /system/lib64/libaudiopolicymanagerdefault.so (android::AudioPolicyManager::initialize()+272, pc 99930)
    /system/bin/audioserver (android::createAudioPolicyManager(android::AudioPolicyClientInterface*) (.cfi)+848, pc 1fe750)
    /system/bin/audioserver (android::AudioPolicyService::onFirstRef()+488, pc 2018e8)
    /system/bin/audioserver (main.cfi+632, pc 7d0f8)
    /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+120, pc 6ea38)

type: crash
flags: dev options enabled
osVersion: google/panther/panther:16/BP4A.251205.006/2026012801:user/release-keys
uid: 1002 (u:r:bluetooth:s0)
cmdline: com.android.bluetooth
processUptime: 0s

signal: 11 (SIGSEGV), code 2 (SEGV_ACCERR), faultAddr db9efb9fb750
cause: trying to execute non-executable memory.
threadName: gd_stack_thread

backtrace:
    <anonymous:db9ed78be000> (pc 2413d750)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (bluetooth::hci::HciLayer::impl::send_next_command()+180, pc ad0474)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (void bluetooth::hci::HciLayer::impl::enqueue_command<bluetooth::hci::CommandCompleteView>(std::__1::unique_ptr<bluetooth::hci::CommandBuilder, std::__1::default_delete<bluetooth::hci::CommandBuilder>>, bluetooth::common::ContextualOnceCallback<void (bluetooth::hci::CommandCompleteView)>)+156, pc abacec)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (base::internal::Invoker<base::internal::BindState<void (bluetooth::hci::HciLayer::impl::*)(std::__1::unique_ptr<bluetooth::hci::CommandBuilder, std::__1::default_delete<bluetooth::hci::CommandBuilder>>, bluetooth::common::ContextualOnceCallback<void (bluetooth::hci::CommandCompleteView)>), base::internal::UnretainedWrapper<bluetooth::hci::HciLayer::impl>, std::__1::unique_ptr<bluetooth::hci::CommandBuilder, std::__1::default_delete<bluetooth::hci::CommandBuilder>>, bluetooth::common::ContextualOnceCallback<void (bluetooth::hci::CommandCompleteView)>>, void ()>::RunOnce(base::internal::BindStateBase*)+88, pc ad6c08)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (bluetooth::os::Handler::handle_next_event()+312, pc 9c6ec8)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (bluetooth::os::Reactor::Run()+804, pc 9c8764)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (bluetooth::os::Thread::run(bluetooth::os::Thread::Priority)+276, pc 9c92e4)
    /apex/com.android.bt/lib64/libbluetooth_jni.so (void* std::__1::__thread_proxy[abi:nn210000]<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (bluetooth::os::Thread::*)(bluetooth::os::Thread::Priority), bluetooth::os::Thread*, bluetooth::os::Thread::Priority>>(void*)+68, pc 9c94a4)
    /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*) (.__uniq.67847048707805468364044055584648682506)+236, pc 8e8bc)
    /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64, pc 7f460)

type: crash
flags: dev options enabled

isPrevious: true
Build: google/panther/panther:16/BP4A.251205.006/2026012801:user/release-keys
Hardware: panther
Revision: MP1.0
Bootloader: cloudripper-16.4-14097579
Radio: g5300q-250909-251024-B-14326967,g5300q-250909-251024-B-14326967
Kernel: Linux version 6.1.161-android14-11-g743e821a8fb4 (build-user@build-host) (Android (10087095, +pgo, +bolt, +lto, -mlgo, based on r487747c) clang version 17.0.2 (https://android.googlesource.com/toolchain/llvm-project d9f89f4d16663d5012e5c09495f3b30ece3d2362), LLD 17.0.2) #1 SMP PREEMPT Tue Jan 20 07:48:22 UTC 2026

[[TRUNCATED]]

Boot info:
Last boot reason: kernel_panic

Johnnyloans

kohlekind

Do you let the battery reach 0% and the phone shuts off?

You could try side loading an OTA (Keeps all of your data
https://grapheneos.org/usage#updates-sideloading

Or reflash GOS (deletes all of your data)

It's either a major software issue or hardware issue.

nandohyphen1

kohlekind turn off Developer Options. They aren't recommended and can cause all sorts of weird stuff. Not saying this is the problem, but it very well could be

de0u

kohlekind I checked some logs and my current suspicion is that this could be related to memory corruption or instability, but I’m not sure.

Based on the information provided so far, flaky DRAM does seem like a plausible match for the symptoms.

kohlekind If it’s memory-related: are there ways to mitigate or isolate the issue without replacing the device?

In theory, yes. On some desktop Linux it's possible to identify a bad "spot" in DRAM and tell the kernel not to allocate it. But phones break for all sorts of reasons (battery, screen, buttons, flash storage, SoC), so it's not clear there is a large enough "constituency" for this particular issue to justify the developer load. Plus, memory issues might be due to a particular "spot" in the DRAM, but the problem might be in the memory controller instead.

Overall it might be most productive to replace the device.

kohlekind

Johnnyloans Thanks for the quick answer and the tips.
For the pixel 7 the build 2026032000 is the newest to sideload, but also the one already installed. Would sideloading have any effect in that case?

Is it possible to find out the reason without wiping the phone? I have many crash logs but it is my main phone :)

The battery did not reach 0%.

Johnnyloans

kohlekind

You can sideload the same version or newer just fine. Also, I would only have developer options on momentarily for things like USB debugging then have it off again (can cause random issues). Try to not change settings in there.

Also, don't mess with default/system apps too much (e.g. disabling them or removing permissions)

Those things could cause these issues maybe.

kohlekind Is it possible to find out the reason without wiping the phone? I have many crash logs but it is my main phone :)

Unfortunately, anyone that could MAYBE find out the reason why probably wouldn't take the time to look at them. It'd probably take hours or days.
There's no other fix possible like: just edit this system file. Copy and paste to replace these 3 system files.

Sideload OTA or flash gos will fix that.

Since the issues are with many things on your phone it probably isnt a simple: the software issue is right here.

MrSandman

nandohyphen1
Out of curiosity, how is having developers option enabled can cause any problem? It is just a menu with full of useful things. Unless you change something there, I do not see that can be problematic.

nandohyphen1

MrSandman read this thread. Having Developer Options on (even if you don't use them) allows ADB to be used, so if someone gains access to your device, they could really screw with it. Its also a huge security risk to have Developer Options enabled.

More threads to read;
https://discuss.grapheneos.org/d/24521-wont-boot-after-crashing-after-changing-to-buggy-language-option
https://discuss.grapheneos.org/d/6633-is-developer-options-safe/9

MrSandman

nandohyphen1 Well they can only gain access if you let them. There is an option in the settings what supposed to happen if you connect a USB cable.

Novalissoide

MrSandman What do you mean brick to device?

nandohyphen1 More threads to read;
https://discuss.grapheneos.org/d/24521-wont-boot-after-crashing-after-changing-to-buggy-language-option

It was a case where a user (correction, two users) ended up factory resetting since the Dev options if I remember correctly made available a language setting unsupported by, or at least conflicting with, the lockscreen, and being a secure OS, that's about it if you cannot enter the passphrase.
Important about that case is that the user changed a setting in the normal UI, which was only available if the developer options was on.

Novalissoide

MrSandman option in the settings what supposed to happen if you connect a USB cable

Settings > Security and privacy > Exploit protection > USB-C port

nandohyphen1

MrSandman not saying you shouldn't use it if you don't want to. If you want to use Developer Options, go ahead. Thats fine. I'm only warning you that it decreases your security and random weird things can happen. Only want to save you the trouble of factory resetting, or worse, a bricked device (it can happen).

MrSandman

nandohyphen1 What do you mean brick to device?
Bricking during setting up GrapheneOS or a new OS?
I have seen a video where the guy tried to brick during installing GrapheneOS and it didn't happen and he tried everything.

MetropleX

If you enabled developer options and run into issues, to receive official support you must be able to demonstrate turning them off and only then providing the steps to repeat the problem.

We don't support developer options being enabled on a production device (there are settings such as the terminal for example that can be turned on and persist once dev options are disabled these are fine any that don't persist, these need to be reset to their out of the box state by disabling dev ops) there is a reason they are there and have not been moved into the general user environment.

nandohyphen1

MrSandman yes, you can't brick the device during Installation - I've seen that video too. I never said your device would get bricked either. Just saying there is a chance that potentially it may not boot and go into a bootloop. Not saying it will. Either way, as @MetropleX explained, Developer Options aren't officially supported, which is why they aren't enabled by default. Its your phone. You can decide if you want to use them or not. Just know the risks.

fid03

Novalissoide It was a case where a user (correction, two users) ended up factory resetting since the Dev options if I remember correctly made available a language setting unsupported by, or at least conflicting with, the lockscreen, and being a secure OS, that's about it if you cannot enter the passphrase.
Important about that case is that the user changed a setting in the normal UI, which was only available if the developer options was on.

This was a bug in pseudo-locale usage and it was fixed some months ago.

MrSandman

nandohyphen1 Two things that is really helpful in developer options. Tracking memory usage and running services. Wish this were available outside of that.

Novalissoide

fid03 This was a bug in pseudo-locale usage and it was fixed some months ago.

Yes indeed, but of course it was. But it had to go through soft bricking a number of users before it got fixed, and these users, some of which factory resetted as a result, all of them got that normal UI settings option available since running dev options enabled.

The case is a perfect lesson since it covers several aspects at once;

-Effectively lock-out for users and forcing factory resets.

The normal UI got affected from Developer Options, Rowhammer-like
No changes needed to be done in the Developer options, just them being enabled was enough to cause the thing.

Since new unfinished innovations shows up in the developer options on a recurring basis, and the above thing needed sacrificing users installed OS:es, this may happen again. Who knows what toggling the new 'adjust cursor blink rate'-option conflicts with in the normal UI? Maybe nothing but I don't know, since the above situation was possible even though it should not have been.

fid03

Novalissoide
You don't need to convince me that regular users shouldn't use Developer options, I wasn't arguing against your points.

Novalissoide The normal UI got affected from Developer Options, Rowhammer-like

Novalissoide Maybe nothing but I don't know, since the above situation was possible even though it should not have been.

I'm not really sure what you're trying to say. Pseudo-locales are supposed to show up in the main UI to make it easier for developers to enable. That's not a bug, it's intended: https://developer.android.com/guide/topics/resources/pseudolocales

If you're doing development work that requires Developer options usage then you must be prepared for data loss. If regular users hadn't used Developer options "just for fun" then the bug with pseudo-locales wouldn't have been anything major.

Think it's about time that the warning screen that gets triggered in some cases when enabling Developer options gets displayed every time the user enables the menu, and not just in rare cases.

Novalissoide

fid03 warning screen that gets triggered in some cases when enabling Developer options gets displayed every time the user enables the menu, and not just in rare cases.

Yes, for starters. And since e.g. Safe Mode has a permanent watermark to inform the user that they're running Safe Mode, a warning should be at that same place when running with Dev Ops.

nandohyphen1

Novalissoide a warning should be at that same place when running with Dev Ops.

That would indeed be a great feature. On both GrapheneOS and stock Android