Would you recommend the overhead of installing & configuring an Android build server for a 1 programmer project?
The alternative is to upload all sources from development computer to git, download to another computer with Android Studio & Android SDK, and build from Android Studio.
If the answer is yes, would you recommend Jenkins, or another solution?
IMHO, yes, if you have significant time to set it up and maintain it on a separate machine. (I personally would not use a shared machine: too many reasons to restart and disrupt it.)
I feel an extra level of confidence each time I check in if Jenkins builds the whole project successfully from a fresh dir (one less thing I have to do.)
If I forget to check in an important file, Jenkins complains. Or, if I code something that generates a new Lint warning, Jenkins puts a spike in the graph. In other words, on solo projects, Jenkins is like an assistant (or mentor) that helps check my work.
Jenkins can warehouse app installers for future reference. So, it also helps me stay organized.
Jenkins offers some nice communications capabilities too. You can have it automatically notify others via Slack, or put an installer on Dropbox, or, through a service like Zapier, create a custom card in Trello. So Jenkins gives me an outward-facing messenger and delivery service.
These are some plugins I have found useful with Android builds:
Android Lint
Credentials Binding
Environment Injector
Gradle
Slack Notification
ThinBackup
Version Number
Zentimestamp
Of course, this only scratches the surface.
It requires some ongoing maintenance work though. And sometimes it's confusing/challenging to configure. (e.g. some plugins are poorly documented or no longer actively maintained. The linter in Android Studio is not exactly the same as the default one run through gradle by Jenkins, etc)
When I first set my build server up, I had a couple weeks of downtime when I was able to experiment with different plugins and troubleshoot the server. I probably wouldn't have done it without that empty window of time at the start.
Related
I'm in a company, and we have a lot of build problems when we put a new developper on an existing react native projects. We all know that it can take hours or even days before he start to work.
We use fastlane and jenkins for deployment but we dont use anything for the local aspect (exept yarn/npm of course).
I guess those problems are caused by different version of build tool (cacoapod, gradle, react-native-cli ...) or different environments (even if we're all working on macos).
I was wondering if any of you have faced some similar situations and if you have some tips.
Maybe something like a "build server" can exist, or tools to automate build tool installation / setup with given versions (something like a package.json for build tools). Or other things that can help us.
A brief list of things that i often face:
Android: impossible to run anything via react-native command (no real debogger) Activity is not found
iOS: The app launch and close a little time during splashscreen
fastlane iOS: The build is working sometimes but it is really fortunate. It says that there are multiple reference to *.a files.
But my collegues face other problems. Our goal is to find a solution that can live over time. Like what a well configured docker can do with web project.
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 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.
As you may know there are three ways to deploy a Qt application on Android :
Use Ministro service to install Qt
Deploy local Qt libraries to temporary directory
Bundle Qt libraries in APK
The first method takes about 30 seconds and it also needs to install an extra apk . Ministro.
The second takes about 1 minute for me ! And anytime I try to run the program Qt creator pushes Qt libraries to the device.
The third one makes the .apk file really big and again takes about 1 minute for me.
I think with this situation that's not reasonable to develop Android application using Qt. Is there a way to make the deploying process faster?
Almost a full year since the OP and things have not changed at all. Deployment of a 7 MB APK takes over minute and a half for a project that compiles in 5 seconds. The reason I am answering is not that the problem got resolved, but to offer an alternative solution.
I've implemented a "workaround" consisting of two applications that work in tandem - one on the PC and one on the device - I created this mostly to compile files remotely, but it turned out to be a much faster alternative for deployment as well. On the host create an application that launches compilation in a separate process, when done copy the product file over network to the device to deploy. Besides remote compilation this reduced the time to deploy to like 10 seconds, I can live with that.
(Not a complete and fully tested answer yet, but I'll update if I find out more …)
Option 1: Copy the changed libraries to a rooted device
A new build will most often result only in one changed file: your libAppName.so, the native library containing your application's code. At least in 2015, it was possible to simply copy over this library to the Android device, without having to re-build the APK package. This only works with rooted Android devices (note that all emulators are rooted by default).
Step by step, according to this blog article and updated with the paths as I found them on my device:
Run the cross-compilation step on your build host system. So just make or the equivalent in Qt Creator.
Copy the resulting libAppName.so to the rooted Android device:
adb push build/path/libAppName.so /data/app/com.example.appname/lib/arm
Restart the application on the Android device.
If that works, you might even be able to integrate it as a custom deployment step in Qt Creator.
I did not test this technique yet due to lack of a rooted device. But it should still work given that (1) rooted Android devices still allow to overwrite all files and (2) debug builds of APKs can still be installed without code signing, so overwriting a library in an APK without code signing should be possible.
Option 2: Desktop targets as a workaround
I found out by chance that Qt's multi-platform character can be used to avoid the slow Android deployment 80% of the time. You just set up another compilation target; under Qt Creator you'd add a target under "Projects → Build & Run", using a kit for "Device Type: Desktop".
Now when you want to test anything that is not Android-specific, test instead in the Desktop version. Building and starting that will only take a few seconds.
This approach is further supported by using a framework for convergent application development so that the same user interface is usable both in the desktop and mobile versions. KDE Kirigami and MauiKit are two libraries for this purpose that build on Qt. Documentation for getting started is a bit scarce, but for Kirigami I wrote an extensive README for the setup of an example application.
I've used Eclipse and vim variously as development environments for Android applications and found both the Eclipse plugin and the command-line SDK tools to be of similar capability.
Since I haven't explored either in its entirety, however, I'd like to ask:
What advantages are there to using Eclipse over the command-line tools and vice-versa?
I could see:
(Eclipse) nice GUI for debugging
(ant/adb/android) more amenable to automation
(hybrid) you can have it all, can't you!?
I'm especially interested in specific features that may be a deal-breaker for one and move a developer in the direction of the other.
Using Eclipse as a development environment for Android doesn't preclude you from also building with Ant to hook into nightly builds or CI tools. You could even configure Eclipse to build using your Ant buildfile if you wanted. If you want some kind of CLI build tool, you might also consider Maven, as it also has plugins to enable building Android apps.
It has been some time (like six months) since I have used eclipse, so maybe it is better now, but I gave up on it because I found it to be very slow and buggy. Maybe it is the integration with ADT, but several times I spent hours hunting down problems that turned out to be fixed if I killed and restarted eclipse (and these problems were not fixed if I did a "clean" within eclipse). After doing that a few times, I felt like throwing the computer against the wall.
"ant clean" is much easier and faster than stopping and restarting eclipse.
Across my personal projects and multiple professional instances of building Android apps, I've always used both types of builds. You'll want to use Ant (or Maven, if you prefer) to set up continuous integration and automated testing. Trying to get that working with Eclipse (which I did a long time ago when the Android SDKs were first coming out) is a nightmare, while Ant/Maven is easily used from any of your favorite CI tools (I've usually used Hudson for this). If there's nothing unusual about your project, it'll be a snap to put together continuous integration, and off you go.
Meanwhile, for just day to day development work, using Eclipse to build your app locally works just fine. But that can easily be left up to the individual developer. I'd make the build that your CI system is running the canonical build, but I do use Eclipse for my normal development.
I'd use Eclipse until such time as you are happy with the debug build. Then you can set up Ant to produce the signed release build.
You can set it up to use the same source files as Eclipse but put the output binaries outside your workspace. You can also set it to use your release.keystore, sign it automatically and obfuscate the code all in one go.
I've set it up to do this. I open a command line (DOS box) move to the projects home directory (\dev\projects\Eclipse\Project1 say), I type "Ant release" and the apk ends up in \dev\projects\AntBuilds\Project1\bin as Project1-release.apk.
If you want the best of both worlds, you might want to look at the m2eclipse-android-integration Eclipse plug-in which allows you to use your command-line Maven build in the ADT/Eclipse environment as well:
https://code.google.com/a/eclipselabs.org/p/m2eclipse-android-integration/
Well for me im just a beginner, but I find eclipse much easier to work with. Android is a pretty complicated to get used to (for me) so having everything layed out in a GUI is preferable to command line. Plus SDK updates and such are easier to get.