Using Ant to Automate Building Android Applications
Using Ant to Automate Building Android Applications
Step1:在命令行进入到需要打包项目目录。
Step2:android update project --path,这样在工程目录下会生成build.xml文件。
Here is an example of successful output:
>android update project --path .
Updated local.properties
Added file C:\dev\blog\antbuild\build.xml
Now you will have a working ant build script in build.xml. You can test your setup by typing ant at the command prompt, and you should receive something similar to the following boilerplate help:
>ant
Buildfile: C:\dev\blog\antbuild\build.xml
[setup] Android SDK Tools Revision 6
[setup] Project Target: Android 1.5
[setup] API level: 3
[setup] WARNING: No minSdkVersion value set. Application will install on all Android versions.
[setup] Importing rules file: platforms\android-3\ant\ant_rules_r2.xml
help:
[echo] Android Ant Build. Available targets:
[echo] help: Displays this help.
[echo] clean: Removes output files created by other targets.
[echo] compile: Compiles project's .java files into .class files.
[echo] debug: Builds the application and signs it with a debug key.
[echo] release: Builds the application. The generated apk file must be
[echo] signed before it is published.
[echo] install: Installs/reinstalls the debug package onto a running
[echo] emulator or device.
[echo] If the application was previously installed, the
[echo] signatures must match.
[echo] uninstall: Uninstalls the application from a running emulator or
[echo] device.
BUILD SUCCESSFUL
If the ant command is not found, then you need to update your path. Like above, on Windows use set path=%PATH%;C:\dev\apache-ant-1.8.1\bin (substituting your actual Ant installation directory), or even better update your environment variables.
At this point you should be able to type ant release at the command prompt, which will build the project, placing the unsigned .apk file inside of the bin/ directory.
Note that the output from Ant will show further instructions under -release-nosign: which says to sign the apk manually and to run zipalign. We'll get to these steps later in the signing section below.
Creating a new project with build.xml
If you've already created your project and followed the above instructions, you can skip this section. If not, you can may either create a new Android project using the regular Eclipse method (via New > Other... > Android Project), and follow the instructions in the above section, or you can use the command line as described here.
android create project --name YourProjectName --path C:\dev\YourProject --target android-3 --package com.company.testproject --activity MainActivity
Here is an example of successful output:
>android create project --name YourTestProject --path c:\temp\TestProject --target android-3 --package com.company.testproject --activity MainActivity
Created project directory: c:\temp\TestProject
Created directory C:\temp\TestProject\src\com\company\testproject
Added file c:\temp\TestProject\src\com\company\testproject\MainActivity.java
Created directory C:\temp\TestProject\res
Created directory C:\temp\TestProject\bin
Created directory C:\temp\TestProject\libs
Created directory C:\temp\TestProject\res\values
Added file c:\temp\TestProject\res\values\strings.xml
Created directory C:\temp\TestProject\res\layout
Added file c:\temp\TestProject\res\layout\main.xml
Added file c:\temp\TestProject\AndroidManifest.xml
Added file c:\temp\TestProject\build.xml
Note: To see the available targets, use android list target and you should see something like:
>android list target
id: 1 or "android-3"
Name: Android 1.5
Type: Platform
API level: 3
Revision: 4
Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P
In the above case, you can use either 1 or android-3 as the target ID. In the sample project, I chose android-4, which corresponds to Android 1.6.
Once the project is created, you can test if your project build is setup correctly by typing ant at the command line. See the above section for further instructions.
Synchronizing with Eclipse
If you open the Ant build script, build.xml, in Eclipse, you will see an error on the second line of the file at this line: <project name="MainActivity" default="help">. The problem with this line is that it is saying that the default Ant target is "help", but the actual Ant targets used in the build file are imported from another location, which the Eclipse editor does not recognize. The import is done at the line <taskdef name="setup", which imports Ant files from the Android SDK.
Unfortunately, while this error is active in your project, you cannot debug your project from Eclipse, even though the Ant build.xml is not needed. There are two solutions. You can remove default="help" from the file, which will remove the error in Eclipse. If you do this, and type ant at a command prompt without any targets (as opposed to "ant release"), you won't get the default help. Or, you can copy the imported Ant files directly into your code, which is exactly what you must do if you would like to customize your build. If you follow this tutorial, you won't have to worry about this error. See the Customizing the build section for more information.
Automatically signing your application
Before an application can be delivered to a device, the package must be signed. When debugging using Eclipse, the package is technically signed with a debugging key. (Alternatively, you can build a debug package using ant debug) For actual applications delivered to the Android Marketplace, you need to sign them with a real key. It is useful to put this step into the build process. On top of the ease of automating the process, it allows you to build your application in one step. (One-step builds are a Good IdeaTM)
If you have not already created a key, you can do so automatically using Eclipse (Right click project > Android Tools > Export Signed Application Package...), or follow the instructions here.
Now we must tell the build script about our keystore. Create a file called build.properties in your project's base directory (in the same directory as build.xml and the other properties files), if it does not already exist. Add the following lines:
key.store=keystore
key.alias=www.androidengineer.com
Where keystore is the name of your keystore file and change the value of key.alias to your keystore's alias. Now when you run ant release, you will be prompted for your passwords, and the build will automatically sign and zipalign your package.
Of course, having to enter your password doesn't make for a one-step build process. So you could not use this for an automated build machine, for one thing. It also has the disadvantage of requiring you to type the password, which it will display clearly on the screen, which may be a security issue in some circumstances. We can put the passwords into build.properties as well, which will solve the issue:
key.store.password=password
key.alias.password=password
Caution: There can be several issues with storing the keystore and passwords. Depending on your organization's security policies, you may not be able to store the passwords in version control, or you may not be able to give out the information to all developers who have access to the source. If you want to check in the keystore and the build.properties file, but not the passwords, you can create a separate properties file which could only be allowed on certain machines but not checked in to version control. For example, you could create a secure.properties file which goes on the build machine, but not checked in to version control so all developers wouldn't have access to it; import the extra properties file by adding <property file="secure.properties" /> to build.xml. Finally, you could always build the APKs unsigned with ant release by not adding any information to the properties files. The package built using this method will need to be signed and aligned.
Customizing the build
Now that we've got a working Ant build script, we can create a one-step build. But if we want to customize the build further, we'll have to do a few extra steps. You can do anything with your build that you can do with Ant. There are a few things we'll have to do first.
The Ant targets are actually located in the Android SDK. The targets are what you type after ant on the command line, such as release, clean, etc. To customize the build further, we need to copy the imported targets into our own build file.
If you look in build.xml, you can see the instructions for how to customize your build steps:
The rules file is imported from
<SDK>/platforms/<target_platform>/templates/android_rules.xml
To customize some build steps for your project:
- copy the content of the main node <project> from android_rules.xml
- paste it in this build.xml below the <setup /> task.
- disable the import by changing the setup task below to <setup import="false" />
Find the android_rules.xml file in your Android SDK. For example, mine is located at C:\dev\android-sdk-windows\platforms\android-4\templates. There, copy almost the entire file, excluding the project node (copy below <project name="MainActivity"> to above </project>), and paste it in your build.xml file. Also, change the line <setup /> to <setup import="false"/>.
Now you can change around the build as you please. Test that the build file is still working properly by running a build. For an example of what you can do with the custom build script, see the next section.
Using a Java configuration file
This is a great way to use a build property to affect the source code of your Android application. Imagine a configuration class in your project which sets some variables, such as a debugging flag or a URL string. You probably have a different set of these values when developing than when you release your application. For example, you may turn the logging flag off, or change the URL from a debugging server to a production server.
public class Config
{
/** Whether or not to include logging statements in the application. */
public final static boolean LOGGING = true;
}
It would be nice to have the above LOGGING flag be set from your build. That way, you can be sure that when you create your release package, all of the code you used for debugging won't be included. For example, you may have debugging log statements like this:
if (Config.LOGGING)
{
Log.d(TAG, "[onCreate] Success");
}
You will probably want to leave these statements on during development, but remove them at release. In fact, it is good practice to leave logging statements in your source code. It helps with later maintenance when you, and especially others, need to know how your code works. On the other hand, it is bad practice for an application to litter the Android log with your debugging statements. Using these configuration variables allows you to turn the logging on and off, while still leaving the source code intact.
Another great advantage of using this method of logging is that the bytecode contained within the logging statement can be completely removed by a Java bytecode shrinker such as ProGuard, which can be integrated into your build script. I'll discuss how to do this in a later blog post.
A nice way to set the Config.LOGGING flag is in your build properties. Add the following to build.properties:
# Turn on or off logging.
config.logging=true
To have this build property be incorporated into our source code, I will use the Ant type filterset with the copy task. What we can do is create a Java template file which has tokens such as @CONFIG.LOGGING@ and copy it to our source directory, replacing the tokens with whatever the build properties values are. For example, in the sample application I have a file called Config.java in the config/ directory.
public class Config
{
/** Whether or not to include logging statements in the application. */
public final static boolean LOGGING = @CONFIG.LOGGING@;
}
Please note that this is not a source file, and that config/Config.java is notthe actual file used when compiling the project. The file src/com/yourpackage/Config.java, which is the copied file destination, is what will be used as a source file.
Now I will alter the build file to copy the template file to the source path, but replace @CONFIG.LOGGING with the value of the property config.logging, which is true. I will create an Ant target called config which will copy the above template to the source directory. This will be called before the compile target.
<!-- Copy Config.java to our source tree, replacing custom tokens with values in build.properties. The configuration depends on "clean" because otherwise the build system will not detect changes in the configuration. -->
<target name="config">
<property name="config-target-path" value="${source.dir}/com/androidengineer/antbuild"/>
<!-- Copy the configuration file, replacing tokens in the file. -->
<copy file="config/Config.java" todir="${config-target-path}"
overwrite="true" encoding="utf-8">
<filterset>
<filter token="CONFIG.LOGGING" value="${config.logging}"/>
</filterset>
</copy>
<!-- Now set it to read-only, as we don't want people accidentally
editing the wrong one. NOTE: This step is unnecessary, but I do
it so the developers remember that this is not the original file. -->
<chmod file="${config-target-path}/Config.java" perm="-w"/>
<attrib file="${config-target-path}/Config.java" readonly="true"/>
</target>
To make this Ant target execute before the compile target, we simply add config to the dependency of compile: <target name="compile" depends="config, -resource-src, -aidl". We also make the config target call clean, because otherwise the build system will not detect changes in the configuration, and may not recompile the proper classes.
Note: The above Ant task sets the target file (in your source directory) to read-only. This is not necessary, but I add it as a precaution to remind me that it is not the original file that I need to edit. When developing, I will change the configuration sometimes without using the build, and Eclipse will automatically change the file from read-only for me. I also do not check in the target file into version control; only the original template and build.properties.
Version control
Do not check in the local.properties file which is generated by the Android build tools. This is noted in the file itself; it sets paths based on the local machine. Do check in the default.properties file, which is used by the Android tools, and build.properties, which is the file which you edit to customize your project's build.
I also don't check in the target Config.java in the source directory, nor anything else is configured by the build. I don't want local changes to propagate to other developers, so I only check in the original template file in the config/ directory.
In my projects, when I release a new version of a project I always check in the properties file and tag it in the source repository with a tag name such as "VERSION_2.0". That way we are certain of what properties the application was built with, and we can reproduce the application exactly as it was released, if we later need to.
Summary
1. At the command line run android create project, or android update project in your project base directory if it already exists.
2. (Optional) Add key.store and key.alias to build.properties if you want to include the signing step in your build.
3. (Optional) Add key.store.password and key.alias.password to build.properties if you want to include the keystore passwords, to make the build run without any further input needed.
4. (Optional) If you would like to further customize the build, copy the SDK Ant build code from <SDK>/platforms/<target_platform>/templates/android_rules.xmlto your local build.xml and change <setup /> to <setup import="false"/>.
5. Use ant release to build your project. It will create the package in bin/.
Sample Application
The sample application is a simple Hello World application, but it also includes the custom build script as described in this tutorial. It also includes the Config.java which is configurable by the build. First, you must run "android update project -p ." from the command line in the project's directory to let the tools set the SDK path in local.properties. Then you can turn on and off logging by changing the value of config.logging in build.properties. Finally, run ant release to build the application, which will create the signed bin/MainActivity-release.apk file ready to be released.
Project source code - antbuild.zip (13.4 Kb)
Posted by Matt Quigley at 2:41 AM
Email ThisBlogThis!Share to TwitterShare to Facebook
Labels: ant, build
55 comments:
Adecus said...
When I run ant release I get all kinds of errors because it can't find any of the dependencies. Is there an easy way to include the project dependencies or do I have to manually include them by modifying build.xml? (I have dependencies to jar files and other java projects)
I thought the whole point of using the eclipse project to build is because it knows about dependencies and the full project structure, otherwise I mind as well just manually make javac calls with all the dependencies included.
August 23, 2010 at 10:05 AM
Matt Quigley said...
@Adecus
If your project builds correctly in Eclipse, and after that you create the build file using the "android update" command but the build file doesn't work, then I suppose the Android tools which create the project do not support automatically adding dependencies to the build file. You probably have to manually update it.
August 23, 2010 at 11:57 AM
Adecus said...
I will try that.
Also, well written informative post, thank you.
August 23, 2010 at 12:16 PM
Armen B. said...
I was having issues referencing a libaray project. I found this info helpful:
http://www.listware.net/201006/android-developers/56532-android-developers-android-library-broken.html
August 30, 2010 at 6:51 PM
vgps said...
Thanks a lot for this useful article.
August 31, 2010 at 10:34 AM
Armen B. said...
Does anyone know how to use ant to build an app that is link sourced to a library project? Thanks.
September 2, 2010 at 2:15 PM
Anonymous said...
Very useful tutorial. Had to properly set the JAVA_HOME (without blanks) and PATH, but once figured out, it worked out well on Win7. Thanks!
September 20, 2010 at 6:21 PM
Text Tool said...
Great article and great blog! Thanks for your lessons, I find them really useful.
September 24, 2010 at 1:10 PM
Anonymous said...
After letting Eclipse update the add-on, I ended having issues building with ant (despite having no problem right before it). Based on some posts I found (from Google staff), changes that are *not* backward-compatible (thank you!) were introduced in the build process. The solution for my project was not to use android_rules.xml to modify build.xml, but rather ant_rules_r3.xml (under /tools/ant). I could apply the other tasks (e.g. config) and it worked fine.
September 24, 2010 at 5:59 PM
alex said...
how do I specify the library .jar files that are located in the project's \lib folder ?
Is there anything I need to do for the .so files in the project's \libs\armeabi folder ?
Currently I get a lot of errors like: "package org.anddev.andengine.engine does not exist"
Eclipse built it fine, but Ant doesn't know about the \lib it seems like.
October 10, 2010 at 4:43 AM
Alex said...
the solution was to copy the andEngine library JAR's to the \libs folder (I had them in \lib)
October 10, 2010 at 5:26 AM
Owen said...
Hi Matt,
excellent article. I have only ever used Eclipse for developing and releasing projects for android, until the use of LVL and Progard became a must have, for security.
I am using Flurry Analytics in my code, so when I process android update and create a build.xml and local.properties file with required changes, I proceed with ant release. Problem is, I am getting "package com.flurry.android not found" error messages. Can you possibly explain why I might be having this problem and what I may be doing wrong? Should I include the Flurry.jar location in my build or properties files?. Your help would be greatly appreciated.
October 11, 2010 at 11:01 AM
Matt Quigley said...
@Owen
I can't tell if you're getting those errors at runtime or during the build. In any case, the default folder where additional libraries go is ./libs/. You might want to try copying the library file (which I guess is a .jar file) into that folder. Or you could try changing build properties to change the default library directory, but I'd suggest getting it working by moving the .jar file first.
October 11, 2010 at 9:54 PM
Owen said...
Hi Matt,
Sorry, I should have explained the problem was in the build. But.....
Thanks a million you are a star. Everything worked fine. I also should have noted the post previous to mine (Alex) where he had and resolved the same problem.
Google needs competent support people like you...Keep up the good work. I think it is appreciated by all.
October 13, 2010 at 7:03 AM
Owen said...
Hi Matt,
I am having alot of problems trying to include the Licensing service in my Ant buid.
I am getting the message:
"com.android.vending.licensing does not exist."
"import com.android.vending.licensing.AESObfuscator;"
default.properties file entry in MyMainProject
android.library.reference.1=c:\\Users\\LeOwen\\LiveProject\\library
-----------------------------------
default.properties file entry in com.android.vending.licensing
android.library=true
target=android-8
--------------------------------
Altough I have read the google documentation I am still having no luck.
Can you possibly tell me what other requirements I need to take into consideration for this to work?
October 15, 2010 at 1:10 PM
Matt Quigley said...
@Owen
Is this a build or a runtime error, "com.android.vending.licensing does not exist."?
Also, have you tried just copying the appropriate library files into the default libs folder? If you can get that to work, then the problem is how you're configuring the new library folder. If you can't, then it sounds like there may be additional problems that I could help with.
I use a library in my project at work, and it works fine, at least with the API level 7 and below build setups. But this may be something special with the craziness that the licensing library has to do, and if so, I will look into it further if you give me a little more insight into how you've setup the project. I'll try incorporating the licensing library into the sample project myself. Be sure to tell me everything I need to try to do so, such as where to download it.
October 16, 2010 at 12:16 PM
Owen said...
Hi Matt,
I have resolved the problem with the LVL library and Proguard using the ANT build method. because Ofuscating is included, I have decided to put the full description in your Optimizing, Obfuscating and Shrinking Post.
October 29, 2010 at 6:40 AM
Owen said...
The following process was used to Build, Optimize, Obfuscate and Shrink an android app
if using windows and eclipse. I Created a separate project from eclipse to avoid corruption that may be caused by typos or incorrect
project configuration set-up.
1.
Create a project root directory and copy the files from eclipse as follows:
AndroidMainfest.xml
CLASSPATH file
PROJECT file
default.properties
Add your my.keystore to the root directory
2.
Copy the eclipse directories into the project root directory as follows:
assets
bin
gen
res
src
3.
Create a libs directory and copy any library *.jar files to the directory.
If you are using flurry, this may be one of them.
4.
Create a proguard directory.
copy the proguard.jar file to the directory.
create and edit the proguard config.txt file according to documentaion and your project requirements.
If libs is not included in the proguard process at the bottom of build.xml file, then it should be included
in the config.txt file as follows:
-libraryjars path/to/your/libs
The LVL -keep statement must also be included:
-keep class com.android.vending.licensing.ILicensingService
Put config.txt in the proguard directory.
5.
locate the market_licensing\libary directory located in your eclipse project and copy to
your Project path.
The final Project Path setup should consist of:
PROJECTROOT
assets
bin
gen
res
src
libs (*.jars)
library (Android LVL)
proguard
6.
Ensure a path to the android.sdk-windows/tools directory has been set up or cd to the location.
enter android update project --path C:\path\to\your\project
A local.properties and build.xml file will be created in the project rood directory.
7. build.xml
You may need to edit and tailor the build.xml file for your project requirements. I copied
the ant_rules_r3.xml file located in android-sdk-windows\tools\ant into the build file, and set
setup import="false"
8. build.properties file
Any configuration changes are placed in this file.
Include the android LVL library path as follows:
android.library.reference.1=library
To automate your signing process, add the keystore and password statements (depending on your site restrictions)
key.store=your.keystore
key.alias=youralias
key.store.password=yourkeystorepassword
key.alias.password=youraliaspassword
If the above instructions are followed or the project configuration has been set up according to your
own requirements, then navigate to your Project root directory and enter.
ant release
The build should complete successfully.
I put most of the above in a batch script to automate the process. You also don't need to create
a separate project if you feel confident with what is in place from eclipse, but you will have
to include proguard and libs in your eclips project path and you won't have control of buid.xml or build properties
for external sources. It is up to you.
Good luck.
October 29, 2010 at 11:39 AM
Owen said...
The following process was used to Build, Optimize, Obfuscate and Shrink an android app
if using windows and eclipse. I Created a separate project from eclipse to avoid corruption that may be caused by typos or incorrect
project configuration set-up.
1.
Create a project root directory and copy the files from eclipse as follows:
AndroidMainfest.xml
CLASSPATH file
PROJECT file
default.properties
Add your my.keystore to the root directory
2.
Copy the eclipse directories into the project root directory as follows:
assets
bin
gen
res
src
3.
Create a libs directory and copy any library *.jar files to the directory.
If you are using flurry, this may be one of them.
4.
Create a proguard directory.
copy the proguard.jar file to the directory.
create and edit the proguard config.txt file according to documentaion and your project requirements.
If libs is not included in the proguard process at the bottom of build.xml file, then it should be included
in the config.txt file as follows:
-libraryjars path/to/your/libs
The LVL -keep statement must also be included:
-keep class com.android.vending.licensing.ILicensingService
Put config.txt in the proguard directory.
5.
locate the market_licensing\libary directory located in your eclipse project and copy to
your Project path.
The final Project Path setup should consist of:
PROJECTROOT
assets
bin
gen
res
src
libs (*.jars)
library (Android LVL)
proguard
6.
Ensure a path to the android.sdk-windows/tools directory has been set up or cd to the location.
enter android update project --path C:\path\to\your\project
A local.properties and build.xml file will be created in the project rood directory.
7. build.xml
You may need to edit and tailor the build.xml file for your project requirements. I copied
the ant_rules_r3.xml file located in android-sdk-windows\tools\ant into the build file, and set
setup import="false"
8. build.properties file
Any configuration changes are placed in this file.
Include the android LVL library path as follows:
android.library.reference.1=library
To automate your signing process, add the keystore and password statements (depending on your site restrictions)
key.store=your.keystore
key.alias=youralias
key.store.password=yourkeystorepassword
key.alias.password=youraliaspassword
If the above instructions are followed or the project configuration has been set up according to your
own requirements, then navigate to your Project root directory and enter.
ant release
The build should complete successfully.
I put most of the above in a batch script to automate the process. You also don't need to create
a separate project if you feel confident with what is in place from eclipse, but you will have
to include proguard and libs in your eclips project path and you won't have control of buid.xml or build properties
for external sources. It is up to you.
Good luck.
October 29, 2010 at 11:41 AM
Premier said...
Can you give me an example for ant build.xml with android library project?
Thanks
December 3, 2010 at 12:32 PM
cisnky said...
A very useful article. Thanks!!!
February 20, 2011 at 11:11 AM
Jay Khimani said...
Very nice and useful post. Thanks
March 6, 2011 at 3:02 PM
Can Elmas said...
Very useful and informative. Thank you.
March 9, 2011 at 7:24 AM
Anonymous said...
Very helpfull! Thanks!
March 15, 2011 at 8:52 AM
Alex said...
Make sure to use the following rules file instead of the one in the platform\template folder, otherwise you will get build errors like aaptexec doesn't support the "basename" attribute:
android-sdk\tools\ant\main_rules.xml
April 22, 2011 at 11:13 AM
Kumar Bibek said...
Thanks a lot.
April 29, 2011 at 12:10 AM
Kamesh Kompella said...
The article is well written. However, the following must be kept in mind to avoid the baseline and other errors people have reported. I spent an hour getting this to work and finally discovered the problem as detailed here:
http://stackoverflow.com/questions/4464461/compile-error-while-trying-to-compile-android-app-with-ant
May 4, 2011 at 2:31 AM
L`OcuS said...
You made my day.
Many thanks.
May 17, 2011 at 1:42 PM
Ajay LD said...
Thanks a lot!
June 15, 2011 at 3:11 AM
lambt said...
A very useful article. Thanks!
July 14, 2011 at 5:52 AM
soft llc said...
Thanks for the great post.
Here's a tip for using the android logger when the phone is not connected.
http://www.softllc.com/archives/125
August 8, 2011 at 11:56 AM
Anonymous said...
Awesome! Very informative.
September 14, 2011 at 1:10 AM
Piyush Patel said...
Kudos to u, Excellent stuff !!
I was able to setup my build system in less than hour.
Thanks a million ;D
September 23, 2011 at 8:49 AM
Kang Taro Gak Ngerti seo said...
i dont know why, so many people talking about android, and i dont know too, why steve jobs is very angry about this? can you mention to me?
October 29, 2011 at 2:35 PM
Basavraj said...
Very helpful for all Android developers
November 17, 2011 at 8:00 AM
apilyugina said...
Thanks a lot for your article! http://www.enterra-inc.com/techzone/ hope this coulsd be useful, too.
January 12, 2012 at 10:12 PM
Michael Totschnig said...
Thank you for this interesting article. There is one thing I am wondering about: You show how to set the logging flag from the build, but in order to be truly useful, IMHO you would need to have the build set the logging flag dependent on if you build for debug or release, for example by defining the filter with
What do yo think?
January 29, 2012 at 1:50 AM
Anonymous said...
Thanks for doing this article. I'm not sure why I found the official docs so intimidating--this is clear and easy!
I did find one change in the Android version I'm running.
Instead of putting the properties in build.properties, they need to be in ant.properties
(The docs say to do that now, at "Build signed and aligned" on
http://developer.android.com/guide/developing/building/building-cmdline.html#ReleaseMode )
Thanks again! This is a great timesaver!!
January 29, 2012 at 11:05 PM
Miguel said...
Thanks for the post, very insightful!
February 14, 2012 at 4:07 AM
Anonymous said...
Thanks for this useful post!!
March 25, 2012 at 5:25 PM
Juhani Lehtimäki said...
Great tutorial. This was very helpful Thank you for posting it!
May 18, 2012 at 8:02 AM
Yuval Dagan said...
That was agreat help for me
Thanks alot!!
June 26, 2012 at 2:53 AM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:52 PM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:54 PM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:55 PM
Gary Frederick said...
Great info. I am about to modify ant/Eclipse and this helps a lot.
July 28, 2012 at 9:12 AM
m0skito said...
Nice tutorial but an engineer using Windows... really? XD
October 30, 2012 at 9:17 AM
Vinoth P.s said...
could u pls elborate the same with the help pf Hudson, that would be more helpful
October 30, 2012 at 9:49 AM
Anonymous said...
Hello, I have been trying to execute the sample project given here. But when I build the 'build.xml' file I am getting this error-"taskdef class com.android.ant.SetupTask cannot be found". All the environment variables are set accordingly.I cant figure out the problem.Could you please help me out.
January 24, 2013 at 6:35 AM
Anonymous said...
buddy you have to setup this particular environment as path "android-home=[YOUR PATH HERE]"
until you specify the system doesn't know where the ant setup is, hope this will resolve this issue
January 24, 2013 at 11:15 PM
Anonymous said...
also check this link
http://blog.klacansky.com/matter-code/ant-taskdef-class-com-android-ant-setuptask-cannot-be-found
January 24, 2013 at 11:18 PM
Anonymous said...
How do you set the "config.logging" property to be true or false depending on what target you're building? (debug or release)
February 17, 2013 at 5:31 PM
Matt Quigley said...
> How do you set the "config.logging" property to be true or false depending on what target you're building? (debug or release)
See the sample project - the ant build script does it for you, depending on whether you are running the debug or release build.
February 18, 2013 at 3:35 AM
Unknown said...
This comment has been removed by the author.
May 3, 2013 at 5:35 PM
Guy Nicholas said...
Thanks for the article. I still have a question though.
We have a build machine for automated building/testing and that runs through an ant build script which I have setup to do a variety of things.
We also have Eclipse setup with C/C++ configurations of debug/release (this is a Java & NDK project), but what I need to do is be able to tie the C/C++ config to the Java side such that I can get the Java and C code on the same page so to speak. Have you done this?
Regards, Guy
May 3, 2013 at 5:36 PM
Post a Comment
Newer Post Older Post Home
Subscribe to: Post Comments (Atom)
Search This Blog
Loading...
Android Engineer
Loading...
Categories
ant (1)
build (1)
Themes (1)
UI (2)
Blog Archive
► 2011 (1)
► June (1)
▼ 2010 (4)
► August (1)
► July (1)
▼ June (2)
Using Ant to Automate Building Android Application...
Using Themes in Android Applications
About Me
MATT QUIGLEY
I am a software developer who has been working in the field of mobile software for 10 years now. Currently I'm involved in many exciting new Android projects.
VIEW MY COMPLETE PROFILE
Copyright © 2010 Android Engineer
先备注在这里，后面有时间在翻译和整理下，同学都可以看看，附上链接地址:
http://www.androidengineer.com/2010/06/using-ant-to-automate-building-android.html
可以参考下面链接：
http://www.cnblogs.com/stay/archive/2013/05/27/3102027.html
Step1:在命令行进入到需要打包项目目录。
Step2:android update project --path,这样在工程目录下会生成build.xml文件。
Here is an example of successful output:
>android update project --path .
Updated local.properties
Added file C:\dev\blog\antbuild\build.xml
Now you will have a working ant build script in build.xml. You can test your setup by typing ant at the command prompt, and you should receive something similar to the following boilerplate help:
>ant
Buildfile: C:\dev\blog\antbuild\build.xml
[setup] Android SDK Tools Revision 6
[setup] Project Target: Android 1.5
[setup] API level: 3
[setup] WARNING: No minSdkVersion value set. Application will install on all Android versions.
[setup] Importing rules file: platforms\android-3\ant\ant_rules_r2.xml
help:
[echo] Android Ant Build. Available targets:
[echo] help: Displays this help.
[echo] clean: Removes output files created by other targets.
[echo] compile: Compiles project's .java files into .class files.
[echo] debug: Builds the application and signs it with a debug key.
[echo] release: Builds the application. The generated apk file must be
[echo] signed before it is published.
[echo] install: Installs/reinstalls the debug package onto a running
[echo] emulator or device.
[echo] If the application was previously installed, the
[echo] signatures must match.
[echo] uninstall: Uninstalls the application from a running emulator or
[echo] device.
BUILD SUCCESSFUL
If the ant command is not found, then you need to update your path. Like above, on Windows use set path=%PATH%;C:\dev\apache-ant-1.8.1\bin (substituting your actual Ant installation directory), or even better update your environment variables.
At this point you should be able to type ant release at the command prompt, which will build the project, placing the unsigned .apk file inside of the bin/ directory.
Note that the output from Ant will show further instructions under -release-nosign: which says to sign the apk manually and to run zipalign. We'll get to these steps later in the signing section below.
Creating a new project with build.xml
If you've already created your project and followed the above instructions, you can skip this section. If not, you can may either create a new Android project using the regular Eclipse method (via New > Other... > Android Project), and follow the instructions in the above section, or you can use the command line as described here.
android create project --name YourProjectName --path C:\dev\YourProject --target android-3 --package com.company.testproject --activity MainActivity
Here is an example of successful output:
>android create project --name YourTestProject --path c:\temp\TestProject --target android-3 --package com.company.testproject --activity MainActivity
Created project directory: c:\temp\TestProject
Created directory C:\temp\TestProject\src\com\company\testproject
Added file c:\temp\TestProject\src\com\company\testproject\MainActivity.java
Created directory C:\temp\TestProject\res
Created directory C:\temp\TestProject\bin
Created directory C:\temp\TestProject\libs
Created directory C:\temp\TestProject\res\values
Added file c:\temp\TestProject\res\values\strings.xml
Created directory C:\temp\TestProject\res\layout
Added file c:\temp\TestProject\res\layout\main.xml
Added file c:\temp\TestProject\AndroidManifest.xml
Added file c:\temp\TestProject\build.xml
Note: To see the available targets, use android list target and you should see something like:
>android list target
id: 1 or "android-3"
Name: Android 1.5
Type: Platform
API level: 3
Revision: 4
Skins: HVGA (default), HVGA-L, HVGA-P, QVGA-L, QVGA-P
In the above case, you can use either 1 or android-3 as the target ID. In the sample project, I chose android-4, which corresponds to Android 1.6.
Once the project is created, you can test if your project build is setup correctly by typing ant at the command line. See the above section for further instructions.
Synchronizing with Eclipse
If you open the Ant build script, build.xml, in Eclipse, you will see an error on the second line of the file at this line: <project name="MainActivity" default="help">. The problem with this line is that it is saying that the default Ant target is "help", but the actual Ant targets used in the build file are imported from another location, which the Eclipse editor does not recognize. The import is done at the line <taskdef name="setup", which imports Ant files from the Android SDK.
Unfortunately, while this error is active in your project, you cannot debug your project from Eclipse, even though the Ant build.xml is not needed. There are two solutions. You can remove default="help" from the file, which will remove the error in Eclipse. If you do this, and type ant at a command prompt without any targets (as opposed to "ant release"), you won't get the default help. Or, you can copy the imported Ant files directly into your code, which is exactly what you must do if you would like to customize your build. If you follow this tutorial, you won't have to worry about this error. See the Customizing the build section for more information.
Automatically signing your application
Before an application can be delivered to a device, the package must be signed. When debugging using Eclipse, the package is technically signed with a debugging key. (Alternatively, you can build a debug package using ant debug) For actual applications delivered to the Android Marketplace, you need to sign them with a real key. It is useful to put this step into the build process. On top of the ease of automating the process, it allows you to build your application in one step. (One-step builds are a Good IdeaTM)
If you have not already created a key, you can do so automatically using Eclipse (Right click project > Android Tools > Export Signed Application Package...), or follow the instructions here.
Now we must tell the build script about our keystore. Create a file called build.properties in your project's base directory (in the same directory as build.xml and the other properties files), if it does not already exist. Add the following lines:
key.store=keystore
key.alias=www.androidengineer.com
Where keystore is the name of your keystore file and change the value of key.alias to your keystore's alias. Now when you run ant release, you will be prompted for your passwords, and the build will automatically sign and zipalign your package.
Of course, having to enter your password doesn't make for a one-step build process. So you could not use this for an automated build machine, for one thing. It also has the disadvantage of requiring you to type the password, which it will display clearly on the screen, which may be a security issue in some circumstances. We can put the passwords into build.properties as well, which will solve the issue:
key.store.password=password
key.alias.password=password
Caution: There can be several issues with storing the keystore and passwords. Depending on your organization's security policies, you may not be able to store the passwords in version control, or you may not be able to give out the information to all developers who have access to the source. If you want to check in the keystore and the build.properties file, but not the passwords, you can create a separate properties file which could only be allowed on certain machines but not checked in to version control. For example, you could create a secure.properties file which goes on the build machine, but not checked in to version control so all developers wouldn't have access to it; import the extra properties file by adding <property file="secure.properties" /> to build.xml. Finally, you could always build the APKs unsigned with ant release by not adding any information to the properties files. The package built using this method will need to be signed and aligned.
Customizing the build
Now that we've got a working Ant build script, we can create a one-step build. But if we want to customize the build further, we'll have to do a few extra steps. You can do anything with your build that you can do with Ant. There are a few things we'll have to do first.
The Ant targets are actually located in the Android SDK. The targets are what you type after ant on the command line, such as release, clean, etc. To customize the build further, we need to copy the imported targets into our own build file.
If you look in build.xml, you can see the instructions for how to customize your build steps:
The rules file is imported from
<SDK>/platforms/<target_platform>/templates/android_rules.xml
To customize some build steps for your project:
- copy the content of the main node <project> from android_rules.xml
- paste it in this build.xml below the <setup /> task.
- disable the import by changing the setup task below to <setup import="false" />
Find the android_rules.xml file in your Android SDK. For example, mine is located at C:\dev\android-sdk-windows\platforms\android-4\templates. There, copy almost the entire file, excluding the project node (copy below <project name="MainActivity"> to above </project>), and paste it in your build.xml file. Also, change the line <setup /> to <setup import="false"/>.
Now you can change around the build as you please. Test that the build file is still working properly by running a build. For an example of what you can do with the custom build script, see the next section.
Using a Java configuration file
This is a great way to use a build property to affect the source code of your Android application. Imagine a configuration class in your project which sets some variables, such as a debugging flag or a URL string. You probably have a different set of these values when developing than when you release your application. For example, you may turn the logging flag off, or change the URL from a debugging server to a production server.
public class Config
{
/** Whether or not to include logging statements in the application. */
public final static boolean LOGGING = true;
}
It would be nice to have the above LOGGING flag be set from your build. That way, you can be sure that when you create your release package, all of the code you used for debugging won't be included. For example, you may have debugging log statements like this:
if (Config.LOGGING)
{
Log.d(TAG, "[onCreate] Success");
}
You will probably want to leave these statements on during development, but remove them at release. In fact, it is good practice to leave logging statements in your source code. It helps with later maintenance when you, and especially others, need to know how your code works. On the other hand, it is bad practice for an application to litter the Android log with your debugging statements. Using these configuration variables allows you to turn the logging on and off, while still leaving the source code intact.
Another great advantage of using this method of logging is that the bytecode contained within the logging statement can be completely removed by a Java bytecode shrinker such as ProGuard, which can be integrated into your build script. I'll discuss how to do this in a later blog post.
A nice way to set the Config.LOGGING flag is in your build properties. Add the following to build.properties:
# Turn on or off logging.
config.logging=true
To have this build property be incorporated into our source code, I will use the Ant type filterset with the copy task. What we can do is create a Java template file which has tokens such as @CONFIG.LOGGING@ and copy it to our source directory, replacing the tokens with whatever the build properties values are. For example, in the sample application I have a file called Config.java in the config/ directory.
public class Config
{
/** Whether or not to include logging statements in the application. */
public final static boolean LOGGING = @CONFIG.LOGGING@;
}
Please note that this is not a source file, and that config/Config.java is notthe actual file used when compiling the project. The file src/com/yourpackage/Config.java, which is the copied file destination, is what will be used as a source file.
Now I will alter the build file to copy the template file to the source path, but replace @CONFIG.LOGGING with the value of the property config.logging, which is true. I will create an Ant target called config which will copy the above template to the source directory. This will be called before the compile target.
<!-- Copy Config.java to our source tree, replacing custom tokens with values in build.properties. The configuration depends on "clean" because otherwise the build system will not detect changes in the configuration. -->
<target name="config">
<property name="config-target-path" value="${source.dir}/com/androidengineer/antbuild"/>
<!-- Copy the configuration file, replacing tokens in the file. -->
<copy file="config/Config.java" todir="${config-target-path}"
overwrite="true" encoding="utf-8">
<filterset>
<filter token="CONFIG.LOGGING" value="${config.logging}"/>
</filterset>
</copy>
<!-- Now set it to read-only, as we don't want people accidentally
editing the wrong one. NOTE: This step is unnecessary, but I do
it so the developers remember that this is not the original file. -->
<chmod file="${config-target-path}/Config.java" perm="-w"/>
<attrib file="${config-target-path}/Config.java" readonly="true"/>
</target>
To make this Ant target execute before the compile target, we simply add config to the dependency of compile: <target name="compile" depends="config, -resource-src, -aidl". We also make the config target call clean, because otherwise the build system will not detect changes in the configuration, and may not recompile the proper classes.
Note: The above Ant task sets the target file (in your source directory) to read-only. This is not necessary, but I add it as a precaution to remind me that it is not the original file that I need to edit. When developing, I will change the configuration sometimes without using the build, and Eclipse will automatically change the file from read-only for me. I also do not check in the target file into version control; only the original template and build.properties.
Version control
Do not check in the local.properties file which is generated by the Android build tools. This is noted in the file itself; it sets paths based on the local machine. Do check in the default.properties file, which is used by the Android tools, and build.properties, which is the file which you edit to customize your project's build.
I also don't check in the target Config.java in the source directory, nor anything else is configured by the build. I don't want local changes to propagate to other developers, so I only check in the original template file in the config/ directory.
In my projects, when I release a new version of a project I always check in the properties file and tag it in the source repository with a tag name such as "VERSION_2.0". That way we are certain of what properties the application was built with, and we can reproduce the application exactly as it was released, if we later need to.
Summary
1. At the command line run android create project, or android update project in your project base directory if it already exists.
2. (Optional) Add key.store and key.alias to build.properties if you want to include the signing step in your build.
3. (Optional) Add key.store.password and key.alias.password to build.properties if you want to include the keystore passwords, to make the build run without any further input needed.
4. (Optional) If you would like to further customize the build, copy the SDK Ant build code from <SDK>/platforms/<target_platform>/templates/android_rules.xmlto your local build.xml and change <setup /> to <setup import="false"/>.
5. Use ant release to build your project. It will create the package in bin/.
Sample Application
The sample application is a simple Hello World application, but it also includes the custom build script as described in this tutorial. It also includes the Config.java which is configurable by the build. First, you must run "android update project -p ." from the command line in the project's directory to let the tools set the SDK path in local.properties. Then you can turn on and off logging by changing the value of config.logging in build.properties. Finally, run ant release to build the application, which will create the signed bin/MainActivity-release.apk file ready to be released.
Project source code - antbuild.zip (13.4 Kb)
Posted by Matt Quigley at 2:41 AM
Email ThisBlogThis!Share to TwitterShare to Facebook
Labels: ant, build
55 comments:
Adecus said...
When I run ant release I get all kinds of errors because it can't find any of the dependencies. Is there an easy way to include the project dependencies or do I have to manually include them by modifying build.xml? (I have dependencies to jar files and other java projects)
I thought the whole point of using the eclipse project to build is because it knows about dependencies and the full project structure, otherwise I mind as well just manually make javac calls with all the dependencies included.
August 23, 2010 at 10:05 AM
Matt Quigley said...
@Adecus
If your project builds correctly in Eclipse, and after that you create the build file using the "android update" command but the build file doesn't work, then I suppose the Android tools which create the project do not support automatically adding dependencies to the build file. You probably have to manually update it.
August 23, 2010 at 11:57 AM
Adecus said...
I will try that.
Also, well written informative post, thank you.
August 23, 2010 at 12:16 PM
Armen B. said...
I was having issues referencing a libaray project. I found this info helpful:
http://www.listware.net/201006/android-developers/56532-android-developers-android-library-broken.html
August 30, 2010 at 6:51 PM
vgps said...
Thanks a lot for this useful article.
August 31, 2010 at 10:34 AM
Armen B. said...
Does anyone know how to use ant to build an app that is link sourced to a library project? Thanks.
September 2, 2010 at 2:15 PM
Anonymous said...
Very useful tutorial. Had to properly set the JAVA_HOME (without blanks) and PATH, but once figured out, it worked out well on Win7. Thanks!
September 20, 2010 at 6:21 PM
Text Tool said...
Great article and great blog! Thanks for your lessons, I find them really useful.
September 24, 2010 at 1:10 PM
Anonymous said...
After letting Eclipse update the add-on, I ended having issues building with ant (despite having no problem right before it). Based on some posts I found (from Google staff), changes that are *not* backward-compatible (thank you!) were introduced in the build process. The solution for my project was not to use android_rules.xml to modify build.xml, but rather ant_rules_r3.xml (under /tools/ant). I could apply the other tasks (e.g. config) and it worked fine.
September 24, 2010 at 5:59 PM
alex said...
how do I specify the library .jar files that are located in the project's \lib folder ?
Is there anything I need to do for the .so files in the project's \libs\armeabi folder ?
Currently I get a lot of errors like: "package org.anddev.andengine.engine does not exist"
Eclipse built it fine, but Ant doesn't know about the \lib it seems like.
October 10, 2010 at 4:43 AM
Alex said...
the solution was to copy the andEngine library JAR's to the \libs folder (I had them in \lib)
October 10, 2010 at 5:26 AM
Owen said...
Hi Matt,
excellent article. I have only ever used Eclipse for developing and releasing projects for android, until the use of LVL and Progard became a must have, for security.
I am using Flurry Analytics in my code, so when I process android update and create a build.xml and local.properties file with required changes, I proceed with ant release. Problem is, I am getting "package com.flurry.android not found" error messages. Can you possibly explain why I might be having this problem and what I may be doing wrong? Should I include the Flurry.jar location in my build or properties files?. Your help would be greatly appreciated.
October 11, 2010 at 11:01 AM
Matt Quigley said...
@Owen
I can't tell if you're getting those errors at runtime or during the build. In any case, the default folder where additional libraries go is ./libs/. You might want to try copying the library file (which I guess is a .jar file) into that folder. Or you could try changing build properties to change the default library directory, but I'd suggest getting it working by moving the .jar file first.
October 11, 2010 at 9:54 PM
Owen said...
Hi Matt,
Sorry, I should have explained the problem was in the build. But.....
Thanks a million you are a star. Everything worked fine. I also should have noted the post previous to mine (Alex) where he had and resolved the same problem.
Google needs competent support people like you...Keep up the good work. I think it is appreciated by all.
October 13, 2010 at 7:03 AM
Owen said...
Hi Matt,
I am having alot of problems trying to include the Licensing service in my Ant buid.
I am getting the message:
"com.android.vending.licensing does not exist."
"import com.android.vending.licensing.AESObfuscator;"
default.properties file entry in MyMainProject
android.library.reference.1=c:\\Users\\LeOwen\\LiveProject\\library
-----------------------------------
default.properties file entry in com.android.vending.licensing
android.library=true
target=android-8
--------------------------------
Altough I have read the google documentation I am still having no luck.
Can you possibly tell me what other requirements I need to take into consideration for this to work?
October 15, 2010 at 1:10 PM
Matt Quigley said...
@Owen
Is this a build or a runtime error, "com.android.vending.licensing does not exist."?
Also, have you tried just copying the appropriate library files into the default libs folder? If you can get that to work, then the problem is how you're configuring the new library folder. If you can't, then it sounds like there may be additional problems that I could help with.
I use a library in my project at work, and it works fine, at least with the API level 7 and below build setups. But this may be something special with the craziness that the licensing library has to do, and if so, I will look into it further if you give me a little more insight into how you've setup the project. I'll try incorporating the licensing library into the sample project myself. Be sure to tell me everything I need to try to do so, such as where to download it.
October 16, 2010 at 12:16 PM
Owen said...
Hi Matt,
I have resolved the problem with the LVL library and Proguard using the ANT build method. because Ofuscating is included, I have decided to put the full description in your Optimizing, Obfuscating and Shrinking Post.
October 29, 2010 at 6:40 AM
Owen said...
The following process was used to Build, Optimize, Obfuscate and Shrink an android app
if using windows and eclipse. I Created a separate project from eclipse to avoid corruption that may be caused by typos or incorrect
project configuration set-up.
1.
Create a project root directory and copy the files from eclipse as follows:
AndroidMainfest.xml
CLASSPATH file
PROJECT file
default.properties
Add your my.keystore to the root directory
2.
Copy the eclipse directories into the project root directory as follows:
assets
bin
gen
res
src
3.
Create a libs directory and copy any library *.jar files to the directory.
If you are using flurry, this may be one of them.
4.
Create a proguard directory.
copy the proguard.jar file to the directory.
create and edit the proguard config.txt file according to documentaion and your project requirements.
If libs is not included in the proguard process at the bottom of build.xml file, then it should be included
in the config.txt file as follows:
-libraryjars path/to/your/libs
The LVL -keep statement must also be included:
-keep class com.android.vending.licensing.ILicensingService
Put config.txt in the proguard directory.
5.
locate the market_licensing\libary directory located in your eclipse project and copy to
your Project path.
The final Project Path setup should consist of:
PROJECTROOT
assets
bin
gen
res
src
libs (*.jars)
library (Android LVL)
proguard
6.
Ensure a path to the android.sdk-windows/tools directory has been set up or cd to the location.
enter android update project --path C:\path\to\your\project
A local.properties and build.xml file will be created in the project rood directory.
7. build.xml
You may need to edit and tailor the build.xml file for your project requirements. I copied
the ant_rules_r3.xml file located in android-sdk-windows\tools\ant into the build file, and set
setup import="false"
8. build.properties file
Any configuration changes are placed in this file.
Include the android LVL library path as follows:
android.library.reference.1=library
To automate your signing process, add the keystore and password statements (depending on your site restrictions)
key.store=your.keystore
key.alias=youralias
key.store.password=yourkeystorepassword
key.alias.password=youraliaspassword
If the above instructions are followed or the project configuration has been set up according to your
own requirements, then navigate to your Project root directory and enter.
ant release
The build should complete successfully.
I put most of the above in a batch script to automate the process. You also don't need to create
a separate project if you feel confident with what is in place from eclipse, but you will have
to include proguard and libs in your eclips project path and you won't have control of buid.xml or build properties
for external sources. It is up to you.
Good luck.
October 29, 2010 at 11:39 AM
Owen said...
The following process was used to Build, Optimize, Obfuscate and Shrink an android app
if using windows and eclipse. I Created a separate project from eclipse to avoid corruption that may be caused by typos or incorrect
project configuration set-up.
1.
Create a project root directory and copy the files from eclipse as follows:
AndroidMainfest.xml
CLASSPATH file
PROJECT file
default.properties
Add your my.keystore to the root directory
2.
Copy the eclipse directories into the project root directory as follows:
assets
bin
gen
res
src
3.
Create a libs directory and copy any library *.jar files to the directory.
If you are using flurry, this may be one of them.
4.
Create a proguard directory.
copy the proguard.jar file to the directory.
create and edit the proguard config.txt file according to documentaion and your project requirements.
If libs is not included in the proguard process at the bottom of build.xml file, then it should be included
in the config.txt file as follows:
-libraryjars path/to/your/libs
The LVL -keep statement must also be included:
-keep class com.android.vending.licensing.ILicensingService
Put config.txt in the proguard directory.
5.
locate the market_licensing\libary directory located in your eclipse project and copy to
your Project path.
The final Project Path setup should consist of:
PROJECTROOT
assets
bin
gen
res
src
libs (*.jars)
library (Android LVL)
proguard
6.
Ensure a path to the android.sdk-windows/tools directory has been set up or cd to the location.
enter android update project --path C:\path\to\your\project
A local.properties and build.xml file will be created in the project rood directory.
7. build.xml
You may need to edit and tailor the build.xml file for your project requirements. I copied
the ant_rules_r3.xml file located in android-sdk-windows\tools\ant into the build file, and set
setup import="false"
8. build.properties file
Any configuration changes are placed in this file.
Include the android LVL library path as follows:
android.library.reference.1=library
To automate your signing process, add the keystore and password statements (depending on your site restrictions)
key.store=your.keystore
key.alias=youralias
key.store.password=yourkeystorepassword
key.alias.password=youraliaspassword
If the above instructions are followed or the project configuration has been set up according to your
own requirements, then navigate to your Project root directory and enter.
ant release
The build should complete successfully.
I put most of the above in a batch script to automate the process. You also don't need to create
a separate project if you feel confident with what is in place from eclipse, but you will have
to include proguard and libs in your eclips project path and you won't have control of buid.xml or build properties
for external sources. It is up to you.
Good luck.
October 29, 2010 at 11:41 AM
Premier said...
Can you give me an example for ant build.xml with android library project?
Thanks
December 3, 2010 at 12:32 PM
cisnky said...
A very useful article. Thanks!!!
February 20, 2011 at 11:11 AM
Jay Khimani said...
Very nice and useful post. Thanks
March 6, 2011 at 3:02 PM
Can Elmas said...
Very useful and informative. Thank you.
March 9, 2011 at 7:24 AM
Anonymous said...
Very helpfull! Thanks!
March 15, 2011 at 8:52 AM
Alex said...
Make sure to use the following rules file instead of the one in the platform\template folder, otherwise you will get build errors like aaptexec doesn't support the "basename" attribute:
android-sdk\tools\ant\main_rules.xml
April 22, 2011 at 11:13 AM
Kumar Bibek said...
Thanks a lot.
April 29, 2011 at 12:10 AM
Kamesh Kompella said...
The article is well written. However, the following must be kept in mind to avoid the baseline and other errors people have reported. I spent an hour getting this to work and finally discovered the problem as detailed here:
http://stackoverflow.com/questions/4464461/compile-error-while-trying-to-compile-android-app-with-ant
May 4, 2011 at 2:31 AM
L`OcuS said...
You made my day.
Many thanks.
May 17, 2011 at 1:42 PM
Ajay LD said...
Thanks a lot!
June 15, 2011 at 3:11 AM
lambt said...
A very useful article. Thanks!
July 14, 2011 at 5:52 AM
soft llc said...
Thanks for the great post.
Here's a tip for using the android logger when the phone is not connected.
http://www.softllc.com/archives/125
August 8, 2011 at 11:56 AM
Anonymous said...
Awesome! Very informative.
September 14, 2011 at 1:10 AM
Piyush Patel said...
Kudos to u, Excellent stuff !!
I was able to setup my build system in less than hour.
Thanks a million ;D
September 23, 2011 at 8:49 AM
Kang Taro Gak Ngerti seo said...
i dont know why, so many people talking about android, and i dont know too, why steve jobs is very angry about this? can you mention to me?
October 29, 2011 at 2:35 PM
Basavraj said...
Very helpful for all Android developers
November 17, 2011 at 8:00 AM
apilyugina said...
Thanks a lot for your article! http://www.enterra-inc.com/techzone/ hope this coulsd be useful, too.
January 12, 2012 at 10:12 PM
Michael Totschnig said...
Thank you for this interesting article. There is one thing I am wondering about: You show how to set the logging flag from the build, but in order to be truly useful, IMHO you would need to have the build set the logging flag dependent on if you build for debug or release, for example by defining the filter with
What do yo think?
January 29, 2012 at 1:50 AM
Anonymous said...
Thanks for doing this article. I'm not sure why I found the official docs so intimidating--this is clear and easy!
I did find one change in the Android version I'm running.
Instead of putting the properties in build.properties, they need to be in ant.properties
(The docs say to do that now, at "Build signed and aligned" on
http://developer.android.com/guide/developing/building/building-cmdline.html#ReleaseMode )
Thanks again! This is a great timesaver!!
January 29, 2012 at 11:05 PM
Miguel said...
Thanks for the post, very insightful!
February 14, 2012 at 4:07 AM
Anonymous said...
Thanks for this useful post!!
March 25, 2012 at 5:25 PM
Juhani Lehtimäki said...
Great tutorial. This was very helpful Thank you for posting it!
May 18, 2012 at 8:02 AM
Yuval Dagan said...
That was agreat help for me
Thanks alot!!
June 26, 2012 at 2:53 AM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:52 PM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:54 PM
Anonymous said...
Am using hudson,ant to build android apk,for normal android project the build works fine, but i created new android unified ui, where the build fails at setup, saying update android project,
but i did it, still the error is there, any help?
July 12, 2012 at 12:55 PM
Gary Frederick said...
Great info. I am about to modify ant/Eclipse and this helps a lot.
July 28, 2012 at 9:12 AM
m0skito said...
Nice tutorial but an engineer using Windows... really? XD
October 30, 2012 at 9:17 AM
Vinoth P.s said...
could u pls elborate the same with the help pf Hudson, that would be more helpful
October 30, 2012 at 9:49 AM
Anonymous said...
Hello, I have been trying to execute the sample project given here. But when I build the 'build.xml' file I am getting this error-"taskdef class com.android.ant.SetupTask cannot be found". All the environment variables are set accordingly.I cant figure out the problem.Could you please help me out.
January 24, 2013 at 6:35 AM
Anonymous said...
buddy you have to setup this particular environment as path "android-home=[YOUR PATH HERE]"
until you specify the system doesn't know where the ant setup is, hope this will resolve this issue
January 24, 2013 at 11:15 PM
Anonymous said...
also check this link
http://blog.klacansky.com/matter-code/ant-taskdef-class-com-android-ant-setuptask-cannot-be-found
January 24, 2013 at 11:18 PM
Anonymous said...
How do you set the "config.logging" property to be true or false depending on what target you're building? (debug or release)
February 17, 2013 at 5:31 PM
Matt Quigley said...
> How do you set the "config.logging" property to be true or false depending on what target you're building? (debug or release)
See the sample project - the ant build script does it for you, depending on whether you are running the debug or release build.
February 18, 2013 at 3:35 AM
Unknown said...
This comment has been removed by the author.
May 3, 2013 at 5:35 PM
Guy Nicholas said...
Thanks for the article. I still have a question though.
We have a build machine for automated building/testing and that runs through an ant build script which I have setup to do a variety of things.
We also have Eclipse setup with C/C++ configurations of debug/release (this is a Java & NDK project), but what I need to do is be able to tie the C/C++ config to the Java side such that I can get the Java and C code on the same page so to speak. Have you done this?
Regards, Guy
May 3, 2013 at 5:36 PM
Post a Comment
Newer Post Older Post Home
Subscribe to: Post Comments (Atom)
Search This Blog
Loading...
Android Engineer
Loading...
Categories
ant (1)
build (1)
Themes (1)
UI (2)
Blog Archive
► 2011 (1)
► June (1)
▼ 2010 (4)
► August (1)
► July (1)
▼ June (2)
Using Ant to Automate Building Android Application...
Using Themes in Android Applications
About Me
MATT QUIGLEY
I am a software developer who has been working in the field of mobile software for 10 years now. Currently I'm involved in many exciting new Android projects.
VIEW MY COMPLETE PROFILE
Copyright © 2010 Android Engineer
先备注在这里，后面有时间在翻译和整理下，同学都可以看看，附上链接地址:
http://www.androidengineer.com/2010/06/using-ant-to-automate-building-android.html
可以参考下面链接：
http://www.cnblogs.com/stay/archive/2013/05/27/3102027.html