I am working on an android (and IOS) application, the application plays audio messages without problem. My problem is as follow:
if the mobile is already connected to bluetooth (bluetooth enabled and connected), if then I launch my application and I play an audio file in this case I hear nothing neither on the telephine nor on the bluetooth speaker.
But, if I launch my application and then I activate the bluetooth,then play the audio file, there is no problem, the sound goes out well on my bluetooth speakers.
The solution I used for now is that when I launch my application I disable completely the bluetooth and then I restart it on the onDeviceready (using a plugin cordova) it works fin like that but it is not ideal as solution, it is very annoying for the users that the bluetooth disconnect and reconnect especially when it is the bluetooth of the car.
Does anyone have the same problem and can you help me find another solution.
I use the latest versions of Cordova (7.0.1), android (6.2.3) ...
and I use the plugova cordova-plugin-bluetoothle to restart bluetooth (disable then enable after the launch of the application)
Any Idea please?
Exact same problem here! I'm working on a musical webapp for Android (6.4.0) and iOS (4.5.3) built with Cordova (7.1.0). I use the webaudio API to play sounds. Everything works great on every platforms except in this specific case:
If the bluetooth is enabled and connected before I launch my App there is no sounds at all playing. This problem occurs only on Android. On some model/type of Android devices it works, on some others it doesn't... Example:
Samsung J3 (Android v5.1.1) = no sounds playing
LENOVO TB2 (Android v5.1.1) = no sounds playing
HUAWEI VTR (Android v7.0) = no sounds playing
LG G6 (Android v7.0) = it works like a charm!
Unfortunately I didn't find any 'clean' solutions yet. I do the same than yours (BT=bluetooth):
force to disable BT if this one is connected,
reload the entire page,
re-connect the BT.
The only hint I found during my tests is about an attribute into the AudioContext object. The AudioContext object has a attribute called baseLatency. The official DOC isn't really clear about it:
This represents the number of seconds of processing latency incurred by the AudioContext passing the audio from the AudioDestinationNode to the audio subsystem [...]
What I understood is that this property give you an estimation (in seconds) of the time/delay needed by AudioContext to bring a sound to his destination...
Right after the AudioContext has been initialized in your code, you can ask for this baseLatency (read-only property):
var context = new AudioContext();
console.log(context.baseLatency);// 0.008 for example
What I noticed during my tests, is that this baseLatency is always higher than 0.2 everytime the problem occurs.
Example with bluetooth DISabled:
// baseLatency on computer = 0.008
// baseLatency on iOS devices = 0.05
// baseLatency on Android devices = 0.05
Example with bluetooth ENabled:
// baseLatency on computer = 0.008 (same)
// baseLatency on iOS devices = 0.05 (same)
// baseLatency on (some) Android devices = 0.2 (HIGHER)
Well, I did this test hundreds times, each times the same result. If BT is enabled before you launch the App on some Androids devices, the baseLatency will be higher than 0.2 meaning the AudioContext won't be able to play any sounds in your app. This is not a solution I know, but that can helps a little by letting you know for sure if the App will play sounds or not.
I tried to re-initialize the AudioContext object, but this doesn't works at all... the baseLatency stay the same even if you reconstruct the AudioContext object.
I hope this tiny hint could help us to find a solution!
Related
I'm using libVLC in my Android app to stream video over rtsp from the camera that I'm connected to over WiFi.
In general, streaming works fine, but there seems to be streaming problem if I'm connected do the camera by WiFi (that provides no internet) and also have got mobile data turned on. I use bindProcessToNetwork to make sure that the streaming is done via my WiFi network. On some devices (like Huawei Mate 10 with Android 9) the streaming works ok (it seems to use WiFi and ignore having mobile data on), but on other devices (like Samsung Note 10 with Android 10) when I use new networking API it seems that VLC is trying to connect via the mobile data, and only after some time when it fails it decides to use my camera's WiFi (despite the fact that I used bindProcessToNetwork).
I get an error log
VLC-std: Unable to determine our source address: This computer has an invalid IP address: 0.0.0.0
Suprisingly, it works fine if I connect to my WiFi from the system settings...
I found some comments that media streaming is done in a separate process, and it ignores calling to bindProcessToNetwork but on some devices (and Android versions) is seems to work and on others it does not.
I already asked this question on the Videolan forum, but with no luck.
Is there a way to force libVLC to stream using a specified network?
I don't think LibVLC can do this, and it's a bit out of scope of a multimedia framework.
I would handle this on the app side if I were you, using something like How do I connect to a specific Wi-Fi network in Android programmatically?
I want to use an audio capture feature at my app. I followed this link at developer.android.com.
I'm using Android Studio 1.4 and a Nexus 5 with Api21 as virtual device. At developer.android it is descripted that it's not possible to use the audio capture feature with an simulator:
Note: The Android Emulator does not have the ability to capture audio, but actual devices are likely to provide these capabilities.
But is this an information that is up to date? I'm able to use the record button but the activity crashes after pressing stop. I can see the audiorecordtest.3gp file on the simulated device and if I save it to my computer I can play my recorded audio. The crash comes without any shown exception. If I ask for
context.getPackageManager().hasSystemFeature(PackageManager.FEATURE_MICROPHONE);
I got back a true. It seems like the simulator is able to capture audio but can't handle correctly the stopping of it? Is there a way to get around?
One aspect of Tamper Checking involves testing for an Emulator running your app...
In THIS article (Paragraph 4.1), Emulator detection is described... The tests detect many emulators, but throw some "false positives", depending on the device.
False positives render some emulator test's, described in the article, not appropriate for production, but are fine in a test environment where you know your devices and their test responses.
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 currently developing a mobile application that is all about very short sound recordings and for the time sake I decided to build it with Cordova (not Phonegap). Unfortunately today I have been fighting with the actual sound recording on my Nexus 5.
I am using the Cordova media-capture plugin, The code currently running is exactly the code from their documentation.
On older device, everything runs great. On my Nexus 5 though, when I click on button to record audio, it just returns error code number 3 (No media files recorded) even without opening the audio recorder. I thought it might be problem with new Android, but on simulator it runs fine. I also thought that somehow it could be connected to that I cannot find any audio recording app on my device, so I installed one and still nothing.
Then I thought maybe I am doing something wrong, so I installed this app: https://github.com/Icenium/sample-capture and the same problem.
There has been some advice around here to update the Capture Java file, which I did and still didn't help. What can I try next?
This is because there is no application installed, by default, to handle the intent (as explained above by others).
Try installing an application that handles that intent. For example I used this one:
https://play.google.com/store/apps/details?id=com.brightattic.soundrecorder&hl=en
(Please note I offer no endorsement of the app other than it worked to prove that the problem was a lack of sound recorder app).
Maybe try to set the targetsdk to 18 instead of 19 in androidmanifest.xml (and of course be sure to have installed api 18 in android sdk manager).
This should force the new kitkat chrome webview to operate in quirk mode and behave like the webview in jellybean.
I had the same issue, running adb logcat is useful:
W/System.err(22102): android.content.ActivityNotFoundException: No Activity found to handle Intent { act=android.provider.MediaStore.RECORD_SOUND }
...
D/CordovaLog(22102): file:///android_asset/www/js/index.js: Line 77 : Capture ERROR: {"message":"Canceled.","code":3}
For me the problem is that Nexus 5 (android 4.4.2) doesn't handle the Intent, i.e. doesn't seem to have a default audio recorder.
On devices which do have a default audio recorder, you might see this error if that application doesn't include a receiver for RECORD_SOUND..
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.