I created a background service on android and I have two buttons which appear on the top of the screen all the time. I want to use these two buttons like scroll down and scroll up. But these two buttons should work on any kind of applications like Instagram, Facebook, Twitter and so. So, it means it should work in all applications that use scrolling.
I search a week on internet but I could not find any solutions.
This is not possible, sorry. Something like this would require your Service to have access to the Views of the applications and this would be a huge security breach, because you could read values from them and so on.
You could achieve this with a custom button code broadcast (so basically your buttons would act as physical buttons on the device) but this would most probably require you to have system-level permissions and some level of cooperation with the OEMs.
Android Activity class has a method called dispatchKeyEvent(), which could let you simulate the key input (with some limitations) but this is not present in the Service class.
Sadly this is not something you can do in Android. Typically you should not be able to touch views with a background service, the point of a background service is that you do some work in it (for example upload files to your web server or get some data). You CAN send a signal from a service once you're finished doing work to tell an app that something needs to happen, however the app needs to be specifically coded to respond to this broadcasted event.
If you wanted to do this with an app that you have developed, that can be achieved by using the onReceive method of say a BroadcastReceiver, however you cannot specifically define the behaviour of other apps as this would represent a security breach in Android.
Related
Is that possible?
I'm developing a service for disabled people. They can define voice commands and the service can detect the commands and execute them. Like when the user says "scroll down", The service (which is in fact a background process) takes control of screen and scrolls down (regardless of what application is on foreground), or touches a specific position and so forth. I wonder if this is possible in an android device? If not, what about a rooted device? (i.e the service has the root permissions). I know that getting voice input and processing it is possible. My question is about doing actions like touch (Action_Down) or scroll the user interface on behalf of a user.
Note that I don't have access to whatever application is running! In fact my service doesn't know about the application that is running on foreground. It might be a social media app or a messaging app or a game or whatever else! So in fact my service must be capable of defining input events like touch, swipe, scroll etc.
Thanks in advance!
Yes, that is possible.
For example, ListView has two methods for programmatic scroll:
listView.setSelection(id); //For instant scroll
listView.smoothScrollToPosition(id); // For smooth scroll
For an example of how to use voice triggered actions - check this answer out
For an example of how to inject events programmatically - check this link out
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.
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.
The primary purpose of my app is to change a smart phone into a sort of smart pager (there is an associated web app, but that's not the purpose of the Android app). I use the Notification system built in to Android to handle alerting the user that they have received a page.
My problem is that the clients want:
The notification ringer to ring forever until acknowledged (easily accomplished with FLAG_INSISTENT)
An easy way to silence the ringer with 1 push of a button. It is really not always feasible due to the nature of their work to press the power button, slide to unlock, and drag down the notification bar. I need to replicate the behavior of a pager.
I need to find a way to satisfy the 2nd requirement. It looks like I can hook into keypresses if I've got an activity running, but of course, when a notification is received, the screen will probably be off. I am looking into this currently, but I was wondering if anyone had some guidance in the meantime.
Does anyone have ideas on how I could accomplish this goal? Are there alternative ways to listen for key presses, or some creative combination of flags that could get me there?
Techniques that would normally be frowned on for Market apps are completely on the table, since the phones are owned by my employer and will only be used by other employees. I just want to avoid using private or deprecated APIs to make switching phone models easier for the developer who eventually inherits this project.
Thank you to everyone for reading!
Does anyone have ideas on how I could accomplish this goal?
You'd have to hold a WakeLock, specifically a FULL_WAKE_LOCK, in order to respond to button presses. This means that battery life will be sucktastic, unless you put some time limit on that (e.g., hold the WakeLock for a minute or two, but otherwise assume the user's not near the device, so don't keep it awake).
You would also need to try to interrupt the keyguard with KeyguardManager. I have not done this so I do not know all of the details. Your "watch for the magic button" logic would have to be in the activity that appears on top of the keyguard.
Also, bear in mind that not all Android devices have physical buttons -- in fact, I would not be the least bit surprised if the whole physical button metaphor goes "poof" with Ice Cream Sandwich later this year. Hence, the button in question really should be an on-screen Button for future-proofing.
Is it possible to customize the call screen in Android? Example would be, two users have the same application, user calls, but the other user cannot pick up, so they respond with some type of predetermined image baked into the application.
Is this possible?
Does this break any rules?
The built-in Phone application is open source, so you can clone it and modify it to your own needs. This will let you make/receive calls using your custom UI (I believe you can receive. It looks like there's ACTION_ANSWER that you can listen to and handle). Of course, the user will be prompted on what application to use for theses actions and you'll have to convince your users that they should use your app instead of the built-in one.