hemlockiv This way of doing it is more secure than the alternative. It also makes apps faster when you're actually using them.
Optimizing Apps during update takes very long time
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
- Edited
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.
- Edited
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.
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
I understand. Thanks for the insight.
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.
I have 280 apps on a Pixel 7. App optimization has taken 45 min for both A14 updates.
- Edited
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.
eatinggrumble84 414 apps here on Pixel 6 Pro. Every update since A14 takes 50-60 minutes.
The developers are aware of the issue. It sounds as if it will take a while to fix - personally I wouldn't be surprised if it persisted throughout October.
Please note that I don't speak for the GrapheneOS project.
pixel 7 pro 249apps 30+ min .....
two days in a row this happened to me.. i'm afraid my phone will die on the battery, then it will be unusable for 40 minutes...
I do not know if this will work for everyone but i find the reason it takes so long is the phone is overheating and throttling down. When i placed the phone against a cold object the optimization was much quicker.
6 days later
This is resolved now:
Huge. Thanks to the devs.
a month later
efall yeah same here. I have pixel 7 but if it does and I charge with my portable charger and it's dead for 40+ min i can't get home 💀