I try to debug a very basic example Qt 5.3 Android native C++ project, and I would like to debug it on the target without using QtCreator or any other IDE like Eclipse but only NDK tools.
This project is compiled through QtCreator tools using Android platform target, in debug mode (-O0, -g), using NDK toolchain, BUT NOT ndk-build.
Therefore I got my .apk, the application itself has been installed on the target and works, everything is fine up to that point. Now I want to execute it in debug mode using NDK tools.
I would like to use ndk-gdb as this seems to be one of the most obvious ways, therefore:
- I created manually required files under my main project directory:
bin
src
res
...
jni
|-- Android.mk
`-- Application.mk
libs
|-- armeabi-v7a
| |-- gdbserver
| |-- gdb.setup
The tree above only underline the files I added by hand, given that they are normally created by ndk-gdb.
Under the 'libs' directory is also stored the native library of the project, called by a simple java wrapper.
jni/Android.mk and jni/Application.mk contains the same single line:
APP_ABI := armeabi-v7a
gdb.setup:
set solib-search-path ./libs/armeabi-v7a
directory <myrootdir>/NDKToolchain/sysroot/usr/include <myrootdir>/NDKToolchain/include/c++/4.6 <myrootdir>/NDKToolchain/include/c++/4.6/arm-linux-androideabi/armv7-a [...]
I checked that the target was connected and accessible by installing the application using adb:
% adb install -r bin/QtApp-debug.apk
It worked ('success'), which I could check directly on the target.
Then when I try to run ndk-gdb, it failed:
% ndk-gdb --start --nowait --verbose
WARNING: The shell running this script isn't bash. Although we try to avoid bashism in scripts, things can happen.
ndk-gdb: 84: Bad substitution
Android NDK installation path: [...]
Using default adb command: [...]/sdk/platform-tools//adb
ADB version found: Android Debug Bridge version 1.0.31
Using ADB flags:
Using JDB command:
Using auto-detected project path: .
Found package name: org.qtproject.example.fridgemagnets
ABIs targetted by application: armeabi-v7a
Device API Level: 18
Device CPU ABIs: armeabi-v7a armeabi
[: 564: 1: unexpected operator
Compatible device ABI: armeabi-v7a
Using gdb setup init: ./libs/armeabi-v7a/gdb.setup
Using toolchain prefix: [...]/ndk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-
Using app out directory: ./libs/armeabi-v7a
Found debuggable flag: false
Found gdb.setup under libs/armeabi-v7a, assuming app was built with NDK_DEBUG=1
ERROR: Could not extract package's data directory. Are you sure that
your installed application is debuggable?
A previous run of ndk-gdb showed me that for some reason it wanted to use ./obj/local/armeabi-v7a as "app out directory", while I set it in gdb.set to ./libs/armeabi-v7a, therefore I had to hack the ndk-gdb script to force it to use the path I chosed. I don't believe this is related to my real issue (?)
Given that I didn't use ndk-build, I believe that my attempt to use ndk-gdb is hopeless, or at least that it will ask me too much work and hacking of NDK scripts which I don't want to do.
Thus 2 questions:
Did I miss something during my build or deployment for getting a
debuggable app ? I know that debuggable flag in Manifest being
'false' is not necessarily an issue, as I built my app with debug
flags. BTW this seems to be confirmed by the fact that the error
message I get is not related to that flag but to the fact that the
script seems to exepect a DATA_DIR folder somewhere...
Is there a
way to debug my application, without using ndk-gdb (and any IDE),
but for example just 'gdb' ?
Thanks in advance
Question 1:
I know that as of SDK r8 you can invoke ant with release or debug. Building with the debug flag might package or run your application differently. Thus allowing or disallowing debugging? This seems like it might be the issue.
Question 2:
From what I understand ndk-gdb does a lot of setup and communication with adb to allow debugging your application, as you may have seen from the script. I wouldn't suggest going down the rabbit hole of not using it.
Related
I spend hours struggling on this issue and I feel dumb as f***. I followed this doc, installed everything I needed until the effective building step:
p4a apk --debug --private $HOME/Documents/Code/Python/app_kivy/identifier/main.py --package=org.example.myapp --name "My application" --version 0.1 --bootstrap=sdl2 --requirements=python2,kivy
[INFO]: Will compile for the following archs: armeabi
[INFO]: Found Android API target in $ANDROIDAPI
[ERROR]: Could not find `android` or `sdkmanager` binaries in Android SDK. Exiting.
Here is the end of my .bashrc
# Adjust the paths!
export ANDROIDSDK="$HOME/Android/Sdk/"
export ANDROIDNDK="$HOME/Apps/android-ndk-r16b/"
export ANDROIDAPI="19" # Minimum API version your application require
export ANDROIDNDKVER="r16b" # Version of the NDK you installed
I tried several paths variants, tried both the full Android Studio and the ‘just the command line tools’ methods of the doc, nothing. NB android and sdkmanager are installed in different folders (resp. tools and tools/bin). I am pretty sure that I am missing something in the .bashrc but what am I missing?
Thanks in advance for any insight
This p4a error message is less specific than it implies. $ANDROIDSDK need not even be a valid path to produce this error. That in mind, you should first check that it has even been exported properly by running the command echo $ANDROIDSDK. If you don't see the expected path printed out, you'll need to run your .bashrc script again the way you normally would.
If you do see the expected path, then the most likely problem is that the contents of $HOME/Android/Sdk/ aren't what p4a was expecting. For that I unfortunately can't offer a suggestion of what might be wrong without knowing what the contents are.
I want to build, install and run the tests of a UiAutomator project through the command line.
In the previous version I was doing:
android create uitest-project -n <project_name> -p <project_path> -t <target_id>
ant build
to build
and then
adb push <jar_path> /data/local/tmp
to install and finally
adb shell uiautomator runtest <jar_name> -c <main_class>
However, right now I'm stuck in the building part.
The result is
-check-env:
[checkenv] Android SDK Tools Revision 24.1.2
[checkenv] Installed at C:\Android
-build-setup:
[getbuildtools] Using latest Build Tools: 22.0.0
[echo] Resolving Build Target for AndroidExplorerTester...
[getuitarget] Project Target: Android 5.0.1
[getuitarget] API level: 21
[echo] ----------
[echo] Creating output directories if needed...
-pre-compile:
compile:
-post-compile:
-dex:
[dex] input: <test_path>\bin\classes
[dex] Converting compiled files and external libraries into <test_path>\bin\classes.dex...
[dx] no classfiles specified
BUILD FAILED
C:\Android\tools\ant\uibuild.xml:198: null returned: 1
Total time: 1 second
I don't know if there is a better way to do it now since the new version of UiAutomator.
Note: I don't know if it matters but I was using Eclipse before and now I'm using IntelliJ (Android Studio if you prefer lol)
Here is one more way for those, who don't want to move to gradle and wish to stay with ant. Btw, main reason, why old way doesn't work, is moving of uiautomator starting from its 2.0 version from standalone test runner for jars to standard android 'am instrument' test runner for apps. This move has only one 'contra'. Now test projects should be bound to a definite target app (see workaround in the first step). So here is a plan.
First of all, you should have a target project, for which your test is designed. In fact it can be an empty app, which will not be shown at all, neither in apps menu, nor during testing. I've managed to create one in Eclipse, without creating any activity in wizard. To make ant's build.xml run:
android update project --target 0 --path %path_to_empty_app%
For more information about android tool see http: //developer. android. com/ tools/ projects/ projects-cmdline .html
Note: you may want to give necessary permissions to your target app, which will be spread to test app. Now test is not run with shell user permissions.
Second step is creating a test project. As I've mentioned, uiautomator is now integrated in standard android testing scheme. Thus, it uses a standard command for creating test apps:
android create test-project -m %path_to_target_app% -n %test_app_name% -p %path_to_test_app%
A usual app structure will be created in %path_to_test_app%, including ant's build.xml
For more information see http://developer.android.com/tools/testing/testing_otheride.html
Third: copy uiautomator classes jar to test app libs. The jar can be extracted from *.aar archive situated in SDK in \extras\android\m2repository\com\android\support\test\uiautomator\uiautomator-v18\2.1.0 or similar.
Fourth: put your test class *.java to test app src folder. Note the following changes in uiautomator here:
package is renamed from com.android.uiautomator to
android.support.test.uiautomator
UiAutomatorTestCase class is
left for compatibility, but is deprecated; extend your test class
from InstrumentationTestCase, to get UiDevice instance, use
UiDevice.getInstance(getInstrumentation())
Fifth: install and run your test. Simple way is the following:
cd %path_to_test_app%
:: Here 'ant instrument install' builds and installs both target and test apps.
ant instrument install
ant test
or the last line can be modified to
adb shell am instrument -w %target_app_full_name%.tests/android.test.InstrumentationTestRunner
For more information see http://developer.android.com/reference/android/test/InstrumentationTestRunner.html
Well I finally figured it out.
From the command line, in the main folder of the project (where you can find gradlew.bat file) run the following commands
build:
.\gradlew.bat assembleDebug
install on device:
.\gradlew.bat installDebug
(if you want Release version just replace Debug for Release, I didn't try it but the options exist and so I suppose they work)
run:
.\gradlew.bat connectedCheck
If you want to know other options you may have run
.\gradlew.bat tasks
Extra information
To do it programmatically (Java) use Runtime.getRuntime().exec(String command, String[] envp, File dir). For instance,
Runtime.getRuntime().exec(shell_command + " <path_to_test_folder>\gradlew.bat assembleDebug", null, new File(<path_to_test_project>));
Where shell_command depends on the operating system (the command for the command line):
- Windows: cmd /C
- Unix-based: /bin/sh -c
I tried to make a standalone Android NDK toolchain on Linux 64 bit:
~/build/android-ndk-r9/build/tools $ ./make-standalone-toolchain.sh --platform=android-14 --ndk-dir=/home/user/build/android-ndk-r9 --system=linux-x86_64 --install-dir=/home/user/build/android-14-toolchain
Auto-config: --toolchain=arm-linux-androideabi-4.6
Copying prebuilt binaries...
No files are actually copied. Something goes wrong. The NDK ist the latest release r9.
How can I run the script so that the files get copied to the installation directory?
A suggestion: Use the --verbose option if you haven't already done so; it will tell you in which stage the error occurs.
Here are the options I ran to make a standalone toolchain targeting android-14 and arm-linux-androideabi-4.7
sudo sh make-standalone-toolchain.sh --verbose --toolchain=x86-4.7\
--install-dir=/project/arm-cc --ndk-dir=/project/android/ndk/android-ndk-r9\
--platform=android-14
similar questions have been asked:
How to run NDK samples?
Making Android NDK apps with NativeActivity?
I've got the command-line documentation down to the point where I can create an empty Android project, I do not know how to build-install-run the NDK examples, particularly the NativeActivity one, in a non-Eclipse build environment (Ubuntu 10.0.04).
So my questions are
does the NativeActivity example "just work" or do you have to do something besides just $adb -d shell "am start -a android.intent.action.MAIN -n com.example.nativeActivity"?
How do you build, install, run the NativeActivity example?
I can't answer about this specific example. But here's the general process for building and installing an Android application which uses the NDK.
cd to the root of its source code.
Run ndk-build. This builds the native code, and should result in some .so files being put into the libs directory.
android update project --path . --name something
ant debug (or similar). This will build the Java code and create an .apk. Crucially, the build process will pick up the .so files left within the libs directory and include them into the .apk.
adb install bin/name-of-project.apk
Then launch as normal using the Android GUI or using an am start command such as you give.
I just installed Android NDK, r5b, and while trying to follow the steps from Exploring the hello-jni Sample, on the command line I receive the error:
MacBook-2:~ mvermant$ cd ndk/samples/hello-jni
MacBook-2:hello-jni mvermant$ android update project -p . -s
-bash: android: command not found
I'm using Eclipse Helios release 2 with Android SDK r10 and ADT 10.0.0 on MAC 10.6.6. I have also checked to have GNU Make 3.81, and installed GNU Awk(though I am not sure it's in the right place).
I've searched a lot, and seems there might be a class path missing somewhere, but I can't figure out where exactly and what to do to fix it.
You should make sure the tools directory of your android-sdk is on your (shell) path.
Something like:
export PATH="/path/to/sdk/tools:$PATH"
before you execute your command.
In general you will also need two other directories to be on your path:
/path/to/sdk/platform-tools - for adb and other android sdk tools
/path/to/ndk - for ndk-build and ndk-gdb, which are ndk tools
You can also do some setup so that you don't have to run these commands every time you open Terminal.