Mobile and Embedded

Alright, after some experimentation - most of that is just wrong :) What the "logical dots" and "device-independent" pixels are, I still don't know, but the units used by default by QML seem to be "physical dots". These do not match actual screen pixels though, at least not always. It seems you need to multiply "physical dots" by QScreen::devicePixelRatio to get the actual on screen pixels (and even then, on newer "Retina" type displays you will get some, hardware forced I assume, downsampling before going to the actual physical pixels on the screen: http://www.paintcodeapp.com/news/iphone-6-screens-demystified). On Android, "physical dots" seem to match actual on screen pixels 1:1 though, but I'd recommend still multiplying by devicePixelRatio, just to be safe against future Android devices where this does not hold. In short, for a fullscreen app: QScreen::size()*QScreen::devicePixelRatio() will give you the actual screen resolution in actual hardware pixels QScreen::physicalDotsPerInch()*QScreen::devicePixelRatio() will give you the actual physical pixel ppi/dpi, of course numInches*QScreen::physicalDotsPerInch() will give you the number of "physical dots" (the value you should give to QML), if you want something to be "numInches" inches long numPixels/QScreen::devicePixelRatio() will give you the number of "physical dots", if you want something to be "numPixels" actual pixels long on the actual screen. Keep in mind though, that on iPhone 6 Plus (and other similar newer "Retina" type displays, I assume) even this will not give you direct access to actual on screen pixels 1:1 - it's just not possible. You will be rendering with 1:1 pixel precision to a 1242×2208 buffer, which will then get downsampled by a factor of 1.15 to 1080×1920 when actually displayed on screen, see: http://www.paintcodeapp.com/news/iphone-6-screens-demystified - it might not be that bad, everything you draw will simply have some hardware forced "anti-aliasing" of sorts, which might be bad or good, you decide, but there is no way of getting directly 1:1 to actual hardware pixels, AFAIK. Please feel free to correct me if I'm still wrong somewhere, or confirm, so this can be more trustworthy and useful to someone in the future.

@Headman said: http://stefanfrings.de/android_qt/index.html Thanks a lot. I already use it but I look for official solution

@SGaist I got it, As a mention I'll make some tutorial to these process beacuse in the Web is very difficult to search something good. Thank You SGaist

Well, even with this workaround it does not work, seems like the path got reset somewhere and settings are not writable. Until this is fixed 5.5.1 for Android is broken and cannot be used, not sure if Qt must put a warning somewhere

Hi, Since url is a property you have the onUrlChanged signal to react to that.

I have found that my libraries on target was probably corrupted, I deleted them and load new .so files.

Thank you Archie. Your post helped me fix my problem. I was switching between the work computer and home computer and that caused the situation you mentioned.

@AddTheBadd I will reply to my own past to save anyone else falling into this very old problem. A 'space' had kept into my development path. I had moved my dev folder to my 'Google Drive' a few years ago and all my build tools where quite happy. Unfortunately it looks like some part of the Qt Qml parse system still has a problem with spaces in the path. I simply moved my Qt Development folder to a clean path and all is well with the world. Thanks, Adam

Solved, cygwin was missing in the system.

@SGaist That's a possiible solution, I'd like to have a try, thaks for you suggestion!

Calling qputenv at the start of main.cpp does the trick

It was easier than I though, I just have to manually start the emulator and It will appear in the Android Emulator List and connect. I tried with the cube opengl example and the application failed due to a failure in the shader compilation

There's always a beginning ;) IIRC sysfs can provide write-only files

I am able to compile a Hello world cpp code and generated binary file is successfully running on my board.

@sharethl In buildroot I have to enable GST1.0 to make GStreamer .............. Yes

I don't have a direct answer. However, it has to be noted that the mobile devices' OS are ultimately in control of what runs and what doesn't. Depending on the device and the OS, there may not be much you can do to control this. I know from a native code standpoint, on iOS, for instance, there's not really a concept of an ongoing background process; however apps can be woken up periodically to do things. In short, I don't know there's a cross-platform answer to this. However, if anyone has any ideas, I'm sure they will contribute them.