I would like to know how I can debug an Android app by using lldb.
I mean using lldb from console not over Android Studio.
From what I found out, Android Studio is doing this:
Pushing the app to the device
Starting this app
Pushing lldb-server to the device
Starting lldb-server on the remote device
Forwarding the ports
Connecting to the local port which is forwarded to the device
I would like to achieve the same using lldb from the console.
Let's say I have already lldb-server on the remote device (because Android Studio did this already for me), what do I need to do is to connect to an App using lldb from the console?
Never tried, but maybe this could help:
LLDB remote debugging
Debugging C++ native libraries in Android using command line
Additionally:
ensure that APK's native libraries (lib*.so) are having debug info/symbols. I pull the apk locally, locate .so file, and check the output of binutils nm utility. When you get familiar with your .so files only checking the size of the .so file could be enough.
one can debug by attaching to a running process/application (attach) and in some cases you need to debug application on application start (run).
in some debugging cases phone/emulator requires root access (file manipulations)
if you manage to debug C++ libs within Android Studio - check Debug+Console and Debug+LLDB output tabs to find interesting commands/options/steps
the procedure looks quite complicated and fragile - arm yourself with patience, don't ignore warnings and don't skip steps.
Related
I am developing a fully native application in using C++ and pure CMake as the build system - no Android Studio involved at all (proof of concept here)
The code builds, apk is generated and can be installed and run via ADB without issue but I cannot get gdbserver64 to attach to the process for debugging.
More details:
App is built against SDK/NDK API level 30
Attempting to debug on an Android 11 emulator instance without Google Play
I can run adb root just fine
Image already includes gdbserver and gdbserver64, attempting to use those
Developer options and USB debugging enebled in emulator
App has android:debuggable="true" in manifest
But every time I try gdbserver64 :5039 --attach $(pidof my.app.id)
I get /bin/sh: <app_pid>: inaccessible or not found
What am I missing? And no, I cannot just move to Android Studio - this is a cross platform project that needs to be buildable using only CMake.
According to my observation, this may be a bug of prebuilt gdbserver. It treats the parameter after --attach as a program name and tries to start it.
It's not really an answer, but in similar configuration to yours I got same error message and unable to overcome this. For me, switching to lldb helped, see e.g.
I am new to javaFx and gluon mobile. In android studio there is the option to debug code whilst it is running on the phone and I was wondering if there is a similar feature for working with intelij and the gluon mobile plugin ? Under the gradle tasks there is a Debug task, which when clicked prints "Listening for transport dt_socket at address: 5005" to the console and waits. Unfortunately there is not a lot of documentation/examples regarding this that I could find. Any help is appreciated.
The Debug task is for desktop only.
It is intended to debug easily on your machine before deploying to mobile, but obviously it will allow tracking down only common issues, and that won't guarantee that the app will work on Android. I.e. using Streams will run on desktop and it will fail on Android.
To debug the app running on Android, the best way is using adb from your Android SDK folder, in the platform-tools folder.
Connect your app to the USB and run it. On a terminal go to that folder and run:
adb logcat -v threadtime
and search through all the messages trying to find out those related to the FXActivity.
You can add print outs in your code so you can easily track them in the logs.
There are other tools like the Android monitor (under Android sdk/tools folder), that will let you add some filters so you can easily go through the app messages.
First make sure you have enabled the Debugging Mode on your phone.
Then in Eclipse e.g., you can create a Debug Configuration of type Remote Java Application which will be attached to the corresponding socket:
You can get the port from the devices view:
Now you have to start your app first, and then start the Debug Configuration
I create a big JavaFX application that works fine in desktop.
In Android, its size is about 20 Mbytes.
Now, for deploying it for Android, I have installed Gluon (JavaFxPorts).
With a small program (using the JavaFX transitions notions, timeline, ...), I have generated an .apk by calling the androidInstall gradle task. That works fine, except I cannot automatically install the .apk file in my phone. I do copy/paste from my desktop to my phone.
BUT, when I want to do the same process with my big application, at the end, my phone screen is already black.
Therefeore, even if this big application works fine on my desktop, it is necessary to debug it for Android on my desktop, too. But, I don't know how to?
What to do with apkDebug gradle task, ..?
gluon+gradle does not provide a kind of Android emulator that allows to finalize the debug on desktop for a smartphone with its specific features (size of screen, landscape orientation). Do you agree?
What is the additional tool that allows to do that?
Moreover,when the application is deployed in the smartphone, does it exist a tool that allows to finalize the debug on smartphone?
Thant you for your response
Note: I have installed Android SDK manager and its AVDM in Eclipse, but with the JavaFX use, it is impossible to use it, isn't it?
Debugging JavaFX projects on Android so far doesn't work on Android emulators.
Command Line
The usual approach is just log messages to the console (i.e. System.out.println() or Log.v()...), and then using adb logcat.
On command line, go to your Android sdk folder, enter into the platform-tools folder and run adb logcat -v threadtime. That will give you all the log messages from your device, so you'll need to find your FXActivity pid there and filter through it.
Another possibility is using Android's monitor under the tools folder, a GUI tool that will allow filtering the console messages.
Eclipse
There is an ADT plugin for Eclipse, that can be installed following this question. This will allow you displaying logCat and device windows among others. Basically this will offer the same options as the monitor tool.
However, this doesn't seem to work with recent versions of logcat.
Android Studio
You can import your gradle project with Android Studio and enable the Android framework, so you can open the Android Monitor, and easily filter the logcat messages, or switch to the monitor tab with live charts of memory, cpu, ...
Black screen
Typically a black screen means you have some exception going on, so you need to use any of the above mentioned logging methods to track it down, solve it and try again.
I'm interested in learning about the Android runtime (ART) and I'd like to be able to put a debugger on it so I can step through the code. I have an AOSP build that I've been running on an emulator.
What's the best way to attach and run source? Should I just use gdbserver on the emulator? Are there any IDEs that people use for native debugging?
Looks like you figured this out, but just for completeness, here's a link to some official documentation which basically covers what you said: http://source.android.com/devices/tech/debug/index.html
If you want to debug native code, you're going to need the source, which of course means getting the AOSP. After you've setup the AOSP, do the following:
In your AOSP directory, run "choosecombo". Select "debug" and pick an "eng" build of your choice.
Build the AOSP
Start the emulator (ie: on Linux, "emulator &")
adb shell into the emulator and run "setprop debug.db.uid 32767". This prevents debuggerd from attaching to a process that it thinks has halted and causing problems. See system/core/debuggerd/debuggerd.cpp in the AOSP for more info.
In the same shell that you built the AOSP, run "gdbclient [process name]". This will attach and load the debugging information for the process you are interested in. You can also attach to a pid, but you will end up having to load the symbol information yourself.
Enjoy debugging native Android platform code
I'm using the NDK to compile libusb (both from the prebuilt one supplied at: https://github.com/monaka/libusb-android) as well as using his changes to compile the latest available (libusb-1.0.8). It appears to load and the initial call to "init()" does not return an error. However, when I try to make the basic call into the library to list devices (from the sample lsusb code included in libusb) I get a crash. Using the NDK-provided "arm-eabi-addr2line" and the address which the dump provides as the fault, I've tracked it down to being that the device listing method in libusb gets an "unknown status" from the device it finds which causes the "usbi_log()" method to be called within which the crash occurs. The NDK tools don't give me line numbers so that's all the details I have for where the error is occurring.
libusb source repo: http://git.libusb.org/?p=libusb.git;a=summary;js=1
I am making a simple JNI call into libusb from a dead-simple Action, though I don't have any reason to think this is part of the issue. It is a very basic .h (from javah) file and .c file which copies the action of the provided "lsubs" sample program and the Action class does nothing but make the call in the onLoad() method.
I also get a crash when running in the emulator. Also unplugged device (a Nexus One) to disable debugging (also disabled in Applications->Development on device) and to have USB bus (theoretically) empty (of at least external physical devices) and get same crash.
Device and emulator Android version: 2.2
NDK version: r5b
ADK version: r10
Host OS: OSX
Thank you for any help you can provide!
If you install an ssh daemon on the phone, then you can ssh into it with port forwarding and run gdbserver and connect to that from gdb on the pc.
You may want to build a command line executable test first, before hooking it up to your java app.