Page 1 of 25

200

charging, battery, performance, caches and battery calibration myths busted Feb 1, 2019

anupritaisno1 , Feb 1, 2019 :

Tl;dr charge your phone overnight while it is turned on
stop wiping caches
stop using weird battery calibration methods
If you just want the solution go here: https://forums.oneplus.com/threads/...alibration-myths-busted.993896/#post-19895569

A lot of people have many misconceptions about wiping caches and many other things (I believe you read the title already so you know what this is about)

What makes the thread different from others?
I would like to make this the most complete thread out there that explains everything to the user about what is happening with their device so that I can get full marks for this assignment

Wait what are you talking about? What assignment?

Exactly! I intend to do exactly the opposite of that. Most threads on this forum give too much information to the user with too little explanation of things or give users information about irrelevant but related things
It's as if you have to write some assignment and you're just writing for the sake of writing
That is what I want to avoid here. No "completeness" here

One more thing. Many people claim to understand everything they read on many articles.
I will make one thing clear: If after reading this article you think you have understood every word of it then you understood nothing at all. Go through the article again if that is the case.
This isn't a thread where you will just get the "solution". Think about why the issue occurs and not how to solve it. If you don't want to think that way then leave this thread

So on to the main thing:
What is a cache and why clearing it is my blind faith:
Definition:
According to wikipedia cache is.........
aaaand skip
we are done here. for the definition just go to https://en.wikipedia.org/wiki/Cache_(computing)

Why do you want to clear the cache?
Good question. If any one of these conditions are met you should definitely wipe cache:
1) You are bored and have nothing to do
2) You don't have battery drain but you want it so that you can bug everyone on the forum
3) You have no issues with performance but you want stutters and lags so that you can show others how bad oneplus is
4) You want your device to charge very slowly and be very hot during charging
5) You need a hand warmer
6) You want to wait weeks for the cache to rebuild and during this time period you want to face all the aforementioned issues

If any of these conditions are satisfied yeah sure go wipe the cache

So why is wiping the cache so bad?


image credit: https://www.xda-developers.com/samsung-galaxy-note-5-marshmallow-system-dump-available/


image credit: https://www.recoverandroid-data.com/blog/fix-android-is-starting-optimizing-app-error
note: information given in that link is incorrect

These images seem familiar? I'm sure you've seen them all during a system update
So what is the big deal? Didn't android N remove this?

Wrong. Android N did not remove this screen but merely postponed the task and the deferring of this task is what's causing your battery drain

So is it optimising in the background?
Wrong again. This optimisation is only triggered during a very special case. It is the lack of this optimisation that causes your battery drain

Yes you read it right. The optimisation is not performed because the user does not know how to satisfy the condition required for the optimisation to start

The result:

Image credit: The android soul

notice android system taking 17% just for itself? That is what happens when you do not let this optimisation complete

Now comes my first forum post about this which says (slightly edited and corrected) :

If you've ever owned a device with Android 6 or lower you might be very familiar with the optimising apps screen. Well android 7.0 added a feature to skip that optimisation and use the JIT and the interpreter to optimise apps on the fly. The code running behind the optimising apps screen wasn't removed however, it was instead run when a very specific condition was satisfied (device is plugged in, charging, full battery, turned on, is not in use and is not in motion)

If all these conditions are satisfied the optimisation begins

Now we get to the battery drain part

Before you read further keep this in mind. The optimisation when the phone is idle is handled by AOT. JIT analyses the app and sees which parts will not benefit much from JIT compilation. It creates a profile and passes this profile to AOT for compilation

Remember that AOT can only use the profile. You can't convert JIT to AOT. Some parts of the system benefit more from JIT than AOT and the other way around is true as well

The issue here is: when you do any of the things I said above like a system update, only the JIT is running (along with the interpreter) and it's optimising apps on the fly. If it's going to optimise apps as you open them it's going to have a lot of processing overhead and this is going to heat up your device a lot and drain a lot of battery. AOT is needed as well

The solution: plan when you want to do a system update. You should preferably do the system update 2 hours before you sleep so that you can leave your phone connected to a charger to allow this initial optimisation phase to pass. This will finish AOT optimisation and reduce some battery drain however there will still be a little battery drain which will go away as you use the device

The other advice is to not wipe your cache often
From: https://forums.oneplus.com/threads/closed-battery-performance.911024/#post-19181266

Now there are some people who will ask what the solution is
To those people here is my answer:
1) It is given right there in the quoted message. Read
2) change your approach. read the bold text at the start of this post. do not ask for the solution but try to find out why the issue occurs in the first place

