CODEWITHSUNDEEP
androidandroid-ndkandroid-gradle-pluginandroid-studio-3.0android-build
SirKnigget
SirKnigget

Reputation: 3644

NDK on Android Studio keeps rebuilding all the time, takes forever

I have a big Android Studio project that has a separate module which contains native code. The native build is defined with CMake and includes a bunch of source files of C++ code.

I noticed that since a very recent update (might be Android Studio 3.5), NDK rebuilds everything ALL THE TIME. It can happen with a small change in Java code, switching flavor in an unrelated module in the project, incrementing version code, etc.

This is a major problem, since it can waste 10 minutes at a time for no reason. I could not find a reasonable way to profile NDK builds in Android Studio and check what's causing the rebuild or what's taking so long.

Unfortunately the project's build files are too big to attach here. Any pointers for things to look after?

Upvotes: 5

Views: 1329

Answers (3)

Alexandre Clement
Alexandre Clement

Reputation: 11

This appears to have been a regression in behavior from Android Studio 3.4 and has been fixed in Android Studio 4.1 Canary 4. Release notes are here.

Upvotes: 1

Bram
Bram

Reputation: 8283

For the C/C++ code that you build with cmake, make sure you point cmake to a directory where it can keep its object files and binary outputs.

Let's say you have a dependency on Game in your top level CMakeLists.txt like so:

# dependency: Game
set ( game_src_DIR ../Game )
add_subdirectory( ${game_src_DIR} ${CMAKE_CURRENT_BINARY_DIR}/game )

Then the second parameter to add_subdirectory specified the place where AndroidStudio will keep the object files.

The debug and release object files will live in different subdirs, as will each dependency, so switching debug/release will not clash.

Upvotes: 1

Alex Cohn
Alex Cohn

Reputation: 57163

Often, it helps to split the AS project such that the C++ part, possibly with its Java wrappers become a separate (library) module. This module will hopefully be more stable, not sensitive to increments of app version code.

Such module should not define many flavors, but have careful matching to the flavors of other modules. Sometimes, it makes sense even to disable "debug" variants for such library. There was an effort of the NDK team to better handle debug vs. release build switching, but this is still tricky.

But if after these improvements, insignificant changes to the project still cause massive rebuild, I would suggest to consider ccache.

Upvotes: 0

Related Questions