(new to AOSP)
I'm confused about the process of adding assets to AOSP (Android 10+) and using those assets in app development. For example, say I want to create my own AOSP build and add Boost (or anything) as a library, how then can I use this via the NDK when building apps (and share it with my team)? As opposed to creating a package (AAR or something) of boost, where every consumer would have to download it and build it into the apk/apb.
I suspect that the answer is doing this with the VNDK, but I still don't see how once I add a LL-NDK (I think?) library, how other developers would be able to access this with their NDKs.
Another way to ask the question, if some phone manufacturer, "SamPlusXel" creates their own version of AOSP, adds a bunch of vendor libraries, do they have a custom NDK they're developers can use to create apps to take advantage of all the vendor libraries they add (via Android-Studio)? Or is this just not something they do? Or can this only be done if they build their app along side AOSP?
(I think this question is similar in nature to Using NDK header when building vendor module with VNDK enabled)
Related
I want to develop an App that makes use of some heavy C++ code.
From what I have understood, I have two choices.
Build the library outside Android Studio and then import it, or put the C++ source code directly in Android Studio to let it build.
If I choose to build the library Outside Android Studio, I can use (OW): Windows or (OL): Linux.
At the same time, I know I can run Android Studio on either (AW): Windows or (AL): Linux.
My question is, can there be any performance difference in the App product running on the phone, depending on a specific approach I would follow (OW+AW/OW+AL/OL+AW/OL+AL/AW/AL)?
To integrate a C++ library into your Android application, from the performance point of view there's absolutely no difference. The difference in all those your mentioned options is the build process of your C++ library (the files with .so extension, i.e. shared library) which will be later integrated into your final .apk executable file. The Android NDK is doing everything at one place, but aside from performance, you should also consider other factors like development and testing capabilities, based on your project and your (and your peers') active skills. Speaking of the performance, it mostly depends on the number of calls between Java and C++ parts - the less data goes back and forth the better for the performance.
I tried searching for a solution but the only answers i found were the other way around (using the AAR inside QT).
I am developing an android app inside QT creator.
All is working fine. Now i need to make the core of this app as a library that can be distributed to android developer to be used in their code (like an AAR).
Is that possible to be done?
If so, how to do it and how to import it in other development tools (android studio/ eclipse ...)?
The easiest way is to compile your library using QtCreator and then send people the generated .so file with the header files. Then people can link with the .so file and use the header files to call the functions or instantiate the classes packaged in it.
Check this link to see how to build a library with QtCreator:
https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application
Note that you'll need to compile both armv7 and x86 targets and send both .so files if those two targets are needed.
I want to make an interface for a C++ complicated algorithm on a tablet environment, the idea of a server running the C++ code isn't applicable.
Can I embed my C++ algorithm in NDK application (for android, can I do the same for iOS?) and make the interface with Android SDK, and then use the NDK app (maybe as a function) in my SDK android app?? is this scenario possible and how hard it's?
I'd prefer the most a solution involving cordova and hybrid approaches.
If there is a simpler approach I'd appreciate any idea.
You probably want to port some code to Android. I do not know if you code has been ever built under Android.
Anyway, first of all you have to locate and manage to build the hello-jni example in the Android NDK. I have it in android-ndk-r9d/samples/hello-jni. After that, you may start to add functions to that project. Forwarding data between Java and C++ is... well... error-prone.
Android comes with two build systems, the old one is ant-based, the new one is gradle. In addition, some guys manage to use 3rd-party build systems for Android.
If your project has never been built under Android, you will have to port it. If it has Windows/Linux/Mac builds, start from a Linux or a Mac one (in the latter case please note that "darwin" contains "win", this may cause bugs in your build script.) You will likely have to borrow some standard functions from where you can find them. In addition, a while ago Android did not support std::string at all...
If your project has been built under Android, you will have to manage to build it yourself and then use the binaries. Alternatively, you might prefer to just use the existing binaries (this will require less effort) and just not care about bugs.
One more possible approach is to find the project that both uses your preferred build system and has an Android build, build that project for Android and remove the contents, thus obtaining an empty project that is built with your build system of choice. I did no do this and I suppose it will not be as easy as it sounds now. (But you will have a chance to become an expert in that build system.) UPD This section applies mostly to projects that come with a 3rd-party build system. Usually such exotic build systems have some specific features, and one needs these features to build successfully. The general rule is that beyond some level of complexity all working systems are modifications of other working systems (and are never created from scratch). (Example: programmers add functionality gradually and testing is done after each addition; they just cannot write all and then test all.) So in the case of a 3rd-party build system it may be reasonable to take some working project using that 3rd-party build system, get the build system working and replace the project source.
In general what you want is possible for both Android and iOS, but there is no general-case solution.
From what I understand, native code on Android is code that works directly with the processor of a specific device. So if I wanted to take advantage of a certain processor I would use native code.
But what happens if I want to make an app that contains native code, but targets multiple processors?
Do I have to make multiple apps, one for each architecture? Or is there a way to put multiple version of the native code in one app picking the one matching the processor of the device it runs on?
The Android Native Development Kit is a suite of cross compilers and support libraries which can be used to produce shared object (.so) files targeting one or more of the officially supported Android architectures.
The Android application package (.apk) specialized zip file format allows inclusion of distinct native libraries for more than one architecture.
If you refer to the NDK documentation, you will see that there is a project configuration file which you can use to specify which architecture(s) your native code should be compiled to support.
This is usually referred to as cross compiling. Ie, you need a compiler than compiles X, your current code, for Y. It generates code for CPU Y, not X as is the usual case.
You need to target multiple CPU architecture only if you are developing a NDK application.
Create a file named "Application.mk" under the jni folder. Add this parameter
APP_ABI=
Example :
APP_ABI:=x86 armv7eabi mips
or you can all do this
APP_ABI:=all ( in which it would create the apk for all supported architecture)
but doing this you would generate a FAT binary and google play will take care of filtering the corresponding apk for different underlying architecture when the user installs your app.
Is there some sort of alternative toolchain or language for Android, which can generate standalone APK files?
Ideally it should not depend on the huge and ever-changing, ever-upgraded official Android SDK.
As a parable, I am looking for a rough equivalent to how PowerBASIC and Mingw targets plain Windows just fine, despite Microsoft releasing new Visual Studios all the time.
Bonus points if this language or toolchain itself is an Android program...
As you may or may not be aware, the Android toolchain is based on a few simple ideas:
Your code is compiled using the plain old java compiler, and linked against the Android stubs (android.jar) for linkage against the system library.
After being compiled, the code is converted to dex format. You can actually run this yourself, just do a dx --help. The job of the dx tool is to take Java class files and convert them to dex code, a pretty straightforward compilation which involves going from a stack based to register based vm, and a few other changes.
After having this in place, an apk is built using a set of apk tools. It used to be apkbuilder, but this has since been deprecated. You can actually run this yourself as well. All an APK is is simply a collection of the manifest, resources, and a single file for all the code in dex form. (I.e., many .class files compile to a single .dex which is quite a bit smaller because of a wrapped web of pointers).
So the Android toolchain isn't really all that complex. The custom build process is handled by ant build rules, which are defined in an SDK wide build.xml, which you can find in the platform-tools/ directory (iirc). However, to generate new baseline projects using this custom build environment you simply use the android update project command.
While I'm not sure if this is the response you'd hoped for, I hope it will disambiguate the build process. It's not really all that complex of a toolchain, the majority of it is off the shelf Java, and not Android specific (all that makes it Android specific is library specific stubs for dynamically linked system code). Beyond this, once you have a set of classes, you need only run a few commands to make an executable APK which Android unpacks. I would suspect that any tool targeting the JVM (and capable of linking with the Android specific dynamically linked API) could perform a similar process of producing class files and using this toolchain to compile the rest of the way, though obviously the automated ant build process makes it much simpler.
EDIT:
After some more digging, I found this relevant android-developers thread. An unsettling quote:
At this time we simply don't have the resources to support people who
want to use their own build system, but we really wish we could. In
many ways we try to make it easy on other tools vendor by clearly
separating logic to eclipse or ant specific code (hence the multitude
of jar files everywhere in the tools and in ADT), but this is not one
of them.
However, you may also find this link helpful.
Terminal-IDE and AIDE are pretty much what I was looking for. Both runs on Android.