Better integration for open web apps on Android

Up until now, developing web apps on mobile has been a little tricky.

After spending the time developing your app, getting your users to install it is difficult, especially when the concept of “installing a web app” is not very well defined.

The most popular method is synonymous with adding a shortcut to the homescreen. This is problematic on a number of fronts, not least because the management of web apps – especially around launching, switching between and uninstalling web apps – differs significantly from that of native apps.

The web app “exists” only on the homescreen, not in the app drawer.

When it’s running, it is not clearly marked in the Recent Apps list.

Even once you get something like a smooth user-flow of installing your app onto the user’s phone’s homescreen, you often find that your app is running in a degraded or out-of-date web view, missing out on compatibility or speed optimizations of a desktop class browser.

What we as developers would like is a modern, fast web runtime, which is kept up-to-date on our devices.

Wouldn’t it also be nice for our users to launch and manage their web apps in the same way as native apps?

Introducing APK Factory

We have been working on making web apps be real on the desktop for some time. On the desktop, if you install a web app, Firefox will repackage the app as a desktop app so that it will integrate perfectly with the rest of your system – as outlined in more detail in Progress report on cross-platform Open Web Apps.

That means being in the Start menu on Windows, or in the Launch Control screen on Mac OS X.

From Firefox 29, that will apply to Android too.

This means that as a web developer, you can rely on a modern, up-to-date web runtime on Android to run your web apps. Even better, that web runtime is provided by an ordinary Android app, which means it will stay modern and up-to-date, and you can finally say goodbye to the Android Browser.

A web app, called ShotClock. Notice its icon in the top right of the screen.

The user will experience your web app as if it is a real native Android app:

  • The app appears in the App Drawer, the Recent Apps list, with its own names and icons,
  • The app can be installed and uninstalled just like a native Android app,
  • The app can be updated just like a native Android app.

In the App Drawer

In the Recent Apps list: all these apps are web apps

Installed with certain permissions

Best yet, is that we make these changes without the developer needing to do anything. As a developer, you get to write awesome web apps, and not worry about different packaging needed to deliver the web app to your users.

So if you’re already making first-class apps for Firefox OS, you’re already making first-class apps for Android.

The Technical details

On Firefox, you can install an app using the window.navigator.mozApps.install(manifestUrl) method call. Any website can use this API, so any website can become an app store.

The manifestUrl is the URL of a manifest.json document which describes the app to your phone without actually loading the app:

  • The app’s name and description, translated into any number of languages.
  • The app’s icon, in various sizes for different pixel densities.
  • The permissions that the app needs to run.
  • The WebActivities that the app wants to register.
  • For packaged apps only, this provides a URL to the zip file containing the app’s code and resources.

On Firefox for Android, we implement this method by sending the URL to a Mozilla-managed service which builds an Android APK specifically for the app.

APKs created by the Factory use Android’s excellent Resource framework so that the correct icon and translation is displayed to the user, respecting the user’s locale or phone screen.

Web app permissions are rendered as Android permissions, so the user will have a completely native experience of installing your app.

For packaged apps, the APK also includes a copy of the packaged zip file, so that no extra networking is required once the app is downloaded.

For hosted apps, the first time the app is launched, the resources listed in its appcache are downloaded, so that subsequent launches can happen as quickly as possible, without requiring a network connection.

And if you want to detect if the app is running in a web app versus in a webpage, checking the getSelf() method call will help you:

