• GeneralPixel 8a

  • Why does Graphene optimize apps so often? (or: why does stock android not)

Afaik, App optimization aka ahead-of-time-compilation is required whenever the Android Java Runtime ART ist updated. For stock Android, this does happen in major upgrades only usually.

I wonder if graphene OS does really have patches to ART in (maybe almost?) every update, as it seems to me like every single update does trigger it.

It does not annoy me a lot, but I'm curious whether stock OS do skip so menu security relevant updates of ART - since ART is the heart of app sandboxing, isn't it? ...

Stock Pixel OS rebuild apps in background, before the final restart.
IIRC this is a unique Pixel feature, all other Android rebuild apps after restart.
GrapheneOS also updates more frequently, patches are released ASAP.

    Cp831jcjeOqj
    Thanks, but the question was not before or after restart, but why it is required in every update and not only for major upgrades.

    As apps can be used during the optimization it does not really matter when this is done.

        Any hints making it faster? i tried putting phone on charger or keep it unlocked, did not seem to help much. 90 apps to optimize takes around 5h on pixel 7a

          ToolTimeTim7 I assume if any of the libraries that any of the apps might use has changed, the optimization is triggered. If only a kernel driver changes, there is no reason to do it, IMHO.

            andrej567 In Pixel 8a it took only a few minutes. Interestingly The number of apps optimized is lower than the number shown by settings - apps :D

                ToolTimeTim7 Sometimes I update before going to sleep. Wake up in the morning and there are 15 apps left. Today it took less than one hour. I was walking, maybe waking up sensors, fooling the process scheduler to keep the optimization process on (???)

                  Maybe you find these posts helpful:

                  GrapheneOS uses ahead-of-time compilation instead of just-in-time compilation the Finalizing step of the update process is supposed to compile apps you've installed and non-pre-compiled OS components (which are rare and have to do with upstream regressions in AOT precompilation support) but it regressed upstream and doesn't fully do it so we re-enabled the UI for showing users apps are being recompiled on first boot of a new OS version / after factory reset.

                  source: https://discuss.grapheneos.org/d/2684-optimizing-apps-during-update-takes-very-long-time/2

                  This way of doing it is more secure than the alternative. It also makes apps faster when you're actually using them.

                  source: https://discuss.grapheneos.org/d/2684-optimizing-apps-during-update-takes-very-long-time/6

                    Murcielago Completely agree and understand, i am just wondering if there is some user action that makes the process significantly faster. it is for sure not about cpu power, there is a lot of it, its about prioritizing the process by process scheduler. It appears it can be set either to very low prio or to sleep

                      5 days later

                      Murcielago Well, this dies not really answer the key questions.
                      It just vaguely states that it is more secure und faster, but it does not explain why.
                      Afaik aosp, stock etc also do ahead-of-time, but only on major Upgrades. Question is: why is it useful to do this every time?
                      If it is, I`d like to understand. If it is not, it would help people to do this only when it is useful, as there seem to be Quite a bunch of usere where this takes very long. (For me it did not yet)

                          ToolTimeTim7 Afaik aosp, stock etc also do ahead-of-time, but only on major Upgrades. Question is: why is it useful to do this every time?

                          As clearly evidenced in the threads reporting on leaked Cellbrite documentation, GrapheneOS is more secure than Google's stock Pixel OS. So expecting GrapheneOS to do (or not do) things the same way as the stock OS is somewhat contradictory.

                          As another example, the GrapheneOS memory allocator paves over memory more often than the allocator on the stock OS.

                          I don't know exactly why GrapheneOS recompiles applications on every update. But I can readily imagine that somebody inside Google might have figured that recompiling less often would be a better user experience while being "safe enough". And I can readily imagine that the GrapheneOS authors decided it would be better to be safer instead of "safe enough".

                            ToolTimeTim7 > do this every time
                            Probably it is much faster and easier to do this everytime if any system library changes than analyzing which library version was installed before and which symbols were exported and which app is using which lib and which functions in it.
                            As a non android developer I assume that it could be implemented more effectively but is simply not worth the effort.

                            Updates that were only changing some kernel modules, related to bluetooth or charging did not trigger optimization if i remember correctly.