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 (source: android hardening project/KSPP/linux-hardnened/copperheados) 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 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 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"