Infinite boot loop after battery drain

Matze

Hey Guys,
got the boot loop Problem recently. Fortunately, I got a Power Meter between the USB-C charger and the wall outlet. So I can see how much Power the phone is charging from USB-C. I Think many people can profit from my findings.

The Phone is taking round about 8 to 9 Watts in the power off state and the boot loader screen ("Your device has loaded a different operating Systems")
As soon as the GrapheneOS Screen happened to appear the USB-C power is dropping to zero, which is for me kind of a safety feature, protecting the phone from sideloading any malware during OS boot.
GrapheneOS is booting until the battery dies, which usually is right in the middle of the boot process.
The loop begins from the start at the power off state. The phone waits for a bit of energy loaded into the battery and starts again automatically.

My steps to prevent any recovery mode or other complicated stuff.

Wait until the phone boots from the beginning into the "Different OS Screen"
Push the power button to pause the boot. During that time the battery is loading. It's kind of a fall back voltage and current, so you have to wait maybe 15 to 20 minutes to get a sufficient charge.
When the time is over, push the power button again to resume to the boot loading.
GrapheneOS should load normally without any recovery etc.

Have a nice day.

nashgraph

Matze Your solution should be pinned to the top of the thread or even get a pin in the main section.

Wrangle6600

stfnh This was a solution for me.

Matze Might also be a solution, your mileage may vary.

Phone discharged to 0%, boot looping infinitely as others have described.
There was a failed update.

I have now enabled some settings in the update menu around only downloading updates while charging to hopefully avoid a repeat incident.

I'll post the log here and in a github issue if I can find one.

motmotmot

thure Great tip, worked for me.

After a complete discharge, I plugged in the 8a, to charge overnight, but it kept rebooting and crashing in the process to start all over again. When I disconnected the power, it would stop, but once I inserted the power, it would start the loop again.

Following the instruction to pause the loop and allow it to charge solved the issue.

So far the only glitch I've had with graphen, thanks to the os team for their great work.

DeletedUser433

motmotmot Yea it worked for me too and from what I've heard is an upstream 'feature' and not a bug exclusive to GOS

deP0isd

bntrtm Despite bad luck on SEO, i found this thread when searching for the text after "Overwrite in-progress update?" and read your post after having this exact issue. I've rebooted normally like 20 times, and was now going to sideload uncleanly. While i have a relatively recent backup, it is a ton of pain to recover. I just wanted to say thank you so much for that post.

My 2 cents:

I noticed that the system stays "on" longer after multiple safe-boot-to-unlock-screen-to-crashs, not sure what to make of it.
It took many times for me to actually get it to be healthy-booting again, but I have a ton of apps, so that might have to do with it taking long to optimize them all.
After the successful boot, i had ₅ notifications of "system_server has crashed" by GrapheneOS, and none talking about any update related stuff. 3 contained nothing, 2 had a stacktrace with a java.lang.UnsatisfiedLinkError: dlopen failed: library "libicing.so" not found. Not sure if related?
If upstream (could be, had similar issues with other os vendors), it should be fixed there. Nonetheless, it seems to be a kind-of-security-relevant thing to be able to softbrick a phone by powering it off/on in the right moment, so it might be something where it would make sense to atleast check if it can be patched without horrible maintenance implications.

I understand about the system dying w/o power (would appreciate a patch to make phone work w/o power though). But shouldnt A/B be able to protect against this?
+Is there (or can we maybe have) an option to not get the slot changed/update applied when the power is below 10% (like with download/install udpate)?
+Is there (or can we maybe have) a way to make the Settings > System > System update > Automatic reboot a bit more user friendly, as in: if no auto restart is active, i want to apply the update soon, but not now (=busy workday) but at 3 am? I think the notification has this option next to the instant restart option on some devices.

de0u

deP0isd I understand about the system dying w/o power (would appreciate a patch to make phone work w/o power though). But shouldnt A/B be able to protect against this?

The short answer is that A/B is great at protecting against corruption of the system partition, but provides no protection against corruption of the user data partition. Among other things, that's where the non-built-in apps are.

de0u

deP0isd Can you post the crash dumps you got?

deP0isd

