Compile C++ program on Android: undefined function assert - android

I'm trying to compile my C++ program on Android but it won't compile because assert is undefined.
I've found a couple of hints online but none of them have worked:
I have set APP_OPTIM=debug in myApplication.mk
I have set NDK_DEBUG=1 through parameters override, e.g.
externalNativeBuild {
ndkBuild {
arguments "NDK_DEBUG:=1"
}
}
I have set the android:debuggable="true" attribute in my Android manifest document.
I have set the build types and toggled debuggable to true and false
buildTypes {
release {
debuggable true
...
}
debug {
debuggable true
...
}
}
I don't know what else I can do. Assert is still being undefined. I must #define assert ; an empty statement to compile. I want to do it the right way.

I am also using CMake and able to use assert.
I would suggest you to try creating new project from android-studio 'File->new project->Choose your project(scroll down and select Native C++)->Next->Next-Finish'. This will create android app with native component in it. modify the .cpp file of native component to use assert(include assert.h) and see if it works.
Also check if this post help you to resolve your issue.
https://stackoverflow.com/a/9144080/4181904

Related

Custom build type with resources

There is custom build type mock and it initialised with debug:
buildTypes {
release {
}
debug {
}
mock {
initWith debug
}
}
There are also debug resources under /debug/res/values/file.xml.
Without copying /debug/res/values/file.xml into /mock/res/values/file.xml project doesn't compile as compiler can't find mock resources.
Is there way to let gradle know that debug resources should be reused for mock build type?
You can put file.xml in the main/res/values folder to share it across all build types

Where are build types of the app defined?

I know we can edit build types in Android Studio:
I know we can edit each build type setting in gradle:
android {
buildTypes {
release {
minifyEnabled true
}
}
I know we can detect build types in code. How do I detect if I am in release or debug mode?
But where actually are the build types defined? Let say I want to commit it to git. What should I do to keep build types of the project consistent?
Where actually are the build types defined?
Basically, BuildConfig is the auto-generated class that resides under path :
app/build/generated/source/buildConfig/yourBuildType/yourPackageName/BuildConfig.java.
This class holds variables provided by buildTypes {} block from app level build.gradle file. So, on every clean & rebuild of project, Gradle auto generates BuildConfig class that can be used in further Android development environment.
I.e. BuildConfig.DEBUG is the default variable that we can use in our application code to determine it's buildType.
We can provide our own fields through buildType from build.gradle file like following:
android {
. . .
buildTypes {
debug {
buildConfigField "String", "SOME_VARIABLE", '"This string value is from build config class"'
}
}
. . .
}

Android and the Fabric (Crashlytics) plugin always generates a UUID (Gradle Kotlin DSL)

I want Fabric to stop generating a UUID on each build. What used to work with Gradle's Groovy DSL does not work with the newer Kotlin DSL. How can I achieve my goal with the Kotlin DSL?
(Gradle version 4.10.2, Fabric 1.25.4)
According to Fabric's documentation, you can add the following to your app's build script
android {
buildTypes {
debug {
// Only use this flag on builds you don't proguard or upload
// to beta-by-crashlytics
ext.alwaysUpdateBuildId = false
and this works. It prevents Fabric from generating a UUID on each debug build. However, if I convert my build script to Kotlin DSL, the following doesn't work
android {
buildTypes {
getByName("debug") {
// Only use this flag on builds you don't proguard or upload
// to beta-by-crashlytics
ext.set("alwaysUpdateBuildId", false)
Fabric ignores this value, now.
I have tried variations, such as the following:
project.ext.set("alwaysUpdateBuildId", false)
rootProject.ext.set("alwaysUpdateBuildId", false)
val alwaysUpdateBuildId by extra(false)
val alwaysUpdateBuildId by project.extra(false)
val alwaysUpdateBuildId by rootProject.extra(false)
None work.
For further reference, the Gradle task generating this value appears to be named :app:fabricGenerateResourcesDebug, and has type DefaultTask.
As Martin Rajniak mentioned, you can only call extra on ExtensionAware objects, with BuildType not being declared as one.
However, during runtime, build types actually are ExtensionAware, which is why this works in Groovy due to its dynamicity, but not in Kotlin where extra in this scope will reference the Project's extensions.
In order to achieve this without Groovy, we can simply cast the build type to ExtensionAware:
android {
buildTypes {
getByName("debug") {
(this as ExtensionAware).extra["alwaysUpdateBuildId"] = false
}
}
}
I have found a workaround to this problem. Create a file, fabric.gradle (Groovy build script!) and place it in your project structure somewhere. It will have the following contents:
// or "com.android.library"
project.pluginManager.withPlugin("com.android.application") {
android.buildTypes.debug.ext.alwaysUpdateBuildId = false
}
Now, in the build script for your module (let's call it app/build.gradle.kts), apply this script plugin:
apply(from = "path/to/fabric.gradle")
This workaround is based on the advice here, in the Kotlin DSL primer.

ndk-build stays at NDEBUG=1 despite Gradle debuggable: true in Android Studio

I'm having a ton of difficulty trying to get Gradle to compile a debug version of my JNI code through NDK build. I've set the debug build to be debuggable in the build.gradle file like so:
buildTypes {
debug {
debuggable true
jniDebuggable true
}
}
I can confirm that the switches are taking effect if I check out Build/Edit Build types. However, once I check the ndkBuild_build_command.txt file inside of the .externalNdkBuild directory, I notice the following entries:
NDEBUG=1
APP_PLATFORM=android-9
I can confirm that my JNI code does not seem to be debuggable. Even though the breakpoints trigger, variables all show "variable not available" in LLVM.
Any ideas as to why NDEBUG is turned on even in a debug build? As a sidenote, I also have no idea where the android-9 platform is entering in... I'm not setting that myself anywhere that I could find.
If you use Android Studio 2.2 with externalNativeBuild, you can set APP_OPTIM=debug in your Application.mk or NDK_DEBUG=1 through parameters override, e.g.
externalNativeBuild {
ndkBuild {
arguments "NDK_DEBUG:=1"
}
}

Gradle: project dependency with variables

I have a gradle script which needs to be imported as a dependency like this:
compile project(':subproject', { ext.app = 'myApp'; ext.serverUrl = 'https://example.com'; ext.system = 'LIVE'})
This is working fine, if I set the variables directly in the dependency statement.
As I have a different system for debug and for release I tried to move these properties to the buildTypes:
...
debug {
debuggable true
serverUrl = 'https://example.com'
system = 'TEST'
}
prerelease {
debuggable true
serverUrl = 'https://example.com'
system = 'STAGING'
}
release {
serverUrl = 'https://example.com'
system = 'LIVE'
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
...
dependencies {
compile project(':subproject', { ext.app = appName; ext.serverUrl = serverUrl; ext.system = system })
}
So, when I build assembleDebug it should use TEST and with assemblePrerelease it should use STAGING. However it is always using the release build type variables to compile the dependency.
The library already contains publishNonDefault true
What's wrong with this gradle script?
I answer my own question.
Gradle does not parse the gradle file as expected. The closures will be evaluated in a single step when the tasks are being generated. This means that there is no concept of having a variable which will only be used when the specific task is being executed. The file is being read once which causes the variables to override the previous values of another flavor or buildType. This is also the reason why changing the order of the flavors results in different values.
The correct solution would be to define a custom task which is run right after the file has been generated. That task will generate a set of tasks for each variant of the app which themselves contain the configuration what to do.
This SO article helped me alot: How to get current buildType in Android Gradle configuration

Categories

Resources