charging, battery, performance, caches and battery calibration myths busted

  1. anupritaisno1
    KitKat 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:
    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!"
    "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
    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:
    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
    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.
    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.....


    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/

    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"

    Attached Files:

    Last edited: Aug 1, 2020

  2. anupritaisno1
    KitKat Feb 1, 2019

    Last edited: Jun 21, 2019

  3. alexphl
    Honeycomb Feb 1, 2019

    alexphl , Feb 1, 2019 :
    This shouldn't be in Off Topic, this is more relevant than most threads in the General and Dev sections.

  4. anupritaisno1
    KitKat Feb 1, 2019

    anupritaisno1 , Feb 1, 2019 :
    Now let us talk about how to force the optimisation to occur

    Rooted users: run su -c "cmd package bg-dexopt-job" in a terminal emulator app. The quotes are part of the command so do NOT remove them.

    Non-rooted users: this should work

    Screenshot from 2019-02-01 22-14-35.png

    I believe an image is worth a thousand words

    The command can take anywhere from 20 minutes to 3 hours to complete

    Disconnecting your phone will abort the process

    It is completely safe to interrupt the process

    On non-rooted devices you might see an error like this
    "user 2000 nor current process has Android.permission.Update_Device_Stats"

    The solution? The error is safe to ignore and you don't need to worry. If you're concerned you can run that command a second time and the error should not occur during the second run

    Curious what this command does? Read the code https://android.googlesource.com/platform/frameworks/base.git/ /f7edab63d9358b9a4e0dbec3243f6db9f50a2bbe

    If you have at least 50% of storage free and have lots of time
    adb shell cmd package compile -m everything -f -a
    Be warned that this will compile everything as AOT, potentially using a lot of storage and any benefit from this will only be seen from P onwards

    "cmd package" can be replaced by "pm"
    "pm bg-dexopt-job" is the same as "cmd package bg-dexopt-job" and "pm compile -m everything -f -a" is the same as "cmd package compile -m everything -f -a"
    Last edited: Jun 21, 2019

  5. anupritaisno1
    KitKat Feb 1, 2019

    anupritaisno1 , Feb 1, 2019 :
    It's time for the "btw I use arch" memes

    I was actually unsure where to post this so I posted this in off-topic

    ce_franck and PlabanRoySarkar like this.
  6. camohan
    Moderator Moderator Feb 1, 2019

    camohan , Feb 1, 2019 :
    Thread moved to "Tech section".

    I would personally suggest a tl,dr for not so technically sound guys like me to easily understand and digest.

  7. anupritaisno1
    KitKat Feb 1, 2019

    anupritaisno1 , Feb 1, 2019 :
    added it

  8. anupritaisno1
    KitKat Feb 1, 2019

  9. SoniaB
    Head Moderator; Community Hero 2020 Head Moderator Feb 3, 2019

    SoniaB , Feb 3, 2019 :
    I do not see any reason for the thread to be pinned. Whilst its informative, I do not see why it would need to be pinned.
    Also, you reported this twice to moderation team. Once will suffice [​IMG]
    We work through the reports and so reporting multiple times does not mean your report will be worked on any faster.

  10. G_Àlex_Ribé_Bachiller_Vi
    Donut Feb 3, 2019

    G_Àlex_Ribé_Bachiller_Vi , Feb 3, 2019 :
    So last night I cleared the cache in my 5T, and today i 've been enlightened with this thread and realised the mistake I made!
    So to prevent my phone from lagging,heating up and having poor battery, I need to leave it plugged in this whole night right?
    Will the optimization still happen if the device is in airplane mode?

    Thanks for all the valuable information!

    Bintang12 and BaconBoi like this.
  11. G_Àlex_Ribé_Bachiller_Vi
    Donut Feb 3, 2019

    G_Àlex_Ribé_Bachiller_Vi , Feb 3, 2019 :
    Thank you! I will do so!

    BaconBoi likes this.
  12. anupritaisno1
    KitKat Feb 3, 2019

    anupritaisno1 , Feb 3, 2019 :
    Airplane mode doesn't interfere with the process

    Also read this post:
    Just run adb shell and cmd package bg-dexopt-job and wait and the optimisation finishes for that session

    Remember that android profiles what is slow and only optimises that


  13. TheMystic
    Lollipop Feb 3, 2019

    TheMystic , Feb 3, 2019 :
    We need write-ups like this from people who are technically and technologically sound. But people who qualify, unfortunately, either don't participate or tend to enjoy reading stuff from others who aren't fully informed (understandably because people come from diverse backgrounds and have focus/ experience/ expertise elsewhere). Neither of that helps.

    Having said that, the internet is full of myths and not real facts. That is precisely for the reason mentioned above.

    This is one of those threads that I have bookmarked for reading again and sharing when an opportunity arises.

    Hope you write some more.

  14. TheMystic
    Lollipop Feb 3, 2019

    TheMystic , Feb 3, 2019 :
    There are plenty of reasons to pin it, only if you appreciate the fact that it can clear a lot of misconceptions and outdated troubleshooting steps that are everywhere on the internet.

    OP should, however, edit the composition in a more educative tone.

  15. anupritaisno1
    KitKat Feb 3, 2019

    anupritaisno1 , Feb 3, 2019 :
    If you want to suggest edits/correct information just reply here with the corrections

    Naveen Rayala and BaconBoi like this.
  16. TheMystic
    Lollipop Feb 3, 2019

    TheMystic , Feb 3, 2019 :
    Well, I don’t have technical knowledge, so I would leave it to you and others with technical expertise to edit your composition.

    As with the tone of your composition, I have gone through this thread as well as the ones linked in it (along with some ensuing discussions), and here are some things you should keep in mind:
    1. When you know something really well, many of the seemingly “common sense” stuff aren’t actually common sense. They are still technical in nature and you should use that opportunity to educate people as much as you can.
    2. Accept that people won’t take your word as final. They don’t know you or how much you know. They will disagree, ask questions, put forward contradictory points. These are not meant to question your level of expertise. Be polite.
    3. So called “myths” are not necessarily myths. Much of those are simply outdated methods that are no longer applicable. And people aren’t aware of that for good reason. So keep that in mind.
    4. Clearing cache hasn’t solved a problem. Wrong statement. It has and continues to be a solution for specific problems, under specific circumstances.
    5. There is no manual from Google for many of the most common problems. Probably there cannot be due to countless permutations/ combinations of what could cause a problem. Also the fact that a problem could be both software (which itself has various 3rd party customisations ) and hardware over which Google has no control. So people depend on a Google search for solutions. There are plenty of well known sites that still promote outdated troubleshooting methods and people believe in them. Or may be it is Google to blame as it throws up such outdated articles when doing search.
    6. Dirty flashing a rom again won’t solve a problem due to inbuilt checks that would prevent a rom from booting if there is a problem with installation. Again disagree. I have personally been able to fix app crashes by doing so, and not too long ago. Why it happened or what exactly solved it - I can’t pinpoint it. I can only say what I did and what happened thereafter. I dirty flashed and it fixed it.
    7. It appears to me that much of what you have written assumes an ideal scenario (or scenarios that ‘should’ exist theoretically), and I am tempted to think that you have ignored the fact that there can be unexpected errors, and unexpected scenarios.
    8. Given that you are a developer and have read the Android source code extensively, use it to educate others in a healthy manner, rather than imposing it. There are some, including in this forum, who boast of how much they know or what they have done, but without sharing much details on how they went about it. Surely, it doesn’t help anyone.


    I personally don’t have most of the problems people complain about. Or let’s say I have been able to keep it trouble free for the most part, with whatever little technical knowledge I have.

  17. Loveit
    KitKat Feb 3, 2019

    Loveit , Feb 3, 2019 :
    OMG are you serious. I obviously didn't read this all but my god, the waffle!

  18. Loveit
    KitKat Feb 3, 2019

    Loveit , Feb 3, 2019 :
    Probably should have just ignored because I didn't really read it but the context seems like it could be downsized by about 1/10th

    palc, BaconBoi and shezack like this.
  19. anupritaisno1
    KitKat Feb 3, 2019

    anupritaisno1 , Feb 3, 2019 :
    1) I should keep that in mind
    2) That would be fine if people did their own research. I am yet to see someone like that. All I see is people who quote others here
    3) It is more to do with naming. Had it been named something other than cache users wouldn't have wiped it. The name is a misnomer and the root cause of the confusion
    4) That is because there is nothing you're technically clearing. The only possible case is that an selinux denial is preventing the system from working with cache due to incorrect labelling. In this case however restorecon -Rv should be a better solution because if it's happening to your ART cache it's also happening elsewhere
    5) Google just wants users to use their devices. That's what android was built around but when something is too good it tends to arouse suspicion even if nothing is really wrong with it. Users start reading stuff written by these people who do not know the impact of what they are doing and the more people that believe it the stronger the lie gets
    6) Dirty flashing a ROM doesn't solve issues because most of these users are on a locked bootloader and the system partition is backed by dm-verity (op5 and lower) and avb 2.0 (op6 and newer). AVB will verify the partition underneath the block device and a read operation will only succeed if the verification operation succeeds. If the verification option fails AVB will immediately notify the bootloader and reboot the device. AVB uses cryptographic algorithms that are widely used all over the world for secure communications (SHA256withRSA2048) and claiming that dirty flashing a ROM would work also implies that all the cryptographers who have tried and not been able to break the algorithm have been proven wrong by you. The system is exactly the same before and after the flash making the whole thing useless
    7) Often users try to come up with explanations for what they do not understand and these assumptions might be very well wrong. Sadly the conclusion that they arrive to is something they strongly believe in even if it is wrong
    8) people do not want to be educated. They expect to come to the forum with their issue, get the solution and then walk off. That is not how things work because then they never understand why the issue occurs in the first place and that is important because the solution otherwise becomes an ultimate truth for these people and they just tell everyone to use it
    Last edited: Feb 3, 2019

    sammerasker likes this.
  20. anupritaisno1
    KitKat Feb 3, 2019

    anupritaisno1 , Feb 3, 2019 :
    Well if you have any suggestions just send them here?