I'm missing the "Top-Level" project build.gradle script from my project:
I imported it into Android Studio from a very complex Maven/Eclipse project, and it basically made a module ("android") in the top level of the directory, and added all the submodules ("tappurwear", "shared", etc) into that original module's directory.
I know this is a kind of messed up structure, but there's a lot of other build scripts so I can't really just move all the files into a proper separate module.
So now I'm wondering, how do I add a top-level build.gradle script, for the entire project? The usual Android Studio projects I've seen just have one, but it's treating my top-level build script as the "android" module's build script. Can I create a new build.script to be the top-level project script that shares settings with the other modules? Is there a way I can rename the top-level build script that gets used in all other module scripts, in Android Studio or Gradle?
I had the same issue on my multi-module project, this solution worked for me.
Closed all the open projects.
Removed project from recent projects in "Welcome to Android Studio" window.
Now click "Open existing android studio project" & browse to the project repo & select top level build.gradle.
close your project
rename the project directory (in the workspace)
open the project with the new name
wait for gradle sync, build.gradle (project) should be added to the Gradle scripts
close the project
rename the project directory with the original name
reopen the project with its good name
wait gradle sync, the build.gradle should be here again...
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.2.3'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
It really doesn't matter from my experience, what you need to do is make a build.gradle file, with your favorite .txt writer (make sure it says .gradle). If your root foldere app name is say "Archiver", then you put the gradle file where you see folders like app, .idea, gradle, e.t.c.
One thing you have to keep in mind is that you may need to add a pointer to this gradle if your project can't find it for some reason.
To make sure your project looks good, go to File >> Project Structure >> Module (and every other menu you feel you implemented). If you don't see any red x's then you may be good to go.
Close project.
Remove ".idea\project_name.iml" (name are usually same as project folder).
Remove reference to this file from ".idea\modules.xml".
Open project.
IDEA will re-create this file in projec's root folder instead of ".idea" and project-level "build.gradle" appears. This makes me think that better solution could be just moving this file outside ".idea" and correct reference in ".idea\modules.xml".
You can just add build.gradle for root folder which contains gradle.properties and settings.gradle file
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
The following steps resolved the issue for me:
Close project.
Remove ".idea\project_name.iml" (name are usually same as project folder).
Remove reference to this file from ".idea\modules.xml".
Open project in IDE
Related
in one example, I saw three dependencies block in build.gradle.
example:
root folder: build.gradle
1.
buildscript{
dependencies{
}
}
2.Under android block
android{
dependencies{
}
}
I see one more dependencies block on root folder
buildscript{
}
dependencies{
}
android{
}
First two are been explained in Android developer site.
1st: is applicable for complete project
2nd: per module.
I am not understanding what 3rd dependency block means.
It's a bit confusing because Android Studio by default shows both build.gradle files right next to each other (when using the Android view).
If you switch to the Project view you can see the actual structure and where the different build.gradle files are located.
The build.gradle (Project: MyApplication) file is in the root folder of the project and its configuration settings apply to every module in the project. A module is an isolated piece of the bigger project. In a multi-module project, these modules have their own jobs but work together to form the whole project. Most Android projects only have one module, the app module.
The build.gradle (Module: app) file here is in the app folder. Its build settings apply only to the app module. If there were another module, then the it would have its own build.gradle file, too. As an example, I made a library project with three modules: a library module, a demo app module, and another app module that I plan to use for testing. Each of them have their own build.gradle files that I can tweak.
In a basic project, almost everything you need to edit will be in the app module's build.gradle file. You can remember it like this:
You're making an app, so go to the build.gradle (Module: app) file.
Further reading
Configure Your Build (Android documentation--very readable and useful)
Introduction to multi-project builds (Gradle documentation)
First two are been explained in Android developer site. 1st: is applicable for complete project 2nd: per module.
It is not exact.
The buildscript block can be specified in the root level but also in the module build.gradle file.
These dependencies block only controls the dependencies for the buildscript process itself, not for the application code.
2.Under android block
android{
dependencies{
}
}
It is not correct.
The correct syntax is:
android {
...
}
...
dependencies {
...
}
Don't put these dependencies in the top-level file.
This question has been asked many times so far, but none of the provided solutions worked for me.
I'm completely new to Android Studio and trying to open this project in Android Studio: https://github.com/monkeyswarm/MobMuPlat.
There is two build.gradle files. One in the root folder and another in in the 'app' folder. is that correct?
When I try to sync the gradle project it says gradle project sync failed and gives me the error: Configuration with name 'default' not found.
This part in the build.gradle file is highlighted:
dependencies {
classpath 'com.android.tools.build:gradle:1.5.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
any idea whats going wrong here?
Your app/build.gradle is containing one line
wearApp project(':mobmuplatandroidwear')
Remove that and try to sync the project.
Hope this helps.
In your MobMuPlat-Android/settings.gradle you are defining:
include ':app', ':mobmuplatandroidwear'
Gradle is searching for a build.gradle in the mobmuplatandroidwear module which is not present.
I built some android projects with android studio 1.4. Today my computer broke and I reinstalled my operating system . I installed android studio 1.5,but it didn't work with the old projects.I built some new projects and there's no errors.When I open the old projects,there is an error.
Error:Unable to tunnel through proxy. Proxy returns "HTTP/1.1 400 Bad Request"
I can't find any information about this error,how can I deal with the old projects?
enter image description here
Put this code in your main build.gridle file, may be it trying to use latest gradle and you have used older one in your previous projects.
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
I solved this problem.Just changed the information in gradle->wrapper->gradle-wrapper.properties->distributionUrl=https://services.gradle.org/distributions/gradle-2.4-all.zip
to https://services.gradle.org/distributions/gradle-2.8-all.zip.And it works for me.
I have a network restriction at my production environment that causes this issue.
I solved the same problem by downloading a Gradle version manually and use this local deployment directly:
Downloading a proper Gradle version from Gradle site. In my case https://services.gradle.org/distributions/gradle-6.4.1-all.zip
Placing this zip file in a proper disk folder, say /path/to/gradle-6.4.1-all.zip
Editing projRoot > gradle > wrapper > gradle-wrapper.properties, so that
distributionUrl=file:///path/to/gradle-6.4.1-all.zip
A robust and cross-platform setup would be
distributionUrl=gradle-6.4.1-all.zip
This is a relative path to
project_root/android/gradle/wrapper/
So you must copy the Gradle zip ball there.
I just noticed there are two build.gradle files in my project. Is it because I used gradle wrapper while importing the project?
In Android Studio what is the difference between build.gradle in project root directory and build.gradle in app folder?
The "app" folder is just one module. When writing more complex apps you may have multiple modules. The build.gradle at the module level relates only to that module whereas the build.gradle at the root relates to all modules in the project.
Example from project level build.gradle:
allprojects {
repositories {
jcenter()
}
}
This is saying all modules should use jcenter repository for resolving dependencies. Now a potentially confusing thing is a terminology clash between gradle and android studio. An android studio "module" is a gradle "project" hence "allprojects".
I'm currently developing both a library (with no activities) and an application that depends on the library. Currently, I have these as separate projects, and I can copy the generated .aar file from the library project into the application project's libs folder, and re-sync gradle. However, this is an inefficient process because I have to rebuild and manually re-copy the .aar file every time I make a change to the library project. My question is, how can I streamline this process so that my application automatically uses the library's most recently generated .aar file?
1) In your app's settings.gradle include your lib as a project:
include ':lib-project'
project(':lib-project').projectDir = new File('../path/to/lib/project/lib-project')
The path to your lib project is relative to the settings.gradle location on your filesystem
2) in your app's build.gradle add lib project as a dependency:
dependencies {
compile project(':lib-project')
...
}
how can I streamline this process so that my application automatically uses the library's most recently generated .aar file?
Option #1: Dedicated Library
Step #1: Put your app project and the library project as children of a common root directory for the overall project. For the purposes of this answer, I'll call these app/ and library/, respectively.
Step #2: In the top level (i.e., the common root directory), have a settings.gradle file that lists these modules:
include ':app', ':library'
Step #3: In the top level, have a build.gradle file that sets up the Gradle for Android plugin and any other common stuff of interest, such as:
// Top-level build file where you can add configuration options common to all sub-projects/modules.
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'com.android.tools.build:gradle:1.0.0'
// NOTE: Do not place your application dependencies here; they belong
// in the individual module build.gradle files
}
}
allprojects {
repositories {
jcenter()
}
}
(note that the above file is what you get from a native Android Studio project, created by the IDE)
Step #3: In the library/ directory, have a build.gradle file that uses the com.android.library plugin
Step #4: In the app/ directory, have a build.gradle file that has compile project(':library') in its dependencies to pull in the library
It may be that your AAR is the deliverable, not the app (e.g., the library is an open source one for community use, and the app is a demo app). In that case, you might use debugCompile in app/ to pull in the local library project for debug builds, but have releaseCompile to pull in the AAR from a published source, to confirm that you can build from the same thing that users of the AAR use.
Most of my CWAC libraries are set up this way (e.g., cwac-richedit).
Option #2: Publish the AAR Locally
You can use the maven plugin and the uploadArchives task to upload to a local Maven-style repo:
apply plugin: 'maven'
uploadArchives {
repositories.mavenDeployer {
pom.groupId = PUBLISH_GROUP_ID
pom.artifactId = PUBLISH_ARTIFACT_ID
pom.version = PUBLISH_VERSION
repository(url: LOCAL_REPO)
}
}
Here, my constants are pulled in from a gradle.properties file, and LOCAL_REPO is a file:/// URL pointing to a local repo. You can then run gradle uploadArchives to generate the AAR and push it to the local repo.
Then, your app can have a maven { url LOCAL_REPO } closure in the repositories closure, and can pull in the AAR artifact from there as if it was coming from a public repo (e.g., Maven Central).
My CWAC libraries use the uploadArchives task, but only for publishing to my local mirror of my Amazon S3-hosted Maven repo.
This approach would be if you really wanted to work off of the AAR, but wanted to do so from multiple projects. Note that you can certainly publish this to some other sort of Maven repo (e.g., a Sonatype server) for enterprise use.
Option #3: Mod a Module to Point to the Library Elsewhere
This is Pavel Dudka's approach in his answer. I haven't tried this. Off the cuff, this would be a good approach if you want to depend upon the library from multiple apps, but you're not really concerned about having an actual AAR as a thing to distribute around.
And I'm sure there are other options than these three.