We decided to use GitHub as our version control. I know the Gradle build scripts use certain paths, such as the Android SDK path in the local.properties file.
Since this path will differ between the five of us, I think the projects will fail to build on my teammates' machines when they pull changes from GitHub. Is this correct?
If so, can we all make an environment variable called something like ANDROID_SDK and use that for the sdk.dir in the local.properties? Would the project properly build on all of our machines if we used the environment variable? Are there any other places where we may need to set
a similar environment variable? Will this work? If so, how do we do this?
I am not sure if this is the best way to go about setting up a team project for Android. I'm looking for suggestions on a best practice for this.
Is this correct?
No, because IMHO local.properties should not be in your Git repo. The standard Android Studio .gitignore file (created when you create the project) has local.properties, meaning that local.properties would not be committed to your repo.
As Doug Stevenson points out in a comment, local.properties is generated when you import a project. It will be driven by Android Studio settings.
can we all make an environment variable called something like ANDROID_SDK and use that for the sdk.dir in the local.properties?
Not for use with Android Studio, at least the last I tried it. For command-line Gradle builds, that works fine, but Android Studio does not pass the environment to its forked Gradle process.
Related
I have set an environment variable ANDROID_HOME, which points to my android SDK location. However, every time I open my project in Android Studio it places local.properties file to the root of my project and copies my SDK location from ANDROID_HOME to this file. I want Android Studio use ANDROID_HOME directly, without generating local.properties.
Why? I'm on Windows 10 and I use Bash for Windows. I want to run command line using Bash while running Android Studio from Windows. For this I need two ANDROID_HOME environment variables, one for Windows, one for Bash. This is because although they point to the same (windows) android SDK the format is different, for Windows it is C:\Users\me\Android SDK while for Bash it's /mnt/c/Users/me/Android SDK. When Android Studio creates local.properties with windows path Bash becomes broken since apparently local.properties takes advantage over ANDROID_HOME, so I have to delete it manually.
You might find this article useful:
Posix path conversion (mingw.org)
The gradle android plugin "Application" extension
(your regular gradle-android interface) has a property
sdkDirectory. Perhaps this can override it? I can't check.
I think there is a configuration switch for bash on Windows to parse path separators Windows-like, can't seem to find it, it is buried deep inside MinGW or MSYS docs I think.
Last resort - git Hooks. Read the ProGit book chapter on Hooks.
The Android will generate this file always when gradle sync it. But if you delete it and define ANDROID_HOME and ANDROID_NDK_HOME environment variables, every time that generates it will read ANDROID_HOME and ANDROID_NDK_HOME.
If you want to build your project in many computers with different home folders, just keep the local.properties outside the source version control.
I'm preparing an Android build pipeline in Jenkins, on a Windows build server. Jenkins uses a number of workspaces and will often re-use them. I've noticed that when Jenkins re-uses a workspace, there are no problems and a build goes perfectly. But when it first checks out a new workspace, the gradle wrapper complains that it cannot install Android build-tools. The build tools (the exact version) are already installed.
I can open another older workspace and run the gradle build in there and it works perfectly and then, with the same login and in the exact same cmd session, go to the new workspace and run the same command and it complains that it cannot install Android build-tools.
A note about the Android configuration: I'm storing the Android SDK in C:\android-sdk\ and have given every user access to that directory. ANDROID_HOME and ANDROID_SDK are set as system-wide variables. This is the most convenient solution- this way every user that logs in, domain account or otherwise, is (in theory) able to immediately build the solution without having to set up their own SDK, and we don't end up with a lot of duplicated SDK data.
I can fix the issue manually by opening the workspace folder in Android Studio. Just doing this alone seems to fix the issue. My hypothesis is that somewhere there's a cached value in the project metadata telling gradle where to find the Android build-tools, and when I open Android Studio it updates this value.
Obviously the work-around isn't adequate because the build needs to work consistently every time without human intervention. Is there some command I can use to refresh this cache? Or perhaps some configuration files that are checked into git that shouldn't be?
Figured it out. Gradle looks in two places, in order of priority, for your SDK: Firstly, it checks whether a local.properties file specifies the SDK. Then, it tries the ANDROID_HOME (not ANDROID_SDK) system variable. Opening a folder in Android Studio generates the local.properties file, which is why that work-around worked.
I had no local.properties file, but my ANDROID_HOME was set to the Android Studio install folder rather than the Android SDK. When I moved it to the SDK and re-started the Jenkins agent service it worked.
I'm trying to import a libGDX project into IntelliJ running OSX 10.9. When creating my own project it's not an issue specifying the path to the android sdk in the gdx-setup, but when importing one I keep getting the issue:
SDK location not found. Define location with sdk.dir in the local.properties file or with an ANDROID_HOME environment variable.
I haven't found anything resembling a local.properties file and wouldn't know how to create one, so I set the ANDROID_HOME environment variable with the path to my android sdk, adding this to my .bash_profile: export ANDROID_HOME=/Applications/android-sdk
Additionally I added $ANDROID_HOME:$ANDROID_HOME/tools:$ANDROID_HOME/platform-tools to my PATH as well, which seems somewhat overkill, but unfortunately the PATH isn't recursive.
IntelliJ isn't getting any of this however, I'm guessing adding it to my .bash_profile isn't the right way of doing it?
Thank you very much in advance!
So thanks to the friendly people in the libGDX IRC it turned out to be relatively easy adding the local.properties file. The necessary content is just
sdk.dir=/path/to/android/sdk
This solves the problem and IntelliJ is now able to import the project. No further info on using environment variables.
This is unorthodox but I cannot comment(not enough karma) so I'm writing an answer instead, where is the local.properties file that you speak of? I am unable to find it.
However I've solved it by:
open your Project Structure settings (Ctrl+alt+shift+s)
Under the Platform Settings group select SDKs
with the + sign add Android SDK > Select your /path/to/android/sdk
Select build target
Optional : I've also named the sdk as 'android' I am unsure whether this fixed anything but it does make sdk's ambiguous
Apply
Go to Project Settings and choose Modules
Select android and under Module Sdk choose the android sdk we just added (renaming can come in handy here).
Apply, wait and done.
On IntelliJ IDEA 2016.1.2 it's worked this way for me:
Menu File -> Other Settings -> Default Project Structure...
There on the left under Project Settings -> Projects
Click on New... button
Choose Android SDK and insert path to it.
After that for you new or imported projects IDEA will know where to find Android SDK
I'm migrating an Android build system from ADT to mostly-out-of-the-box Ant and would like to make it as painless as possible for devs. A fresh checkout doesn't contain local.properties (as advised, and which makes perfect sense), and the build yells at you:
sdk.dir is missing. Make sure to generate local.properties using
'android update project' or to inject it through the ANDROID_HOME
environment variable.
Either of these steps is tedious enough that doing it after every fresh checkout is unsavory under Windows. Given that the ADT knows the SDK location (and that's all we really need), is there any way to spit the file out without having to drop into cmd drill into Windows env vars?
I tried Project > Android Tools > Fix Project Properties, but that doesn't seem to take care of local.properties.
There's no way to do it. Eclipse with ADT uses a different mechanisms for some parts of the build project.
I'm not sure why setting ANDROID_HOME is tedious to do after every checkout. You only need to set it once.
I am trying to automate the android build process using Jenkins
I am using the following site to achieve this
Link to site
I am successfully able to Build it on my own machine. Initially i got error saying that build.xml file not found (build using ant requires this file). So i execute "android update project". So it automatically generate all necessary file for ant.
Now my problem begins when i tried to host my repo to remote server and tried to build from another machine. The error it is giving is the sdk.dir is not correct. When i analysed the project folder ther is a file called local.properties which contains the SDK path of my first machine which is wrong for other machines. So i add that file to gitignore. Now that file is not tracking and because of this the build is failing.
So is there any way to automatically generate the files that is necessary for ant after jenkins is cloning project from the remote repo?
From the website you link to, they precisely explain how to configure sdk.dir:
Configuring the environment
When jenkins builds your project with Ant, it needs to know where your
android sdk folder is. To do this, click Advanced on the Ant target
build step you just configured and add the following variable to the
Properties field. sdk.dir=/opt/android-sdk-linux/
Don’t forget to substitute the value of the variable with the correct
location where the Android SDK is installed on your build server.
Job configuration is done. Click Save. Time to test your build.
We also build android apps with Jenkins, and also need to edit the local.properties.
In my case, I have the file updated with the path to SDK by the Jenkins build itself. Just before the build starts.
You can use a simple sed command on linux or echo the content on windows (overwriting content).
Example flow:
SCM - get sources
Edit the local.properties (as suggested before)
Run ant build
Note - if you are using the "Invoke Ant", you should add an "Execute Shell" step before to deal with the editing of the local.properties.
I hope this helps.
Yes.
If you install the Android Emulator Plugin for Jenkins, you can add the "Create Android build files" build step to your job.
This will automatically detect any Android app, test or library projects in your Jenkins workspace and add/update the build.xml and local.properties files as necessary.
Alternatively, if you're using the Ant build step and already have the build.xml in your repository, you can ignore the need to create a local.properties file, by specifying the sdk.dir property yourself in the Advanced Ant options.
You can configure ant properties in jenkins. So you can specify all properties of your local.properties through the jenkins job configuration.
Of course you will have to install the android sdk on the jenkins build server.
Please read this for info on how setting ant properties with jenkins.
It's not a good practice to put the local.properties under source code management since multiple developers and CI will have different values for those properties.
you can edit the local.properties file in the jenkins workspace folder to the correct sdk path
I think you want to add the build step "Create Android build files" to your configuration. Place it before the ant build.
This invokes the android update project and android update lib-project. Make sure you referenced your library dependencies in the project.properties with relative paths. Like this:
# Project target.
target=Google Inc.:Google APIs:19
android.library.reference.1=../external-libs/google-play-services_lib
android.library.reference.2=../external-libs/android-support-v7-appcompat