Now the second myth:
"Wiping cache makes my phone boot faster! You are lying!"
Busted:
"When you boot the first time after a system update/cache wipe, the phone analyses which parts of the apps and system are slow to compile directly on the CPU

So it writes out a profile and on the second boot, android picks up this profile and pre-optimises those methods, causing that second boot to take longer

If you wipe caches, you are basically forcing the system to redo this"

Myth: after a system update, old cache is redundant and must be thrown away
Fact: android compares the build fingerprint (build date on custom ROMs) first and if it matches then the old cache is compared against the boot.art in /system and if either of these doesn't match, the entire cache is discarded so manually doing it is no different
From: https://forums.oneplus.com/threads/one-plus-5-lags-after-9-0.974976/page-3#post-19739199

ART already supports garbage collection: https://source.android.com/devices/tech/dalvik/gc-debug

You do not need to wipe cache after a system update at all

In other words wiping cache might make the first boot after wiping it fast but your actual performance and battery life will suffer

Myth: custom ROM developers tell me to wipe cache every time I flash the ROM
Facts:
1) the first way is by not using support commits created for AOSP ROMs like these https://github.com/GlassROM/android...188c7d1#diff-360091044818cdff1986e50afcef960e
These already exist in lineageos and most major ROMs so custom ROMs are able to properly clear caches and manage themselves after a system update
If they are not including these commits because they want to keep the code "clean" it's likely that they actually have no clue of what they are doing

2) they haven't read the code and are shipping ROMs for which the code hasn't been audited by themselves first. Do you really trust such "developers"?

We are done about battery and performance myths

To sum it up:
JIT:
poor performance (but improves over time and on P eventually surpasses AOT)
high resource usage
high power usage
low runtime performance
compiles quickly and can make the system and the apps available to the user faster
easier to exploit compared to AOT
Native code the processor can easily understand
AOT:
very high performance
lower resource usage since a compiler/interpreter is not active during execution
lower power consumption
very high runtime performance
compiles very slowly. some apps like google play services can take anywhere from 20 minutes on an op6 to 45 minutes on an op2
significantly harder to exploit compared to jit. Especially if backing device has verity
ART code. Requires the ART library. Not directly executable on the processor

Order of preference: if JIT, AOT and interpreted code are all available due to multiple optimisations/deoptimisations over time then the order of preference is

JIT>AOT>interpreted code

On a oneplus 3 fully optimised JIT was approximately 1.6 times faster than AOT

To reiterate: charging your phone overnight will finish AOT compilation but JIT compilation happens as you use the device. Charging overnight will improve performance but your battery will improve in a few days as you use the device

Why is JIT insecure?
On a computer system, writable data must never be executable and executable data must never be writable. We call this as a write xor execute or W^X restriction. JIT generates code in RAM and then executes it. This is a W^X violation. If executable data is also writable then an attacker can achieve arbitrary data execution. I encourage you to read chromium bug reports and see how many of those arise due to the JIT alone. JIT must not be considered secure. You can flash a ROM like glassrom that completely disables JIT and relies on AOT and the interpreter alone

Read about it: https://en.m.wikipedia.org/wiki/W^X#:~:text=W^X ("write xor,or executable, but not both

This is the order of security for the curious:
Interpreter > (almost equal) AOT >>> JIT

Sadly the interpreter alone is too slow and AOT is needed for performance. Also since AOT can actually be verified it is far less of a security risk than JIT

why is this optimisation needed in the first place?
app developers cannot optimise their app for every device and every hardware and software combination out there so the obvious solution is to make one app that can run on every device. However it is inefficient as it is not optimised for your cpu and processing is needed so that the cpu can understand it. Interpreting every time you launch an app is slow and puts a lot of load on the cpu. On the other hand AOT compiling everything is a bad idea. AOT is faster as most of the processing part is already complete but JIT is initially slow and becomes faster after some time. Also you will have some code that will benefit from JIT and some that will benefit from AOT. You don't want to AOT compile everything. Too much of anything is bad but too little can be bad too. AOT is ART code and requires android's ART library while JIT is native CPU code. Neither is "better" than the other and both should be balanced. What you should do is just use your device and let it handle the optimisation. Do not interfere by wiping the cache or anything else.

Myth: cache is rebuilt immediately after cleaning
Wrong. cache can take anywhere from a few hours to even a few weeks to regenerate and while it does you will face severe battery drain (remember that while JIT does get faster over time AOT is still required)

