Develop Reference

ANR on mkdirs() and exists()

I'm pretty baffled by the ANR I'm getting from my application as I don't understand how it could happen.
I've got mutliple ANR for these codes:
File(applicationContext.filesDir).mkdirs()
File(applicationContext.filesDir).exists()
and I get the following ANR report:
1.
main (native): tid=1 systid=30195
#00 pc 0xc57c8 libc.so
#01 pc 0x21580 libopenjdk.so
at java.io.UnixFileSystem.createDirectory0(UnixFileSystem.java)
at java.io.UnixFileSystem.createDirectory(UnixFileSystem.java:354)
at java.io.File.mkdir(File.java:1325)
at java.io.File.mkdirs(File.java:1352)
#01 pc 0x21fc0 libjavacore.so
at libcore.io.Linux.access(Linux.java)
at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
at libcore.io.BlockGuardOs.access(BlockGuardOs.java:76)
at libcore.io.ForwardingOs.access(ForwardingOs.java:131)
at android.app.ActivityThread$AndroidOs.access(ActivityThread.java:8068)
at java.io.UnixFileSystem.checkAccess(UnixFileSystem.java:281)
at java.io.File.exists(File.java:813)
My application targets from Android 5 to Android 12 and only Android 11 and Android 12 are getting these ANRs.
Do you guys have any idea how to solve this ? Should I File(applicationContext.filesDir).mkdirs() on a different an IO Thread to avoid blocking ?

You should definitely perform all file operations off the main thread, regardless of what else is happening. It's definitely not a permissions issue -- if it were, you would just get a permission denial, not an ANR.
Having said that, you generally wouldn't get an ANR from just checking your app's fileDir, even on the main thread. But my guess is that wherever this AND came from, either the device's internal storage is really slow, or it's likely that your app was moved to external storage. Checking external storage availability takes longer.
Either way, as I said earlier, it doesn't actually matter why it's happening. You should just be performing all the file IO on a separate thread

Mysterious Signal 11 crash when accessing Room database

About
I have an android application, which has 2 activities. Activity A spawns Activity B, and Activity B accesses Room Database in another module. I'm using Koin for all dependency injections, and rxandroid (Schedulers.io() for observing and UI thread for observing) to observe the database transaction
The Issue
When I access the database, the action completes successfully, an entry is added in the database, and then 1-2 seconds later the activity crashes and the app returns to Activity A with no stack trace or any error message in the application logcat.
Im testing the app in AVD Pixel 2 API 28
If I remove all filters from logcat, I can find this error:
2021-01-14 22:31:01.836 9799-9799/com.example.myapp I/System.out: Saving Course
2021-01-14 22:31:01.928 9799-9799/com.example.myapp I/System.out: Added course to DB: 11
2021-01-14 22:31:02.822 9799-9835/com.example.myapp I/om.example.myap: Explicit concurrent copying GC freed 94987(4MB) AllocSpace objects, 0(0B) LOS objects, 49% free, 3MB/6MB, paused 329us total 10.624ms
2021-01-14 22:31:03.439 1935-2006/? W/InputDispatcher: channel '7a68875 com.example.myapp/com.example.myapp.activities.CourseCreatorActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
2021-01-14 22:31:03.439 1935-2006/? E/InputDispatcher: channel '7a68875 com.example.myapp/com.example.myapp.activities.CourseCreatorActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
2021-01-14 22:31:03.441 1935-2006/? W/InputDispatcher: channel '1c99176 com.example.myapp/com.example.myapp.activities.MainActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
2021-01-14 22:31:03.441 1935-2006/? E/InputDispatcher: channel '1c99176 com.example.myapp/com.example.myapp.activities.MainActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
2021-01-14 22:31:03.443 1773-1773/? I/Zygote: Process 9799 exited due to signal (11)
signal 11 is apparently segmentation fault..
What I've tried
Only creating the room entity without inserting it in to the DB still produces the crash
removing Activity A and starting the app on Activity B (which accesses the DB) seems to not produce error (ive tried a few dozen times)
stepping through the save function using the debugger. I can break the main thread or the IO thread, and in both cases the app will crash despite the thread being in break state.
replacing rxandroid for kotlin coroutines. The crash still happens after this
I've tried debugging the app on my phone (pixel 3a) and have so far been unable to reproduce the crash. Will keep trying though.
I tried this on a Pixel 3a AVD at API 30, and couldnt replicate the crash. Then I tried on a Pixel 3a AVD at API 28, and the crash was there. So currently it seems to only happen in API 28...
Tested with API 27 and API 29, both worked fine. Deleted the API 28 SDK and redownloaded it, deleted all related AVDs and recreated them, still getting the signal 11 crash like 2nd try on a fresh install of API 28.. So it seems that the segmentation fault only occurs on Android Pie
I started creating a simplified version of the same overall architecture and logic im using here in an effort to pinpoint where the error originates from exactly. Im not very keen on starting over on the simplified project as without knowing what is causing this error, I would most likely just run in to it again eventually.
Note: Sometimes I will make a change and it will "fix" the issue, only for it to reappear after a while and that makes this really hard to debug with conventional methods
Conclusion
What I really need is some way to debug this. I have no idea what is causing it, and really no idea how to go forward in debugging it.

