[Development] Android port - Why do we need Ministro?

[Felipe Crochik]

BogDan: Thank you for all your work and this explanation!

I was afraid that, at least part of, the reasoning for Ministro was the
create/control a "shared location" :(

Do you have any ideas of how we could continue with "shared libraries" (not
per app) but avoid having to install ministro "manually" ? I know it sounds
like a lot of trouble for something that only has to happen once per device
but I found out that is the big roadblock for a lot of people to install
your application.

On Fri, Jan 11, 2013 at 1:52 PM, BogDan <bog_dan_ro at yahoo.com> wrote:

> Hi,
>
>   I have write a few mails on this matter at android-qt mailing list.
> Here https://groups.google.com/group/android-qt/msg/854062a719092224
> you can find my reasons why I believe that Ministro is the best solution
> for
> Android deployment.
>
> 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.
>  - 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).
>
> Cheers,
> BogDan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130111/0118ec11/attachment.html>