The spec already includes a determinate progress bar when installing system updates. Unfortunately, this isn't implemented yet. <https://wiki.ubuntu.com/SoftwareUpdates#installing-mobile-system>
According to bug 1359344, the update itself happens after the restart. So if the precompilation happens after the restart too, that would be fine. If the precompilation happens before the restart, that would be a bit worse, but not terrible: the progress bar could advance from 0 to 40% (for example) for the precompilation, then the device could restart, then (assuming that the restart took 5% of the time) the progress bar could reappear, advancing from 45% to 100%. You wouldn't be able to do anything else during the installation, so that the device restarted in the middle would be merely an implementation detail. That disappearance and reappearance of the progress bar would be worthwhile if it allowed for faster updates overall: for example, if the precompilation could begin, or even complete, before the rest of the system image downloaded or before you decided that now was a good time to restart. So to design this, I need the answers to three questions: A. Is it practical to use the device while precompilation is happening in the background? B. What drawbacks, if any, are there from using the device after precompilation finishes, but before the device restarts? C. When recompilation is required, what proportion of overall update installation time, on average, is taken up by (i) the precompilation (ii) the restart (iii) the flashing (iv) anything else? (Bonus points if you manage to relate (i) to the number or size of the policies.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to click-apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1385410 Title: [system updates] hook into system-image updates to precompile policy prior to reboot Status in Ubuntu UX bugs: Triaged Status in click-apparmor package in Ubuntu: Confirmed Status in unity8 package in Ubuntu: New Bug description: Occasionally users will receive and OTA update that requires apparmor policy to be recompiled. Recompiling apparmor policy can take quite a bit of time (minutes) depending on how many applications the user has installed. While this is only expected to happen on major OTA OS upgrades (eg, 14.10 to 15.04), it is possible it could happen at other times. This would improve the user experience for developers considerably since policy recompiles can be relatively frequent when running the development release. To improve the user experience, we should detect and recompile apparmor profiles prior to reboot but after system-image updates has downloaded the new update. This always for the possibility of using a progress meter when compiling policy (which we currently cannot). Needs design input for when to do it and how the progress meter should look. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-ux/+bug/1385410/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
