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 have a cross-platform app that starts and runs fine in the IDE debug mode.
However, if the app, in a debug compilation, is started from either iOS or Android starts and subsequently fails; it runs fine on UWP though. I have had the app run on them in earlier versions.
What settings/logs on those OS's should I set to try and debug the executables?
Is there any documentation for working this type of problem?
Per this conversation, John suggested "application level unhandled exception handers on each platform" which I researched, found example code here and use it to form my own code to resolve the issue I was having.
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.
I am using Android Studio to develop my apps.
Since I upgraded my HTC One M8 to Lollipop, I can not use it to test my apps by "Run app" in Android Studio.
I get this error and nothing happens on my phone:
Launching application: com.project.GalleryActivity.
DEVICE SHELL COMMAND: am start -n "com.project.GalleryActivity" -a android.intent.action.MAIN -c android.intent.category.LAUNCHER
java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String android.os.SystemProperties.native_get(java.lang.String) (tried Java_android_os_SystemProperties_native_1get and Java_android_os_SystemProperties_native_1get__Ljava_lang_String_2)
at android.os.SystemProperties.native_get(Native Method)
at android.os.SystemProperties.get(SystemProperties.java)
at com.htc.customization.HtcCustomizationManager.<init>(HtcCustomizationManager.java)
at com.htc.customization.HtcCustomizationManager.<clinit>(HtcCustomizationManager.java)
at android.os.Environment$UserEnvironment.getCustomizationReader(Environment.java)
at android.os.Environment$UserEnvironment.isDynamicSwitchSupported(Environment.java)
at android.os.Environment$UserEnvironment.<init>(Environment.java)
at android.os.Environment.initForCurrentUser(Environment.java)
at android.os.Environment.<clinit>(Environment.java)
at android.os.Environment.getLegacyExternalStorageDirectory(Environment.java)
at android.os.Debug.<clinit>(Debug.java)
at android.ddm.DdmHandleHello.handleHELO(DdmHandleHello.java)
at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java)
at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java)
java.lang.UnsatisfiedLinkError: android.os.Debug
at android.ddm.DdmHandleHello.handleFEAT(DdmHandleHello.java)
at android.ddm.DdmHandleHello.handleChunk(DdmHandleHello.java)
at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java)
java.lang.UnsatisfiedLinkError: android.os.Debug
at android.ddm.DdmHandleProfiling.handleMPRQ(DdmHandleProfiling.java)
at android.ddm.DdmHandleProfiling.handleChunk(DdmHandleProfiling.java)
at org.apache.harmony.dalvik.ddmc.DdmServer.dispatch(DdmServer.java)
Aborted
My project's settings are these:
This technique used to work perfectly before upgrading and I have not change anything since that time.
I was facing the same error on Asus Zenfone 5 (ASUS_T00J) with Android 5.0. For me the solution was to switch off the "Verify Apps over USB" in the "Developer Options".
Launcher may not be the issue since I tried with Google Now Launcher as well without success. It was working fine on my Nexus 5 with Android 5.1
Workaround: disable ADB integration in Android Studio.
Tools > Android > uncheck Enable ADB integration
I'm not sure what the underlying cause is, but I found I could successfully avoid this issue by closing down all running apps on the phone before trying to Run my code on my M8.
Do you use any third-party launcher on device? I have same issue when use Aviate launcher. I switch back to BlinkFeed in Personalize->Main Screen settings and my deploy to device is stable now.
Classpath com.htc.customization.HtcCustomizationManager make me thing than this issue related to launcher.
I met the same problem on ASUS ME176C(Lollipop 5.0),
but I resolved it by setting "Select debug app" to "No". Then push apk as usual. After that, you can reselect "debug app" to target app.
I discovered a "workaround" to solve this problem
Find the HTC Blink Home Launcher and uninstall the update
(CAUTION:uninstall the launcher update will remove all icons and widgets placed on the launcher)
This works for me and it can be used debugging now without removing the apps in multitask.
This should be a bug caused by HTC?
(I am using HTC Butterfly 2 & Android 5.0.2)
I don't have the rep for commenting but i was in the same situation of #user47625 but my "Verify Apps over USB" was already off. I've tried to enlarge a bit this answer with some reasoning.
At first I've tried to change the launcher and I got some luck but was hit and miss, not a proper solution. Rebooting the phone granted a couple of hours of calm work.
Then i've found someone on google that stated:
If it is that bug: The DDMS client connects with a "Hello" when the PM process first starts and registers itself, but before it has fully initialized all the native code. It is a race in stock Android and occurs there too
So if this race occurs it doesn't occurs everytime, but every now and then, I suspect something regarding interaction of item on Android. I don't know if it's CPU, RAM or App related, but on my Zenfone 2 closing all background apps (1) and releasing the memory (2) does the trick, letting me able to debug the app properly.
I used Clean Master cause is stock with Zenfone 2, but i suspect every memory manager can do that. Give it a try
On my HTC M8, I resolved the issue by disabling "Settings -> Developer options -> Use NuPlayer(experimental)"
What I have noticed is, when I try to run the application I created long back (few years ago), I have to disable the NuPlayer. However, with new applications, I must keep the option checked.
Hope this helps....
On an Asus ZenPad, 5.0.2 I was able to solve the issue by going into Asus' Auto-start Manager (Settings -> Power management -> Auto-start Manager) and allowing my app to auto-start.
I've had a reasonable amount of success with the workaround below.
After each debugging session with your app, go to the Android Studio terminal:
> adb shell am force-stop com.your.app.package
I still occasionally get the java.lang.UnsatisfiedLinkError but only following the above command rather than in between the build/push apk/install process and attempting a debugging session.
To me, this saves a lot of wasted time building only to get the error. If the command above doesn't work, just up-arrow and re-run the command until it works without an error.
This solution worked for me, you may give it a try.
Add adb path to System Environment Variables (I'm using windows 8)
Ex: my path is "C:\Users\xxx\AppData\Local\Android\sdk\platform-tools"
Dont forget to reboot your system to take the effect!
About how to set the path and environment variables in Windows >> here
how can we solve this types of the error -> "This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz."
This is a problem with Mac OSX and the Eclipse Android emulators. There is nothing wrong with your code. It seems to happen at it's own whim. I find that starting the emulator on its own (Window>Android SDK and AVD Manager, select the emulator and click Start...) and then running the build once the emulator is online seems to eliminate it, but this could be pure superstition. Nonetheless, it will work on your Mac if she is in the right mood.
http://groups.google.com/group/android-developers/browse_thread/thread/f10995f2a829229d
This is a probleme with osx Emulator.
You can ignore this warning but to test your app you must:
1-launch your emulator by running your app (you will have warning message)
2- wait for emulator to start completly
3
. Since emulator and wait for it to start and then relaunch your app.