I have a custom gradle build file and i need to run aapt with various params (to extract package names and recompile resources in a custom made resource directory).
For the time being i'm iterating over the directories of ../sdk/build-tools/* and taking the latest dir (most recent).
However i know that there's a gradle android plugin and that it has inside an aapt task or a method to control it.
Can i apply the android plugin and use only the aapt command in my task/ groovy class ?
10x.
10x once again stack overflow for the flood of answers i got while all the idiotic questions are being answered...
i didn't find a way to do it, but i use the following a separate gradle file with a class that encapsulate finding the aapt and running it, then i use apply from: 'xxx.gradle'
and in the included file i use ext.aapt= new AaptRunner(); then i can use aapt object in the original build script.
Related
So,
We are using Dagger 2 in our Android application.
Code generated by
Dagger 2 is located in build/generated/source/apt.
In the documentation of apt-plugin it states that :"Using this plugin Android Studio will be configured to place the generated sources on the build path, preventing errors in the IDE"
If I remove apt-plugin from my build.gradle file, in a place where I use generated code I see compilation error. (Which is reasonable, generated code is not my source).
The questions are:
What does it mean that apt-plugin configures Android Studio so that it places generated code to build path ?
From what I know final dex file is generated from source folder that is specified in build.gradle, how do these generated files become the source ?
Thanks.
The apt-plguin is a gradle plugin and as such it runs with your build script.
This plugin configures apt to be run with your build and sources to be generated. It further adds the path of the generated files to your source sets, which is why the build succeeds and Android Studio recognizes the files as well.
For further information you could always have a look on the gradle documentation on Gradle Plugins.
I created a new project in Android studio and got many files generated, where as my actual code is found in just one folder - src.
Why the so complicated structure? Please explain the motivation of putting meta-files at the root of the project instead of some inner folder named gradle.
Android build system consists of an Android plugin for Gradle. Gradle
is an advanced build toolkit that manages dependencies and allows you
to define custom build logic. Android Studio uses a Gradle wrapper to
fully integrate the Android plugin for Gradle.
Android Studio projects contain a top-level build file and a build file for each module. The build files are called build.gradle, and they are plain text files that use Groovy syntax to configure the build with the elements provided by the Android plugin for Gradle.
Gradle is an automated build toolkit that allows the way in which projects are built to be configured and managed through a set of build configuration files. This includes defining how a project is to be built, what dependencies need to be fulfilled for the project to build successfully and what the end result (or results) of the build process should be. The strength of Gradle lies in the flexibility that it provides to the developer.
For more info you may visit
Gradle Tutorial
Android Application Modules
First of all if you don't want to see those metadata... you can change it(see Image)..
gradle is required to compile your project. for example: In gradle file we specify minsdk version,maxsdk version and dependencies etc
To Know more about gradle go to http://gradle.org/the-new-gradle-android-build-system/
Why the so complicated structure?
IMHO the structure you are referring to is pretty straightforward but your assumption that all those meta-files are related with gradle is wrong.
Meta-files related with your android application are located inside the "app" sub-folder. You have some gradle files there because those are for the purpose of building that specific module.
As pointed out before in a previous answer the best resource to understand the file tree structure for this part is here.
You also have some metadata generated by the IDE (.idea sub-folder):
IntelliJ IDEA stores the configuration data for projects and their
components in plain text XML files making it easy to manage and share
project configuration data with others.
And .iml files:
A module is a discrete unit of functionality which you can compile,
run, test and debug independently.
Modules contain everything that is required for their specific tasks:
source code, build scripts, unit tests, deployment descriptors, and
documentation. However, modules exist and are functional only in the
context of a project.
Configuration information for a module is stored in a .iml module
file. By default, such a file is located in the module's content root
folder.
More info about can be found here.
Please explain the motivation of putting meta-files at the root of the
project instead of some inner folder named gradle.
As mentioned before in some previous answers some metadata is related with the configuration of your project itself and some is module-specific. One example is the build.gradle files. The global file has this comment:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
About the motivation I only assume it was for simplicity and to keep the semantics of the project structure. Other possibility is that it was just by convention.
I am trying to write a script in gradle that requires opening up a file. I am trying to find the current directory where the project is installed. so I can open a file in my "raw" directory.
Note: I am aware that I can use a temporary file to find the current location of the application. However, I am trying to stay away from that solution.
I am trying to find out if gradle has a buildDir variable that I can use in my task instead.
See the Gradle docs. Specifically, you're interested in projectDir (The directory containing the build script) or buildDir (projectDir/build).
I am trying to build a branded Android app, that will have different resource files (mainly drawables) for different customers. The Java code in the apps will be the same, but the different apps will have a different look--meaning different color schemes and different logos etc. I have been told, and my research suggests that Ant is the best way to achieve this.
Where should I change the Android 'build.xml' file? What sort of Ant task should I use to achieve this?
For debugging, I would like to just use Eclipse and build with the default resources. But for production releases, I would like to run Ant on build.xml to produce multiple APKs from different /res folders. I do not even need any code snippets (although that would be nice), just even some tips from people that have done this before or something similar.
I ended up writing a Python script to reorganize the Android project before each build. I recommend avoiding the use of Ant for stuff like this. My 100-200 lines of Python achieved the equivalent of about 1000+ extra lines of Ant that was required in addition to the default Android build.xml Ant script.
I have encountered a similar issue where I want to compile the same code base with some changes as well as changes in the resource files. The solution I am pursuing at the moment is creating a library with the shared code/resources and separate "regular" projects for each of the different APK releases. Unfortunately, I don't have a functional final solution to the problem yet, so all I can give is these vague hints.
Requirement Setup
1. Go to the URL :
http://ant.apache.org/bindownload.cgi
and download the apache ant and extract it in to the any folder like d:/ant .
2. I think you already having the Android SDK path is like(D:/Android SDK/)
Now go to the Enviroment variables and check whether path variable is there is there add these in path otherwise create a new varible with name path and put it there in vaue
D:/ant/bin;D:/Android SDK/tools
done
Go to command prompt and navigate it to the root directory of your project and run the command
android update project -p /
Note: / if you are in the root directory of project else you need to give the path of root directory like d:/myworkspace/mysampleproject
this will generate and build.xml file in your project.
now run the command for this it is necessary to be in root directory of your project
ant debug
this will generate an apk file in bin folder signed with default debug key.
I am managing and running my android app from command line without using ant, I followed these steps:
generate R.java
compile R.java and all .java files in src to .class files
assembling set of class files into dex file using the command below
dx --dex --verbose --output=./bin/classes.dex ./bin
.class files are in bin directory.
But I'm getting the following errors in these steps:
java.lang.Runtime exception:.\bin file not found
at com.android.dx.cf.direct.ClassPathOpener.process
at com.android.dx.command.dexer.Main.processOne
at com.android.dx.command.dexer.Main.processAllFiles
at com.android.dx.command.dexer.Main..run
at com.android.dx.command.dexer.Main.main
at com.android.dx.command.Main.main
Due to this, I'm unable to create the Classes.dex file.
Can someone suggest a solution for this?
[not using eclipse and ant only through command line]
If you need to "manage your Android projects from command line", when you should use Ant build.
Ant's build.xml is a official standardized way to build Android projects. Ant scripts can do anything you may need to build your project.
If you want most modern build tools for Android, you can look at Gradle for Android projects. Note: today it's still in alpha stage.
Try entering the full path instead of the relative path.
Also you must put the class files inside a directory named exactly like it's package name. for example for com.test.me.MyActivity you must use com/test/me/MyActivity.class
And since we are on the topic, remember that dx can only work with class files created using Java6 (or less) so if you are using java7 to compile your code, add "source 1.6 target 1.6" parameters to your command line.