if (window.navigator.mozApps) {
  // We're on a platform that supports the apps API.
  window.navigator.mozApps.getSelf().onsuccess = function() {
    if (this.result) {
      // We're running in an installed web app.
    } else {
      // We're running in an webpage.
      // Perhaps we should offer an install button.

Keeping your apps up-to-date

For hosted apps, you update your apps as usual: just change your app on your server, and your users will pick up those changes the next time they run your app. You can change as much as you want, and your users will get the latest version of the app each time they launch and connect to your servers.

For anything needing changes to the app’s manifest, your users will get an updated APK sent to them to update their existing installation.

For example, if you want to change the app’s icon, or even name, changing the app’s manifest will cause the APK Factory service to regenerate the app’s APK, and notify your users that there is a new version available for install.

For packaged apps, the same mechanism applies: change the app’s package zip file, then update the version number in the app’s manifest file, and the APK Factory will pick up those changes and notify your users that an updated app is available. Your users will get an notified that there’s a new APK to install. Simples.

Is that it?

This is an exciting project. It has very little web developer involvement, and no extra API for developers to use: however, it should represent a step forward in usability of web apps on Android.

Now that we have taken the step to generate APKs for web apps, this gives us a platform for further blurring the lines between web apps and apps. Check it out for yourself and help us improve the feature: get Firefox Beta from the Google Play Store, install apps from the Firefox Marketplace, and let us know what you think!

About James Hugman

James is a software engineer who has been working with mobile operating systems since 2009, and with small underpowered computers all his life. At Mozilla he works in the Web Runtime team, spending most of his time persuading the two naughty children "Gecko" and "Android" to play nicely together.

More articles by James Hugman…

About Robert Nyman [Editor emeritus]

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City. He regularly also blogs at and loves to travel and meet people.

More articles by Robert Nyman [Editor emeritus]…


  1. Scott Arciszewski

    Okay, so… in the event that a webserver hosting/serving a mozApp is hacked and a false replacement is made with malicious code, this design doesn’t seem to incorporate any way of preventing malware. It lacks trust agility in the server.

    Is there any sort of plan to allow code-signing with a TOFU public key policy so that any mozApp “update” that is not signed will not be trusted?

    March 20th, 2014 at 11:05

    1. Kumar McMillan

      I worked on the APK signing service; security was our top priority. There are many layers to prevent an attacker from signing malware. In the first version the key store is generated and protected by Mozilla but in a future version developers can work with their own key stores

      March 21st, 2014 at 01:35

    2. Kumar McMillan

      To answer more directly, if an attacker hacked the site *serving* the manifest URL they could also hack the app so they can serve malware all day long. This attack is possible with any hosted web app, not just apks. If instead you meant an attacker could swap in a new manifest URL then the original app would not be affected because the URL is different . When a signed apk is installed, it can only be updated with a new one signed by the same key

      March 21st, 2014 at 01:41

    3. Myk Melez

      In addition to what Kumar said, note that are two kinds of Open Web Apps (i.e. “mozApps”): hosted and packaged.

      Hosted apps, like websites, can update their code at any time, and Mozilla doesn’t review those updates. But hosted apps can’t get elevated privileges, so their security characteristics are similar to those of websites (for good or ill).

      Packaged apps, on the other hand, can get elevated privileges, like access to device APIs. But their code can only be updated via a process that subjects it to review by Mozilla.

      For more information about the security and privacy model, see this document: .

      And to answer the question about code-signing with a TOFU public key policy specifically: we don’t have any plans to do that at the moment.

      March 21st, 2014 at 10:11

  2. Caspy7

    First of all, let me say, this is excellent (and beautiful).

    I just want to clarify: The guts of the runtime (gecko, spidermonkey, etc) are all still stored in the WebRT app and are not copied into the generated app, is that correct? Otherwise I imagine the size of each app would be huge and updates to the runtime itself would be problematic.

    Also, how will we handle WebRT installation in the future? If someone wants to install an app on the marketplace will we just link them to Firefox in the Play store first? I thinking, if I send a link to a friend to “check out this app” I’d want them to have the smoothest possible flow to install it. (Say, is it possible to create a link that invokes Fx:URL from within another browser?)

    Can apps be sideloaded? (apologies if this is prohibited by the implementation and I missed it)

    Again, this is very exciting for its potential.

    March 21st, 2014 at 04:37

    1. Myk Melez

      Yes, the runtime lives in Firefox for Android, not in each individual app, so the web app APKs contain only the app’s code (plus a bit of code that implements the APK “wrapper” library), and the device only needs a single copy of Gecko, SpiderMonkey, etc.

      As for installation without Firefox, Firefox Marketplace uses the same mozApps API as on FxOS and desktop OSes to trigger installation, which won’t work in another browser that doesn’t support that API.

      But if you share an APK that you get from Marketplace, and your friend installs it and launches it on a device without Firefox, then it’ll direct your friend to download Firefox from Google Play Store. We have some work to do to make this experience better, and we’re tracking it in

      And regarding sideloading, yes, apps can be sideloaded! And we’re working on a Node-based CLI for building sideloadable APKs that developers can use for testing and debugging. See for more information on that.

      March 21st, 2014 at 10:44

  3. Fabricio C Zuardi

    So, without publishing a web-app to the firefox marketplace, is there another way to generate a .apk file such as the one that you described (that will use fennec as the WebRT if installed or open Google Play to install it if fennec not present)?

    Something like a command line tool maybe? Is that tool?

    March 21st, 2014 at 14:07

    1. Kumar McMillan

      It’s even easier. Just call navigator.mozApps.install(manifestUrl) from your webpage when run from Firefox on Android to install the app. In the background, the APK will be generated. If the APK already exists, it’s fetched from the cache.

      March 21st, 2014 at 14:15

  4. Fabricio C Zuardi

    Yes Kumar, but I am thinking of cases where “run from Firefox on Android” is not possible because the user don’t have Firefox yet.

    From Myk’s comment it looks like the generated .apk from the Firefox Marketplace can start a flow that will install Firefox first if needed, and it’s this kind of .apk that I want to be able to generate on my own computer and distribute to people.

    March 21st, 2014 at 14:29

    1. Kumar McMillan

      Oh, right, that will be possible soon with the library you linked to.

      March 21st, 2014 at 14:32

    2. Myk Melez

      Bug 962879 is about implementing a command-line interface to the APK Factory, but it doesn’t generate APKs locally; rather, it retrieves the APK from Mozilla’s APK Factory server. And the APKs it generates are not generally redistributable, because they’re marked as “debug” APKs and intended to be used by developers to test/debug their apps.

      It sounds like you want a tool for generating an APK on your own computer. The APK Factory Service, whose code is in the apk-factory-service repository (and uses apk-factory-library as the “template” for the APKs it generates), used to have a “command-line mode” for doing that, although I’m not sure it still works, and we aren’t currently focused on that use case.

      You can, however, query Mozilla’s APK Factory server for an APK for any webapp that is publicly accessible to it. Just make an HTTPS GET request to the server at with the manifestUrl query parameter set to the URL of the webapp manifest (or mini-manifest, in the case of a packaged app). For example, here’s a command that uses wget to retrieve an APK for my Mykzilla test app:

      wget -O mykzilla.apk

      March 24th, 2014 at 13:24

      1. Anthony Cameron

        Thanks Myk for the excellent comment!

        I don’t suppose it’s possible at this time to rely on Marketplace as the APK generator — trying to upload the APK to Google Play complains that “You uploaded an APK signed with a certificate that expires too soon. You need to sign your APK with a certificate that expires farther into the future”

        The other thing it complained about was zipalign, but I was able to get past that quickly.

        March 25th, 2014 at 19:07

        1. Kumar McMillan

          Well, huh, I guess 10 years is too short. Thanks for the report! I captured it here It should be an easy fix.

          March 26th, 2014 at 16:17

        2. Myk Melez

          I don’t know if it’s possible, but it isn’t currently a priority, so there’s no guarantee that it’ll work (or, if it works, that it’ll keep working).

          Nevertheless, our certificates shouldn’t be expiring “too soon,” and Austin King filed bug 988450 to investigate the possibility that they are.

          I would also be interested to hear more about the zipalign issue you encountered. Perhaps we should be doing something differently when generating the APKs!

          March 26th, 2014 at 16:20

  5. Nathan

    How do I uninstall apps on Linux? Shouldn’t about:apps give me the list of installed apps? Running latest Nightly on Fedora 20.

    March 22nd, 2014 at 07:42

    1. Myk Melez

      Uninstallation on Linux is complex. We haven’t implemented about:apps on any desktop OS (Windows, Mac, Linux), but we did implement uninstallation on all three OSes, and on Linux we did it via a “desktop action”, which is a standard, in bug 780528.

      Unfortunately, Linux distributions don’t all implement that standard. So we have bug 896679 about finding another way to uninstall apps on Linux.

      Note that comment 4 of that bug says that GNOME 3.10 will support desktop actions. And this article says Fedora 20 comes with GNOME 3.10. So perhaps you can use a desktop action to uninstall an app?

      If so, then you should see an “Uninstall App” item in the context menu of the icon representing the app in the user interface. And selecting that item should uninstall the app.

      (Sorry for the generic description here; I’m not familiar enough with Fedora to know exactly where that icon is and how to invoke the context menu.)

      March 24th, 2014 at 13:37

  6. Controlling User

    What control does the user have over automatic upgrades? The net is littered with stories of forced upgrades breaking things for users. Surely there is a way for a user to prevent an automatic upgrade if they so choose.

    March 22nd, 2014 at 13:54

    1. Myk Melez

      Yes, there is no forced automatic upgrade in our implementation. Fennec does check for updates daily, and it notifies the user when they’re available. But Fennec will only download the updates if the user taps the notification. If they dismiss (or ignore) it, Fennec will do nothing.

      (We do have plans to streamline the process a bit by automatically downloading updates when the user is on wifi. But we still won’t force the user to update their apps, as we’ll require them to confirm the updates before we apply them.)

      March 24th, 2014 at 13:39

  7. Raymond Camden

    So wait, when did we get the chance to install apps on the *desktop* version of Firefox? I’m not seeing that.

    March 23rd, 2014 at 06:37

    1. Kumar McMillan

      Desktop apps have been available for a while: You may still need to use Nightly though; I forget if it’s preffed on in the public release

      March 23rd, 2014 at 07:58

      1. Raymond Camden

        Thanks Kumar – I can see it working now in 28. Query – is there any way to get access to the console for a desktop app? I can with the simulator – and hitting the app in FF itself – but not via the desktop. I’m getting an error *only* in the desktop version.

        March 23rd, 2014 at 08:12

        1. Myk Melez

          There’s a way! To access the console (and other remote developer tools), start the app from a command line with the -debug flag, optionally specifying a port (default: 6000). For example, on my Mac I start my Mykzilla test app via:

          > /Applications/ -debug 6000

          Then, in Firefox, go to Developer Tools > Connect… and connect to the “localhost” host at the port you specified. After pressing the Connect button in Firefox, make sure you go back to your app and confirm the connection. Then return to Firefox and select a “tab” (i.e. an open window in your app) or “Main Process” to debug the Web Runtime’s chrome code.

          Then a copy of Firefox’s Remote Developer Tools should open in a new window, and it should be connected to the “tab” you selected.

          (We know this is complex and undiscoverable and hope to improve it over time.)

          March 24th, 2014 at 13:51

          1. Raymond Camden

            Where do you see “Connect” as an option? I don’t see it in my dev tools.

            March 24th, 2014 at 14:15

          2. Raymond Camden

            Of course – the second I post I see it. I was looking in the bottom panel – not the top menu.

            March 24th, 2014 at 14:16

          3. Raymond Camden

            This is working, but I still don’t know why my app isn’t showing the latest changes I’ve made on the server. But instead of me adding a bunch of comments here, is it more appropriate for me to post to the Google group

            March 24th, 2014 at 14:19

        2. Myk Melez

          It’s fine to post here, but it’ll probably be more productive to discuss and troubleshoot your issue in that group, as there are a bunch more people in it who can contribute, and the group is better designed for long-running conversations!

          March 24th, 2014 at 16:33

          1. Caspy7

            There are others subscribed to these comments, so please pursue longer discussion threads elsewhere.

            March 24th, 2014 at 17:26

  8. James

    Will it be possible to place these apk’s in the play store?
    If that was the case, users could find the app in the play store, then on first run the app would install firefox

    This might be easier than getting a user to first install firefox then load firefox marketplace then locate & install the app

    Also the user may self discover an app in the play store but never self discover if he has yet to install firefox for android

    Finally a interesting option might be to alow apps in the Firefox market place to be mirrored in the play store .. As soon as you add to the market place or update the description or app that goes into the play store .. Might be an interesting idea & get people using more html apps!!

    March 23rd, 2014 at 06:57

    1. James Hugman

      There’s certainly no reason why the APK can’t be uploaded by the developer to an APK app store (e.g. the Google Play store).

      In the absence of a compatible runtime, the APK should offer to go find and install Firefox for Android.

      Currently we have no plans for the APK Factory to automatically upload APKs to any appstore.

      March 23rd, 2014 at 07:32

    2. Kumar McMillan

      One thing to be careful of is that when you upload a Mozilla generated APK to the Play store you’ll only be able to update it with a Mozilla generated APK (because Mozilla would hold the key store).

      March 23rd, 2014 at 08:00

      1. James

        Oh cool that sounds very useful!
        Will there be any way to produce the APK but signed with your own key?
        Maybe downloading the tools to do the APK packaging and run them on your local machine ?

        March 23rd, 2014 at 08:21

        1. Kumar McMillan

          Yeah but we are still planning out how that feature will work. I think it will be possible using the library tool (needs work)

          March 23rd, 2014 at 08:23

          1. James

            Oh wow that looks fantastic !

            It might be a more attractive option for android html 5 development over say phone gap ( for the obvious reason of having a consistent and far more upto date web view ) and also a great way to get firefox ( and therefore a more upto date browser ) onto users devices! Also will get the packaged app api’s used & expand the Firefox market place apps along the way too !

            Il try watch out for when the tool becomes fully stable !

            March 23rd, 2014 at 09:24

  9. Anthony Cameron

    Very awesome, was hoping for this from day 1 when I first heard you could install Mozapps on Firefox Beta!

    As for integration with other APIs, e.g., Notification, are these still in the works to provide a native Android experience? Not seeing any notifications being generated, but perhaps I’ve not declared it correctly in my manifest or am using the wrong version of the API

    March 23rd, 2014 at 12:56

    1. Wes Johnston

      The web Notification spec is supported in Fennec (a version was even supported in Fennec 4, but the newest spec was supported in 22) for all web apps. Its not widely used, so if you find bugs, please file them! Android provides some “rich” notification features that aren’t really supported by the spec. We’ll have to look at extending it if we want to support them as well, but given the slow uptake of the current spec, it hasn’t been a priority.

      A lot of the other web apis that b2g pioneered are already supported as well. Others may just require a pref flip to turn on, and we’re usually willing to flip those prefs in webapps. Our packaged app support includes the same security features so that we can lock out API’s based on an apps priveledge level as well.

      There are still other APIs that need to be implemented. For instance, I have an intern doing the initial WebActivity support work for us right now. That will allow sending intents from web pages, and getting back responses from Native Apps. Phase 2 of that will be hooking up WebApps to receive and respond to intents as well.

      March 25th, 2014 at 08:54

      1. Anthony Cameron

        So, if I wanted to use Notifications from the APK, it’d need to be a packaged app vs. a hosted app, and it should all just work? I’ve verified that my notifications are displayed in the FXOS simulator so I think I’m using the correct API

        March 25th, 2014 at 09:54

        1. Myk Melez

          Hmm, no, I don’t think your app needs to be packaged to use the Notifications API, since it’s available to web content, and all APIs available to web content should be available to hosted apps, per the security model. But it’s possible that there’s a bug preventing it from working. You might try loading your app in a Fennec tab to see if the API works there. And if you can’t get it working, then please report the problem, and we’ll investigate it!

          March 25th, 2014 at 17:30

  10. d00d

    Does the user need to have the “Unknown sources” setting enabled to install the APKs?

    March 24th, 2014 at 08:03

    1. Myk Melez

      Yes, Mozilla’s APK Factory is an “unknown source” according to Android, so the user has to enable “unknown sources” to be able to install APKs from it.

      On Android 4 devices, Android itself will walk the user through the process of enabling “unknown sources” the first time the user tries to install an APK from the factory. On older devices, we’re working on ways to help the user through the process over in bug 986085.

      March 24th, 2014 at 14:09

      1. Mathis Gardon

        First of all, I just want to congrats all the people involved in this project, it’s an engineering beauty and a hell of an exciting project for all developers involved in making seamlessly integrated mobile WebApps a reality.

        That said, I do believe this issue is the single bottleneck to tackle regarding a real-world use of mozilla-packaged webApps on Android, as most “basic” users outside of us developers & power users will not want to enable this option (insert some obvious stats here).

        I do understand that there is a game at play here, where Google does not want to enable easy apps installation outside of it’s Play store, while Mozilla is very much interested in bypassing the Play store to promote its own Marketplace inside the Android platform (just like google did on windows with ChromePackagedApps, in a way.).

        That said, leaving strategic concerns behind, I as a developer would very much want to be able to take the best feature of your solution (an up-to-date web runtime) while keeping the ability to publish apps to the play store without any further constraints.

        To do that, I can obviously publish my mozilla generated APK (as stated previoulsy), but it requires the user to install fennec before running the app, a step which seems fairly obvious to me as a developer (and I’m pretty happy about it, too as I love moz) but a crucial step that may prevent most of the basic users from using the app (a typical reaction may be : “I don’t want no spam on my new shiny S5, yo !”).

        In that regard, do you plan on offering some sort of packaging of the necessary bricks of the runtime (gecko, ionMonkey…), scrapped out of any unnecessary parts to lighten the package to the bare minimum, à la Xamarin mono runtime on Android, so that we may be able to deploy a webApp using the FF runtime without the need for FF to be installed ?

        Or do you prefer to go the google way and bet on the browser to be the trojan horse into another platform (à la ChromePackagedApps) ? In that regard, what are your plans for iOS deployment ATM ?

        Sorry for the far too long comment/question.

        March 25th, 2014 at 10:23

        1. Myk Melez

          Hi Mathis,

          There are a few questions here! Let’s see if I can address them all.

          1. Regarding packaging apps with an embedded runtime, the APK Factory project isn’t working on this, but some other Mozillians have been working on something called GeckoView, which seems like it could be used to achieve it. I don’t know enough about that project to describe it well, so I recommend you search the web for more information!

          2. Regarding “going the Google way”, I don’t speak for “Mozilla” the organization or community, only for myself here, as I don’t have enough insight into overall strategy…

          But I see the Android runtime and APK Factory as being about benefiting users by making Open Web Apps available on more of the platforms they use while benefiting developers by increasing distribution opportunities for their apps.

          It’s true that it might also benefit Firefox over Chrome/the native Android browser, as users of these apps also install Firefox. And I think that’s a great thing, because Firefox for Android is awesome, I encourage all Android users to try it!

          But you might also say it benefits Android over FxOS, by enabling users to access these apps without having FxOS.

          And Google could decide to implement a compatible Open Web Apps runtime, in which case users wouldn’t have to have Firefox to run these apps. There’s no prioprietary technology here, just open source code and some APIs that are being (or should be) standardized.

          So this isn’t about Firefox per se, it’s about fulfilling Mozilla’s mission by giving developers the freedom to develop web apps and distribute them to users on the platforms of their choice.

          3. Regarding iOS, I’m unaware of any plans to implement an iOS runtime. We do have a runtime for Mac OS, however, plus runtimes for Windows and Linux. And FxOS!

          March 25th, 2014 at 17:25

  11. Brian LePore

    About time this finally got ported to Android!

    That being said, did the mainfest.json path for icons change or something? I’m trying to figure out why the icon for my app displays a generic firefox marketplace icon (what is that rocket ship icon supposed to be called?) instead of my app’s icons. Is there a heuristic for icon sizes for Android? Right now I have an icon defined for 16, 48, and 128px and when I save app in Windows 7 it’s fine.

    I love making web apps and love the whole ability to bookmark sites to the home screen and putting apps in stores that are just websites … but really, can we get everyone to agree on a common set of sizes at some point? Off the top of my head I know of 11 different icon sizes that you need to include with apps (6 of which are various versions of iOS). This feels a bit much. =/

    March 24th, 2014 at 10:27

    1. Anthony Cameron

      Try running through the linter again

      I’m using 16,32,48,60,64,90,120,128 and see my icon correctly

      March 24th, 2014 at 10:38

    2. Myk Melez

      We’ve recently discovered a few issues with icons. Bug 982814 and bug 984028 are fixed, but the fixes haven’t been pushed to production (which it sounds like will happen tomorrow). Then there’s bug 960703, which hasn’t been fixed yet.

      March 24th, 2014 at 14:56

  12. Anthony Cameron

    Is there a good way to change the browser provider for the new APKs? I selected Aurora and after an Aurora update I think I’m seeing bugs. A re-install didn’t prompt me to select the browser runtime

    March 25th, 2014 at 10:06

    1. Wes Johnston

      You may need to clear the default app settings for Android. i.e. Open Android Settings -> Apps -> Aurora -> Clear Defaults

      March 25th, 2014 at 12:33

  13. Enrique

    Cool, I tested in Android / Windows / Linux and worked like charm. Still in my particular use case I can’t directly use it. I’m developping a multimedia webapp and to make it work on Android I need to manually setup the next values:
    browser.cache.disk.enable : false
    media.stagefright.omxcodec.flags: 16
    stagefright.force-enabled: true

    Specially, video will not work if stagefright is not configured properly. I think it would be ideal to somehow/somewhere allow to overload default config values changing the standard behaviour of the Mozilla engine (which I imagine is not easy without “collateral effects”). For the moment the only solution I find is to create a custom extension.

    April 9th, 2014 at 04:48

    1. Kumar McMillan

      It’s not the best solution but embedding GeckoView in an Android app might solve it for you However, the component is not production ready yet.

      April 9th, 2014 at 08:06

    2. Myk Melez

      Hi Enrique,

      I asked around, and folks are confused about why you need to set both stagefright.force-enabled and media.stagefright.omxcodec.flags, since one forces software decoding, while the other forces hardware decoding. They also don’t understand why you’re disabling the disk cache.

      In any case, it sounds stagefright is disabled on some platforms because of bugs, so unfortunately you can’t simply create an app to do what you want, if you’re targeting devices on those platforms. I don’t have more information about those bugs, but I’ll let you know if I find some!

      April 14th, 2014 at 15:32

  14. Enrique

    @Kumar Looks GeckoView is definetely what I was searching for. I was not aware of it. Thanks for the link!

    @Myk. Disabling disk cache is due to the fact that my app will download lot of pictures, and music from a local-network (WiFi) server. (At this moment I’m even testing with video-fragment download for HLS - and DASH - Since there is a local server already acting as a cache and mobile phones and tablets usually have an (personal opinion based on experience) non-reliable flash storage prefer not to use it. Also this flash memory tends to become very slow and “blocky” when the availabe space goes bellow 20-30%. I don’t think it would be a good idea to use it for anything apart of preferences/metadata.

    Respect to the media.stagefright.*, it’s a “works for me” tunning. According to what I have read - media.stagefright.froce-enabled force to use the stagefright “pipe” for video processing, while media.stagefright.omxcodec.flags=16 informs stagefright to force hardware decoding and not fall back to software (which anyway will not work with low-end ARM devices).

    April 15th, 2014 at 00:24

    1. Myk Melez

      Enrique: I’m not the expert on those prefs, but your description sounds different from what others have told me. This isn’t a great forum to have a discussion about this topic, however. I suggest posting about your issues to the mobile-firefox-dev forum.

      April 18th, 2014 at 08:15

Comments are closed for this article.