ndk-gdb with Android Studio - c++

I was previously able to use eclipse to build an android app with ndk-build and I was able to debug using the ndk-gdb. When I do the same on the app built using Android Studio, I get this error:
ERROR: Non-debuggable application installed on the target device.
Please re-install the debuggable version!
I have set jniDebuggable=true in build.gradle:
buildTypes {
debug {
debuggable true
jniDebuggable true
}
release {
debuggable false
jniDebuggable true
}
}
Am I missing something here?
Note: I have tested on Samsung S3, Moto-g Second Generation. I tried with r9d, 10c and 10d.

Related

Build and test V8 from AOSP for the older version on Ubuntu 18.04.5 LTS

I am trying to run the unit tests for the V8 present in the AOSP's lollipop release: external/chromium_org/v8
by following the documentation from https://v8.dev/docs/build. But the build itself is constantly failing.
Steps followed:
Export the depot_tools path
gclient sync
install dependencies using ./build/install-build-deps.sh (This script was not present by default in the source code, so had to copy manually from the higher version)
gm x64.release
I have installed all the dependencies and followed all the steps from the documentation mentioned above but when I do:
gm x64.release
the build fails with the following output:
# echo > out/x64.release/args.gn << EOF
is_component_build = false
is_debug = false
target_cpu = "x64"
use_goma = false
v8_enable_backtrace = true
v8_enable_disassembler = true
v8_enable_object_print = true
v8_enable_verify_heap = true
EOF
# gn gen out/x64.release
ERROR at //build/config/BUILDCONFIG.gn:71:7: Undefined identifier
if (os == "chromeos") {
^-
I have tried building the it with gn as well by following the manual workflow but I am ending up with the same errors. I also tried setting the os variable to linux in the gn args list but there as well I get the unknown identifier error.
I see that the v8 used in the AOSP project differs a lot in terms of files from the main source code with the same version. The helper script tools/dev/gm.py is also not present by default so I am using one from the higher version. It would be great if anyone could suggest if there's any different set of steps I should be following or any other resources I can refer to in order to build the V8 present in the AOSP project
Version: V8 3.29.88.17
OS: Ubuntu 18.04.5 LTS
Architecture: x86_64
3.29 is seriously old; I'm not surprised that it won't build with current tools. Rule of thumb: when building old software, use the tools that were used to build it back then.
In the case at hand: try make x64.release.check -jN with N being the number of CPU cores you have.
I see that the v8 used in the AOSP project differs a lot in terms of files from the main source code with the same version.
The "lollipop-release" branch contains V8 3.27.34.15, whereas "lollipop-mr1-release" contains V8 3.29.88.17 which you quoted. Does that explain the differences?

How to change CMake path in Android Studio

I copied an existing Android Studio project from another user and I can't compile C++ files using CMake because it uses the other user's CMake path
I already tried to delete and re-create the CMakeLists.txt file and re-installed CMake using SDK Manager
Here's my gradle:
apply plugin: 'com.android.library'
android {
compileSdkVersion 25
defaultConfig {
. . .
externalNativeBuild {
cmake {
arguments '-DANDROID_TOOLCHAIN=clang'
}
}
}
buildTypes {
release {
. . .
}
}
lintOptions {
abortOnError false
}
externalNativeBuild {
cmake {
path file('CMakeLists.txt')
}
}
}
About 2 months ago, the project worked perfectly. Then I made some minor modifications and now I have this error.
It's just like there's a way to indicate which CMake use, but I don't know where to find it.
Here's a resume of what the console show me when I want to clean the project:
Caused by: net.rubygrapefruit.platform.NativeException: Could not start '/Users/Old_User/Library/Android/sdk/cmake/3.6.4111459/bin/cmake'
at net.rubygrapefruit.platform.internal.DefaultProcessLauncher.start(DefaultProcessLauncher.java:27)
at net.rubygrapefruit.platform.internal.WrapperProcessLauncher.start(WrapperProcessLauncher.java:36)
The rest of the error log is about the same message saying that it can find the cmake file
It appears that android build system is not able to find cmake utility. Please check if it is installed.

How to fix Android NDK app crash with UnsatisfiedLinkError when loading protobuf-lite.so on Android 6.0?

I have created an Android application with a custom C++ library that depends on Google's protobuf-lite library. It works fine on all the recent devices I have tried to run it on (under Android 7, 8 and 8.1). However, I found that on older devices running Android 6.0.1 or 6.0 (Asus Nexus 7 and some old Motorola phone), the application crashes on loading the libprotobuf-lite.so dependency.
Here is the stacktrace I get:
E/AndroidRuntime: FATAL EXCEPTION:
main Process: com.mycompany.core, PID: 11582 java.lang.UnsatisfiedLinkError:
dlopen failed: cannot locate symbol "__aeabi_memmove8" referenced by "/data/app/com.mycompany.core-2/lib/arm/libprotobuf-lite.so"...
at java.lang.Runtime.loadLibrary(Runtime.java:372)
at java.lang.System.loadLibrary(System.java:1076)
at com.mycompany.core.CameraTestActivity.<clinit>(CameraTestActivity.java:46)
at java.lang.Class.newInstance(Native Method)
at android.app.Instrumentation.newActivity(Instrumentation.java:1067)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2317)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2476)
at android.app.ActivityThread.-wrap11(ActivityThread.java)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1344)
at android.os.Handler.dispatchMessage(Handler.java:102)
at android.os.Looper.loop(Looper.java:148)
at android.app.ActivityThread.main(ActivityThread.java:5417)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726)$
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616)
This is really weird because the missing symbol "__aeabi_memmove8" appears to be a low-level standard library feature and I do not really grasp why it would not be found on Android 6.
In addition, I am quite confident that the issue comes from protobuf-lite not linking correctly because previous versions of my app, which were not using protobuf, ran fine on these Android 6 devices.
Below are some details on my config.
Protobuf version: 3.6.1
Lib package cross-compiled from source using Cmake GUI, NDK r18 toolchain and MinGW
Devices' ABI: armeabi-v7a
Android SDK compile version: API 28
Application build toolchain : Gradle + CMake.
Android Studio 3.1.3
Here is my build.gradle file:
android {
compileSdkVersion 28
defaultConfig {
applicationId "com.mycompany.core"
minSdkVersion 21
targetSdkVersion 28
versionCode 1
versionName "1.0"
testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
externalNativeBuild {
cmake {
cppFlags "-frtti -fexceptions"
}
}
}
buildTypes {
release {
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
ndk{
abiFilters "arm64-v8a", "armeabi-v7a"
}
}
debug {
ndk{
abiFilters "arm64-v8a", "armeabi-v7a"
}
}
}
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
}
dependencies {
implementation fileTree(include: ['*.jar'], dir: 'libs')
implementation 'com.android.support.constraint:constraint-layout:1.1.3'
implementation "android.arch.lifecycle:extensions:1.1.0"
implementation "android.arch.lifecycle:viewmodel:1.1.0"
testImplementation 'junit:junit:4.12'
androidTestImplementation 'com.android.support.test:runner:1.0.2'
androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}
And here is my CMakeLists.txt file:
cmake_minimum_required(VERSION 3.4.1)
include_directories(src/main/cpp/protobuf/include)
file(GLOB SRCS
"src/main/cpp/core/*.cpp"
)
file(GLOB JNI_SRCS
"src/main/cpp/jni/*.cpp"
)
add_library(mycorelib SHARED ${SRCS} ${JNI_SRCS})
find_library(log-lib log)
add_library(libprotobuf-lite SHARED IMPORTED)
set_target_properties(libprotobuf-lite
PROPERTIES IMPORTED_LOCATION
${CMAKE_SOURCE_DIR}/src/main/jniLibs/${ANDROID_ABI}/libprotobuf-lite.so)
target_link_libraries(mycorelib
android
jnigraphics
${log-lib}
libprotobuf-lite)
Has anyone run into this problem before? Any hint on how to fix this would be greatly appreciated.
This is https://android.googlesource.com/platform/ndk/+/master/docs/user/common_problems.md#cannot-locate-symbols.
Your protobuf library was built for a higher minSdkVersion than the rest of your app, and cannot run on the device you're using.
You need to change the version of the NDK that you are using. The article below suggests that moving to NDK 22 or newer will fix this.
unable to run on Android 6.0 after 7b77c0acedf708749b68304cc5f0ac469c9d7136

