I have a fairly typical Android-Studio/Gradle project with several library modules and one module that defines the launcher activity. So, one APK, so far so good.
But I want to have a second APK generated out of a new top-level project. Note that it's not just a flavor, it's a different app that needs to be in a different module. Still I want to reuse most library modules, so I want it to be in the same Gradle project (and the same Git repo).
Can I just create a new Android module (apply plugin: 'android') with its own launcher activity? In that case, what will ./gradlew assemble build?
Can I just create a new Android module (apply plugin: 'android') with its own launcher activity? In that case, what will ./gradlew assemble build?
Yes you can create a new Android module and when you run ./gradlew assemble it will build both modules.
In case you want to build just one you can run ./gradlew :module:assemble
Related
I have an existing Android project that already has 2 product flavors. Each flavor is an individual android app that has a lot of common code.
Now we also need to build a library (AAR) from the same repo for distribution. We were able to do it by changing the Android Plugin from
apply plugin: 'com.android.application'
to
apply plugin: 'com.android.library'
The problem now is that I have to build both the apps and also this SDK from a single Android Project.
Let's consider the two apps are App-A and App-B, the SDK is using the common modules used by both the app and also some modules in the App-B.
Is there a way to make the SDK as a third flavor?
The plugin (Application or Library) is specified in the app-level build Gradle rather than in flavor level.
There is a way to make the common modules and modules used in the SDK as a library project and use it to build the Apps. But it requires a lot of code restructuring. So I will have to do it as a last resort.
I think its highly recommended to keep your library code separate and have a separate build flavor for library.
1.Separate Library.
2.One Application with two different flavors to access required logic from library module.
So maintainability will be easy from here after.
Had followed this approach for one of our SDK project.
Trying to find the bare minimum source and build files needed to build an android project in Android Studio. I want to publish to github and avoid uploading generated build files or binaries.
I do have a Android.gitignore from but I still see some more files getting pushed into the repo which may not be necessary. I understand the few obvious ones but about others, do I need them and if so kindly explain the usage.
So the question, do I need the following and if so then a short description of why?
root
build.gradle
gradle.properties
gradlew
gradlew.bat
settings.gradle
/app
app/build.gradle
app/proguard-rules.pro
/gradle (tested, android can re-download/generate following it if not present)
gradle/wrapper/gradle-wrapper.jar
gradle/wrapper/gradle-wrapper.properties
This question can have two different answers based on the meaning of the word needed.
First (the real one)
Assuming your project has currently those files, if your question is:
Should I commit these files on my Git repo?
The answer is yes, all of them, and I'm explaining why:
root
build.gradle -> defines the configuration for all the Gradle modules in your project (e.g. use the same remote repositories to download some Gradle plugins)
gradle.properties -> defines some optional flags used when building the app (e.g. enabling the incremental KAPT, enabling the AndroidX jetifier)
gradlew -> invokes the Gradle wrapper (which can be found under gradle/wrapper/gradle-wrapper.jar) to avoid to have Gradle installed when building your project on Darwin/Linux
gradlew.bat -> the same of gradlew but for Windows
settings.gradle -> defines the list of modules which are part of your project
app/
app/build.gradle -> defines the configuration only for your app module (e.g. its build types, its flavors, its version code and version name)
app/proguard-rules.pro -> defines the obfuscation rules when your app enables the minification
gradle/
gradle/wrapper/gradle-wrapper.jar -> provides the same version of the Gradle wrapper jar for all the users. This is very important because it forces the users to use the same version of the Gradle wrapper to compile your app
gradle/wrapper/gradle-wrapper.properties -> same as above, it defines which version of the Gradle wrapper you need
Second (the useless one)
Now, I'll give you the answer to the question:
Are these files strictly needed to compile an Android project?
To successfully compile an Android project with Gradle you just need the root build.gradle if you have Gradle installed on your machine or build.gradle + the wrapper files if you have not Gradle installed on your machine.
Theoretically you can:
put your application code in the root project and that avoids you one build.gradle and settings.gradle
disable the obfuscation and that avoids you proguard-rules.pro
remove gradle.properties and set the properties via command line
Obviously this solution won't happen on a real project scenario.
I have a a multi-project gradle project (Android) with following structure:
root
|-projA
|-projB
|-projC
|-...
In my specific case, projA is an app which uses projB (module). When I run build on projA, projB also gets built. I need to perform an action only on the project that was originally built (the project where the original action was performed on).
For this purpose I need to somehow get the name/path of this project. I need to do this in the afterEvaluate step if this matters.
Example:
gradlew :projA:build // Builds A and B -> I want only "projA"
gradlew :projB:build // Builds B -> I want "projB"
gradlew :projC:build // Builds A, B and C -> I want only "projC"
I am not sure how I can achive this, I hope someone of you can help me.
You can check the official doc:
The standard project dependencies are supported and makes relevant projects configured. If project A has a compile dependency on project B then building A causes configuration of both projects.
However you can disable the build of dependency projects (but pay attention!)
If you don't want depended on projects to be built when doing a partial build. To disable the build of the depended on projects you can run Gradle with the -a option.
Example:
gradle -a :projA:build
From the doc:
-a, --no-rebuild
Do not rebuild project dependencies.
I have a command line program that, depending on a set of source files, generates a jar file that I want to use in my Android gradle build (A). This command line program simply stores a jar file in a directory on the disk.
How can I create a new gradle project (B) that runs my command line program (inside of a gradle multi-project setup) that the Android Gradle project(A) will depend on: in other words, if the sources for B change, it should rebuild!
Note:
Project B is neither a Android library project nor is it a java project. It simply runs a program via command line that happens to store a jar file on the file system.
You could do this by creating your own custom task(s) in project B to execute your program which generates a JAR. Be sure to declare your inputs/outputs properly so Gradle knows how to handle dependencies for the task:
task buildProjB {
inputs.file file('my_source_file.name')
ext.dest = new File(buildDir, "libs")
outputs.dir ext.dest
doLast {
// Run your program and put output in "libs" subdir
}
}
tasks.whenTaskAdded { theTask ->
if (theTask.name.contains("assemble")) {
theTask.dependsOn "buildProjB"
}
}
Note that the buildProjB task gets "hooked" to any of the assemble tasks. You will likely need to do this or to one of the build tasks in order for it to be built properly as part of the normal Android app build.
In your project A settings.gradle, make project B part of the build:
include ':projectA', ':projectB'
In your project A build.gradle file, make project B a dependency:
dependencies {
...
compile project(':projectB')
}
This is assuming you have project B (module in Android Studio terms) beneath the top level Android Studio project, so at the same level as project A.
I'm trying to migrate from maven to Gradle for an Android project and I am facing the following issue:
I have three projects i.e
root
- projlib
build.gradle
- projA
build.gradle
- projB
build.gradle
build.gradle
settings.gradle
Basically what I want to achieve is that projB depends on projA and projlib. projlib is a lib folder that compiles and generates a lib(jar) file. projA is an Android Application and projB is another Android Application that needs to reference code in projA. Right now what I have added in the projB build.gradle file is
dependencies {
compile project(':projlib')
compile project(':projA')
}
So say if there's a class
FooProjLib in projlib and
FooProjA in projA
Then In projB I can do
FooProjLib foo = new FooProjLib
which works fine
but when I do
FooProjA foo = new FooProjA
Gradle gives me package projA does not exist, what I have observed is that both dependency is resolved but only the lib can be reference and not the apk.
Does anyone have an idea how to solve this?
You can't do exactly what you want. projA can't build an application (i.e. an APK) and also have other things depend on it. projB can only depend on projA if projA is an Android library, meaning in its build file you have this declaration:
apply plugin: 'android-library'
instead of
apply plugin: 'android'
Of course, this means that projA won't build an APK, but will build an AAR instead.
If projA needs to also be an APK, you'll have to restructure things such that the common code that's in projA that projB also needs is moved out to a shared library. If both projects are similar, perhaps you could have just one module for them and use project flavors to differentiate them; it's hard to say whether this is a good approach without a lot more information.