The Google Pixel 4a’s horrific battery update hides more than we thought

There’s been a lot of talk lately regarding Google’s Battery Performance Program for the Pixel 4a, which, among other things, includes a software update that has a huge impact on its battery life. Many users now consider the phone unusable and are rightfully mad at Google, which hasn’t done a great job communicating why it was suddenly rolling out such an update six years after the device’s release.

A few days ago, a post by Hector Martin (known for his work on Asahi Linux, which brings Linux to newer Macs) shed some light on the update. But we still have loads of unanswered questions, so I decided to investigate it myself and dig deeper into the kernel update.

Exploring the fixes

As revealed in Hector’s post, the Pixel 4a has two different battery variants. While both of them share the same exact specs and are even manufactured by the same company, Sunwooda Electric, they have battery cells (the thing that actually stores the charge) from different vendors. The cells that are affected by Google’s update are from Lishen (LSN), while the good ones are from Amperex Technology Limited (ATL).

The post revealed that Google has reduced the maximum voltage of the LSN batteries down to 3.95 V, from the original 4.45 V. However, this fact is worthy of greater explanation. At a very high level, battery charging works by pushing more electrons into the cell, raising the internal voltage. Using the stored charge basically works in reverse, using the electrons to power whatever components require it and thereby slowly dropping the voltage.

At first glance, this might not seem too bad — shaving 0.5 V off 4.45 V is a mere 11%, but that’s not the end of the story. Lithium-ion batteries, like the one used in the Pixel 4a, are only really unusable in a range of voltages. The bottom limit of that range is called “cutoff voltage.” In the case of the Pixel 4a, this value is 3.3 V.

Doing some simple math, we can see that the usable battery range after the update has dropped from 1.15 V to 0.65 V, a 43% drop! This, however, still isn’t the full picture, as batteries are not really linear as you can see above, but we can just check the original voltage-to-percentage curve from the software to see what 3.95 V corresponds to. As it turns out, that value corresponds to 56% of the charge before the update (which is also marked on the image above)!

The kernel patch Google applied also changes the charging profile on affected units. While Hector’s post mentions the value Google used for capacity — 1,540 mAh — I wouldn’t necessarily trust it to be entirely accurate, as all the changes in the update seem extremely rushed, and this value is exclusively used to calculate charging speeds anyway.

The more important thing here is the charging speed reduction. Li-ion batteries are usually charged at a current defined by a “C” value. For example, 1C charging on a 5,000mAh battery would mean 5,000mA of current flowing into the battery.

Google’s original charging profile allowed up to 1C of current (depending on the conditions), which would be 3,080mA. After the change, this value is halved to 1,540 mA, which directly translates to the same charging speed decrease (now 0.5C).

Interestingly, Google also added a check for ATL cells — if they exceed 800 cycles, a health issue will be reported (and indicated in Android as a generic notification), but it won’t trigger the same mitigations.

While the update does not make any other changes to the battery on the kernel level, there is more going on on the Android side. The most obvious is that the user is notified about the replacement program with a notification and a tip in settings. Additionally, while charging, the battery icon is replaced by one with an exclamation mark.

As in turns out, the source code of the Android part of this special build has been uploaded, so it’s easy to find other things that changed. A quick look at all the commits shows they all have one thing in common — they do more than their titles suggest, and the context they provide for the changes is minimal.

There are two other major functional changes for the affected devices. First, the battery charge ETA is disabled, which seems to be because the AI models used to power the feature were never updated for the new reduced capacity. Not only that, but Adaptive Charging, the feature meant to extend the life of batteries by learning your habits and slowing down charging when possible, is also disabled for a similar reason.

Other than that, Google seems to have blocked the “show percentage in status bar” option at the settings level, but this doesn’t stop users who already had it on from using it. The intention might have been to hide the incorrect percentage on affected devices, but as with the other changes, the underlying charging curves were never properly updated.

We already know what changes were included in the update, but there’s still more context to be uncovered. As it turns out, the build was marked as an Emergency Maintenance Release (EMR) — a special type of build that doesn’t have to go through all the usual certification steps.

Google has also built the kernel without its usual automation — the whole process was done on a developer’s machine. This is also likely the reason the kernel source has only been released almost a month after the update went live.

Interested in the unusual circumstances of this build, I reached out to a source inside Google. Unfortunately, even the bug tracker entry that was mentioned in the open-source changes in this build has no details filled in besides the title “sunfish [the codename for the Pixel 4a] sunset EMR”.

There’s no way to know exactly what caused Google to release such an overly cautious and rushed update, but we can certainly speculate.

Google is making Pixel 4a phones containing batteries with cells from Lishen basically unusable, and it seems pretty unlikely it would do something like this for a device that was already dead without a really important reason. The clearly rushed nature of the update, plus the fact it’s an EMR, shows Google was rushing to get it out of the door as soon as possible. This definitely suggests there is some deeper reason behind the whole program, and given that Google has also removed all the previous builds from its site, it seems like it might have been a safety issue that triggered the response.

I doubt we’ll ever get an official answer as to what happened — it’s simply not in Google’s best interest to say more than necessary — but it’s pretty evident it’s not nothing, and Google didn’t simply kill the Pixel 4a for no reason.