Develop Reference

java.util.concurrent.TimeoutException: id.finalize() timed out after 10 seconds

Our company's app encountered a crash, but this problem is not necessarily present, I can not reproduce the problem now, we can provide me with the next solution to ideas
id.finalize() id is RandomAccessFile's Subclass .
this STACK_TRACE is :
java.util.concurrent.TimeoutException: id.finalize() timed out after 10 seconds
at libcore.io.Posix.fstat(Native Method)
at libcore.io.ForwardingOs.fstat(ForwardingOs.java:56)
at libcore.io.BlockGuardOs.close(BlockGuardOs.java:60)
at libcore.io.IoUtils.close(IoUtils.java:43)
at java.io.RandomAccessFile.close(RandomAccessFile.java:166)
at java.io.RandomAccessFile.finalize(RandomAccessFile.java:175)
at java.lang.Daemons$FinalizerDaemon.doFinalize(Daemons.java:194)
at java.lang.Daemons$FinalizerDaemon.run(Daemons.java:176)
at java.lang.Thread.run(Thread.java:841)

This sounds like broken memory that caused writes to it to take too long. Happens when you use bad sd cards. You should do a stress test and write many bytes to a file and close it.

Android DeadSystemException

Currently, we are experiencing a DeadSystemException in our HockeyApp crash reporting. It occurs on Android 7.0 and Android 7.1. We don't experience this exception in the previous version of our application (they are currently both used by users), so I guess this exception is caused by some code change. But stack trace is not very helpful for this. Any idea?
Thanks for any suggestions.
Stack trace from HockeyApp:
java.lang.RuntimeException: android.os.DeadSystemException
at android.app.ActivityThread$StopInfo.run(ActivityThread.java:3781)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6119)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:886)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:776)
Caused by: android.os.DeadSystemException
... 8 more

The Android Developer docs for android.os.DeadSystemException says the following:
The core Android system has died and is going through a runtime
restart. All running apps will be promptly killed.
The source code does not help much more:
package android.os;
/**
* The core Android system has died and is going through a runtime restart. All
* running apps will be promptly killed.
*/
public class DeadSystemException extends DeadObjectException {
public DeadSystemException() {
super();
}
}
Overall, it looks like this is being thrown by the OS and has nothing to do with our code.
Looking at the JavaDoc from the superclass, DeadObjectException, backs this theory up:
The object you are calling has died because its hosting process no
longer exists.

One cause was a bug in the notification service of Android version 7 and 8.
It was caused by using "vibration pattern" in the notifications, which throws an ArrayOutOfBoundsException. This leads the whole system to crash and post a DeadSystemException.
For further details you can refer to this Medium article here.

Fatal Exception: java.lang.RuntimeException: android.os.DeadSystemException
This exception was caused in one of the apps I was developing, it occurred mostly in MI devices.
After debugging I found that I was trying to start another service (Say B) in the current service (Say A) from a background thread, but when startService(itService) method was called the service A was already killed.
The only solution I found till now is to check if the current service A is running or not before you start another service B. Depending on your implementation you can use one of the various ways to check if a services is running from this answer.

I was able to reproduce this exception in one of my apps.
It turns out that I misunderstood something while implementing in-app purchases, as I wasn't expecting Google to notify also the already purchased and acknowledged products, so I was not checking if I already managed the purchased product notified about.
So I had an infinite loop in my app consisting on reloading again and again and again the same information on screen, until eventually (but a little bit randomly I must say) this exception raises.
Caused by java.lang.RuntimeException
android.os.DeadSystemException
android.app.ApplicationPackageManager.getPackageInfoAsUser (ApplicationPackageManager.java:188)
android.app.ApplicationPackageManager.getPackageInfo (ApplicationPackageManager.java:159)
com.google.android.gms.common.GooglePlayServicesUtilLight.isGooglePlayServicesAvailable (GooglePlayServicesUtilLight.java:13)
com.google.android.gms.common.GoogleApiAvailabilityLight.isGooglePlayServicesAvailable (GoogleApiAvailabilityLight.java:2)
I hope this to be useful to someone, as it's info about how to try to reproduce the exception, not how to solve it (well, in my case was just fixing the silly error and preventing the infinite loop of screen reloading, but there must be variety of different causes producing this exception).