How to disable Android NDK build for some build variant

I am using Android Studio 2.2 and have setup Gradle to build c/c++ sources with NDK via CMake.
Now I would like to disable NDK build for buildType "debug". For buildType "release" I would like to keep it.
The goal is to make NDK sources compile on the build server (using "release") but disable it for developers (using "debug").
This is the build.gradle file currently in use:
android {
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
defaultConfig {
externalNativeBuild {
cmake {
arguments "-DANDROID_TOOLCHAIN=clang"
cppFlags "-std=c++14"
}
}
ndk {
abiFilters 'armeabi-v7a', 'x86'
}
}
buildTypes {
release {
externalNativeBuild {
cmake {
arguments "-DANDROID_TOOLCHAIN=clang"
cppFlags "-std=c++14"
}
}
ndk {
abiFilters 'armeabi-v7a'
}
}
}
}
How can I disable NDK build (externalNativeBuild) for defaultConfig or buildType "debug"?
Other developers won't have NDK installed (local.properties without ndk.dir=PATH_TO_NDK). Is this possible to configure?
Thanks in advance
Edit:
This externalNativeBuild must be configured with a 'com.android.library'-module, not a 'com.android.application'-module.
Here is how I solved it.
This way Gradle build works for developers with and without NDK installed (and on the build server), which was the goal.
/*
* As soon as Gradle is linked to the externalNativeBuild (cmake / ndkBuild) with a path to
* CMakeLists.txt / Android.mk, the ndk.dir from local.properties file or the ANDROID_NDK_HOME
* environment variable needs to be set, otherwise gradle fails.
* E.g.:
externalNativeBuild {
cmake {
path "CMakeLists.txt"
}
}
*/
// Only enable externalNativeBuild on machines with NDK installed -> valid ndkDir
def ndkDir = project.android.ndkDirectory;
if (ndkDir != null && !ndkDir.toString().isEmpty()) {
externalNativeBuild.cmake.path = "CMakeLists.txt"
}
Regarding #1, if I understand correctly you want to do (or skip) certain things according to the buildType. If so, you can look at one of the many discussions on this subject, such as this one: get current buildType.
Regarding #2, it is not very clear what you want. If you are seeking an alternative to setting the NDK path in local.properties, you can set it via ANDROID_NDK_HOME environment variable. If you want to prevent gradle from failing, check if the ndk.dir exists in the relevant places of your build.gradle script (using properties.getProperty('ndk.dir')).

