I'm on TQ1A.230105.001.A2.2023010300

I first noticed a few weeks ago that during the update, "optimizing Apps" takes a very long time, much longer than it used to. It says I have approximately 300 apps and it takes perhaps 20 minutes to optimize for them.

This used to be a much quicker process. Did something change? Is this expected behavior or no?

    spiral 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.

      a month later

      This might be a silly question, but why do apps have to be recompiled with every system update? This isn't something I've seen other (stock) OSes do, unless they do or completely silently, in which case itwould be nice if Graphene did that too...

        8 days later

        matchboxbananasynergy I like fast and secure apps. I wish Graphene could use the A/B update partition to optimize the apps. It might require an extra reboot during the update process, but on the bright side it would be completely silent and wouldn't make the phone busy for a long time.

        Alternatively, let users delay and then manually start the app optimization process, so we could choose to let it run overnight.

        8 months later

        matchboxbananasynergy but this is only since the last 2 updates, i tink it was the 10.October the first time.
        it took me a few days ago 30 minutes and now I'm waiting again 10 minutes.

        before that, the optimization was finished within a few seconds at most minutes.

        Since Android 14 update,optimizing apps takes several hours after each update (376 apps)

          @Tealk @kabob The initial Android 14 update taking a long time is expected, however, the fact that it does so on subsequent updates is a regression introduced upstream by Android 14.

          The team is aware and is tracking the issue here, labeled as max priority:

          https://github.com/GrapheneOS/os-issue-tracker/issues/2515

          We are currently dealing with resolving a lot of upstream issues to ensure that everything is smooth for everyone, so I appreciate your patience in the meantime.

            matchboxbananasynergy

            Perhaps the option could be added to schedule a reboot (after downloading latest update) for a specific time.

            If the phone could be scheduled to reboot at say, 3am, long app optimization time might not be as big of a deal to most people.

              spiral Currently, the default is that the automatic reboot opton in the updater app is disabled by default.

              Therefore, the option to update after an update completes is 100% manual.

              Features like that for the updater might be nice, but they would have to be developed very carefully, as the updater working 100% of the time with zero exceptions is critical (think of bug breaking updates and people don't realize) which is why it's mostly left untouched. Not something that's being ruled out, but must be handled with care.

                kabob 376 apps?! Wow.. It takes my phone at right about 10 minutes to optimize all 170 apps since A14. I'm not sure why it would take you hours. P7Pro here

                  GrouchyGrape I have around 256. It definitely takes right at an hour for me. Really kills the battery, and the phone gets quite hot. Pixel 6 Pro.

                    matchboxbananasynergy We are currently dealing with resolving a lot [emphasis mine] of upstream issues to ensure that everything is smooth for everyone, so I appreciate your patience in the meantime.

                    This situation shows why project people, need to stop criticizing users who wish to not update automatically, but instead want to ensure that updates are reliably defect-free before rebooting an update that cannot be rolled back. Updating is a user policy decision, equal to (not) running Play Store components as a user policy and a user threat model decision.

                    I am unfamiliar with GrapheneOS's automated test suite and checklist before release. Is there a place I can find that, and maybe even contribute? All the descriptions of release testing I have seen only seem to refer to something that sounds rather ad-hoc. What am I missing?

                    As a GrapheneOS donor I dislike the repeated finger pointing at and blaming of "upstream". The use of AOSP was a deliberate and fundamental/core choice for GrapheneOS base. It is GrapheneOS, not AOSP which supposedly tests the whole package, proceeding through Alpha-Beta-Final release phases. Own the decision and the release software please. I don't see Linux distros repeatedly blaming upstream for defects in software they release, nor should it be that way. Accept responsibility as well as deserved accolades.

                    If am personally glad to wait patiently until I feel a release which I cannot uninstall will not break my daily use phone, and support getting it right rather than rushing defects out the door. Thanks for explaining where you're at.

                      ve3jlg I don't see Linux distros repeatedly blaming upstream for defects in software they release, nor should it be that way.

                      Upstream bugs are frequently mentioned on bug trackers. I've seen them mentioned on bug trackers for Ubuntu, Debian, Fedora, Qubes OS, and other software projects. Maybe you're not seeing them because you don't actually spend time in areas they'd be reported? 😂

                      414 apps here on Pixel 6 Pro. Every update since A14 takes 50-60 minutes. Currently on app 65 of 414 after 15 minutes with 2023101300....

                      This really sucks if every update going forward is like this.