Diagnostic test:
I told 2 people to do this
The first was to keep their phone connected to a charger for a week and just leave it idle
The second was told to use his device but was told to charge it to 100% only when turned off and never charge when turned on

You would say the first device would have bad battery? Wrong
The device you think was mistreated actually had the best battery performance and was smooth

To keep the test fair: both devices were used almost the same after the experiment was over
both devices were on wifi and airplane mode was enabled
both devices had the same apps installed
both devices had dm-verity in enforcing mode
both devices were encrypted

The first device:


The second device which you thought will have the best battery life and performance:



do you want to still say wiping cache helps?

now it's time for an official article written by google:

From: https://source.android.com/devices/tech/dalvik/configure

Additional proof: Xposed implements an "optimise apps now" function.
https://www.xda-developers.com/xposed-installer-v3-15-android-oreo-fixes/
Read post 4 for a little more information.

Apart from runtime optimisation android does storage optimisation. Google scheduled the optimisation to occur when the phone was idle on a charger but people did not charge their phones so android skipped storage optimisation
Google finally made the storage optimisation behaviour very aggressive if the device wasn't being charged and left idle https://github.com/LineageOS/android_frameworks_base/commit/7265abe77a76f848a316640b5da106e882bdbc8a
In other words by not charging your phone overnight you're essentially increasing write amplification and killing your storage.

Had enough proof? Oh wait
"Doesn't charging your phone to 100% damage the battery?"
I quote an electrical engineer:

Now my 2 cents:
Let us say the battery does get damaged when you charge to 100%
If the optimisation does not complete you will have terrible battery drain anyway
So what do you get out of this? Peace of mind? Poor performance? if it is as you say then neither way will you get the battery and the poorer performance comes with it as a bonus

Busting cache partition myth:
The cache partition is a partition on android that stores temporary files and these are useless.....

WRONG. COMPLETELY WRONG

What the cache partition really does:
"I have also busted the cache partition

The cache partition is useless while booted to android and selinux blocks android from writing to /cache or even knowing that the cache partition is present

The cache partition is used only when booted to recovery, incremental OTAs will copy the blob (some file or partition) the script is patching, compute the patch on /cache and copy it back to the partition being updated

The reason for doing so is that the cache partition can store the overall progress of the update so by using it if a user interrupts a system upgrade, the bootloader will read the misc partition, boot recovery and recovery will read misc (or /cache. Thanks to @elanglois for the correction!)

The recovery will then read the contents of /cache and reverse the system update because it has the last version of the file that it was patching in case something goes wrong. It will then start the system upgrade again

The cache partition doesn't even store the OTA, the OTA is stored on data. Uncrypt is used to decrypt the blocks of data containing the OTA/if using file based encryption the encryption policy is modified to allow the recovery to read the OTA

Since the cache partition is not encrypted, storing anything here is serious information disclosure and while booted it serves no purpose.... It's just there

A/B partition scheme did not require such a failure recovery mechanism and the cache partition was dropped

The cache partition is always empty. There is nothing to wipe"

Myth: oneplus 6 removed the cache partition so.........
Stop right there. In the absence of a cache partition android's vold uses /data/cache and it is usually bind mounted to /cache

Now some stupid ROMs do place something called an openrecoveryscript in /cache to flash instead of using the misc partition. Stay away from these ROMs. They do not know what they are doing

If a developer/maintainer tells you to wipe caches/clean flash every build then that developer/maintainer/whatever is not really what he claims he is and knows nothing about android

moving on

what is battery calibration?
"Just because the whole world does something does not mean it is right"
It is a stupid myth and I already have a thread about it here: https://forums.oneplus.com/threads/battery-calibration-time-to-destroy-this-age-old-myth.833209/
Debunked by Google engineer: https://www.xda-developers.com/goog...-battery-stats-does-not-improve-battery-life/
https://forum.xda-developers.com/showthread.php?t=1460553

Google play services battery drain:

Google play services is a so-called listener app that delivers notifications via FCM to other apps. In other words if Google play services is using a lot of battery it is likely due to some app either receiving too many notifications or using some other play services API too much

To solve this battery drain you have to find the app that is using Google play services so much. Unfortunately that isn't so easy and finding the app will take a lot of time

There are various stupid hacks to allow doze to optimise Google play services. Do not do these. You will miss important notifications and calls and you're also breaking the doze specification. Apps will no longer work correctly if you do this. Find the app that is using play services and fix that app

"Don't shoot the messenger"