On 22:58, Mon, 14 Apr, Fabrice Desré wrote:
Hi all,The situation with updates on b2g is far from being ideal. On one side, phone manufacturers have little incentive to ship updates for a long time. On the other side, users legitimately expect to be able to get the latest version of the OS for as long as their phone works. I think a reasonable target is to support devices for 2 years. Since there's no hope that we will get partners to provide updates for so long, I've been thinking about what we could do to help users. One piece is to provide an *easy* way to change the update channel. Fortunately that's actually simple: we can just use a web activity that will be provided by the settings or system app, and then do the usual setting -> gecko pref mapping. That would let any 3rd party or mozilla provide gecko+gaia updates without any legal issues. Where things get a bit more complex is when oems use their own update mechanism, removing gecko's standard one. Currently in this case we can't even switch users to another update channel. To fix that, we'll need to provide a proper webapi for updates management instead of our current mess, with pluggable implementations and the ability to switch back to the default one. If we get these 2 parts done, I believe that will move us to a much better position, where we would be able to confidently recommend devices to users as upgradable. And I'm sure communities will provide cyanogenmod-like updates too. Another annoyance is that we still can't update gaia apps without doing a full update. That's pretty ridiculous to not be able to upgrade productivity and media apps for instance. That is blocked on some APIs being only available to certified apps. If we look at the calendar app, only the "settings-read" permission is blocking it from being privileged though. I may be wrong, but I'm less confident in a short term solution here.
There's another issue here that I think is pretty important to address - how can we restrict or permit updates based on the underlying gonk version?
In many cases Mozilla is only going to be able to distribute gecko/gaia updates. If there are gonk changes from the upstream vendor, the user or developer will most likely be responsible for updating those separately.
How will we handle the case where a new gecko update requires the gonk update to happen first? AFAIK, currently there is nothing in the update server, or client-side code to detect this and prevent an incompatible update from being downloaded or applied.
Cheers, Chris
signature.asc
Description: Digital signature
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