de0u That makes total sense, but then i dont understand how - in a perfect world with no limitations for an os dev - a crash should be able to occur caused by errors in user space. Is this reported at AOSP level (where is suspect the root cause)?

Anyways, the stack:

type: crash
flags: dev options enabled

SystemUptimeMs: 31627
Process: system_server
Timestamp: 2025-09-14 09:41:10.090+0200
Build: google/husky/husky:16/BP2A.250805.005/2025091000:user/release-keys
Crash-Handler: com.android.internal.os.RuntimeInit$KillApplicationHandler
Loading-Progress: 1.0
Dropped-Count: 0

java.lang.UnsatisfiedLinkError: dlopen failed: library "libicing.so" not found
	at java.lang.Runtime.loadLibrary0(Runtime.java:1090)
	at java.lang.Runtime.loadLibrary0(Runtime.java:1012)
	at java.lang.System.loadLibrary(System.java:1765)
	at com.google.android.icing.IcingLibraryLoader.loadLibrary(IcingLibraryLoader.java:9)
	at com.google.android.icing.IcingSearchEngineImpl.<clinit>(IcingSearchEngineImpl.java:41)
	at com.google.android.icing.IcingSearchEngine.<init>(IcingSearchEngine.java:78)
	at com.android.server.appsearch.external.localstorage.AppSearchImpl.<init>(AppSearchImpl.java:340)
	at com.android.server.appsearch.external.localstorage.AppSearchImpl.create(AppSearchImpl.java:298)
	at com.android.server.appsearch.AppSearchUserInstanceManager.createUserInstance(AppSearchUserInstanceManager.java:250)
	at com.android.server.appsearch.AppSearchUserInstanceManager.getOrCreateUserInstance(AppSearchUserInstanceManager.java:113)
	at com.android.server.appsearch.AppSearchManagerService.lambda$onUserUnlocking$1(AppSearchManagerService.java:358)
	at com.android.server.appsearch.AppSearchManagerService.$r8$lambda$7li-QUZvrsDk5ZvsFzpgCXuGV7s(AppSearchManagerService.java:0)
	at com.android.server.appsearch.AppSearchManagerService$$ExternalSyntheticLambda3.run(R8$$SyntheticClass:0)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:651)
	at java.lang.Thread.run(Thread.java:1119)

Possibly the same as in: https://github.com/GrapheneOS/os-issue-tracker/issues/5257

Btw: Simple workarounds seems to suggest there are (alternative) causes that are a) a software error instead, b) a hardware error that the software can easily self-heal. Not to diminish the great, free help provided by absolute experts - quite contrary - but i find it very dangerous in which wording things are often declared a hardware error.
Many people are gonna read it and - due to the high level of knowledge around the people in this forums - assume their phone is softbricked, even if their case is different. It makes people reset their data w/o investing time to find the root cause and possibly loosing data since last backup, so maybe we need a disclaimer to prevent this, if possible.

de0u

deP0isd Thanks for posting the crash dump and the link to the existing issue.

For whatever it might be worth, here is what I think I understand.

