After a while of working with Android Studio and figuring out some things the hard way, I'd thought I collect this knowledge here in this sticker thread, so you don't have to go through the same process on your own.

The basic steps to set everything up are described very well in this tutorial. This thread collects additional info about the current situation, which is subject to change at any time as Google is improving and changing Android Studio. This post is as of 29 April 2016. I'll do my best to keep it up to date.

Please keep in mind that NDK (C++) support in Android Studio is experimental and it is not expected that everything runs smoothly. You might get the occasional "Internal IDE error" or other unexpected behaviour, and might need to close and restart Android Studio if something is not working.

Update 29 April 2016: this sticky post is getting shorter as I keep removing issues that are now fixed by Google.

1. Make sure you are running the newest Android Studio

This includes both the Android Studio app and the Android build tools. Make sure you always use the lateset version. As of April 2016, JUCE supports Android Studio 2.1.

2. Get the native debugger running

[updated on 24 Feb 2016]

First of all, go to the SDK Manager (Tools -> Android -> SDK Manager) and make sure you have LLDB installed:

The next thing to do is to go into your app configuration here and to select app-native as the configuration you want to debug:

Setting breakpoints, looking at the call stack, etc. should all now work.

3. Release vs. Debug configurations

It is not obvious how to switch beetween Release and Debug builds. It is not the "Play" and "Bug" button, respectively (as far as I can tell, both do the same thing...)

Instead, it's here:

To actually build a release build, you also need to sign it. For testing you can use the debug keystore (default setting). But for a proper release build you have to create a keystore with a signing key using the command-line application keytool (documentation here), put it somewhere on your machine, and then when Android Studio asks you to provide a keystore, use the one you created.

Update 2 February 2016: How to run a Release build from within the IDE

If you try to run a release build on a physical device from within Android Studio using the "play" or "bug" buttons, you may get an "Error: Build Type isn't debuggable". In this case, ignore it, click on "Run", and in the next dialogue that pops up click on "Continue Anyway".

gradle wrapper
(this will create the “gradle wrapper” script that will build the app from the command line in the next step)

./gradlew assembleDebug
(or assembleRelease, respectively.)

On Windows, it should also work, although we didn’t test it. The generated wrapper script will be called gradlew.bat.

5. Known issues

5.1 General

If you ever see this error when opening a project in AS (happens for example after cleaning the build folder and re-exporting from Introjucer/Projucer):

then:

delete the project from the list on the left by hitting the backspace button while it is selected (blue).

Click on "Import project (Eclipse ADT, Gradle, etc.)"

A file dialogue opens. Navigate to the project manually, and in there select the "Android Studio" folder inside the "Builds" folder.

Import this. It will re-generate the missing .idea file and then the project should open again.

Another thing to keep in mind is the way we currently generate Android Studio projects from the Introjucer/Projucer. Apparently, AS expects all the source code of a project to be inside the project's app folder. However, with JUCE projects it is sometimes unavoidable to include source files that are somewhere else (e.g. in the global JUCE folder). Other IDEs like Xcode, Visual Studio etc. allow you to specify the location of each file that should be compiled, and then to organise them into groups. AS lacks this functionality. The way we currently emulate this common project structure on AS is to build a tree of symlinks inside the app source folder, which then link to the actual source files that may be located somewhere else.

This works just well most of the time, but you should keep in mind that such a symlink structure does not play very well with things like version control systems, compressing the folder, transferring it to another machine etc.

Update 2nd February 2016:

Android Studio seems to be not very good at picking up code changes and realising that it has to recompile (this applies to C++ code, not Java code). You will find yourself having to "Rebuild project" a lot, even if you have changed only one line of code. We are aware of this issue and have forwarded it to the Google Team. In the meantime, please post if anyone knows a solution.

Update 21 March 2016:

Android Studio apparently cannot handle underscores in the app activity class name (see this thread) so you should avoid them.

5.2 Windows-specific

We highly recommend to use either OSX or Ubuntu for Android Studio development. We strongly recommend not to use AS on Windows for developing JUCE apps as you are likely to run into unsolved issues. If you're brave enough anyway, here's a few tips:

