I am little bit confused with SDK path in qt for mobile. I know Qt is based on Android NDK (C++). Then why we need to set path of SDK in tools->options->device->android->sdk path. Is SDK is based on Java?
NDK is used to compile your C++ code.
But NDK is only able to generate .so files (libraries compiled from C++). SDK is needed to generate the apk that will contain the program's main entry point that will end up using the .so files compiled by the NDK.
I don't think (not sure) that any app can be deployed on an Android device without using the SDK. Anyway, even if that could be possible, the way QtCreator works, it needs the SDK to deploy your application correctly on the device.
Related
Note - I am relatively new to Android and AOSP...
Where can I find the Android SDK in the AOSP? As we know, we build apk files in the android studio using the separately installed SDK. But for some reason, I wish to use the SDK in the AOSP if it is available. I see the source code of SDK in the AOSP; do we need to build it?
Why/How I have arrived at the above question:
I had created an .apk in the AOSP which had JNI files and dependency on some existing Broadcom libs (so). It is a system app. What I noticed is the .apk package does not contain the JNI libs but rather is copied to /system/lib folder separately. Hence I had a doubt how the .apk upgrade will work? Is it possible?
I assumed the .apk upgrade won't work that way and the .apk should be packaged including the JNI libs. Hence I planned to build the .apk in the studio and use the .apk as prebuilt and just sign it in the AOSP (we have the keys). Then I also wanted to allow the developers to build the .apk in AOSP itself by running the Gradle in the command line. I did so by adding the command to the Android.mk. But the point here is, it is still using the SDK installed in /home//Android/Sdk. But there may be build machines which may not have the SDK installed. So I am putting this question - Do we (where?) have the SDK in AOSP? Can I use that instead?
I tried to explain the problem.. in case it's not clear please let me know... Will try to give more details...
OTA update will work. Update with Package Manager - won't. This is normal for system apps with native libraries.
In AOSP applications are built differently depending on their location in build tree. Apps placed in ~/packages/apps and ~/device/some_vendor are system apps and they are handled differently by the system. One of differences is that during build process they are stripped of their native libraries and those libraries are simply copied to the /system/ partition.
Including pre-built apk is a good solution.
Yes you can build sdk yourself from sources. Yes, it's there. But I don't understand why you need that. Are there any changes to the API?
There are other options. For example, you can mangle your build scripts. Say, you can add a global FLAG that would disable lib stripping for system apps.
I am trying to create a shared library, using Embarcadero's C++Builder and RAD Studio 10.2. I created a C++Builder "Dynamic Linked Library" project. When I specify the target platforms to build for, the only options are 32-bit Windows, 64-bit Windows, and OS X. I need to be able to build the library for the Android (Linux) platform as well. How can I accomplish this?
At this time, RADStudio (including Delphi and C++Builder) does not support the creation of custom .so libraries for Android (only consuming them). Per the documentation, .so files can be created for Linux (and .dylib files for OSX/iOS) by creating a Delphi-style Package instead of a Dynamic-Link Library.
RADStudio-created Android apps are compiled as .so files (because they are based on the NDK, so the real app is just a small Java stub class that loads and executes the .so at runtime), but that is the extent of Embarcadero's .so generation on Android. Compiling custom .so libraries for Android is simply not supported yet.
I am trying to debug (from Windows) a native library (built with NDK v13b) that is shipped inside an Android application. The library is built outside of Android Studio, it does not use Gradle (CMake is used).
My library is built with debugging; the debug configuration in Studio is Hybrid, and I give the appropriate symbol directories. To "import" my library, I simply copy the .so and the .jar files inside my project directory in the appropriate locations (libs for the JAR, jniLibs for the SO).
When the library is built on a separate machine (Linux), I can do step-by-step without any problem, as long as I remap source locations (ie. using settings set target.source-map).
However, when I build the library on my Windows system, step-by-step does not work anymore.
I noticed a difference of behavior depending when I debug using the "built-from-Linux" or the "built-from-Windows" library. When debugging using the from-Linux one, LLDB command image list indicates that the library path is in the initial build directory. However, when debugging the from-Windows one, It is in C:\Users\foo\.lldb\module_cache\remote-android\.cache.... And this version of the library seems to be stripped.
Why this difference of behavior?
How can I either 1. use a pristine copy of my library in the module cache, or 2. directly use the build library?
Thanks,
I am trying to deploy a Qt app to an Android device, though I receive the error about missing stdlib.h. I found out that this library is actually inside sub directory tr1 of includes. I modified the include<stdlib.h> to include<tr1/stdlib.h>. After this I encountered the error for locale.h. This files doesn't seem to be present anywhere in the NDK.
The app works fine if build for Desktop as the Linux GCC has all files in proper hierarchy.
Any fixes?
Finally, I resolved the issue. It was just the wrong Android NDK build I downloaded. My system architecture is x86_64 and the Android architecture is x86. The build I downloaded was that x86_64 Android. Make sure when downloading the target platform is your Android architecture.
Also, one might find several solutions recommending to create stand-alone build using make-standalone-toolchain.sh script and setting CXX home to this build and as well as set "sysroot". Please do not do it. It's not at all required. Just set the NDK path from Android option from Qt itself. That shall be enough.
I would like to use a .jar file generated by SWIG in an Android application. What is the best way to deploy all of the underlying dll's with the Android application?
In a desktop environment, my PATH variable includes the folder containing these dll's.
DLL is a Windows technology. Android is not Windows. Android is based on Linux. You would be looking for .so libraries. More accurately, you will be looking for the C/C++ source code behind those libraries, so you can cross-compile them for Android chipsets (e.g., ARM). That will be accomplished via the Native Development Kit.