HOWTO qt app without ministro

[avraham]

How-to: create a standalone app that doesn't need ministro

warning: this isn't a copy-paste howto. You will need to understand the logic and apply it to your own app.

I assume that your app already works OK with ministro and with the 'use local qt libs' option. If not, make it work first and only then come back here.

Main idea

The main idea is to mimic what necessitas does when you use the 'deploy qt libs' and 'use local qt libs' options in the project run configuration.

I found out that these are the things it does:

1. deploy a large amount of files and puts them in the path /data/local/qt/ on your emulator.

You will need to get a copy of these files. (see step 1).

2. Pass some parameters to QtActivity.java. And lator on pass more parameters to the method loadApplication(Bundle loaderParams).

You will need to find out what these parameters are. (step 2).

Some of the parameters are files which your application needs in order to run properly. These files will need to be either added to your /android/libs/ path, or you will have to copy them manually to the device and then tell QtActivity.java where to look for them.

Some other parameters are Strings that you will need simply to pass forward in the same way.

i attached all of my code, you can use it under the included license.

Step 1

As a first step you will need to get a copy of the libraries Necessitas uses. To achieve this, deploy your app to an emulator using the 'deploy qt libs' option. Then use ddms (from android sdk) to pull these files back to your pc.

Note 1: the deployed file are different depending on the type of your emulator, so you will need to hold a copy of all options. Right now I only know of a difference between arm v5 and arm v7 architectures, so you will need to get one copy of the files from an API 14 emulator for arm v7 and another copy from a different emulator for arm v5. (AFAIK arm v5 and v6 act the same so no need to worry about v6 at all).

Note 2: not all of these files are actually used. It is recommanded to find out which files you need and which you don't. (more will be explained in the next steps).

Step 2

From this step and here after we will be editing the file QtActivity.java which is automatically created by necessitas and put in your <app-dir>/android/src/org/kde/necessitas/origo/ path. It is recommended (but not necessary) to use eclipse for these modifications.

In the method startApp you will find the following piece of code:

// use local libs

if (getIntent().getExtras()!= null && getIntent().getExtras().containsKey("use_local_qt_libs")

&& getIntent().getExtras().getString("use_local_qt_libs").equals("true"))

{

ArrayList<String> libraryList= new ArrayList<String>();

String localPrefix="/data/local/qt/";

if (getIntent().getExtras().containsKey("libs_prefix")) {

localPrefix=getIntent().getExtras().getString("libs_prefix");

// Log.d("izar", "local prefix = " +localPrefix);

}

if (m_qtLibs != null)

for(int i=0;i<m_qtLibs.length;i++)

{

libraryList.add(localPrefix+"lib/lib"+m_qtLibs[i]+".so");

}

if (getIntent().getExtras().containsKey("load_local_libs"))

{

String []extraLibs=getIntent().getExtras().getString("load_local_libs").split(":");

for (String lib:extraLibs) {

// Log.d("izar", "lib: " + lib);

if (lib.length()>0)

libraryList.add(localPrefix+lib);

}

}

String dexPaths = new String();

String pathSeparator = System.getProperty("path.separator", ":");

if (getIntent().getExtras().containsKey("load_local_jars"))

{

String []jarFiles=getIntent().getExtras().getString("load_local_jars").split(":");

for (String jar:jarFiles)

if (jar.length()>0)

{

// Log.d("izar", "jar: " + jar);

if (dexPaths.length()>0)

dexPaths+=pathSeparator;

dexPaths+=localPrefix+jar;

}

}

// Log.d("izar", "dex paths: " +dexPaths);

Bundle loaderParams = new Bundle();

loaderParams.putInt(ERROR_CODE_KEY, 0);

loaderParams.putString(DEX_PATH_KEY, dexPaths);

loaderParams.putString(LOADER_CLASS_NAME_KEY, getIntent().getExtras().containsKey("loader_class_name")

?getIntent().getExtras().getString("loader_class_name")

:"org.kde.necessitas.industrius.QtActivityDelegate");

// Log.d("izar", "LOADER_CLASS_NAME_KEY: " + (getIntent().getExtras().containsKey("loader_class_name")? getIntent().getExtras().getString("loader_class_name") :"org.kde.necessitas.industrius.QtActivityDelegate"));

loaderParams.putStringArrayList(NATIVE_LIBRARIES_KEY, libraryList);

loaderParams.putString(ENVIRONMENT_VARIABLES_KEY,"QML_IMPORT_PATH=/data/local/qt/imports\tQT_PLUGIN_PATH=/data/local/qt/plugins");

loaderParams.putString(APPLICATION_PARAMETERS_KEY,"-platform\tandroid");

Log.d("izar", "loader params:\n" + loaderParams +"\n<<end>>\n");

loadApplication(loaderParams);

return;

}

you basically need to use the method Log.d() on any string you don't know the value of. Then run your app once again, using the 'use local libs' option, and get the results in the output.

Step 3

In this step we will be adding the files to the target device, and telling your app where to find them.

This is what I found out about my app:

First i need to add the libraries displayed in <app-dir>/android/res/values/libs.xmlto the libraryList. Then I need to add another file named "lidandroid-#" where '#' is a number that depends on the target device's API level.

All of these library files need to go into your <app-dir>/android/libs/armeabi/ or /armeabi-v7a/ path, so that thay will be automatically installed on the device. Tell your QtActivity to look for them in the /data/data/<app package name>/libs (instead of localPrefix+"lib").

The last file I found that is used by my app is QtIndustrius-#.jar where '#' is a number that depends on the target device's API level. This file can not be deployed automatically so you will need to create your own method to do this, and then tell QtActivity where the file is.

I used a class called CopyResources (which I wrote) to perform this task. It copys files from the assests folder to a location on the target device. I used the built in getFilesDir() method to give me the best path.

Step 4

The rest of the parameters that go into loaderParams can probably copied from what QtActivity does when it receives the 'use local libs' command. You will have to try and see what happens.

Didn't work what to do

First read everything again and make sure that you really understood.

Try to figure out if your app does something differently than mine.

I don't promise to help anyone, but you may ask as a last resort.

[Ray Donnelly]

Pleas don't do this.

Minidtro exists for a good reason.

[Koying]

Well, if you compile your own necessitas (with patches), I don't see how you can do otherwise...

I never checked Ministro, but if there is a way to hook your own repository, that would be better, of course.

[Ross Bencina]