The error about libicing.so not being found means that a filesystem has lost the file. Looking at a build tree, libicing.so appears to be part of an APEX module called com.android.appsearch. My understanding is that in Google's stock OS the initial version of each APEX is part of the system partition, but APEX modules can receive updates into the data partition which are mounted into /system as overlays (source). At least initially I don't think GrapheneOS used the same flow for APEX modules, so it may be the case that they all end up in /data.
The question then is why that file "got lost" (causing system_server to crash). It is absolutely the case that a hardware failure in the flash storage can have this result, and in cases with certain other symptoms that is a good guess. When there has been a flash storage failure, sometimes a "factory reset" (wiping the data partition) can enable the system to run for a while by skipping the bad area of the flash storage, but it is not at all rare for Recovery to be unbootable or for the "factory reset" to fail; this is reasonable evidence of a flash failure.
However, it is also clear that in some circumstances running the battery flat can result in filesystem corruption. In theory this shouldn't happen, but there are at least two ways that it could. One would be a bug in the filesystem code (e.g., f2fs). Another would be misbehavior of the flash storage controller, which should not start a write operation unless there is enough power to finish it.
It seems to be the case that sometimes rebooting a lot can revive a corrupted filesystem. In theory this shouldn't happen: there is some filesystem healing code that can fix some problems, but it should be running on every boot and thus it shouldn't take 20 boots or whatever to bring the filesystem back.
Whether there is a bug in some of the Android filesystem code (which has happened before, so it's very plausible) or in the flash controller (also completely plausible), or both, is very difficult to determine based on reports over the Internet. It would be great if the problem(s) could be reproduced by a developer on a machine with a debug build, but that hasn't happened yet.

Overall:

Very similar symptoms can result from hardware failures (which absolutely happen and "should" cause destruction) and from filesystem corruption related to sudden power loss (which "should not" cause destruction but which may be doing so),
Sometimes the pattern of onset of a specific device's problem may suggest hardware failure, sometimes it's hard to tell,
If it's "merely" a filesystem problem, rebooting a lot may help (though in a sense it shouldn't, and maybe it won't),
If it's a serious hardware failure, rebooting alone is genuinely unlikely to help.

deP0isd I dont understand how - in a perfect world with no limitations for an os dev - a crash should be able to occur caused by errors in user space.

In modern systems lots of critical functions happen in user space. Filesystem healing programs (beyond rolling a journal forward) are all in user space. The unlock screen is in user space, and so is the window system. Android systems expect a lot of things in user space to work or else booting won't happen. To be clear, this crash almost certainly wasn't caused by something bad that user space did; it was almost certainly caused by either a filesystem bug or a flash-controller bug (or maybe both).

Does that help?

springspring

Hi everyone, I had a similar issue, though after several reboot loops, the phone simply won't start at all even when plugged in, would it be charging if plugged in?

EDIT: Managed to get it restarted into the fastboot mode, presumably leave it charging for about 15-20 mins and restart?

boards_of_canada33

For future reference, I just resolved this by the above suggestion of pressing power at first screen to pause boot, then resuming like 10 min later. When resuming, it was at 1% power (despite having it plugged in for the past hour, though it was boot-looping).

rylabs

stfnh Ran into this same issue yesterday on a Pixel 8 after the battery discharged to 0%. Here is my fix, hope it helps:

Plug in phone to charge
Shutoff phone
Turn on phone
Pause boot at alternate os warning screen by tapping the power button and wait 10-15 minutes.
Resume boot by tapping the power button.
On the Google logo hold volume down, keep holding for about a minute into the GrapheneOS logo. Wait for it to enter safe mode.
Unlock and in settings check for updates, install them, and wait until verification completes.
Reboot phone, repeat steps 3 through 5.
Wait for it to say update applied.
Reboot phone

Should boot regularly.

Only oddities I noticed so far are my contacts were erased and a home screen widget was removed.

Thanks for this. Ran into exactly this issue this morning on a Pixel 9, and this worked on the first run. Just one boot into safe mode boot to let the failed update restart, and then all good on the next boot into normal mode

pulec

I had this as well. I am not sure if there was an OS update pending, probably not, since a few days ago.

Charged the phone to 91%, saw 500ms of the lock screen, and it kept rebooting, booting to fastmode and restarting didn't work either. But pausing the boot just for a minute or so helped somehow.

I won't try to replicate this.

Asus-support-agent

Pardo I recently had this issue but the fix was stupidly simple just press the power button to pause the fast boot then resume after 30 seconds I was charging with the same charger for over 2 hours i tested unplugging it and waiting like 5 min 3 times during that period 😵

Fix pause fast boot for 30 seconds =)

Fix for android if the fast boot fails 2 times wait until the battery is charged to 3℅ it's as "shrimple" as that

BadRobot

Over the last year I've had a few experiences where 7a's and 8a's have gone into boot loops. The general pattern appeared to be extreme depletion of the battery and when I did manage to the device back to a normal boot, there was evidence each time that some sort of update was/is in progress.

The most recent occasion was in the last days. The device, at a momentary glance in the main screen was showing 100%. But the boot looping continued. Attempted pauses at boot as some have suggested in this forum. I selected recovery, trying to reboot all sorts but was then continually arriving at the inebriated green android with its chest open.

Here's my mistake, when you get to the robot, with the "no command" don't assume it's a failed state and attempt to reboot yet again. No. no. Put the phone down and leave it charging for a good long while. Let it do what it's got to do and it will (likely) restart.

Best

« Previous Page