Develop Reference

bt-hci btu_ble_process_adv_pkt still runs after iBeaconManager.unBind(this); is called onDestroy()

I am using Radius Networks iBeacon library for Android to build my first Android app. It's been really easy to implement the library and I've got a half-decent demo app working (thanks a lot davidgyoung!).
I am now trying to iron out the kinks. My app works as a demo whereby a user needs to tick off 3 checkboxes by going near 3 iBeacons. They are then presented with an activity that asks if they want to do it again with a button to restart.
The function that displays the 'completed' activity also finish()s the 'checkbox' (ranging) activity, and onDestroy calls the unBind method of iBeaconManager.
Intermittently, after a restart the iBeacons aren't picked up and LogCat is spits out this forevermore.
02-18 14:52:38.800: I/bt-hci(1392): BLE HCI(id=62) event = 0x02)
02-18 14:52:38.800: I/bt-hci(1392): btu_ble_process_adv_pkt
02-18 14:52:38.850: I/bt-hci(1392): BLE HCI(id=62) event = 0x02)
02-18 14:52:38.850: I/bt-hci(1392): btu_ble_process_adv_pkt
02-18 14:52:38.910: W/bt-btif(1392): bta_dm_ble_observe BTM_BleObserve failed. status 2
02-18 14:52:38.980: I/bt-hci(1392): BLE HCI(id=62) event = 0x02)
It usually happens on the second/third run of the app.
My hunch is that it is because of a failing with
iBeaconManager.unBind(this);
not releasing the BT stack properly, so ending up with two instances overlapping.
Could anyone shed some light on this because I've reached a point where I'm not getting anywhere.
Please let me know if you'd like to see more code.
Best
Andrew

I suspect the issue does have to do with binding to/unbinding from the service. This should be no problem doing what you describe if the code always unbinds before rebinding later. It is hard to say for sure what is going wrong without seeing the code (or a simplified version that reproduces the problem.)
I would suggest adding a log statement when you bind and another when you unbind, then run the app and make sure they match up. The Android life cycle can be tricky. I bet you will find that there is a mismatch. Are you sure the on Destroy() is always getting called?
Understand that if iBeaconManager.unbind() is called when no other clients are bound, the IBeaconService will stop, and LogCat should confirm this. If you later rebind, it will simply start back up again. Are you seeing this?
One other tip: if you have two apps running on your phone using the Android iBeacon Library, you will have two copies of the service running. This is by design, and should pose no problem, but might make LogCat output confusing. Use settings to stop or uninstall all but one of these apps to aid in debugging.

I had this issue as well and tracked it down to a bug within the IBeaconLibrary itself. I was about to report the issue to RadiusNetworks but noticed on their GitHub that this was already found (or a similar bug with related cause) and was fixed in their current code. Unfortunately, it is not yet in an official release and so you'll need to download the source from GitHub and build the library yourself but I can confirm that after having done so, I am no longer seeing this issue.

Is it a good idea to initialize Crashlytics, on android's onCreate method?

I'm using Crashlytics for android and it really helped me to fix many of my crashes. But today I had a little problem with it.
When I tried to test crashlytics on 2.3.3 Galaxy S device, which is connected to internet by wi-fi(with proxy), I saw black screen on device for about 2:30 minutes. While debugging; I see that Crashlytics.start(this) code is not async. It waits to establish a connection and thus onCreate method can not be finished by UI thread.(This explains black screen).
I know this a proxy issue(proxy setting is a bit buggy on 2.3.x devices) but waiting for about 2:30 minutes made my app black screen. This worried me that this may happen on any other real life conditions such as poor internet connection.
I will try to put Crashlytics.start(this) function into an asynctask and will try this on every activities onCreate method. (AFAIK there is no method to check isCrashlyticsInitialized)
Does anyone have better idea about this?
Thanks in advance.
LOGCAT:
10-02 16:01:38.410: D/Crashlytics(1561): Initializing Crashlytics 0.9.11.11
10-02 16:04:19.664: E/Crashlytics(1561): Network error while loading Crashlytics settings. Crashes will be cached until the network is available.
[URL=https://settings.crashlytics.com/api/v2/keys/KEY/platforms/android/apps/com.myapp/settings.json?libVersion=0.9.11.11&bundleVersion=441210&shortBundleVersion=2.1];[class java.net.SocketTimeoutException: Connection timed out]

Marc from Crashlytics here. Crashlytics.start() does all the heavy lifting in a background thread in newer versions of the SDK. Your logs indicate you're using v0.9.11. Once you update to the latest version (v1.0.4), you'll be fine keeping Crashlytics.start in the Application subclass. Please contact us at support at crashlytics dot com if you need any help updating!

android ANR(activity not responding) trace.txt

I have in my app an occasional and very hard to reproduce ANR event. Today it's happened, and I pulled out from the device the file trace.txt situated in /data/anr.
Unfortunately I can't understand the data in this file, here is the complete file content.
Can someone understand what is keeping my app's UI unresponsive?
I've already read similar questions but still can't read the file..
I've pasted the complete trace.txt file content to pastebin
EDIT
the file on pastebin is not available anymore and I do not have access to the trace.txt file anymore, so the answer can be closed.
thank you

You can use Strictmode to find out what calls delay a specific thread. The best way to use it is in the following form. In your application onCreate() you enable StrictMode. After that, (almost) all slow calls on that thread will be reported to your Log, with a full stacktrace of where it happened.
In your custom Application class:
public void onCreate() {
if (DEVELOPER_MODE) {
StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()
.detectAll() // detect everything potentially suspect
.penaltyLog() // penalty is to write to log
.build());
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
.detectAll()
.penaltyLog()
.build());
}
super.onCreate();
}