On 12/02/2012 12:00 PM, Ray Donnelly wrote:
> Pleas don't do this.
>
> Minidtro exists for a good reason.

Hi,

Sorry, dropping in after a long time away...

Is there a more offical option other than doing what avraham suggests if
you need to ship a customised Qt build with your app? Does Ministro now
support multiple side-by-side Qt builds? Including custom app-specific
builds?

I've used Qt for over 3 years and I have *never* been able to ship Qt
libs built from stock sources -- local patches have always been required
to fix bugs. Of course this is not a specific problem with qt-android
but until such time as Qt project sorts out their QA I think this
use-case needs to be accomodated somehow.

Thanks

Ross

[Ray Donnelly]

Ok, I see, thanks guys.

Hello Ross, long time no hear from!

Well, in theory if the patches are definitely good, we would consider
applying them to the Android version (though BogDan will have final
say on this of course).

For developers working on Necessitas or testing local changes, you can
use local Qt libs (copying your own Qt libs over the ones the
Necessitas installer creates), but that doesn't address final
deployment...

There isn't a way to hook your own libs into Ministro at present
(though there is a capability for different branches which is subtly
different), the hope was obviously to reduce the size-impact of Qt
libs on the user's device(s) and having the ability for apps to
declare their own versions would work against that (and create a
QA/reputation problem if there's bugs in your own libs)...

So this needs a lot of discussion...

Cheers,

Ray.

[Koying]

On Sunday, February 12, 2012 2:22:29 PM UTC+1, mingw.android wrote:

For developers working on Necessitas or testing local changes, you can
use local Qt libs (copying your own Qt libs over the ones the
Necessitas installer creates), but that doesn't address final
deployment...

Problem is that you have to be hooked to Qt Creator for that to work, which is sometimes not an option even for personal testing...

[Tommy Griffith]

If anybody just needs to get this working on a development device, you
can skip all the CopyResources stuff that Avraham implemented. As
long as you have already run an app on your device with "Deploy local
qt libs" checked (using necessitas of course), then all of your libs
should already be on the device in the location /data/local/qt.

Just add the required qt libs to your libraryList, add the right (for
your API level) QtIndustrius-X.jar to dexPaths, and set your
LOADER_CLASS_NAME_KEY to
"org.kde.necessitas.industrius.QtActivityDelegate". I also added the
following lines to the beginning of my startApp() function:

getIntent().putExtra("use_local_qt_libs", "true");
getIntent().putExtra("load_local_libs", "plugins/platforms/android/
libandroidGL-X.so");

Good luck.

On Feb 11, 5:19 pm, avraham <iza...@gmail.com> wrote:
> *How-to: create a standalone app that doesn't need ministro*

>
> warning: this isn't a copy-paste howto. You will need to understand the
> logic and apply it to your own app.
>
> I assume that your app already works OK with ministro and with the 'use
> local qt libs' option. If not, make it work first and only then come back
> here.
> Main idea
>
> The main idea is to mimic what necessitas does when you use the 'deploy qt
> libs' and 'use local qt libs' options in the project run configuration.
>
> I found out that these are the things it does:
>

>    1.

>
>    deploy a large amount of files and puts them in the path

> /data/local/qt/on your emulator.

>
> You will need to get a copy of these files. (see step 1).
>

>    1.

> // use local *libs*
>
> *if* (getIntent().getExtras()!= *null* &&

> getIntent().getExtras().containsKey("use_local_qt_libs")
>
> && getIntent().getExtras().getString("use_local_qt_libs").equals("true"))
>
> {
>

> ArrayList<String> libraryList= *new* ArrayList<String>();
>
>  String localPrefix="/data/local/qt/";
>
> *if* (getIntent().getExtras().containsKey("libs_prefix")) {
>
> localPrefix=getIntent().getExtras().getString("libs_prefix");
>
> // Log.d("*izar*", "local prefix = " +localPrefix);
>
> }
>
>  *if* (m_qtLibs != *null*)
>
> *for*(*int* i=0;i<m_qtLibs.length;i++)

>
> {
>
> libraryList.add(localPrefix+"lib/lib"+m_qtLibs[i]+".so");
>
> }
>

>  *if* (getIntent().getExtras().containsKey("load_local_libs"))

>
> {
>
> String []extraLibs=getIntent().getExtras().getString("load_local_libs"
> ).split(":");
>

> *for* (String lib:extraLibs) {
>
> // Log.d("*izar*", "*lib*: " + *lib*);
>
> *if* (lib.length()>0)
>
> libraryList.add(localPrefix+lib);
>
> }
> }
>
>  String dexPaths = *new* String();
>
> String pathSeparator = System.*getProperty*("path.separator", ":");
>
> *if* (getIntent().getExtras().containsKey("load_local_jars"))

>
> {
>
> String []jarFiles=getIntent().getExtras().getString("load_local_jars"
> ).split(":");
>

> *for* (String jar:jarFiles)
>
> *if* (jar.length()>0)
>
> {
>
> // Log.d("*izar*", "jar: " + jar);
>
> *if* (dexPaths.length()>0)
>
> dexPaths+=pathSeparator;
>
> dexPaths+=localPrefix+jar;
>
> }
> }
>
> // Log.d("*izar*", "*dex* paths: " +dexPaths);
>
>   Bundle loaderParams = *new* Bundle();
>
> loaderParams.putInt(*ERROR_CODE_KEY*, 0);
>
> loaderParams.putString(*DEX_PATH_KEY*, dexPaths);
>
> loaderParams.putString(*LOADER_CLASS_NAME_KEY*,

> getIntent().getExtras().containsKey("loader_class_name")
>
> ?getIntent().getExtras().getString("loader_class_name")
>
> :"org.kde.necessitas.industrius.QtActivityDelegate");
>

> // Log.d("*izar*", "LOADER_CLASS_NAME_KEY: " +

> (getIntent().getExtras().containsKey("loader_class_name")?
> getIntent().getExtras().getString("loader_class_name")
> :"org.kde.necessitas.industrius.QtActivityDelegate"));
>

> loaderParams.putStringArrayList(*NATIVE_LIBRARIES_KEY*, libraryList);
>
> loaderParams.putString(*ENVIRONMENT_VARIABLES_KEY*,
> "QML_IMPORT_PATH=/data/local/qt/imports\tQT_PLUGIN_PATH=/data/local/qt/plug ins"
> );
>
> loaderParams.putString(*APPLICATION_PARAMETERS_KEY*,"-platform\tandroid");
>
>   Log.*d*("izar", "loader params:\n" + loaderParams +"\n<<end>>\n");
>
> loadApplication(loaderParams);
>
> *return*;

>  CopyResources.java
> 13KViewDownload
>
>  QtActivity.java
> 77KViewDownload

[Tommy Griffith]

Hi Ray,

There is another reason why a patch like this is needed for a
necessitas release...

I'm not sure if you guys are aware, but there are some Android devices
out there with absolutely no way to get on the Internet. The GD300,
for example, does not have any type of networking hardware (no Wifi,
no 3G, no 4G, no EDGE, etc.) Thus, I think it's pretty crucial to
have the ability to use local libs without having to start the program
through necessitas every time.

Regards,
Tommy

On Feb 12, 8:22 am, Ray Donnelly <mingw.andr...@gmail.com> wrote:
> Ok, I see, thanks guys.
>
> Hello Ross, long time no hear from!
>
> Well, in theory if the patches are definitely good, we would consider
> applying them to the Android version (though BogDan will have final
> say on this of course).
>
> For developers working on Necessitas or testinglocalchanges, you can

> uselocalQtlibs(copying your own Qtlibsover the ones the

> Necessitas installer creates), but that doesn't address final
> deployment...
>

> There isn't a way to hook your ownlibsinto Ministro at present

> (though there is a capability for different branches which is subtly

> different), the hope was obviously to reduce the size-impact of Qtlibson the user's device(s) and having the ability for apps to

> declare their own versions would work against that (and create a
> QA/reputation problem if there's bugs in your ownlibs)...
>
> So this needs a lot of discussion...
>
> Cheers,
>
> Ray.
>
> On Sun, Feb 12, 2012 at 9:34 AM, Ross Bencina
>
>
>
>
>
>
>
> <rossb-li...@audiomulch.com> wrote:
>
> > On 12/02/2012 12:00 PM, Ray Donnelly wrote:
>
> >> Pleas don't do this.
>
> >> Minidtro exists for a good reason.
>
> > Hi,
>
> > Sorry, dropping in after a long time away...
>
> > Is there a more offical option other than doing what avraham suggests if you
> > need to ship a customised Qt build with your app? Does Ministro now support
> > multiple side-by-side Qt builds? Including custom app-specific builds?
>
> > I've used Qt for over 3 years and I have *never* been able to ship Qtlibs

> > built from stock sources --localpatches have always been required to fix

[Vadim Fedotov]

Hi.

 

Of'cource minimalization of qt applications size on user devices is generaly a good idea. But local patches are a real world situation. Also external application dependacy is not user friendly at all, many software customers will be really upset by that. I'm pretty shure our boss will be upset definetly.

[XumuK]

I tried to do all as Izar said and i have now one problem...In output when i start application with "use devices libs" option i see:

No implementation found for native Lorg/kde/necessitas/industrius/QtNative;.startQtAndroidPlugin ()Z

Please, take a look on files attached.

Thanks, Rustem.

[XumuK]

Problem closed.

вторник, 15 мая 2012 г., 15:19:14 UTC+4 пользователь XumuK написал:

[İsmail Dönmez]

Closed how? :)

[XumuK]

I just follow izar`s instructions and add something from myself. I can send files to this topic,  if you want (i use this files as a template for Qt development for android). Also with this template i can use commandline options (like linux application).

[İsmail Dönmez]

Would be nice to document this somewhere if not on the mailing list.

[Nalin Savara]

Hi XumuK,

Sure... would be great if you can send files to this group.

OR if you cant send files-- then give some tips/comment on how to fix errors I faced.

Thank you and Regards,

Nalin

[XumuK]

Just give me some time, i`m working now but when a came home i will write document with comments.

пятница, 27 июля 2012 г., 14:43:28 UTC+4 пользователь Nal Sav написал:

[Nalin Savara]

On Fri, Jul 27, 2012 at 4:15 PM, XumuK <hubb...@mail.ru> wrote:

Just give me some time, i`m working now but when a came home i will write document with comments.

cool thanks... but even if you cant write documents.. and just send ZIP file with code... it will help.

Meanwhile-- if I can get it done--- even I will share... and even I will be happy to help...

Regards,

Nalin

[XumuK]

First of all you must run application with 'use qtcreator libs'. This will copy all libs and neccecary files to /data/local/... dirs.

After that you have to change startApp method in QtActivity in your source file like in attached file. After that you can run your application with 'use local qt libs' option.

Check that all libs are included in .pro file ( Qt+= gui core and so on). Also check libs.xml. There must be all libs that you will use.

It works fine for me on Galaxy tab 8.9 (also i bundle my own libs, use postgress sql and so on). 

Good luck!

[S.H.H]

i browse with root manager in my phone and i saw these file  download :

/data/data/org.kde.necessitas.ministro/files/qt/jar/QtIndustrius-14.jar
/data/data/org.kde.necessitas.ministro/files/qt/lib/libQtCore.so
/data/data/org.kde.necessitas.ministro/files/qt/lib/libQtGui.so
/data/data/org.kde.necessitas.ministro/files/qt/lib/libQtNetwork.so
/data/data/org.kde.necessitas.ministro/files/qt/lib/libQtXml.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/accessible/libqtaccessiblewidgets.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/bearer/libqgenericbearer.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/imageformats/libqgif.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/imageformats/libqico.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/imageformats/libqjpeg.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/imageformats/libqmng.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/imageformats/libqtiff.so
/data/data/org.kde.necessitas.ministro/files/qt/plugins/platforms/android/libandroid-9.so

so i copied those files to MYSUCROSE/android/libs/armeabi/

how can i tell QtActivity.java to load included files form /data/data/org.kde.necessitas.MYAPPNAME/ ?
is there any thing i most to do ?

i used XumuK and izar source nothing of theme didn't work

please help me

[XumuK]

Try again, our examples works.

четверг, 6 сентября 2012 г., 13:50:46 UTC+4 пользователь S.H.H написал:

[Nalin Savara]

Sorry I did not reply earlier as was stuck with work.

Right now, uploading my working "Hello World"'s with lib bundling to my site.

Will just email link-- once uploaded ETA about 30 mins as 50 mb file and my conn slow.

Also, XumuK and Izaar had helped me earlier-- and I had said I will write a tute/upload some code-- about bundling libs-- and in next week I will do that also.


Regards,

Nalin

[S.H.H]

great...!
thank you very much
that's work very good
Regards,

[izar]

BTW:
according to my current tests, this how-to works ok also with alpha4.

also, instead of what i said in step 1, you can find the needed  files from ministro's repository, i.e.:
http://files.kde.org/necessitas/ministro/android/necessitas/objects/0.411-armeabi/

[angelus]

Can the posted changes libs.xml file content?

I do not know how to do this step?

[Flavio Portela]

Hi

and only tested it with alph4 but without success

Only works if run and maintain active [X]-use_local_libs.

Running the newly installed program, he is calling for Minister for download of libraries.

Anyone know leave permanent [X]-use_local_libs. thus always carrying / data / local / qt /?

Sorry for the english

[Flavio Portela]

Problem solved by sending QtActivity.JAVA

[mixxer]

Shame it has to be so convoluted. Clearly many of us would like to use this, so why not make it a standard deployment option in the next release?

[Ray Donnelly]

Because we clearly don't like it or want to encourage it.

[mixxer]

With due respect, this falls into category of making assumptions about what everybody needs based on your own needs or perhaps likes. For me, and I would venture to guess a good proportioin of others, your assumption is wrong.

The benefit of bundling libraries with the app is pretty clear - the end user does not have to deal with another unfamiliar step during installation. What's more, downloading Qt libs after purchasing an app may take up their 15 minutes of being able to claim a refund. They get angry if it doesn't work out and can't get a refund (e.g. a bug that affects their device or they didn't fully understand the app before buying). What follows are negative comments, support requests and manual refunds.

Compared to 'standard' android apps, the user experience is damaged before the app actually starts.

The only benefit of ministro is that multiple apps written in qt may share code. First, this is not entirely true as various apps may use different releases of qt libs. Second, the likelyhood of end users picking two qt based apps out of the 600000 in the google's store is pants.

So, apart from you not liking this, what exactly are the reasons why we shouldn't have this as an option?

[Ray Donnelly]

My reasoning was already given in a reply to this thread on Feb 12th.

> Shame it has to be so convoluted. Clearly many of us would like to use this, so why not make it a standard deployment option in the next release?

>> Because we clearly don't like it or want to encourage it.

> With due respect, this falls into category of making assumptions about what everybody needs based on your own needs or perhaps likes

No it doesn't, not at all. It falls into the category of me deciding
how I want to prioritise my hobbyist programming. You asked why the
Necessitas developers don't make it a standard deployment option and I
gave you my reasons for not spending my time doing this (BogDan or
some of the other devs may think it's a great idea, but I've seen no
evidence of that so far...). To me, it's you who's making the
assumptions here. I'm well aware that other people will have different
opinions on this potential feature. Anyway, you do raise some valid
points which I'll address later.

You said "Clearly many of us would like to use this". "many"? Is this
1%, 10%, 50%? All of these could qualify as many, given a large enough
population.

> The benefit of bundling libraries with the app is pretty clear

...

> The only benefit of ministro is that multiple apps written in qt may share code.

The detriment of bundling libraries with the app are also clear. To
call it to "only" benefit belittles the list of actual benefits of
Ministro providing shared libraries:

1. With bundled shared libraries the App developer will have to
satisfy the requirements of the LGPL.
2. The non-shared Qt libs won't get updates (bug fixes, security
patches, performance enhancements)
3. The App developer doesn't have to debug or fix issues in the Qt
libraries themselves, the Necessitas developers will do this for
him/her, but if they do want to do this, then everyone benefits from
those fixes (which is large part of the spirit of the (L)GPL)
4. We wouldn't want to 'stand behind' any App that used customised
versions of the Qt libraries, in terms of a Necessitas splash screen
or bug reports as we don't know what the App developer's done (for
example, have they put some backdoors in?)
5. The size of the App (I'm more hopeful than you - maybe naively so -
that there'll eventually be a killer app or two that a reasonable
percentage of people will want to install)

> First, this is not entirely true as various apps may use different releases of qt libs.

This is only the case to a very limited extent. There are Qt 4.8 based
apps and there'll be Qt 5 based apps eventually. We don't provide lots
of different minor versions. It's only API incompatibility that would
force us to provide new versions. The idea is that we make sure that
we don't break existing apps when we roll out a new version of the Qt
libraries.

> Second, the likelyhood of end users picking two qt based apps out of the 600000 in the google's store is pants

600000 is irrelevant in this context, I think that somewhere north of
95% of all apps can be written off as crap or of use to very specific
subsets of people. We hope that some great Qt apps will get ported and
that they'll be in other group.

IMHO your points about refunds and the unusual install procedure are good.

> So, apart from you not liking this, what exactly are the reasons why we shouldn't have this as an option?

To move this forward, if you really can't handle the convolution then,
in this order you could:

Propose it, code it and if all else fails, fork it.

Cheers,

Ray.

[mixxer]

Ok, thanks for replying. Don't mistake my argument for disrespect, I really do appreciate the hard work that everybody involved is putting into this.

I would just like to clarify that I am not proposing that everybody should mod and build their own DLLs. Most of your arguments (LGPL, thing about updating and development etc) would be valid on that basis but do not really apply to my suggestion.

I am only proposing an additional deployment option for necessitas DLLs - to be included in the APK as they are. The reasons are clear enough from my previous message and as far as I can see they remain valid. User experience being top of the list.

In any case, I take your point about doing it myself. I'll see what I can do, but must admit this is not my area of expertise.

Thanks

[John Papale]

Hello,

I've been following this thread closely, because I've been worried about the common user reaction, when they discover they have additonal libraries to install. Now that I've got the first reactions, I can tell it is a problem. Some users doesn't complete the installation, because they think we are installing a malware in their back. Some others get stuck. Those who go till the end find it annoying.

I think static should definitively be an option, if not the default way.

Best regards.

[angelus]

This is a very necessary option, which will greatly promote the development of Necessitas!

[Soheil]

I'm agree with mixxer. Ministro is the only thing which stops me to port already written apps to Necessitas. Why? exactly for everything mixxer said. If there were a clean solution to this which costs me say $10000 I would pay for it to override Ministro. Users do not like something like that. 

[Ray Chan]

I agreed with Mixxer. 

First I do respect Necessitas a lot.

And when I try to deploy my app in the market, I found that a lot of devices don't support Google Play. This means there is no way for user to get qt libraries from Ministro.

The only way for me is to deliver a single apk which has all necessary qt-libraries included.

Ray

在 2012年11月11日星期日UTC+8上午1时24分26秒，mixxer写道：

[Marcio Andrey Oliveira]

I second Mixxer and Ray Chan.

Static link should be available for those developers that want to use it instead of shared library.

Regards.

2012/11/18 Ray Chan <ray.chen.i...@gmail.com>

--
Play free on-line games

Get free games for

[Willy Gardiol]

The necessity to be linked to Google Play is stopping me too as i
deploy a lot on Amazon Market.

I am sking to BogDan, would it be possible to migrate Ministro inside
the Qt app so that the libraries can be downloaded automatically anyway?
I mean, no need to go to the google play and install anything, make
ministro part of each Qt app, so the user will not be confused and will
just see the downloa bar automatically?

This would solve all the user interaction issues i guess.

The issue woul probably be where to store the downloaed libs so that
they are available to all Qt apps...

Il 18.11.2012 22:54 Marcio Andrey Oliveira ha scritto:
> I second Mixxer and Ray Chan.
>
> Static link should be available for those developers that want to use
> it instead of shared library.
>
> Regards.
>

> 2012/11/18 Ray Chan <ray.chen.i...@gmail.com [1]>

>
>> I agreed with Mixxer. 
>> First I do respect Necessitas a lot.
>> And when I try to deploy my app in the market, I found that a lot of

>> devices dont support Google Play. This means there is no way for

>> user to get qt libraries from Ministro.
>> The only way for me is to deliver a single apk which has all
>> necessary qt-libraries included.
>>
>> Ray
>>
>> 在
>>
> 2012年11月11日星期日UTC+8上午1时24分26秒，mixxer写道：
>>

>>> Ok, thanks for replying. Dont mistake my argument for disrespect,

>>> I really do appreciate the hard work that everybody involved is
>>> putting into this.
>>>
>>> I would just like to clarify that I am not proposing that
>>> everybody should mod and build their own DLLs. Most of your
>>> arguments (LGPL, thing about updating and development etc) would
>>> be valid on that basis but do not really apply to my suggestion.
>>>
>>> I am only proposing an additional deployment option for necessitas
>>> DLLs - to be included in the APK as they are. The reasons are
>>> clear enough from my previous message and as far as I can see they
>>> remain valid. User experience being top of the list.
>>>

>>> In any case, I take your point about doing it myself. Ill see what

>>> I can do, but must admit this is not my area of expertise.
>>>
>>> Thanks
>
> --

> PLAY FREE
>
> GET FREE GAMES FOR
>
> [2] [3]
>
>
>
> Links:
> ------
> [1] mailto:ray.chen.i...@gmail.com
> [2] http://plicatibu.com/mkand0
> [3] http://plicatibu.com/mkbb0

--
Willy Gardiol
wi...@gardiol.org
www.gardiol.org
www.trackaway.org -> Track YOUR way the way you want!

[tomasl]

Hi, 

I just wanted to share what we did as a workaround for users not connected to Google Play: 

When starting our app and no Ministro is installed, the app goes to our own webserver to get the latest ministro.apk and run it. If that fails, we try to go to Google Play as normal. 

This way we still use Ministro as we should, but without the need for a google account (which in many of our customers' opinion definitely is a no-go).

We hacked QtActivity.java to be able to do this on startup, and it does mean that we'll have to make sure that the latest Ministro release is present at our webserver at all times. 

Please share if you have an even more clever solution :)

TomasL

[mixxer]

Thanks all for support and also bringing to fore further issues I was not aware of:

1. Cautious end-users who don't immediately recognise Ministro for what it is (e.g wrongly assuming it is not kosher)
2. Being stuck with Google Play as the only store supported by Ministro

An option to bundle DLLs instead of using Ministro is necessary for good proportion of people here. Now, how do we go about having this implemented?

Thanks

[mixxer]

Created a separate thread for talk about the non-ministro deployment option:

https://groups.google.com/forum/?fromgroups=#!topic/android-qt/c4tlwuqW1_0

[BogDan Vatra]

Hello,

Before I'll answer to some of your questions, I want to clarify a few things.
We, the people behind Necessitas
(http://necessitas.kde.org/people.php), are doing this job for *FREE*
only on our spare time, just because we love to do it.
We are *COMMITTED* to do what *we believe* it is the best for Qt, for
developer and the most important for *USERS*.

Personally, I write a lot on this subject, but it sees it was not
enough, I'll do it one more time now.
You may wonder why I bother to create such a complicated flow and why
I didn't chose to bundled all the needed Qt libs together with the
application or to statically link the application with qt libs? The
answer is simple, if you bundle Qt libs your application package will
be *HUGE*, let me explain more: I had a hunch that there are a lot of
low-end devices (armv5) out there, so, I asked KDE sys-admins if I can
get simple statistics (download count) about the files which are
downloaded from kde.org, they kindly provide me the needed information
and my hunch become reality. According to these stats 45% are armv5
low-end devices, most of these devices have less than 512Mb of disk
space. If you plan to release an application that targets two
platforms you'll need to bundle Qt libs twice (e.g. armv5 and armv7),
so your package will need 40-100Mb *ONLY* for Qt libs (if you plan to
add VFP support for armv5 and NEON for armv7, you'll need to double
that size). For the most Android users (not only for those how have
low-end devices) is not acceptable to download 100Mb for an
application which doesn't do too many things! There are only a few
apps that are bigger than 25Mb that are downloaded by Android users.
Ministro solves this problem by downloading the right libs for the
user platform *ONLY* once, in a central location, so if the user will
install a new Qt application it will use the existing libs, already
downloaded for other apps. Even more, it detects if the device has an
armv5 CPU with VFP or an armv7 CPU with NEON and it can download libs
tuned for that CPU.
Because I'm committed to do the best for the users and because I'm not
planning to punish them to download 40-100Mb for every Qt application,
I spend a lot of time to invent, design and code Ministro.

Why I believe it is also good for the developers? Static linking (also
bundling Qt libs) to your package comes with even more challenges than
the package size, developers *MUST* provide a way to users to repack
the application with other Qt libs (please check LGPL license on this
matter) or to use a commercial Qt license. Using Ministro, developers
don't have to worry about this problem.

Because I truly believe that Ministro is the best solution for the
users and also for developers, personally I'm not going support or to
spend a single minute on other solutions (static linking, bundling
then into application, etc.) ! It doesn't mean that if anybody creates
a *CLEAN* patch, I'm not going to accept it!
I'll accept any patch with two reasonable conditions:
- the patch *MUST* not affect existing apps and design in any way.
- the committer *MUST* update the work every time we'll do a new
release if is necessary.

Also you are free to add this information to necessitas wiki.

Because I don't want to start a flame war here, most probably this is
my last post on this matter.

Now the FAQ part:

> With due respect, this falls into category of making assumptions about what
> everybody needs based on your own needs or perhaps likes. For me, and I
> would venture to guess a good proportioin of others, your assumption is
> wrong.
>

Ray already answer this problem, and I fully agree with him on this matter.

> The benefit of bundling libraries with the app is pretty clear - the end
> user does not have to deal with another unfamiliar step during installation.

The user will do this "unfamiliar step" only once, then (s)he will
forget about Ministro. IMHO is fair trade for not downloading Qt libs
many times.

> What's more, downloading Qt libs after purchasing an app may take up their
> 15 minutes of being able to claim a refund. They get angry if it doesn't
> work out and can't get a refund (e.g. a bug that affects their device or
> they didn't fully understand the app before buying). What follows are
> negative comments, support requests and manual refunds.
>

Hmmm ... if I recall correctly, last time when I bought an application
(a few weeks ago) the purchase notification came to my mail before I
finished the application download. So I wonder how the user will be
able to download in 15 minutes an application that is two times bigger
than Qt libs that are downloaded by Ministro, but (s)he doesn't have
enough time for Ministro to download the libs? Something doesn't fit
in my mind here ...

> If there were a clean solution to this which costs me say $10000 I
> would pay for it to override Ministro.

With all due respect, I'd like to inform you that there are things and
people that can't be bought. For those interested to help us with
money, stating with alpha4, we added an option to necessitas website
where people can make selfless donation:
http://necessitas.kde.org/getinvolved.php

> And when I try to deploy my app in the market, I found that a lot of

> devices don't support Google Play. This means there is no way for user to

> get qt libraries from Ministro.

> The necessity to be linked to Google Play is stopping me too as i
> deploy a lot on Amazon Market.

Please send me a links with all those markets and I'll upload Ministro
to all of them, of course it should not cost me too much money to
create accounts:). I already did it for SAMSUNG apps, appslib.com,
etc.

>Now that I've got the first reactions, I can tell it is a problem.

>I have some complains on this matter from xxx users....

Ministro was successfully download by +2.9M user (yes, almost three
millions users !). What makes you think that your users are more
stupid than these 2.9M users?
It is not Ministro's fault because some of your apps are not wanted
and users don't download them.... Instead of blaming Ministro and
wasting time to remove it, I'll use that time on the application
itself ...

> To address the size issue, I'm going to release two apps on the Market, one for armv5 and one for armv7 !

Be serious! An user that is not able to install Ministro, I bet (s)he
can't make the difference between armv5 and armv7 !

> Some users doesn't complete the installation, because they think we are installing a malware in their back.

Ministro got these bad reviews for a few reasons:
- most of the users don't make the difference between Ministro and
the application that they just installed. If you check Ministro's
users comments, you'll see that +90% they are referring to other apps
that they just installed. It seems that there are a few apps that
users really don't like.
- there are some users that installed Ministro hopping it is a hot
shot game/application without having the curiosity to read the damn
description.
- there are users that finds unacceptable to download an extra xxMb
of libs. I bet these users will not accept to install the same
application that is twice bigger!

I'm doing my best to help people to understand what Ministro is and
what is its purpose, a little help from your side will be very
appreciated.


I really hope I didn't offend anyone, if I did it, it wasn't my intention !

Yours,
BogDan.

[Nalin Savara]

While I agree 100% with BogDan and Ray... 

A addendum (1) to the bit about "paying to bundle libs":-

> If there were a clean solution to this which costs me say $10000 I 
> would pay for it to override Ministro. 

There are atleast 2 options for this:--

Option-1

I believe if you buy commercial "Qt for Android"-- from Digia-- then you get the right to statically link to Qt libs... solve your problem... with added benefit of small size (see below)

This will give you two main benefits:--

1. Statically linking means that you are essentially bundling parts Qt's libraries as part of your own executables.

2. Assuming that "smart linking" is supported-- then, you will end up only linking classes/functions/pieces of code that are actually called... hence possibly using much less than the "40 MB to 100MB BogDan mentioned.

Buying Qt-commerical license will cost you much less than "$10,000"... and we must support Digia also... since they are serious about Android-Qt.

Option-2:

Use one of the many "bundling libs" howtos-- by XumuK (in his list replies) ; by Izaar OR by me.

Here's a link to a howto I posted on KDE's community wiki...

http://community.kde.org/KDE_Community_Wiki:Community_portal

It includes sample code that bundles libs... but for Alpha-3 only... as want to put it on Github and figure out ethical implications of sharing first...

Regards,

Nalin

<snip>

 

[Pritpal Bedi]

Hi BogDan

Before I'll answer to some of your questions, I want to clarify a few things.
We, the people behind Necessitas
(http://necessitas.kde.org/people.php), are doing this job for *FREE*
only on our spare time, just because we love to do it.
We are *COMMITTED* to do what *we believe* it is the best for Qt, for
developer and the most important for *USERS*.

I think all your points are valid one.

With just one request:

Is it possible that Ministro is installed automatically and starts 

the download operation right after installing the application ? 

This will  ease a lot of problems.

Pritpal Bedi

[mixxer]

Hi Bogdan,

Thanks for taking the time to answer.

Let's be clear - we are all in awe at what you and the team have achieved. I, for one, am hugely thankful++. Please don't take this as anything other than an ordinary feature request. There is no philosophical difference here - I think that Ministro is the best deployment option for most apps - but perhaps should not be the only deployment option because special cases do exist.

I'm grateful that you are willing to accept a clean patch that will provide the functionality. Anybody interested in joining the effort to implement this, please join the developer mailing list. Perhaps, once this is done, new joiners (me included!) can remain with necessitas so we can help in other areas. Provided Nalin agrees, we can use his work to get a head start.

To make sure we understand the issue completely, let me clarify a few points that have not come accross right.

1. 15 minute refund limit

The 15 minute refund limit begins when app installation completes. Ministro download only starts when the app is launched for the first time and hence the problem - time is ticking from the moment app installation is done.


2. Separate app packages per CPU architecture

Stores automatically make the distinction which APK to show and deliver based on architecture. See the "Native platform" field in the APK settings.


3. Size

Most apps won't use all Qt libs so we are probably talking in the range on 20-30Mb only (see also point 2). That's not a lot on devices with many gigs available. Many apps are over a gig / hundreds of megs - take Lego Star Wars, Batman etc, Galaxy on Fire or Need For Speed for example.

Thanks,
Mixxer

[mixxer]

Correction (thanks Ray): The large apps I have listed are iPhone versions. There are large Android apps too but they seem to use something similar to Ministro. The apk size limit is 50Mb according to: http://support.google.com/googleplay/android-developer/bin/answer.py?hl=en&answer=113469

[Ray Chan]

Hi Dear All,

   It's no doubt that Necessitas is a giant.  Many Qt developers could have their program run on Android Device by sitting on the shoulder of the giant, include me. 

   Great contributions have been done by the team and Thanks a lot!

   I'm a Qt developer based in China. The Android Market is a red sea here. This article tells a lot (http://www.gizchina.com/2012/08/14/20-ways-to-get-free-android-apps-downloads/).  On the other side, it's estimated that their will be 500,000,000+ mobile internet users in China by the end of 2013, most parts of them are using Android Devices.

  How to deal with different Android Market is really a headache.

  Good thing is in the oversea, I only have to put app into Google Play and Amazon Store.

Regards,

Ray Chan
  

[Nalin Savara]

sure... I'm happy to contribute my work-- but give me 1-2 days to
clean up and document my code-- possibly check it into github.

My vision would be for necessitas to ultimately support 3 scenarios:-
1. Ministro+ shared libs

2. Ministro + bundled libs... With ministro allowing you to optionally
switch from bundled to shared libraries...
To ensure we respect LGPL's requirement to allow replacing of shared
LGPLed libraries.
Also useful, Incase a critical update comes.

3. Necessitas commercial for statically linking... To minimize
compiled code size.

Hope that helps.
Today's 21st... Latest by 23rd, I'll post a link to a better
documented, cleaned out version of code I already posted.

Regards,

Nalin

On 11/20/12, mixxer <iv...@litovski.com> wrote:
> necessitas so we can help in other areas. Provided Nalin agrees, we can use
> his
> work

> Hi Bogdan,
>
> Thanks for taking the time to answer.
>
> Let's be clear - we are all in awe at what you and the team have achieved.
> I, for one, am hugely thankful++. Please don't take this as anything other
> than an ordinary feature request. There is no philosophical difference here
>

> - I think that *Ministro is the best deployment option* for most apps - but
>
> perhaps should not be *the only* deployment option because special cases do

>
> exist.
>
> I'm grateful that you are willing to accept a clean patch that will provide
>
> the functionality. Anybody interested in joining the effort to implement
> this, please join the developer mailing

> list<https://mail.kde.org/mailman/listinfo/necessitas-devel>.

> Perhaps, once this is done, new joiners (me included!) can remain with
> necessitas so we can help in other areas. Provided Nalin agrees, we can use
> his

> work <http://community.kde.org/KDE_Community_Wiki:Community_portal> to get

[Flavio Portela]

E/autoCopyMyResources(24879): /abcdxyz.txt (Permission denied)

or

E/autoCopyMyResources(24879): /data/local/tmp/abcdxyz.txt (Permission denied)

I seem to not be allowed, however when starting the application receive permission to write to / data / local / tmp.

What is necessary to receiving permission for writing in QtActivity.java or CopyResources.java?

[Nalin Savara]

Hi Flavio,

When compiling with Necessitas Alpha 3; I havent ever faced problem you describe-- hence some questions:--

(1) Are you able to open my oneBtn project's .PRO in QtCreator and get my oneBtn project-- that shows how to bundle libs into APK ?

Does it work on your phone ?

If not... what model of phone you use ? What version of Android on phone ? What SDK-platform version you compiling with ?

(2) If NO to (1) above-->> ie: bundled libs are NOT working on a device-->> then what device are you using ? WHat version of Android ?

Personally I have mainly tested/worked this on android 2.3.3 gingerbread ; and compiled it with android platform-8; using armv5 binaries for qt and armv5 target to compile oneBtn and projects derived from it.

Afterwards... I also tested the compiled APK on Samsung Galaxy Note running android 4.0.3 ICS.

(3) if yes to (1)--> ie bundled libs working on device-- and you have probs copying assets.

I strongly suggest that the files you are manually copying; ie: "abcxyz.txt"--> you can instead move the copying bit-- involving stuff not connected with bundling-- to c++ code... many examples of this on Qt for various platforms are available.

Do reply when you have a chance... with info I asked in (1), (2) and (3) and I will do my best to help.

Regards,

Nalin

[Flavio Portela]

I used the project oneBtn.

device:

Model: LG-P350f

Android Version: 2.2.2

I copy:

1-CopyResources.java

2-in QtActivity.java I include "CopyFile" "autoCopyMyResources"

I only change to my test: "abcdxyz.txt" to "/ data / local / tmp / abcdxyz.txt"

I do not think coding error, but permission.

I know being in QtActivity permission because I have sufficient permission to QFile and craiar the file in / data / local / tmp / abcdxyz.txt

[Flavio Portela]

device:

Model: LG-P350f

Android Version: 2.2.2

ARMV5

[Flavio Portela]

I am sending the log OneBtn.

Fatal error occurs, do not know what I did wrong.

[Nalin Savara]

Flavio,
if its permissions then one probably just needs to poke and google...
Till one figures out.

However... Did you see it works ok on another phone or emulator ?

If not tried:
can you share (ie:upload to dropbox or sm website) me the apk.

Am abt to sleep, bt hv my Galaxy note by my side... So I cud try to
see if it works.

Or if not see what adb shows as err log-- when I awake.

Regards,
-Nalin

[Flavio Portela]

I do not understand what you meant.

But I tried on the emulator.

I modified the /abcdxyz.txt to /data/local/tmp/abcdxyz.txt.

Got resultatos with the error:

on Emulator:

E/tag     (  375): /data/local/tmp/abcdxyz.txt

on Device:

E/tag     (30237): /data/local/tmp/abcdxyz.txt (Permission denied)

Seems to be the same error on the emulator and device

[Flavio Portela]

I include project modified by me

[Flavio Portela]

Hi Nal Sav

 what is the android folder .. / assets?

[Sebastian Diel]

Am 24.11.2012 13:40, schrieb Flavio Portela:

Hi Nal Sav

 what is the android folder .. / assets?

If you mean the folder "yourProject/android/assets" on your developing machine:

Therein you can put in files that are to be deployed with the apk.
You can find this folder in the apk, too, of course.

These files/dirs are read only on your device, but you can copy them to your app's file folder on first startup.

Sebastian

[Flavio Portela]

Not allowing this copy.

You know why?

[trusktr]

Hi, I've started a new thread and it relates to this one thread also.
groups.google.com/forum/?fromgroups=#!topic/android-qt/cI0L5S3Ur5I

On Saturday, February 11, 2012 2:19:34 PM UTC-8, izar wrote:

How-to: create a standalone app that doesn't need ministro

warning: this isn't a copy-paste howto. You will need to understand the logic and apply it to your own app.

I assume that your app already works OK with ministro and with the 'use local qt libs' option. If not, make it work first and only then come back here.

Main idea

The main idea is to mimic what necessitas does when you use the 'deploy qt libs' and 'use local qt libs' options in the project run configuration.

I found out that these are the things it does:

1. deploy a large amount of files and puts them in the path /data/local/qt/ on your emulator.

You will need to get a copy of these files. (see step 1).

2. Pass some parameters to QtActivity.java. And lator on pass more parameters to the method loadApplication(Bundle loaderParams).

You will need to find out what these parameters are. (step 2).

Some of the parameters are files which your application needs in order to run properly. These files will need to be either added to your /android/libs/ path, or you will have to copy them manually to the device and then tell QtActivity.java where to look for them.

Some other parameters are Strings that you will need simply to pass forward in the same way.

i attached all of my code, you can use it under the included license.

Step 1

As a first step you will need to get a copy of the libraries Necessitas uses. To achieve this, deploy your app to an emulator using the 'deploy qt libs' option. Then use ddms (from android sdk) to pull these files back to your pc.

Note 1: the deployed file are different depending on the type of your emulator, so you will need to hold a copy of all options. Right now I only know of a difference between arm v5 and arm v7 architectures, so you will need to get one copy of the files from an API 14 emulator for arm v7 and another copy from a different emulator for arm v5. (AFAIK arm v5 and v6 act the same so no need to worry about v6 at all).

Note 2: not all of these files are actually used. It is recommanded to find out which files you need and which you don't. (more will be explained in the next steps).

Step 2

From this step and here after we will be editing the file QtActivity.java which is automatically created by necessitas and put in your <app-dir>/android/src/org/kde/necessitas/origo/ path. It is recommended (but not necessary) to use eclipse for these modifications.

In the method startApp you will find the following piece of code:

// use local libs

if (getIntent().getExtras()!= null && getIntent().getExtras().containsKey("use_local_qt_libs")

&& getIntent().getExtras().getString("use_local_qt_libs").equals("true"))

{

ArrayList<String> libraryList= new ArrayList<String>();

String localPrefix="/data/local/qt/";

if (getIntent().getExtras().containsKey("libs_prefix")) {

localPrefix=getIntent().getExtras().getString("libs_prefix");

// Log.d("izar", "local prefix = " +localPrefix);

}

if (m_qtLibs != null)

for(int i=0;i<m_qtLibs.length;i++)

{

libraryList.add(localPrefix+"lib/lib"+m_qtLibs[i]+".so");

}

if (getIntent().getExtras().containsKey("load_local_libs"))

{

String []extraLibs=getIntent().getExtras().getString("load_local_libs").split(":");

for (String lib:extraLibs) {

// Log.d("izar", "lib: " + lib);

if (lib.length()>0)

libraryList.add(localPrefix+lib);

}

}

String dexPaths = new String();

String pathSeparator = System.getProperty("path.separator", ":");

if (getIntent().getExtras().containsKey("load_local_jars"))

{

String []jarFiles=getIntent().getExtras().getString("load_local_jars").split(":");

for (String jar:jarFiles)

if (jar.length()>0)

{

// Log.d("izar", "jar: " + jar);

if (dexPaths.length()>0)

dexPaths+=pathSeparator;

dexPaths+=localPrefix+jar;

}

}

// Log.d("izar", "dex paths: " +dexPaths);

Bundle loaderParams = new Bundle();

loaderParams.putInt(ERROR_CODE_KEY, 0);

loaderParams.putString(DEX_PATH_KEY, dexPaths);

loaderParams.putString(LOADER_CLASS_NAME_KEY, getIntent().getExtras().containsKey("loader_class_name")

?getIntent().getExtras().getString("loader_class_name")

:"org.kde.necessitas.industrius.QtActivityDelegate");

// Log.d("izar", "LOADER_CLASS_NAME_KEY: " + (getIntent().getExtras().containsKey("loader_class_name")? getIntent().getExtras().getString("loader_class_name") :"org.kde.necessitas.industrius.QtActivityDelegate"));

loaderParams.putStringArrayList(NATIVE_LIBRARIES_KEY, libraryList);

loaderParams.putString(ENVIRONMENT_VARIABLES_KEY,"QML_IMPORT_PATH=/data/local/qt/imports\tQT_PLUGIN_PATH=/data/local/qt/plugins");

loaderParams.putString(APPLICATION_PARAMETERS_KEY,"-platform\tandroid");

Log.d("izar", "loader params:\n" + loaderParams +"\n<<end>>\n");

loadApplication(loaderParams);

return;

}

you basically need to use the method Log.d() on any string you don't know the value of. Then run your app once again, using the 'use local libs' option, and get the results in the output.

Step 3

In this step we will be adding the files to the target device, and telling your app where to find them.

This is what I found out about my app:

First i need to add the libraries displayed in <app-dir>/android/res/values/libs.xmlto the libraryList. Then I need to add another file named "lidandroid-#" where '#' is a number that depends on the target device's API level.

All of these library files need to go into your <app-dir>/android/libs/armeabi/ or /armeabi-v7a/ path, so that thay will be automatically installed on the device. Tell your QtActivity to look for them in the /data/data/<app package name>/libs (instead of localPrefix+"lib").

The last file I found that is used by my app is QtIndustrius-#.jar where '#' is a number that depends on the target device's API level. This file can not be deployed automatically so you will need to create your own method to do this, and then tell QtActivity where the file is.

I used a class called CopyResources (which I wrote) to perform this task. It copys files from the assests folder to a location on the target device. I used the built in getFilesDir() method to give me the best path.

Step 4

The rest of the parameters that go into loaderParams can probably copied from what QtActivity does when it receives the 'use local libs' command. You will have to try and see what happens.

Didn't work what to do

First read everything again and make sure that you really understood.

Try to figure out if your app does something differently than mine.

I don't promise to help anyone, but you may ask as a last resort.