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.
Related
I am using ...
com.google.firebase:firebase-crashlytics-ndk:17.3.1
com.google.firebase:firebase-crashlytics-gradle:2.4.1
com.google.gms:google-services:4.3.5
... in my Android application project which depends on a Android library project. The library project uses both Kotlin and C-Code. The library build process outputs an *.aar with unstripped *.so files. When I build the application project I can verify that the unstripped *.so files of the library are unpacked into app/build/intermediates/merged_native_libs/<BuildVariant>/out/lib and that they are still unstripped.
The app is configured with the build flavors free and paid and the usual build types debug and release.
First, I assemble the APK via ./gradlew clean assembleFreeDebug.
Then, I invoke ./gradlew generateCrashlyticsSymbolFileFreeDebug which fails:
Execution failed for task ':app:generateCrashlyticsSymbolFileFreeDebug'.
Unstripped native library path required by generateCrashlyticsSymbolFileFreeDebug does not exist: app\build\intermediates\merged_native_libs\PaidDebug\out\lib. Check your configuration, or override using the firebaseCrashlytics.unstrippedNativeLibsDir extension property.
Is this a bug where build flavors are mixed up by the Gradle plugin or a misconfiguration on my side?
I can workaround it if I also assemblePaidDebug without clean. Then, symbol files are generated by generateCrashlyticsSymbolFileFreeDebug in app/build/crashlytics. I am however not sure if it is a good idea to mix the input files (flavors) to generate the *.cSYM files.
Related
:app:generateCrashlyticsSymbolFileRelease error: Unstripped native library path required by generateCrashlyticsSymbolFileRelease does not exist:
try to remove unstrippedNativeLibsDir. If you are building C++ code as part of your app build and not in library, crashlytics should find necessary path automatically
if it's still not working and you're using cmake for build try tu use this path: ./build/intermediates/cmake/release/obj
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'm using Intellij14. I am using a Project artifact to produce a release version of the android app. The name appears to be based on the name of the Module under Project Settings.
What I'd like to do is use the android:versionName defined in my AndroidManifest.xml as a part of the APK file name. I'm not sure if there's anything in the IntelliJ build file to allow me to do this that I can see. I'm not sure what I can do short of having a post build script parse the android manifest and rename the file
I use TeamCity as my build server. If this dynamic renaming is a feature that is available only in TeamCity for some reason, that is OK.
Note: I am using an intellij project file, not a gradle build.
I created a test project to understand how to build and run the tests using command line tool. I managed to create a project, updated it with
android update project -p .
and debug with
ant debug
When I added a library project to this test project, the ant debug started to fail because it couldn't find the build.xml of the library. The only solution I found atm is to update the library project as well (found here). Is this the correct way? I see pom.xml files in many of the libraries that I use. I know it is used by Maven (although I know nothing about it) and it might help me with another solution.
Ant is the official way to build android apk. Maven is an alternative way of doing it (not officially supported, but it works very well).
There are few differences regarding default project layout when working with maven or ant, but it's possible to have both build system working on the same source code if you do some additionnal configuration work (i.e. some information will be duplicated).
Default project layout with maven
java source files are under `/src/main/java``
dependencies are defined in the pom.xml (using the maven way of defining dependencies, with type apklib for android libraries)
Default project layout with ant (and eclipse ADT plugin)
java source files are under /src
dependencies are defined in /project.properties and are specified using relative path.
Here is an example of project.properties (it's a typical example of a library project referencing 2 other library project):
target=android-15
android.library=true
android.library.reference.1=../somelib
android.library.reference.2=../someOtherLib
(as you can see some additionnal information are stored in this file : the android target and the fact that the project is an library or an app. When you use maven, this information is in the pom.xml)
How to build a maven android lib with ant ?
The problems (when you need to build a maven-layout-android-library with ant) are the following:
having a proper /build.xml (it can be done through android update library-project ... here is the official doc about this command)
having a proper /project.properties (it is partially done by the android update ... command, but you may need to add some android.library.reference by hand or with eclipse ADT plugin)
telling ant that the java source files aren't at the default location, but are under /src/main/java
For this last point, here is how to do it:
create a file /ant.properties (in your maven-layout-android-library)
put the following entry in it:
source.dir=src/main/java
(Important : it is not always required because sometimes the java source files are already under /src in the maven-layout-project and in this case, the pom.xml contains the information that the source dir is /src)
And that's all. Now, your maven-layout-android-library can be build with ant debug
After updating to ADT 14/15 I started having a couple problems with our build.
With one Android based libraries (call it Framework) which is added into the actual android project app (call it App). The Framework project has a couple jar files in its own lib folder which is added to its own build path. Those same jar files are required to be added to the App's build path as well.
So jar files on the Framework build path
Framework/libs roboguice
Framework/libs gson
Those same jar files on the App build path
Framework/libs roboguice
Framework/libs gson
Also the Framework.apk is added via the Android Library panel in the App's project properties.
Both projects are targeting the same Android.
Now when I build the project I seem to have resolved the errors however when running it, at times I receive the Missing Framework.apk in the console window.
So based on this scenario any thoughts on how to correct this build? I have a feeling its still setup incorrectly.
This should help you out!
http://android-developers.blogspot.com/2011/10/changes-to-library-projects-in-android.html