I have a requirement where I would want to initiate and manage GSM calls (Like the ones we make via Phone)
I will be connecting to a GSM Module/DTMF Module (context: robotics) via this method and would be sending instructions via DTMF tones.
I don't want to open up the phone dialer via an Intent with tel: data, would rather want to manage the telephony myself.
First thought that the system might not allow a third-party app, without a signature matching system's signature, to do telephony stuff, but then I wondered how some of the apps available in the market are doing it. (I'll attach links as soon as I find suitable ones)
EDIT: The apps that I had seen, were launchers and call manager apps, and once installed, had replaced my default phone apps (and thus were making calls instead of the default phone app doing it)
EDIT: I have found this question asking something similar, and also has an answer: Android Dialer application. I'll try this out and post back if I get any success.
Any pointers will be greatly appreciated.
Related
My team is developing an Android app that includes the ability to call and talk to customer support. We are calling an Intent with ACTION_DIAL, which brings up the dialer with the phone number pre-populated, as expected. In the device emulator, we also see links to Create a new Contact and Add to a Contact, which are fine, but we want to suppress the Send SMS link, since there is no way for us to read messages sent to that number. Ideally, I'd like to be able to pass a parameter or change a setting that disables SMS messaging for that one invocation, but I'm open to other solutions. Searches that I've done haven't turned up anything.
Thanks in advance,
Dan
No. There's no way of knowing what dialer is being launched for action dial- OEMs all have the option of using their own, or the user can even download one of their own. There's no way of knowing what options those dialers support, and definitely no way of configuring them. Even if there was, a dialer app could ignore the configuration. You may want to use ACTION_CALL instead, which requires additional permissions but will directly call without bringing up a prefilled dialer.
I am new to android development. I came to know that Intent and Intent filters can be used to share data among applications but I wonder if it is possible to design an android application which can extract some specific information from other applications while running in the background. For example, if the user is using whatsapp it may get know the call drop rate or if a video is being played at user terminal in YouTube, Facebook or Netflix, it will get buffer playtime, video bitrate etc. I will be very grateful if answer to this question is provided with an example.
No, mostly no.
However, as wrote Tim Castelijns, if the 'target' app allows it, like via a content provider, its possible.
On a rooted device, after long hours of reverse engineering the targeted apps, it MAY also be possible to get some info. Only from rooted devices too.
Other case is you write several app and design that they can communicate together, like via intents, content providers.
There is also possible to get the list of running apps (user must permit it)
In Android, each application is running on its own "sandbox" that is supposed to be isolated from the rest of the applications running on the device.
In order for an application to communicate with other applications, the Android framework supplies several mechanisms to send/receive data to/from other applications: Intents, IPC (AIDL), Content Providers etc...
Each application that wants to expose its data to other applications on the device needs to implement an interface using one or more of the mechanisms described above.
That means that if an application doesn't implement an interface to expose its data or inner workings, it won't be possible for another application to access this information.
Keep in mind that some applications choose to save some of their data on publicly available disk spaces (i.e. a camera that takes pictures might save them on the SDcard that is accessible by all applications). In that case, if you know what to look for, you can tell certain things about certain applications.
In addition, the Android operation system exposes the states of several global settings such as: Device's connectivity state, Battery state, currently opened Bluetooth interfaces, running applications, last executed apps etc...
This configurations might give you an overall idea of what is happening on the device.
As indicated in other answers, you're mostly limited to what apps will explicitly make available to you; in fact, well-engineered apps will generally try to prevent "information leakage" beyond what they actually want to make available.
Some other people mentioned Content Providers but the one other construct to look into is Broadcasts. If an app broadcasts an intent locally (i.e. is using the Local Broadcast Manager) you won't be able to see it but if they're using a "system-wide" broadcast or receiving another "system-wide" broadcast you can receive the same event.
Hey does anyone know if it's possible to intercept incoming calls via an app for both IOS and Android (no jailbreak) then based on certain criteria the phone takes action?
Have already read a few posts saying it's not possible however they are quite old, anyone know of anything new?
Thanks!
The short answer:
On Android: You can do this, but this may require special treatment for different vendors and/or OS versions. It won't be simple to support all (or at least most) devices, but with a lot of manual trial and error, it can be done.
On iOS: It's not possible locally, as Apple sees it as an invasion to the user's privacy.
The (slightly) longer explanation:
What is possible, for both iOS and Android, but will probably require a lot more work and external support than you originally planned, is to divert the calls via a server. This way, when someone calls you, the call is "stolen" by the server (which the user has to manually allow when installing the app) and the call is received on your device as a VOIP call, allowing the app (on the server side) full control over the call (which ones are actually received on the device, what's played, how long, recording, etc). You can see this app for an example of how it works: https://yallo.com/.
I hope this helps. Good Luck.
I'm currently working on a productivity app. One of the features includes obtaining an information about apps that are started by the user
For example I would like to obtain information that the user has started the Youtube app or listen for a specific Intent being sent without registrating a BroadcastReceiver
Is this even possible?
You cannot intercept intents sent to other apps by extending the BroadcastReceiver abstract class for obvious security reasons. So, basically, this is not allowed using conventional features (or APIs) of the Android SDK. There might be some hacks out there that could work, but they're all hacks at the end of the day which are not guaranteed to work, for example there are some articles proposing to read the system's log, it used to work in older api levels but not anymore...see some references below and make sure you read the comments as well...
Android, Detect when other apps are launched
Detect when user launches a new application on an Android device
In simple words, you can't do that. Note, that having root is a complete different story
I'm trying to get an idea of what's possible and what isn't in terms of using a custom dialler app for internet calls.
The idea is that the standard Android dialler be used when no internet connection is available, but use a custom-written VOIP dialler / caller app whenever an internet connection is available.
I see that in the Android call settings you can set it to use Internet calling whenever a connection is available. How does this work? Does this simply tell the native dialler app to use internet calling, or is there actually a specific Intent or something that gets fired when an internet call is made so that I can open my custom SIP app?
And also, is the 'standard phone app' icon always linked to the standard phone app, or can you override this phone icon to open your custom VOIP app when a connection is present?
So basically, is there a way to seamlessly and automatically switch between the standard dialler and the custom SIP dialler based on whether or not the phone is connected to the internet?
If not, is this something that could be done by customizing Android?
Thanks,
There are four possible ways of doing what you want that I know of:
1. Replace the Android Dialer
This is hard and a lot of work. The Android Dialer (last time I checked anyway) WAS the telephony stack in Android. So to replace it you have to replace the complete telephony stack (including any public API) i.e. handle all cellular (and now sip) calls in and out of the device. Also the only way to replace it is to root the device as it can't be replaced normally.
2. Provide your own Dialer that is separate to the main dialer.
This has it's advantages that you will never get into "trouble" with anything else.
3. Hook into the outbound call API (ACTION_NEW_OUTGOING_CALL)
This is something that is pretty cool and I haven't seen any other OS allow you to do. Basically you can trap when either the normal dialer starts to dial a number (or when another application starts to dial a number as well) and you can either allow it through, modify it or cancel it. Behavior I've seen from sip clients is that they will cancel the call and put up a selection screen prompting where you want to send the call (sip, cellular or something else).
Here is an example of it's use.
The downsides are:
You can be fighting with other applications to which gets first go. There is a 'priority' setup, but all I've seen is everybody wants to be number one.
On some Android devices where the OEM providers that own Dialer, they don't always fire it!!!
4. Detect when the dialer is shown and show your own dialer in front of it.
This works and does allow you to provide a nicer more integrated feel as you can provide call type selection within the dialer, as well as other custom number lookups but that can be a little tricky to do on some devices.
I would suggest 3 to begin with as it's pretty easy to do and you can get something up going pretty fast. In code that I have worked on, we have done 2, 3 and 4 and also looked into 1.