I use Android Studio 4.0.1
In my project, my local.properties has the following properties:
sdk.dir=C\:\\Users\\xxx\\AppData\\Local\\Android\\Sdk
ndk.dir=c\:\\yyy\\tools\\android-ndk-r19c
cmake.dir=c\:\\zzz\\cmake-3.17.0-win64-x64
Despite this, I get a compilation error when I Build -> Rebuild project or Clean project because my CMakeLists.txt begins with cmake_minimum_required(VERSION 3.14.3) and Android Studio uses the CMake included in the Android Studio folder instead of the one I point to in cmake.dir:
CMake Error at CMakeLists.txt:5 (cmake_minimum_required):
CMake 3.14.3 or higher is required. You are running version 3.10.2
-- Configuring incomplete, errors occurred!
See also "C:/Users/xxx/AndroidStudioProjects/E2e/app/.cxx/cmake/debug/x86/CMakeFiles/CMakeOutput.log".
FAILED: build.ninja
ninja: error: rebuilding 'build.ninja': subcommand failed
C:\Users\xxx\AppData\Local\Android\Sdk\cmake\3.10.2.4988404\bin\cmake.exe -HC:\Users\xxx\AndroidStudioProjects\E2e\app\src\main\cpp -BC:\Users\xxx\AndroidStudioProjects\E2e\app\.cxx\cmake\debug\x86
What am I missing for AS to pick up the cmake 3.17 I already installed when I select Rebuild Project or Clean Project?
Notes:
The directory I point to with cmake.dir is valid and being read by AS. If I introduce a typo in the path, AS complains about it.
This problem only occurs when I do Build --> Rebuild project or Clean project. If instead I do Build --> Make project, then AS will pick up the cmake version that I point to in local.properties
Clean Project worked again after deleting .cxx folder
I'm not sure about Android Studio, but you could try editing the project's build.gradle :
android {
externalNativeBuild {
cmake {
path file('CMakeLists.txt')
version '3.24.1'
}
}
}
.... and CMakeLists.txt :
cmake_minimum_required(VERSION 3.24.1)
I'm setting up an android project from another company which involves selfmade C++ cross platform libraries. For an older version of these libraries an complete app project was made in java with a jni interface to access these libraries, which are stored as their own modules with gradle.build files. The goal is to get the app compiling for arm64-v8a architecture because of the Google requirements for app update.
The project is set up with:
gradle experimental plugin 0.11.0
gradle plugin 4.1
boost 1.64.0 for armeabi-v7a (got arm64-v8a precompiled libraries as replacement)
opencv 2.4.13.2
ndk r15c
I checked all dependencies for getting a arm64 pendant, which was only needed for the boost dependencies.
I tried changing the ABI list which is used for every project to include all architectures or all seperatly. I tried using other ndk versions. What might help but i didn't accomplish was changing the experimental gradle plugin to the normal plugin but i couldn't get that right.
I expected some compiling or linking errors but it only tells me "ABI filter 'arm64-v8a' is no longer supported in NDK version r15.2.4203891.". If i try other architectures i get the same error, but instead of the 'arm64-v8a' the current selected architecture. If i give an invalid architecture it changes to "Target ABI 'hello' is not supported.", so it recognizes the architecture i think.
Stacktrace of first error:
A problem occurred configuring project ':app'.
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeLibrary(ModelMap, NdkConfig, NdkHandler, ModelMap, File, ServiceRegistry) > create(livestage) > withType()
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeLibrary(ModelMap, NdkConfig, NdkHandler, ModelMap, File, ServiceRegistry) > create(lib-jni-cxx) > withType()
Exception thrown while executing model rule: NdkComponentModelPlugin.Rules#configureNativeBinary(BinaryContainer, ModelMap, NdkConfig, NdkHandler) > withType()
ABI filter 'arm64-v8a' is no longer supported in NDK version r15.2.4203891.
The experimental plugin hasn't been supported for years, so it's no surprise that it doesn't work. Migrate to externalNativeBuild: https://developer.android.com/studio/projects/add-native-code
I am unable to build a NDK project from the Android Studio environment but can build it manually using the command console.
I get the following error after building:
Error:Execution failed for task ':xxxxxx:compileReleaseNdk'.> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'C:\Users\xxxxx\AppData\Local\Android\SDK\android-sdk\ndk-bundle\ndk-build.cmd'' finished with non-zero exit value 2
I got a similar error while invoking ndk-build.cmd manually using the console from the jni directory where my NDK project is stored.However I fixed it by modifying the following in my Application.mk file as follows:
NDK_TOOLCHAIN_VERSION := 4.9
since 4.9 is the tool chain available on my install. I suspect from the Android Studio environment, the toolchain version is being picked incorrectly, and yet I do not know where to set this option in the GUI.
The build.gradle file has the following NDK block:
ndk{
moduleName "xxxxxx"
ldLibs "log"
cFlags "-std=c++11 -fexceptions"
stl "gnustl_static"
abiFilters "arm64-v8a armeabi armeabi-v7a mips mips64 x86 x86_64"
}
Please advise me on how to go about solving this problem.
Just out of curiosity, I moved my project directory to the desktop and tried to build that project. The build was successful.
Finally narrowed down the problem to the NDK compiler not being able to create the following intermediate object file inside my project folder:
C:\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\build\intermediates\ndk\debug\obj/local/arm64-v8a/objs/natXXXX/C_\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\src\main\jni\NativeXXXX.o.d
The reason was the well known windows path cannot exceed 255 characters issue. As you can see above the NDK-Build utility tries to append a deep folder hierarchy like "C_\Users\xxxxx\GitRepos\REVIEWS\xxx\SMART-xxxx\xxxx-xxx-androidnative\xxxLibraries\xxxlibrary\src\main\jni\" which exceeds MAX_PATH.
I have imported a project to Android Studio using Gradle. Import process was successful, but it gives an error for android.os.*, when I try to import it.
It is a libGDX project.
I suggest to use AGP Upgrade assistent.
I often have probs upgrading gradle. This time with artic fox and java 11 it I got all those infamous android.* not found errors.
Then I discovered that neat AGP Upgrade assistent (in tools since Studio 4.2) - and it did what it should and everything is now using gradle 7 and compiles again.
About time such a tool was introduced - and I just saw about half a year too late ;)
Recently, I met a similar case in Android Studio 3.2.1 Ubuntu/Linux version.
I am quite sure about the issue shall be related to the Android SDK installation,because I build the same project in Android Studio of my Windows 10 laptop.
Issue:
Java compiler error at Android studio
error: package android.os does not exist
error: package android.media does not exist
error: package android.content does not exist
error: package android.util does not exist
error: cannot find symbol variable Log
error: cannot find symbol class Context
error: cannot find symbol class AudioRecord
Solution:
The android.jar which was mentioned at the build.gradle file was not installed at the /sdk/platforms/ directory. See the android.jar dependency at my build.gradle file below(which caused the issue),
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
compile files(sdkDir+'/platforms/android-24/android.jar')
}
Install the correct android platform(correct API level as mentioned in the build.gradle file,if any) and rebuild the project.
I am building from an old article, https://medium.com/#authmane512/how-to-build-an-apk-from-command-line-without-ide-7260e1e22676, and it doesn't yet have a build.gradle file, but I had the same error. I solved it by changing the compile command in my Makefile to:
classes: $(SOURCES)
javac -d obj \
-source 1.6 \
-target 1.8 \
-classpath src \
-bootclasspath $(ANDROID) \
$+
where ANDROID is /usr/local/src/android/adt-bundle-linux-x86_64-20130717/sdk/platforms/android-19/android.jar.
I get warnings now that source value 6 is obsolete, but at least it compiles.
In my case it was showing same kind of error with android.content.context
I figured out that the issue is I was using old gradle version with below android params in build.gradle
android {
compileOptions {
sourceCompatibility JavaVersion.VERSION_11
targetCompatibility JavaVersion.VERSION_11
}
}
So I removed this and the error is no more.
The new Android gradle plugin (0.7) seems to include new support for the NDK, but in the documentation there is little to no mention of it (the only reference I found is a test called ndkSanAngeles).
It looks like gradle is looking for the NDK, which I have included in my PATH. However, building the project fails with
What went wrong:
Execution failed for task ':OGLTests:compileDefaultFlavorDebugNdk'.
NDK not configured
How can I configure the NDK in gradle?
My current build.gradle looks like this:
task nativeLibsToJar(type: Zip, description: 'create a jar with native libs') {
destinationDir file("$buildDir/native-libs")
baseName 'native-libs'
extension 'jar'
from fileTree(dir: 'src/main/libs', include: '**/*.so')
from fileTree(dir: 'src/main/libs', include: '**/gdb*')
into 'lib/'
}
tasks.withType(JavaCompile) {
compileTask -> compileTask.dependsOn nativeLibsToJar
}
dependencies {
compile fileTree(dir: "$buildDir/native-libs", include: '*.jar')
}
android {
compileSdkVersion 19
buildToolsVersion '19.0.0'
defaultConfig {
minSdkVersion 14
targetSdkVersion 19
versionCode 1
versionName "0.1"
}
buildTypes {
release {
runProguard false
}
debug {
// jniDebugBuild true
runProguard false
debuggable true
}
}
productFlavors {
defaultFlavor {
proguardFile 'proguard-rules.txt'
}
}
}
Thanks.
Looking through the gradle plugin code, I found the following that helped me use both NDK and prebuilt native libraries:
To simply Link in Prebuilt Native Libraries, just add an ndk section to your task. For instance, I added it below in productFlavors. The abiFilter is the folder name the libs are stored in. abiFilters means both libs from the comma separated list will be added to your final APK (so you could theoretically have "armeabi", "armeabi-v7a", "x86", and "mips" all in one APK, and the O/S would choose the supported architecture lib on install):
productFlavors {
arm {
ndk {
abiFilters "armeabi", "armeabi-v7a"
}
}
x86 {
ndk {
abiFilter "x86"
}
}
}
In this example, the arm build will create an APK with the V5 and V7A arm libs in it, and the x86 build will create an APK with just x86 libs in it. This will search for the native libraries in your project jniLibs directory. The jniLibs directory should be structures as the old jni directory, i.e.:
[project]/[app]/src/main/jniLibs/armeabi/libmyNative.so
[project]/[app]/src/main/jniLibs/armeabi-v7a/libmyNative.so
[project]/[app]/src/main/jniLibs/x86/libmyNative.so
Then you can load it in Java as follows:
static
{
loadLibrary("myNative");
}
Now, let's say one native library depends on another one. You MUST (if setting your min API to API 17 or lower) load the dependent libraries first:
static
{
loadLibrary("myDependency");
loadLibrary("myNative");
}
You can also place the ndk {} section in your defaultConfig or a buildType (such as debug or release or whatever else you may use). For example:
buildTypes {
debug {
ndk {
abiFilters "armeabi", "armeabi-v7a"
}
}
}
By prebuilt, I mean 3rd party libs you downloaded or a library you built using the NDK toolchain or your own ARM toolchain (not the ndk-build script itself).
In API 18, they fixed a long standing architectural issue that prevented the native lib loader from "automatically" loading dependencies because it didn't know about the application's lib directory (security reasons, etc). In API 18 and above, if myNative depends on myDependency above, you can just call loadLibrary("myNative") and the OS will handle loading myDependency. Don't RELY on this though, until the market penetration of devices running API 17 and below is at a low number acceptable to you.
To explicitly Build NDK Libraries From Source in the current version of Android Studio, you may do the following:
Set the ndk.dir value in your local.properties to point to NDK home as mentioned previously. Does anyone know if you can use env vars directly in local.properties? :)
In your build.gradle file, add something like this to your task (again, can be defaultConfig, debug, release, a productFlavor, etc):
ndk {
moduleName "myNDKModule"
stl "stlport_shared"
ldLibs "log", "z", "m"
cFlags "-I/some/include/path"
}
This is the basic structure with currently supported types (moduleName, stl, ldLibs, and cFlags). I looked and did not find more than this. There is an issue I believe with ldLibs because it automatically adds "-l" to the front of each field above. You can trick it though (I had to) by saying:
ldLibs "log -lz -lm -Wl,-whole-archive -l/path/to/someOtherLib -Wl,-no-whole-archive"
In this line, you're just tagging on to the end of the first parameter to add parameters that don't start with -l, so you can get by for now. In the case above, I'm linking a whole static library into my NDK module for use from within Java. I've asked the google developer to add additional features to allow this or even ability to merge your own Android.mk file into the NDK build process, but as this is all new, it may be a while.
Currently, whatever you put in build.gradle deletes the temp build directory and recreates it every time, so unless you want to download and modify the gradle android plugin source code (which would be fun), there are some "make due"'s like this required to get your stuff copied into the build. The android gradle script that provides this ndk support in essence generates an Android.mk file and builds using the NDK system in a temporary directory.
Sidetracked for a sec. The moduleName should match a c or cpp file in your project under the jni directory like:
[project]/[app]/src/main/jni/myNDKModule.cpp
The stl value should be set to a value of "stlport_shared" or "stlport_static" if you want to use the stlport libraries for C++. You can leave stl out if you don't need extended C++ support. Remember Android provides very basic C++ support by default. For other supported C++ libraries, view your NDK documentation guidelines in the NDK you downloaded. Note that by setting it to stlport_shared here, gradle copies the libstlport_shared.so lib from your NDK's sources/cxx-stl/stlport/libs directory to your APK's lib directories. It also handles the include path in the compiler (technically the gradle doesn't do all of this, but the Android NDK build system). So don't put your own copy of stlport into your jniLibs directory.
Lastly, I think cFlags is pretty obvious.
You can not set ANDROID_NDK_HOME on the Mac OSX (see below), but from some research I've done appears maybe this still works on other OSs. It will be removed though.
I wanted to comment but don't have the reputation yet. Dennis, the environment variables are ignored completely, not just overridden. In fact, you don't get any of your environment variables. From what I can tell, the Android Studio IDE creates its own environment with just a few specific environment variables (check System.getenv() and print it out from a gradle script).
I wrote this up as a bug here because using env vars builds fine from cmd line:
https://code.google.com/p/android/issues/detail?id=65213
but as you can see, Google decided they didn't want environment variables being used by the IDE at all; I'm still on the fence on that decision. It makes my life painful to have to update local.properties to point to absolute paths that can be loaded in my gradle scripts, which I still haven't figured out how to do yet (but haven't looked that hard). That means I either force my team members to use the same path as me, play with links, make them all type them in every time they pull the repo, or add an automation script. I believe it's a bad decision that will cost time for any developers that rely on env vars which may be small at the micro level but huge at the macro level.
groundloop, I believe the IDE will be updated soon with the ability to add the NDK folder path to your project, and it will auto generate the local.properties file from that (at least it wouldn't make sense if they had not thought of this).
For more detailed examples from Google, here are the latest examples (search for jni or ndk):
https://docs.google.com/viewer?a=v&pid=sites&srcid=YW5kcm9pZC5jb218dG9vbHN8Z3g6NDYzNTVjMjNmM2YwMjhhNA
cross-platform fat APKs using NDK:
Lastly, there is a drawback to using gradle and not being able to provide your own Android.mk file so that you could only link in 3rd party native libraries from a single architecture to your NDK. Note I said "link in". You can build the NDK Modules (moduleName above) in several architectures with the "abiFilters" command, and they will be placed in your app such that the same APK could be used on multiple architectures. If you need to link in your own 3rd party libs or even have different values for cFlags depending on your architecture, there's not a simple way.
I tried the following and it appeared to work at first, but then I found out it was simply building the NDK by appending everything together from the two ndk sections (or something like that, it did somehow build multiple architecture libraries though):
android {
compileSdkVersion 23
buildToolsVersion '23.0.1'
defaultConfig {
minSdkVersion 14
targetSdkVersion 23
versionCode 28
versionName "3.0"
}
buildTypes {
def commonLibs = " -lfoo -lbar -lwhatever"
def armV7LibsDir = "/whatever/armv7a/libs"
def armX86LibsDir = "/whatever/x86/libs"
def armV7IncDir = "/whatever/armv7a/include"
def x86IncDir = "/whatever/x86/include"
debug {
ndk {
cFlags = "-I" + armV7IncDir
moduleName "myNativeCPPModule"
stl "stlport_shared"
abiFilter "armeabi-v7a"
ldLibs "log -L" + armV7LibsDir + commonLibs
}
ndk {
cFlags = "-I" + armX86IncDir
moduleName "myNativeCPPModule"
stl "stlport_shared"
abiFilter "x86"
ldLibs "log -L" + armX86LibsDir + commonLibs
}
}
}
}
After much grief trying to create a fat binary in a clean manor with gradle and native 3rd party libs, I finally came to the conclusion that Google Play's built-in multi-architecture support for APKs is really the best route to go anyway, so create individual APKs for each architecture.
So I created multiple buildTypes, no product flavors, and added the following code to generate the version code for each type.
// This is somewhat nasty, but we need to put a "2" in front of all ARMEABI-V7A builds, a "3" in front of 64-bit ARM, etc.
// Google Play chooses the best APK based on version code, so if a device supports both X86 and
// ARM, it will choose the X86 APK (preferred because Inky ARM running on an X86 with Houdini ARM Emulator crashes in our case)
android.applicationVariants.all { variant ->
if (variant.buildType.name.equals('release')) {
variant.mergedFlavor.versionCode = 2000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debug')) {
variant.mergedFlavor.versionCode = 2000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debugArmV8a')) {
variant.mergedFlavor.versionCode = 3000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('releaseArmV8a')) {
variant.mergedFlavor.versionCode = 3000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debugMips')) {
variant.mergedFlavor.versionCode = 5000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('releaseMips')) {
variant.mergedFlavor.versionCode = 5000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debugMips64')) {
variant.mergedFlavor.versionCode = 6000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('releaseMips64')) {
variant.mergedFlavor.versionCode = 6000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debugX86')) {
variant.mergedFlavor.versionCode = 8000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('releaseX86')) {
variant.mergedFlavor.versionCode = 8000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('debugX86_64')) {
variant.mergedFlavor.versionCode = 9000 + defaultConfig.versionCode
} else if (variant.buildType.name.equals('releaseX86_64')) {
variant.mergedFlavor.versionCode = 9000 + defaultConfig.versionCode
}
}
Now all you have to do is set the value for versionCode in your defaultConfig object, as you would do normally, and this appends it to the end of the architecture-specific version string, based on build type. The version string remains the same for all builds but varies the code to provide an order of precedence from ARM all the way up to X86_64. It's a bit hackish or hard-coded, but it gets the job done. Note that this provides you with up to 999 versions, so if you need more, multiply the numbers above by 10, not sure what the max value is that you can put in for the version code.
In my case, we have a fairly complex build system. We build CPython for 9 architectures, 3 of which are Android, then build a bunch of our own libraries, and link them all together into a single library for each architecture. We use the ndk command line build tools, automake, and python to build everything, instead of Android.mk files. The final libraries are then linked into a single JNI interface cpp file (called myNativeCPPModule above). One click of the button, and everything is built all at once, very nice Android Studio.
Found the answer. Including ndk.dir=path/to/ndk in the local.properties file did the trick.
Update:
On the latest versions of Android Studio, you can set the value directly in the Project Structure > SDK location.
you can also set ANDROID_NDK_HOME environment variable
As commented before, adding ndk.dir= in local.properties helps. Interestingly I found that local.properties overrides any value set for environment variable ANDROID_NDK_HOME, even if you don't have ndk.dir configured in local.properties. (at least with the gradle android plugin v 0.7.3).
This is confounding as Android Studio can overwrite local.properties, and it doesn't seem to provide a way to configure ndk.dir :(
Android studio suggests to include the path to ndk in local.properties