I have a library project that serves as the backend for a number of other projects. It does the web connection and parsing etc. Then I have other front end projects that build on this.
For development and server environments I wrote an ANT build script that replaces certain values in the code bases on the build type.
So I have two targets buildDev and buildProd.
Is there a way for me to have the values set correctly while building the dependent (non-library projects). E.g. if I do ant debug on the project it builds the backend with ant buildDev and if I do ant release it does it with ant buildProd.
I'm pretty sure that's not possible, so what are the alternatives.
For the curious, the custom builds just replaces a file that has static variables that are assigned different values based on the type of build. Nothing too complex.
In ant, there are a variety of different tasks that can be used to edit properties in a file.
I'm sure you're aware of property files, so if you use the documentation here:
http://ant.apache.org/manual/index.html
It could probably help you.
If you set your variables in an ant-style property file, then for certain builds you could have separate files for separate builds, and then therefore have the variables set correctly.
If you're talking about having variables set in your source, try the copy task:
http://ant.apache.org/manual/index.html
Filterchains on a copy task will allow you to replace certain lines of code out of a file. So if you have a variable named server_ip or something like that, you can use a filterchain to change that value and re-copy that source file back into your tree.
I hope this answers your questions. If not, be gentle. I'm kinda new at answering stuff and I got slightly chewed out on an Android post haha.
I found the solution. The default Android Ant build.xml passes the release name to the child library project script while calling it. The following lines and the code that follows details it.
<!-- figure out which target must be used to build the library projects.
If emma is enabled, then use 'instrument' otherwise, use 'debug' -->
<condition property="project.libraries.target" value="instrument" else="${build.target}">
<istrue value="${build.is.instrumented}" />
</condition>
Then it's just a matter of having the same targets in all the interdependent projects.
Related
In iOS do we have something like Gradle Build Flavors on Android.
Basically I want to integrate Applause SDK with my app but I dont want that code to be part of the release build. I only want to use applause sdk only to distribute the app internally and for bug reporting.
If there is nothing like flavors then what is the best way to do this.
You can make use of Schemes and Build configurations in Xcode. Here's the official documentation: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/BasingBuildConfigurationsonConfigurationFiles.html
After you create a build configuration, you should edit your scheme to use that build configuration. For that click on your scheme and select Edit Scheme.
In short, the process is:
Create a build configuration
Set some custom flags for that configuration. For this, go to your target, select Build Settings tab, and search for Preprocessor Macros. There you'll be able to add custom flags
Edit your scheme, or create a new scheme, to use your build configuration.
In your code, you'll have to ask if the flag is available using preprocessor macros:
#ifdef APP_STORE
//do something
#endif
There are several approaches you can take to build an iOS app in different flavors:
Different versions of a resource file
Use a custom build variable to switch between different versions of a resource file. This article discusses how to build an app with different icons.
For *.strings files and resources linked in *.storyboard files the suffixing approach suggested in the first item did not work for me. So I added a Run Script build phase early in the pipeline. Using a script you are free to do whatever you want before the usual build chain handles your files. This is great for dynamic file generation or advanced file selection logic. As a switch you can (again) use a custom build variable.
Modifiying code
Use a compiler flag as suggested here. These can be checked using the preprocessor.
Alternatively you can (again) check custom build variables. To make them accessible add them as a key in a plist file.
My server needs to keep building a large amount of Android projects. All of them are almost identical except for minor change on manifest.xml or any resource file (if it's better for the task) for each build. To reduce cost and improve efficiency, I try to implement incremental build. My planned procedures are:
after the first successful build, skip all the previous
procedures (aapt to generate R.java, adle to make java, etc.)
directly call aapt to make resource files, e.g., *.ap_
call apkbuilder to make classes.dex and usigned.apk
make signed.apk
So my question is whether the above solution is possible? And any clue about how to implement it?
This isn't necessarily a solution for your particular requirements but perhaps it will provide you with some useful pointers.
I have an Antlib that I use for building Android projects. You probably won't want to use it yourself as it has some drawbacks, but it should serve as an example of how to perform the various steps to build an Android app using Ant. In particular, it shows how to call the various Android SDK tools from Ant and how to use the Ant uptodate task and Ant's if and unless attributes to avoid processing files that haven't changed.
The source for the Android Ant macros is here (the Antlib documentation might help you to make sense of what it's doing).
I have an ant build setup for my Android project, and I've been reading guides and tutorials all over stackoverflow and online, but cannot seem to understand how to make this work. Basically in my code I have a variable, "isDebugVersion" (which will print out logs, and a few other things). When I build with ant, I want that variable in my code to be set to "false". I'm looking around and I cannot find the custom_rules.xml examples even though it's listed in the build.xml file.
So the variable is in com.example.application.Globals, and it's listed as isDebugVersion. Can someone please give me an example for how to manipulate this variable using an ant build script?
You can a file named custom_rules.xml to the root folder of your project.
Inside define any property you want.
Note that what you are trying to achieve could be simpler using BuildConfig.DEBUG. This file is in the gen folder of your project, close to R.java. It is generated during the build and the constant DEBUG will be set to false during debug builds and to true in release.
So if you type ant release, you will get false. With eclipse or ant debug, you will get true.
You could also learn how to use RoboGuice, it has an interesting logging solution.
You can use this constant for all purposes like changing the google map api key from debug to release key. For an example, follow this thread.
I'd like to be able to use TIME and DATE macros in Java, just as I would in C. However, I'm aware they don't exist. I've looked at various sites, and seen suggestions such as http://www.rgagnon.com/javadetails/java-0532.html. I understand that this could be implemented by creating a custom build.xml, but I'm reluctant to break that far from the Android tool chain.
An Eclipse Builder might have been a viable solution, but modifying files outside Eclipse seems like an unwise thing to do.
Has anyone a suggestion for accessing build date/time from within their Android application without a custom build.xml? Is it possible to use the build.properties file, an Eclipse Builder, or something else?
I would recommend using a build.properties file written by ant script registered as a project builder. As part of ant builder configuration you can specify which resources to refresh post-build, so the fact that you are writing this file external to Eclipse isn't going to be much of an issue. Make sure to configure your source control system to ignore this build.properties file.
I am interested in integrating Scala (or some other non-Java JVM-language) into the android platform. I am not referring to writing an android application with Scala, that I did early early on, but actually hooking into the build process that builds the android platform source tree. I imagine this will be a matter of hooking into the makefiles and such. Does anyone have insight into this?
What I have so far:
The platform source treefrom git://android.git.kernel.org/platform/manifest.git built in its virgin form, guided by "[Download and build the Google Android][1]"
build/core/combo/scalac.mk # Configures scala compiler related variables, included by config.mk
Added definitions in build/core/definitions.mk for an all-subdir-scala-files and an all-scala-files-under
Added definition in definitions.mk to build scala files such that they are included in the package
What's left:
Include scala-library.jar
Ensure changes to -bootclasspath has not broken anything
Figure out how to handle case where scala classes depend on java classes and visa versa
Major cleanup of code
Testing!
Figure out what to do (other than just posting them here) with the changes I've made
Looks like I'm almost there!!!
Some notes from the past
Latest: I have found where the Java source files are compiled! In definitions.mk, see 'define transform-java-to-classes.jar'. The latest idea is to write a transform-scala-to-classes definition and then have it store those classes in the directly that gets packaged. I will call transform-scala-to-class right before this step in transform-java-to-classes.jar. Support for eclipse and cygwin will for now be dropped as it clutters up the code with workarounds and therefore increases my chances of failure.
The build process starts out by the root Makefile running build/core/main.mk
build/core/main.mk includes build/core/config.mk which includes build/core/combo/javac.mk which sets HOST_JAVAC, TARGET_JAVAC, and COMMON_JAVAC. COMMON_JAVAC is the "Java compiler command with common arguments," by the look of it the other two variables get these values by default, unless in a special environment (openjdk or eclipse). COMMON_JAVAC is not used outside this file. The other two are only used in build/core/definitions.mk.
build/core/java_library.mk (included by config.mk) seems to only be concerned with building jars. This is out of the scope of us caring. Any interaction with jars presupposes class files which presuppose that we were already successful in building our scala files.
There are checks in main.mk regarding the version of java. We will ignore these and assume that our version of scala is compatible. Right now (in combo/scalac.mk) I am using the same --target arg used in javac.mk. This should perhaps be stored in a variable.
main.mk also includes build/core/definitions.mk which in turns defines some useful functions. The one we care about here is all-java-files-under and all-subdir-java-files. The latter is used in Android.mk files to find java files. The former is used in the implementation of the latter. I will write Scala equivalents of them.
To figure out how the build process works, I am now running make with -n and others. I got this idea from the stackoverflow article "[Tool for debugging makefiles][2]". I am also investigating debugging with remake.
build/core/{config.mk, definitions.mk} gives us light as to which make files/commands are used to do what.
As a possible way of hacking in support on a per project bases, additional code could most likely be added to the project's Android.mk file. From platform/build/core/build-system.html we read "Android.mk is the standard name for the makefile fragments that control the building of a given module. Only the top directory should have a file named "Makefile"." You could create a new target like "scala-build" and run that (make PackageName scala-build) before the final make. One could perhaps also hide it sneakily in a variable assignment, mitigating the need for a target to be called explicitly.
Another way (far far more hackish) is to hijack the command being used for javac. This is set in build/core/combo/javac.mk. Your project's Android.mk will have to include *.scala files in LOCAL_SRC_FILES along with the *.java files.
Guys on reddit say, there's a tutorial on integration Scala into Android with ant here.