Apple is very conservative in allowing developers long term background threats/events.
Taken from the Apple docu:
Implementing Long-Running Background Tasks
For tasks that require more execution time to implement, you must request specific permissions to run them in the background without their being suspended. In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background, such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app Apps that support Voice over Internet Protocol (VoIP) Newsstand apps that need to download and process new content
Apps that receive regular update from external accessories
Apps that implement these services must declare the services they support and use system frameworks to implement the relevant aspects of those services. Declaring the services lets the system know which services you use, but in some cases it is the system frameworks that actually prevent your application from being suspended.
That said, a navigation app should fall in this category. But as it is, you're bound to do it in OBjective-C but its relative easy to include ObjectiveC code in Qt.
There was no "src" directory at that location. So I created one and moved the java files there. I did not mention them in the .pro file. The files have not shown up in the project view within QtCreator. I executed qmake, rebuilt and ran the app. Same result (RuntimeException). Can I trace or debug somehow, what's going on?
After adding them to the DISTFILES variable, they got copied to the build directory and ignored afterwards. The Qt deploy tool obviously does not do anything with them. Shouldn't they be compiled into the dalvik executable?
OK, I found them as ".class" files in <build-folder>/android-build/build/intermediates/classes/debug/... among other java files like "BuildConfig.class". So maybe, some identifier is wrong or something.
Is this library stable? If not, when stable version will be released?
It depends on what you mean by stable.
If you mean the API, then probably you can safely say it's stable. I don't plan any (big) changes in the API. As for the binaries, it is binary compatible.
If you mean performance, I suppose it's stable enough. I have a project deployed with it and hadn't had any problems yet. Also it was reported by @madababi that the library works fine on Raspberry PI (with proper cross-compiling of course). There's always the possibility of minor bugs, but it should be fully functional.