I'm currently working on a large Android app using a massive amount of C++ code.
It compiles and runs, so far so good.
Unfortunately, every time I modify something in the structure of my native source (add/delete/rename/move a file), which happens pretty often, ndk-build rebuilds the whole source, even the untouched files.
Does anyone know how I can set up the Android NDK to build incrementally somehow?
Thanks in advance
I got fed up with the NDK build system, studied it for a bit, and wrote my own makefiles. This was not hard.
However, it was then pointed out to me that by doing this, I would have to take responsibility for tracking future changes to the platform, for example if it becomes necessary to ship binaries for additional processor types, I'd have to modify my homegrown build solution to do that too.
In other contexts, I've sometimes had projects with two build systems - one for quick experiments, another for deployable builds. The time spent updating both now and then was saved many times in the speed gain for daily work. Provided I had to do a real build at least every week or two, things never got very far out of consistency (and both build scripts were in the revision control system, so there was history to examine). Something like this could be done with a custom makefile for debug builds and still using the NDK build system for deployable packages.
(In one case of doing a lot of experiments at the edge of what the platform permits, I actually had my makefile pushing the updated .so onto the device and gave my application one of the discouraged hard-quit buttons, so I could restart it using an updated native library without even having to rebuild and reinstall the apk)
Related
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.
I'm not too familiar with the Android build process, so I'm sorry if this comes off as a really stupid question.
Anyway, I'm writing testing code utilizing ActivityInstrumentationTestCase2 and Robotium for an Android application by the company I work for.
The company is rather large, so the transition to Gradle is going very slow. I would like to use Gradle for my testing project for ease and future maintainability, but right now the application I'm testing is built using a combination of ANT scripts and manual intervention with all dependencies checked in as jars in the repository. I'm not at all involved in that process, but I know it's pretty hacked together.
From what I understand, Gradle cannot simply depend on and trigger the building of another existing Android project unless that project also utilizes Gradle. So unless I want to really get my hands dirty with the build process of our application (we have people who are literally hired to only deal with that), I'm out of luck.
What I do have access to, however, are debug builds of our application.
So my question is, is there some way that I can have Gradle use the compiled debug APK as a local file dependency, or can APKs not work like that?
APKs don't work like that; you can't depend on them, for a variety of reasons. The most important reason is that the code and resources are processed and compressed and much of the original information needed to build them is lost at that point.
You'll have a tough time getting it to work properly. If things that you depend on are pure Java libraries, then if you could get them in JAR format you could depend on them from a Gradle project pretty easily. But if they're Android projects containing resources and manifest entries and such, then there isn't a compiled file format you could obtain those libraries in that would be compatible with Gradle. Gradle supports the AAR format for Android libraries, but that format is generated by Gradle and nothing else.
I have been working with standard android for some time. Recently I have been building android sdk for windows and find some interesting things in Android build env. There is a command called lunch which can be used to list all available targets to build. However, it does not list sdk and its variants,even though they are valid options.
Does anyone know why is that the case?
Also can I build any specific module in Android sdk without building the whole sdk. (It could be a great help as I dont wanna build the whole sdk, if I gonna do a small change in one component.)
Thanks
Under the hood, lunch uses make, so if some pieces of SDK do not change, they won't be rebuilt.
My speculation about your first question: rebuilding SDK was never considered a major task of lunch. It is most often used to port or mod the system and produce an installable system image, and receive the ADK as by-product. Later, people realized that often (with root access to the device) you can iterate over one component without need to reinstall the whole system image.
When we first started developing for android, we had 2 projects:
One for the 'core' functionality, other for the 'business' functionality.
So far so good, we went through bad times waiting so much time for compilation of XML changes, but life was still quite bearable.
After some time, we evolved (or not) to come with 9 projects. For some projects, we have a 'test' project.
We also have some library projects, for instance, we have two different projects for different versions of android, and we have a 'shared' project for shared configs or controllers.
The reason for that is because our application is quite big.
When we make some changes on the core project, we usually have to recompile, and 'clean' the workspace with eclipse. Also, we usually have to use the 'Build Project' option a few times for the projects to update their references, the first build hardly compiles everything, we call this in our team 'COMBO', which is the combination of 'F5' and 'CTRL+B' to compile the projects.
All this setup is killing a lot of time and making developers sad, like, a team of 6 developers :(
I know that by this time we should pretty much know all the issues and the best options, but I can't believe the way it is. And after so many time searching and trying to improve, we can't seem to find other solutions to improve development time with android.
Our set of tools is:
Eclipse 4.2.1
ADT 21.1.0
Eclipse Colour Themes (for a cute code)
SDK always updated
Hardware:
Windows 7 Professional 64 bits
8 GB RAM
Intel Core i5-3470 3.20GHz
I would love answers about:
Compilation time improvement: Did you found any IDE that for YOU it was faster than eclipse? Why? How was the setup? What are the drawbacks of using ADT and how can I improve performance with it, while using multiple projects?
Project references management, is there any suggestion on how
to speed up build? Should I put the whole source code in a single project?
Any way to speed up development when you have the device and need to deploy it while testing the application?
Try Intellij.
In the latest version, 12, they made project build improvements that make it much faster than 11 and Eclipse.
Parallelization
Note also the third column, called Parallelized. This
is a new compiler option which allows you to use more than one core
for building a project. In this case the compiler runs for multiple
independent project modules in parallel. Since each compiler thread
uses file system, the benefit of parallelizing highly depends on how
fast you hard drive is. Still the average gain in performance is
spread between 10 and 20 percent for large projects.
Automatic Make
One more exciting compiler option added in IntelliJ
IDEA 12 is automatic make. This is another time-saver, which triggers
project make automatically on every change. Since the compiler runs in
a separate process, it is able to compile modified files in the
background, while you are doing something else. This means your
project is in compiled state all the time, so you don’t need to wait
any time you want to run it.
http://blogs.jetbrains.com/idea/tag/brand-new-compiler/
Also if you are using git for version control I have noticed Intellij is much better at updating after I switch branches. It integrates well with git and notices that you switched branches and refreshes and cleans out the project in the background automatically, while on Eclipse you might have to refresh and clean manually.
I've spent the last few days struggling with getting a system up and running for building multiple configurations of our Android NDK App. I am able to build the libraries fine; the issues I run into usually stem from keeping those libraries up to date when changing build configurations.
I need a system that is for the most part fully automated: the user should just change build configurations and everything just works!
How have you addressed build configurations and the issues with libraries not being properly rebuilt?
I've tried a bunch of different approaches to this, but they all seem to end up with issues that are out of my hands.
Initially we just outputted a Shared Object file with the same name regardless of Build Configuration (eg. game.so). The problem is, changing build configurations doesn't trigger the library to be rebuilt; you have to make a change to the source or build scripts. So people change from Debug to Release, run the app, and are unknowingly actually linking to the Debug version still.
So then we tried outputting the library to a unique Shared Object based on the build configuration. For example, the debug version is gamed.so. The release version is gamer.so. The problem is, the Java code has no concept of build configuration, so how do we know which version of the library to load (which is done from Java)?
Well to get around that we do a try/catch looping through all the possible versions of the library attempting to load them. When we find the one that exists, load it! Problem being that the old versions of the library do not get removed when deploying a new configuration to the phone. So if you have built and run both Debug and Release, both of those libraries are now on the phone! Which ever one you ask for first, it will find and load.
So anyway, this seems like something that must have been solved already, but I have found very little information online. Nothing that has met my needs.
My question is: how have you addressed build configurations and the issues with libraries not being properly rebuilt?
This is actually strange. I have always seen that install -r refreshes the /data/data/app.pack.age/lib directory. Which device do you use for development?