Another example :
try {
ActivityManager.getMyMemoryState(mAppProcessInfo);
} catch (Exception exception) {
exception.printStackTrace();
return;
}

ANR application

I know this question is probably asked few times but I can not find a valid answer for my case.
In my logcat I get
D/AndroidRuntime﹕ Shutting down VM
W/dalvikvm﹕ threadid=1: thread exiting with uncaught exception (group=0x418337c0)
which indicates I have a crash somewhere, but I can not see it in log, there is no more information about the crash.
I have tried
adb server -kill, adb server-start.
I closed the adb from the proccess in Task Manager and closed AndroidStudio and started everything again (I tried restart windows too).
I am using CrashLytics in my application, but I do not receive crash there either, however TestFairy was able to give me finally some information which is application ANR and the next log (sorry about messy log)
java.lang.Object.wait(Native Method)
java.lang.Thread.parkFor(Thread.java:1231)
sun.misc.Unsafe.park(Unsafe.java:323)
java.util.concurrent.locks.LockSupport.park(LockSupport.java:157)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:813)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:846)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1176)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:185)
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:261)
com.google.android.gms.analytics.zzx.zzfj(Unknown Source)
com.google.android.gms.analytics.GoogleAnalytics.zzfj(Unknown Source)
com.google.android.gms.analytics.ExceptionReporter.uncaughtException(Unknown Source)
java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)
java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)
dalvik.system.NativeStart.main(Native Method)
so I tried to search around and some says it can be a crash in GoogleAnalytics while trying to report another crash. so I disabled this code
UncaughtExceptionHandler myHandler = new ExceptionReporter(
mTracker,Thread.getDefaultUncaughtExceptionHandler(),
getContext().getApplicationContext());
Thread.setDefaultUncaughtExceptionHandler(myHandler);
I know that this issue happens after trying to open a fragment but when I debug the fragment is not started yet.
The problem is I still can not see any more information, so How can I see log or more information? Thanks and sorry for long post.

An ANR will occur if you are running a process on the UI thread which takes a long time, usually around 5 seconds. During this time the GUI (Graphical User Interface) will lock up which will result in anything the user presses will not be actioned. After the 5 seconds approx has occurred, if the thread still hasn't recovered then an ANR dialogue box is shown informing the user that the application is not responding and will give the user the choice to either wait, in the hope that the app will eventually recover, or to force close the app.

Black Screen After Restart