OCCI app crashes when running in debug mode in Visual Studio 2005

I'm attempting to get a development environment up and running for developing applications with Oracle C++ Call Interface (OCCI) in Visual Studio 2005.
My system specs are:
OS: Windows 7, 64-bit
Oracle: 11g release 11.2.0.2, 32-bit
Instant Client: BasicLite and SDK version 11.2.0.4 32-bit
Visual Studio 2005 Professional Edition version 8.0 with 32-bit tools enabled
I've followed this guide by Mark Williams and I got the example running but only in release mode. When I switch to debug mode the app will build, but when I run it I get the following error:
Problem signature:
Problem Event Name: APPCRASH
Application Name: OCCITest.exe
Application Version: 0.0.0.0
Application Timestamp: 53f5dfdd
Fault Module Name: KERNELBASE.dll
Fault Module Version: 6.1.7601.18229
The small example program that triggers this error is:
#include "employees.h"
using namespace std;
using namespace oracle::occi;
int main (void)
{
Employees *pEmployees = new Employees();
delete pEmployees;
return 0;
}
Employees::Employees()
{
user = "hr";
passwd = "hr";
db = "localhost:1521/service_name";
env = Environment::createEnvironment(Environment::DEFAULT);
try
{
con = env->createConnection(user, passwd, db);
}
catch (SQLException& ex)
{
cout << ex.getMessage();
exit(EXIT_FAILURE);
}
}
Employees::~Employees()
{
env->terminateConnection (con);
Environment::terminateEnvironment (env);
}
If I remove all calls to OCCI functionality the application doesn’t crash. That is, this program runs error-free:
#include "employees.h"
using namespace std;
using namespace oracle::occi;
int main (void)
{
Employees *pEmployees = new Employees();
delete pEmployees;
return 0;
}
Employees::Employees()
{
user = "hr";
passwd = "hr";
db = "localhost:1521/service_name";
cout<<"Look at me, I'm running"<<endl;
}
Employees::~Employees()
{}
In the guide Mark mentions that when running in debug mode, the linker should use the library file oraocci11d.lib. However, this file is not included in the Instant Client SDK version 11.2.0.4, so I’m using the input file oraocci11.lib for both the release and debug version.
I'm running out of ideas about how to proceed in solving this problem, and I would greatly appreciate any and all help.
If the Oracle DLL receives and/or passes objects such as std::string or any other object that either:
Manipulates the heap in any way, or
The objects could have differing internals between app and DLL,
then you have no choice but to use the correct library to link with. Otherwise you wind up with binary or heap incompatible objects being passed, which leads to what you're seeing now.
See here: http://docs.oracle.com/cd/E11882_01/appdev.112/e10764/install.htm#CBHGBBJI
The link above mentions both the debug import library and debug version of the DLL. Also this is stated at the link:
Applications that link to MSVCRTD.DLL, a debug version of Microsoft C-Runtime, /MDd compiler flag, should link with these specific OCCI libraries: oraocci11d.lib and oraocci11d.dll.
Since it took me quite some time to get the debug environment working I figured I'd answer my own question now that I did.
I got a variety of errors throughout the ordeal, but the error that I got most stuck on was an error saying:
'The application was unable to start correctly (0xc0150002).
Click OK to close the application.'
Also, I used http://www.dependencywalker.com which repeatedly told me that either oraocci11d.dll or a the following list of dll's could not be found.
API-MS-WIN-APPMODEL-RUNTIME-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-1.DLL
DCOMP.DLL
IESHIMS.DLL
However, what was really missing was for the executable to be able to find oci.dll. I'm just mentioning the errors in case someone else runs into these.
Here is what was needed to make it work:
First of all, the Instant Client does not contain the oraocci11d.lib or oraocci11d.dll, so it is necessary to install the full Oracle Client.
Next, the following must be added to the PATH:
C:\Program Files\Oracle\11.2.0\OCI\lib\MSVC\vc8
C:\Program Files\Oracle\11.2.0\BIN
In Visual Studio, select Tools -> Options, unfold 'Projects and Solutions' and select VC++ Directories. In 'Show directories for' under:
Include Files add C:\Program Files\Oracle\11.2.0\OCI\include
Library files add C:\Program Files\Oracle\11.2.0\OCI\lib\MSVC\vc8
In the property page for your project under Configuration Properties -> Linker select Input and under Additional Dependencies add oraocci11d.lib (or oraocci11.lib for release mode). Then select debug/release mode in the Configuration Manager
I have a related problem in that I am successfully using oraocci12d.dll/msvcr100d.dll, but this in turn is using oci.dll/msvcr100.dll. ie, oci.dll is not using the debug version of msvcr100.
My program seems to run okay, but any memory leak reporting disappears on exit.