update 15 Feb 2016:You need to run the Introjucer as Administrator, otherwise Project Saving for Android Studio will not work and you will get a bunch of Introjucer errors about failing to write a file to disk etc.

JUCE apps won't compile in AS if the JUCE module folder is on another drive than your project. Make sure both your project and the JUCE folder are in C:\, or alternatively set copy-mode for all JUCE modules in the Introjucer/Projucer.

5.3 OSX-specific

Sometimes, AS seems extremely slow on a Mac and/or is forever stuck at "Build symbols..." so you can't do anything. When this happens, do two things:

1. Increase the available memory. Here's how. Locate the file /Applications/Android Studio.app/Contents/bin/studio.vmoptions. It should look like this:

Sometimes, after being stuck for a while, AS will eventually display an "Out of memory" error dialogue. Whenever that happens, you can edit those numbers above directly in that dialogue, so you don't even have to manually edit studio.vmoptions.

Just tried to update from Android Studio 1.5 to 2.0. Clicking "Release Notes" as described above leads to a website where I can download a zip file. Should I do something with that zip file? Extract it over the existing Android Studio installation or so?

Just restarting Android Studio after having clicked "Release Notes" does not make the button "Update and restart" appear on my machine. I must be missing something...

Thanks. Got a few steps farther now. Behaved a little funny - and did not replace the installation of Android studio 1.5 so I now have both versions. Still fighting, not able to debug yet, but proceeding. I will post updates when I have more news.

Well, this looks like an Android Studio and/or gradle bug, so can’t really do much about it except reiterating for the 100th time that you should not use Android Studio on Windows because so many things are not working properly. For Android development, switch to Ubuntu or a Mac.

Since Android Studio 2.1 Beta 3, there is another bug which basically breaks the clang toolchain on OS X. I submitted the bug here: https://code.google.com/p/android/issues/detail?id=207585 but could not find any workaround. It is therefore recommended that everyone compiling JUCE apps with Android Studio uses the gcc toolchain instead (it’s a build setting in the Projucer). I changed the Projucer so that gcc is now the default option.

I cannot get the latest release of jucer to build for gradle. I go through the steps to generate the wrapper (which is successful) then I run the debug build command, ./gradlew assembleDebug, and get…

In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/app/src/main/jni/juce_gui_extra.cpp:9:
In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_gui_extra/juce_gui_extra.cpp:40:
In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_gui_extra/juce_gui_extra.h:53:
In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_gui_basics/juce_gui_basics.h:55:
In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_graphics/juce_graphics.h:55:
In file included from /Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_core/juce_core.h:169:
/Users/mikef/Desktop/JUCE-master_4_2/examples/Demo/Builds/AndroidStudio/…/…/…/…/modules/juce_core/system/juce_StandardHeader.h:53:10: fatal error: ‘memory’ file not found

Then after a few of those scrolling past clang crashes. Any ideas? I just updated to the latest everything but not being able to find memory seems odd

What OS are you on? Looks like you are using the clang toolchain? What are you trying to build? The JUCE Demo? Your own project? Do you use the default build settings that the Projucer uses, or custom ones? Did you make sure to re-build the Projucer from the newest tip?

Oh yeah. Now I know what’s going on. std::atomic doesn’t work/compile on pre-ARM7 (armeabi). There’s nothing we can do about that. So probably when you build from Android Studio, you have the ARM 7 architecture selected (armeabi-v7a in Build Variants). But when you build from the command line then gradle will always build all your architectures.

The fix is to remove armeabi from the architectures you are targeting.

If you’re up for using the experimental Gradle plugin for Android Studio, I’ve updated my Github repo (on the develop branch https://github.com/sureshjoshi/android-ndk-swig-example/tree/develop) to use Android Studio 1.5, and the latest experimental Gradle plugin (0.6.0-alpha3).
With this new plugin, there are a few changes required to the build.gradle files.
Please note, though, if you try to use SWIG AND the native auto-generation, the auto-generated code will be placed in the incorrect location in your SeePlusPlus_wrap.cxx file (it manually needs to be moved inside the “extern C” block.
You can read more about android ndk in android studio with swig if you like.

The Projucer project defaults will use the latest platform tools version for you. The SDK depends on the oldest phone you still want to support. If you are using midi you should use SDK version 23. But we also regularly test version 10.