I am trying to understand the working details of the Package Manager API on Android. I'm using Android Studio to debug it. I have built the AOSP code and am running it on an emulator. Android Studio provides a way to attach to Android processes; however, I am not sure which process to connect to to debug the PackageManager. I assumed the name of the process would be com.android.packageinstaller, but it never shows up on the list of debuggable processes, even when I try to install an apk on the side via adb although my print lines in the AOSP code seems to show up (which means the process is running). Could somebody please explain me how I should be going about debugging the Package Manager? Which process should I be connecting to?
Thanks very much!
Try connecting to the system_process. Most of the core services that compose Android all run in that process.
The Package Manager as well as many other critical services are built off of frameworks/base/services/ (see: http://androidxref.com/6.0.1_r10/xref/frameworks/base/services/) into a services.jar artifact which is a library (http://androidxref.com/6.0.1_r10/xref/frameworks/base/services/Android.mk#7) and not an app.
The "app" that runs this code happens to be a custom instantiation of the core Dalvik virtual machine that you'll find in Zygote.java (the "Main" class for the Dalvik VM). See here: http://androidxref.com/6.0.1_r10/xref/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java#514.
When the Zygote process (the root process of all Android Java processes) is started it is named app_process but when started for running the core system services, then it is run with a special command line argument that causes it to call itself system_server.
So if you want to debug the Package Manager code, best is to attach to that process. You might also consider sprinkling log statements into the package manager code in the framework and looking at those as well or instead.
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 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.
I'm trying to restart the mediadrmserver on the Android Emulator by modifying "/etc/init/mediadrmserver.rc" and then restarting the mediadrm service. However, I notice mediadrm restarts just fine even when there is an error in mediadrmserver.rc.
This brings me to my question: How are services started on Android? How do I launch a service with a custom command?
What I would finally like to achieve is to run valgrind on mediadrmserver using the steps given in Using Valgrind.
The mediadrm service does indeed start the mediadrmserver process using "/etc/init/mediadrmserver.rc". The problem I was running into was that the mediadrm service wasn't recognizing the changes I had made to the ".rc" file during relaunch. Modifying the ".rc" file and then restarting the emulator fixed the problem for me.
As for what I was trying to achieve, I ran mediadrmserver through valgrind, using the steps given here (also applies to any service/process), and I compiled valgrind for the Android emulator, using the steps given in Valgrind's README.android.
However, I couldn't get it to work (valgrind crashes with SIGSEV) because it looks like valgrind only works on emulators running Android versions up to ICS (4.0.3). Furthermore, Google plans to remove Valgrind from the platform in a future release and recommends using Address Sanitizer instead.
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'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