Environment variable in settings.gradle not working with Android Studio

Question

I do have a multi-module project with a library project in a different root path. As illustration you can imagine something like this:

/projects_home/projects/app_root
   |--app/
   |   |--build.gradle
   |--build.gradle
   |--settings.gradle

/libraries_home/libraries
   |--libA
       |--build.gradle

In my settings.gradle file I am able to set the absolute path to the library project utilizing the projectDir attribute. This works just fine within the console as well as with Android Studio.

But if I try to use an environment variable it stops working with Android Studio. The settings.gradle for the example above would look like this:

include ':app'
include ':libA'

project(':libA').projectDir = new File("$System.env.LIB_ROOT", '/libraries/libA')

If I build with the graddle wrapper from the console, it still works. But AS stops working with the following error msg:

Gradle 'app' project refresh failed:
Configuration with name 'default' not found.

If I unset the environment variable, the build on console fails with the same msg:

* What went wrong:
A problem occurred configuring project ':app'.
> Configuration with name 'default' not found.

Therefore I guess that AS is somehow not be able to access the environment variables set with my ~/.bashrc

Does somebody of you maybe know a way how I can make AS aware of my environment?

Answer 1

On Mac OS Android Studio actually started to read env vars some time ago. Before it didn't. But errors may occur during the process importing those vars. You can read further more here on official intellij support page https://youtrack.jetbrains.com/articles/IDEA-A-19/Shell-Environment-Loading

Answer 2

On Macs, Android Studio does not read environment variables for use in Gradle apparently. I believe this is the cause for confusion in the answers here - maybe it does on Windows.

In order to get Android Studio to read environment variables, I run the application from the command line:

> /Applications/Android\ Studio.app/Contents/MacOS/studio 

The other answers here offer solutions other than using environment variables. For my situation, I'm using a library I didn't write that requires the use of an environment variable, and I'd rather not edit their code so it's easier to update later.

EDIT: And, I have a dock icon to launch Android Studio this way:

• OSX: Add Dock icon for dedicated Terminal command explains how.

Answer 3

I faced the same issue in apple laptop after the Android Studio Bumblebee update. This seems to be happening due to some permission issue with the Android Studio.

The workaround is to add missing flag:

chmod +x /Applications/Android\ Studio.app/Contents/bin/printenv

You can check this issue tracker for more details.

Answer 4

MAC OS Update

I confirm that I have Environmental Variables working on Mac OS Catalina

You just need to set it in the shell you are using. I was using zsh, and was trying to set ~/.bash_profile, so it wasn't working.

Example:

ZSH Profile

Answer 5

Android Studio does read the environment variables. You can prove it by launching Android Studio from the shell in which those env. variables being specified instead of from X-window dash board.

The reason you did not have those variables is the X-window environment you were using did not read $HOME/.bashrc which contained those variables. This makes sense because bashrc is for Bash not X.

Assuming you are using GNOME or Unity, to launch Android Studio with those environment variables being specified, just modify the .desktop file of Android Studio (e.g. ~/.local/share/applications/android-studio.desktop):

Find this line:

Exec="/home/username/tools/android/android-studio/bin/studio.sh" %f

Change it to:

Exec=env LIB_ROOT=/libraries_home "/home/username/tools/android/android-studio/bin/studio.sh" %f

Note:

This modification just prepend env LIB_ROOT=/libraries_home to the original command. You must replace username with your own user name.

Update

If you have any questions, please leave a comment instead of editing the answer directly.

Answer 6

It works for me with the following steps:

1. Set your variable in Windows
2. Reboot
3. reach it in gradle build: System.env.MYVARIABLE

Answer 7

You can set environment variable by appending:

-DYOUR_VARIABLE=variable_value

to ~/Library/Preferences/AndroidStudioX.X/studio.vmoptions that you can open by selecting Help -> Edit Custom VM Options... from Android Studio menu.

And then you can use it like:

System.env.YOUR_VARIABLE

in build.gradle or settings.gradle.

Answer 8

Despite the answer from Scott Barta is correct, I realized there is a way to solve my problem and wan't to share this in case somebody else has the same requirement.

I am now using the gradle.properties file do define and use gradle properties instead of system properties. The documentation of this feature can be fined in the user guide

The solution to my original question now looks like this:

$USER_HOME/.gradle/gradle.properties:

LIB_ROOT=/libraries_home

The settings.gradle file has to be modified to use the gradle property instead of the system property:

include ':app'
include ':libA'

project(':libA').projectDir = new File(LIB_ROOT, '/libraries/libA')

This works fine for me, headless as well as with AS.

Some more words regarding the fact that I am working with modules which are not placed underneath one project root. Till now it looks like AS is not complaining about this. But I just started working with this structure and it may be that I will run into problems later. What I like about this is the more flat representation in AS which is more like I am used to have it with Eclipse.

What is also described in the user guide, is to set system properties with the gradle.properties file. I tried this also, but I did run into the same problems with AS using environment variables.

Answer 9

Android Studio doesn't read environment variables, so this approach won't work. Also, using the projectDir scheme in settings.gradle will probably cause problems. Android Studio has a limitation that all of its modules need to be located underneath the project root. If you have libraries that are used in multiple projects and they can't be placed under a single project root, the best advice is to have them publish JARs or AARs to a local Maven repository that individual projects can pick up.