Overview:
We have developed an app that allows customers check in using an NFC enabled card with a stationary Nexus S. The app sit ready to read a card, when a card is tapped, the app reads the unique ID for the NFC card.
Problem:
The challenge we have run into, is that the Nexus S locks up after scanning 50 to 100 tags. The app continues to function, and so does android, however neither our app, or the native app within android will read a tag. It is as though the scanner has been disabled. I have tested it using 4 different Nexus S devices running Android 2.3.6.
Debugging:
The only solution I have been able to find is to either:
- power the nexus s off and then power it back on
- disable NFC and then re-enable it through Setting --> Wireless & network settings --> NFC
If either of those are done, the scanner works again and app continues to work as normal until it locks up again after 70 or so scans.
Any idea how to fix this bug, or work around the issue?
Update: it appears as though this is not just with our app, testing the "Tags" native app that comes with the Nexus S also has this issue.
We have experienced the same issue with our NFC apps. Seems to be a hardware issue. We have done the same thing you are doing by re-enabling NFC in settings.
Unfortunately I don't think it's your problem so you may have to report the issue directly to Samsung or Google via Samsung Tech Support or a Google Android bug report.
Another thing to do is to see how the tag recognition works with the new Galaxy Nexus when it gets released in the next 2 weeks.
Related
I've developed an Android app for remote controlling some special hardware devices. The communication is done via udp and wifi. The app already runs on ~60k devices without any problems but since the rollout of Android 6 I'm getting more and more reports from users who get some strange errors:
Usually the app searches for the hardware with a broadcast package. The app then requests all data from the hardware to stay in sync (~4000 packages in both directions). This sync process is heavily tested with all wifi conditions possible and does work as intended (also on Android 6).
User with a Samsung device and Android 6 are now having the issue, that the sync is unable to complete (no reply from the hardware within 20 seconds). The odd thing is that the broadcast search does work just fine, as well as the beginning of the sync. Usually the timeout happens when 5-15% of the sync was completed.
As I have no idea what could cause this issue I wanted to ask if there is any known problems with Samsung / Android 6 and udp communication via wifi?
Also were there any other changes on the network stack in Android 6 that could cause this issue? On my test devices (HTC mostly) everything runs fine so I'm currently out of ideas.
Edit:
I narrowed the issue down to the following devices:
Samsung Galaxy 6
Samsung Galaxy 6 Edge
Samsung Galaxy Note 5
Edit 2:
I got a Samsung Galaxy 6 device for testing purposes and of course it does work for me. I also tried all sorts of network setup, power saving, anti virus and general settings combination but it's just working all the time.
Edit 3:
After getting some Galaxy S5 and S6 test devices I was not able to reproduce the problem. Comparing the ROM version I found out that these devices all have a newer rom than the devices which got the issues.
Turns out that Samsung simply broke something in their wifi stack which causes the wifi to stop working properly after some udp packages. So only fix for this issue is to wait and hope they fix it in all countries soon.
Would a Bluetooth LE Jedi know any trick how to get a reliable BLE scanning mode on cheap Android 4.4 devices ?
Everything works fine from Android 5 to 6, and most of the Android 4.4 phones...
However, on some cheap phones with 4.4 we encounter random issues, some phones do not detect anything, or sometimes just a few beacons among others, depending on environment, daytime, weather, or whatever... It's obviously due to a poor software or hardware on this side, but is there any trick to make it more stable programmatically ? (for example enabling / disabling Bluetooth regularly)
EDIT
To describe a typical behavior:
First, note that it is the exact same behavior with all scanning Apps I could test (Estimote, Kontakt.io, AltBeacon, etc. etc.) - so this is much probably not a matter of App implementation.
It occurs only below Android 5 (4.4.2, 4.4.3, 4.4.4) and on cheap devices, never on phones like a Samsung S5 for example.
The behavior: let's assume we have 5 beacons very close (less than 2 meters, all working fine).
- Once rebooted the phone finds 5 beacons for 1 or 2 minutes.
- Then it finds nothing for 5 minutes.
- After a refresh it finds 2 beacons.
- Another refresh of the scan: only 1 found. Then none... etc.
I could not find any logic, for now it looks erratic.
Enabling / disabling Wifi / Bluetooth, Bluetooth+Wifi, Wifi then Bluetooth, etc. make sometimes the scan find one more beacon, sometimes not... there is probably not much difference if I just wait without changing those params.
The only way to get back a reliable scan is to reboot the device... then it works only for 1 or 2 minutes again...
It occurs on some very different devices (a Wiko Sunset, a Samsung XCover, an Orange Roya).
On more recent devices (Nexus 6, Samsung S5, Samsung A4...), 100% of the beacons are detected, for hours, and never lost.
So, as the complete reboot is actually the best solution to get all beacons detected I was wondering if there is a way to "refresh" the device's Bluetooth module without rebooting it... Or if we just have to become a philosopher about this ;-)
if you are develop your application using node.js then there are many api's avaliable which may work for you.But in case of android it is totally depend on your android version
I'm currently trying to use a smartwatch LG G Watch R (fully updated) as a Beacon Scanner.
The Beacons are made by Estimote, so I'm using its SDK.
Using the smartphone I have no problem at all, but with the smartwatch I receive the signal from the beacons every 5 seconds despite having set both on the app and on the beacons the advertising time at 325ms.
The code is basically the same used on the smartphone.
Any ideas?
I don't know about the LG watch, but I realized similar behavior with other devices, like the Moto G2 for example. Even though the code is exactly the same, different devices handle it differently. It might be due to different chipsets used or how they are implemented.
Go to the logcat (without filtering the app) and look at the times when scans are started, stopped and when results are received. You might see that the scan process makes random "breaks" for no visible reason. Maybe it's the same issue with your watch.
Unfortunately I don't know about a solution.
I am working on an Android application that uses Bluetooth to communicate with a nearby PC.
The app works greatly on my own device (Samsung Galaxy Note 3 - CM 12.1) but on of my beta-testers it does not.
Simply put the app allows people to write and receive SMS from their
PC (with my C# WPF app) via Bluetooth & their phone.
My beta-tester is using a Samsung Galaxy Note 4 stock ROM (Lollipop).
At first I thought when his screens turned off, Android would kill the MainActivity which holds on a few threads including the one maintaining the connection alive (with a inpustream.read() blocking method). Such behavior does not occur on my own device : I could keep the connection alive for a whole night without plugging my phone.
I was warned, though, that using services would avoid such problem because Android does not behave the same way from one device to another. So I updated my app and made my MainActivity use my MainService to spawn the relative threads. But it did not change a thing.
As my title suggests, the problem lies with his antivirus and more precisely : AVG.
I have no knowledge on how such antivirus work on Android and I don't even use one. By freezing AVG with Titanium Backup on his rooted Galaxy Note 4, my app stopepd crashing and is now working perfectly well as intended.
So I wonder, how come AVG deciced to kill my app when the device screen turned off?
How should my app behave so that this won't happen with any other users using AVG or any other antivirus ? What should I do so that my app does not look as a suspect ?
I don't know exactly what the AVG did to your app.But I think that AVG may don't let your app force to turn on the bluetooth or use the Bluetooth when Android device is sleep or send/receive SMS.The AVG is one kind of antivirus apps that most of them have lots of permission request limited or power saving strategy,especially on rooted Android devices or the first part app already in the Android ROMs.
Try to make clear that what's the real point AVG did to your app.And then try to solve your problems with gentle and smart.
For example：
1.If the AVG doesn't let you use BluetoothAdapter.enable() to force to turn on the Bluetooth, try to use Activity.startActivityForResult() to let users to choose whether turn on Bleutooth or not.
2.If the AVG doesn't let you use Bluetooth when the Android device is sleep.You can try to use WakeLock.acquire() to hold the Android device.
3.If the AVG doesn't let you use SMS sending or receiving.You can changed another communication protocol, SPP or BLE or something else.
Maybe you have heard Xiaomi.If you are an Android Developer in China,because Xiaomi is very popular in China,you must deal with the adaption with Xiaomi,and then you will find that Xiaomi is really fucking for Android Developers in China.
Xiaomi doesn't some really amazing things to the original Android.For example:
1.
AlertDialog..getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
you can't alert the TYPE_SYSTEM_ALERT dialog on some xiaomi ROMs that they tell you nothing.
2.Xiaomi has modified lots of original themes.
3.Xiaomi has changed the Android alarm timing mechanism while the device is sleep which is called Wake-Up-Alignment.This is really terrible for the apps that with the function of timing.
The above problems are that I met in Android development, some problems I can resolve it, some you don't have any chances to change it.
Remember that:The adaption with Android devices is that you must make your users know you app works on most of the popular Android Devices,the developers try to make the app run on most Android devices,but it maybe not work on some Android devivces with customized ROMs or with some special third part apps.That's it ,that's true, that's Android.
If the problem can't be solved,it's not a problem!
I am trying to recreate an issue which is only caused on HTC One XL phone running Android 4.2.2. It is a styling issue which can be fixed with CSS. The problem is that the Chrome Developers Tool does not have a profile for HTC One XL phone running Android 4.2.2.
I do not have a real device! How can I test for an issue that only exists on particular phone running a particular Android version?
FInd someone with the device to test a beta or debug info gathering build. There's three reasons one particular device has issues.
1)Hardware problem. No emulator will solve this as they won't perfectly emulate hardware.
2)Software bug on this device's framework. Since each OEM ships their own set of patches, there's no way to know what is actually running, except for having the device.
3)Something weird in the system of an individual user. Some odd combo of software, hardware, and data. You need that actual phone to fix this, but it generally only effects a handful of users.
But none of these are solvable without access to the device, or a real Eureka moment. More logging helps, but you'd still need to get those logs which requires a device.