rnewman's analysis is apropos. On Thu, May 7, 2015 at 7:54 PM, Richard Newman <[email protected]> wrote:
> Separate APKs have some limitations that make me inclined to rule them out: > > - There's a signing, update, releng, and distribution problem. > - Somehow you have to get them to the user. If they're installed OTA, > the user needs to have disabled Google's safety checks. If they're > installed via Play, now we have another app listing. > - Separate apps are exactly that: separate. Getting > org.mozilla.firefox to use org.mozilla.speech's libxul instead of its own? > Not trivial. And now you have to make sure that users update them both! Not > fun. > > For the record, it is not particularly hard to arrange the signing/security side of cross-APK resources, partly by accident: we already set android:sharedUserId and Beta and Release are already signed by the same key. So some putative Speech APK just needs to do the same. Of course, this does not help you get the APK onto devices. > So, if the decoder is 2MB, and thus bundling it into libxul is a > non-starter (even the desktop team is trying to make libxul smaller!)… > > The best way to get this feature into a released version of Fennec is, > IMO, to make the decoder a separate .so, and the models separate files, and > to try to join the "download it later" train that we're thinking about for > fonts and other large semi-optional content. (Something along these lines > might make Firefox 42.) > > That involves figuring out a distribution and update mechanism, local > storage, triggers, all that kind of stuff, but there's a growing list of > reasons to do that work. > > The more you can attain C++ ABI/API stability, the more likely this is to > work, of course. > Wow, 2MB compiled for the decoder? That hurts. It's relevant to this discussion to note that binary extensions in add-ons have recently been deprecated, so this type of dynamically shipped binary code will be an even less tested and supported code path in the future. I am not certain but I recall recently overhearing that the Google Play Store agreement may prevent Apps from executing downloaded *binary* code, making such a separate .so outside of the rules. I believe Google built the OBB mechanism (http://developer.android.com/google/play/expansion-files.html) partially for this reason. (I can't find a reference for this right now, so perhaps I am making this up. Clarification appreciated. Note that web browsers generally do not download *binary* code, they download and interpret non-binary sources.) > The other thing to think about is whether you can deliver the web speech > API in Fennec without bundling an on-device decoder. For example, Google > Play Services offers speech recognition, and Fennec already has a voice > input button in the URL bar in Nightly; you might be able to offer similar > functionality to JS. > I suggest that this is the most feasible approach for Fennec. For the record, Fennec includes (but does not utilise or test) a .dex extension mechanism. I wouldn't recommend it -- in fact we should remove it, it's a knee-cannon -- but it does exist. Nick > On Thu, May 7, 2015 at 6:40 PM, Andre Natal <[email protected]> wrote: > >> >> Separate APKs looks like the most reasonable solution in terms of Fennec. >> We can have an APK for the decoder, and separate APKs with the models for >> each language. The question is: how to update the libxul.so from a separate >> apk? >> >> On Thu, May 7, 2015 at 1:36 AM, Ben Bucksch <[email protected]> >> wrote: >> >>> Kelly Davis wrote on 07.05.2015 09:35: >>> >>>> Should there be more/less fine grade control for installation there? >>>> >>> >>> Can this be done as Firefox extension? Or as separate APK installation? >>> _______________________________________________ >>> mobile-firefox-dev mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>> >> >> >> _______________________________________________ >> mobile-firefox-dev mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/mobile-firefox-dev >> >> > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
