As discussed in other posts, most Android devices don't support recording calls.
Recording AudioSource.VOICE_CALL does though work fine on my Samsung Galaxy S2.
Does anyone know if supporting this is Google's new trend, or it's just a feature specific to SGS2?
I don't believe that Google is moving towards recording voice calls. In fact, I think they are probably working on ways not to allow this due to large security issues. Speaking of which, some recent news that happened a few days ago reports of such security flaws. I don't think that using AudioSource.VOICE_CALL was meant to be used in this way. Hope this answered your question.
Update: News link from 2011 is unfortunately broken now. Sorry about that.
Google doesn't have any control over this (unless they start mandating that devices must / mustn't support voice call recording in their Compatibility Definition Document).They have provided a way for applications to request the voice call audio by adding the VOICE_CALL AudioSource, but the actual implementation of this feature is platform-specific and is handled by the platform vendors and OEMs.
It may, however, be the case that you see more platforms having support for this feature now than you did back in 2011 (or 2010, since it takes a while for new platforms to appear on the market in consumer products).
I've worked with about half a dozen different mobile platforms over the last couple of years. Of these, every single one has had support for recording voice calls, although on two of them the software support was unfinished.
TL;DR: No, it's not an SG2-specific feature, but it's also not universally supported. And it doesn't really have anything to do with Google.
Related
Does anyone know if any of the latest smartphones provide a audio line-in support?
Am aware that this question has been addressed earlier as well but it has been a while since the last query on this and also the smartphones has evolved so much.
For the sake of completion, I will answer my own query. After googling for few days, I conclude that none of the existing Android phones in the market provide line-in support. This is more of a hardware restriction.
Line stereo/2-channel recording has detailed explanation.
I'm writing an app for which the camera is an essential feature. In this regard I want to be 100% certain about the following aspects:
If I use the deprecated camera: will the app still run on all APIs
now?
If 1) is yes: At what point in time this app will not run
anymore on all APIs (my app shall cover minimum API 17) ?
Where can I find updated official information about 2), i.e. what is planned and by when?
Say, I would use the new camera2 already now, my understanding is that the app would
not run on any API below 21 - correct?
My working hypothesis from the information I got so far is: NOW still use the the deprecated Camera. But Keep watching market shares of APIs and start learning camera2 soon, in order to be ready to switch the app to camera2 within the next 2-3 years. Do you agree?
In any case, the use of a device's camera and making it run on virtually all targeted devices is tricky enough (as for now I am happy to have mastered the "old" Camera...). Therefore, I really want to be sure about the above points. Many thanks for your answers.
If I use the deprecated camera: will the app still run on all APIs now?
Yes.
At what point in time this app will not run anymore on all APIs (my app shall cover minimum API 17) ?
Build a time machine, go into the future, find out, and let the rest of us know.
IOW, we have no way of predicting if and when Google might discontinue this API entirely. That being said, they almost never discontinue APIs.
Where can I find updated official information about 2), i.e. what is planned and by when?
Get a job with Google, or go with the aforementioned time machine option. Google is not in the habit of announcing plans in advance, and their time machine is not available for rental.
(though Elon Musk probably has a Tesla outfitted with a Mr. Fusion, so you could reach out to him...)
I would use the new camera2 already now, my understanding is that the app would not run on any API below 21 - correct?
Correct.
NOW still use the the deprecated Camera. But Keep watching market shares of APIs and start learning camera2 soon, in order to be ready to switch the app to camera2 within the next 2-3 years. Do you agree?
No, for reasons I will clarify after your next quote.
the use of a device's camera and making it run on virtually all targeted devices is tricky enough
Part of that trickiness is the fact that device manufacturers have camera implementations that might be generously described as "quirky".
The problem with sticking with the old camera API exclusively is that I expect quality control on that API to steadily decline. What limited resources device manufacturers have for cameras primarily will be devoted to the new API.
Hence, my recommendation is to use both APIs: using camera2 where possible and falling back to the original API where needed. Admittedly, this requires substantially more work. If you are not in position to do that work, then you have no choice but to stick with the original camera API until such time as you are ready to have your minSdkVersion be 21+.
Google Just announced CameraX, a API wrapping camera and camera2. This new support API tries to eliminate the quirks each manufacturer added to for our enyojment.
Check it out: https://developer.android.com/training/camerax
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 am trying to write an android application that uses several of the android apis(like policy manager, package manager, wifi apis etc).
The concern i have is, android being open, manufacturers/carriers are free to take any specific version of android as their start point and customize the same and ship it with the device.
Note:Please excuse me if this post is in anyway a repeat of earlier posts on the same/similar topic. In such a case, appreciate anyone sharing the earlier post.
Few things that bother me are:
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
how do i ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know these are some naive questions for many of you who may have been on android for a while, but any pointers in this regard would be of immense help.
Any other information in general w.r.t cross version, cross device incompatibilities and strategies to deal with them would be very helpful.
Thanks a lot in advance.
Regards,
Deepak
Your concerns (and many other developers) are addressed by: http://source.android.com/compatibility/index.html
But this still does not guarantee that manufacturer will not change API and break your application.
The common approach is to initially target subset of devices that make up large percentage of market and then implement workaround for other devices (if necessary). Sample info about device market penetration can be found at:
http://opensignalmaps.com/reports/fragmentation.php?
Kind regards,
Bo
First off, I don't believe you should need to worry about this. Only after you have thousands of users will you end up needing to face the more complex issues caused by the great number of manufacturers offering Android devices. This should not discourage you from developing for Android.
Does android enforce/require manufacturers/carriers to retain the default apis and only over-ride/customize the look-and-feel?
No. But it would certainly work against them if they remove important APIs from the system. The core exists as a whole, though there really isn't anything preventing them from removing or disabling chunks as they wish. For example, AT&T had disabled the ability to sideload apps on Android devices some time ago (but I don't think they still do that). An example of a device with reduced functionality: Amazon Kindle Fire. It doesn't at all look like Android in the majority of its interfaces (except within third-party apps) and it doesn't offer the complete API set. Even with those dramatic changes, Android app developers still have great success building and selling apps that run well on the Kindle Fire.
Even if manufacturers change the implementation/behavior of the basic apis that comes from android, do they adhere to the interfaces so that my code doesnt break?
That's the idea, but there isn't anything in place to forbid them from breaking things. Nor is there anything that will keep them from introducing bugs accidentally.
How do I ensure/test that my code works on all of the android devices since there is a possibility that one or more customizations could break my whole application?
I know that some manufacturers will offer an emulator for their devices/configurations to help test against their systems. For example, Motorola offers MOTODEV Studio for this purpose.
I've been working on a project that would greatly benefit from call-stream modification. This has been repeatedly said/assumed to be unachievable, as most people believe that the hardware loop for the in-call audio is completely disconnected from the main MCU of the device.
Questions like Stream audio to a phone call Android have received answers stating that it is impossible to access the audio. I agree that this is definitely impossible from the Android API, but it is completely unclear whether the hardware ACTUALLY is disconnected completely.
The stackoverflow user 'artsylar' said that they were able to modify the 'framework layer' of Android OS to inject recorded audio into call streams, which would be a huge step forward (see Play an audio clip onto an ongoing call, artsylar's comment on the selected answer). Assuming artsylar's success is valid, there definitely is a way to control the call stream audio by modifying the framework (I assume the telephony base framework in the Android source).
Basically, I completely agree that modifying or controlling the call-stream is impossible from the application layer. However, I am interested in customizing the Android OS in framework or Radio Interface Layer; artsylar seems to have had success, but there is no explanation in open-literature on how. Given the current state of Android technology, could anyone clarify the above to actually establish whether controlling call audio is possible by modifying the core Android OS, and a good path to accomplish this goal?
I believe that a final clarification on this issue would be of great value to the open-source community.
Thanks!
It's technically possible to inject audio into the voice call uplink on some platforms (Qualcomm's MSM8960 and APQ8064, for example). Support exists at the hardware level and at the device driver level. But to make that functionality available to normal applications you'd have to create a custom Android ROM where you've added all the necessary user-space parts in both the Java layers and native layers of Android.
So the short answer is: no, there's no standard way of doing this as an app developer (doesn't matter if you use the SDK or NDK).
If you're working for an OEM or by some other means are able to build and flash your own Android ROMs you can probably get the information you need by asking your platform vendor.
It is very difficult to do so because it relates to handling the Linux Kernal inside the Android OS.
Not only is there no API support , but also the security issue is not allowed to do so.
As being a professional in the software engineering field especially the programmers, we
never assume anyone's success on invention and the related project is valid until the project is being tested.
Also streaming the audio during the call may invoke the issue of privacy and security issue among the smartphone users and the service provider of telephony