I'm using FingerprintManager in my app and usually all works fine.
The main issue I have is that customers sometimes complain that the fingerprint operation is sometimes cancelled, what I can see in the logs as error 5 (Fingerprint operation canceled).
Now, I know that other apps not developed good can hold the sensor if they do not release it on inPause or similar, so even lockscreen can't use the sensor.
Is there a way to get around this issue and force the sensor to start working with my app again?
Thanks
I faced the same issue, there is an issue raised around this with Android.
https://code.google.com/p/android/issues/detail?id=208512
Here is how I am handling it in my code.
if (errMsgId != FINGERPRINT_ERROR_CANCELED) {
// As you see below that error code happens when device is locked.
}
Related
We have an app utilizing NFC and recently migrated from enableForegroundDispatch to enableReaderMode. Since then, we have been receiving bug reports where the user intermittently has trouble scanning tags.
I was troubleshooting remotely with a customer today who was unable to scan any tags (the app was working through yesterday). Sometimes they would receive an "NFC read error. Try again" message.
When we had them install the older version of our app which uses enableForegroundDispatch, NFC scans worked as intended. Scanning using the NFC Tools app was also working during this time, as was scanning with no app open. We tried rebooting the device and also toggling NFC on / off with no luck. It was just our app.
After much debugging, what appears to have resolved it was to fully delete our app from the device and then reinstall it. The device is a Google Pixel 2 running Android 11.
I have read countless threads about enableReaderMode and am also aware of this bug affecting kiosk apps in Android 11 (but our app isn't a kiosk). I also read about how there is a bug where Android might think our app is not in the foreground.
Is there any credence to the theory that deleting our app (vs. updating the same installed package with different builds) is what resolved this, and if so then what exactly is happening that is causing this?
Edit: I just found the threads about "NFC service dead" and am guessing this is what happened.
I have read the public code for NFC service, I cannot remember it having anything that would be affected differently by update vs uninstall/install other than possibly the Manifest(PackageManager?) permission to use NFC.
I have not looked in to details about how an app update updates the Manifest permissions, but guess an update might not update the permissions if it thinks they are not changed whereas remove/install would probably delete the whole entry and re-add it thus if there was corruption in the permission list a remove/install would likely fix it.
Also if the NFC Service is dead then other App's would not scan as well. I do seem to remember there is something in there to restart the NFC service if it had died.
My ionic angularjs corodova app works great when receiving calls from the demo web page on chrome. When I try to initiate a call to the demo site or another device, whether using demo API key or real api key, i get
call_crossing_detected
What does this mean, and how do you fix it?
More details on symptoms. When this occurs, no video comes up and the initiating device shows the error and the call button remains. But the receiving device switches to the hangup button, which then works. And if you speak into either device the receiving device receives the audio, but nothing on the initiating device
"call_crossing_detected" reason appears on hangup event when a call is already established between the two users and you are trying to establish a new one.
So I think you may have an issue on the first call hangup.
I have resolved this issue. It was caused by apiRTC.init executing more than once.
Is there any way I can get rid of this message despite the app being stopped due to any exception?
My app(background service) is designed in such a way that it always restarts itself within 1 mins in case it gets killed. So even if it gets stopped, it would be restarted again, with no negative impact. Hence that message would unnecessarily annoy/worry the users.
As the app works fine on my device, but on other's device, its giving that message once or twice a day. I have no way to read the logs and check whats going on. I have placed the try/catch block everywhere. And the code is too complex to dig into again and check whats wrong. In short, I don't want to get rid of the "cause" off the message. But the "message" itself. Is it at all possible?
So How do I get rid of android OS showing that message even if it has "stopped"?
So even if it gets stopped, it would be restarted again, with no negative impact
There is no way to know whether or not there is a "negative impact" until the source of the problem is found.
I have no way to read the logs and check whats going on. I
Use crash logging frameworks like ACRA to collect stack traces from production apps.
And the code is too complex to dig into again and check whats wrong.
Use the crash logs from crash logging frameworks like ACRA to identify the source of the problem.
Is it at all possible?
Read the documentation for your chosen crash logging framework and see what the options are for user notification regarding such crashes. Some, like ACRA, will offer a "silent" mode where the crash is logged but without informing the users of that crash.
Theoretically, you could set up your own Thread.setDefaultUncaughtExceptionHandler
Recently my users are complaining that application hangs while using it and the data stored getting lost when the reboot the mobile.
Its not happening everytime too.
Can some one please tell me for what are all the reasons sqlite data will get lost.?
Also for what are the reasons android application freeze?
Background : My application perform sqlite operation from all the screens. The device
Model Number: Samsung GT-18160 , Android Version:2.3.6 , Kernel
Version:2.6.35.7-1219296 dpi#DELL210#2
You can assume no data should be lost. But you may want to nail down crash culprit first - luckily your user is on 2.x so tell him to use tools like aLogCat and grab the logs after your app crash. Then check what's there and fix. That should solve your "data lost" issue as whatever it is, it occurs after your app crashed. If it stop crashing then it should not trigger the snowball....
I developed an application for android tablets. In that application, when I get into the app and after doing some actions I keep the application idle for half an hour or sometimes and again get back into the app to perform any action, it leads to application crash with UNKNOWNHOSTEXCEPTION.I don't know why it happens even after i gave INTERNET permission in Android manifest file.I have been searching solution for this problem for one week...still i could not able to find any solution.i used fragments in my application...please help me...
Likely the tablet temporary switching off the network to save energy. Add try/catch to your requests and probably do 2-3 tries in some interval before you will show error to user.
This type of exception happens when you try to switch networks , or the required Network isn't available.
Use try/catch block to prevent crashing of application.