My goal is to develop an Android app to record telephone call audio (incoming and outgoing calls). Not VoIP, not SIP, not anything else.
IMPORTANT: I will not create an app that relies on workarounds, rooting devices and/or hack it in any way, shape or form.
Surely enough, I also expect to sell this app on Google Play store. In other words: all by the book.
As far as I learned from the documentation (https://developer.android.com), the way to capture phone call audio is by using MediaRecorder with audioSource set to VOICE_CALL. This audio source requires permission "android.permission.CAPTURE_AUDIO_OUTPUT", which in turn is "reserved for use by system components and is not available to third-party applications.".
On the other hand, I also did my research in forums like this. Unfortunately and recpectfully, all of the "solutions" were, in fact, workarounds. Other than that I have found some people stating that the lack of API support was deliberately by design and that kind of app functionality is forbidden by Google. Though, no official references were provided to support those claims.
At this point, looks like it can't be done.
Before giving up, I would like to ask the following:
If It's really by design and forbidden to record phone calls, could you point out where, exactly, in some official documentation and/or some reliable source (like... android team, for instance) that explicitly validates those claims?
Kind regards,
Juan Soria
Related
First things first, I am writing this question after researching quite a bit.
Broader View of the issue
In this day and age, we require a more reliable way to perform peer-to-peer communication, preferably using technologies like NFC.
I mean we are in the year 2018 and I cannot believe that there isn't reliable means to communicate peer-peer between and ios and an android. I am talking about offline, close proximity/range communication, which can open up a new world of possibilities for mobile apps. Many of the apps we use to communicate with other devices require one or more of internet, login, credentials/authentication, etc. I am making this effort because most of the readers/users/developers do not actually know what has changed in 2018, so if anythings changed, I would love to hear it!
Hindrances
IOS has very weak NFC support, functionality-wise..?
IOS doesn't support Android Beam.
Not enough members are bothered to fix this or are helpless.
IOS doesn't support non-ios Bluetooth connection? (Doubt it/Tried but failed)
What I need
Efficient cross platform solution for communication between two different mobile devices preferably offline.
A way to send and receive money other than Apple Pay/GPay/Samsung Pay/iMessage/AndroidMessages, such as over NFC/Bluetooth preferably offline mutually, but connected to internet independently.
A way to automatically send data when two devices (different platforms and within ios) are in close proximity, without the need to login or register or any other steps. At least a way to trigger something upon nearing one device from the other, like NFC basically.
What I have
Working android application that uses android Beam to send and receive ndef messages, which is easy to do, between two android devices. So we can make the payment happen here in this case.
Questions arise when we try to proceed with android -> ios or vice versa.
I have read a lot of related questions where the answer is outright NO. However, am not taking time to write this question to be told it's not possible. I want the crowd here on stack overflow to help me find a way to workaround this situation. I know it is a lot to ask, but I feel this invention or discovery will help man app developers stuck in this same zone. This question should be answerable by someone who is ideally in the Fintech domain, and is an IOS developer or mobile developer, with working knowledge of card emulation, secure element, ios 11+ or ios 12 development, NFC, NFC tags, etc.
Questions/Ideas:
Can we use the secure element and NFC Tag with ios 12 or ios 11+ libraries to simulate this required functionality?
Does any third-party library get close to having the ios/iphone act like a NFC writer?
Can we simulate NFC writer for ios?
Can I simulate a tag on android device, have the iphone read it(do not want the apple pay popup somehow) and then follow through the next workflow via the internet? For example, if I had a sender and receiver (payments), since android supports a lot more than ios, can I simulate something on android so that either the apple pay thinks am a terminal of sorts and pays me electronically (securely of course), or at the least can I read apple pay credentials of sorts and simulate a terminal and accept a payment from ios on android?
Something on these lines, I know its not very clear, though I am trying to be clear and simple.
Suggested by others and why it is not a great solution:
WebRTC - Needs internet
alljoyn - Need only 2 device not 2+ and no need for server or client setup.
Relay Server not quite sure is offline or works
android-ios-peer-to-peer-architecture question talks a lot about it as well!
developing-mobile-p2p-payment-apps question, which seems to be relevant has NO answer.
why-android-ios11-cannot-communicate-via-nfc question talks about React Native. I for one have looked at PhoneGap and Nativescript which just have the same level of support for ios. In short, it won't work.
Any I left out, in short no solution.
Comments:
//Due to the fact that there is no solution, I feel even more motivated to post this question. I feel we should come together as one and fight for this right. I mean usually seemingly impossible questions are answered here, so I figured you guys could take this as a challenge. The challenge would be to find a legal loophole, an ethical approach, nothing unethical of sorts. So let me know if we can arrive at any positive conclusion! Thank you for being patient.
//I have read the rules and "do not ask" section, so I would just request moderators to check if there *can* be any answer before you flag it or take it down, by which I mean we just need one correct answer, and it can come from anyone or anywhere.
I am pleased to reveal that there has been demand for this and Google has released Nearby API as early as 2016. This is the way to move forward. This is a device independent API.
Please checkout Monzo Bank's Nearby Pay
Google and others claim it works with Ios as well.
It has been around since 2-3 years, which means there should be good support and documentation, though I might be wrong.
I hope this answer paves the way for others in my position! Good Luck!
In the latest update to Glass, Google dropped the Hangouts feature. Since the Glass development kit is fairly new does anyone know of any API available to do a video chat using Glass?
Any inputs will be appreciated. At present I am planning to use SIP as done in Android. Can the same be applied to Glass?
This is what they said on the Google + page:
Video calls – We hold ourselves to high standards for the features
that we build, and video calls aren’t living up to these standards.
Explorers have told us so directly, and fewer than 10% of them use
video calls. For this reason, we’ve made the hard decision to remove
video calls from Glass until the experience is better. We don’t know
when that will be, but in the meantime, keep an eye on MyGlass as more
Glassware is built and released – we’re already seeing the developer
community work on other video streaming services. We’ve always said
that feedback from Explorers shapes Glass, and this is no exception.
I think your SIP approach is the way to go for now.
I'm checking Twilio as a framework for VoIP calls we would like to integrate into our mobile application (Android and iOS).
I've gone over the Android tutorial and documentation, and so far it seems awesome.
One important requirement we have, though, is that the voice media streaming is encrypted.
I couldn't find anything about it in the documentation.
Anyone knows what the current situation and future plans on this subject are?
Thanks,
Yoram
They don't encrypt the data (that would require them to use SRTP, which they don't)
you can see https://www.twilio.com/docs/sip/sip-security for the Sip Security Best Practices, they offer SIP over TLS though, to prevent anyone from seeing your SIP messages, but from what I've read, the audio frames are not encrypted.
I'm looking to get access to get low level network information on an android device that isn't available through the api. Is there a way to talk to the RIL to get more information?
Yes. I'm actually messing around that same thing. My hardware uses GSM radio and everything turns around the android internal API. (do a stackoverflow search with "[android] internal API" and you will get tons of info on how to access it). In my case, I'm interested in the data link over the GSM. So, it's in android source code in frameworks/base/telephony/java/com/android/internal/telephony/DataConnectionTracker.java. If you are interested in other features like SMS, SIM cards, voice call or anything that is not available on the standard "public" API, look in the folders frameworks/base/telephony/java/com/android/internal/telephony and the names are pretty relevant to what it does. As for a clear documentation, I did not find it. I think it's not publish since it is not recommended to use the internal APIs because it could change without notice and there is no guaranty an internal API will not change in the next Android version.
What opportunities are there for regular app developers (with that I mean, you're not a million dollar content producing company or distribution channel provider, but a regular, small app development company) to secure video/audio content for the app from being saved/distributed.
I mention the 'regular developer', because I had seen in the Android core code that Sony had added some code portions into it, in the DRM packages. Let's assume we're not that powerful to talk to Google to include such in their core code.
Are there any real secure ways to protect video/audio (as part of an app) on Android.
Assumptions (correct me if I'm wrong):
devices could be rooted by the users, need to be aware of that
detection whether a device is rooted or not (within an app) is not really possible on Android, as a super user can basically fake any state of the device.
we cannot modify any hardware or the user's system (meaning: we don't bundle our app product with a device, the app should be available as a 'regular' app on the App Market for download)
the media files/stream could be locally on the device or come remotely from a server, both is ok
I have researched this topic quite a bit, googled a lot, went through (hopefully) all related questions here on SO, I have talked to one DRM provider (which is really hard to get in touch with as a small company or freelance developer, or at least to get some real relevant information, technical docs and details).
I looked into DRM as one approach, but "security-by-obscurity" does not seem to be a very good way. Besides, I haven't found any information or real solutions/APIs for regular developers.
Public-key encryption was another idea, but where to store the private key really safely? Furthermore, I assume that in such case, the entire media framework & player would need to be rewritten, in order to pass a secure video stream to the player. Or am I mistaken?
I would like to get some opinions from other experienced developers in the field, as it's really hard to find information about media content protection for Android anywhere.
Update:
In the context of my question, I found this Question and it's update interesting: Streaming to the Android MediaPlayer
Are there any real secure ways to protect video/audio (as part of an app) on Android.
If by "secure", you mean "fullproof", then no. See Analog hole.
detection whether a device is rooted or not (within an app) is not really possible on Android
Nor is it possible anywhere. the laws of the universe make it impossible to detect such a thing, (okay, maybe you could exploit quantum physics for this, but even then I'm not sure) you can only add code to detect known techniques, all of which are trivial to bypass.
Public-key encryption was another idea, but where to store the private key really safely?
There is nowhere to store it safely. Think about it, you want to encrypt content and give the user the key to decrypt it (so he can watch it), but you don't want him to be able to decrypt it (so he can't copy it). This is a contradiction.
The most you can do is encrypt your stream to prevent the user from being able to just intercept it and use it. Then obfuscate the code that decodes/plays the stream. Though by implementing that you risk introducing more bugs (and worse performance), making the legitimate user's experience worse. If decide not to roll your own obfuscation, and use some automatic obfuscater product already available by some big company, it will already be generically cracked, and it will be extremely easy for someone who hardly knows what he's doing to crack your product in a small amount of time. As long as your product becomes remotely popular, one person is going to crack it and upload all the videos to torrent, then everyone will be able to pirate your product without doing any work.
I don't think there is a solution to protect media content in apps from being ripped off. DRM is of course not suitable for regular developer. I don't see also why public key can help.