We have just managed to replicate an issue that a customer is reporting with our Android Tablet (4.4.2) and a Bluetooth device. They have reported that they are unable to pair our supplied bluetooth device with the our supplied tablet. To fix it they just rebooted the tablet.
In the office we have replicated this. Going to Settings->Bluetooth and clicking on the device in Available Devices doesnt do anything. If I power up another one of our devices, then I can pair with it without an issue.
Its only this one particular device thats causing the issue....which got me to thinking Android was caching this devices info somewhere and that cache was now out of date/corrupt somehow.
After a lot of googling I came across the tip of clearing the "Bluetooth Share" application data cache and this fixes this issue. However I need to do this automatically from code.
Has anyone come across this issue? And if so how have you managed to call this Clear Cache function from code?
Thanks!
Related
I'm porting Android Lollipop on x86_64, seeing one weird behavior from device.
As soon as device goes in suspend state it reboots the device.
Please help me to investigate the reason behind it, what all the possible methods to reboot the device without using power button (i.e. from kernel code, android framework).
After lot of research, what all I can conclude is, that this issue was caused by unsupported sleep state provided by ACPI.
Restarting automatically can be down (but not limited) to a few different things:
WiFi related
Lock screen related
Storage related - Some users report that a low internal storage was the cause of this, and simply freeing up some space fixed this
Battery related - Malfunctioning or insufficiently charged battery
Power button related - Many report that dirty can get stuck under the power button, triggering the button randomly. Pressing it in hard can remedy this
On top of these known reasons, it seems that this is a recognised problem with the Lollipop update.
User Nitin Dhage from the following Google Product Forums page wrote:
I'm also facing the same issue (restart when phone locks, red.)
however if I set the other security type except pattern the problem is
solved. If we use PIN or NONE then the problem will solve, the problem
is with Pattern security type only.
You may want to join the following discussion regarding the topic of Restarting frequently from lock screen after updating to Lollipop
https://productforums.google.com/forum/#!msg/nexus/X6ZjAAauATc/MmPqyAay3UMJ
I'm having trouble with an app I published that sends user notifications.
The notifications are called from a background service that checks for a boolean that gets saved to SharedPreferences when the user selects to enable notifications or not.
However, I've had some users on the Galaxy S5s say that they can't turn them off (I test with nexus devs and have beta testers on m8, etc). How do I address this issue?
What is the strategy for solving problems that arise only for specific devices?
IMO, Android kinda sucks in that regard. There is absolutely no way to guarantee that if one piece of code that works on one device works on another one. Since Android is open source, manufacturers usually modify the firmware to make it kinda customized. However, they sometimes change things that will affect performance of a single function.
It is even worse! Your code might work on S4 with Android JellyBean, but not work with the same device Android Kitkat. Anyways, no - there is no way to debug without the actual device. However, you can log different events in your code and use an analytic service (like Google Analytics) and send the data to your database to study and figure out the problem. This is the method that I typically use in such cases.
If the problem is that the app crashes on some device. It is even easier. Users need to press on the "send crash data" button - so you can study the log on your developer account.
I'm developing an Android application able to connect to a BLE (Bluetooth low energy) device.
Problem is after connection, when I want to re-connect to an other device, I can't.
The only solution is to off and on phone bluetooth.
(On the iOS app, it works so problems is from Android app).
I get this error :
BLE connection generic error
I there any known bug on Android >=4.0 on BLE connections ?
There are lots of bugs in the bug tracker and the documentation and example are not good.
You have not given enough information to really be able to tell what your specific problem is but the main issue people fall over is thinking that because the api calls are asynchronous you can just use them that way. In practice you need to use them in a synchronous manner e.g. wait for one call to finish before issuing the next. I am not clear if this is by intention of just a buggy implementation but it is the case at the moment.
There are definite issues in the underlying framework / drivers as you can get the system into a state where it want allow Bluetooth to switch off, it want work without switching Bluetooth off and on again, it want work without rebooting your phone, it want work reliably with Wifi enabled. If you go through the bugs list you will find more.
In my opinion it's not at beta standard yet but we have been trying to live with it for the past 9 months and Google look to of stopped working on it as far as I can tell from the updates we have had since the initial release.
I am developing one SIP based application to make and receive a call.I have used shared preference to store the all the registration related data like user-name,password,context etc.This data are also stored in A2billing.And i have used Asterisk Realtime to register sip user in application.
The main issue is that when i am running my application it works fine in all the other devices except Samsung Galaxy S2. On this device SIP user is not get registered and on asterisk console it gives me a error of Wrong password.
I cant configure what the actually issue is because its runs perfectly on other devices except galaxy SII(4.0.3).currently i have tried with HTC phones and galaxy SII(2.3.6) and it worked fine
If you have any idea and suggestion regarding this please share with me so i can workaround with this.
Thanks in Advance
Solved:
Finally the problem is solved when i uninstalled the Avast Antivirus from the device. i think Avast was causing a problem while accessing the data from sharedPrefrences don't know why. yeah but now i need to searched about that about, how do we avoid this kind of problems.
Are you using the native Android SIP stack or your own, linked in your app? If you are using the native one, might be a bug in the firmware. Debug your app and check if it is reading/writing the proper password. Then capture traffic with Wireshark, etc. and check what exactly is being sent over the wire(less). Then compare with traffic from other devices that work. Rinse and repeat until you pinpoint whose fault the error is.
I have an idea for an but I am not sure if it's even possible. I ran into an issue the other day where a phones touch screen was barley working and I needed to get the contacts off of it. I have a cellbrite machine but anyone who has ever used one knows how finicky they can be.
I would love to develop an android app that will connect to any phone via bluetooth and force pull all the contact from it, this would be handy if you have a troublesome screen. My question is this even possible based on the different phone types, and the different level of bluetooth protocols supported on the phones. If anyone has any ideas on how this might be accomplished hat would be great.
Any app with the necessary permission can read a phone's contacts and send them over Bluetooth (or Wi-Fi).
I think the main problem would be that people don't think to install your app until they need it. Then, you can't install your app onto their broken phone unless the phone has a network connection, and if they have a network connection then there isn't really any need to use Bluetooth in the first place.
Actually, one of the basic ideas of Android is that everything on your phone is sync'ed - so you don't have to worry if your phone gets crushed.