@SimonSchroeder OKay thanks.We shall see when he explain more

These bots... sigh

@jsulm, @JonB
Hello Both,

I found the reason for high CPU load.

Background:
We have our own devices and I'm working on creating user Interfaces on the display of our device. We have many qml files to create some objects which needs to displayed on the device.

We have a Software Tool which draws the objects on the PC using qml Files as per the user settings(like the size, position of the object on the display etc..). Then the objects are downloaded into our device.

Root cause for High Cpu Load, Inaccuracy of QTimer:
As a part of the objects that are created and downloaded from PC to the device, there is a ".gif(AnimatedImage)" object also.
We are setting the "playing" property of this qml object to "true". So, this object is causing high CPU load even though the page in which this object is present is made invisible(i.e "visible" property is changed to false). This is the reason also for the inaccuracy of the QTimer as AnimatedImage is consuming lot of CPU time and Qtimer is not triggered at the right time.

When I binded the "playing" property of "AnimatedImage" object with its "visible" property, the cpu load is very much reduced(from around 100% to around 15%). Only when I open the page which has "AnimatedImage" object, the cpu load is increasing back to around 100%.

Questions:

Any idea why "AnimatedImage" is causing such a high cpu load. Any CPU intensive operations are done by QT which are specific to AnimatedImages? The "cache" property of the "AnimatedImage" is false in high CPU load scenario. But if I change "cache" to true and open the page with "AnimatedImage", cpu usage is around 35%( but it was more than 100% when "cache" is false). How "cache" property is affecting the cpu usage of "AnimatedImage"?

Thanks in Advance.

Thanks guys for reading the post and trying to help.

Ultimately the problem was as very often between keyboard and chair. Other incredients were the most confusing error messages of the Android sdk compiler and linker. A part played also a creator bug for setting additional libraries used for building apk archive.

@J.Hilk you could be right with androiddeployqt and also the advice of @SeeLook might helped. However, around that time I made yesterday my final attempt which succeeded and I called it a day.

I think it is not conclusive, but may be the origin of my problems.
The main project folder was initially holding the pro file and everythink was already in subfolders. This is also true for the main sources and java stuff including AndroidManifest.xml. Now by changing to a subdirs project for the building. I replaced the pro in main folder with a subdirs pro file. This requires an additional subfolder for the new pro file due to the subdirs template mechanics. I had added the subfolder and redirected from there to pull the required files and setting the pathes to the other subfolder where the stuff was. I am pretty sure that the pathes were all correct, but apparently not a good idea for the use of one of the tools involved.
After correcting and having a straight increasing cascade of subfolders I managed to have sufficient cinfusion created to keep me busy.

My conclusion is to keep the project setup straight and avoid parallel back-stepping in your overall subfolder structure.
The output of Android SDK compiler, linker and also at run-time were pointing into different directions and always away from where the problem was.

I agree, this while() was bothering me.

I'm using a _timer with QTimer where start() by clicking, I get the Socket data with onReadyRead() process met _timer.stop() but emito sign for the status, seems to be working well.

But I accept suggestions for improvement, but I removed the loop while()