Is there any way to identify that a Voip conversation is happening in android?
I have an app that needs to know whether any conversation is happening now through Voip. Never mind if it's Skype, Viber, WhatsApp or whatever.
I know that there are many different protocols for Voip, some of them proprietary. But I wonder if there is some clever way to do it.
Profile the bandwidth.
Find an API that lets you monitor incoming/outgoing bandwidth on a per-application basis (I don't know android but this is possible in windows and unix)
Check each application and write heuristics to classify their bandwidth usage
VOIP will have significant pattern, You'll have to watch it, but it will intuitively look similar to this
consistent amount of data being sent or received (note: test this with several VOIP solutions, and scale it - compression may vary)
usually doing mostly sending and mostly receiving (one side talks at once while the other just sends Acks)
sending and receiving swaps at a known interval (like a conversation)
maybe write a neural network if you have hundreds of recordings of conversations/non-conversations/borderline to train it with.
Etc ... you get the idea. Google 'detect a conversation' for more (couple good studies near the top). Note these portend access to the data stream; you will only be able to see data usage unless the VOIP is stupid enough not to encrypt or somehow let you MITM them.
Notes:
if something other than a conversation is going on, or there is noise, this may fail
no program has to identify itself as VOIP. Assuming you're monitoring employees they could download something obscure or bespoke to fool you. And data should be encrypted. So this is your only hope.
Possible to fool this by faking sending extra data. Not likely ... why would a program waste bandwidth?
If the users want to fool you into thinking they are talking - e.g., they are your telemarketers - why not mandate what they use? You would probably want to anyway so you can record for legal purposes.
Here is the code that will give current running application
ActivityManager manager = (ActivityManager)mContext.getSystemService(Context.ACTIVITY_SERVICE);
List<ActivityManager.RunningAppProcessInfo> tasks = manager.getRunningAppProcesses();
Log.i("current_running_app",tasks.get(0).processName);
You can detect incoming calls using this:
http://karanbalkar.com/2014/02/detect-incoming-call-and-call-hangup-event-in-android/
I also found another SO answer that maybe can help you:
https://stackoverflow.com/a/22904362/1723525
Using the SipAudioCall.Listener
Related
I know this is some sort of pattern question and had lots of reviews but I am here for something slightly different. In the world generally there are 3 main types of APIS which provide these functions:
QuickBlox, Sinch and PubNub.
I do not want use any of them. They are purely horrible for me. Now each of them separately.
1) QuickBlox - Setting its API is already a huge headache, you are writing heaps of code, logging user every time to get the calling ready. Plus QuickBlox do not keep any session out of box (in the background) so no luck with background listening for incoming calls. So I quit QuickBlox.
2) PubNub - Pretty much OK but the price and the trial is absolutely crazy. I can't imagine myself giving someone 50 dollars every month just for audio call and video call functions, whereas I would not have any income from both of them as there is no such good app in world which offers paid app-to-app calling, so mine should be free too. And also I am in the development phase so I do not want to waste money. They say they giving free 100 users at start. But what it is ridicioulus as 100 users won't give any income so the PubNub is fast out.
3) Sinch - This was the only library I loved and loved really much, I even asked them to add a function of WebRTC of videocalling and they did it! But still there is one more big issue which cannot be handled. The background service. Sinch does not provide and you do not have any chances to listen for incoming calls if your app is killed, so Sinch unfortunately is out too.
4) The last option I HAD to do, because I had no choice, was SIP of Android. It is basically saving hugely but I encountered an issue. I generally and now think to fully move to SIP calls, I did try to load the demo, but what is the issue, is that as far as I understood, to make SIP calls you MUST have a SIP account pre-registered. The horrible part is that I am developing a chat application and that chat application should have that audio calling at least. So it is not good practice to ask users to register a SIP account with in-app account. So by Googling I did not find any solution and came here to ask. Is there any way,to register to a SIP server (free SIP servers which are plenty on the net) with default SIP class of Android, without forcing the user to do it manually? If yes can you please provide code?
I am writing app to monitor data usage by other installed applications. By far, I managed to get data usage through mobile and wlan interface. It will be pretty useful if I could track GPS usage per application (or UID). I dont know how it will be presented (time on "fix", number of requests?).
I can't find anywhere how to get that data. Does android save logs from GPS somewhere I can read them?
As #CommonsWare indicated in the comments, there mostly shouldn't be a way to access that information for application privacy reasons.
However, a question similar to this was asked on another stack exchange website and the solution was to try using an application called Spare Parts.
I am unfamiliar with the application, but I suspect you will be unable to access this information programatically. If all you would like to do is to see this information, this should do nicely. If your intent is to create some logic based on GPS usage, you may run into a little more trouble.
As relatively new to the android platform I was given the task of implementing a email client. For this I want to use an service that allways run in the background (client should allways receive emails as soon as the server gets them, requirement from the customer).
Now I've looked into the Service's in android, but can't seem to find any good answer on whether or not the Service should be local or remote.
What would the main advantages/disadvantages be with choosing one over the other? Bare in mind the Service must be running at all times. I know, I know. BAD. But it is essential to core features of the application.
First, the correct/efficient way to do instant notifications from a remote server like this on Android is to use Google Cloud Messaging. GCM lets you remotely wake up the device by sending an Intent to your application, which you can then use as a signal to fetch the message from the server, post a notification to the status bar, etc.
Doing what you're describing with an eternally running service will have a significant effect on battery life unless you get everything exactly right. Keeping the phone awake all the time is not a viable option. Use GCM and do not roll your own solution for this.
But since your question was more general about whether to run a service in a separate process, in general simpler is better and in this case simpler means running in the same process. You'll have access to all of the various elements of your app's process in memory and in general you will probably have a much easier time. Your events will all happen on the same main thread's Looper. Everything will be much more straightforward.
If you don't already have a very good reason for using a separate process for your service, you should run it in the same process.
Generally I don't know the reason why you can want to use another process. If you will - you'll have to deal with Inter-process communications, with all this AIDL, Parcels etc.
And if you will keep the same process - it will be much easier to transfer the data between your components.
The only reasons to make several processes I think is to try to avoid Android Heap budget limitation. You can try to move heavy objects between processes and try to double your limit. However I think you don't need this, also it's bad way too.
So I will recommend not to play with processes and keep things as simple as possible.
Good luck
Is there anyway to identify when a call goes from 1-to-1 to multiparty/conference call?
Is any kind of broadcast or event called?
Thanks
Unfortunately, not at the moment. This is managed by the system and is inaccessible to developers. The closest you have is TelephonyManager, but you are only really able to access basic information about the phone. I believe this is mainly for security reasons (so people can't "bug" phones with a simple program), but also because telephony is managed on a lower level, within the kernel.
The information his phone has regarding calls is not shared with your phone at any point doing the call or otherwise, it's shared with the towers. there will be no app or software or hardware for that matter that can do what you need unless it's police sting ray
I'm making a mobile app where users should be able to start their own radio broadcast channels from their mobile phone. Other users will then be able to browse broadcasts and connect. It also includes some special perks to make it unique.
I've got the general concept of it thought out.
The thing is, I'm not sure how to implement some kind of "server" for it. I could think of two solutions to my problem currently:
Running a server which manages both the list of broadcasts channels,
and also broadcasts the channel to all users.
Running a server which manages the list. It stores a handle for connecting directly to the broadcasters phone.
Now I'm a total beginner when it comes to how demanding something is. Am I thinking correctly if i say that the first solution would overload the server when there are many users on it?
That would make the second option seem good, although if a channel gets popular enough, wouldn't it require insane amounts of bandwidth for the broadcaster?
Help me out guys, as I said I'm a total beginner when it comes to these kinds of things.
I would just use SHOUTcast or Icecast. It is very easy to start up either of these from another application.
These servers are very simple in their operation. Data comes in (usually encoded in MP3 by the source client [your mobile app]), and the server sends the exact data right out the door to any connected clients. It does implement a small buffer so that receiving clients can be initially flooded with data, to speed up the time before audio is played. You could always implement one of these yourself, but there is no sense in re-inventing the wheel.
You absolutely cannot run a server on the phone itself. Not only won't there be enough bandwidth, but each connection consumes some resources, which are extremely limited on a mobile device. You should host the streams on your own servers, and use the mobile device as a source client.
You're going to have to utilize some off the shelf product here. There's no way you're going to write something yourself that will do what you're hoping (unless your product is a total flop, and no one is using it). People can't broadcast much off their phones (your initial thought), so, you'll *have to be re-broadcasting everything for them, to whoever wants to be listening. It doesn't really matter how popular a specific "station" is, because the point is that you have to be broadcasting to whoever wants to be listening. These sorts of solutions require all sorts of very convoluted server mirroring schemes.
I'm not sure if something like SmartFoxServer can help you or if you want to try to leverage a VOIP server of some kind. I'm sure someone else will pipe in with a more specific and useful suggestion, but I can tell you for certain that this is NOT something you're going to write yourself, if you have no experience with this sort of thing.
And not that you asked, but I'll also note that if the users start broadcasting copyrighted material, then you're liable for pirated distribution of it. So, I'd be VERY careful what you allow people to transmit!