One of the first questions that was asked when talking about releases is would users be able to reset their device to a stock OS image that isnt carrier modified, would that be part of our brand requirements of using "Firefox OS", I believe Tim asked it? The answer was yes, but in practice has been a resounding no
It seems like we want the ability to switch update channels for dogfood devices, also moving as many apps to have uncoupled hosted updates is just a good thing. but bypassing carrier updates seems like it wont work until the above is in place. With the reference device having publically accessible + flashable stock builds we are at least catching up to how open Android is, it would be nice to be better, but I think we should at least get to that point first On 15 April 2014 13:11, Zac Campbell <[email protected]> wrote: > Aside from the technical solution, I think this is quite inherent in the > market itself. > > At the Mozilla Festival last year a group of Mozillians who were keen to > keep old devices alive for various reasons and myself discussed what it > might take. A wide variety of reasons for example it has a nice hardware > feature or they don't want to create landfill. They wanted to keep devices > alive for 2+ years and way longer than what current consumers would > consider the lifespan. I was the only staff member and person that worked > in the industry, the others were all contributors/consumers. > > We discussed both the pace of technical development in the form of > pressure from competitors and consumer criticism which leads the software > developers to push onto the latest driver versions and hardware and leave > the old ones behind. This has led even us to have hundreds of Otoro, Unagi > and Leo paperweights. > > We also discussed the financial model of selling mobile phones and that > the financial income is not tied to the life of the phone. It is only tied > to the life of the user's SIM card by the contract. There's no financial > incentive to keep pushing updates any more than is needed to not piss > people off. Even then it's probably only a minority of customers actively > pursuing updates. > > If the financial model was tied to the life of the phone then there would > be incentive for the carriers to push updates out more frequently, to keep > that phone alive for longer. It might even put pressure on all parties to > streamline and cheapen the process of certifying and pushing updates. > > I think we'll just come up against this problem with every carrier that > sells a device. Thus we either do the updates ourselves (which could get > costly for every device) or try and change the industry's model. > > > Zac > > > > > > > On 15/04/14 06:58, 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. >> >> I really want to get the update channel and web api parts happen for b2g >> 2.0. Volunteers welcome! >> >> Fabrice >> > > _______________________________________________ > dev-b2g mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-b2g >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