As #Mohamed_AbdAllah has written on his comment "trace.txt is the situation of all running threads when the ANR occurred." Finding the reason of ANR from a thread while ANR occured seems impossible with a trace like you post. If you want to understand what those texts in trace mean, you may be interested in this. (You can get which thread is long running when the ANR occured from trace but this probably does not help you)
Alternatively, if you want to see what type of crashes/ANRs do you have with your andoid application(I assume that you are interested in applications that you developped and published on google play) you can use a crash report api. I use crashlytics for this purpose and it really helps me to fix my applications crashes. When you add this api to you application you can trace all Crashes/ANRs on a web page.
If your aim is understanding how to find reasons of ANRs from trace.txt then I have no idea. But if you need to find and fix your crashes/ANRs, then use a crash report api.
Edit: I assumed you are talking about an application which you've developed and published on google play. If you are talking about an application which is not published to google play yet, #Jeffrey Klardie's suggestion is just what you need. But it is not advised to enable Strictmode on applications at google play.

It's really hard to help on this without code to see what's going on, so instead I'll list what I would do to my own code should I be in this situation.
Run a Static Analysis tool on my code to identify some odd behavior (infinite loops, missing cases, etc.). Personally I use FindBugs.
Review the errors that pop-up from the Static Analysis tool, correct the ones that make sense for what you are doing.
Look through the code for any occurrences of "evil" code such as really long loops, synchronous activity that can be asynchronous, use of the sleep() function, asynchronous activity that is being treated synchronously, etc.
If none of the above made an impact start throwing in Log statements all over the place. Watch the output from a run and see where it gets to or what is repeating.
If none of the above worked, pop open a beer do a little yoga and then get back on the prowl and dig some more!

The most likely cause is the compiler is waiting for some interweb operation on the UI thread.

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

Android Force Close Uncatchable Unreportable

I've released my second game project on the Android Market this week, and immediately had multiple 1-star reports due to force closes. I tested it on many handsets and many emulators with zero issues. I'm completely at a loss for how to proceed and looking for advice.
I use Thread.setDefaultUncaughtExceptionHandler to intercept and report uncaught exceptions, then close gracefully. The people reporting force closes aren't getting to any of that, even though it is the first thing set in the application's main task constructor, and everything is wrapped in try/catches throughout. They are also reporting that there is no "Send Report" option in the force close popup (providing the Developer Console error reports), so I have absolutely no way of knowing what the problem is.
Uses Android 2.0, with android:minSdkVersion="5". Only Permission required is INTERNET.
(on Android market as 'Fortunes of War FREE' if you want to test)

I'm a bit surprised about the missing "Send report" button. What API level did you build the game with? I usually build the level with your minimum API level to make sure you're not using any API calls beyond that, but then switch back to the highest API level so you can use functionality like "install to SD".
I'm sure there's at least one user who wrote you a mail. Can you ask them to install LogCollector and mail you the log?
Btw, in general, I wouldn't use Thread.setDefaultUncaughtExceptionHandler so there IS the option to send a report. (It's ominously missing in your case, but normally, it should be there.)
Btw btw, the exception handler applies to the current thread. If you have an OpenGL app, maybe the crash happens in the GL thread?

I'm not sure if I understood you correctly, but as far as I know Android only shows that report dialog if you use its default UncaughtExceptionHandler.
Try this:
In your UncaughtExceptionHander's constructor, call Thread.getDefaultUncaughtExceptionHandler and save the returned object in a variable (let's call it defaultHandler). In your Handler's uncaughtException() do the things you want to do, and then call defaultHandler.uncaughtException() afterwards.
Maybe something you should know:
In my experience, your Context isn't functional anymore at uncaughtException(). So, you can't send broadcasts, etc anymore.
By the way, if you really wrapped everything in try/catch, that could be the reason why error reporting doesn't work as expected? :P
Good luck
Tom

Perhaps the force closes are caused by stalls, rather than exceptions. Users may not notice the difference. This kind of problem can occur more often if users have CPU hogging services running at the same time as your application, which explains why you're not seeing the issue in your testing.

Permission Internet sounds a lot like you try to transfer data from the net, which is very fast in your local LAN, but all of a sudden becomes slow (and time consuming) when people try this over their GSM connections.
If you then do the data transfer in the UI thread, this one is blocked and the system detects the block - but then this should end up in a "Did not respond" -- but then I've seen one user report an error with in the market on my app that was such a slow down cause.