I wonder if it is possible to build an application for Android that waits for incoming calls and only allows the ones that are in an internal white list to show and make sound.
I know this is what a normal call blocker would do and I know that it is possible..however what I really want is:
If a call arrives that is not in the white list, I don't want to reject it, I don't want the caller to know the call was rejected. I just want my app to be aware of it but make it invisible to the current phone app. I could mute the phone and the call wouldn't ring but the phone app would still popup in front of everything or at least on the status bar.
If a call arrives and it is in the white list then the app would do nothing..just allow the phone app to treat it.
I think I can do this by implementing my own dialer app, but would much prefer not having to do that and just use whatever the user already has.
Thank you
Carlos
Related
The problem here often appeared, but I didn't found anything about it for delphi and firemonkey.
I would like to display some information when my application detects an incoming call (Android).
I know it would be best to create my own phone application and set it as the default one.
But Android has Toas and Notification and I thought to use it.
1) I tried to use a toast but did not manage to display information ON THE incoming call screen
2) Notification displays the message but I must first swipe down notification bar. It gives me nothing. I would like information to appear for example like
information about the end of the battery (information available above all screen application)
Is anyone able to tell me something?
Is it possible for a 3rd party Android application on an device that is not rooted, to somehow make an outgoing phone-call, without launching the dialer ? What I mean is that my own Activity (displaying some information, image or video) keeps running in foreground, while the phone-call progresses in the background. Clearly, my Activity needs to be aware of call-state changes (i.e. when call is terminated). My own Activity (not the dialer), would have the "Call" / "Hang-up" buttons.
If possible, kindly share some pointers and hints as to how this could be done. If this is possible via the ITelephony (or other such) reflection based API, even if it is undocumented and hack-based method -- I would like to know about it.
So far in my research, I've come to know of only the method where you place the call directly to a number, without having to open up the Dialer first. However during the phone call, the Dialer application's Activity is open. I cannot show any other information on the foreground. Any alternative workaround, s.a. using Dialog overlay etc., might work as worst-case fallback, though I am not sure if there is anyway to show any "active" content (s.a. images that change, or video) in a Dialog.
Finally, can Fragments be a solution ? Can I show the DialerApplication activity in a Fragment ? I don't think so, but wonder if there's any hack possible for it ?
1) Is it possible for a 3rd party Android application on an device that
is not rooted, to somehow make an outgoing phone-call, without
launching the dialer ? What I mean is that my own Activity
(displaying some information, image or video) keeps running in
foreground, while the phone-call progresses in the background?
Ans.
It is not possible to keep our application foreground during phone call because the phone call is a system app and has highest priority.
2) Clearly, my Activity needs to be aware of call-state changes (i.e.
when call is terminated). My own Activity (not the dialer), would
have the "Call" / "Hang-up" buttons.
Ans.
Yes this is possible to get notify on call-state changes.
Look at here
I'm trying to figure out the right way to add Chromecast buttons (pause, play, etc) to an Android Notification. I've set up a custom notification that sends PendingIntents to a ChromecastService. That service is trying to interact with a class I built called ChromecastAdapter. The ChromecastAdapter implements MediaRouteAdapter and contains all the listeners and state that go along with casting. However, all this state is gone as soon as I exit the application. So, my ChromecastService doesn't end up having access to the Chromecast once my app is gone.
It seems to me that the only way to get this to work is refactor all the Chromecast state into a Service that implements MediaRouteAdapter. I really don't want to do this since I'm pretty happy with the way things are now.
Since these interactive Notifications are required by Google, I feel like there has to be a standard way of interacting with a cast from a Notification. Am I on the right track here? Do I have to place all my Chromecast interactions behind a Service?
What the behavior should be depends on the type of app and the requirements of the app. If your app is "gone" (in the sense that the Application instance is gone), then the question that you should ask yourself is whether you would want to keep a notification mechanism to stay around; there are apps that when they are killed, the receiver also gets closed and user is sent back to the home screen on the chromecast device, in which case there is no reason to keep a notification around.
On the other hand, there are apps that based on their requirements, you would want to let the cast device continue what it was doing (for example play the video) even if the mobile app is gone. In those cases, you may want to have a notification mechanism in place for "bringing up" the app. To achieve that, you need to maintain certain amount of information/state/objects in a service, enough to be able to establish a connection again and "join" the running app. In addition, your "service" needs to be aware of the status of the app on your receiver so if that app is killed (say, someone else starts casting a different app to the device), it can be notified and exit.
I have developed an android app that uses a timer with a call back. When a specific criteria has been satisfied, the app either rings or vibrates the phone depending on user settings. It will continue to ring until the user acknowledges an alert box. This all works fine. However, if the user has brought another app to the front then he may not realize it is my app causing the phone to ring and re-open it. Is there a way I can force my App to the front or at least the Alert Message to be on top of anything else?
Notifications are your friend. They wont interrupt a users workflow and with the new JellyBean apis you can put actions and other dynamic components in them.
Instead of doing that, you could just use a notification with a specific ringtone once it has been sent instead of annoying the user this way.
I am developing an Android app that will run as a service most of the time. The user would be able to control it via the status bar -- including the ability to stop the service altogether.
Even though I am able to make a custom view and put buttons on the Notifications area [see Figure 1], I would like to be able to put it above the "Android"/Service Provider's name. Much in the same way as the Music Player app does this [see Figure 2]. That way, even if the user clears their notifications, my app's control panel will remain active as long as the service is running.
What's the best way to do that, please?
Original Image Link
Your ROM has hidden the Ongoing header; both the Music player and the hardware control widget use the ONGOING_EVENT flag to remain where they are (someone correct me if I'm wrong). Confirm this by loading your app onto your patched phone - the documentation specifically names e.g. Music players (and other times your process is still going on in the background) as times when you should use this flag.
You might like to note that the same page recommends the FLAG_NO_CLEAR flag - if all you want is for it not to be cleared when the user clicks clear notifications (this is recommended for ongoing apps).