I want to automatically increase the version and build number in my kotlin projects. For my iOS applications, fastlane solves my problem with the plugin it offers. but I don't know how to do this in my android projects. maybe there is a gradle plugin? can you help me
I like ReactiveCircus/app-versioning. It reads Git tags to set Android's versionCode and versionName. The default behavior works great and you may create custom rules if needed.
Related
I'm working on an Android app that gets built into the system image, and I'd like to add Kotlin support to it.
Currently it builds with Gradle (regular development) and make (Android.mk, system build). Adding Kotlin support to Gradle is very smooth, but I'm stuck on the make based parts. I'm thinking of moving the make based parts to Soong, after seeing that it's somewhat similar to Bazel (at least semantically, what about feature wise?), which seems to support building Android apps. I realize this is a rare setup, and I haven't found any examples where Kotlin is used with make or Soong.
With the latest AOSP it's now possible to build system apps written in Kotlin with Soong, with some limitations. See https://github.com/jzoran/kotlin-privapp for more details.
I have a QtApp on android which builds using ant. This is working fine.
BUT ----> To regularly update my app on google Playstore I need to increment the version number of the app. I found that gradle has a nice way to increment the version number. But I see that gradle pulls in a lot of other complexities. I want to keep this simple with ant as it is working.
Isn`t there a simple way to increment the version number using ant without indulging gradle ?
Should I really consider switching from ant to gradle ? Are there many strong reasons of using gradle on android ?
You can set versionCode & versionName in manifest directly. By
the way gradle does same thing, it just merges your manifest with
generation of additional fields according to build.gradle file
You should definetely use gradle, it has a lot of features in comparison with ant. Android Studio supports gradle fully, it is more customizable, more flexible, than ant. You could easily transfer project across your team, but with ant this could lead to a lot of headache with dependencies conflicts. So loading dependencies on a fly it's a gradle feature and it helps a lot. I haven't written more, because you can check all gradle features yourself. I've just given you a council
My ultimate goal is to be able to write Clojure apps for Android, using Android Studio and Cursive. I started with leiningen but found out that it is a build system that is independent of what Andoid Studio uses ie Gradle. So I tried leiningen with Intellij, but couldn't get Android deploys to work except from the command line. Since I wanted to integrate with Android Studio, I decided to try Graclj: https://github.com/graclj/graclj which is a Gradle plugin for Clojure.
I can get the Graclj tutorial running in Android Studio, as per this guide:
https://github.com/graclj/learning-graclj/tree/learning-0.1.0
However:
Graclj expects the Clojure src and built classes and jars to be in the root project
Android Studio expects src and classes to be in the app subproject
After the tutorial I end up with separate Gradle build tasks for Graclj and Android Studio but I don't know how to integrate them
So, can anyone suggest a way that I can hook into Andoid Studio's build process?
Do I need to change some settings to the Graclj plugin to do this? If so, how?
Do I need to change some Android Studio plugin settings?
Do I need to add/change something in the Gradle build scripts?
Am I heading down a dead end? ;-)
I have looked at the Android Studio build process: http://developer.android.com/tools/building/configuring-gradle.html
but I don't know enough about Gradle to know what I'm supposed to be doing here.
If I need to supply any more info, just ask.
Any help appreciated!
Unfortuantely, I don't have any Android (let alone Android Studio) experience. However, I'll do my best to answer based on Gradle/Graclj knowledge.
Graclj does not require you to use the root project. You can apply the plugin(s) in any of the projects that you have in your build. However, I don't know how well a model-based plugin like Graclj will work with the "traditional" Android plugin. You could try the "experimental" one that's using the model approach, though there's a decent chance that it won't be compatible unless there's one that works with Gradle 2.12.
Alternatively, you might be able to add a dependency to the Android app project on the JAR produced by Graclj (which you may still want to put in a project besides the root). Not sure if there's a very good way to do this (haven't tried myself).
dependencies {
// my-other-proj being whichever one you use Graclj in
compile project(':my-other-proj')
}
Or maybe you would need to add it to a configuration first in the my-other-proj to interop with traditional plugins:
artifacts {
archives createMainJar
}
It is possible that you're at a dead end (for now). Graclj is very new, so this stuff should all be possible eventually.
I have updated my Cordova project so it now uses cordova-android#4.0.0. So far it seems good but I cannot work out some things which I need to know in order to create an APK.
The newest version utilises gradle and creates an Android Studio compatible project - great! Also, you can use the new Crosswalk WebView which I decided I need to because I have seen increasing issues on older devices (typically pre-Android KitKat - 4.3 and lower). So Crosswalk seems to have overcome the issues I had and comes with a marginally noticeable increase in speed.
Anyway, a couple of issues/confusion I have been having with regards to cordova-android#4.0.0/gradle/Android Studio:
My armv7 APK created has now inflated from a moderate 8MB to 28MB! The www folder is the same - is there any chance it's duplicating these in the APKs generated? If not, why is it so big?
versionCode - the app version is set in config.xml - mine is set to 4.9.1.2. When cordova generates the versionCode (used in the AndroidManifest.xml) - Cordova has a weird parsing rule which replaces the periods '.' with '0's - but only for the first three values. So 4.9.1.2 becomes 40902. In existing versions of Cordova, you could manually edit AndroidManifest.xml and supply your own value - and Eclipse build would not overwrite this.
I have a feeling either Gradle or Android Studio is overwriting this - I cannot workout which. Please can somebody explain as I need to fix this come go-live otherwise the versionCode will not supersede my current live version of my app!
Gradle options - how do I set these!? There seem to be two places. I can either:
Run the following command (I will explain the extra flags in point (4))
cordova build android --gradle --release --versionCode=49120 --gradleArg=PcdvBuildMultipleApks=false
Or
Create a file named gradle.properties and place the following two properties in there:
cdvBuildMultipleApks=false
cdvVersionCode=49120
Both methods explained: https://cordova.apache.org/docs/en/edge/guide_platforms_android_tools.md.html#Android%20Shell%20Tool%20Guide_building_with_gradle
This point kinda ties in (2) and (3) - but if I can set those two options, I think I can overcome my two issues explained above! Although as a side not, the documentation states by default cdvBuildMultipleApks is set to false, but it isn't - in CordovaLib, the gradle build file sets it to true if it is null - am I missing something obvious here?
Final point and question! If I run cordova build android this builds my project with gradle - good! If I then open Android Studio and my project, whenever I export a signed APK, it also runs through some gradle scrips - are the two builds the same process? Do I need to run cordova build or does Android Studio essentially run it for me?
A long thread but I think just a few teething issues with cordova-android#4.0.0 and gradle so if you could clarify, that would be greatly appreciated.
The Crosswalk contains compiled version of browser, that's why APK size increases by 12MB.
The versionCode calculated by Android Studio, but could be overriden by the Gradle property cdvVersionCode
When running build from the command line you could override cdvVersionCode by using following command
cordova build android -- --gradleArg=-PcdvVersionCode=49120
Most likely you miss - before Pcdv... when specify --gradleArg
Second method with additional file is also viable. choose whatever will work for you.
To set multiple Gradle options, use
cordova build android -- --gradleArg=-PcdvVersionCode=49120 --gradleArg=-PcdvBuildMultipleApks=true
The cordova build android and Android Studio both use Gradle to build Cordova project. They both interchangeable.
You can also set the versionCode explicitly by:
<widget android:versionCode="123">
in your config.xml.
To help alleviate the APK size increased caused by Crosswalk, you can opt to use Crosswalk only for pre-L Android versions (or for pre-kitkat if you find that webview good enough). Since L has an updatable webview, it almost certainly use a version of Chromium that is the same or newer than the one Crosswalk bundles. Details in plugin README, but pasted here for convenience as well:
To build Crosswalk-enabled apks, add crosswalk plugin and run:
$ cordova build --release
To build System-webview apk, remove crosswalk plugin and run:
$ cordova build --release -- --android-minSdkVersion=21
I have a published app that I use daily, installed on my phone. I also want/need to continue developing it, and I debug on the same phone (no emulator). Using eclipse, is the best solution for me to rename the updated package while I build and debug it so that I can continue to use the old version, or is there another way? If that is the solution, can I refactor a package name or do I have to change all of those manually?
I did search, and don't believe this is a duplicate as I do not want to publish multiple versions of the app. This would just be for me, and I am rooted if it would help my cause.
What has worked out great for me is using Android Library projects. I've got a Paid, Free and a dev version of my app which all use the same codebase.
My main codebase is an Android Library Project and I created other projects for the various versions. Then in your Application class, you differentiate between which version you're on to determine if you need different functionality. In your case, you'll just have a different package name.
Here's some links to get you started if you wanted to go that route. It's worked great for me, and I didn't want to go the route of Ant scripts:
http://developer.android.com/guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject
http://blog.donnfelker.com/2010/08/05/howto-android-full-and-lite-versions/
http://www.marvinlabs.com/2011/01/sharing-code-full-lite-versions-application/
There's a refactor-Menu for renaming classes and functions, so the refactoring should be pretty easy. But I'd go the other way around and rename the stable application once on your phone instead of renaming every build you do - that way, you only have to rename the stable application once you want to update to a new stable version.
At university, we had a similar problem and built a small build-script, which would copy and rename libraries, etc. to the appropriate location (in our case, we wanted to handle iOS and Android-builds from the same source, so the build-script had to build some configuration files from configuration templates, too). Unfortunatly, Eclipse does not provide an easy way to define pre-build scripts via a project's options or something similar (as VisualStudio does).
You can do this easily with the maven Android plugin. Of course, it carries the additional overhead of having to use maven just for this purpose, but it's super easy, and you don't have to move ANYTHING around.
<properties>
<androidManifestFile-location>${project.build.directory}/AndroidManifest.xml</androidManifestFile-location>
<outputApk>${project.build.directory}/${ota-dir}/${application.name.forapk}-${project.version}.${project.packaging}</outputApk>
<debug-signing>false</debug-signing>
<android.renameManifestPackage>${target.package}</android.renameManifestPackage>
</properties>
As long as the ${target.package} keys are different between "installations", you can install the apps side by side.