I changed to a different android API level and the problem has not resurfaced since

Having to post as an answer due to the character limit
Going to tack onto this as i was experiencing the same thing across two different EMU's - 28 and 30. Two weeks of debugging i came across this. I felt like my app was simple.
Core composed Dagger2 RxJava2, Room, Retrofit, Material etc.
Main Activity A contained 5 set fragments and 3 were liveData. - fine.
Moved to Class B, fine, Getting a list of Objects from DB. - fine
Moved to Class C, crashing from instant - 7 seconds. This was a similar setup, Class C, contained Fragments that observed different LiveData.
No errors, nothing on debug - just the debugger disconnecting, nothing in logcat except like the above. Nothing in tombstone. Just channel closing + I/Zygote: Process xxxx exited due to signal (11)
The app would always fireup the previous activity or the same activity with no database data.
Fired up leakcanry, nothing there, Fired up Google vitals nothing there, fired up Firebase crashlytics and still nothing there. Even fired up Airbrake, still nothing.
Switched to Class D, that was highly similar to class C but skipped Class B, - still crashing.
Switched to Class E, no live data but saved to DB directly, crashing there.
I have performed the usual invalid cache and restart, wipe data on the EMU's...alot more debugging attempts... Fast forward two weeks, and i came upon this and it saved me having to rip Room out.
Solution:
I had to create all new EMU's. Now the exact same code is working from Android 23 to 30.

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

How can I detect the cause of silent failures on Android?

I am debugging an Android application and one of the activities just failed silently; it popped off the back stack and I got the previous activity.
I've seen silent failures of this type that can be attributed to memory problems, but in this case I am testing without the debugger attached. The logcat shows virtually no information: after some output from our touch listeners, I get
I/DEBUG(85): debuggerd committing suicide to free the zombie!
I/DEBUG(24919): debuggerd: Jul 8 2011 06:16:01
I/ActivityManager(157): Process com.tse.newsreader (pid 24415) has died.
I/WindowManager(157): WIN DEATH: Window{4108f938 com.tse.newsreader/com.tse.newsreader.activities.StorefrontFragmentActivity paused=false}
com.tse.newsreader is our process.
I would like to know if this is caused by a memory leak somewhere and I was hoping to add an HPROF dump to a global exception handler, somewhat as described in Is there a way to take a memory dump on app crash? but if there is no exception or OutOfMemoryError to catch, I don't see how that will help.
Can anyone suggest how I can get at the cause of these silent failures?

I'm not sure if this is what you mean, but you could consider adding something like bugsense to your app. It will pick up uncaught exceptions.