Hi all,
It's true that our update situation is far from ideal - we already had
threads around providing better system update API to limit gecko
fragmentation for instance.
In 2.2 I'd like us to do the following:
1) Upgrades for certified apps from the Marketplace. Mostly what James &
Marco described. There are a bunch of details to figure out:
- Since there will be dependencies on gecko version, we need some
sort of versioning or at least update channels per fxos version.
That will imply platform work but also server side changes.
- These apps will be signed for obvious reasons. I don't feel like
we can let partners update certified apps without reviewing and
signing them ourselves.
- For that to be really useful, we'll need to commit ourselves to
backport eg. the improvements of the 2.3 email app on 2.2 for
people that can't do a FOTA update to 2.3.
2) Incremental updates for packaged apps. I ran some experiment with
popular apps from the marketplace and it's very promising. I'll
see what we get with gaia apps but that should be similar.
3) Language packs. That may seem unrelated, but we will ship them as
apps and they will have the same versioning constraints. Stas and
Gandalf are leading this effort.
4) Gecko improvements so that partners don't have to ship a patched one.
We have the engineering mode API, we need to finish the system update
API, and the RIL team is working on stabilizing the RIL interfaces.
With that in place, we may have some better options to eventually
provide gecko updates ourselves.
I think making progress on this topic is of the uttermost importance for
2.2. Android L is shipping with a WebView that is silently updated like
the Play Services. That means that if we don't move, android will end up
with a better web runtime than fxos in 2015.
Fabrice
On 10/23/2014 11:34 PM, Marco Chen wrote:
> Hi all,
>
> I would like to echo this requirement from James because it is also
> requested by partners.
> And the reasons are
>
> 1. Partners would like to build their own pre-installed and certified
> apps for differentiating their own product.
> And they need a way to upgrade these apps (the tied schedule may
> push them to ship first with small bugs).
> The cost of the only way now - FOTA/OTA is expensive then just
> doing a single application upgrade.
>
> 2. In order to co-work with other service providers in the world,
> partners may need to create their own APIs for fulfilling various
> requirements.
> And partners also want to keep Web consistency so their APIs will
> be certified type only.
> Due to this vision, their apps can not be installed or upgraded
> from market place because our capability now.
>
> 3. I also think that in the emerging market the narrow bandwidth is
> not suitable for doing FOTA/OTA.
> But an upgrade per app may be more easy there.
>
> So vote to this requirement.
>
> Thanks,
> Sincerely yours.
> ------------------------------------------------------------------------
> *From: *"James Burke" <[email protected]>
> *To: *[email protected]
> *Sent: *Thursday, October 23, 2014 3:07:54 AM
> *Subject: *[b2g] For v2.2: distributable certified apps
>
> For 2.2, I would like to see an exploration into allowing Gaia apps, and
> apps that can use certified APIs, to be distributed via marketplace
> channels, and updated outside full OS updates.
>
> That could take a few forms, including just pushing more/all certified
> APIs to "privileged" status. However, I expect that may not be feasible,
> so right now I am assuming there will be a continued need for
> "certified" apps.
>
> I wrote up something about this capability here:
>
> https://github.com/jrburke/certified-marketplace
>
> Feel free to file issues in that repo if you have questions about it.
> Happy to move the info elsewhere, just wanted to get something up.
>
> More importantly, it would be good to figure out the relative priority
> of this sort of feature for 2.2, which is the primary point of this thread.
>
> This sort of capability could be in opposition to some of the UX or
> product features.
>
> For example, I am thinking of the "themeable" feature, to allow apps to
> be themed, and to have that theming coordinated across apps, and for
> apps to have a specific dependency on a theme.gaiamobile.org
> <http://theme.gaiamobile.org> "app".
>
> However, this type of app distribution capability is very fitting for
> our mission, as it allows more people to make certified apps (after
> being vetted in some way) and to allow those apps to get updates outside
> of full OS updates.
>
> ---
>
> If this is just too big of a project for 2.2, then I would like to get
> an awareness or some sort of agreement for allowing individual apps to
> follow this path, and to realize it may mean those apps are not able to
> meet some other goals if they pursue this route.
>
> Specifically, I work on the email app, and I believe we could still get
> to a "updatable via marketplace", and I would like to try for that for 2.2:
>
> Email app goes privileged, and the app just lives with what is available
> to privileged apps. I think this is possible and still have a great,
> usuable email app.
>
> However, it means email not picking up any gaia-wide efforts that my
> require certified stuff. For 2.2, that could mean things like theming
> and if custom elements are not fully enabled for non-certified use, any
> common building blocks.
>
> Even if custom elements are available for 2.2, I am sure there will be
> other things in other releases, just pointing out the need to get wider
> agreement this pathway is OK for some apps that may be seen as part of
> "gaia".
>
> It also means possible modifications to the l10n.js capability to load
> localizations from app storage, and to do downloads of localization
> bundles from somewhere. While I am willing to do the modifications, it
> would still require some impact on reviewers' time, and likely some
> server work.
>
> To clarify: I want to preserve the existing localizer workflow, just
> want to modify how an app pulls in the final localizations, see above
> link for some more background.
>
> ---
>
> In summary: I would like this “certified” capability considered for 2.2.
> I am not expecting an immediate resolution, as all the 2.2 work needs to
> be balanced in total, and is still in planning.
>
> This is just to get it on the radar and to call out some of the
> tensions. Also, dev could start some plumbing now while planning is
> still in progress, and where it makes sense for the email app, I will
> start exploring in these areas.
>
> James
>
> (sending to dev-b2g, as it seems the most appropriate for what this
> capability spans, and want to avoid cross posting to multiple lists)
>
>
> _______________________________________________
> 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
>
--
Fabrice Desré
b2g team
Mozilla Corporation
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
