Note that with some tweaking, it is already quite possible to build statically or bundle the libraries you want as part of your .apk if you're not worried about the library size. We probably won't make a out-of-the-box-solution for this for the Qt 5.1 release, since it just doesn't fit in the schedule, but I've tested it with both Necessitas and with Qt 5, and if you're comfortable with Java and the Android package system, it's not that hard.
About protecting against unexpected behavior: I think this will be an issue anyway, since you're depending on several shared libraries in the platform in addition to Qt, and they can all be updated behind the app's back. So developers will have to test against changes in the underlying stack and maybe make their own updates if it turns out that they depended on buggy behavior. -- Eskil Fra: [email protected] [mailto:[email protected]] På vegne av Laszlo Papp Sendt: 11. januar 2013 20:14 Til: BogDan Kopi: Pau Garcia i Quiles; Abrahamsen-Blomfeldt Eskil; Felipe Crochik; [email protected] Emne: Re: [Development] Android port - Why do we need Ministro? On Fri, Jan 11, 2013 at 6:52 PM, BogDan <[email protected]<mailto:[email protected]>> wrote: I'll do a summary of them: - the most important is that qt libs are very big (Qt4 libs are +40Mb for one platform and most probably Qt5 will be more than that), if you want to target two platforms (armv5 and armv7) you need to bundle +80Mb of qt libs. Even more, if you want to use NEON for armv7 and VFP for armv5 you need to double that size. Ministro downloads the right libs for your platform only once. QtCore 4.8.4 is 2.9 MB for me. It does not look that bad if you need some core feature only. Besides, there is another point (perhaps mentioned in this thread already), you can make sure your application remains working against unexpected behavior and so forth changes we had unfortunate examples in the past. So, it is also a matter of ensuring the functionality of your application. In my opinion, this can be a valid concern for certain application developers. The convenient way for the end user would just be a plus in such a scenario. - android offers no way to install shared libs into its system libs folder, and there is no read/write location that application can use to store shared libs (obviously, for security reasons). Ministro solves this problem by using its own home folder as a central location for qt libs, where only Ministro has read/write permissions to these libs, the other app have only read-only permission, just like your linux desktop. - statically linking or bundling LGPL libs into your package comes with even more challenges than the package size, developers *MUST* provide a way to their users to repack the application with other Qt libs (please check LGPL license on this matter). I do not see the problem in there yet. It is replacable after repackaging or by direct overwrite if the platform security allows that with Harmattan for instance. That being said, I also agree about that Ministro can be a useful tool. Laszlo
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
