I have set up a Concourse CI pipeline to run tests and build my apk. I've built a docker image for my job to run in. The image contains the sdk tools, build tools and platform tools but does not contain the platform that corresponds to the compileSdkVersion. It seems to work and build the apk correctly, I can run the apk on a device. I'm slightly confused by this as I would have thought that the platform would be required. Does anybody know how this is working under the hood and what the minimum set of files are required to compile and build the apk?
Thanks
It turns out that gradle actually pulls down the platform during the build, I noticed it in the logs.
Related
Gradle is just a build system, right? Why does intellij want to download gradle 2.3 when I have the latest gradle version locally installed. If i setup intellij to use the local distribution, the build fails with an error saying no cached version of gradle 4.3 is available for offline mode.
Point #1, You can point Intellij to a gradle installation. See Intellij Gradle docs that describes your options, but pay special attention to the next point, which intellij also supports.
Point #2 Build systems also have versions. Gradle is constantly being updated, so building with the wrong version of Gradle can fail.
That is why a gradle script can specify the version that it needs in order to build. This is essentially a bootstrapping process designed to make your build scripts essentially self sufficient. See for example Gradle docs that describe this practice.
I have updated my gradle-wrapper.properties to 2.10 from 2.8. But I want to know that what its purpose in Android Studio. As we didn't see any gradle-wrapper properties in eclipse.
Gradle Wrapper is a type batch or shell script that downloads and automatically configures Gradle to execute tasks. Imagine that you want to run a Gradle build, well you need to download and install Gradle in your computer, so this concept allows is to distribute our project and build configurations with no need to have Gradle installed.
Also their official gradle webiste says :
Most tools require installation on your computer before you can use
them. If the installation is easy, you may think that’s fine. But it
can be an unnecessary burden on the users of the build. Equally
importantly, will the user install the right version of the tool for
the build? What if they’re building an old version of the software?
The Gradle Wrapper solves both these problems and is the preferred way
of starting a Gradle build.
I'm trying to build(not develop) an android application on server. I've the whole native android code on the server, which I need to build according to some modification done on the server.
I've been looking all over the internet but couldn't find any detailed solution. All I got to know was I might need Jenkins or some CI tool (which I think is time consuming as I'll need to get them installed on server and then all the android dependencies).
Initial idea was to build the .apk file via some python script which contains all the gradle commands in it.
How can i do this?
Android apps can be built easily on a system that doesn't have any Android tools installed by applying the Android SDK Manager plugin for Gradle to your project.
When running ./gradlew assembleDebug (or whatever task), then Gradle will be installed and then all Android dependencies, including the SDK tools, build tools, platform versions and other dependencies will be installed automatically.
You can run this simply on the command line yourself, or automate to run after every commits to source control easily with Jenkins (it's easy to install on a wide range of operating systems).
You need to install Stand-alone SDK tools and suitable SDK packages to your server to build Android software.
When you have all installed and good, you can build APK with gradle , e.g.
(Linux and Mac)
./gradlew assemble
I am trying to run a test and get coverage for an Android application I developed, and because this is for research purposes, I would also like to be able get coverage for the Android source code being call as well as coverage for my application under test. I followed some advice on another question I asked and am currently trying to use Ant.
I ran
ant emma debug install test
in my test but it gave me the following error:
BUILD FAILED
/scratch/android-sdk-linux/tools/ant/build.xml:377: The Android Ant-based build
system requires Ant 1.8.0 or later. Current version is 1.7.1
I went online and installed the latest version of Ant directly from the Apache website, but now I've realized that I need to upgrade the version of Ant in the SDK directory. I haven't just simply copy and pasted because I had a feeling that would mess up with the paths in the configuration that are probably called when commands such as above are called.
What I want to know is if there is a way to update specifically the version of Ant contained in the Android SDK?
Thanks.
EDIT: I tried changing the Ant classpath in Eclipse Juno to where I stored a version of Ant 1.8.4. However, I still get the error that the current version 1.7.1. At this point, I'm sure that I need to probably change settings somewhere in Eclipse for this to work, but how?
I am not sure, if we just use different SDKs, but my android SDK doesn't contain any ant itself :)
Just some ant build files, but the normal ant installed is used. So I would assume, that you did something wrong, with upgrading ant. If you enter in your console ant -v it should print out the version. As long as this version isn't larger or equal than 1.8.0, something with the upgrade has gone wrong.
I recently upgraded the Android SDK on our build machine, and now Android builds using Ant fail with the obscure message:
The <apply> type doesn't support the nested "path" element.
Our build.xml is the standard one generated by Android tools, and we automatically run
android update project -p .
before Ant runs the debug task.
The error message appears during the -dex phase of the build process.
Since this buildfile is using one of the standard Android templates, I'm not sure what's causing this change in behavior. Any ideas?
Never mind, I figured it out. Seems that Android version 8 or higher now require you to have ant 1.8 or higher (I was still using 1.6.5). The fix was simply to upgrade my ant installation to the latest version.