The Android Studio Build menu has options including
Make Project
Rebuild Project
When should I use each?
Most of the time you should use Make Project. Sometimes, after adding libraries and making big changes to the project you should use Rebuild Project.
If you look at the menu, you'll see that Make Project and Compile have keyboard shortcuts, that suggests that they are often used. Others are seldom used.
It is the same as IntelliJ Idea.
Compile All the source files in the specified scope are compiled. The scope in this case may be a file, a package, etc.
Make Project All the source files in the entire project that have been modified since the last compilation are compiled. Dependent source files, if appropriate, are also compiled. Additionally, the tasks tied to the compilation or make process on modified sources are performed. For example, EJB validation is performed if the corresponding option is enabled on the Validation page.
Make Module Compiled are all the source files that have been modified since the last compilation in the selected module as well as in all the modules it depends on recursively.
Rebuild Project All the source files in the project are recompiled. This may be necessary when the classpath entries have changed, for example, SDKs or libraries being used added, removed or altered
Copied from IntelliJ Idea 13 help.
The difference is that Rebuild executes gradle's clean task first. If you look in the Gradle Console 'Rebuild Project' will say something like
Executing tasks: [clean, :app:compileDebugSources, :app:compileDebugAndroidTestSources]
While 'Make Project' won't have clean
Executing tasks: [:app:compileDebugSources, :app:compileDebugAndroidTestSources]
Difference between make and rebuild is "clean" task.
When you do rebuild project it performs clean too.
Related
Gradle on Hard Disk
How to avoid multiple versions of Gradle being used when importing Android projects from GitHub and only use one Single version of Gradle to save hard disk space?
I have low hard disk space. When importing Gradle Android projects from GitHub, many have different versions of Gradle specified.
Preferably, how to make sure when importing any kind of Gradle Android project, only one single version specified by me (which would be latest) is used.
So even if the GitHub project specified version 6.7 and I specified in some settings 6.8, then 6.8 should be used regardless.
Too much data and space are wasted otherwise.
In git, the uploader has added all the Gradle files installed in his system. If you want to remove it. You need to edit gitignore file so that the git doesn't upload everything.
It's very simple. You just need to add
# Gradle files
.gradle/
in .gitignore file check here!
https://github.com/xabhi7549/ImageSliderExampleInKotlin/blob/master/.gitignore
To "avoid using multiple versions", before importing a project into android studio, right after you clone it, check its .gradle files for the project, and make sure the distributionUrl is the version of gradle you want.
For the actual version of Gradle, check our gradle-wrapper.properties for something like:
distributionUrl=https\://services.gradle.org/distributions/gradle-6.5-all.zip
That's the version of "Gradle" that will be downloaded if you don't already have it. (the -all version is 139mb).
I think you're chasing the wrong problem here; this whole post and process will gain you at the most <200mb of HDD space. An average project will likely use much more than that to build (as cache).
You're still welcome to go to your $HOME/.gradle folder and clear up its /cache/ folder (warning: you'll need to re-download all dependencies again).
You can also save space by deleting the Gradle caches. If you want to learn more about how they work, check this blog post titled: "Understanding Gradle caches" (two parts).
My question has the same problem as Issue with using .AAR file in other project. But I want to add more details. Hence the new question.
I am also aware of solutions such as this Android Studio cannot resolve symbols from imported AAR module but the answers aren't exactly what I am looking for.
I can add my AAR file into my project without problem either by adding it in libs/ folder or adding as new AAR module. The problem happens when the AAR authors give an updated AAR (because they changed something in their public API i.e. adding new parameter in one of the old methods).
Android Studio can't seem to pickup the changes. In the old library, I had this method call:
library.showText("hello");
Authors released a new API with update to the same method, and should be called as:
library.showText("hello", 5000); // added timeout param
When I CTRL+click the method, it takes me to the old class that has the method located in C:\Users\MyUser\.gradle\caches\transforms-1\files-1.1\library.aar\...\old.class. I think this is the problem why I get "cannot resolve symbols" error.
How do I fix this?
I would tell what I had done to correct this error:
Delete this dependency from build.gradle file, and sync, this action will be abort because of missing specified file;
Now revert the build.gradle file, and sync;
Done, everything is OK.
I guess the problem was Android Studio and Gradle did not agree. Here are three solutions that worked for me (after hours of tests). If one option does not work for you, try the next.
Option 1
Gradle -> Refresh All Gradle Projects
Option 2
Gradle -> Refresh All Gradle Projects
Remove 'build' directories from project
Remove .gradle cache from C:\Users\YOUR_USER_NAME\.gradle\caches\transforms-1\files-1.1\* (only delete the few latest folders)
Build -> Clean Project
Option 3 (this will restart your Android Studio)
File -> Invalidate Caches / Restart
then choose Invalidate and Restart
Gradle -> Refresh All Gradle Projects
depends on the way, how you import that library:
download .aar and store into libs directory - you need to download everytime, when the new version was released and overwrite your current .lib file + Sync gradle/Rebuild project
using gradle file with url pointed to that library - Sync gradle (right top bar „Gradle“ - open and click on Refresh icon to reimport libraries)
We have Gradle set up to build and test our Android app. Now we ran into the problem, that Gradle test runs fail reproducibly after a class was renamed somewhere in the project:
Execution failed for task ':PROJ:compileDebugUnitTestJavaWithJavac'.
> Unable to read class file: '/path/to/class/with/the/name/before/renaming.class'
This error is reproducible both..
locally (run gradle tests from Android Studio, or on command line using ./gradlew test), and
remotely, when the tests run on our CI (a Teamcity server).
What solves the issue, is manually triggering a rebuild locally (e.g. in Android Studio Build > Rebuild Project) or re-running the Teamcity task with the flag clean all files in the checkout directory before the build set.
Is there any way we can get our tests to not fail after a class has been renamed?
While the above solution is simple enough it is kinda annoying that a simple rename which makes it to our repo will blow up the CI builds... We really want those to stay green. :)
This is a known issue in Gradle 2.14 and 2.14.1 and there will be a workaround for it in upcoming Android Gradle plugin release.
As a workaround you can do a clean build for your project. For a CI build, a clean build is a good idea anyway.
You could use the Swabra build feature of TC that cleans out the working directory either before or after each build, so that all generated files are blown away and the build always starts with a clean working copy. For reproducible builds this is a must-be-used feature in my opinion.
Alternatively you can of course also add the clean Gradle task to your TC configuration so that Gradle cleans away previous build artefacts. But if using TC I'd prefer Swabra as it restores VCS state reliably.
I have a multi-project setup in Gradle and work in Android-studio. The setup contains two apps (each one has its own project directory with its own build.gradle) and some libraries shared by those apps.
The directory structure looks like this:
/workspace/
/workspace/app1/
/workspace/app2/
/workspace/app3/
/workspace/library1/
/workspace/library1/
When I build from the command line I can limit the build to only one of the apps via
gradle assembleDebugApp1
When I build from within Android Studio, it seems to build all projects that have a build.gradle file and are inside of workspace.
In Android Studio, when I run Build->Make Project, I see on the bottom what gradle does:
Gradle build using tasks: [:app1:assembleDebug, :app2:assembleDebug, library1:bundleDebug, (...)].
I would like it to only run the assemble task for my "current project".
I'm new to AndroidStudio, so maybe the question is : How do I set the "current project'?
How do I tell Android Studio to only build what I need for app1?
Edit based on replies:
I do want to run gradle via make so it does give feedback back to the IDE, because I'd like to see the "Make Messages" window:
Open Gradle tasks tab and select task to run. You can select a task from subprojects.
On command line:
gradle :app1:assembleDebug
I'm not sure if there is an "official" way of handling this yet but I got around it by creating a new "Run Configuration" and replacing the default "Build" option in the "Before Launch" section with my own command that calls Gradle with the relevant command line options.
If I make changes in my Android Library project I have to manually refresh, and sometimes clean all projects that use the Library. Is this normal? Is there a way around this?
I found a workaround for this issue. The basic idea is to use custom ant builder, because it has ability to refresh any specific resource or whole workspace on clean, manual build or auto-build.
So here are the steps:
1) Create a simple ant file with one empty stub target:
<?xml version="1.0" encoding="UTF-8"?>
<project name="android" >
<target name="refresh" />
</project>
2) Name it "lib-refresher.xml" and place it into folder where application's .project file is located.
3) Now go to eclipse, find the project that uses android library (not library project itself).
4) For this project go to: Project -> Properties -> Builder
5) Create new builder, select Ant task, select specified "lib-refresher.xml", select build base folder.
6) important - Refresh tab of ant builder task select "Specific resources" and select you library dependent project.
7) important - On Target tabs select "refresh" target for build variants: Clean, Manual Build, Auto Build.
8) important - Save changes, move your new custom ant builder to the top of builders stack.
Now the whole project is going to refresh just before building and lunching application. This will include all changes made to library project into application project. Which is what was needed.
(This can be done the other way around: library project may refresh whole workspace whenever autobuild is launched. This may be a bit overkill, but may solve some harder cases).
I have booth project in workspace (Android Library and Android App) and when i have made any changes in library i have must refresh project with app, but this fixed my problem:
(Application) project properties -> Java Build Path -> Tab Projects
and there i have added my android library.
That is true. If your lib builds a jar, a that you have added to the Android project you will need to refresh (you can also just right click and refresh on the external jar reference also to save time).
I had this same issue a couple weeks ago. I didn't find the solution I wanted, which was to modify the sources directly in the library project and the dependent projects automatically refresh, but I did find something better than the chaos of constantly refreshing and cleaning.
The best way that I could find was to use the linked library folder from the dependent project being worked on, that way the project sees the changes live. When jumping to another dependent project, you'll still need to refresh the files that were changed in the other project (usually just the src folder). You may also need to refresh the library project if you want to make direct changes. It might not sound like much of a help, but if you spend large chunks of time in a single dependent project (as has been my case so far), it really does help.