I've a strange black screen problem at app restart after the app wasn't used for a while reported by users in the play store developer console with an ANR with a quite strange stack trace:
----- pid 2704 at 2013-08-15 09:08:32 -----
Cmd line: system_server
DALVIK THREADS:
(mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)
"main" prio=5 tid=1 NATIVE
| group="main" sCount=1 dsCount=0 obj=0x400281b8 self=0xd088
| sysTid=2704 nice=0 sched=0/0 cgrp=default handle=-1345006464
| schedstat=( 29713532638 35237133707 131286 )
at com.android.server.SystemServer.init1(Native Method)
at com.android.server.SystemServer.main(SystemServer.java:918)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(...)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:665)
at dalvik.system.NativeStart.main(Native Method)
...
and no thread with app code involved. I can kind of reproduce it on one of my test devices but it is quite random and takes really long to run into the error. But if I'm able to I get the following messages in the log of the device right after starting the app:
I/ActivityManager( 2704): Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.example.client.android/.ExampleMainActivity bnds=[125,494][235,632] } from pid 2908
W/ActivityManager( 2704): Receiver during timeout: BroadcastFilter{40b8b180 ReceiverList{40b8b108 32495 com.example.client.android/10107 remote:40b34b28}}
I/ActivityManager( 2704): Skipping duplicate ANR: ProcessRecord{40bfc8c0 32495:com.example.client.android/10107} Broadcast of Intent { act=android.intent.action.SCREEN_OFF flg=0x40000000 }
W/ActivityManager( 2704): Activity idle timeout for HistoryRecord{40578b78 com.example.client.android/.ExampleMainActivity}
I already googled around and found the following posts on StackOverflow concerning these messages:
Activity idle timeout for HistoryRecord?
Activity idle timeout for HistoryRecord
And the following post in google groups:
https://groups.google.com/forum/?fromgroups#!topic/android-developers/TfkPlN5b-ig
I checked for services, if there's anything heavy-weight in onReceive of the BroadcastReceivers but haven't found anything.
We use a OnGlobalChangeLayoutListener, which applied an View.invalidate() to work around a WebView repaint probelm which maybe could cause a draw-Looping. I removed it but still do get the problem.
Anyone maybe having the same problem and having an idea how to fix it or to isolate it? I'm pretty much out of ideas here and would love to understand what's going on here.
UPDATE
I forgot to mention: if this black screen problem happened the only way getting the app out of this is a forced stop of the application process. Otherwise the log lines get logged every time I try to start the app.
UPDATE 2
A more detailed description of what is happening as requested: The black screen occurs very randomly. It always happens at start of the app and if happened only a force stop gets the app out of this. It seems to happen only after the app wasn't used for a longer and was probably swapped out of memory. And it looks like only Android 2.x devices are affected although I'm not sure with this.
UPDATE 3
I've added a button which calls android.os.Process.killProcess(Process.myPid()); and if I call this again and again I've been able to reproduce it after some time, by starting the app and quitting it using the button. After some time (quite random), I get this right after quitting using the button:
E/JavaBinder( 2704): !!! FAILED BINDER TRANSACTION !!!
followed by a:
W/ActivityManager( 2704): Activity pause timeout for HistoryRecord{40976dd8 com.example.client.android/.ExampleMainActivity}
and next time I restart the app I just get a black screen and the log messages mentioned above. I've been unable to reproduce the same with an android 4.1 device, only with two 2.3 devices.
Googling around I found this:
http://androiddiscuss.com/1-android-discuss/42614.html
suggesting the binder transaction buffer is somewhat exhausted. We use the MediaPlayer, InApp-Billing and Google Cloud Messages which use binding. I removed all of them and still get into this error. Maybe someone knows other hidden binder related stuff to check for?

I was finally able to identify the faulty component: I recently updated the used Admob-SDK from 6.2.1 to 6.4.1 and the black screen (and the Java-Binder message) happens since the update. Rolling back to 6.2.1 solved the issue.

App dies with "Sending signal." but no exception or other info

I'm working on an app that is recording data via Bluetooth, but it intermittently crashes after hours of collecting data (making it hard to track down the bug).
The logcat output isn't very helpful:
http://i.imgur.com/EalnX.png
There are no exceptions thrown and no clues for what caused the process to be terminated.
How can I figure out what went wrong? Is there an exception being thrown that isn't being shown by logcat? How can I track this bug down?

Signal 9 is SIGKILL, which will terminate a process immediately (no handlers inside the process will run). From the log line, the process is killing itself, so its not an external agent that is issuing the SIGKILL.
My guess (and its really a guess) is that the memory management code running inside your process (as part of the infrastructure, not code that you wrote) is deciding that you've exhausted some resource and the only recourse is to die. I would expect there to be more messages before this point is reached in the log, so it may be worth browsing the log history to see if there are useful warnings from the process before this point.
The line immediately before this is a GC log, which implies that some sort of memory resource is running low. But it looks like the heaps are not full, so failing allocations seems unlikely. You can still get allocation failures if the object being allocated was too large to fit on the heap, or fragmentation prevented it from being allocated. I'd expect to see more relevant log messages in this case, though.
I think capturing more of the log (perhaps filtering it by your app's PID if necessary) will help you make progress.

In my case there was no warnings or any clues in the log.
Eventually I found that my problem was that one of the activities I was going into (lets say Activity X) was registering to a broadcast receiver but never unregistered from it.
Therefor by closing the activity (Activity X) and coming back to it caused registering Again to the same broadcast receiver - which caused the mess!
Simply adding unregisterReceiver(mybroadcast); (in Activity X) solved it.
(I added mine to onDestroy. make sure you unregister in the right location).
And if you are super desperate I recommend seeing this slide share which explains Android crash debugging your errors.

this problem happens when using RXjava and not implement the onError callback method