I can't figure out the problem. I look at logcat, and I see that the application starts onCreate, and then there is onDestroy and onResume again and it works. But due to the fact that there is onDestroy, the application does not work correctly. When it starts, there is a Bluetooth connection and onDestroy breaks the sequence of actions. Please help me figure out what the problem is. Thank you in advance.
12:28:32.533 AdrenoGLES-0 I Build Config : S P 10.0.7 AArch64
12:28:32.533 AdrenoGLES-0 I Driver Path : /vendor/lib64/egl/libGLESv2_adreno.so
12:28:32.544 AdrenoGLES-0 I PFP: 0x016ee190, ME: 0x00000000
12:28:32.566 hw-ProcessState D Binder ioctl to enable oneway spam detection failed: Invalid argument
12:28:32.639 MyLog D onPause
12:28:32.643 MyLog D onStop
12:28:32.646 MyLog D onDestroy
12:28:32.688 MyLog D onCreate
12:28:32.894 MyLog D onStart
12:28:32.899 MyLog D onResume
12:28:32.969 BluetoothSocket D close() this: android.bluetooth.BluetoothSocket#e23dd5e, channel: 1, mSocketIS: android.net.LocalSocketImpl$SocketInputStream#76c153f, mSocketOS: android.net.LocalSocketImpl$SocketOutputStream#5386e0cmSocket: android.net.LocalSocket#3d6b355 impl:android.net.LocalSocketImpl#5cc716a fd:java.io.FileDescriptor#496c65b, mSocketState: INIT
Related
I'm trying to build and deploy declarative-camera example on my android phone but I keep receiving this error and a white screen:
[SurfaceTexture-0-31406-1] bindTextureImage: clearing GL error: 0x502
Although when I touch the screen it appears for less than a second then turns to white screen again. I'm using Qt 5.14/ NDK Version 20/ SDK Version 26.1.1.
I use QuickWidget inside my .cpp file for displaying the .qml file by setSource(QUrl("qrc:/declarative-camera.qml")).
My current Kit is Android for armeabi-v7a,arm64-v8a,x86,x86_64 (Clang Qt 5.14.0 for Android). Same code used to compile successfully without any errors on the same phone with Qt 5.13 with Android for arm64-v8a (Clang Qt 5.13.1 for Android ARM64-v8a) Kit.
Any idea what is causing this behavior?
P.S This is my Application Output after I call setSource :
D ViewRootImpl#30773d6[QtActivity]: ViewPostIme pointer 1
D InputMethodManager: HSIFW - flag : 0 Pid : 15832
D InputMethodManager: HSIFW - flag : 0 Pid : 15832
D SensorManager: registerListener :: 1, K6DS3TR Acceleration Sensor,
200000, 0,
D SensorManager: unregisterListener ::
D Camera : app passed NULL surface
D Camera : app passed NULL surface
D SensorManager: registerListener :: 1, K6DS3TR Acceleration Sensor,
200000, 0,
W GLConsumer: [SurfaceTexture-0-15832-1] bindTextureImage: clearing GL
error: 0x502
W GLConsumer: [SurfaceTexture-0-15832-1] bindTextureImage: clearing GL
error: 0x502
It's a QT bug, although it's already fixed in 5.14.2 which is due in March.
https://bugreports.qt.io/browse/QTBUG-81006
In binder. c init function is defined but no exit function.
In init part misc_register() is called. The same should be deregistered in module exit by calling
Misc_deregister() function. Can anyone help me to understand why no module exit function for android binder driver?
Before I did any changes, I printed Log.isLoggable(MYAPP_TAG) for all levels.
I/System.out﹕ MYAPP Loggable Level: [V:false][D:false][I:true][W:true][E:true]
And then I did adb shell setprop log.tag.MYAPP_TAG WARN.
The Log.isLoggable(MYAPP_TAG) message now became
I/System.out﹕ MYAPP Loggable Level: [V:false][D:false][I:false][W:true][E:true]
However, all log messages (Log.v, Log.d, etc) can still be observed in Logcat.
02-03 13:18:28.050 3284-3284/com.XX V/MYAPP_TAG﹕ onServiceConnected
02-03 13:18:28.050 3284-3284/com.XX D/MYAPP_TAG﹕ onServiceConnected
Why is that?
I think you need to wrap your logs:
if (Log.isLoggable("MY_TAG", Log.VERBOSE)) {
Log.v("MY_TAG", "Here's a log message");
}
otherwise android seems to ignore your settings; it seems like the Log.v, Log.d, etc. are not checking against the LogLevel.
I'm trying to debug a mysterious crash of my Android application that seems to occur in the low memory conditions. The sources of the app in question are available from https://bitbucket.org/stativ/chmupocasi. The application's package is cz.jirkovsky.lukas.chmupocasi
What happens is that when the phone starts to run low on memory and I try to reopen the application from the list of recent apps (the one that shows after a long press of the Home button), the application crashes.
I've tried to debug the application using the Android Studio, but the application always crashes before hitting any of the breakpoints in the main Activity's onCreate() and onStart() making it impossible to debug. What is worse that even the logcat doesn't contain any information, the only related line shown when the app crashes is:
I/ActivityManager( 428): Displayed cz.jirkovsky.lukas.chmupocasi/.MainActivity: +1s45ms (total +23m23s835ms)
The full logcat is available at http://pastebin.com/TtSuqxCW, in case I'm missing something.
Finally, I've tried attaching the debugger to the application after it crashes, when the Android's dialog "Unfortunately the application has stopped" is shown. I don't see any of my code being run in any thread. Here is what the "Export Threads" contain:
<1> main#830017304224, prio=5, in group 'main', status: 'RUNNING'
at android.os.BinderProxy.transact(Binder.java:-1)
at android.app.ActivityManagerProxy.handleApplicationCrash(ActivityManagerNative.java:3147)
at com.android.internal.os.RuntimeInit$UncaughtHandler.uncaughtException(RuntimeInit.java:76)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
at dalvik.system.NativeStart.main(NativeStart.java:-1)
<10> Binder_2#830026133152, prio=5, in group 'main', status: 'RUNNING'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<9> Binder_1#830026131496, prio=5, in group 'main', status: 'RUNNING'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<8> FinalizerWatchdogDaemon#830026116408 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:364)
at java.lang.Daemons$FinalizerWatchdogDaemon.run(Daemons.java:214)
at java.lang.Thread.run(Thread.java:856)
<7> FinalizerDaemon#830026115976 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:401)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:102)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:73)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:169)
at java.lang.Thread.run(Thread.java:856)
<6> ReferenceQueueDaemon#830026115560 daemon, prio=5, in group 'system', status: 'WAIT'
at java.lang.Object.wait(Object.java:-1)
at java.lang.Object.wait(Object.java:364)
at java.lang.Daemons$ReferenceQueueDaemon.run(Daemons.java:129)
at java.lang.Thread.run(Thread.java:856)
<5> Compiler#830026115320 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<3> Signal Catcher#830026114840 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
<2> GC#830026114616 daemon, prio=5, in group 'system', status: 'WAIT'
at dalvik.system.NativeStart.run(NativeStart.java:-1)
If I try to examine the main thread, I can see that there is an unhandled exception somewhere in the ThreadGroup:
No such instance field: 'nthreads'
Any ideas how to debug such crash or how to get more information about it?
I've finally found a solution. It was actually two separate problems.
The first one was that my device (Huawei Y300) didn't log any stack trace that could be retrieved using logcat. This was likely resolved by a reboot that i did earlier today, or, less likely, by the fact that I tried to use logging via android.util.Log to log some debug info.
The second one was the crash itself. After getting the stack trace from the crash, the problem was quite easy to fix. Even though the previous information I obtained using debugger pointed to some problem with threads, the real cause was the following exception:
android.app.Fragment$InstantiationException: Unable to instantiate fragment cz.jirkovsky.lukas.chmupocasi.RetainFragment: make sure class name exists, is public, and has an empty constructor that is public
The true cause was that the RetainFragment was package private. However, all classes inheriting from Fragment have to be public classes or public static inner classes.
If they are not, it may bite you badly. The reason is that even though it seems to work fine when the class is package private, it will fail when a Fragment is being recreated after it was destroyed to reclaim some memory in a low mem condition.
The moral at the end is that you shouldn't always listen to what your IDE says, because I introduced the bug after the Android Studio told me that this fragment class can be made package private.
Sometimes I see the following logcat output such as that below:
<3>[ 283.152845] init: untracked pid 4217 exited
<3>[ 283.162185] init: untracked pid 4078 exited
<3>[ 283.173691] init: untracked pid 1504 exited
<3>[ 283.177018] init: untracked pid 1468 exited
What is the meaning of the log of init: untracked pid xxxx exited?
use logcat and read the huge log carefully. You might find the program that crashes all the time.
There may be many different reasons, one of them is that android init trying to
initialize services specified by init.rc failed.
You can try to bisect the services started from init.rc first, and once you find
the errornous service, then try to fix the specific service start up errors, which
may be the kernel driver error, or android hal driver error, library fault, or
sometimes android framework error.
Technically, this message (modern version of which is "Untracked pid XXX exited with status YY") means that Android init sees a child process exit (that is, receives SIGCHLD signal and then gets its pid with waitpid()), but it can't associate that process with any of configured services (see this question on Android init service configuration).
This in turn opens up a question of what can daemonize itself in Android environment and how to find it. But I don't think that I can answer that, the only suggestion that I have is getting root access and checking processes.