[Android-development] Attempting a port to Android - Notes and Suggestions

[Patricia Aas]

On Wed, 27 Feb 2013 20:04:53 +0100, BogDan <bog_dan_ro at yahoo.com> wrote:

>>
>
>>>  Hi,
>>>  [...]
>>>
>>>>  B ) Assets should be loaded automatically, without the assets:/  
>>>> prefix,
>>>>  will probably require changes to AndroidAssetsFileEngineHandler
>>>
>>>  Searching trough android assets is very expensive, if for every file
>>>  you'll first search assets it will take ages until your application
>> starts,this is the reason why assets:/ prefix is needed.
>>
>> Yes, however I don't want to search. If the path is assumed to be in  
>> assets,
>> which it is for all resources, except files you write yourself to files,
>> supporting Android as a second/third/.. platform for an existing Qt  
>> project
>> becomes feasible. Where as now none of the paths in my application  
>> works, and I
>> will have to make significant code changes to make it work, with ifdef
>> __ANDROID__ everywhere.
>>
>
> By searching I mean: for every file you want to open, the android plugin  
> will search it
> first on assets which is *VERY* slow ! There are many other files that  
> qt needs toopen not only your resources files, here  
> http://pastebin.com/vXa3r5ue is a list with
> all the files that Qt is trying to open for a very simple widget based  
> application.
> Don't forget that Qt is not trying to open any style files or more  
> plugins. As you
> can see Qt tries to open almost 400 files just to start, now imagine if  
> you have to
> wait for every one of these file from 50-100 ms and you'll see that you  
> application
> will have to wait a very log time before it starts (every time !).
> [..]

Hm, interesting, I am now copying 454 files on startup from assets to  
files (in java code using AssetManager), and copying all of those files  
(total 14MB) takes all together 649ms, averaging 1.4ms per file.

But to make that work I had to avoid using AssetManager.list() (one single  
call to it took ~170ms). So I had to make an index file of all assets that  
I placed in assets, and use that to look up each asset.

Now something like that could maybe be used in your case as well, you  
could check the index if the file is in there before spending valuable  
(possibly futile) time looking for it. On the other hand if you are  
getting full paths, I don't understand why it would take so long, there  
should really not be a need to "look" for it, if you know where it is.

>>  What I really want is this :) :
>>
>> 1) A way to tell Qt that all my external paths are relative to assets  
>> root
>
> -2 on this point from my side. I explained above the reason.

If the reason is the inefficiency - then I would like a chance to look  
into that, maybe there is something we could do?

>> 2) A way to load qml plugins with the qmldirs in assets and the so in  
>> libs
>
> +2 I totally agree on this one, we should find a way to address the qml  
> plugins
> issue on Android and IMHO we should do it before shipping Qt 5.1.

Great :) Thanks.

>> 3) A way to load QGenericPlugins from libs, even though there is no
>> "generic" subdirectory there
>>

If you have custom QGenericPlugins then the so will be packaged in lib -  
but setting QT_PLUGIN_PATH to lib does not work, because Qt expects there  
to be a subdirectory called generic there. Which there isn't. My current  
workaround is creating plugins/generic directories in files, copying the  
plugin so files to files/plugins/generic  and setting the QT_PLUGIN_PATH  
to files/plugins.

So my point is that Qt should not require that there is a "generic"  
subdirectory on the QT_PLUGIN_PATH.

>>
>> Now if I had that, wow, my port would be a dream :D (I hope, I'm not  
>> done
>> yet...)
>>
>
> If you still want 1) I'm afraid it will become a nightmare :) !

lol, I still want 1) :D But I am willing to work for it ;)

Thanks,

-- 
Patricia Aas
Developer
Cisco