I am developing a SIP based application to make and receive a calls. Recently i have tested the application on different devices. first, i have tested with Samsung Galaxy five(2.2) and Samsung Galaxy y(2.3.6),when called both side audio was fine.
But when i have tried with Galaxy y(2.3.6) and Sony XPERIA (4.0.3),there was an one sided voice.Application worked fine with 2.2 and 2.3.6 but while testing with 2.3.6 and 4.0.3 there was an audio issue with ICS.
Anyone have idea about this issue or Had this kind of problem then please give me the some idea about this.
Thanks
EDIT:
I am using codecs in application and i have created the .so file for that codecs. But i have created the .so file for only armeabi processor. And i think in Android 4.0.3 there is an armeabi-v7a. so should i need to create the .so file for armeabi-v7a CPU?
armeabi also runs on armeabi-v7a.
Anyways, the processor type is device dependent and not OS dependent.
You can Have armeabi-v7 even in Gingerbread...
You need to find the exact position of the package/audio-loss.
In SIP-Applications, the error-chain is quite long.
Can you verify with shark if RTP packets are received on both devices even if you got no audio (You need root for running shark/tcpdump om your device)?
Otherwise, try forcing RTp proxy and run wireshark on the proxy.
If packets are transmitted in both directions, check where the packets are lost and they reach the encoder.
Put logs and checks verywhere in the audio-transmission pipeline until you know where they are gone and feed us with more information.
as sebweisgerber states, there are several possible failure points, if the call is properly established but no audio is hear, it should be in audio capturing/playing, audio de/codification or audio transmission. If we take into account that this works in 2.3.6 but not 4.0.3, I would bet for audio capturing/playing or codification.
Are you working with third party libraries for codification? Because, if this libraries are trying to access system's codification libraries, like csipsimple project, most of library names for decoding have changed from Gingerbread to ICS so, this would explain the "one sided" behaviour.
Hope this helps.
Related
I built a very VOIP app for android phones. All i have is a text field that lets a user enter the username of the person they'd like to call. Then when they press call, it will wake up the recipients phone and play a ring tone. The recipient can answer or decline the call.
At the moment the app "almost" works fine on the following devices:
Galaxy Note 1 with OS 4.0.4
GS3 with OS 4.2.2 and 4.3
GS2 with OS 4.0.4
Nexus 4 with OS 4.2.2
Some minor issues I'm having are calls between some GS2 phones (GT-S7530M) to some GS3 phones, where the audio is extremely quiet. I'm not sure why this is, even though we maxed out the volume. Other times, there's plenty of crackling in the calls, or you miss out on people's sentences. We made sure the network speed was always at least 15mbps download and 1.5mbps upload.
Every other phone seems to work fine.
I am using linphone as the sip library for the phone. I am using asterisk as the telephone server. I am using GSM as the codec for the phone and for the asterisk server. I'm pretty sure I'm not doing anything "special" with my code. It's a simple app and I think any experienced Android developer will find my code pretty minimal and simple.
My question is, assuming I correct the issues for the targeted phones above, is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+? Let's assume I want to be able to hit 70% target within a few weeks.
Some of you might think my question is too broad, so I want to make it clear that i'm just looking for a yes or no answer to whether it's realistic or not and the reason for your answer.
The reason I'm asking is because I had an earlier prototype, and I asked some strangers with other phones like Sony Xperia ZL, HTC One etc... and they seemed to have problems getting my app to work correctly. They experienced problems like the ring tone didn't work, or they couldn't receive a call (even though they successfully connected to my asterisk server), or the audio quality was extremely poor. This led me to do a bit more research on the popular problem known as Android Fragmentation. When I saw all the android phones out there, it scared me. Can I really reach 70% of modern android phones running OS 4.x all by myself in the next two weeks? Will this new version that I've created with bug fixes for Note 1, S3, S2 and Nexus 4 work perfectly on the other phones?
It's a very simple app
I long for the day when we can actually describe a custom VOIP app as being simple. It's 2013, and we cannot say that today with any degree of accuracy. IMHO, your app is rather complicated. It just so happens that most of the complicated bits are in a glob of open source code that you did not write (linphone) and a third-party server that you did not write (Asterisk).
It's a simple app and I think any experienced Android developer would find my code pretty minimal and simple
Pretty much all of the symptoms that you have described would either be part of linphone or part of Asterisk, from what I can tell. Your code may be simple, but your app is not.
is it realistic for a single programmer to attempt to make this voip app work on 70% of modern android phones that are running OS 4.x+?
If you remove linphone and Asterisk from the equation -- say, by rewriting your app to play a ringtone based upon an GCM user notification -- your objective seems reasonable.
However, since your app as presently constituted is almost completely linphone and Asterisk ("any experienced Android developer would find my code pretty minimal and simple"), your success is gated by how well linphone works on Android, and how well linphone-on-Android works when communicating with Asterisk.
Hence, the only people who will be able to answer that are those experienced with those technologies. You might try asking on some dedicated linphone and/or Asterisk resources. Or, you might ask fresh StackOverflow questions, with tags appropriate for those technologies, with more focus.
No. Some carriers inflict inanity: sip hostility or not awesome flavors of IPv4 to IPv6.
Currently I am also working on an Android VoIP client.
Actually there is no any difference between the different hardware and OS versions except this audio handling headache.
Unfortunately there are a lot of inconsistencies in the audio implementation by the different vendors. I would suggest you to have a look at some open source SIP softphone source code such as sipdroid, mizudroid and csipsimple. I was learnt a lot especially from sipdroid, although the code is not well commented. Be prepared to a lot of workaround handling each devices differently.
I would like to understand how an application like AlsaMixer or MixGet, mixer widget with alsa is working.
Specially, I would like to develop an application which makes use of the "/etc/asound.conf" which would be available with ALSA.
Has anyone more knowledge on this? How can I "build" ALSA for every Android-device?
I personally have tested those applications on my own Samsung Galaxy Nexus which natively uses "tinyalsa" and on an "HTC Desire" which uses something with "/dev/msm_audio_out" (don't know what this is exactly).
It seems that those apps require root, ok no problem, but they work without larger modifications and on a large range of devices).
Thanks in advance for your help, I've read hundreds over hundreds of docs and found no real informations.
If an Android device
actually uses ALSA drivers; and
is rooted (so that your app can access the device files),
then you could the NDK to access the ALSA libraries.
In that case, ALSA works just like on any other machine.
I am interested in building Android for Source for a Galaxy S3 (but just knowing how to do it in general will be quite helpful)
I know how to do it for all the nexus devices in general, but I was wondering how to do it for some of the other phones. I know that it is possible because CyanogenMod and other modders do it. Usually when they announce them they include the source for the kernel.
How do you put the pieces together? Getting the android source code and the custom kernel together in something that can be flashed.
Generally it is not trivial. You need some binary files for hardware support (camera, WiFi, NFC, etc) and you need to figure out which those are and how to pull them from the device. The kernel is GPL licensed, so the the manufacturer will release their version/patches at some point, but you might have to wait. Then you have to create device build files to put all those together in an image for the particular device. Your best bet is to get CyanogenMod source and see how it is done in practice.
I have developed an Android application which uses JNI (java native interface) for Archos 43.
Had no problems and i was able to run the application smoothly.
Later I tried to run the same application on Samsung I9100G Galaxy S II as well as Samsung I9100 Galaxy S II.
I was able to run the application on I9100G but not on I9100.
The reason being that the JNI part of the application was not supported on I9100.
I did try to get to know the reason for this and was able to find that I9100G uses Ti OMAP 4430 chipset and PowerVR SGX540 as GPU whereas I9100 uses Exynos 4210 chipset and Mali-400MP as GPU.
I suspect that the reason might be the change in chipset (since Archos 43 uses Ti OMAP as well). But any further results couldn't be obtained from my search.
update The application makes use of bluetooth. While trying to connect to a custom hardware(CH), am not able to get any response from the CH when am running the application on I9100. The bluetooth communication part is written using jni.
So my question is whether am not able to run my application with JNI on I9100 because of the chipset and if so why ?
Also a more general question is which devices support Android JNI applications and what are the basic features necessary in a device to run an Android JNI application ?
(I spent a considerable amount of my time trying to find the answers for all these questions and any help will be greatly appreciated.)
Thank You.
All Android devices 'support' JNI, that is how a big part of the OS is implemented: Java services and frameworks using native libraries via JNI. There are, however, different architectures, and if you have a native module, you need to make sure you build one for each architecture you want to support. Even if you are targeting ARM devices only, there are ARMv5 and ARMv7 ones out there. ARMv5 should work on all, but is slower.
Galaxy SII devices probably use the same architecture, so you've hit some other problem/bug. What errors did you get? Post logcat if available. Maybe you are trying to access hardware that is not available on one of the devices? Or link against system libraries that are for some reason missing?
Now that you disclosed that the problem might be related to BT on 2.3.3, it all makes sense. The Android Bluetooth interface before 4.0 was not standartized, and it's most likely that your code is TI OMAP - specific. So, if you want to support other chipsets, you need to communicate to other drivers, or target devices with ICS and higher.
I am trying to develop a BLE bluetooth (SMART) application for Android.
I managed to download the Broadcom BLE SDK, install through the Android SDK Manager as explained on the web site and download the projects examples.
When I tried to push one of the examples into my tests phones (HTC One S, HTC One X both with Bluetooth BLE feature), I am facing the following issue:
INSTALL_FAILED_MISSING_SHARED_LIBRARY
Is there any possibility to include the broadcom library described in the AndroidManifest.xml file ?
<uses-library android:name="com.broadcom.bt.le" android:required="true"/>
Is someone managed to test the broadcom projects examples? And on which phone?
According to this post, a bug has been discovered on Samsung Galaxy S3, but I didn't find any information about HTC products.
UPDATE : What a great news!!!
Last Android version 4.3 (Jelly Bean) now support low-energy Bluetooth Smart accessories.
http://www.android.com/about/jelly-bean/
https://developer.bluetooth.org/Pages/Bluetooth-Android-Developers.aspx
Not sure that every phones will have an update (even the last HTC One M7 for example) but next phones will certainly embed this major release.
The problem is that if your phone doesn't have the .so file installed, this isn't going to help.
And your device will only (as of this writing) have the .so file if Broadcom has blessed the device.
For example, the latest official build (4.0.4) for the reasonably-new Samsung Galaxy Nexus does not.
For those that don't know, there are two different (incompatible) APIs for LOW-ENERGY Bluetooth (BtLE, now apparently called BT Smart). One is from Broadcom, and the other is from Motorola. Unsurprisingly, each only works on a phone that has that vendor's chips in it.
This is a terrible, terrible situation, and Google REALLY needs to get moving on a solution or Android will become totally irrelevant in a little industry known as HEALTHCARE!!!!!
The HTC One X and One S use a Qualcomm Bluetooth chip, not Broadcom. Therefore the Broadcom SDK would not be expected to work. There is an HTC BLE SDK that works with the HTC One X+, Droid DNA, and HTC One that you can sign up for the HTC BLE SDK here:
http://www.htcdev.com/devcenter/opensense-sdk/partner-apis/bluetooth-low-energy/
Confirming BroadCom BLE stack works on HTC 1X+ and cooperates with standard TI KeyFob Demo.
Seems like I'm making a dumb post, but I thought someone might be encouraged to keep going by an unequivocal statement of at least a tiny success.
BleFindMeClient really does work on the HTC 1X+ in conjunction with the TI CC2540-mini Keyfob aka KeyFobDemo in the TI distro.
I've never written an Andoid app., or code for the TI keyfob, so it took me a frustratingly long while to figure out how all the tools worked and how to configure them, but there was no real magic. For me, some of the other Android demos don't compile out the gate without some code tweaks, but that could just be my inexperience.
http://youtu.be/cqWpjU7gJ2Q
On the other issue regarding getDeviceType(), here is a code fragment that works perfectly every time on the HTC 1x+. Hope this helps too.
BluetoothDevice device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE);
if ( BleAdapter.getDeviceType(device) == BleAdapter.DEVICE_TYPE_BLE ) {
...
}
Someone find the solution here.
The three steps to do are :
Do not include in manifest file.
In project Properties → Java Build Path → Libraries → Add external jar, add broadcom ble jar.
In project Properties → Java Build Path → Order and Export, check the included jar in step 2.
Finally, the Broadcom samples projects run, but crash after few seconds due to an unknown virtual method not implemented on HTC (.getDeviceType(), ...)!
It seems that something might be missing on the HTC phones as well. This error means that there is probably a layer of software missing (or malfunctioning) between the BLE hardware and the API. As for today I have only seen BLE kind of working on an the Motorola Razr but it seems to be limited to the heart rate profile (and it does not use the Broadcom API).
If any body writing a app depending on this SDK, there is one line I want to tell
in DeviceDiscovery they call a method getDeviceType which is not defined anywhere in the entire Android JB codebase hence it crashes there only. so if are trying hard to remove the crash, just keep in mind you can not do it if it is crashing in device Discovery event.
What a great news!!!
Last Android version 4.3 (Jelly Bean) now support low-energy Bluetooth Smart accessories.
http://www.android.com/about/jelly-bean/
https://developer.bluetooth.org/Pages/Bluetooth-Android-Developers.aspx
Not sure that every phones will have an update (even the last HTC One M7 for example) but next phones will certainly embed this major release.
Just to clarify, only starting with these currently available HTC devices will you find BLE support:
the HTC One X+, the HTC Droid DNA, and of course the HTC One and upcoming flagship devices. Note that as of 4.3, you should migrate to use the standard official Android BLE API, to support devices pre-4.3 you can use the HTC BLE API. See https://www.htcdev.com/devcenter/opensense-sdk/bluetooth-smart for more info and sample code supporting both APIs.